Z-wave JS update triggers smoke/CO alerts

Configuration Z-Wave
1

I have two of the ZCOMBO First Alert smoke/CO detectors. When I update Z-wave JS, they both generate alerts when the update is complete.

Is there any way to prevent this behavior?

2

You would need to post the YAML for your automation. First guess is you aren’t properly handling the entities’ unavailable state which occurs during the upgrade.

3

Thanks-I have no idea how to handle that.

All were built by duplicating the first:

alias: Inside smoke
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.inside_smoke_co_alarm_smoke_detected
conditions: []
actions:
  - action: persistent_notification.create
    metadata: {}
    data:
      message: Inside smoke!!!
  - action: notify.mobile_app_XXXX
    metadata: {}
    data:
      message: Inside smoke!
  - action: notify.mobile_app_XXXX
    metadata: {}
    data:
      message: Inside smoke!
mode: single
4

Now that you have armed me with the key term “unavailable,” I was able to do some more informed searching.

Is this excerpt the way to go?

triggers:
  - trigger: state
    entity_id:
      - binary_sensor.inside_smoke_co_alarm_smoke_detected
    not_from:
      - unknown
      - unavailable
      - none
conditions: []
actions:
  1. Is my indenting correct?
  2. Do I need “none” in this case?
5

Is the state of “binary_sensor.inside_smoke_co_alarm_smoke_detected” equal to “on” when smoke or co is detected? If so, it seems like you would want a to: option instead of a from: option. for example:

triggers:
  - trigger: state
    entity_id:
      - binary_sensor.inside_smoke_co_alarm_smoke_detected
    to: "on"
conditions: []
actions:

I am assuming you only care if the state changes to “on” and you probably don’t care if the state it changed from was either “off”, “unknown”, or “unavailable”.

Your original automation in the first post would trigger for any change to the state. I’m guessing when zwave js was updated, the automation was triggering when the state went from “off” to “unavailable”.

1 Like
6

That looks OK to me. I’ve never seen unknown or none for Z-Wave sensors, but those won’t hurt.

1 Like
7

That’s precisely the problem. When you upgrade Z-Wave JS the connection from HA is lost and all sensors go to “unavailable”.

8

It’s a smoke detector

Maybe it’s best to turn off automation before upgrade vs create a possible scenario where alarm doesn’t go off.

9

Or just don’t upgrade when you aren’t home.

10

His automation is not preventing the alarm from going off. The alarm is on the smoke detector itself. The alarm is not controlled by Home Assistant or anything else on the zwave network.

2 Likes
11

Thanks, all. I’ll try both suggestions and also see if the entity’s state shows as “off” when all is well.

12

Yes, but with complexity. I’m finally getting it now. Clearly, my trigger should be a change from one state to another instead of any change in state (what I did).

But it all seems unnecessarily unintuitive. In the UI, the sensible choices are From: Clear (confirmed in the log, changed during the update) and To: Detected, but in YAML those turn into:

trigger: state
entity_id:
  - binary_sensor.inside_smoke_co_alarm_smoke_detected
from: "off"
to: "on"
for:
  hours: 0
  minutes: 0
  seconds: 2
13

Basically, if you want to be certain you are notified of the alarm, use only the to: "on" trigger. You may get duplicate events, but if it’s important enough that’s OK. Some notification services might even suppress duplicates for you. An example edge case where this would apply would be:

  1. entity state is off
  2. Z-Wave integration crashes or restarts, e.g. network connection lost with Z-Wave JS
  3. entity goes unavailable
  4. the smoke alarm sends an alert
  5. HA re-connects to Z-Wave JS
  6. entity goes from unavailable to on

Z-Wave JS entities go unavailable when:

  1. HA loses connection to Z-Wave JS
    a. due to an upgrade
    b. due to a crash / restart in Z-Wave JS
    c. due to a crash / restart of the Z-Wave integration
  2. Device goes from Alive to Dead

So consider how you want your automations to react to those scenarios.

1 Like
14

The UI shows you the “translated” states based on the device class. The actual binary sensor state is always “on” or “off”.

1 Like
15

That makes it somewhat less nonsensical, thanks.

16

So just delete the


from: "off"

line?

17

I typically use the version posted above.

In some cases I’ve done both.

entity_id:
  - binary_sensor.left_garage_door_is_open
to:
  - "on"
  - "off"
not_from: unavailable
trigger: state
1 Like
18

This will guard against the issue you’re describing, but will still trigger if your sensor goes from on to off, which will be annoying. You don’t need none because that’s not a recognised state in HA (unless your sensor is doing weird stuff).

Try this - it should only trigger when the sensor goes on, but only if the previous state was not unavailable or unknown:

triggers:
  - trigger: state
    entity_id:
      - binary_sensor.inside_smoke_co_alarm_smoke_detected
    to: "on"
    not_from:
      - unknown
      - unavailable
1 Like
19

It seems this is the way to go, as I saw both “unknown” and “unavailable” in the entity’s log during the update.

Thanks, everyone, I learned a lot.

1 Like