Trying to set up SharpTools with Hubitat and Webcore, and ran into a snag. The SharpTools color temp tile expects to see an attribute called "colorTemperatureRange" from the device, and uses this to set the minimum and maximum range of the adjustment slider. BUT...the Hubitat Hue bulb driver apparently doesn't expose that attribute, so the sliders don't go low enough to fully adjust the Hue color temp.
From Josh at SharpTools:
For reference, the optional colorTemperatureRange attribute is what is used for determining the range and it’s a string in the format 2200...7000 otherwise the slider defaults to 2700-7000K if the device doesn’t report a range.
Is there a different Hue driver that does have this attribute, or would it be relatively easy to add it to the stock driver?
Or...could HE devs please add it to the stock driver, for better integration with SharpTools?
My guess is that staff are therefore unlikely to add it to any stock driver for only this purpose. There is also no way to add it to a stock driver, as they are closed source (aside from a few examples they've published) and there is no way to "extend" an existing driver, only use a different one. If these are directly paired bulbs, the "Generic Zigbee RBGW Bulb" driver is one of those examples and could be modified and installed yourself. If it's a Hue Bridge bulb, there are at least two community integrations that you could also modify per the license terms (one of which is mine; not sure I want to do this if there is no "standard" use for the attribute...maybe it was an ST thing?).
Alternatively, perhaps SharpTools could provide a way to manually set this on the Dashboard for specific devices?
That was my suggestion also... just add a couple of variables on the tile edit screen to set the minimum and maximum color values. They suggested I post over here.
My bulbs are all bridge bulbs, exposed to Hubitat through the built-in Hue app.
As you alluded to, it's used in some SmartThings Color Temperature devices (including Samsung provided integrations even though it's not part of the SmartThings documentation either IIRC).
To me, it totally makes sense for the device to report what inputs it supports and there is precedence for this.
Take for example, the supportedThermostatFanModes and supportedThermostatModes from the Thermostat capability - it enables other apps to know what potential inputs are available - for example, we could normally expect that a thermostat would have modes like 'heat', 'cool', 'off'... but European thermostats often assume an implicit heat-only functionality and have extra modes like 'Eco' or 'Away'.
I encourage the creation of a Feature Request in the SharpTools community - from my original reply:
If there's enough community interest in it, I'd be open to adding it as a tile setting. That being said, I think it could easily be solved today by switching to a community driver like CoCoHue and adding the attribute to their own copy of the driver.
I've been developing and beta-testing software for 40 years....so I'm full of suggestions and feature requests. Some of them even make sense sometimes. LOL
You should still be able to create a request even if you've reached your voting limit. You can also unvote on something to free up a vote if you want to move your votes around.
So I installed the CocoHue app and drivers, and added a couple of CT bulbs. How do I add the colorTemperatureRange attribute, and get it to work in SharpTools? I added this to the driver meta:
attribute "colorTemperatureRange", "string"
But how do I set the value? (I haven't programmed any custom drivers).
EDIT:
I added the following line to void setColorTemperature(value), just to see if it would add the attribute when something fired, and it worked.
It added the attribute, which shows up in Hubitat's device page for a bulb as colorTemperatureRange : 1800...6500. I then created a new tile in SharpTools for that bulb, but SharpTools still has the same slider range.
Ok. Where is the best place in the driver to add the sendEvent line? And is that the proper way to initialize the string value?
EDIT:
Don't see how it can be related, but after reauthorizing that one bulb in cocohue to test it, two of my dashboards are completely empty other than the dashboard links, mode, and media devices. Even after removing the cocohue device...still all gone.
WTH? Dozens of tiles just gone now.
Please tell me there is a backup that I can restore hours of work from.
EDIT #2
All devices still show as authorized in Hubitat, but SharpTools says no devices are authorized.
Edit #3
For some reason, SharpTools just lost connection with Hubitat and had no authorized connections. Weird
Once the devices get synced over again, the tiles will rehydrate.
A large chunk of devices going missing during the sync is most often indicative of an issue communicating with the hub - either the hub getting bogged down or unable to communicate with the Hubitat Cloud Relay.
The most common first troubleshooting step is to reboot your hub, wait several minutes for it to boot up and things to calm back down, then retry the authorization process again starting from your SharpTools.io User Page
Thanks Josh. Once I resynced the hub, it came back, except for a weather tile that it lost.
I got it to work, sort of. I set the attribute to "1800...6500", which the Hubitat device page shows...but the SharpTool slider now goes from 1000 to 6500. It looks like the lower slider value isn't reading or scaling the low end correctly from that attribute.
More importantly, this isn't really a good fix for me. To make it work this way, I basically have to start over on many dashboard tiles with new Hue bulb devices, and replace dozens of devices in Webcore.... all to just get an accurate color temp slider. Unless there is an easy way to replace a device in an existing tile, I don't see this as a viable alternative.
Hopefully you guys can add a couple of slider variables to SharpTools in the near future.
