I noticed after updating to OpenHAB 3 that my older GE zwave dimmers weren’t working quite as I expected (they didn’t seem to be updating the status that I send to HomeKit). I had time to take a closer look, and as it turns out, it looks like they literally don’t work at all with OH3.
The behaviour: if I turn on/off a switch (dimmer), it doesn’t update in OH. If I send a refresh command to them via the console, they still don’t update. I can see in the logs that they receive a NIF command when they’re toggled at the device, and I can see that it says it’s polling them.
@chris I’m curious if there were any changes in the binding that would cause this behaviour. I’d suspect it was one of the devices because frankly they have kind of ended up sucking (and I’m slowly replacing them), but it seems unlikely that all of them would just cease to function.
They do receive commands without issue (i.e. I can control them over zwave)
Throwing my TRACE levels logs in here in case that helps.
There were no changes in OH3 - or very few, but since I have no idea what you were using previously I can’t really say what changes there were between your version.
I may try and setup a 2.5 instance to do more testing, but it is really weird that they just stopped. IS there any way to get more info on what’s being sent to the controller?
That database entry has not been updated since OH 2.5.0. I notice no Association Groups in the database. That may not be unusual for some old Z-Wave devices. @chris would know better.
Perhaps the log viewer can help you interpret the DEBUG logs.
The device doesn’t seem to support associations. Many of these older devices didn’t support them so there was no direct reporting. The other way reporting was done was to use the HAIL class where a HAIL command gets sent to the binding, and then the binding has to poll - this got around patent issues at the time. It doesn’t see this device supports that though either - or it may be that the database is wrong - I don’t know.
Old indeed. When I got these OpenHAB was in beta for 2.0. They were well regarded at the time and actually worked really well, though durability has been a big issue.
Up until these issues, they’ve generally worked almost like they have instant status.
What really confounds me is why they don’t even update the status after sending the refresh command.
@Bruce_Osborne@chris I looked at the log viewer tonight, but it’s pretty sparse (including a screen shot). Is there any way to get deeper logging to figure out what may be going on with the binding? Unfortunately I don’t have a Zniffer or extra Zwave controller to create one so that’s not an option, and I’m purely running macOS so I can’t easy use the Silabs PC Controller software.
I tried with 5 different switches of that model and the behaviour/logs looks to be the same.
@chris@Bruce_Osborne to try and do some more debugging I quick installed Zwave JS. Figured it would be a good way to confirm that the devices aren’t the issue. They work flawlessly there.
So I suppose that means either there’s an issue with the device in the db or in the binding itself. Not really sure where to go from here though.
ZWave JS is a much newer project. These devices have been used by many users without major issue over the 5+ years of this binding. The issue is likely something unique to your environment, either configuration or device related. ZWave JS also uses a completely different database, Ours is community maintained based on actual devices used in the binding,
Are you defining your Thing in a file or automatically? File-based Things are very error-prone and discouraged. The binding has changed over the years so a file-based Thing may not work with the same definition in newer bindings.
EDIT: I just looked and ZWave JS device database just has the configuration parameters, not the Endpoint(s) from the device firmware. Perhaps posting your device xml file from userdata/zwave could provide a clue.
It’s database, not file based config. Nothing particularly interesting about the thing or item setup. And as I noted, they receive the commands without issue.
And again, I should note, these previously worked flawlessly. As Chris said, they send a command and then you poll them. But as of right now, even if I send a REFRESH command they aren’t updating.
Sorry - I’m not really sure. There’s very little here to understand what’s happening. The log doesn’t show any reports, so clearly if it’s not receiving anything, then the binding will not do anything.
@chris this is definitely the most frustrated I’ve been with OH in the many years I’ve used it. I setup an OH2 instance on the old Pi I used to run it on. Plugged in the USB stick, allowed all of noise on the Zwave network die down, added the thing/ & item for one of the GE dimmers, and it worked fine. Here’s the log:
So obviously something is different between OH2 and OH3. Considering I got it up and running on Zwave JS without any issues, I’m going to guess OH3 (as in the OH3 version of the binding) is the bad apple here. Unless the database is different between OH2 and OH3. But I’m assuming that’s not the case.
If there’s anything more I can do to debug I’m happy to do it…but I’m really hoping to avoid having to spin up a Java dev environment here and throw a bunch of debugging into the binding to get more info.
I was looking through the binding code, specifically the polling code. I noticed in my two sets of logs that the difference was that in OH2, it polled for that channel…in OH3, it just started the “Polling…” process and then did nothing. In the code I noticed that polling had a heavy requirement on the channel linking. I was staring at my OH3 channel item, and the link was there, but I paid some more attention to the “Profile” section, which is new in OH3 and I’ve never used before. Saw this:
and thought: “what’s the difference between (No Profile) and Default?” So I switched it to Default, and voila!
I’m guessing that’s because all of my links/items were created from a OH2 upgrade, and that doesn’t set it as Default. I imagine none of my Zwave items are polling properly because of this, but it’s only the GE ones that require polling to work.
@feens - Glad to see you managed to get this sorted! I wanted to chime in and say I have a bunch of (mix of ~30 different GE/Honeywell/Jasco models) in-wall Z-Wave devices and they all work perfectly fine using ‘No Profile’ on the latest stable OH 3.x branch. Their statuses when changed directly at the switch or otherwise via the App stay in sync as expected. This is on a clean install of OH3 - didn’t upgrade; rather just rebuilt from scratch.
I am still pecking away at this other issue below effecting only the Scene_Number channel for only one older device… And in my case switching the Profile didn’t help either - simply nothing gets captured or logged (in DEBUG mode) when attempting to change scenes. And this particular model does support Association Groups in case anyone here was wondering - this one is setup for the Associate Group #1 being the Controller:)