Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publisch next scheduler action to HA #170

Closed
RonnyDeLoor opened this issue Jan 17, 2022 · 17 comments
Closed

Publisch next scheduler action to HA #170

RonnyDeLoor opened this issue Jan 17, 2022 · 17 comments

Comments

@RonnyDeLoor
Copy link

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
Copy link
Contributor

KTibow commented Jan 17, 2022

The scheduler entities already exist.

@nielsfaber
Copy link
Owner

Schedule entities already show the planned actions in their attributes:
image

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link

peely commented Jan 24, 2022

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 😅

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
Copy link

peely commented Jan 25, 2022

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
Copy link
Author

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:

  1. 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

  1. 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
Copy link

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
Copy link

I checked for similar existing requests (both open and closed) before posting.
You sure?
Duplicate of #170.
Originally posted by @nielsfaber in #174 (comment)

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
Copy link
Owner

I am proposing the following changes:

  1. 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.
  2. 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).
  3. 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
Copy link

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
Copy link
Owner

@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
Copy link

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
Copy link
Author

Hi Niels,

I am perfectly happy with your proposed change.
Thanks

@nielsfaber
Copy link
Owner

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
Copy link

Thank you very much @nielsfaber works great

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants