Scheduled zones becomes unavailable whenever the HA host reboots
soheiladeli opened this issue · 18 comments
Hi, I have latest version HA OS (2024.9.1) running on a VM which has a reboot schedule for two times a week and I have the latest version of the irrigation program (V5.4.20).
I noticed whenever the HA host reboots the irrigation automation is not running as scheduled.
I had a look next time and I noticed after the HA host reboots, the 'Next Run' time on the zone becomes unavailable an it does not run on the scheduled time.
If I make a dummy change on the program time, then it becomes available and shows the 'Next Run' time correctly as you see below.
For now as a temporarily solution I have set a automation to update the program time helper about half an hour after the HA host reboot time, which make it working.
Hi @soheiladeli
V2024.09.01 is up as a Beta, I have not been able to recreate you specific issue with this release. Please try this version and let me know if the issue persists.
Pete
Hi @petergridge , thanks for looking into this. I just installed the new V2024.09.01. unfortunately its happening again after the reboot as you see below:
if I disable and then enable the program or the zone, then it shows the Next Run_
Do you get any error messages in the log?
no, there are no errors in the log!
The next run goes into an unavailable state when the switch/valve does not have a valid on/off state. So I am guessing that the Irrigation program is checking these before they have completed setting up.
If you restart HA, not your entire VM does the same issue occur?
Are you comfortable with modifying a little code?
at line 374 of the switch.py file:
change
self._unsub_start = async_at_start(self.hass, hass_started)
to
self._unsub_start = async_at_started(self.hass, hass_started)
This should wait for HA to complete the start before firing the next_run calculation. It may work, it does not impact the operation on my hardware.
The next run goes into an unavailable state when the switch/valve does not have a valid on/off state. So I am guessing that the Irrigation program is checking these before they have completed setting up.
If you restart HA, not your entire VM does the same issue occur?
just tested with only restarting HA, and it happened again
Are you comfortable with modifying a little code? at line 374 of the switch.py file: change self._unsub_start = async_at_start(self.hass, hass_started) to self._unsub_start = async_at_started(self.hass, hass_started)
This should wait for HA to complete the start before firing the next_run calculation. It may work, it does not impact the operation on my hardware.
Ok Thanks, I'll change the code and give it a try now
ok after making the change and restarting HA, the program did not load and I get below error in the logs:
Logger: homeassistant.components.switch
Source: helpers/entity_platform.py:595
integration: Switch (documentation, issues)
First occurred: 10:52:26 PM (1 occurrences)
Last logged: 10:52:26 PM
Error adding entity switch.program_1 for domain switch with platform irrigationprogram
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 595, in _async_add_entities
await coro
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 909, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1365, in add_to_platform_finish
await self.async_added_to_hass()
File "/config/custom_components/irrigationprogram/switch.py", line 376, in async_added_to_hass
self._unsub_start = async_at_started(self.hass, hass_started)
^^^^^^^^^^^^^^^^
NameError: name 'async_at_started' is not defined. Did you mean: 'async_at_start'?
Sorry, I forgot the import. At line 28:
from homeassistant.helpers.start import async_at_start
Add ',async_at_started'
Updated the code and rebooted but unfortunately it still happens and the Next Run is unavailable
Thanks, I have a couple of ideas to progress this, I thought that solution was too easy, but worth a try
Here is one more change to verify:
Can your replace the function check_switch_state(self): with the code below. Make sure to maintain the indentation.
This will wait for a few seconds before reporting a switch as unavailable.
irrigationzone.py line 476.
def check_switch_state(self):
"""Check the solenoid state if turned off stop this instance."""
for _ in range(CONST_LATENCY):
if self.hass.states.get(self.switch).state in ["off","closed"]:
return False
if self.hass.states.get(self.switch).state in ["on","open"]:
return True
asyncio.sleep(1)
return None
Hopefully this solves the problem.
Cheers
Pete
Hey Pete, much appreciate your help mate, unfortunately still the same issue :(
But I got below warning in the logs this time:
This error originated from a custom integration.
Logger: py.warnings
Source: custom_components/irrigationprogram/irrigationzone.py:493
integration: Irrigation controller (documentation, issues)
First occurred: 10:18:51 PM (1 occurrences)
Last logged: 10:18:51 PM
/config/custom_components/irrigationprogram/irrigationzone.py:493: RuntimeWarning: coroutine 'sleep' was never awaited asyncio.sleep(1)
After rechecking I noticed that the state of my water tap timer stays unknown after reboot for almost 30 seconds until it becomes available. Its strange, as it is a Zigbee device, all my other zigbee devices become available almost instantly but for some reason the state of this tap timer and also my soil sensor stay unknown for about 20-30 seconds. Anyway thank you for looking into this, I know this issue is not related to your component, but wish there was a way for me to fix it.
I haven't given up on this, I have added monitoring of the zones, when the state changes it should trigger to set the next run attributes. It does not appear to impact the process, but I may to remove it if the early adopter Beta downloaders find issues.
Let me know if it works, it is difficult to test.
excellent job! tested and YES, its working now on the V2024.09.02
Thank you very much!
happy to help, it is unlikely that you will be the only person having the issue, the zigbee devices are getting cheaper and more common. Hopefully no knock on effects. I'll close this ticket.