Closed jamesw4 closed 2 years ago
Hey there @icemanch, mind taking a look at this issue as it has been labeled with an integration (flux_led
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
flux_led documentation flux_led source (message by IssueLinks)
We will need some more information about which model you are using and how the device looks in the unexpected state. Example:
Please post the model number from the devices screen
.
Please post screenshots of the light panel
as well as photos of the strip in the unexpected state
Thanks đź‘Ť
Not sure if this is related, but I just started seeing these errors on the flex_led.aioscanner after upgrading to 2021.11.1 (from 2021.10.6.
2021-11-06 12:57:39 ERROR (MainThread) [flux_led.aioscanner] LEDENETDiscovery error: [WinError 10022] An invalid argument was supplied 2021-11-06 12:57:41 ERROR (MainThread) [flux_led.aioscanner] LEDENETDiscovery error: [WinError 10022] An invalid argument was supplied 2021-11-06 12:57:42 ERROR (MainThread) [flux_led.aioscanner] LEDENETDiscovery error: [WinError 10022] An invalid argument was supplied 2021-11-06 12:58:03 ERROR (MainThread) [flux_led.aioscanner] LEDENETDiscovery error: [WinError 10022] An invalid argument was supplied 2021-11-06 12:58:06 ERROR (MainThread) [flux_led.aioscanner] LEDENETDiscovery error: [WinError 10022] An invalid argument was supplied 2021-11-06 12:58:09 ERROR (MainThread) [flux_led.aioscanner] LEDENETDiscovery error: [WinError 10022] An invalid argument was supplied
That looks like an issue with protractor asyncio so likely unrelated. If it's a supported install method, please open a new issue
I too am having this issue after 2021.11
Device screen: UFO LED WiFi Controller (0x04)
Light Panel
Lights in unexpected state. Every other LED should be off
Entity data sent : { "brightness": 255, "rgb_color": [255, 130, 30]}
Other attempts made: { "brightness": 255, "rgbw_color": [255, 130, 30, 0]} { "brightness": 255, "rgbww_color": [255, 130, 30, 0, 0]} { "brightness": 255, "rgb_color": [255, 130, 30], "white": 0}
Observation: If I update the color in the MagicHome app to 255, 130, 30 set the brightness to 100% and Warm White brightness to 0% then HomeAssistant will display brightness of 127, color brightness 100%, warm white brightness 0%. If I try to call light.turn_on with those values it will do a mix of brightness and warm white brightness instead
edits: fixed typos
The main brightness slider represents white brightness + rgb brightness.
AFAICT, This looks like it's working as designed.
icemanch is much more familiar with this topic so let's wait for him to weigh in.
After tinkering around today yes it does look like a change of functionality in 2021.11 for these controllers.
I was able to make { "brightness": 128, "rgbw_color": [255, 130, 30, 0]} work and produce the same results { "brightness": 255, "rgb_color": [255, 130, 30]} achieved in prior versions.
I've been able to update my automations to handle a time based transition that has never worked on these for the updated brightness values.
To be honest I downgraded back to last version that worked for me. Will try again today.
How I had my automation before was it would just change colour brightness (via brightness attribute) during different conditions, I could freely change the colour and it would remain that colour and automation change brightness only. I’m not sure this is possible with these changes as doesn’t look like I can pass colour brightness to the light service.
@jamesw4
Sorry, for taking so long to get to this. I have another broken-down car I have to get back up running. Anyways.
This is working as intended. The main brightness controls all channels and will adjust them all up or down as you move it. To control a single channel you use either the white or the color channel.
I think there are three options here.
You can also change the color mode in the customization menu.
No worries. I’ve managed to work around it with the info from @alertrenegade.
I couldn’t find anywhere in the magichome app to change anything regarding what type of controller it was. I did try customising the entity in home assistant but it still ends up controlling the brightness of the white channel. Happy to crack on with the work around and will keep an eye to see if anything else can be done.
Thanks all
I tested this with the RGB/W setting (behaving like it did in earlier versions) and the RGB&W setting (behaving as described in this issue), and confirmed its working as designed.
3. Wait for me to add an option to change the bulb type in the API and then in HomeAssistant too. I've started working on this but, it's not ready yet. I think I'll have it finished by 28th since I'm on vacation from work the week of thanksgiving.
Changing the type to RGB/W in the Magic Home App is probably the best option to get the behavior you are looking for without the workaround.
I don't think there is anything to be done here so I'm going to close out this issue.
@bdraco - am I being stupid here, where can the type be changed in the magic home app? All I seem to be able to change is the device name and remote access settings. Thanks.
Long press and hit change led strip type
The problem
Just upgraded to core-2021.11.0.
My RGBW Magic Home devices are now acting strange with the flex led component.
Brightness is now controlling the colour leds and the white leds. As such can barely see any colour now when changing brightness as the white is overpowering the colour.
What version of Home Assistant Core has the issue?
core-2021.11.0
What was the last working version of Home Assistant Core?
core-2021.10.4
What type of installation are you running?
Home Assistant OS
Integration causing the issue
FluxLED
Link to integration documentation on our website
https://www.home-assistant.io/integrations/flux_led/
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response