core: ZWave light service calls never timeout when entities go to Unavailable with turn_off service
The problem
If an automation or script issues a turn_off e.g. light turn_off, switch.turn_off and the target entity doesn’t go to off but goes to Unavailable then the script/automation hangs in a running state. A script can only be stopped by a script.turn_off or a change and automation can only be reset but a reload or updating the automation.
What version of Home Assistant Core has the issue?
2023.8.2
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Automations/Scripts
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
alias: "[Auto Driveway lights] Driveway Lights Auto"
description: ""
trigger:
- platform: state
entity_id: binary_sensor.front_door_motion_sensor_state
to: "on"
- platform: state
entity_id: binary_sensor.front_door_sensor
to: "on"
from: "off"
- platform: state
entity_id: switch.driveway_lights_switch
to: "on"
- platform: state
entity_id: binary_sensor.driveway_motion_sensor_state
to: "on"
from: "off"
condition: []
action:
- choose:
- conditions:
- condition: sun
after: sunset
after_offset: "+00:15:00"
- condition: time
before: "23:00"
sequence:
- service: switch.turn_on
data: {}
entity_id: switch.driveway_lights_switch
- conditions:
- condition: or
conditions:
- condition: time
after: "23:00"
- condition: sun
before: sunrise
sequence:
- type: turn_on
device_id: ceec3e04c9a70826d58041326465331b
entity_id: switch.outside_wall_lights_switch
domain: switch
- delay: >-
00:{{ states('input_number.driveway_lights_on_minutes') | int
}}:00
- type: turn_off
device_id: ceec3e04c9a70826d58041326465331b
entity_id: switch.outside_wall_lights_switch
domain: switch
default: []
- delay: 00:{{ states('input_number.driveway_lights_on_minutes') | int }}:00
- service: switch.turn_off
data: {}
entity_id: switch.driveway_lights_switch
- if:
- condition: sun
after: sunrise
- condition: sun
before: sunset
before_offset: "-5:00"
then:
- type: turn_off
device_id: ceec3e04c9a70826d58041326465331b
entity_id: switch.outside_wall_lights_switch
domain: switch
mode: restart
Anything in the logs that might be useful for us?
Going to traces for the automation/script for the failed run shows it still running and for the subsequent runs show them not starting because the script is already running.
If the entity goes to Unavailable then th script/automation.
Additional information
I don’t have any hard evidence of this but I believe this was working pre 2023.5/6 the zwave light that goes to Unavailable has done this for a while and I have other lights which are WiFi on switches which get accidentally turned off and I haven’t had an issue with a Good Night script or the driveway lights automation above freezing up until around 2023.7
See some screenshots of the case when a script is stuck and the next case can’t run(this is for my good night script):
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 20 (7 by maintainers)
@raman325 i know you were asking for cases related to z-wave so thought I would flag to you. i asked for some detail about, but feel free to correct me if that isn’t the right set of detail.
I have been able to test on 11.14.0, it seems that the handled error because the node goes to Unavailable is working and the Automation/Script does not get stuck in a running state. The Script is stopped due to the ZwaveJS returning the error as expected.
Using
continue_on_error: truein the YAML allows the Script to continue even if the zwave node does return an error.Thanks for your help with this.
Thank you for the excellent issue report. I think this is a duplicate of #98073 so we can track there, and we may have a root cause identified.