RonnyDeLoor commented 2 years ago

Checklist

[x ] I checked for similar existing requests (both open and closed) before posting.
[x ] My request is generic, other users may benefit from it too.

Proposal

I really like the scheduler component and now mainly use it to set schedules for my home thermostats. In times of high energy prices I would like to make my (custom) thermostat code more intelligent.

By intelligent I do not mean 'app' access, but a real intelligent home heating algorithm. My current system is already taking the outside weather temp in consideration to set the boiler temperature (floor heating). My next step is to predict when the heating really should start depending on the time I would like to have a certain temperature in the house (set by the scheduler card/component) and the temperature difference between the room and external temperature. Especially for floor heating this is really important, since there is a big delay (several hours) between switching on the system and reaching the desired temperature.

So I would like you to consider to make the next action (as can be seen in the live view) available in something like a text sensor. So we can access this info from HA code and decide at what appropriate time we should take action to be 'ready' in time.

KTibow commented 2 years ago

The scheduler entities already exist.

nielsfaber commented 2 years ago

Schedule entities already show the planned actions in their attributes:

The only thing which might not be visible from it is which action(s) apply to which timeslot(s), it's just a list of ALL actions in the schedule. Is what you're looking for an extra property relating the configured times with the ID the action? Otherwise, please elaborate.

I don't think adding a text sensor per schedule is a good idea. You could always create this with a template, but 9/10 users wouldn't be too excited with the extra entities.

BTW: it is not feasible to show the name of the action (as displayed in the card) in the entities, since these are defined in the code of the card only. So for scheduler entities, the action refers to the service + parameters.

RonnyDeLoor commented 2 years ago

