Getting this error:
Using built-in driver for bulbs
Any idea on what might be the cause of this error?
Thanks
This is a problem with the HubConnect RGBW Bulb driver. It will need to be updated to match the "new" (as of Hubitat firmware 2.2.6) specification for the setColorTemperature() command, which can now accept up to three parameters instead of just the required one (color temperature, level, and duration; not just color temperature).
I'm not sure it's "officially" abandoned, but we know the original app developer no longer uses Hubitat as his primary hub. Unlike the app, the drivers are under an open license, but my suspicion is that this is still unlikely to happen. If you wanted to fix it yourself, there appears to be a set of lines in the RGBW driver now that looks like this (starting at line 173 in the code I'm looking at in the current v2 repo, but this may be different at a different point in time):
def setColorTemperature(value)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "setColorTemperature", [value])
}
If you change it to something like this instead, it should work:
def setColorTemperature(ct, level=null, duration=null) {
if (level == null && duration == null) {
// just in case any pre-2.2.6 drivers don't like the "extra" parameters and they
// aren't specified--more likely to be compatible:
parent.sendDeviceEvent(device.deviceNetworkId, "setColorTemperature", [ct])
}
else {
parent.sendDeviceEvent(device.deviceNetworkId, "setColorTemperature", [ct, level, duration])
}
}
3 Likes
That fixed it, I certainly appreciate the help on this.
Thank you
1 Like
I've treated this like it was a pull request and will release both the RGB and RGBW drivers with the change as I get a moment to wrestle with the duplicate release repos.
2 Likes
RGB shouldn't have color temperature, so this or a CT-only driver (not sure I remember there being one) should be the only place(s?) you'd need to worry about. Thanks for the maintenance!
The RGB bulb driver does have the CT method because the HubConnect (stub) driver philosophy has been different from traditional.
Had it been possible, Steve probably would have created a single driver for HubConnect that contained every option. There are conflicts in doing that but it's not impossible to have gotten down to single digits in drivers.
But built into HubConnect from the beginning was the expectation that it wouldn't cover "tomorrow's devices" and that a mechanism to allow anyone to create a stub driver specific to their device, was needed.
However, stub drivers are built to a "family of devices" definition vs a specific device. Thus having the CT method inside a non-CT driver meant it could be used for bulbs that were not quite an exact match for the RGBW "family".
I've updated both out on github:
And I've updated HPM's manifest BUT it's not detecting the change. I'm probably doing something wrong in the manifest, but that's another day's task. 
Note: I used an Overload method vs an IF within the method.
I just took a look at this and it should be noted that the two signatures now in the driver don't quite match all possible cases. The two I'm referring to are, of course:
def setColorTemperature(ct)def setColorTemperature(ct, level, duration)
In the "new"/three-parameter command, both level and duration are allowed to be optional, so nothing will match if, say, you run a setColorTemperature(2700,100) without a duration (or even if the second parameter is explicitly null but the third is not provided at all). Probably not a lot of apps that do this, but it is technically allowed. I do remember people playing around with this in the admin UI during the initial releases (when it was new), however. 
1 Like
def setColorTemperature(ct, level, duration=null)
