Reading todays posts I saw something I felt was worthy of a deeper discussion. Toggle. As it pertains to virtual drivers, switch drivers and group drivers.
I once dove the deep hole of learning and writing a driver. It was based on the shoulders of a giant but I needed abilities and 'updates' for newer devices.
I recognize that devices have command sets - and not every command is available in a driver. In some cases it's nearly impossible to find documentation of these capabilities, or sometimes no one is aware the device has extended functions.
I note that a number of my switches whether they be Group Switches, public drivers /generic switches and specific switch drivers that 'Toggle' isn't a button on the device - ie; the driver has no built in ability.
I customized my driver and added this ability. It was hard to do. I learned about timing and about command sets for hardware devices. But I did succeed.
Often, I now rip open drivers, customize them and add a number of features I like, including AutoOff, Toggle and Flash.
I submit that developers who create new drivers and future updates to old drivers (including embedded HE provided drivers) should add enhancements to support a similar 'additional' capability set.
Autooff, Toggle and Flash are VERY valuable features. In my case, toggle is critical to my environment since I use smart bulbs with smart switches. Adding this feature to my drivers allows me to make smart switches play nicely with my smart bulbs.
The cost is I'm now deviant. If an updated driver comes out (which is albeit rare) I have to create a source patch and modify my fork. But I have extended control that others using 'generic' drivers don't have. It's a trade off that has paid off.
Thoughts and discussion? (begin the belittling).
I can see where some people would find this valuable. But at the same time, all of these are do-able at the app level. For toggle, the app just needs to read the current state, then send the appropriate command. This is what apps with a "toggle" function built in already do, like Button Controller, Rule Machine, Dashboard (it's what clicking/tapping a switch tile does), and others. Auto-off can also be done with an app (I wrote one to do exactly this, and I'm sure there are others)--but some devices have a built-in feature where the same can be configured. In those cases, it is often in the driver.
Flash is a bit of an odd one. Theoretically, this can also be simulated at the app level, and some devices have such a function built in that the driver just exposes. For others, it's simulated in the driver by basically repeated, scheduled calls to turn the device on or off. In fact, most drivers I've seen actually do it that way. (It's further odd in that this command was never part of a "standard" capability until recently, so apps like Rule Machine had no way of knowing whether a particular switch/bulb/dimmer you selected could actually do it. That changed recently, though I'm not sure if it's taken advantage of yet.) It's further odd in that doing this tends to flood mesh networks with commands, making Zigbee and perhaps especially Z-Wave sometimes unhappy, subject to missed commands, etc., so some people recommend avoiding it or using a long interval, and some community developers choose not to include the command at all (unless the device natively supports it)...and some people who do use it have bad luck.
Anyway...
I can't tell you why some are standard or at least conventional and others are not. My guess is that lots of early built-in driver authors agreed with you on the value of flash(), just perhaps not on the others. Neither is "right" or "wrong," but neither also concerns me much given that an app can do anything there with or without anything special in the driver (and that's where I prefer to keep as many of my automations as possible, especially things like "auto off" that might be more difficult to troubleshoot--but I understand the gray area between automation and device features, especially when it's one way with some and another with others).
FWIW, I also use smart switches (load control disabled) with smart bulbs and haven't needed anything special to make it work.
I prefer Auto Off to be managed in an app. (I use the Auto Off app). That way I only have to go to one place to create, review, and update any auto-off settings. Using them in a driver for me would complicate things, as then I have to actually remember what I've done, where. That's a big ask for me. Just my 2 cents...having auto-off in a driver wouldn't bother me, but I wouldn't use it (except for virtual switches that I have created to use specifically in an automation).
Sorry to go off topic, but is this an actual app that has been developed by a user?
If so, to save me searching as I'm a lazy so and so, could you point me in the right direction.
Thanks.
some decent dialog, I admit. Just breaking down my post into 3 sub functions - autoOff, toggle and flash.
autoOff is easily arguable as an app. heck, I even agree that it doesn't really belong in a driver. I do have a small argument in favor tho - virtual switch devices. adding a child for each autoOff needing device seems like too much managment. I set and forget in my virtual switches.
Flash is on the bubble. about 1/2 of the hardware manufacturers have it built into the device commands. It is very useful when you have a bunch of switches around the Christmas tree doing various odd jobs and you can't remember which one turns on the various decorations! I love flash personally.
Toggle is to me critical. Like 3 position switches. I was recently doing some SQL work building an sales app and it was so useful. Same with hardware - instead of having to poll and parse a device status, you can just issue a 'flip' and be done.
One thing I'll add is the advancement of drivers. Drivers to me IMHO, are no longer built like the models of old. hardware links directly to app layers today. Because of that, its simpler to add functionality into the hardware with code. If we rely solely on the hardware manufacturer - we get limited solutions. Besides that, there never is agreement on what vendors support and implement. Kinda like Matters (HA!).
There is no "flip()" command. The driver needs to know the state of the device to either turn it on or off.
And knowing that state doesn't require having to do a poll if a device appropriately sends its status to the hub as an event. Zigbee devices, z-wave+ devices, and Lutron devices do this.
not sure if maybe it was a language thing but flip is another word for toggle. You 'flip' a switch - regardless of state... ie; toggle it. it's often a part of the built in hardware command set. Polling the device prior to setting a state is commonly done -the recent implementation of optimization is one of the first apps I've seen that rely on the hub already knowing the correct state. I don't rely on it since devices have proven to be too flakey to be trusted and hubitat has them wrong too often for it to be trusted. I never enable optimization and rely on metering.
But this is a topic of 'Toggle' - not my personal experiences and use. I digress.
For my upstairs hall lighting I have 3 smart switches (newer Zen23s) that are power only /no load and one single pole dimmer (Zooz Zen74) connected to the hall lighting on the stairs..
I used to use ZW association to connect all of them together but found the popcorning effect to be terrible and sometimes lagging. Also tried HE's mirrorsync app then a somewhat convoluted sequence in Node-RED. None of these worked well enough to really be happy. Also trying to keep all the switches in sync was quite noisy with all the relays clicking.
Switched over to using "smartbulb" mode for all the switches and button detection (toggle mode) and things have been working great ever since. Now don't have to worry about the state of any of the switches and there are no relay sounds..
Neither is "right" or "wrong," but neither also concerns me much given that an app can do anything there with or without anything special in the driver (and that's where I prefer to keep as many of my automations as possible, especially things like "auto off" that might be more difficult to troubleshoot--but I understand the gray area between automation and device features, especially when it's one way with some and another with others).
Just my 2 cents...having auto-off in a driver wouldn't bother me, but I wouldn't use it (except for virtual switches that I have created to use specifically in an automation).
