Inovelli NZW37 not refreshing/reporting switch state

Awesome, thanks guys.

@john.hart3706 @dustin
Were you guys able to resolve this? I just noticed I'm not getting states updated. I could make a rule to refresh but thought I's see if there was another solution.

Thanks

I got sidetracked on building out new devices so haven't had time to test this on my side. I've just left the refresh rule in place to handle the state change updates.

1 Like

Thanks for the reply.
It's strange that this plug has worked perfectly for a couple of years...

Not to hijack the thread, but im seeing the same problem with some of my devices, not Inovelli. I had to resort to a refreshing rule that runs every few minutes, which fixes it right up. Seems like an ugly hack that shouldn't be needed. The devices I have affected are a GE 14291 and Leviton DZPD3s. The RM Refresh isn't able to select the DZPD3 Generic Z-wave smart dimmer devices though, which seems odd when I can manually do it right from in its device.

SmartThings polls all ZWave devices. Which is a complete waste of a ZWave mesh, if the devices are sending status anyway. Older ZWave MIGHT not send status. ZWave Plus MUST send status. The GE 14291 is ZWave as far as I can discern.

On Hubitat, there's an App called ZWave Poller. It's entire reason for life is to poll dimmers (and switches) that are not sending status.

This dates back many years to when there was a patent for Dimmers sending status. The patent has expired and everything new is ZWave Plus. If you find a ZWave (not Plus) device, carefully consider before buying it.

There's a 9 month long thread here on the forum regarding this. Ultimately it lead to Hubitat including the ZWave Poller app. Give it a try, you may like it too.

Thanks for the reply. Id like to try the z-wave poller but the 14291 doesnt appear in the list of devices able to be polled, neither do the DZPD3s. Both 14291 and DZPD3s are z-wave plus.

What else could explain devices not sending status reliably? Ive often wondered why z-wave isn't more like TCP that has an ACK mechanism to check if things were done, and to try redoing them until they are.

Its interesting you mention SmartThings polls all devices because I had unreliability there too, which is why I moved to HE....

Z-Wave+ devices using the Z-Wave smart series drivers should not need polling, if they do something else is going on...

Agreed. So any ideas what might be the issue here when the status doesnt update when I click the physical device buttons on or off, but always updates instantly and correctly when I do a refresh from device in HE ? the status always seems to update just fine when I turn the device on and off from HE ie digital.

Ive read about GE switches that didn't reliably update physical state, but this unit worked fine until recently with it on ST, so I assumed this one wasn't one of those.

ive excluded and re-paired it with no problems, it participates and completes its z-wave repair just fine.

im seeing the following in debug logs when the buttons are pressed. What might skip Crc16Encap mean? this is using the generic z-wave smart switch driver.

dev:2342018-12-31 03:39:03.441 pm infoBasicReport value: 0

dev:2342018-12-31 03:39:03.440 pm debugparse description: zw device: 1D, command: 2003, payload: 00

dev:2342018-12-31 03:39:03.067 pm debugrefresh() was called

dev:2342018-12-31 03:38:59.495 pm debugskip: Crc16Encap(checksum:null, command:null, commandClass:null, data:null)

dev:2342018-12-31 03:38:59.491 pm debugparse description: zw device: 1D, command: 5601, payload: 25 03 00 67 A8

dev:2342018-12-31 03:38:54.293 pm infoFart Fan was turned on[digital]

dev:2342018-12-31 03:38:54.283 pm infoBasicReport value: 255

dev:2342018-12-31 03:38:54.282 pm debugparse description: zw device: 1D, command: 2003, payload: FF

dev:2342018-12-31 03:38:53.920 pm debugrefresh() was called

dev:2342018-12-31 03:38:47.994 pm debugskip: Crc16Encap(checksum:null, command:null, commandClass:null, data:null)

dev:2342018-12-31 03:38:47.959 pm debugparse description: zw device: 1D, command: 5601, payload: 25 03 FF 79 58

dev:2342018-12-31 03:38:41.605 pm warndescription logging is: true

Crcencap16 is a depreciated zwave command class and is not used in zwave+ devices, so what exact model switch do you have that's associated with the logs above?

I pulled it out of the wall to check, it shows 14291-3, date code 1823 on the front.

command: 5601, payload: 25 03 00 67 A8

looks like its sending a 56 01 for crc16encap but then its a regular command class 25 03 with 00 for off and FF for on

Very odd, the version on mine is 5.0, not 5.0d, same model, date code 1714.
I don't recall it sending data in crc encap, and it makes no sense what so ever, zwave+ has crc built in...
And why would ge implement a depreciated command class in a new device in the first place?
In any event we haven't implemented crc16, so none of our drivers use it either, so that is the reason that device isnt reporting since we aren't decoding that payload...

How old is this switch?

The only devices I'm aware of that insist on crc16 are very old fibaros...

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

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?

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

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

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?

Have you looked at this thread?