FYI, that’s been fixed since addon v4.0.0. User and config files are persisted now.
2 Likes
Gah, LOL I did my first attempt at upgrading to ozw I guess hours before 4.0 released. I went through some headaches renaming then found out the lack of persistence (cache file). So I went back to the zw integration and had to rename again. Now, I shall go through the process of upgrading to ozw a second time… hopefully it will let me use a snapshot I took with the 3.0 addon so I don’t have to rename the entities again.
Thank you all for your help and advice. Wake up followed by refresh worked like a dream. I will mark this advice as the solution.
Thank you also for pointing me at MQTT Explorer. I had seen mention of it but continued to use command line tools. It looks like a very useful tool.
And I will avoid the reboot, thanks again for the heads up.
Actually, it’s not fixed yet…
…no worries though, I assumed this was the case and had some spare time to have fun with experimenting today. So the time spent renaming (probably shouldn’t have done that yet lol) isn’t a huge deal. That said, until this issue is really fixed, lets be careful about recommending ozw-beta in certain cases (battery devices).
The entity names are preserved, but after reboot the state remains unknown. Unfortunately, opening/closing the doors/windows doesn’t refresh the state either. So the state is ignored (node effectively dead) until it decides to wake again. When it wakes could be 5hrs for some of those devices, and 2 of them will never wake up without a paperclip (pushing a wake button). Anyhow, I’ve posted about this a few times in a few places on these forums, and I’m pretty certain the devs are aware and adding a cache file soon. Until then, ozw-beta is broken for battery devices.
1 Like
I too suffered from this. I rebooted at one point in my trials to see if it helped and what I had disappeared.
Some of my devices appear only to wake every 24 hours! I think that is why they did not appear first time around, I was impatient. Anyway as long as I have a workaround for Beta software I am happy. I would not say that it is broken just that it requires a little loving care.
From my own point after just 24 hours I think I will keep this beta as I prefer it to the ‘production’ alternative. It will only get better.
Thanks to the developers for their hard work. I like the results.
1 Like
For Clarity - 2 “issues” here:
-
Lack of cache in the HACS addon - that was a implementation error by the HACS guys. It took longer than I would have like to get corrected, but at least on the official containers (ozwdaemon) it wasn’t a issue.
(also - please see my response about “is it ready” here- So when is OpenZWave (OZW) version 1.6 coming to Home Assistant? -
Wakeup - There is no difference here between OZW 1.4 and OZW 1.6. After restarting, you have to either manually wake up a device (and thats different from triggering say motion, or opening a door, its pressing a button or doing a action in some way defined by the vendor) for OZW to get it “operational”. One of the big benefits of the new integration - When you need to restart HA, you don’t need to restart ozwdaemon (as long as the MQTT broker stays up as well - which it should) - so everything should work straight away without having todo the wakeup dance on your devices (or waiting for the wakeup interval).
2 Likes
Well yes, patience is key here. I’m still playing and poking around with ozw beta on my system. I also would like to see ozw take over, since being on 1.4 when 1.6 is out just sounds wrong to me hehe. I will stick with it (avoiding reboots for now) and see if I can give back to the devs WRT a couple of devices I have that aren’t working yet.
Just for your own clarification: HACS is a custom solution section. Openzwave is going in the offical support. They typically are referred as hassio addons but I think now we’d call them supervisor addons.
@Fishwaldo, Thanks for the excellent response, and I’ll be checking the other thread often.
With the current zwave integration somehow the sleeping sensors are operational right after a host reboot. It does take a minute or 2 for the network to start, but once it does those sleepy sensors work right away (HA registers doors/windows opening and automations working, despite sensors not having ‘waken up’ yet). I’m not sure how that works, or if it even has to do with ozw 1.4 vs 1.6, but that ‘sensors work right away after a power outage’ is very important to folks using HA as an alarm system, or for other ‘critical automations’ like say aquarium controls etc.
Ok - Not being a HA user - It confusing for me 
- the ozwdaemon thats “packaged” with HA is a “addon?” I thought it was in HACS as well though? (I see references to installing it from HACS around the place!)
There is this: https://github.com/home-assistant/hassio-addons/tree/master/zwave
and I swore I saw something in HACS as well?
Yeah, it is confusing but you are correct. It’s a ‘add-on’.
HACS is an integration. So the 2 differences are:
addons are docker containers that run other software.
integrations link devices (and other software) to home assitant.
Pretty sure the early versions of the openzwave integration were in HACS. I could be wrong, I wasn’t using it then.
EDIT:
So currently, there is an openzwave integration and an openzwave addon.
So as long as you don’t reboot/restart the ozwdaemon container - Yes, those sensors will continue to work as normal.
Its when the ozwdaemon container is restarted that the battery devices will go into a “CacheLoad” status - Meaning we loaded the cache, but waiting for the sensor to wakeup.
Here is the conundrum - in order to “expose” those battery devices to HA (or MQTT) - I have to send the Values of the sensor (eg, lets say Temp sensor). Without the device waking up - What value do I send?
- The value in the cache? That might be days/weeks old (depends when the cache file was last written - Once your Network is running, thats not very often at all!).
- a value of 0, or false, or some other “default” value? If you have automations, say a heater tied to your thermostat - Sending a “default” value of 0 isn’t going to make you to happy, but potentially very hot if its the middle of summer!
In OZW, I err on the side of accuracy - So OZW doesn’t send anything (and hence a device will not be “ready”) till the device actually reports in the first time (via a wakeup - where OZW refreshes ALL the values on the device)
I know its not ideal - but unless these battery devices start rolling out with FLiRS support (and then suffer the short battery life as a result) then my advise is - Critical sensors should NOT be battery sensors. Now in reality I know that’s not very practical, but potentially the best solution as it stands today.
So the “integration” is ozwdaemon container? and the Addon is OpenZWave (beta)?
So I’m refering to the “container” thats packaged up and available to deploy in HA. Thats not maintained by me! (and its confusing -as the docs point to the qt-openzwave (aka ozwdaemon) github repo… go figure
I would like to have a “global” choice to what to be sent after restart of ozw (addon - container?). For me personally I would like to have that set to “last known/last updated”. That would for me not break any logic or automation since that value was already known in HA. Since I reboot a lot (don’t want but it’s the nature of hass and containers) I hate it to see stuff “0”, “0.0”, “unavailable” etc… that’s not what a zwave controller should look like compared to other commercially available products. I have never seen one of them reporting “0 celcius” after a reboot … ?
Thanks!
Nope reversed. OpenZwave (Beta) is the integration, where the addon is the ozwdaemon container (maintained by frenck n friends).
I’m trying to learn more about the container, mainly because i’m running into so many issues with my personal setup. Once I learn all the gotcha’s, I plan on creating a guide for other users so they don’t have to deal with what I have to deal with. Last piece of the puzzle is this group association thing.
Hopefully this will alleviate questions your way.
1 Like
WRT that container (addon) I would really like to see that more frequently updated following the openzwave 
Petro,
The container configuration is available at the ozwdaemon container git page. This has the Dockerfile, not too complex.
Basically it is the ozwdeamon running with a none HA supplied VNC server to access the ozwdaemon features.
The integration is very much the way HA talks to the ozwdaemon via MQTT. I would think that once everything is complete the basic user, like myself, will not need to know anything about how the add-on works just how the integration works. Unfortunately for the early adopter neither end of the chain is complete yet.
There are issues with the cache in the addon. There are then also feature omissions in the integration, like no way to easily send zwave commands, which the current zwave integration (based on OpenZWave 1.4, noted for Fishwaldo’s benefit) can provide. Even missing these features I am finding the stability is much better and the integration fits the modern HA facilities much better.
For me access control is based on doors being Open or Closed not on binary values, Automatons are simpler, Scripts more readable. Best of all I can now understand the zwave logs from the addon.
1 Like
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.