I am working on dialing in my CT world and am using the Virtual CT bulb driver. Since no virtual drivers are available in the Hubitat examples respository, I can't really review the code to see what it does or how it works.
Can I just use a similar driver and call it a virtual device? I'm afraid to try it!
Have you looked at virtual driver code posted here in the community?
Not really, though I suppose it depends on what you really want out of the virtual device. Virtual devices generally simulate "real" device behavior by generating events when you send commands (e.g., if you sent a "Set Color Temperature" command to the virtual bulb, it will then report the expected value out of the "colorTemperature" attribute; for a real device, what normally happens is that the command is send to the device, then if/when the device sends the new state back to the hub, the attribute value is updated--that last part won't work with most "real" device drivers that weren't intended to work as virtual devices).
This is not the case. Here are the current virtual driver I see in the HubitatPublic repo:
- virtualActuator.groovy
- virtualLock.groovy
- virtualOmniSensor.groovy
- virtualOpenVentArea.groovy
- virtualThermostat,groovy
- genericComponentParentDemo.groovy and genericComponentDimmer.groovy, intended to demonstrate how the generic component drivers work, but this example is effectively a virtual parent/child pair example (due to how the parent is implemented)
If you are looking for a bulb driver in particular and don't know where to start, I can probably throw one together quickly from what I have...
3 Likes
I completely missed those- i must be blind as a bat. if you were to put together a virtual CT bulb... I'd be eternally grateful!
Is there anything you'd be looking for in the driver? Virtual drivers are pretty simple, basically implementing the required commands per the capabilities you declare. Since they're virtual, running the command would normally just do a sendEvent() or whatnot immediately to update the attribute corresponding to the real-world change you'd expect to see on an actual device. (There are rare exceptions; Hubitat's virtual shade drivers will, by default, simulate the delay after an open() or close() by going to an "opening" or "closing" position before "open" or "closed," but this is not common.) Being able to see the code shouldn't be necessary to use the device, but your intended use isn't clear to me.
To be perfectly honest, i intend to take what you create and replace my two virtual CT Bulb driver devices (I use one for monitoring Circadian Daylight - and another for tracking the CT Values during set during sleep in case I get up for any reason). I'm going to replace the color table with one that matches all my CT bulbs. thats it! nothing wierd, nothing wild! (and I intend to look at your work to learn more about this stuff as well).
I would use the published advancedZigbeeCTBulb driver as an example, and use it to create your own virtual driver.
I honestly can't remember but I was having a problem with a driver not doing Refresh right (okay - the way I wanted it too) and Bravenel edumacated me a bit. I ended up modding the OhLaLab driver since it refreshes so well. Bertabcd1234 has sort of offered and anything he does it going to be head and shoulders above my hacks! I'll hurry up and wait to see what he creates before I attempt delving farther than I can currently swim!
Try this:
1 Like
Flawless. I didn't see a refresh button so after the driver change on my existing virtual device it didn't pop into play right away - got it to kick in by sticking some values in the 'Set Color Temperature' button on its device page. It's exactly what I wanted and would have built myself - over a 4 week stretch of hair pulling. I"m grateful and thankful - I hope others also enjoy your work that you've shared with the community. Thank you for saving me hours of effort!
For anyone interested - likely no one - here are my personal color values - I use these based on the Alexa Developers table, with overlaps on the Wiki color temp table - effectively removing some of the odd names that seemed non-sensical in my environment:
if (value <= 2051) genericName = "Candlelight"
else if (value < 2450) genericName = "Sunrise"
else if (value < 2750) genericName = "Warm White"
else if (value < 3050) genericName = "Soft White"
else if (value < 4050) genericName = "White"
else if (value <= 5550) genericName = "Daylight"
else if (value < 6550) genericName = "Cool White"
else if (value < 20000) genericName = "Polar"
1 Like
Right, "refresh" normally tries to grab the current state of the device by asking it; for a virtual device, this doesn't really make sense--the state is all imagined (internally simulated), so I'm not really sure what it would do. I did try to make it set default values of some sort upon pairing, but it's possible I mistyped something to make that not work...
And yeah, I understand thinking the color/CT names are odd. I just used the ones Hubitat published as examples, but there are far more distinctions than I really care about as well as some names I wouldn't really use. But they're just for display purposes anyway, and I never use them anywhere, so doesn't really matter to me. 
(Honestly not even sure why they're there unless they had different plans for the UI when this was created, or it was copied for compatibility with ST.)
1 Like
I don't think your Virtual driver had any flaw - au contraire! I just assumed there would be a refresh button as it seems to exist on all the drivers - in hindsight I have no idea if all drivers have one. I use refresh and configure buttons by mashing them after a driver change - it seems to cause the driver to 'kick-in' otherwise I just wait some arbitrary time.
Re: colors - The color table has purpose - in the HE environment not much but my voice interface is through Alexa. I experienced this wholly confusing result when issuing color commands - as a human, I don't think 'wow - 2795 K would be great, I'll set my bulb'. I think 'I bet soft white would be nice'. Well issuing Soft White or other supported voice commands via Alexa results in the tiles showing some odd names. I compared the Wiki table, with the Google Home published table with the Alexa table to the results I'd get in HE and was really unhappy with the results. I felt that color names are a seperate, personal thing or at least there shouldn't be 'hardcoding' on drivers. It would be best to remove that kind of limiting seemingly arbitrary settings to a settings button in HE. Then one could choose 'Alexa' 'Google' 'Wiki' 'HE' or {custom}. In the end I took an example driver, put my color table together and had it cross reference as well as I could and this was my result. Then I banged into the Virtual driver having the same weird table and you appeared - then became my hero!
As a further aside - I wonder about other hard coded settings that are legacy. The example code I modded has changelog dates going back 3+ years - my guess is the driver is some very aged code that has just lingered. I'm sure I'm wrong.
I suspect the same ideas, and concepts apply in the color bulb world as well I have little doubt. Who defines what is Red? Is Alexa Red the same as Google Red? Does HE tiles reflect the same name? What about levels? is there a 'Set bulb to Half brightness' command for a level? I am certain no one wants to go back down that road - it's just no fun but sometimes that hard work can garner heaps of value toward the future.
Anyways - I digress. Thank you for doing this! I'm currently enjoying your work - Now when I tell Alexa 'Set the bedroom white' - the Virtual bulb, the bedroom lamp, Alexa and my head all agree!
