-
-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HyperHDR + WLED: Turning off LEDs from HyperHDR, cannot turn them back on #90
Comments
Are you using adalight or network driver for WLED? How many instances are configured in HyperHDR? |
Logs are necessary also (as whole, try to deactivate it as you described and next try to activate it again). |
Network WLED, only one instance. Here is a log: I rebooted HyperHDR, then rebooted WLED to get the lights back on. Then I used the 'Led device' switch, lights went off, but did not come back on when I reenabled the switch. I then did the same with the USB grabber. Still no lights. Then I rebooted WLED (which still says receiving data even after a refresh) to get the lights back |
OK, thanks. Will try to test it later. |
Same thing, even with smoothing and grabber disabled. Also in case it's relevant, even when I press the override button on WLED, the LEDs still won't turn on without a reboot. Tried changing colour/brightness/effects...nothing works. Thanks for your help....much appreciated! |
Yes, it's an important information. Seems like WLED hangs, maybe it's related to particular ESP hardware or it's a WLED misconfiguration or a software bug. Anyway I'll test the scenario with my setup. But first must downgrade from testing v17 ;) I'll let you know. |
Ahh exciting!! :D Thanks man, whenever you get a chance, no rush. |
I found something: one change made for hyperion ng could break backward compatibility in some strange way (should not hang WLED command interface anyway, WLED 11 and above) |
Yeah that seems to fix it! |
Great! I consider a patch for that change in WLED API anyway so I'm leaving the issue open as 'feature request'. |
Thanks so much for the help |
Hi! Just wanted to add to this that not only a reboot of WLED can turn the LEDs back on, also 3 to 6 times on-off-cycle in the WLED app or on the WLED web page can achieve the same, at least in my setup (Wemos D1 mini). For me the "force brightness trick" is no solution because I am using WLED not only for HyperHDR and I have to be able to control brightness from WLED also... |
Didn't have time to test it yet as I use HyperSerialESp8266 not WLED, but ' override' mode in WLED should bring the control to the WLED application...and even if HyperHDR turned off the LED controlled by the WLED earlier, should not matter in the 'override' mode and manipulating the brightness from the WLED page should bring them online. On/off WLED can be considered as another workaround but it seems something is not working as it should and the WLED hangs when the old style API protocol is used (even at some point). |
I'll try 'override' mode next time to test it. Sadly, manipulating the brightness only did not have any effect. Something else must happen whenever HyperHDR sends its LED-off command via URL... I thought about doing the same manually to see how WLED reacts... BTW, your HyperSerialWLED is the same as official WLED, only that I could attach a USB cable to the controller and run everything via AWA protocol, right? Perhaps this could sort out that problem... not my preferred way of doing it, because I'd like to use Wifi for the connection, but for a single test it might be worth trying. |
@awawa-dev see: |
With HyperSerialWLED use can use both Wifi and 2Mb serial port via USB. Only slow adalight driver 115kb is replaced with 2Mb Awa protocol: the rest works like standard WLED application. |
I was thinking the same about the 'live' property. But the promise was that it won't cause any sideeffects for WLED backward compatibility. Anyway, must test it first to confirm the problem. |
You could introduce a single config parameter for WLED so that the user can choose between HyperHDR using the 'live' property or (legacy) power state. So one can decide what works better... or, even more user friendly, check if you get HTTP 200 when using 'live' option and if not, use power instead ;-) |
I'm afraid we have no choice but to hardcode it :/ If the backward compatibility is broken that parameter would be useful only for persons who use WLED 0.10 and below. Imagine supporting all the problems related to that question if someone accidentally turned it off ;) Beside it seems that 'live' implementation in Hyperion ng still working with 'turning off' the led lamp, it's just additional parameter: without it WLED starts to behave unpredictable. Optional additional 'state saving' could be autodetected on the other hand. I have prepared a test patch: |
@awawa-dev |
Great! Just remember to switch to 'v16_hotfix' branch before compiling ;) |
Sadly, I get a pthreads.h not found error during cmake phase and I am not familiar enough with C++ on Windows to sort out this error. Do you have any idea? |
pthreads.h is not required, in fact my cmake doesn't find it either. Maybe something else is missing? Paste full log from cmake please. |
OK, thanks. pthread doesnt seem to be a problem: it's a standard "try to include/build something and see if it succeed" procedure in the cmake configuration phase. Please delete CMakeCache.txt from the build folder and run the configuration again: this time from windows 'cmd' terminal and paste the logs from that terminal. |
|
OK, submodules are not initialized. Usually But it easy to fix, hope I remember it correctly...try this from the project folder: |
That was it! My fault, sorry, I totally overlooked the recursive param... Many thanks :-) - Compilation is running right now 👍 |
A small hint regarding the Compilation Howto: perhaps you can add a hint that it is necessary to add '--target package' to the build command, if one would like to create the installer ;-) - I had to dig into the CI files for Hyperion_NG to find the answer :D |
Thanks for the hint :) I've added the info about |
Many thanks for the hotfix! It is working perfectly well! HyperHDR is able to turn WLED off after signal loss and it starts again, when the signal is back! 'Live' option did the trick! |
- upgrade Bootstrap from version 3 to 5 - replace and update most of UI components - software screen grabbers (Windows:DirectX11 / Linux:X11 / macOS:CoreGraphics) #46 - HDR available as a global component - automatic signal detection with learning capability - reimplemented backup import / export function for all instances' settings - current video stream information in the 'overview' tab - support for my new HyperSPI project (https://github.com/awawa-dev/HyperSPI) with awa_spi LED driver - new video stream crop method in JSON API - JSON API documentation in a form of live playground in 'Advanced' tab - LED grouping aka PC mode aka gradient mode - add timeout for the anti-flickering filter - translation resources are updated - new panel for easy video resolution & refresh mode selection - add release for AARCH64 architecture #68 - fix for WLED new network protocol #90 - fix missing Linux taskbar icon - support for libCEC 6.0.2 to turn on/off video & system grabber - support for libCEC to turn on/off HDR tone mapping with remote buttons - compatibility with QT6.2 (tested with the preview version/Vulkan/Windows) - lower CPU usage when automatic signal detection triggers 'nosignal' ('save resources' for software framerate decimation) #93 - standardize libJPEG-turbo library (where it's necessary) - fix values premature clipping in the LUT generator & SDR preview rendering fix, access available now from the menu ('Advanced' tab) - suppress most of external components' warning while building - faster image to LED colors transformation - import 'sparks' and 'system shutdown' effects to the new effect API #75 - better logging with instances' indexes - fix power saving issue with macOS port - fix memory leaks in SPI drivers
Implemented in version 17 (beta for testing). |
With WLED, I've got an issue with toggling the LEDs. If I turn off the LEDs from within HyperHDR, using the 'Led device;' toggle in the remote settings, I cannot then turn the LEDs back on using the same toggle. The same thing happens if I turn off the USB capture....lights go off but then do not come back on when reenabled.
Rebooting WLED gets the lights back on. Weirdly when you go into WLED during the issue it will still say that it's receiving data from HyperHDR. The grabber still outputs an image. Basically everything seems completely normal, except the LEDs.
I've tried both your HyperSerialWled version and normal WLED, same thing happens on both. Is there something I'm missing?
The text was updated successfully, but these errors were encountered: