Restore previous state after disconnecting hyperion.ng

[BeMacized]

Is your feature request related to a problem? Please describe.

Currently, when hyperion "disconnects" from WLED (for example, by turning hyperion off through its home assistant integration), the lights controlled by WLED are always turned off.

Because of this, I run into an issue when using hyperion and wled with scenes in home assistant:
When the scene turns off hyperion but turns on the wled light, the wled light often still turns off anyways.

Describe the solution you'd like
An option for WLED to resume its previous state after hyperion disconnects.

Describe alternatives you've considered
I set up a workaround with an automation that turns on the WLED led strip when it detects hyperion being turned off.

Additional context
I use a NodeMCU with WLED flashed to it, with home assistant and hyperion both running together in a VM.

[ProtoxiDe22]

Dropping in to follow and say that i'm looking for this too :) In the meantime would you share the details of your workaround?

[BeMacized]

@ProtoxiDe22 It's an automation in node-red that gets triggered by home assistant when a. hyperion is turned off, and b. the wled strip is still on while it happens. When this occurs, it tells home assistant to turn on the wled strip (even though it is already on). There is just enough delay for this to happen right after wled turns off the ledstrip, so that it turns back on. I'd imagine you wouldn't need node-red for it though, you could probably do the same with a home assistant automation alone.

[Aircoookie]

Interesting, thank you for the report!

WLED should not turn off after the Hyperion.ng stream ends, instead it should resume whatever state it had before the stream started.
Could it be that there is an automation configured that turns WLED off before or during receiving data from Hyperion?

[ProtoxiDe22]

@Aircoookie it happened to me with a brand new installation of both wled and hyperion, no special settings. I haven't checked that explicitly, but it might be that hyperion purposedly turns off the led strip? After i close hyperion on the computer, wled reports the status as "off"

[Aircoookie]

You can try disabling the three checkmarks Receive Brightness, Color, and Effects in the WLED broadcast section of Sync settings and rebooting. Perhaps WLED mistakes some hyperion data packet for a WLED sync packet and turns itself off.
Shouldn't be possible as it is a different network port, but it is the only reasonable hunch I have about this behavior...
What device config are you using in Hyperion.ng by the way? UDP 0 on port 19446?

[ProtoxiDe22]

Will do some testing tomorrow and report back, I'm just using the default hyperion config when you select wled as the led hardware

[Aircoookie]

Just looked into it and they indeed have a device type for WLED now which even interfaces with my JSON API and has the ability to turn off the device: https://github.com/hyperion-project/hyperion.ng/blob/efc2046ab561a04cfff703b54cbb67ee15c6ed21/libsrc/leddevice/dev_net/LedDeviceWled.cpp#L148

Seems like the HyperionNG devs thought it would be a good idea to turn WLED off when turning the stream off (which it can be depending on your use case!), but maybe you need to open an issue with the HyperionNG repo as it is nothing I can change on the WLED side :) Maybe the power behavior is user configurable somehow.

[ProtoxiDe22]

As suspected, it is hyperion that implemented something that explicitly turns off the led strip when the program is shut down, it's easy to verify this because if you terminate hyperion forcedly (eg via task manager) this behaviour does not occur, unfortunately this does not seems configurable on hyperion side.
Nonetheless, this is a problem (feature?) on the hyperion side of things, not WLED's

EDIT: i submitted this to hyperion-project/hyperion.ng#1095

[ProtoxiDe22]

However, i'm also noticing that if WLED was off when hyperion is opened, and then you close hyperion this way, WLED will now be on, and won't remeber it's previous state. i don't know if that's really possible (you would need to be able to know that WLED was turned on by Hyperion), but maybe it would be nice to add this?

[Aircoookie]

That is to be expected, since the Hyperion code will likely also set an on command when beginning the stream, thus changing the WLED state to on. That could be quite handy if you don't want to turn on WLED manually (It will only turn on automatically if the Force max bri option in sync settings is enabled) but it should do it in a way that restores the previous state after the stream is finished.

