setColorTemperature in virtual RGBW device turns bulb on

🚧 Developers
1

.... setLevel(0) impossible... same with setColor(h,s,v) with a level: 0

I'm likely going to post a few issues with the virtual RGBW driver published by Hubitat (closed source), additional to the post a few days ago which was unanswered.

Let me start with a question - the setLevel command in the UI for this device shows an allowable input range of 0-100 , as expected, but in reality you can't post a value of 0 in this entry box, only 1 or larger. Why ?

The bad side effect of this is that a virtual RGBW does not turn off by posting a level of 0 which is contrary to the default implementation in a standard dimmer, a behavior that I personally dislike, but that's been discussed and dismissed elsewhere. Ineed it will turn on instead. It at least should be consistent within HE.

Net effect - you can't set a colortemperature on a bulb without turning it on - even though the setColorTemperature command supports inclusion of a level eg 0 as the second parameter. It will ignore 0 and turn the bulb ON at level 1. Why is this behavior preferred ?

setColorTemperature( colTemp, 0 ) << turns light on even though brightness level is 0

It's the same gripe I have with level - setting a brightness >0 turns the lamp on. I don't want that behavior - if the lamp is switched OFF then it should remain off is my preference. But I understand there's another expectation on this.

I am trying to create a virtual RGBW that reflects the state of a bulb as reported on MQTT but every time the colortemperature status is reported the bulb turns on. I can't check the color temperature matches the virtual bulbs color temperature as typically this is a rounded value e.g. 5000 rather than 5123 so I will always try and update the HE virtual RGBW device which turns the light on even though I know it's off.

I have moved on from HE being my primary controller for these and other enforced behavior reasons but I am trying to maintain the MQTT application in a way that HE devices can be exposed to MQTT allowing them to be used from other controllers, and the reverse of allowing a remote device being mirrored into HE but aspects like this make it very difficult causing spurious on off with lights that are synchronized.

Why is the code implemented like this and why are virtual (and generic) drivers not published in the HE public repository to allow us to work around this behavior ? These closed source basic drivers are another reason that HE is no longer my preferred controller. I understand that they might become harder to support if modified but they have issues that can't easily be worked around except by proliferating more and more custom drivers which confuses.

2

The command setLevel 0 turns off the device, leaving the level unchanged. I have no problem entering a zero for setLevel, and just tested this. For both real and virtual devices, setting level (other than to zero) turns on the device, and setting level to 0 turns them off.

Yes, setting colorTemperature also turns on the device. Some drivers allow preset of color or color temperature, but that feature has not been done for the Virtual RGBW driver. But since setting the level to zero turns the light off without changing the level, this is a reasonable thing to do. The alternative is that if you were to have the driver set the level to zero, and then the light was turned on, it would say on but be off. This would really confuse users.

I will post the Virtual RGBW driver code to our public repo.

1 Like
3

So how can I set colortemperature without the device turning itself on ?

That would seem the obvious way leaving level at 0 or previous value and switch OFF, but switch becomes ON

4

You can't without pre-staging. 0 is not a valid value for colorTemperature. I can't tell what you're trying to accomplish with this. Setting colorTemperature turns on a light that is off, just as setting level to some value other than 0 does.

This driver could have a command added that sets the color temperature without turning it on. That is called pre-staging.

5

Has any thought been given to adding a capability and associated command to preset color temperature (in a standard fashion, versus the historic preference-based options in some drivers)? Similar to LevelPreset starting in firmware 2.2.6...was hoping that was the beginning of something like this but haven't seen anything since. :smiley:

(I know, if this gets done, then color probably should, too, and that's a bit messier, but...still possible, and probably better if standardized, in the long-run.)

That's one way this issue could be addressed, virtual or otherwise. In the meantime, it could probably be a custom command?

6

Not really. We've been busy on other things,

7

I am setting a 0 level not a 0 temperature. The second parameter is a level.

The problem is that when a remote MQTT device that is OFF reports it’s color temperature , and it does this periodically or at connection to MQTT time either by HE or device then I update the mirror virtual RGBW device locally. This triggers an undesired event from the device of ‘on’ and as there is no way of determining the origin of events on HE it looks like a command eg from RM so this gets forwarded back to the original remote device and it turns on. Color temps rarely match exactly numerically as they are rounded to numbers based on hardware capability so the color temp status updates have to applied. I can’t match against currentColorTemperature

Net effect an OFF RGBW device reports it’s color temperature and as a result gets turned on

This , which stipulates level 0 directly in the command as the second parameter is ideal for meaning the device should remain OFF .

setColorTemperature( colTemp, 0 )

An equivalent is not available for setLevel()

As Bert reminded me a similar issue happens on hue, saturation etc, I guess I can work around this by reading .currentSwitch and noting that if OFF then these updates will generate an ON event and sending that back to the original device as an OFF immediately. Then blocking the ON and the now subsequent OFF events from propagating to the ‘real, remote device

8

With the driver source published, you should be able to solve these issues for your needs.

2 Likes
9

I have modified the virtualRGBW driver to workaround my issue.

I have added capability levelPreset and added

presetLevel()
presetColor()
presetHue()
presetSaturation()
presetColorTemperature()

There is only the capability levelPreset available so most of these are just custom. I hope I've done this in the way that I expect Hubitat to implement them so that when they do get around to it my driver can just be deprecated.

I have modified the existing code within setColorTemperature() to support

setColorTemperature(colortemperature, level, transitionTime)

such that level can be 0 leaving the bulb OFF after execution which I reason is how this should work , not turning the bulb ON.

Also an HSV map received through setLevel() with the level set to 0 will leave the the device OFF rather than ON

I may need to grab some other virtual drivers to add the preset commands to but I can probably deduce a lot of them from this example.