Well that’s both confusing and embarrassing!
Are you referring to double tapping the up or down switch?
Is your a dimmer or just a switch.
On my dimmer this is what i get:
Double tap top switch:
{
"event_type": "zwave_mqtt.scene_activated",
"data": {
"node_id": 6,
"scene_id": 1,
"scene_label": "Scene 1",
"scene_value_id": 4,
"scene_value_label": "Pressed 2 Times"
},
"origin": "LOCAL",
"time_fired": "2020-03-03T13:18:21.042925+00:00",
"context": {
"id": "565f0a66fa494afbba4cb728c91c3ada",
"parent_id": null,
"user_id": null
}
}
Double tap bottom switch:
{
"event_type": "zwave_mqtt.scene_activated",
"data": {
"node_id": 6,
"scene_id": 2,
"scene_label": "Scene 2",
"scene_value_id": 4,
"scene_value_label": "Pressed 2 Times"
},
"origin": "LOCAL",
"time_fired": "2020-03-03T13:18:44.951024+00:00",
"context": {
"id": "0648802737544444b75047d55559d787",
"parent_id": null,
"user_id": null
}
}
I get pretty much the same except that for “scene_label” I get “Bottom Button Scene” if I tap the top of the paddle and “Top Button Scene” if I tap the bottom of the paddle. This is on Homeseer switches and dimmers. Is your output for a Homeseer device or other? I ask because I think all the info is encoded in OpenZWave on a per device manufacturer/model basis and it looks like the database for your switch is different. It it is for a Homeseer unit then something else is going on and I don’t understand the architecture. In either case, I see reversed info.
Are you sure you are getting “Buttom Button Scene” for the Homeseer switches? Which models? I searched the entire source code and the only place that phrase appears is in an Inovelli config file (not sure why that is still defined, since OZW 1.6 properly implements central scene events based on the standard). Those overrides were only necessary for 1.4, unless there’s some issue with that switch. All of the config files which manually defined the central scenes (well almost all, apparently) have long ago been updated to remove the overrides.
Scene labels in 1.6 should all be “Scene 1”, “Scene 2”, up to the supported number of scenes. The scene data, aka key attributes are all hard coded according to the standard.
That was for my Homeseer dimmer.
I installed a new one today and I get the same output that my other switch gives.
Can I run the docker image on a different machine and still use this to do the bindings locally? I really like how this is more native and manages it. I just want to move my z-wave controller to a different location. Would it be better for me to just use the other project?
Running the controller on a remote server is one of the central features for this integration. The docker container of course must be running on the host that is connected to the USB stick. You can put this host wherever you want, as long as it can talk to the MQTT broker.
still use this to do the bindings locally
Not sure what you mean by this? The integration mentioned here is (will be) part of HA, it just listens to the related MQTT topics instead of interfacing with the C++ library locally. The experience will be the same as native zwave.
1 Like
Interesting. I definitely get those “Button” labels for the Homeseer devices on my installation. I installed the OZW stuff via a docker pull of openzwave/ozwdaemon:latest so not sure why I see out of date data. Not sure where to look to see what database I have after the install though.
The database is part of the container image.
What is the raw MQTT data showing?
Below I copied a section of what I assume is the initial dump from the daemon to HA when things start up. Node 19 is a Homeseer switch and as you can see the class 91 is returning what I guess is the old form of things. The pull of openzwave/ozwdaemon:latest was 3 days ago. I just started a new pull of it and it is replacing things so I can try again with the new image and see if I get up-to-date descriptions.
OpenZWave/1/node/19/instance/1/commandclass/91/value/562950277873684/ {
“Label”: “Top Button Scene”,
“Value”: {
“List”: [
{
“Value”: 0,
“Label”: “Inactive”
},
{
“Value”: 1,
“Label”: “Pressed 1 Time”
},
{
“Value”: 2,
“Label”: “Key Released”
},
{
“Value”: 3,
“Label”: “Key Held down”
},
{
“Value”: 4,
“Label”: “Pressed 2 Times”
},
{
“Value”: 5,
“Label”: “Pressed 3 Times”
},
{
“Value”: 6,
“Label”: “Pressed 4 Times”
},
{
“Value”: 7,
“Label”: “Pressed 5 Times”
}
],
“Selected”: “Inactive”,
“Selected_id”: 0
},
},
“Units”: “”,
“Min”: 0,
“Max”: 0,
“Type”: “List”,
“Instance”: 1,
“CommandClass”: “COMMAND_CLASS_CENTRAL_SCENE”,
“Index”: 2,
“Node”: 19,
“Genre”: “User”,
“Help”: “”,
“ValueIDKey”: 562950277873684,
“ReadOnly”: false,
“WriteOnly”: false,
“ValueSet”: false,
“ValuePolled”: false,
“ChangeVerified”: false,
“Event”: “valueAdded”,
“TimeStamp”: 1583259430
}
Well it’s certainly there. Can you post your ozwcache file to a pastebin?
Regardless, you (hopefully) shouldn’t need to care about the label. Does the scene ID that HA gives you match what you expect? I would personally use the scene id to avoid having to use strings.
Is that the file with a name like ozwcache_0xf11229f7.xml that is in the data directory supplied to the container?
Re what to use - that was one of my earlier questions. What do we think best practice will be for matching things like scene activations. The 2 items of interest are the label and the value_label for which I could match the string or match the code. If the code is going to be standardized across switches so that a double press always yields the same code value then that would certainly be preferable. But it looked to me like the code values might differ but map to the same string value in which case matching “Pressed 2 Times”, while awkward, would be preferable. I didn’t know which path the open zwave stuff was taking and I do know that under the old HA zwave implementation you had to know the particular weird values that each switch sent. So I was matching on the string with this new implementation. Sounds like best practice will be the values themselves?
Assuming the answer to my cache question was yes here is a link to it: https://pastebin.com/ACNqYhWX
ozwcache*.xml is the 1.6 version of zwcfg*.xml
You can of course use the strings at least for now, since HA is providing them. The key attributes in fact are standardized.
The OZW values are +1 because it also defines that “Idle” value (no event active) as 0.
I can’t confidentially be say the strings will or will not ever change. OZW has various levels of localization, maybe it will support scene labels some day. The current labels look inconsistent to me, some start with “Key” others don’t, maybe those will be “fixed”? The integers however shouldn’t change, so I would personally use those. Or, maybe HA will end up setting its own labels, currently it just passes the OZW labels as-is. Too early in the game to tell. 
You could probably post an issue in the project and ask for clarification or recommendations. I’m sure at some point it will be documented.
Thanks for all the insights. While a retired software guy of 40+ years I’m not yet a deep zwave guy. So I deleted the cache file and restarted the openzwave daemon and now I’m getting what you expected. It seems that somehow I got an old database that then polluted the cache so my initial re-pull didn’t do anything. Sorry to have taken you down this dead end but I do appreciate your help and I’ve certainly learned a few things of use along the way.
Well I’m not sure how, but your cache file has the labels set:
<Value type="list" genre="user" instance="1" index="1" label="Bottom Button Scene" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="0">
It’s almost like it got mixed up with the Innovelli settings. The source code is using “Scene %d”.
You could try stopping the OZW daemon, deleting the entire Node contents for that Homeseer, and restarting. It should be detected again.
Strange! Glad its working. Deleting the cache file is always a good troubleshooting step.
Another issue that maybe I’m missing something for. With the existing zwave integration there is a provision for setting a refresh of the switch state after a command. This can be important for dimmers since if they have a slow ramp set the immediate state update will likely still show them off and HA gets out of sync with the actual switch. With the new integration this capability seems to be missing (unless I am missing it). The generic homeassistant.refresh_state service also doesn’t seem to work. This makes a workaround in scripts pretty awkward. What I have found works is to issue the on to the dimmer, delay a bit, then issue the same on to it again. The first light.on in fact turns the light on but HA still sees it as off. Since it is off, the second actually tries again to turn it on and by then the light returns an on state and so HA is happy. While this works, it is certainly not a permanent solution.
Best practice for working with Labels - dont! In 1.6 many aspects affect the labels. It could be config driven, or how the value scene is exposed on a device. For Values - always try to use the Index. That will basically be “static”.
Same goes for Value_Label versus Value.
Labels are basically there to display in GUI’s. Using them in scripts/automation will probably end up one day causing a “why does this not work? Oh - someone contributed a new config file for this device. Doh!
That gives you maximum portability between devices/installations etc.
Switched over to this, still working through little kinks but overall a really nice setup, easy to reason about and I really appreciate being able to inspect the MQTT traffic.
Random small question: Where is log level taken from? I’ve added to my ozwdaemon container’s options.xml:
<Option name="logging" value="true" />
<Option name="SaveLogLevel" value="4" />
However, I’m still getting all the debug logs:
[20200310 16:28:44.715 UTC] [qt.mqtt.connection.verbose] [debug]: Received PUBLISH
I’ve also tried a few environment variables OZW_LOG_LEVEL but not making it stick.
options.xml is for the OZW library, but those logs are for the ozwdaemon. Looks like the logging settings are hardcoded for now. I’d recommend creating an issue since they should be configurable.
That said, according to the QT docs it looks like it might possible to override the rules using the QT_LOGGING_CONF or QT_LOGGING_RULES environment variables. I think you’d want something like QT_LOGGING_RULES="*.debug=false" or maybe an empty string, I haven’t tried it.
1 Like