Pseudocode for that would be:

bool wledPreviousState = device.getOnOffState(); //"on" from json/state
if (!wledPreviousState) device.turnOn();
stream();
[...]
endStream();
if (!wledPreviousState) device.turnOff();

The best option would really be to have a config option to be able to choose between this behavior, the current "turn on always, turn off always" behavior, and not using the WLED API at all (although you could probably achieve that by configuring the device with the "traditional" UDP type 0 protocol on port 19446)

[ProtoxiDe22]

Thanks, i hoped this could be also done from WLED side, but as i suspected, it's not really possible, sice WLED doesn't know the "reason" it was turned on in the first place, in this case i'll add this suggestion to the Hyperion issue

edit: nevermind, you already did that, thanks!

[BeMacized]

Thank you both for figuring it out so quickly!
I can indeed confirm that this only happens when using the wled device config in hyperion.
Having switched it to udpraw instead, it behaves the way I would expect it to, restoring the state after hyperion is turned off.

[Lord-Grey]

@Aircoookie Thanks for bringing this up.
The hyperion LED-device protocol already considers storing & restoring state in general, but it has not been implemented for WLED yet.

This is a good opportunity to tackle it now and the behaviour will be configurable as for other devices.

As a start, I am storing the full "state json" before hyperion start streaming (WLED is on displaying a color):

2020-11-17T10:15:22.407 hyperiond LEDDEVICE    : <DEBUG> LedDeviceWled.cpp:198:storeState() | state: [{"bri":128,"ccnf":{"max":5,"min":1,"time":12},"lor":0,"mainseg":0,"nl":{"dur":60,"fade":true,"mode":1,"on":false,"tbri":0},"on":true,"pl":-1,"ps":-1,"pss":1,"seg":[{"bri":255,"col":[[3,108,255],[0,0,0],[0,0,0]],"fx":0,"grp":1,"id":0,"ix":128,"len":24,"mi":false,"on":true,"pal":0,"rev":false,"sel":true,"spc":0,"start":0,"stop":24,"sx":128}],"transition":7,"udpn":{"recv":true,"send":false}}]

when restoring the state is required after streaming, I was under the assumption that I could just "play-back" the state json and WLED acts on it....
I perfectly get an API-Success, but WLED does not react on the command.

2020-11-17T10:15:24.025 hyperiond LEDDEVICE    : <DEBUG> ProviderRestApi.cpp:150:put() | PUT: [http://wled-00581d/json/state] [{"bri":128,"ccnf":{"max":5,"min":1,"time":12},"lor":0,"mainseg":0,"nl":{"dur":60,"fade":true,"mode":1,"on":false,"tbri":0},"on":true,"pl":-1,"ps":-1,"pss":1,"seg":[{"bri":255,"col":[[3,108,255],[0,0,0],[0,0,0]],"fx":0,"grp":1,"id":0,"ix":128,"len":24,"mi":false,"on":true,"pal":0,"rev":false,"sel":true,"spc":0,"start":0,"stop":24,"sx":128}],"transition":7,"udpn":{"recv":true,"send":false}}]
2020-11-17T10:15:24.150 hyperiond LEDDEVICE    : <DEBUG> ProviderRestApi.cpp:179:getResponse() | Reply.httpStatusCode [200]

plus WLED stays in "WLED is receiving live hyperion data" mode, even if streaming stopped.
This might be due to the fact I set "Timeout: 65000 ms" to overcome that WLED turn orange in scenes without updates for a longer period (we discussed this "issue" before).

Further testing showed, that when I sent a "pure"power-off before restoring the state, it perfectly works.
If I sent a "pure" power-on before the command it does not.

It looks like that when sending a power-on state, WLED ignores the update as it is already on.

Is there any other command that would tell WLED to disable realtime streaming immediatly and I can restore the overall state successfully?
In case you store the overall state before streaming, I am happy to send selected commands only, if that helps.
(Just playing-back the json looked appealing).

Thank you!

Ping me, if you have further questions.