- Exclude your LZW36 and join it without security.
- Download the firmware update from Inovelli
- Follow this doc
2 Likes
If you're using an Inovelli device I'd look and see if they have their own device driver (via HPM if you've got it). I installed one of their Red Series dimmers and the driver that came with Hubitat was messing it up. I installed the Inovelli driver via HPM, changed the device to use that, and all of a sudden it worked perfectly. It also had a TON more options and functionality.
1 Like
There is an Inovelli driver available for the LZW36 on their site, and yes it does have some features the built-in driver does not.
The Inovelli driver is available via Hubitat Package Manager as well
1 Like
Cool. Iām not a user of HPM so I wouldnāt have known.
ugh. I am losing confidence here....
I've excluded all my devices that were paired with security (except 2 door locks) and then re-included all of them again. Recreated my coming/going scenes and recreated my RM to trigger scenes based on modes. Still getting incomplete scene activation. Another thing that might help troubleshooting is that the scene sometimes says "captured & set" like this screen shot, even though it's clearly not fully set - as is also evidenced by the "Activate Scene" button displaying as an option.
I did try it once before unpairing everything. Let me give it another go since I've added everything back with no security. Thx for mentioning
If Iām remembering correctly, Mike Maxwell said 50-75ms was usually enough time. I did 50 since I didnāt have that many devices. You might want to try 75 first and try less if successful.
I just edited the main scenes to meter at 250ms. I ran one just now and all devices responded, except one. I'll keep tweaking, this might the last piece.... fingers crossed!
1 Like
I've slowed it down to 500ms and still getting 1-4 stragglers. If I go to the device page and view directly, a sinlge click 'off' or 'on' responds perfectly and quickly. Still think there's something amiss with the Scenes.. For example, I have set all the devices in the correct state (most with the scene running, then cleaning up the rest directly (through device pages) and the Scene details show all the devices in their correct states but still doesn't say "Capture & Set" or "Active"? Any ideas?
I've only written one driver (albeit, its intended to be universal for all dimmers/switches https://github.com/jvmahon/HubitatCustom) but I've take approach #1 as I was trying to optimize for speed. So in my driver, I assume the command will succeed and send the "sendEvent" before I instruct the device. This allows other rules to trigger and stuff to update right away. As was pointed out, the risk in doing that is that the command never makes it to the device which could lead to devices being out-of-sync with Hubitat. But to compensate for that, I also use the Supervision command class which implements an automatic retransmit if the command isn't acknowledged by the device. I found this ensures the reliability of operation, but allows other Hubitat "stuff" to work faster. So, for example, another rule can be triggered before a dimmer finishes a transition . My driver does work with devices that don't support supervision - which are generally older pre-S2 devices - I haven't noticed a big difference in reliability, but maybe a few times they failed to respond. My personal feeling is that the added reliability of the "Supervision" class is a key reason to use and buy S2 devices (I understand all S2 devices implement supervision) and is more important, at least to me, than the security features of S2.
Have you tried activation optimization? I assume itās similar to the optimization in groups, which doesnāt send the command if the device is already in the correct state.
Is there a way to ensure this in play for my scene activations?
Should I go back to the drawing board and ditch 'scenes' altogether and just use individual actions in RM for all the device commands I want to send?
No, supervision doesn't matter if you use scenes or RM. Its about how you included the device and the drivers you use. The way it generally works - if you included the device using S2, then the device will send to Hubitat using supervision ensuring reliability from Device -> Hub direction. But the driver you use on the Hubitat side will still need to implement supervision to send "supervised" to the device for Hub -> Device direction reliability. The appropriate driver gets you "supervision" from Hub -> device even if you don't pair using S2; S2 gets you supervision from device -> hub even if the driver doesn't support "full" supervision. At this time, I"m not aware of any driver that implements supervision other than the one I mentioned - you can give that a try for a few devices to see how that affects your scenes / rules (you can always go back to whatever you had before). Just be sure to reboot hubitat after switching to my driver set (there's a lot they do during startup, and they won't work correctly without the reboot). Good luck.
Thanks - I'll give it a go later today if I get the chance.
I also noticed just now that after excluding and re-including all the devices with no security, I get 0 nodes that have any other nodes listed for "out" on the zwave details. They seem healthy enough for the "in" with most listing 14-15 nodes. (Most are identical patterns, which is interesting). Example:
in: 0x5E, 0x26, 0x25, 0x85, 0x8E, 0x59, 0x55, 0x86, 0x72, 0x5A, 0x73, 0x70, 0x5B, 0x60, 0x9F, 0x6C, 0x7A, out:
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
