Turning on LEEDEVICE, when it's already on, should not change output behavior #967
Closed
1 task done
Assignees
Labels
Comments
|
@dermotduffy Please share a Debug log of hyperion that we can follow what is happening on hyperion side. |
|
Hyperion UI before (note LEDDEVICE on):
WLED correctly receiving data from Hyperion:
Turn LEDDEVICE on: WLED stops receiving data from Hyperion:
Logs:
Relevant section: Larger log (all available in UI): |
Lord-Grey
added
needs investigation
|
@dermotduffy Would you mind redoing the test again, please? I do see that you disabled and enabled the device But you did not provide anything after 18:41:13 that shows that an active device switch has happened. If it is the latter, then nothing can be done about it, given that this device works via UDP and hyperion will not recognise the unavailability of WLED. To continue the stream you would need to disable the device (manually or via API) and enable it afterwards. |
|
I tested again, same results. But perhaps this is incorrect expectations on my end, and I don't quite follow what you mean in your last paragraph In this test, I do not touch WLED. It is available throughout, and I do not interact with it at all beyond watching the output.
My expectation is that the WLED will continue to show that same color after the last API call (as semantically the API call should not have changed anything). |
Thanks for confirming. I was looking for that. Just to validate that I got the test result right. "Step 4: API call to turn LEDDEVICE on" -> and then the WLED does what ? Turning off ? Flicker? Would you mind sharing the log output after you send the API call to turn on the LED-device which is already enabled? In case you test #968 with PR #960, could you test this scenario too? |
|
After step 4, WLED goes back to it's non-Hyperion mode (it drops the "WLED is receiving live Hyperion data..." banner) and just goes back to whatever WLED's last setting was. For example, in the screenshot I included earlier, it just goes back to showing solid red which was the prior color set in the native WLED interface (Hyperion had been sending green). Yes -- happy to test this also against your PR! |
|
As said before, I do not know how WLED react or can be configured.... as I lack a device myself (until now). In case, Smoothing is off: If you set a Color in Hyperion (e.g. green) then there will be one! update send to the device. Depending on WLED's behaviour, it may drop the "receiving hyperion data" banner, if no updates were received in a given timespan. That would explain the situation which is perfectly fine from my perspective. Depending on the Smoothing timing you might also run in the same situation. For me it looks like that WLED does some independent actions which you see the effects on.... |
|
WLED config Timeout | 100..65000 | Time after which to resume normal mode once stream has stopped Looks like that config item is causing your behaviour seen... |
|
If it was a WLED timeout issue, then I would expect to see this behavior all the time (e.g. put up a Hyperion color, wait, then it should eventually disappear). However, I don't (at least not within any timeframe I've noticed) -- however I immediately see this behavior after the API command on the Hyperion side. Thus, it really does not seem like this is an issue with a WLED timeout ... Going to try the new build now... |
|
New build shows the same (IMO: broken) behavior.
... WLED resets immediately, losing the Hyperion banner and returns to its native settings. |
|
Toobad. Seems i need to get hold of a WLED myself... |
|
@Lord-Grey Happy to share whatever you think might be useful -- just let me know? Here's the latest failed test run: If there's anything else I can share, definitely let me know... |
|
@dermotduffy I got hold of a WLED device myself now. For the static color update in hyperion only one update is sent (as normally the devices hold that color). To overcome the WLED fallback behavior, please set the timeout = 65000 ms. (see https://github.com/Aircoookie/WLED/wiki/Settings) Would you mind testing with the timeout parameter and report back, please? |
|
@Lord-Grey Firstly, thank you continuing to investigate this issue, or misunderstanding. Without touching the API, with the timeout parameter at the default 2500ms, I can set a color in Hyperion and it will 'hold' on WLED indefinitely. If Hyperion only sends a single color update, why does WLED hold it (far longer) than 2500ms by default? Regardless, the moment I send the API command to turn on LEDDEVICE (when it is already on), WLED will immediately reset. In my view, this is a fundamentally surprising behaviour. Turning something on, that is already on, should have no observable impact -- and this is demonstrably not the case. Are you able to reproduce this effect? Now, to the timeout value: If I set it to 65000ms, I confirm I do NOT observe this behaviour. The hold of color that WLED had appears to 'stick' despite the LEDDEVICE API call. ... but that honestly feels besides the point of this bug: setting something to 'on', that is already 'on', should not be able to cause any observable impact regardless of any settings for anything outside of Hyperion, i.e. why is there not a check in the API code to take no action when LEDDEVICE is already on, and discard the API call? If truly no action was taken by Hyperion, then WLED would not reset (regardless of its timeout value). |
|
@dermotduffy The observation is not linked to the API usage. This is just a co-incidence. In case you enable a device which is already enabled, the request is ignored. |
I do not. An experiment I just performed: Run 1:
Run 2:
Thank you for the code, I agree that appears like it should cope with this situation, so I cannot explain what's going on here. Would you mind repeat the above experiment on your side with your WLED device and see what behavior you get? |
|
@dermotduffy Thanks for the update. Could you test with smoothing off? I will further investigate what happens when smoothing is on and the API call. |
|
I can reproduce with smoothing on and the device enablement trigger. The situation is due to the fact that the Smoothing ColorQueue is cleared on a LED-Device update which makes WLED there is no stream any longer. I need to think about it.... Thanks for your patience. PS: Nevertheless, the WLED Timeout should be set to 65000 disabling the stream timeout detection. |
|
Aha. Yes, it's smoothing related! If I disable smoothing, then the WLED timeout actually behaves as I would have expected (i.e. 2500ms only holds the color for 2.5ms, 10000ms holds it for 10s, etc). My smoothing config:
It is presumably the 'Continuous output' option that is causing it to appear to 'bypass' the WLED timeout, and the code snippet you found that causes it 'reset' upon LED device change. Phew -- thank you for getting to the bottom of this! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report
Turning on the component LEDDEVICE via the API, when the LEDDEVICE is already on, should not result in any noticeable output behavior. However, it appears to 'reset' the connection to WLED causing WLED to stop showing streamed UDP data. I don't know if this is specific to WLED, or a more general issue.
Steps to reproduce
What is expected?
No change should be observed.
What is actually happening?
WLED appears to lose the "connection" to Hyperion, and resets to it's state to that prior to streaming the data from Hyperion.
System
Fresh build from head yesterday.
Hyperion Server:
Hyperion Server OS:
The text was updated successfully, but these errors were encountered: