search

awawa-dev / HyperHDR

Highly optimized open source ambient lighting implementation based on modern digital video and audio stream analysis for Windows, macOS and Linux (x86 and Raspberry Pi / ARM).
http://www.hyperhdr.eu/
MIT License
1.05k stars 110 forks source link

HyperHDR + WLED: Turning off LEDs from HyperHDR, cannot turn them back on #90

Closed maltyjava closed 3 years ago

maltyjava commented 3 years ago

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?

awawa-dev commented 3 years ago

Are you using adalight or network driver for WLED? How many instances are configured in HyperHDR?

awawa-dev commented 3 years ago

Logs are necessary also (as whole, try to deactivate it as you described and next try to activate it again). WLED status about 'receiving data' not always is up to date and need to be refreshed. Try to F5 in webbrowser.

maltyjava commented 3 years ago

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

awawa-dev commented 3 years ago

OK, thanks. Will try to test it later. One more thing. Could you disable USB grabber & smoothing, then play the rainbow effect. And with the rainbow effect running disable and enable WLED to see if the same thing happens. That action could rule out two main components from suspected.

maltyjava commented 3 years ago

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!

awawa-dev commented 3 years ago

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.

maltyjava commented 3 years ago

Ahh exciting!! :D Thanks man, whenever you get a chance, no rush.

awawa-dev commented 3 years ago

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) https://github.com/Aircoookie/WLED/issues/1962 Could you try "Force max brightness" trick to see if it changes something?

maltyjava commented 3 years ago

Yeah that seems to fix it!

awawa-dev commented 3 years ago

Great! I consider a patch for that change in WLED API anyway so I'm leaving the issue open as 'feature request'.

maltyjava commented 3 years ago

Thanks so much for the help

pandel commented 3 years ago

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...

awawa-dev commented 3 years ago

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).

pandel commented 3 years ago

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.

pandel commented 3 years ago

@awawa-dev Does your current release make use of the new 'live' feature in WLED? It would be much more logical to notify WLED of start/end of stream instead of turning it off or on. That might sort out any problems in this regard...

see: https://github.com/Aircoookie/WLED/commit/adbeb4ae547e7874ba6bb5be150ce0ed1fd10c01 https://github.com/hyperion-project/hyperion.ng/pull/1204

awawa-dev commented 3 years ago

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.

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.

awawa-dev commented 3 years ago

@awawa-dev Does your current release make use of the new 'live' feature in WLED? It would be much more logical to notify WLED of start/end of stream instead of turning it off or on. That might sort out any problems in this regard...

see: Aircoookie/WLED@adbeb4a hyperion-project/hyperion.ng#1204

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.

pandel commented 3 years ago

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 ;-)

awawa-dev commented 3 years ago

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: https://github.com/awawa-dev/HyperHDR/tree/v16_hotfix unfortunately it needs to be build on your own as HyperHDR docker images already moved miles further and are ready for v17 (but this breaks v16 automatic builds).

pandel commented 3 years ago

@awawa-dev Man! You are fast! Many thanks for that. I will prepare a Windows 10 build env as soon as possible and will try to get it up and running. I'll post my results after that!

awawa-dev commented 3 years ago

Great! Just remember to switch to 'v16_hotfix' branch before compiling ;)

pandel commented 3 years ago

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?

awawa-dev commented 3 years ago

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.

pandel commented 3 years ago

CMakeError.log CMakeOutput.log

awawa-dev commented 3 years ago

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.

pandel commented 3 years ago 
Microsoft Windows [Version 10.0.19043.1110]
(c) Microsoft Corporation. Alle Rechte vorbehalten.

c:\Git\HyperHDR\build>set QT5_DIR=C:\Qt\5.15.0\msvc2019_64\lib\cmake\Qt5

c:\Git\HyperHDR\build>call "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.10.4
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

