Issue with one GE switch on Wave 2.4 binding

zwave
Tags: #<Tag:0x00007fe05d18d158>
(Trevor) #1

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.

(Trevor) #2

@chris any thoughts? Any other data I can provide that would help?

(Chris Jackson) #3

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.

(Trevor) #4

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 Jackson) #5

Why do you say this? Sorry, but I don’t understand the point you’re making?

(Trevor) #6

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

(Trevor) #7

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

(Chris Jackson) #8

As said earlier -:

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.

(Trevor) #9

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

(SiHui) #10

As far as I remember that hasn’t changed: click the reinitialize button in the advanced Thing dialog in HABmin.

(Chris Jackson) #11

Yes, it’s the same as the new binding.

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.

(Trevor) #12

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

35%20AM
Screen Shot 2019-02-14 at 8.53.35 AM.png1858×746 62.1 KB

(Chris Jackson) #13

I would suggest that the switch is broken then.

I think the binding now might use the listening flag to make some decisions so this might be why it possibly worked in the past, but doesn’t now.

(Trevor) #14

@chris Is there any way to “override” the settings? Also, any thoughts as to why I don’t see the Reinitialize option in habmin in 2.3?

(Mark) #15

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
(Chris Jackson) #16

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.