OpenZWave - event type?

Hello,

I have this automation that I’ve been running and ever since I moved to OpenZWave (beta), it is not triggering.

I believe it is because I have the wrong event type. What is the correct event type to determine whether z-wave network is ready, complete, etc. when using the OpenZWave (beta) integration?

Thank you

- alias: 'Start HomeKit'
  trigger:
    - platform: event
      event_type: zwave.network_ready
    - platform: event
      event_type: zwave.network_complete
    - platform: event
      event_type: zwave.network_complete_some_dead
  action:
    - service: homekit.start

There is no equivalent for these events in the ozw integration. I use a binary sensor to indicate the zwave status.

binary_sensor:
  - platform: mqtt
    name: ozwd_available
    state_topic: OpenZWave/1/status/
    value_template: >
      {{ "ON" if value_json.Status in ["driverAwakeNodesQueried", "driverAllNodesQueriedSomeDead", "driverAllNodesQueried"] else "OFF" }}
    json_attributes_topic: OpenZWave/1/status/
    device_class: "connectivity"

If you search the forums you might find similar examples.

If you use such an automation, be aware that it’s much more likely for the zwave network to go offline while HA is still running than with the old integration. Would it be a problem if you try to start homekit multiple times, or does it just ignore it?

1 Like

That doesn’t give me a warm-fuzzy feeling about the new integration…

Perhaps my phrasing was not clear.

In the old integration, the z-wave network is in-process. It never shuts down unless you manually turn it off in the control panel, or shut down HA.

In the new integration, the z-wave network is managed by a completely separate process, connected via MQTT (network). That means your MQTT broker going down, a restart of the ozwdaemon container, etc. will appear as the network going offline. Just like anything else that is network-connected. This happens because HA is still online.

Thus, in the old integration, in nearly all cases you will only see those zwave network events when starting up. In the new integration, there are simply more reasons for the network to appear offline. I didn’t mean to insinuate that the new integration is less stable (although at this point it is). That’s just the reality of moving the network from in-process to out of process.

1 Like

Thank you @freshcoast! Your example worked perfectly :smiley:

Here’s a complete solution using your example… for anyone using HomeKit integration with OpenZWave and wanting to do the same…

Create binary sensor…

- platform: mqtt
  name: ozw_network_ready
  state_topic: OpenZWave/1/status/
  value_template: >
    {{ "ON" if value_json.Status in ["driverAwakeNodesQueried", "driverAllNodesQueriedSomeDead", "driverAllNodesQueried"] else "OFF" }}
  json_attributes_topic: OpenZWave/1/status/
  device_class: "connectivity"

and then create the Automation

- alias: 'Start HomeKit'
  trigger:
    - platform: state
      entity_id: binary_sensor.ozw_network_ready
      to: 'on'
  action:
    - service: homekit.start

I’d argue, at least in my personal experience, that the ozwdaemon container is quite stable. I only encounter a segfault when refreshing a specific node. Other than that, I’ve had the container running non-stop of weeks on end now. :slight_smile:

2 Likes

Hmm. I followed this exactly and something is not working for me.
I can see the state of binary_sensor in States as “on”
When I restart HA, one of the 1st or 2nd entries in Logbook after “Home Assistant Started” is “openzwave_network_ready is connected”. But the automation doesn’t fire and HomeKit never starts. For reference, here are the exact steps I took:

  1. Created binary sensor
  2. Changed HomeKit config.yaml to auto_start: false (PERHAPS THIS IS MY ISSUE?)
  3. Created Automation to delay startup

Re. 2) above - I assumed I needed to do this because the intention is that HK doesn’t start before OZW is ready. But perhaps this is my issue… Because OZW and MQTT are running in containers and already “on” - the intention of this automation is to call HK service if OZW went offline and then back on? Not really for a reboot of HA?

Here is my automation (done via UI):

- id: '1600433256064'
  alias: Delayed Start - HomeKit
  description: Checks binary ozw sensor before starting HomeKit
  trigger:
  - entity_id: binary_sensor.openzwave_network_ready
    platform: state
    to: 'on'
  condition: []
  action:
  - data: {}
    service: homekit.start
  mode: single

Here is my binary_sensor:

#Binary Sensor to determine if OZW Beta is running (for HomeKit delayed startup)
binary_sensor:
  - platform: mqtt
    name: openzwave_network_ready
    state_topic: OpenZWave/1/status/
    value_template: >
      {{ "ON" if value_json.Status in ["driverAwakeNodesQueried", "driverAllNodesQueriedSomeDead", "driverAllNodesQueried"] else "OFF" }}
    json_attributes_topic: OpenZWave/1/status/
    device_class: "connectivity"
1 Like

The beauty is that we won’t have to wait 5 or 10 minutes (if you have 100 ZWave devices) for the ZWave network to initialize after each HA restart, right ? :slight_smile:

Hey, had the same issue, Homekit bridge wasn’t starting for me either. So I switched up the automation slightly - this is working for me this, it has a wait template in it and I get a notification if it doesn’t start:

# Start Homekit
- alias: 'Start HomeKit'
  trigger:
  - event: start
    platform: homeassistant
  action:
  - wait_template: "{{ is_state('binary_sensor.ozw_network_ready', 'on') }}"
    timeout: 00:10:00
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ not wait.completed }}"
        sequence:
          - service: script.notify_tom
            data_template:
              title: "Homekit Error"
              message: >
                "The Homekit bridge has not started."
          - service: script.persistent_notify
            data_template:
              title: "Homekit Error"
              message: >
                "The Homekit bridge has not started."
              notification_id: homekit_bridge_error
    default:
      - service: homekit.start

If you want to simplify it, and you don’t want the notification:

# Start Homekit
- alias: 'Start HomeKit'
  trigger:
  - event: start
    platform: homeassistant
  action:
  - wait_template: "{{ is_state('binary_sensor.ozw_network_ready', 'on') }}"
    timeout: 00:10:00
  - service: homekit.start
1 Like

Thanks for this. Since I posted, I seemed to have resolved my original problems by simply removing the auto_start: false from my config.yaml. I’m finding that my OZW container is super stable, and reboots of HA don’t affect it at all. My automation has only fired once in the last couple months, which was when I updated Ubuntu and required a reboot of the overall server. I think the auto_start: false is much less relevant with OZW unless for some reason your container isn’t stable or you are taking it down often.

That said, your automation makes much more sense and seems entirely foolproof.

1 Like

No worries, and I’m glad that you managed to resolve this :+1:

I loved this wait template. I tried to reproduce it with the new zwave js integration. I got rid of the sensor as I didn’t know how to adapt it to the new zwave integration. Instead of waiting for the template I tried waiting for an event. The code below does not work, as in it passes after 15 minutes:

    - wait_for_trigger:
      - platform: event
        event_type: zwave.network_ready
      timeout: 00:15:00
    - choose:
        - conditions:
            - condition: template
              value_template: "{{ not wait.completed }}"
          sequence:
            - service: notify.pushover_config
              data:
                title: "Home Assistant"
                message: "Homekit bridge has not started."
                data:
                  sound: intermission
      default:
        - service: homekit.start
        - service: notify.pushover_config
          data:
            title: "Home Assistant"
            message: "Home Assistant, Z-Wave and Homekit are fully loaded."
            data:
              sound: intermission

@Jasper8472 I’ve started a new thread here: Zwave-JS delay Homekit start automation

Hopefully someone will have some ideas - I’ve run into the same problem.