Yes, I’m currently using the addon over the container because that will be my personal end game. So I’m working through all the lumps with the addon as we speak. So far, only issue’s I’ve ran into are essentially due to my lack of understanding of zwave and not fully knowing what commands to use and when to send them. Either way, if others plan to migrate, they will have a tough time. This is why I want to document all the pitfalls I ran into. I’ve been here for ~4 years at this point and I know others have the same hardware setup that I have. I won’t be the only one with these issues.
1 Like
The add on doesn’t support a remote or configurable MQTT broker does it ?
As I understand it the add-on is supposed to use the MQTT broker that is configured by the MQTT integration (I do this in my configuration.yaml).
I have not tried it with my setup. In fact I took the opportunity to reconfigure it to use the MQTT add-on rather than the external one I had on a cloud server. What it did do was pickup the correct TLS setup and port. The only untried part would be specifying an external host name, although my setup does appear from the route taken to be going to the correct dns name, I use a name not an ip address.
I agree WRT accuracy, I also don’t like the idea of inferring a state after a reboot. For example I have code to handle esphome devices after reboot, which also say “unknown” until the state is determinant.
That’s not what I was talking about though…
Using the normal zwave integration, after host reboot many of my battery devices will show ‘Initializing’, and after a while some also say ‘cached load’. While in either of these states, the entities will still update when I open and close said openings (of course, state is determinant when this happens, and these changes after bootup should be accepted as accurate).
For example, a sleeping ecolink says “Initializing”, I open the door, HA recognizes that and the automation fires. Close the door, HA recognizes that too, and automation fires. After all that, the device still says “Initializing”… eventually after it wakes it will say “sleeping” and of course it works then as well. So essentially, if power is cycled, it only takes a few minutes for my zwave network to startup, then ALL automations work properly… battery device or not.
Unfortunately it seems the OZW-beta integration and ozw ‘addon’ does not work this way. No automations will fire when doors/windows are changed until AFTER the node actually wakes. Another way to put it, if my battery devices are “Initializing” “Cached load” etc… they don’t work even if I open/close a window many times. They only work in HA after they are “sleeping” (which of course only happens after waking). All the other non-sleeping nodes work fine right after network startup (lights and switches), and of course if I really need an automation to work NOW, I can manually wake the sensor in question. However, that’s obviously something that has to be fixed before OZW-beta is ready for certain applications, including alarm use.
In this regard, the existing zw integration better suited to battery powered devices, compared to the current state of ozw-beta. I sure do hope all these things get worked out soon, ozw-beta can be ozw-release, and I can finally ditch the antiquated 1.4 based system.
I think your problem is the loss of the ozwcache file. You would have the same issues you’re describing in 1.4 if you lost the cache file there as well. If the cache file exists, there is no problem restarting ozwdaemon, even if the nodes have not woken up. In fact I have a few devices that never wake up, such as a door sensor, and they work fine right after a restart, even in the “CacheLoad” state.
Are you 100% sure you’re on the latest addon version (0.4.3)? If you are, then you might consider submitting an issue. The devs claim the persistent cache file is fixed, and others are reporting success.
Yes, my webui said “0.4.3”, and the \core_zwave\addon.json from my snapshot has "version": "0.4.3". Also, the data persistence issue is not my problem; my snapshot also has /data/ozw/config/ozwccacheXXXXXXX.xml, which indicates the proper file location. This file also has what appears to be all valid contents (overall looks OK, without going over it hair by hair).
TBH, where the problem lies, whether in the addon, the integration, or both, is above my head. All I know is the existing integration works well, and I’m happy to share logs etc from my ozw-b experiences.
Hmm… Does this work the same in 1.4? Could this be the cause of one of my battery motion sensors reporting a Burglar=8 twice every time I restart HA? (MQTT is not being used) It’s only that one sensor that does it.
wait, I thought the add-on WAS the container? Are you talking about differences between the ‘easy’ HA installation on Pi and the HASSIO manually using Docker?
I’m curious what you’re running (I’m new) 
Just so I’m clear, that’s not possible on the normal Home Assistant install, is it, since we can’t really install any SW on the HASSOS?
The Add-on is a container…but not the same container as the official container.
The add-on container isn’t maintained by fishwaldo but by someone else using the official container as the base.
The point was that the add-on isn’t necessarily always going to be up-to-date with the official container.
OK, I guess I’m confused. What you said makes sense to me with my understanding of the current HA OZW 1.4 implementation, which is why it is out of date. But I thought the point of the new OZW beta was to create an environment where the Python wrapper on the OZW fork was replaced with a normal integration to the Add-on, which is the official OZW and MQTT. As the official OZW is updated, then the OZW Add-on would be by default (when updated), without having to update the integration.
@GrizzlyAK. Think of it this way. The HA developers take the container published by fishwaldo and then they use that as the basis for the add-on store version. They do a few things in this step like setting it up to store the data files where add-ons are supposed to store data files, etc.
This is great in that you get a one-click newbie-friendly install, but you don’t have as much control. For example, you can set environmental variables to control the logging levels and other aspects of how OZW behaves if you run the container directly. You can also easily edit device config files, set options.xml etc.
Also since it takes work to take the fishwaldo releases and turn them into the add-on and right now fishwaldo is releasing updates almost daily, it makes sense that the add-on will not be update nearly as often. So for the early-adopters who want to help test, get in and tinker, etc. the direct-from-fishwaldo container is the way to go
That clears it up. Thanks!
I’m running into the same thing as the OP and I’m new to how MQTT works. I’m trying to find what I need on the forums but coming up short. Is there something someone could point me at on how to use MQTT to send the two commands to my devices? I have it connected to the broker, just can’t see how to send those two commands to the nodes under the OpenZwave tree.
Hi. I moved to OZW Beta today and everything is working well. Thanks to this topic.
The only question I have is around support for Group Associations. It is functionality that I use. Is this being implemented or is there a service that can be called?
Hi, I migrated to the open zwave beta but I can’t get all the things working. I am using homeassistant supervised. I already using the Mqtt integration and mosquito broker as a separate container (not the add-on) The OZW add-on runs fine. (Changing the parameter works much better 
)
I installed the OZW integration but then there is silence:(. The nodes are not recognized as devices. I am using an aeotec stick, aeotec range extender and some battery powered pirs.
How can I get things to work?
Your devices will only come through once topic OpenZWave/1/status/ returns driverAllNodesQueried or driverAllNodesQueried
What stage are your devices in? Query, Probe, etc? (check the status in the OZW Admin tool)
The stage of the extender and the stick is completed. The Pirs are in cacheload stage.
That doesn’t work. The OZW Addon requires the Mosquitto addon. You cannot use an external broker.
1 Like
Thanks this fixed it!