Just a quick note, worked with GitHub to shift my repo to the top of the network (above @ryanjmulder initial repo). I see there are a few forks out there, I would strongly encourage you to fork the top level repo to keep more closely aligned if you are able to further contribute.
Would/could the LEDs be configured in the driver as child devices? Or, @TAustin has developed drivers that create additional drivers. I admit I don’t understand what goes into this, but if that could be incorporated somehow to create the LEDs as RGB devices, it would be awesome. I really need the ability to automate the LEDs on my FC200+. Thanks to all you guys picking up the slack!
@Spire interestingly enough that was a similar ask from @ryanjmulder as well … Conceptually, it can be done, it may take just a bit to get down that path … I suspect that it would require some sort of multi-channel build out to emulate child “switches” … in any case, it is something I want to get to once I’ve covered through getting the firmware nuances and basic fan control turned on.
The Zooz Edge Driver exposes LED Color, LED Brightness, and LED Mode as things that can be acted upon from a routine, and they don’t seem to be child switches. I’m not sure how they did it, but it seems that there must be a way.
@ryanjmulder I expose the ability to manipulate those parameters for the HomeSeer set in similar manner.
The Community drivers have three files that work together:
init.lua (top level code)
– this table set is used when the “doConfigure” lifecycle event is fired
– the values are focused on the parameter #, byte size, and ‘default’ value
– this table set is used to update a device when “infoChanged” lifecycle event is fired
– similar to configurations, but omits the ‘default’ value
I have opened an issue in my repo to track … but short answer is that the new methodology is to move away from child devices (unless necessary) and to use a multi-component concept … my intent is to model each of the LEDs as unique components (Switch) that can be exposed to “on/off” functions
Development actually went somewhat the other way. Initially, edge drivers could only be multi component, no parent/child structure, but then it turned out that you couldn’t individually address the sub components with voice assistants, and you couldn’t change their names in the app and that just wasn’t working. So they went back and added parent/child constructs into the edge architecture to address those two issues. If you look at the stock edge drivers, you’ll see that several of them have now been updated to allow for voice assistant control of the children. This was particularly important for power strips and multi gang light switches, where the sub components are in someways more significant to the end-user than the master component is.
@JDRoberts yes, I have experienced this first-hand with Aeon Smart Strip … and I had to wrap the component with a Virtual Switch to allow them to be controlled by my voice assistant. I suspected that path was at best the initial path (speed), but that the longer road was to look at the Child pattern
Hey Jeff. Thanks for all of this. You (and Ryan) rescued me with this driver. Full functionality, multi-tap, etc with ZWP/Zlink dimmers. Oddly, last night, something changed last night that made them non-responsive. I tried excluding them, then re-adding, but they only work when I use the generic driver now. Appreciate everything you and Ryan started here. I’m hoping it’s something that can be resolved.
@ajtelang and others – @RandomEngy had opened a formal issue in the repo. I have pushed a fully updated code base to the main branch/channel. At this juncture I can see the primary issue appears to be resolved, but will await feedback before closing the issue.