Hi @chris - I’m working on doing a fresh OH setup on new hardware and using that opportunity to use the new Zwave binding version and re-add my devices. I’m having an issue with one particular switch, one that works fine in my previous setup but seems to have been configured incorrectly on the new version.
It’s a GE switch…I have a whole bunch of them in my setup and they all seem to work fine. I noticed this one wasn’t responding/updating when I tried to control it via UI. If I manually use the switch, OH is getting the updates. When I look at the attributes I notice some key differences with my previous and current setup:
Manufacturer 0063 Jasco Products
Type / ID 4944:3031
Firmware Version3.37
Basic Class ROUTING_SLAVE
Generic Class MULTILEVEL_SWITCH
Specific Class POWER_SWITCH_MULTILEVEL
Using Security ?
Routing ✔︎
Listening ✔︎
Frequently Listening x
Beaming ✔︎
vs
Manufacturer 0063 Jasco Products
Type / ID 4944:3031
Firmware Version3.37
Basic Class BASIC_TYPE_CONTROLLER
Generic Class GENERIC_TYPE_NOT_USED
Specific Class SPECIFIC_TYPE_NOT_USED
Using Security x
Routing x
Listening x
Frequently Listening x
Beaming ✔︎
I’ve tried removing and re-adding the Thing but that didn’t help. The logs don’t seem to indicate any issues either. Any other thoughts?
Oh, and I should note, I’m using the same zwave controller (stick), just switching it from one pi to another to get things setup.
I can’t see how this can be related to the binding - it’s not possible to configure these parameters at all. They are read from the controller only. If the logs show that these values are being received like this (which seems likely) then probably the device is simply broken.
That doesn’t make sense though. When I return the Zwave stick back to my other Pi, running OH 2.3, everything works perfectly fine as it did before.
From what I understand given those parameters, it looks like on the new setup (new OH w/revamped zwave binding) the device isn’t listening to updates. Given that it works fine (aka I can send it updates w/o issue) when I switch it back, it seems that the hardware itself must be fine.
@chris Just trying to nail down the core issue. I.e. On the new version of the binding, the device doesn’t receive commands. On the old version, it does.
I obviously don’t know the ins and outs of the binding, but I’m speculating that if it shows in the attributes that it’s not listening that the binding doesn’t send the commands to the device (given that the device aka hardware does seem to receive commands/updates without issue)
@chris comparing the XML files for the node now. Where does that info get pulled from? Is there any way to forcibly update it, or perhaps override what’s returned?
As I said, if the controller is reporting this (as you should see in the logs?), then it is a problem with the device. Otherwise just try initialising again.
@chris is there a way to re-initialize a device on the older version (2.3) of the binding? I tried on my WIP setup (2.4) and that didn’t seem to solve anything. Switched the zwave stick back to my 2.3 setup and it’s working fine, as expected, but I was hoping to see what would happen if I re-initialized it.
I still can’t wrap my head around why that specific device won’t in work in 2.4. I would expect if it’s “broken” it shouldn’t work on 2.3 either, but it is.
Have you tried what I suggested on 2.4 yet? It’s VERY unlikely to be a binding problem as such. You have already stated that every other one of these bulbs works fine, so clearly it’s not a basic bug. As I’ve said - this information comes from the device directly from let’s see what is received from the device.
@chris I did try re-initializing it on 2.4, and it did report the incorrect values for those parameters. I was then hoping to try doing the same on my 2.3 setup to see what it said…I wonder if it technically functions fine but is just reporting the wrong information…but because it’s already setup on 2.3 with the correct information it behaves properly.
For some reason though, I don’t see the option in the dropdown to re-initialize when on 2.3.
I think the device may need to be fully initialized in order for the option to show up on the menu. At least that’s the way it works in 2.4 – not sure about 2.3.
If you want to force the binding to reinitialize a node that has not completed initialization, you can run this command. Replace YOUR.HOST.NAME with the name of your openHAB host, and replace NN with the node number. I know this works in 2.4 and later. Again, not sure about 2.3 but I think it will work.
curl -X PUT -H "Content-type: application/json" -d '{"action_reinit":true}' http://YOUR.HOST.NAME:8080/rest/things/zwave:device:zstick:nodeNN/config
Not really. You could try editing the XML file in the userdata folder, but it might be reset at any time in future.
If reinitialise is already in progress, then you can’t reinitialise again. You could do what Mark suggested - this will send the command, but note it might have unexpected results and you would probably be better to the binding.