Hi Niels, Thanks for your fast response. So what I am missing is how to access the switch attribute(s) in a lambda python code. So is it as simple as switch.schedule_84d16a.next_trigger to get the next action time ? If I can read the attributes, I probably can work out myself what the next action will be (based on next_slot?

RonnyDeLoor commented 2 years ago

I got a bit further. I managed to get the next action time in a template sensor. So question left is: can I deduce the action corresponding to this trigger ?

RonnyDeLoor commented 2 years ago

Hi Niels,

I fear I am stuck again. I believe it is not possible to relate actions to the time slots. In my case I have three Times: 0h 5h00 and 21h00, but since I switch temperature from 19 to 21 and back to 19 degrees, I only see 2 actions, (I see 3 actions when the evening time slot has a different temperature.) But is it guaranteed that the actions are in the slot order?

So coming back to your question: Is what you're looking for an extra property relating the configured times with the ID the action? I know would say YES.

peely commented 2 years ago

Amazingly, I started trying to create a display for my home-made thermostat this weekend (TYVM for enabling that project via this component BTW), eventually got to the part where I wanted to display the "Next temperature target", and stumbled into this exact problem. I can't tell which "action" corresponds to the next "slot" from the /api/states endpoint. I came here to look for similar issues, and this one is 7 days old :sweat_smile:

Is what you're looking for an extra property relating the configured times with the ID the action?

Is 100% what i'm looking for yes. Would it be possible?

peely commented 2 years ago

I don't know Python, and I don't know how to write a Home Assistant integration. But I was reading through your source anyway. Seams the data we want is in the .storage file, but it gets separated out when defining a few properties. I don't know how these properties make it into the /api/states response, but if we could have another one of timeslots which is just a key-value pair of timeslot-action, the value of action being the index of the associated action in the in the actions property maybe?

I'm sure i'm missing loads of complexity, like "is it really the next action if the condition is not met when the timer expires", but i'm not sure how to solve that right now. Maybe make it clear that the "next" action might not happen, but calling the property "next_scheduled_action" or "potential_next_action" or something.

RonnyDeLoor commented 2 years ago

Hi Niels, Peely,

I managed to get to the info wanted by, and make the 'actions' attribute to return the 'all_actions' structure. At this time it seems the action list ordering complies with the time slot ordering, and next_slot can be used as an index in 'all_actions' list to get what we need:

adding all_actions property to 'switch.py':

..... @property def all_actions(self): actions = [] if not self.schedule: return for timeslot in self.schedule[const.ATTR_TIMESLOTS]: for action in timeslot[const.ATTR_ACTIONS]: my_action = { CONF_SERVICE: action[CONF_SERVICE], } if action[ATTR_ENTITY_ID]: my_action[ATTR_ENTITY_ID] = action[ATTR_ENTITY_ID] if action[ATTR_SERVICE_DATA]: my_action[ATTR_SERVICE_DATA] = action[ATTR_SERVICE_DATA]

if my_action not in actions:

            actions.append(my_action)
    return actions

... @property def state_attributes(self): """Return the data of the entity.""" output = { "weekdays": self.weekdays, "times": self.times, "actions": self.all_actions, "current_slot": self._current_slot, "next_slot": self._next_entries[0] if len(self._next_entries) else None, "next_trigger": self._timestamps[self._next_entries[0]] if len(self._next_entries) else None, "tags": self.tags, } return output

accessing the attributes from configuration.yaml, I created two template sensors to get next trigger time and action:

template:

sensor:
- name: "Living next action" state: > {% set next_slot = state_attr('switch.schedule_living_area', 'next_slot') | int %} {% set actions = state_attr('switch.schedule_living_area', 'actions') %} {{ actions[next_slot]['service_data'] | string}}
- name: "Living next trigger time" state: > {{ state_attr('switch.schedule_living_area', 'next_trigger') }}

So Niels, it would be nice if you would consider adding the 'all_actions' property in next release.

pebblebed-tech commented 2 years ago

Hi Niels, Peely, Ronny, Along a similar line being able to get a list of all actions ideally in a easily accessible format/ structure would be great. Bit of background I am creating a controller for a biomass boiler heating system using ESPHome and I want it to be able to operate standalone if HA is not available so normal operation this scheduler would manage the scheduling of the system but in fallback I want the ESPHome device to be able to operate the system so being able to get a list of actions with times that could be stored of the ESP device would would be amazing

Thank You All

florianec commented 2 years ago

I checked for similar existing requests (both open and closed) before posting. You sure? Duplicate of #170. Originally posted by @nielsfaber in https://github.com/nielsfaber/scheduler-component/issues/174#issuecomment-1025505875

I confess to didn't read the thread here. I wanted the current scheduler action, so i just read "next scheduler action" and thought – no.

So Niels, it would be nice if you would consider adding the 'all_actions' property in next release.

That would be perfect!

nielsfaber commented 2 years ago

I am proposing the following changes:

The attribute times is renamed to timeslots and will have a list of slots where each item has format hh:mm - hh:mm (first is start time, second is stop time). In case of a schedule without timeslots the list will contain a single time with format hh:mm.
The attribute entities is added which contains the list of entities involved in the actions of the schedule. Since they are in common for all actions, I think it is practical to show them separately (it's also easier to get them using a template).
the attribute actions is changed and will now contain a list of action per timeslot. So first list item corresponds to timeslot 0, etc.

Note that the current_slot and next_slot properties represent the number of the timeslot, so they can be used to find the relevant item in the list of actions as well as timeslots.

Example:

@RonnyDeLoor @peely @paul-at-pebbletech @florianec please put a thumbs-up on this message if you're happy with this proposal, otherwise please share your counterproposal.

pebblebed-tech commented 2 years ago

Yes happy with the proposal but it would be nice to get a field that has the timeslots and the actions in a comma delimited string. That could then be consumed by a device. The reason I have adopted HA & ESPhome is mantra of driving automation to the edge. EG not relying on high order capabilities such as cloud compute and even HA, such as being able to get the sensor devices to operate when HA is not available. This would aid this approach, but if it is a stretch to far I can use a python script to achieve it. @nielsfaber Do you want me to raise a separate request for such a capability as it beyond the initial usecase in this issue?

nielsfaber commented 2 years ago

@paul-at-pebbletech I don't want to go that route. HA uses yaml format for the attributes (see e.g. weather entities), so I intend to keep it the same. The attributes should remain readable for the user and (ideally) be usable in templates (either for automation/scripts or populating sensor states).

If you want to go crazy, you should consider using websocket API. This is how scheduler card communicates with the component as well. The state attributes will never give you the full configuration (e.g. conditions are not displayed). With websocket API this is much more flexible (and you can also interact with scheduler).

pebblebed-tech commented 2 years ago

Ok I respect your view. But I think I will stick with the python script approach as its one less technical head to deal with. Hopefully :-)

RonnyDeLoor commented 2 years ago

Hi Niels,

I am perfectly happy with your proposed change. Thanks

nielsfaber commented 2 years ago

Release v3.2.7 of scheduler-component contains these changes. I think we can close this now. Let me know if there are problems.

pebblebed-tech commented 2 years ago

Thank you very much @nielsfaber works great

nielsfaber / scheduler-component

Publisch next scheduler action to HA #170

Checklist

Proposal

if my_action not in actions: