Inovelli NZW37 not refreshing/reporting switch state

🛎️ Get Help
32

That is weird. I have a number of GE/Jasco 14291 switches, and don't remember seeing that message... Although I wasn't looking for it either.

With debug on all I see is:
dev:712018-12-31 07:33:43.513 pm infoGuest Bathroom Vent was turned off[physical]

dev:712018-12-31 07:33:43.492 pm infoSwitchBinaryReport value: 0

dev:712018-12-31 07:33:43.485 pm debugparse description: zw device: 16, command: 2503, payload: 00

dev:712018-12-31 07:33:25.940 pm infoGuest Bathroom Vent was turned on[physical]

dev:712018-12-31 07:33:25.927 pm infoSwitchBinaryReport value: 255

dev:712018-12-31 07:33:25.921 pm debugparse description: zw device: 16, command: 2503, payload: FF

1 Like
33

date code 1823, bought from Amazon around September. I have factory reset it with the 3 taps on 3 taps off magic command, which resulted in the led flashing 5 times to confirm, then it was able to pair easily. I have also air-gapped it, but I have not yet tried killing its breaker. I read somewhere that popping the air-gap was not equivalent to turning the break off and on. Is it worth a try?

34

No, that isnt going to fix this unfortunatly...
I'll have a poke in the zwave aliance database tomorrow, maybe there's a parameter option to disable this nonsense...

35

I did not... I'm working on getting logs etc over to @ericm. I've been offline for a few weeks so just getting back to this.

1 Like
36

Googling around for things like 14291 and crc16encap, im seeing other folks had the same issue and someone wrote a DTH for ST that included the crc16encap method for the event function, and it made the device work properly for them. So maybe the generic z-wave smart switch handler in HE needs the crc16encap added?

If not, how might one go about making a custom driver? Is there a way to access the code for the built in drivers so they can be edited and made into a custom device driver?

Or maybe there is a way to tell the switch not to use crc16encap by setting a config option? that would be of course the most elegant solution. Where are the config options documented?

37

Have you looked at this thread?

38

So I just installed a new GE 14294 dimmer, and it has the same issue, its sending crc16encap when you press the physical buttons.

Could this be due to some command that Hubitat is sending to it (and the 14291 switch) when it adopted the device? Like its putting it in "crc16 mode" somehow?

Im not sure what to glean from the referenced Fibaro thread, other than crc16encap capability is coming to the platform? If so, great! But does that infer it will also be implemented in the generic z-wave smart switch and dimmer drivers?

39

I just don't understand that. NONE of my GE 14294 dimmers send CRC16encap commands/events/errors. I don't get what would be different between yours and mine.

All I see when turning mine off/on (with debug logging on) with the physical switch is:

dev:772019-01-05 03:16:58.262 pm infoLiving Room Overhead Light Dimmer is 99% [physical]

dev:772019-01-05 03:16:58.260 pm infoLiving Room Overhead Light Dimmer was turned on [physical]

dev:772019-01-05 03:16:58.250 pm debugdimmerEvents value:99, type:physical, bin:-1

dev:772019-01-05 03:16:58.244 pm debugSwitchMultilevelReport value: 99

dev:772019-01-05 03:16:58.242 pm debugparse description: zw device: 1A, command: 2603, payload: 63

dev:772019-01-05 03:16:48.746 pm infoLiving Room Overhead Light Dimmer was turned off [physical]

dev:772019-01-05 03:16:48.741 pm debugdimmerEvents value:0, type:physical, bin:-1

dev:772019-01-05 03:16:48.738 pm debugSwitchMultilevelReport value: 0

dev:772019-01-05 03:16:48.737 pm debugparse description: zw device: 1A, command: 2603, payload: 00

dev:772019-01-05 03:16:39.524 pm infoLiving Room Overhead Light Dimmer is 99% [physical]

dev:772019-01-05 03:16:39.521 pm infoLiving Room Overhead Light Dimmer is on [physical]

dev:772019-01-05 03:16:39.509 pm debugdimmerEvents value:99, type:physical, bin:-1

dev:772019-01-05 03:16:39.495 pm debugSwitchMultilevelReport value: 99

dev:772019-01-05 03:16:39.475 pm debugparse description: zw device: 1A, command: 2603, payload: 63

40

I was pretty surprised too. That's what makes me think they are being told to use it, or set into that mode by my HE somehow.

41

This is not possible, we don't have any of these commands implemented, none of our drivers have them either.
The device itself is dictating the use of this command, it's basically a wrapper around the normal command and includes a check sum.
The command had been depricated by the zwave alliance so new devices aren't supposed to implement it, additionally zwave plus has check sums already built in.
The crc command class is listed in the command class listing for this device on the alliance site, and I also have this device, and it doesn't attempt sending packets in crc16..., have you tried a full factory reset on this switch?

42

Its happening on two GE devices now, I just put in a brand new dimmer today, one would assume its factory fresh, and its also sending crc16encap on button presses.

What is the correct procedure to factory reset them? I did do the 3 up 3 down presses on the 14291 switch and got the 5 blue flashes confirmation.

Would it be useful to provide the version info from both devices for comparison with yours and @JasonJoelOld 's?

So you are saying the crc command IS listed as being one of the commands this device should be sending? Doesnt that indicate the driver should support it, regardless of whether its officially deprecated or not?

43

Here's mine.

52%20AM
Screenshot 2019-01-06 at 8.00.52 AM.png1328×206 8.45 KB

44

I used the basic z-wave tool to pull the actual versions from the device, here is what I am showing:

GE switch 14291
dev:2342019-01-05 09:07:09.241 pm infoVersionReport- applicationVersion:5.22
dev:2342019-01-05 09:07:09.239 pm infoVersionReport- zWaveProtocolVersion:4.54
dev:2342019-01-05 09:07:09.237 pm infoVersionReport- zWaveLibraryType:Enhanced Slave
Data
deviceType: 18770
inClusters: 0x5E,0x56,0x86,0x72,0x5A,0x85,0x59,0x73,0x25,0x27,0x70,0x2C,0x2B,0x7A
deviceId: 12342
manufacturer: 99

GE dimmer 14294
dev:2402019-01-05 09:03:51.296 pm infoVersionReport- applicationVersion:5.26
dev:2402019-01-05 09:03:51.295 pm infoVersionReport- zWaveProtocolVersion:4.34
dev:2402019-01-05 09:03:51.290 pm infoVersionReport- zWaveLibraryType:Enhanced Slave
Data
deviceType: 18756
inClusters: 0x5E,0x56,0x86,0x72,0x5A,0x85,0x59,0x73,0x26,0x27,0x70,0x2C,0x2B,0x7A
deviceId: 12344
manufacturer: 99

45

Here is the basic zwave tool info for one of my 14294. Both the version and data info are identical to yours.

dev:772019-01-06 01:08:53.885 pm infoVersionReport- applicationVersion:5.26

dev:772019-01-06 01:08:53.882 pm infoVersionReport- zWaveProtocolVersion:4.34

dev:772019-01-06 01:08:53.880 pm infoVersionReport- zWaveLibraryType:Enhanced Slave

46

Thanks for this Jason, the mystery continues. Identical devices, identical firmwares, different behavior.

Im tempted to pick up a 3rd GE/Jasco switch or dimmer just to see if it also does the same thing. I think that would pretty firmly push the chances above pure coincidence that I have 2 faulty devices and it s actually the HE thats telling them to use crc16encap, or putting them in that "mode" at pairing time.

Could it be some setting thats gotten stuck in the HUSBZB-1 stick thats making them do this? A couple weeks ago I did pull the stick from the hub and use it on a PC for a few minutes while doing some firmware updates.

I started down the rabbit hole of creating a custom driver that would work around this issue, to find that its the zwave.parse function thats not handling the crc16encap type, just returning nulls for the members. Still hacking away at it, learning groovy at the same time. The parse function in my driver splits the description string into fields, if the command is 0x5601 , then re-pack the description string without it and carry on as usual. Probably a horrible hack, but it might get my GE devices working, which is all I care about at this point. Hoping the built-in zwave.parse function could be updated at some point to support crc16encap method, even though its supposed to be deprecated.

PS 1000 apologies to the OP for taking this thread off-topic, maybe it should be forked into its own thread, but I dont know how to do that,.

47

Should, could and would are all different things.
Not every command class needs nor should be used in every device driver.

Just to be clear, irrespective of what you see in the live logs, these devices are? or are not working...
And if they arent working, is it physical or command activation that isnt working...

48

As I've already mentioned, the pairing process does not tell the device to use crc, the device itself is making this decision on its own.

49

its the physical button press this not being seen by HE due to it being crc16encap.

this is what the debug log shows when I press either physical up or down button

dev234)2018-12-31 03:38:59.495 pm [debug] skip: Crc16Encap(checksum:null, command:null, commandClass:null, data:null)
dev234)2018-12-31 03:38:59.491 pm [debug] parse description: zw device: 1D, command: 5601, payload: 25 03 00 67 A8

50

The devices work fine on their own, and HE can control them just fine, with status being updated correctly too. Its just the physical button presses that aren't seen by HE, which is a problem for the bathroom fan switch as it needs to trigger a timer, and for the other the motion lighting rules need to know if the dimmer has been turned on or not.

For the switch, I am working around the issue with a refresh rule machine that runs every 5 minutes. Unfortunately, for some reason, dimmers are not available in RM as devices that can be refreshed, which is strange as there is a refresh button in its device page that works fine to update the device's status when clicked in the web UI.

51

Understood, thanks, I'll fire up mine tomorrow And see what's up with it, we are planning on implementing the crc16 class, so this shouldn't be a long term issue.

1 Like