Help needed with test of OpenZWave Beta 1.6

Configuration Z-Wave
1

Hi

I am not having too much success with the new OpenZWave integration and was hoping somebody could help. I run my system using hassio (currently v111.2) on a raspberry pi 4.

What I did:

1. Delete z-wave integration
2. Install OpenZWave add-on
3. Configure Add on
4. Start Add on
5. Install OpenZWave integration
6. Go to OpenZWave panel

I find I have seven devices but their characteristics are not complete. I have NOT repaired the devices with OpenZWave. The detected devices are:

1. My controller (ZME_UZB1 USB Stick)
2. D-Link Siren
3. D-Link Door/Window Sensor
4. D-Link Door/Window Sensor
5. D-Link Door/Window Sensor
6. Fibaro Door Sensor

I have repeated this sequence several times, returning to the original zwave configuration very easily. The result is the same. I have not reset the zwave controller. I have not attempted to pair any devices under the OpenZWave configuration as of yet, expecting that it can pick-up devices that are already paired. I have used the same Network key for the both zwave configurations.

I have left the new integration running for several hours in the hope that my whole zwave network may eventually just appear.

No device is detected as zwave plus, which I believe they all are. No big deal but a point that detection may not be perfect. They should all be set up as secure devices, they are not actually used as such yet.

All the device configuration xml files are in the /data/ozw/config directories.

There is a switch on the Siren. This is available. This is called switch.unknown_type_0000_id_0000_switch, which is obviously wrong. This works, setting off the siren. There are a couple of other siren entities that have become available in subsequent tests.

None of the door sensors are detected as having entities associated with them. This is a problem as I use the access control entities to power different automations. I also monitor the temperatures, the luminance values and battery levels. These devices also provide feeds to notifications of problems.

In the logs I do see:

[20200614 12:42:47.231 BST] [ozw.library] [debug]: Detail - Node: 3   Received: 0x01, 0x12, 0x00, 0x04, 0x00, 0x03, 0x0a, 0x8f, 0x01, 0x01, 0x06, 0x31, 0x05, 0x01, 0x0a, 0x00, 0x48, 0xc7, 0x00, 0xd9
[20200614 12:42:47.232 BST] [ozw.library] [info]: Info - Node: 3 ApplicationCommandHandler - Unhandled Command Class 0x8f

In my experiments I see that all the door sensors have given similar unhandled command class messages. These appear to be cause by events on the device, like the door opening.

What should my next action be?

Paul

2

I just went through this yesterday. Get MQTT Explorer. Wake the devices that aren’t working. When they are awake send refreshnodeinfo command in MQTT explorer. If that doesn’t work, exclude and reinclude.

1 Like
3

…and don’t reboot the host or you will have to do it all over again.

4

FYI, that’s been fixed since addon v4.0.0. User and config files are persisted now.

2 Likes
5

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.

6

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.

7

Actually, it’s not fixed yet…

Untitled
Untitled1129×777 120 KB

…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
8

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
9

For Clarity - 2 “issues” here:

  1. 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?

  2. 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
10

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.

11

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.

12

@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.

13

Ok - Not being a HA user - It confusing for me :slight_smile: - 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?

14

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.

15

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?

  1. 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!).
  2. 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.

16

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 :slight_smile:

17

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!

18

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
19

WRT that container (addon) I would really like to see that more frequently updated following the openzwave :smiling_face_with_three_hearts:

20

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