You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few seconds after powering off a controller with a virtual LED segment, the virtual segment turns back on by itself in bright green.
This does not occur when switching off the segment itself. It happens only when the controller with the virtual segment is powered off.
It is not rebooting and the default power on behavior is to stay off.
To Reproduce Bug
A QuinLED ESP32 connected via ethernet is running four small LED strips and also has the virtual segment (DDP RGBW). It's directly running four outputs to four strips, but configured as five segments. The virtual LED strip being the sixth.
A WT32-ETH01 (also ethernet) is physically connected to the virtualized strip and no others.
The strips are all SK6812/WS2814 RGBW with 20 or fewer LEDs/LED segments.
Expected Behavior
.
Install Method
Binary from WLED.me
What version of WLED?
Both running 0.14.3 (build 2404040)
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
No response
Anything else?
As a workaround I'm turning it off by setting the brightness to 1%. It seems to stay off when I do that.
Update:
I went into HA and added the controller physically connected to the virtual segment. I found that it was set to green, hence the bright green. When the controller with the virtual segment is shut off, the controller physically connected to that segment shuts off but then reverts back to its own settings.
I turned off the physically connected controller, then turned it on via the controller hosting the virtual segment. Now the former seems to stay off.
However, this adjustment does not survive a reboot. Furthermore, after a reboot, the physically connected segment has a brightness set to zero and does not respond at all until this is turned up again manually (changing the settings of the controller hosting the virtual segment does nothing).
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
What happened?
A few seconds after powering off a controller with a virtual LED segment, the virtual segment turns back on by itself in bright green.
This does not occur when switching off the segment itself. It happens only when the controller with the virtual segment is powered off.
It is not rebooting and the default power on behavior is to stay off.
To Reproduce Bug
A QuinLED ESP32 connected via ethernet is running four small LED strips and also has the virtual segment (DDP RGBW). It's directly running four outputs to four strips, but configured as five segments. The virtual LED strip being the sixth.
A WT32-ETH01 (also ethernet) is physically connected to the virtualized strip and no others.
The strips are all SK6812/WS2814 RGBW with 20 or fewer LEDs/LED segments.
Expected Behavior
.
Install Method
Binary from WLED.me
What version of WLED?
Both running 0.14.3 (build 2404040)
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
No response
Anything else?
As a workaround I'm turning it off by setting the brightness to 1%. It seems to stay off when I do that.
Update:
I went into HA and added the controller physically connected to the virtual segment. I found that it was set to green, hence the bright green. When the controller with the virtual segment is shut off, the controller physically connected to that segment shuts off but then reverts back to its own settings.
I turned off the physically connected controller, then turned it on via the controller hosting the virtual segment. Now the former seems to stay off.
However, this adjustment does not survive a reboot. Furthermore, after a reboot, the physically connected segment has a brightness set to zero and does not respond at all until this is turned up again manually (changing the settings of the controller hosting the virtual segment does nothing).
Code of Conduct
The text was updated successfully, but these errors were encountered: