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): Screenshot_20230812-171507 Screenshot_20230812-171546

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 20 (7 by maintainers)

Most upvoted comments

@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: true in 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.