Automations not firing before or after update, had to manually trigger the automation.
It’s a simple numeric comparisons based on Hygrometer reading and a helper value that used to work for months until after HAOS 15.0 → 15.1
Values are received I can see them but long standing unchanged automations are not firing, so no dehumidifier running this morning.
It seems I’m headed for real problems, I had to do a power off yesterday as it collapsed and was totally unresponsive.
It’s using exponentially more CPU and periodically spikes memory usage to only dump a huge amount (using OS statistics not product data). I’ve lost confidence in it completely, it’s forcing me to monitor it carefully which makes a mockery if it’s purpose AUTOMATION!
You are not giving us much information on your setup to be able to help you. What hardware are you running on, what installation type, is it a VM? if so using OS information on things like memory use are hugely unreliable. You will need in product info to diagnose that properly.
Without any info to help narrow down possible causes, maybe this can be of help: The Home Assistant cookbook has a whole section on troubleshooting.
I did say I ran it manually, so missing reference is not the issue. I can see the value if the Hygrometer and my configuration page shows the value of the helper it’s compared to, and they function fine before HAOS 15.0 → HAOS 15.1
It’s now telling me switches are on that’s off, things are full that aren’t, and well it’s so slow I’m forced to reboot several times.
I only have warning in logs after a clean reboot and then it just degrades to unusable.
I’ve remove Tuya and PI-Hole integrations and it seems to have settled a little.
I’m still getting an error though.
Logger: zigpy.zcl
Source: runner.py:154
First occurred: 20:30:36 (3 occurrences)
Last logged: 21:25:22
[0x1592:1:0x0020] Traceback (most recent call last): File “/usr/local/lib/python3.13/site-packages/zigpy/device.py”, line 381, in request return await req.result ^^^^^^^^^^^^^^^^ asyncio.exceptions.CancelledError The above exception was the direct cause of the following exception: Traceback (most recent call last): File “/usr/local/lib/python3.13/site-packages/zigpy/zcl/init.py”, line 378, in request return await self._endpoint.request( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ …<9 lines>… ) ^ File “/usr/local/lib/python3.13/site-packages/zigpy/endpoint.py”, line 270, in request return await self.device.request( ^^^^^^^^^^^^^^^^^^^^^^^^^^ …<11 lines>… ) ^ File “/usr/local/lib/python3.13/site-packages/zigpy/device.py”, line 380, in request async with asyncio_timeout(timeout): ~~~~~~~~~~~~~~~^^^^^^^^^ File “/usr/local/lib/python3.13/asyncio/timeouts.py”, line 116, in aexit raise TimeoutError from exc_val TimeoutError The above exception was the direct cause of the following exception: Traceback (most recent call last): File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/general.py”, line 630, in check_in_response await self.checkin_response(True, self.CHECKIN_FAST_POLL_TIMEOUT, tsn=tsn) File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/init.py”, line 85, in wrapper with wrap_zigpy_exceptions(): ~~~~~~~~~~~~~~~~~~~~~^^ File “/usr/local/lib/python3.13/contextlib.py”, line 162, in exit self.gen.throw(value) ~~~~~~~~~~~~~~^^^^^^^ File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/init.py”, line 70, in wrap_zigpy_exceptions raise ZHAException(“Failed to send request: device did not respond”) from exc zha.exceptions.ZHAException: Failed to send request: device did not respond
[0x7F30:1:0x0020] Traceback (most recent call last): File “/usr/local/lib/python3.13/site-packages/zigpy/device.py”, line 381, in request return await req.result ^^^^^^^^^^^^^^^^ asyncio.exceptions.CancelledError The above exception was the direct cause of the following exception: Traceback (most recent call last): File “/usr/local/lib/python3.13/site-packages/zigpy/zcl/init.py”, line 378, in request return await self._endpoint.request( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ …<9 lines>… ) ^ File “/usr/local/lib/python3.13/site-packages/zigpy/endpoint.py”, line 270, in request return await self.device.request( ^^^^^^^^^^^^^^^^^^^^^^^^^^ …<11 lines>… ) ^ File “/usr/local/lib/python3.13/site-packages/zigpy/device.py”, line 380, in request async with asyncio_timeout(timeout): ~~~~~~~~~~~~~~~^^^^^^^^^ File “/usr/local/lib/python3.13/asyncio/timeouts.py”, line 116, in aexit raise TimeoutError from exc_val TimeoutError The above exception was the direct cause of the following exception: Traceback (most recent call last): File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/general.py”, line 630, in check_in_response await self.checkin_response(True, self.CHECKIN_FAST_POLL_TIMEOUT, tsn=tsn) File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/init.py”, line 85, in wrapper with wrap_zigpy_exceptions(): ~~~~~~~~~~~~~~~~~~~~~^^ File “/usr/local/lib/python3.13/contextlib.py”, line 162, in exit self.gen.throw(value) ~~~~~~~~~~~~~~^^^^^^^ File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/init.py”, line 70, in wrap_zigpy_exceptions raise ZHAException(“Failed to send request: device did not respond”) from exc zha.exceptions.ZHAException: Failed to send request: device did not respond
What’s the point of highlighting an error without any definition of which devices it’s occuring on?
Plus the ping tests are unreliable after months without issue prior to the HAOS upgrade.
It’s highly recommended to read the release notes before upgrading and check the breaking changes as well, that is: if your HA plays an important role in the house and even more if you don’t live on your own and you have automated basic stuff such as lights
No it isn’t, it’s very common in failed software development, coming from writing SCADA system for decades you be in prison with failure rates like this. Imaging if my nuclear power monitoring it oil platforms just stopped working? Making excuses for such catastrophic failure is part of the problem. It’s not rare or controlled at all.
It’s absurd this is considered complete or stable.
I’ve just discovered my laptop refused to start charging because the MQTT posting the Hone Assistant is receiving and displaying did NOT trigger the <30% battery level it is displaying (therefore receiving) but failed at 29%, 28% and 27% to actually turn on the socket - that incidentally before HAOS 15.1 worked reliably.
The entire package is unreliable and far from functionally acceptable after uodates do this. If this was being sold regardless of dismissal of accountability there would be a slew of legal action in respect of the damage it can potentially cause.
Being free shouldn’t mean it’s operationally risky to use. Disclaimers don’t excuse such catastrophic failures…
If software doesn’t reliably do what it claims to what’s the point of it? Someone’s pet project that escaped?
The release notes cover speech and other protocol inclusions that aren’t relevant to my implementation, no warning, no references they’re the same document modified slightly each time.
You’re told remain up to date but each update destabilised what you have.
This isn’t new to me I tried several years ago and it collapsed on a heap then too. Shedding devices until only three remained.
It’s very very unstable and the excuse is “this is what softwares like”. I wrote system that ran for years and a failure would shutdown a business if it failed.
I really don’t understand people who think this is how it should be.
I’ve done dangerous goods monitoring, health & safety system, warehousing and product management, transport planning from before Microsoft had windows and networking was a thing.
Believe me in business this haphazard ideology won’t fly!
This is likely an issue with your hardware, not the software. I’d start by looking at your coordinator because it’s having trouble talking to your devices. The error is saying that your devices are not responding.
As usual two statements out of context and a flippant challenge. Stop making excuse for shoddy unstable work.
You’ve got a good backup system without a workable restore system, to be forced to rebuild it to restore is absurd. You rebuild a complete system to restore?
And this is the system you want to enable open access to your network to deposit files on?
If core functionality can just stop there is no core functionality.
To be offered a dump of an error with no real definitive description is NOT an acceptable error messaging.
To have a system go from functional and stable to unstable on an upgrade that they assert “is required”, that isn’t software it isn’t development, it’s what known as cyber hacking taking control of some bodies system and crashing it…
Nowhere in the release notes does even imply “this may cause instability or create non-functional systems”.
There’s obvious no soak tests before release and testing is obviously very limited and does not account for interoperability when the entire system is codependent built on interdependent layers. That they can’t be testing prior to release.
Stop making excuses for this it’s not acceptable! Even free!
Your subject refers to the HA version and your complaints refer to the HAOS update (very different things). Which one are you actually complaining about?
@Dave_of_Yorkshire I think you will offend a lot of people with your comments. A lot of work goes into the beta testing. Are you using custom integrations? If you are these are not covered by the HA developers and you need to take it up with the integration developer.
Are your triggers firing and the automations not continuing (use trace for this - firing them manually bypasses the triggers).
A simple methodical approach is usually the route to finding the issue. There are a lot of users of HA and if all automations ceased to function I think the forums/discord would be alight with issues.