c:\Git\HyperHDR\build>cmake -DPLATFORM=windows -G "Visual Studio 16 2019" ..
-- CMake Version: 3.21.1
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
-- The C compiler identification is MSVC 19.29.30040.0
-- The CXX compiler identification is MSVC 19.29.30040.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CCache is not found
-- PLATFORM: windows
-- ENABLE_SPIDEV   = OFF
-- ENABLE_TINKERFORGE = OFF
-- ENABLE_V4L2 = OFF
-- ENABLE_WS281XPWM = OFF
-- ENABLE_AVAHI = OFF
-- ENABLE_USB_HID = OFF
-- ENABLE_WMF = ON
-- ENABLE_AVF = OFF
-- ENABLE_SOUNDCAPWINDOWS = ON
-- ENABLE_SOUNDCAPMACOS = OFF
-- ENABLE_SOUNDCAPLINUX = OFF
-- Current Version: 16.0.0.1
--  - Build:  (Awawa-c3fe63e/04a8c47-1627926412)
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- QT version 6 not found. Searching for QT version 5 instead.
-- Found Qt Version: 5.15.0
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp toolset variant: including SDK versions that drop XP support in search!
-- Found WindowsSDK: C:/Program Files (x86)/Windows Kits/10
-- WINDOWS SDK: C:/Program Files (x86)/Windows Kits/10 WindowsSDKDir environment variable
-- MSVC VERSION: 1929
-- Performing Test TURBOJPEG_WORKS
-- Performing Test TURBOJPEG_WORKS - Success
-- Found TurboJPEG: C:/Git/HyperHDR/resources/dll/jpeg/turbojpeg.lib
-- Using Turbo JPEG library: C:/Git/HyperHDR/resources/dll/jpeg/turbojpeg.lib
-- 7-zip found: C:/Program Files/7-Zip/7z.exe
CMake Error at dependencies/CMakeLists.txt:27 (add_subdirectory):
  The source directory

    C:/Git/HyperHDR/dependencies/external/flatbuffers

  does not contain a CMakeLists.txt file.

CMake Error at dependencies/CMakeLists.txt:35 (export):
  export given target "flatc" which is not built by this project.

-- Using flatbuffers compiler: $<TARGET_FILE:flatc>
CMake Error at dependencies/CMakeLists.txt:86 (add_subdirectory):
  add_subdirectory given source "external/protobuf/cmake" which is not an
  existing directory.

CMake Error at dependencies/CMakeLists.txt:94 (export):
  export given target "protoc" which is not built by this project.

-- Using protobuf compiler: $<TARGET_FILE:protoc>
CMake Error at dependencies/CMakeLists.txt:223 (add_subdirectory):
  The source directory

    C:/Git/HyperHDR/dependencies/external/mbedtls

  does not contain a CMakeLists.txt file.

-- Found Qt SerialPort library
-- Configuring incomplete, errors occurred!
See also "C:/Git/HyperHDR/build/CMakeFiles/CMakeOutput.log".
See also "C:/Git/HyperHDR/build/CMakeFiles/CMakeError.log".

c:\Git\HyperHDR\build>
awawa-dev commented 3 years ago

OK, submodules are not initialized. Usually git clone --recursive https://github.com/awawa-dev/HyperHDR.git .... from the instruction handles it. Probable --recursive option was not used.

But it easy to fix, hope I remember it correctly...try this from the project folder: git submodules init .... NEXT ...git submodules update

pandel commented 3 years ago

That was it! My fault, sorry, I totally overlooked the recursive param... Many thanks :-) - Compilation is running right now 👍

pandel commented 3 years ago

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

awawa-dev commented 3 years ago

Thanks for the hint :) I've added the info about cpack command but it's in a manual of developing version v17.

pandel commented 3 years ago

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!

awawa-dev commented 3 years ago

Implemented in version 17 (beta for testing). If you have some time, please test it. Reopen the issue if needed. https://github.com/awawa-dev/HyperHDR/releases/tag/v17.0.0.0beta