I need to mirror a Virtual RGBW Light with another RGBW light. I tried to use the Mirror app, but it fails to listen to change events for several critical events for RBGW lights.
The Master Bedroom Light is my "Virtual RGBW Light" device, and Master Bedroom Ceiling Light is the physical light.
As soon as I select the source device (Master Bedroom Light) RGB, color, colorName, colorMode are all turned off. When I select the target devices (which implements all the capabilities for these command) they stay off.
This is a problem, because I need the Virtual RGBW Light as my control for the physical lights, due to a defective wall dimmer, and behavior issues with Alexa, in order for my motion lighting, alexa lighting, and dimmer scene controller to work the way my old dimmer setup did.
All of the events being ignored aren't required for mirror replicas to work properly.
All of those events are generated on the replica device based on the events that are forwarded from the primary device.
What device and driver is the replica?, and what commands being sent from the primary are not being sent to the replica?
Trying to understand this. So, since colorMode is not sent, the target device should assume if an RGB event is sent, to switch to colorMode RGB, and if a colorTemp is sent, to switch to colorMode CT? I understand colorName is an attribute without a command, and RGB is used by most devices (if any). I am not sure what "color" events are, so I won't even bother digesting that one. But since the target device in my case is not receiving the change from CT to RGB, it sounds like my target device driver needs to be updated to assume any HUE, or Saturation changes are assumed to be a change to color mode over to RGB.
Correct? If so, this is my own code in the target device, and I can make that happen.
Thanks for the reply. I will tinker with it and see if that is all I needed to do.
RGB isnt supported as a color command at this time.
A primary device of type rgbw will be commanded to setLevel, setColor, setHue, setColorTemperature and on off.
setColor can set hue, saturation and level at the same time.
In response to colorTemperature event a setColorTemperature command is generated and forwarded, the replica device will then honor that request and change colorMode if required, and update the color name ect.
In a similar way setColor, setHue and setSaturation commands are generated and forwarded, the replica device then sets its own color name and changes mode if required...
There are no commands for changing colorMode or changing colorNames as these are driver generated based on commands being sent.
It probably would make more sense for the app to say commands forwarded as opposed to events...
The app subscribes to events from the primary device, converts these to the corresponding commands which are executed on the replica devices
Thank you again for the response. Very thorough and informative. I tracked down the issue. My driver is talking to hue, and hue used to take color mode as an argument even though it wasn’t documented as a set table value. It no longer accepts it and that is why my issue was occurring.
It was not your problem and I really should have fully tested that all my stuff was still working without that new app instance in place. I never change colors in that room, so I didn’t realize this is a new problem. And down stairs where I do change colors via Alexa, I just assumed it was Alexa acting up, because it has been problematic lately.
Anyways, I will patch my code. Thanks.
yup. It's all working again. I thought it was the rule, but it was Hue hub that changed behavior. And it was my fault, as I was using an unsupported attribute that it was accepting before. Thanks again.
