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?
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?
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
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
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,.
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...
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.
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
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.
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
I found that setting the device to Generic z-wave dimmer, I'm now able to refresh it from RM.
Any reason the "smart" version doesnt get included in the list of devices able to be refreshed under RM?
What are the differences between the smart and non-smart versions of drivers for generic z-wave dimmers and switches?
"Smart" and "non-Smart" is the Refresh method. Non-Smart has a refresh() method, Smart does not. Therefore devices using the Smart driver shouldn't appear in the selection list. 
"Smart" means it accurately returns status.
Thanks for the explanation.
So the bug here is in fact that the generic z-wave smart switch IS available to be refreshed in RM, not that the smart dimmer is not available.
what does it mean to "have a refresh() method"? both smart and non-smart have refresh buttons in the Device handler. Does HE do a refresh() by itself on these non-smart devices? or is it just made available to be used in RM?
Here's a good post that gives a tldr version with links to other posts if you want greater detail.
The fix for this will be in platform 2.0.4, it's been added to the generic switch and dimmer drivers, the ge motion devices, but excluding the scene controllers as none of the devices in that class need this command.
2 Likes
Confirmed working great now, thanks for the incredible support!
So glad I moved to HE.
2 Likes
Glad to hear it! Still don't know why yours act differently than mine. But now, I guess it doesn't matter. 
Hi, @ericm do you have a solution for this issue? I when RM send a command to OFF device go OFF but Status still ON.
I might have a solution. The last person that I was working on with the issue said it cleared itself up, so we weren't able to do much troubleshooting. You can try this version of the driver:
Let me know if that makes a difference.
