WLED v0.13.1 does not return to default state when exiting Hyperion

[FlaMike]

I run Hyperion on a PC that can control LED strip lights running WLED. Previously, I was running WLED v .0.13.0-b6 for ESP 8266 precompiled. If the lights running were running only under WLED control, they defaulted to default color and pattern. When the PC was turned on, Hyperion took over control of the lights. When the PC was shut down, WLED regained control of the lights and the default color and pattern were restored.

When I upgraded to WLED v0.13.1 precrompiled for ESP 8266, the lights remain in the last static color pattern when the Hyperion PC is shut down (WLED does not regain control of the lights). The version of Hyperion running has not changed.

I downgraded WLED back to v0.13.0-b6 and Hyperion and WLED interact as they had previously.

[Aircoookie]

WLED expects a {"live":false} message from Hyperion to leave the live Hyperion mode. Possibly that is not sent by Hyperion when turning off the PC. Perhaps a mitigation would be for Hyperion to only send {"live":true} to enter indefinite realtime mode when it intends to display a static pattern (i.e. not refreshing data). The reason this bug didn't manifest in b6 is thay this indefinite realtime mode was not correctly entered in the first place.

[FlaMike]

Thank you for your speedy reply. I really enjoy using WLED.

I can send a note to the Hyperion folks with your suggestion. I don't know if there is anything else that I can do as a user of both of these amazing projects.

Thanks again.

[stale[bot]]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED!

[Krystm]

This issue continually pops up and is still persistent in the latest issue. I cut power to 2 of my Hyperion devices (Rasp Pis) but this hadn't been an issue for a while. A 3rd device is a Windows machine using the software and even proper shutdown does not restore the last state. I have to manually go in each time to disable the stream.

[blazoncek]

This is Hyperion thing or issue if you want. Due to the fact that Hyperion sets WLED to receive "live"/realtime data indefinitely. Normally if you exit Hyperion it should send command to WLED to exit live data mode.

[Krystm]

So there is no checks on the WLED side to see if there is still incoming data? What has me boggled is that before v13 all my instances worked fine no issue with no update or changes otherwise to Hyperion or versioning. While I do understand the flag being set on the Hyperion side, what was changed on the WLED side that caused it to recognize when devices went down?

With my Raspberry Pis there is NO chance it can send a kill / off command due to sudden loss of power. So I am inclined to believe that there is something else that was updated or potentially something was corrected and the previous behavior while was working as I wanted may have been wrong and is now working "as intended" which is not releasing the remote session. Can there be a timeout or some sort of check on the WLED side so if they don't fix it.

I'll probably just use a HA Script when Powering down devices to restart wled as that's the only fix I can think of or manually go in and override the stream that is no longer happening.

Would it be possible as a feature request to have a timeout or not seeing new data could release the stream and reset back to standalone operation?

[blazoncek]

Yes, there is a timeout but is set by Hyperion. In WLED you can only cancel current data stream.

[blazoncek]

Instead of rebooting WLED you can just send "live":false or "live":0 as a JSON API call from HA or any other external device.

As a remedy ask Hyperion developers to impose none-indefinite timeout when connecting to WLED. I.e. "live":64999. I am closing the issue as it is out of WLED scope if external app/device incorrectly set parameters. If you feel otherwise please reopen.