I use a driver to control Tuya color light bulbs, it works fine within Hubitat with all the controls. I added the bulbs in sharptools and also everything works fine except when I change the color through the picker the bulbs switch off, it doesn’t reflect the color change in Hubitat. Is there any suggestion ?
What driver are you using in Hubitat? It sounds like it might have a wonky setColor
implementation.
I think the driver works fine, did further testing today and realized that when I change the RGB setting sharptools send all the info correctly but the level is always switched to zero. Manually changing the level on sharptools send the correct level to Hubitat and all work fine. Which means that every time I change the color I have to change the level just to avoid it going back to zero. Any ideas ?
Still sounds like a driver issue to me. Almost sounds like the driver is expecting the color and level when calling the setColor()
command.
If it’s a community developed driver, I might be able to suggest some edits to get it to work as expected.
Any hope to fix the level set to zero at each color change ?
I took a look at the code and it’s quite a complex driver as it contains all the logic for all the various Tuya device types and relies on ‘Generic Component’ devices as a proxy for the real devices. Without having a real device to test with, I’m hesitant to suggest changes… but if you want to give it a try, keep reading.
The issue appears to be what I expected. The setColor(COLOR_MAP)
command is expecting the level
to be included in the map, but it’s supposed to be an optional value. What appears to be happening if the device is falling back 0
during one of its conversions so that’s causing the light to get turned off.
This all happens around Line 473 of the driver:
I suspect you could work around it by adding a line that tries to fallback to the device’s current level if the level
attribute isn’t passed into the map. You would add a line just before the Map value = [
line:
colorMap.level = (colorMap.level != null) ? colorMap.level : dw.currentValue('level')
So the final function would look something like:
void componentSetColor(DeviceWrapper dw, Map colorMap) {
Map<String, Map> functions = getFunctions(dw)
String code = getFunctionCode(functions, tuyaFunctions.colour)
if (code != null) {
Map color = functions[code] ?: defaults[code]
// An oddity and workaround for mapping brightness values
Map bright = getFunction(functions, functions.brightness) ?: color.v
//level is optional, so fallback to the current device level if the colorMap doesn't include the level
colorMap.level = (colorMap.level != null) ? colorMap.level : dw.currentValue('level')
Map value = [
h: remap(colorMap.hue, 0, 100, (int)color.h.min, (int)color.h.max),
s: remap(colorMap.saturation, 0, 100, (int)color.s.min, (int)color.s.max),
v: remap(colorMap.level, 0, 100, (int)bright.min, (int)bright.max)
]
if (txtEnable) { LOG.info "Setting ${dw} color to ${colorMap}" }
tuyaSendDeviceCommandsAsync(dw.getDataValue('id'),
[ 'code': code, 'value': value ],
[ 'code': 'work_mode', 'value': 'colour']
)
} else {
LOG.error "Unable to determine set color function code in ${functions}"
}
}
Thanks a lot for the effort, unfortunately it didnt work, the lights didn’t go off but the color changes are not transferred from sharptools to hubitat.
One observation which may help is that when I use Hubitat dashboard with the original driver’s code everything works fine, which push the problem to the sharptools-Hubitat integration.
Can you check the post above and try again? I noticed a typo in the original post. I’ve updated it with the correction:
The change should be:
colorMap.level = (colorMap.level != null) ? colorMap.level : dw.currentValue('level')
–
If that doesn’t help, I would suggest posting in the device author’s thread.
Without logs or further details and not being able to see the changes being made it’s hard to troubleshoot.
As mentioned above, I can see from the code above the problem is as I suspected. Hubitat likely includes the level
value when setting the color, but it should not be required by the driver (per the capability spec). As such, SharpTools doesn’t include it as the device drivers should still work without it. This device driver falsely requires it.
Thanks again, you are absolutely correct, now it works fine.
Do you mind to share this important fix on the hubitat community ?
I shared it as a PR directly to the device author the other day: