Think I have something working now.
So I made a time scheme with a time slot that triggers 4 switch
entities (yes I can do that) to turn on simultaneously.
Switches 1 and 2 are off, switches 3 and 4 are unavailable (I used MQTT availability topic to test).
So I restart HA, in the middle of the time slot.
Shortly after restart I change the availability for switches 3 and 4.
Hereâs the results:
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler] Scheduler coordinator is ready
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] Rescheduling timer for switch.schedule_fcda8c
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] We are starting in a timeslot. Proceed with actions.
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] Start of executing actions for switch.schedule_fcda8c
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] Executing action switch.turn_on for entity switch.switch_1.
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] Executing action switch.turn_on for entity switch.switch_2.
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] Entity switch.switch_3 is not available right now, action switch.turn_on will be queued.
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] Entity switch.switch_4 is not available right now, action switch.turn_on will be queued.
2020-10-03 17:01:08 DEBUG (MainThread) [custom_components.scheduler.switch] The next timer is set for 2020-10-04T16:45:00+02:00
2020-10-03 17:01:14 DEBUG (MainThread) [custom_components.scheduler.switch] Entity switch.switch_3 was updated to state=off, processing queued action.
2020-10-03 17:01:14 DEBUG (MainThread) [custom_components.scheduler.switch] Executing action switch.turn_on for entity switch.switch_3.
2020-10-03 17:01:20 DEBUG (MainThread) [custom_components.scheduler.switch] Entity switch.switch_4 was updated to state=off, processing queued action.
2020-10-03 17:01:20 DEBUG (MainThread) [custom_components.scheduler.switch] Executing action switch.turn_on for entity switch.switch_4.
As you can see, there is detection of unavailability before executing the action.
Unavailable entity actions are queued, and a listener is activated, which waits for the entity to have a state change.
Entities that are available will have their action executed right away.
In the mean time the next timer will be set for tomorrow (which is the next timeslot in my fictive case).
There is still listeners for switches 3+4 active on the background.
When the switches come available, their action is also executed.
The queue is automatically wiped when entering a new timeslot.
But as long as a device goes from unavailable->available within the timeslot, its action will be triggered.
Only the first time though. I donât want to enforce the entity to keep the state set during the whole timeslot. And I am assuming that devices have state persistence.
I will add the same functionality to the normal (non time scheme) schedules.
Only here the retry will be limited to a timespan of 10 mins, since you donât want the retrying to last up to 24hrs.
If you have any devices with (WiFi) stability issues, the scheduler can deal with these.
I think it seems pretty solid this way. What do you think?
@Canaletto Your (rather empty) post does not belong in this topic.
If you have a problem with HACS, you should write to them, not complain here.
HACS is pretty notorious for causing huge amount of GitHub trafficâŠ
âextra keys not allowed @ data[âpresetâ]â when trying to adjust time/add another time slot for climate, set preset, none. If the change in time is 20 mins or less, it works ok. Ie. I can adjust the slider by adding 20 and 20 mins, and saving in-between. If trying to move the slider >20mins, it fails with the mentioned fault.
A bit hard to describe this one, so please ask for more details if this one is unknown
Looks promising. How do you check the availability?
Afaik z-wave devices donât have a state called âavailableâ but âreadyâ (when HA starts they are starting in the state âinitializingâ)
Yes indeed it is now OK after one hour⊠Sorry
@aeklo looks like a typo in the standard configuration registry. Sorry for that. Will fix it in a new release.
Hello,
congratulations for this development. When I use the scheduler with my air conditioning which is managed by my broadlink which uses âclimateâ, the thermostat displays cool heat and off, but I would like to display on, which will turn on the air conditioning.
Thank you in advance for your help.
States unavailable and unknown will be checked. Others are very platform specific, I cannot account for all of these.
My z-wave devices go to unavailable when the z-wave network is down.
I would expect yours will do the same. Unless you mean the. zwave.my_device
entities, but those are not involved in the scheduler, only the actuator entities.
The options that you can choose from, are taken from the properties of the device.
If âheatâ is shown, it means your device supports mode âheatâ.
There is no easy way to hide it. Unless you write your own customized action for it.
If you have z-wave devices and you say it works with those, then it is fine by me. Iâm sure itâll work with mine too
I have a problem, whatâs with this:
Logger: homeassistant
Source: core.py:1269
First occurred: 19:10:00 (1 occurrence)
Last logged: 20:47:00
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File â/config/custom_components/scheduler/switch.pyâ, line 271, in async_timer_finished
await self.async_execute_command()
File â/config/custom_components/scheduler/switch.pyâ, line 322, in async_execute_command
await async_call_from_config(
File â/usr/src/homeassistant/homeassistant/helpers/service.pyâ, line 91, in async_call_from_config
await hass.services.async_call(*parms, blocking, context)
File â/usr/src/homeassistant/homeassistant/core.pyâ, line 1269, in async_call
processed_data = handler.schema(service_data)
File â/usr/local/lib/python3.8/site-packages/voluptuous/validators.pyâ, line 208, in cal
return self._exec((Schema(val) for val in self.validators), v)
File â/usr/local/lib/python3.8/site-packages/voluptuous/validators.pyâ, line 287, in _exec
raise e if self.msg is None else AllInvalid(self.msg, path=path)
File â/usr/local/lib/python3.8/site-packages/voluptuous/validators.pyâ, line 283, in _exec
v = func(v)
File â/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.pyâ, line 272, in call
return self._compiled(, data)
File â/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.pyâ, line 817, in validate_callable
return schema(data)
File â/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.pyâ, line 272, in call
return self._compiled(, data)
File â/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.pyâ, line 594, in validate_dict
return base_validate(path, iteritems(data), out)
File â/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.pyâ, line 432, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data[âmodeâ]
Thanks for your help
An invalid service call. What schedules do you have set up?
Climate.set_hvac_mode and climate.set_preset have a typo in the config!
It needs to be fixedâŠ
I was setting up my schedules to be as simple as possible, which is how I found your project. My suggestion for grouping the same entities together was because I had one schedule for turning an entity on and then another schedule for turning the same entity off. That resulted in me having two items. You actually solved my feedback when you introduced the whole time scheme piece. Once you added schemes, that did away with me having to setup multiple schedules for the same device. Amazing!
It would be nice to be able to sort the schedules similar to how other cards allow you to move entries.
Super cool!! But way more complicated than I was looking to start with as a first time HA user. Definitely want to get to that level of customization though.
Sorry if my English is not very good, but if I understand correctly, this will be corrected in a future version?
Yeah, itâll be fixed.
Thankâs