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?
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?
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.
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.
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:
Created binary sensor
Changed HomeKit config.yaml to auto_start: false (PERHAPS THIS IS MY ISSUE?)
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"
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 ?
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:
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.
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: