How about try super basic Z-wave parameter and see what kind of setting is in there? Possible the preference setting with the driver is not sticking.
I'll look into that, but I think it may be a little over my head
You ever consider changing the setting, saving preferences, then changing it back and saving pretences?
I've tried that as well. And rejoined them multiple times. Put a new switch in yesterday (same manufacture date) and the problem has carried over to it. The only dimmer I have that works is scene enabled. All the regular on/off switches are fine too.
Hey guys, I've been working with a couple customers behind the scenes and have identified what is going on. It seems that a change in Hubitat is causing problems with the configuration value sent to our devices. The only value that seems to be affected is our auto off parameter (which happens to be the only 2 byte value). This might cause problems with other Z-Wave devices using 2 or 4 byte configuration values, but I haven't confirmed.
For example, if I try to set auto off to a value of 20, Hubitat actually sets it to 5131
Inovelli Dimmer Scene parameter '5' with a byte size of '2' is set to '5131'
If I set it to a value of 0, Hubitat sets it to 89
Inovelli Dimmer Scene parameter '5' with a byte size of '2' is set to '89'
I've added a workaround to our drivers while things get straightened out.
1 Like
I read somewhere it's been found and fixed, next release.. least that's what my memory coughed up 
1 Like
That's why you shouldn't use two byte and larger parameters for small values in devices.
But yes, this is a known issue in the HE platform and will be fixed in a future release. In the meantime you can certainly change the parameter write on the driver to explicitly pack the bytes instead of relying on the platform to scale it to the right byte size.
That is what I did on a few of my drivers.
Or cheat as a temporary work around and use basic zwave tool to write to the parameter, using size 1.
My memory says the flaw was on the platform, as I (try to) remember more. Wouldn't matter which driver. Explicitly packing might help.
Using basic zwave tool works too. I've done it dozens of times. If it's a numeric one byte entry (<256) just specify size 1 for the parameter instead of the real parameter size.
if you specify the actual parameter size, it will not work as you run into the same platform issue as the drivers currently are running into.
Explicitly packing definitely works, and was the recommendation from Hubitat support until the platform change gets implemented.
This particular parameter is to automatically turn the device off after x number of seconds. A 1-byte parameter only provides 256 possibilities (0-255) which would be 0 - off, or 1 sec to 4 minutes and 15 seconds. It makes sense that a 2-byte parameter here as it provides 65535 possibilities (much more appropriate for this kind of setting). The actual limit on this device is 0-32767. I'm not sure why the last bit wasn't used, it may have been reserved for some reason, but the point is the same. 2 bytes allows a value of 0-off, 1 sec to 546 minutes (about 9 hours).
I guess I don't understand your point that "you shouldn't use two byte and larger parameters for small values in devices". As a matter of principal I agree, but a 2 byte parameter is appropriate in this situation. If I think about it, I have not seen any Z-Wave devices that use a 2 or 4-byte configuration parameter where it isn't appropriate.
Also, I don't fault Hubitat at all for this bug. I am a developer so I understand things happen. I know a few members of the Hubitat team and I think they are great. They always provide me with quick and thorough answers in a kind and professional tone. I'm team Hubitat all the way. In this case though, I don't think blame should be put on the device developer choosing a 2-byte vs 1-byte parameter. Even if they did so inappropriately. The platform should scale the input appropriately (and it has since its release). Again, I'm not mad at Hubitat, just clarifying my perspective.
2 Likes
Yes it is, you are right. I should have looked up the parameter details before being a smart ass. 
I assumed (incorrectly) that it was a 2 byte param for as small integer value. You may be shocked how many manufacturers do that (for reasons I can't understand). Obviously that doesn't apply here, though.
I think everyone agrees with that - no argument from me there. I had to work around this issue on a number of drivers myself. Glad it is going to be resolved soon at the platform level.
1 Like
Kind of related; is there any way to have github integration with the hubitat hub in a similar way that the smartthings account does so that code updates can be easily checked?
I have been trying for a couple days to figure out what I was doing wrong and why all my inovelli switches were "randomly" turning off. I finally sat down and searched these forums to find this post.
My 2-channel plugs seem to be having this problem as well. Any plans to fix these?
Sorry, forgot to upload those updated drivers. They should be available in github now.
About your other question, there isn't anything built into Hubitat at this time that will notify you if there is an update to a driver or app. I think there is an app watchdog or driver watchdog that does something like that, but I haven't had time to look into it yet.
3 Likes
Wow, thanks for the quick response and answers to my questions.
@ericm might I suggest you add the raw url for the code in each groovy file so that users don't make a mistake and import the wrong code ?
Thanks @anon61068208. There is a specific link for each device in the compatible device wiki:
Not sure if that is what you are referring to though.
He's referring to adding the direct link to the github raw code in the header of each driver/app. It's something that @ogiewon started and many devs are doing to make it convenient for users to update their drivers/apps using the recently added IMPORT button.
4 Likes
Oh, gotcha. Yeah, I can put the url at the top of the driver.
2 Likes
Notice that it's to the RAW url for Import. 
1 Like
