It sure looks to me like the device is sending reasonable info back to openhab. Single presses and double presses each generate a line in the log like this:
2020-10-10 10:07:14.245 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=2.3
with different values for the scene depending on what I do: 1.0 for single On, 1.3 for double On, 2.0 for single Off and 2.3 for double Off.
Interestingly, I also have a Nanomote Quad, and when openhab gets a button press from it, I see these two lines in the log:
2020-10-10 10:02:42.825 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=4.0
2020-10-10 10:02:42.825 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:4a5c3110:node15:scene_number to 4.0 [DecimalType]
The new switch doesn’t generate that second message about updating channel state.
I’ve tried removing and re-adding the link to the scene channel, but that didn’t help. Restarting openhab didn’t help either. Since good data is coming to openhab, I feel this should be fixable (and it’ll probably turn out to be something really simple, too). What are the next steps in debugging this? In case it helps, here’s the node.xml: node16.xml (10.0 KB)
Normally we support the central scene command class, but this device has been configured with the scene activation command class. As I mentioned earlier, there is normally a config command to change this.
I’m loath to change the database as we’ll likely break other peoples configuration - unless we’re really sure that the database is wrong.
Unfortunately I’m still a bit new to the zwave and openhab world. What does it mean for the device definition to use one class vs another when I’m trying to write a rule? So far I’ve just been defining things in the ui, and haven’t (had to) resort to hand-crafting definitions in .item and .thing files. Is that where I need to go? How do I find out how to trigger a rule on a scene activation event?
Or, you’ve said that the device itself is configured to use that other class, and that there’s probably some command I can issue to it to use a different class. How do I do that? The only thing I see that’s configurable in habmin is the led.
For the rule, it means nothing, but you don’t have an issue with the rule, you have an issue in that the data from the device is not being sent to the channel.
No - it’s not related to this - according to the database, the device supports two different scene command classes. The binding normally uses the CENTRAL_SCENE class as it provides the best information, rather than the older SCENE_ACTIVATION class. Your device though is using the SCENE_ACTIVATION class.
Normally there is a configuration option to change this - I’ve not had the chance to check for this device.
I should have added (sorry - writing this on my phone) that there is always the possibility that this has never worked, and we should simply change this over to the CENTRAL_SCENE class. I normally prefer not to do this on the assumption that this worked for someone at some stage, and changing it might be it for any number of “someones”.
Thanks, @chris. I feel like I’m heading down a rabbit hole here, but I grabbed the zwave binding source, changed the command class in the XML for my switch to COMMAND_CLASS_CENTRAL_SCENE, and rebuilt. I found instructions for replacing the binding, but I can’t tell if I will lose my configurations when I do that. I also have no idea if that’s actually even remotely close to being the right way to try your suggestion. How would I know if the rest of the plumbing is going to work? It does sound like the zwave people try to make things compatible, so I would assume that if a device claims to support a particular command class, then generic code in the zwave binding would be able to use that command class, but I’m still new here, so I’m not sure.
Also, I’m happy to be a guinea pig on this. If there are other experiments I should try, to confirm whether the SCENE_ACTIVATION class is really the more appropriate one to use (even though it’s not working currently), let me know.
It’s not really a case of if it is more appropriate. As I said earlier, it is the one we normally use. The point I was trying to make is that I don’t like to change things when a device has been in circulation for a long time - it risks solving the issue for you, and breaking it for others who may be using the device.
The question is really if others are using the device, and if there is a way to change the configuration to use the other command class. One assumes this must be possible since the device does support this.
Just because the parameter is not in the database, doesn’t mean it doesn’t exist. Unfortunately some manufacturers don’t publish information about the parameters. I think when I looked the other day, the documentation didn’t have any parameters at all - even the LED one.
If there’s no way.to activate the CC, then it just seems surprising that it is included in the device.
So what are my choices at this point? If it’s hard to change the database safely, how can I figure out where the problem is with SCENE_ACTIVATION for me?
Also, out of curiosity, how authoritative is products.z-wavealliance.org? That shows that this switch has two parameters: 19, for something called “alternate exclusion”, and 3 for the LED, but nothing about switching command class usage. It does, however, say that Central Scene V3 is supported.
Well, we could just change the database, and see if anyone complains - maybe no-one is using the older command class, and if the device is only sending the CENTRAL_SCENE, then maybe this is fine. It’s not super nice, but as there’s no way to know if anyone uses this channel, I simply don’t know if it will cause problems.
It’s generally pretty poor - especially for older devices. For very new devices, it’s probably ok as ZWA now require manufacturers to provide the database information, but this is a relatively new requirement.
I went ahead and tried rebuilding the binding with the updated configuration file (46201_0_0.xml). That didn’t seem to help, I still get very similar looking logs. I see the message about receiving a COMMAND_CLASS_CENTRAL_SCENE message, but nothing about updating the channel. I confirmed the new binding was loaded, and I cleared the cache and tmp folders before restarting openhab. Is there another file that needs to be updated or cleaned to recognize the change? Do I have to re-add the device?
Also, I found another switch that appears to be identical except for the physical switch part (the older style toggle instead of a big paddle), with part number 46202 (mine is 46201). In the database, that other switch is configured to use CENTRAL_SCENE. So, I have a strong hunch that it’s just a problem with the database, but I’d love to be able to confirm that locally so nobody has to change the database just on my hunch.
@Bruce_Osborne Well, it’s really just a guess - the descriptions are very similar, and the model numbers differ by only a digit. I couldn’t figure out how to find what the latest firmware is for the other switch (mine I can read in openhab). Do you know where to find that? I couldn’t see anything on the Jasco site, not even how to update the firmware, although I understand that has to be done via the hub.
In other news, removing and re-adding my switch WORKED! I am now able to write a rule that catches the double-tap gestures on the switch. So, if nothing else, I now have a way to do what I want. It looks like there are a bunch of differences in the xml file, so I conclude that the database is only read once, when the device is added.
Anyway, thanks everyone for all your help. I have no idea how to tell if other people out there would be affected by a change to the database, but I can now say that changing the entry fixed things for me. Should I submit a pull request to the code, or make an update on opensmarthouse.org itself, or both, or let someone else do it?
When the Thing needs to change “shape” because the binding has updated e.g. changing channels under the influence of the database in this case - yes, you need to bin an old shaped Thing and make a new one.