It looks like Rule Machine needs the device drivers to implement flash to be able to use flash in a rule. There's no emulated flash functionality. I understand that I can make a virtual device that handles flashing but no thanks. I don't want 25 extra devices or any extra devices for that matter.
I was going to add the flash command to your driver but I was looking around for how the OOB driver handled it and I can't find the out of the box driver. Does the Hubitat group publish their drivers like ST did? There are only a few handful of samples in their github. I would like to see if they had an intelligent way to do it other than ramping up brightness and scheduling something X ms later to ramp it down. Does this switch support it in hardware somehow?
Typically you would use it as the trigger or condition in an RM rule, and then the actions of the rule would be whatever you are trying to do - turn on other lights, set brightness levels, whatever.
I have a really dump question. Is there an easy way to tell what version/firmware a switch is once paired? I know I could in ST IDE. But info doesn’t appear to be visible under the device in Hubitat.
Unable to change the default preference for LED behaviour. Change the preference, then click on Save Preferences, then click on the Configure button. No many how many times I do this I cannot change the LED behaviour. Any help would be appreciated.
Generally the pattern for drivers should be the following.
Configure is run when the device initially pairs, this is done at the platform level, it should not be run manually unless you're swapping drivers around and want to establish a base line, ie default settings to start from.
Changing preference settings should update (via the drivers updated method) the relevent parameter without the need to call configure.
Obviously how the preferences are applied to the driver is up to the driver author, however with the built in drivers changing preferences does not require calling configure by the user after preference settings are saved.
This would be the recomended approach to handling preference settings.
@mike.maxwell I just tried updating the driver and used the import feature. Really cool stuff. Since the code changes, is there anything you need to do once it is updated to have the switch/hub to recognize and use the new code?
Code is used instantly. As soon as the save is complete (compiles the code) it is available to be used.
A driver (or App) has independent sections. Meaning the next time some event occurs and needs the driver, the new section from the new code gets used. However, as Mike said above, that does not cause the other sections to be run.
Does anybody have an issue of the dimmer/switch status not updated on HE when the switch is toggled physically?
The state is reflected when I toggle the switches through z-wave, but not when I do it by hand.
If I hit "refresh" button, then the state comes in nicely...
Just in case, I tried it on six 12724s that worked perfectly with Smartthings.
One more note, I have the same behavior with the "Generic z-wave smart dimmer" driver as well.
Welcome to the community. Those older z-wave (non plus) switches/dimmers do not report physical events. SmartThings got around this issue by polling them frequently. If you need faster status updates from them, there is a built-in app called Z-wave Poller you can install. Select only the switches you need and you'll be good to go. Just remember, this polling adds a great deal of network traffic, so choose wisely...or replace them with z-wave plus switches.
I don't see any parameter that would let me configure the polling interval inside zwave poller app. Was it removed in the recent versions or am I looking at the wrong place?
