Ramans fixes only fixed zwave, you should report your issues on github with the devices (and their integrations) that are causing the problem.
The problems clearly must be lying much deeper.
The symptoms are still the same. Upon upgrading to 9.1, some automations will just freeze the first time they are invoked - never to be unfrozen unless the system is restarted. Up restarting HA, the same thing will happen again instantly. I, thus, assume there is an underlying problem with the mechanism to release a running automation. If I may be so bold to suggest looking for a problem in zwave might just be looking in the wrong place. As aforementioned, I have never used zwave ever.
I cannot report on Github since I do not have an account. Due to its ownership I am not inclined to sign up there.
it is not lying deeper. We know what’s causing it.
Thanks for the prompt response. I appreciate this.
But then, how can the freezing affect systems without any zwave integration? As mentioned earlier in this thread, some of my integrations have worked flawlessly for years. It is only the core upgrade from 73. to 8 or 9.1 respectively bringing some of them to a halt (never to be unforzen again - unless the core is restarted).
P.S. A rollback to 7.3 gets everything working again.
because, it’s caused by whatever integration you’re using. Not zwave. That’s what you aren’tr understanding. The device is causing the automation to halt, not automations.
And because you’re unwilling to report your devices due to account creation, your device/integration won’t be fixed.
2 Likes
Isn’t this somewhat a contradiction? First you said the problem is linked to zwave. Then you said the automation is halted by any device (sounds more generic to me).
One of the automations freezing instantly (on 2023.8+) is triggered by these devices:
- sun
- time
- 3x Aqara door sensors (DeCONZ) (reporting as lumi.sensor_magnet.aq2)
- 3x Door sensors (DeCONZ) (reporting as eWeLink DS01)
- 2x Aqara motions sensors (DeCONZ) (reporting as lumi.sensor_motion.aq2)
- 1x IKEA motion sensor (DeCONZ) (reporting as Signify Netherlands B.V. SML004)
I was always under the impression that using ConBeeII/DeCONZ was not very exotic, i.e. there might be fellow users.
You clearly haven’t read the thread.
A timeout was removed from automations to allow for services to return data. This timeout will never be added again. This timeout allowed automations to continue when a service call lagged beyond 10 seconds, which should never happen.
A fix was deployed to fix Zwave service calls, so that they didn’t lag beyond 10 seconds.
This is now happening for you in whatever integration you’re using.
And, it’s not the trigger that’s causing the lag, it’s a service call. I.e. what’s in your actions.
So, before you continue to argue on what we know the problem is, Please do us a favor and find out the actions that are causing your automation to lag. Note the integration that creates the device, and report that integration.
2 Likes
Thank you for clearing this up to me. So, it seems like DeCONZ needs to be fixed as well, since my service calls (in this example) all seem to point to one Zigbee lamp (reporting to DeCONZ as LEDVANCE CLA60 RGBW Z3). However, depending on things happening in the house, there might be more than one service call to that very lamp within a very short time.
My apologies if I came across as “arguing”. I was just trying to get a clearer picture.
Here are the actions performed on the ZigBee lamp (reporting to deCONZ as LEDVANCE CLA60 RGBW Z3). The lamp (and the sensors) are all using the deCONZ integration.
- alias: Corridor downstairs lamp changes on event
trigger:
- platform: sun
event: sunset
offset: -00:10:00
- platform: time
at: '19:00:00'
- platform: state
entity_id: binary_sensor.door_kitchen
- platform: state
entity_id: binary_sensor.door_familyroom
- platform: state
entity_id: binary_sensor.door_antecorridor
- platform: state
entity_id: binary_sensor.door_maindoor
- platform: state
entity_id: binary_sensor.motion_antecorridor
- platform: state
entity_id: binary_sensor.presence_corridor_downstairs
- platform: state
entity_id: binary_sensor.door_bathroom
- platform: state
entity_id: binary_sensor.presence_wc
action:
- choose:
- conditions:
- condition: state
entity_id: binary_sensor.door_maindoor
state: 'on'
sequence:
- service: light.turn_on
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 0
color_name: silver
brightness: 255
- conditions:
- condition: state
entity_id: binary_sensor.door_bathroom
state: 'off'
- condition: state
entity_id: binary_sensor.presence_wc
state: 'on'
sequence:
- service: light.turn_on
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
color_name: purple
brightness: 255
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.door_bathroom
from: 'off'
to: 'on'
- service: automation.trigger
target:
entity_id:
- automation.corridor_downstairs_lamp_changes_on_event
- conditions:
- condition: state
entity_id: binary_sensor.door_bathroom
state: 'off'
sequence:
- service: light.turn_on
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
rgb_color:
- 255
- 0
- 100
brightness: 255
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.door_bathroom
from: 'off'
to: 'on'
- service: automation.trigger
target:
entity_id:
- automation.corridor_downstairs_lamp_changes_on_event
- conditions:
- condition: state
entity_id: binary_sensor.presence_wc
state: 'on'
sequence:
- service: light.turn_on
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
rgb_color:
- 80
- 0
- 255
brightness: 255
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.presence_wc
from: 'on'
to: 'off'
- service: automation.trigger
target:
entity_id:
- automation.corridor_downstairs_lamp_changes_on_event
- conditions:
- condition: or
conditions:
- condition: time
after: "21:59:00"
- condition: sun
before: sunrise
- condition: numeric_state
entity_id:
- sensor.motion_patio_lux
below: 2000
- condition: or
conditions:
- condition: state
entity_id: binary_sensor.presence_corridor_downstairs
state: "on"
- condition: state
entity_id: binary_sensor.motion_antecorridor
state: "on"
- condition: template
value_template: "{{(as_timestamp(now()) - as_timestamp(states.binary_sensor.door_antecorridor.last_changed) < 5)}}"
- condition: template
value_template: "{{(as_timestamp(now()) - as_timestamp(states.binary_sensor.door_familyroom.last_changed) < 5)}}"
- condition: template
value_template: "{{(as_timestamp(now()) - as_timestamp(states.binary_sensor.door_kitchen.last_changed) < 5)}}"
- condition: template
value_template: "{{(as_timestamp(now()) - as_timestamp(states.binary_sensor.door_maindoor.last_changed) < 5)}}"
sequence:
- service: light.turn_on
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
color_temp: 425
brightness: 255
- delay: "00:05:00"
- service: light.turn_off
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
- conditions:
- condition: sun
after: sunset
after_offset: "-00:30:00"
- condition: time
before: "22:00:00"
sequence:
- service: light.turn_on
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
color_temp: 425
brightness: 255
default:
- service: light.turn_off
target:
entity_id:
- light.extended_color_light_corridor_downstairs
data:
transition: 2
mode: restart
max_exceeded: silent
If I may just add a reference to the report below on the forum. It does not seem like that person was using deCONZ. The fact that also the automation.trigger functionality (restarting that same automation) was specifically named still makes me wonder if the real problem is not located deeper in HA core. If an automation needs to be restarted, surely a still running job must be cleared instantly no matter the state of the integrations involved, right?
I have upgraded Home Assistant to the latest version, 2023.9.2, and also Z-wave JS UI to 1.15.11 (as I was also facing multiple Z-wave issues.
Am I correct in assuming that the issue reported above has now been fixed - at least for the Z-wave integration? I have started reverting my automation to the previous state, without a lot of bandaids and stuff as it was too cumbersome to trace or even read anything in the automations. But I thought I should ask to ensure the “coast is clear” so to speak before I do a lot of work and find out I need to revert… So far I have tested two automations and they seem to work fine, including with parallel mode, and… so far, so good, at least so it seems.
Would appreciate any feedback - TIA…
I am not sure that we are talking about the same reference as my Zwave JS UI shows 8.25.1, but my HA is also at 2023.9.2. The only band-aid I had when some automations became problematic was to restart HA evert night at 4 am.
I removed that restart a few days ago and everything seems to be running fine.
1 Like
I am afraid the issue reported here was not about Z-Wave at all. The person who reported it (i.e. moi) does not even use Z-Wave. I mostly use DeCONZ, Mosquitto as well as a REST API.
The problem seems to revolve around automations triggering themselves (to simulate a WHILE loop). Sadly, this fact does not seem to attract much attention.
1 Like
No the issue here has been discovered and we know what causes it. You need to identify where the automation is stalling. Once you figure that out, create an issue against the device that is holding up the automation. I.e, if a deconz device is stalling an automation, you’d write up an issue against deconz, not automations. This has been explained many times in this thread.