Adafruit ESP32 - Could not detect HyperSerialEsp8266/HyperSerialESP32 device

[stickmanbrad]

Heya,

Apologies if this is the incorrect place to send over this query. I've just swapped out my ESP-WROOM-32E for an ESP-WROOM-32 assuming I could get the baud rate of '2000000'. On the first boot up funnily enough the logs mentioned the whole 'DETECTED DEVICE USING HyperSerialEsp8266/HyperSerialESP32 FIRMWARE', but after an additional reboot (and any subsequent) its now not (logs below). The led's still work fine and other than the expected error message it all works. I just wondered why it would of said it the first time round but then decide its not happy with it afterwards?

Below is the current logs after the latest reboot. Unsure if I need to purchase another ESP32 or not.

Kind regards in advanced for all your help.

I also performed a video benchmark with following results:

Perfect minimal latency (related to FPS):: 16.67ms Average measured latency:: 58.89ms

Internal latency: 13.44ms

Logs starting:

2023-01-18T20:22:28.140Z [LEDDEVICE_ADALIGHT] Received: '� Welcome! Awa driver 8. NeoPixelBus SK6812 cold GRBW.

RGBW => Gain: 255/255, red: 160 , green: 160 , blue: 160' (117) 2023-01-18T20:22:28.141Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:106) Close UART: ttyACM0 2023-01-18T20:22:28.228Z [EFFECTENGINE0] (EffectEngine.cpp:174) Start the effect: name [Rainbow swirl fast], smoothCfg [2] 2023-01-18T20:22:28.228Z [MUXER0] Register new input 'System/EFFECT' with priority 0 as inactive 2023-01-18T20:22:28.228Z [HYPERHDR] Initial foreground effect 'Rainbow swirl fast' started 2023-01-18T20:22:28.228Z [SMOOTHING0] Using alternative smoothing input (0) 2023-01-18T20:22:28.229Z [COMPONENTREG0] LED device: disabled 2023-01-18T20:22:28.283Z [MUXER0] Set visible priority to 0 2023-01-18T20:22:28.283Z [HYPERHDR0] New priority[0], previous [255] 2023-01-18T20:22:28.283Z [HYPERHDR0] New source available -> switch LED-Device on 2023-01-18T20:22:28.283Z [SMOOTHING0] Clearing queued colors before: enabling 2023-01-18T20:22:28.283Z [SMOOTHING0] Smoothing queue is cleared 2023-01-18T20:22:28.284Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:102) Enable device 2023-01-18T20:22:28.284Z [LEDDEVICE_ADALIGHT] Opening UART: ttyACM0 2023-01-18T20:22:28.284Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:183) _rs232Port.open(QIODevice::ReadWrite): ttyACM0, Baud rate [2000000]bps 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:188) portName: ttyACM0 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:189) systemLocation: /dev/ttyACM0 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:190) description: USB Single Serial 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:191) manufacturer: 1a86 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:192) productIdentifier: 0x55d4 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:193) vendorIdentifier: 0x1a86 2023-01-18T20:22:28.323Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:194) serialNumber: 537E053428 2023-01-18T20:22:28.344Z [EFFECT0(Rainbo...)] Begin playing the effect with priority: 0 2023-01-18T20:22:28.580Z [LEDDEVICE_ADALIGHT] Could not detect HyperSerialEsp8266/HyperSerialESP32 device 2023-01-18T20:22:28.580Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:329) Switch on 2023-01-18T20:22:28.581Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:405) Power On 2023-01-18T20:22:28.581Z [MUXER0] Priority 0 is now active 2023-01-18T20:22:28.581Z [COMPONENTREG0] LED device: enabled 2023-01-18T20:22:28.582Z [SMOOTHING0] Clearing queued colors before: enabling. Smoothing configuration changed: restarting timer. 2023-01-18T20:22:28.582Z [SMOOTHING0] Smoothing queue is cleared 2023-01-18T20:22:28.582Z [SMOOTHING0] Selecting config (2) => type: Linear, dirMode: false, pause: false, settlingTime: 200ms, interval: 40ms (25Hz), antiFlickTres: 0, antiFlickStep: 0, antiFlickTime: 0 2023-01-18T20:22:28.582Z [SMOOTHING0] Using linear smoothing input (2)

Logs Finished

[awawa-dev]

Did you finally update to version from the release page? Because symptoms from other your thread sugestts you are using older version: https://github.com/awawa-dev/HyperHDR/releases/tag/v19.0.0.0beta2

[stickmanbrad]

Did you finally update to version from the release page? Because symptoms from other your thread sugestts you are using older version: https://github.com/awawa-dev/HyperHDR/releases/tag/v19.0.0.0beta2

Hiya,

Yes I can confirm I am using the latest and greatest version.

So one thing which puzzles me, is that in the last 10 minutes it's now working. There was one thing I changed in the config.txt file in /boot.

dtparam=audio=off

to

dtparam=audio=on

I had disabled this while troubleshooting after the flickering issue a week ago. Is it at all possible this would of caused this issue? Because now after two reboots (testing), I get the following log - much better :-):

Logs starting:

2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:188) portName: ttyACM0 2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:189) systemLocation: /dev/ttyACM0 2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:190) description: USB Single Serial 2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:191) manufacturer: 1a86 2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:192) productIdentifier: 0x55d4 2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:193) vendorIdentifier: 0x1a86 2023-01-18T20:48:20.167Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:194) serialNumber: 537E053428 2023-01-18T20:48:20.389Z [MUXER0] Set visible priority to 255 2023-01-18T20:48:20.389Z [HYPERHDR0] New priority[255], previous [255] 2023-01-18T20:48:20.389Z [HYPERHDR0] No source left -> switch LED-Device off 2023-01-18T20:48:20.389Z [SMOOTHING0] Clearing queued colors before: disabling 2023-01-18T20:48:20.389Z [SMOOTHING0] Smoothing queue is cleared 2023-01-18T20:48:20.462Z [LEDDEVICE_ADALIGHT] DETECTED DEVICE USING HYPERSERIALESP8266/HYPERSERIALESP32 FIRMWARE (Welcome! Awa driver 8. NeoPixelBus SK6812 cold GRBW. RGBW => Gain: 255/255, red: 160 , green: 160 , blue: 160) at 39 msec 2023-01-18T20:48:20.462Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:329) Switch on 2023-01-18T20:48:20.462Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:405) Power On 2023-01-18T20:48:20.463Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:138) Disable device 2023-01-18T20:48:20.463Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:355) Switch off 2023-01-18T20:48:20.463Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:313) Set LED strip to black/power off 2023-01-18T20:48:20.469Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:123) Flush was successful 2023-01-18T20:48:20.470Z [COMPONENTREG0] LED device: enabled 2023-01-18T20:48:20.471Z [EFFECTENGINE0] Run effect "Rainbow swirl fast" on channel 0 2023-01-18T20:48:20.593Z [EFFECTENGINE0] (EffectEngine.cpp:174) Start the effect: name [Rainbow swirl fast], smoothCfg [2] 2023-01-18T20:48:20.594Z [MUXER0] Register new input 'System/EFFECT' with priority 0 as inactive 2023-01-18T20:48:20.594Z [HYPERHDR] Initial foreground effect 'Rainbow swirl fast' started 2023-01-18T20:48:20.594Z [SMOOTHING0] Using alternative smoothing input (0) 2023-01-18T20:48:20.594Z [COMPONENTREG0] LED device: disabled 2023-01-18T20:48:20.650Z [MUXER0] Set visible priority to 0 2023-01-18T20:48:20.651Z [HYPERHDR0] New priority[0], previous [255] 2023-01-18T20:48:20.651Z [HYPERHDR0] New source available -> switch LED-Device on 2023-01-18T20:48:20.651Z [SMOOTHING0] Clearing queued colors before: enabling 2023-01-18T20:48:20.651Z [SMOOTHING0] Smoothing queue is cleared 2023-01-18T20:48:20.651Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:102) Enable device 2023-01-18T20:48:20.651Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:329) Switch on 2023-01-18T20:48:20.651Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:405) Power On 2023-01-18T20:48:20.652Z [COMPONENTREG0] LED device: enabled 2023-01-18T20:48:20.652Z [SMOOTHING0] Clearing queued colors before: enabling. Smoothing configuration changed: restarting timer. 2023-01-18T20:48:20.652Z [SMOOTHING0] Smoothing queue is cleared 2023-01-18T20:48:20.652Z [SMOOTHING0] Selecting config (2) => type: Linear, dirMode: false, pause: false, settlingTime: 200ms, interval: 40ms (25Hz), antiFlickTres: 0, antiFlickStep: 0, antiFlickTime: 0 2023-01-18T20:48:20.652Z [SMOOTHING0] Using linear smoothing input (2) 2023-01-18T20:48:20.692Z [SMOOTHING0] Using linear smoothing procedure (2) 2023-01-18T20:48:20.721Z [EFFECT0(Rainbo...)] Begin playing the effect with priority: 0 2023-01-18T20:48:20.784Z [MUXER0] Priority 0 is now active 2023-01-18T20:48:20.785Z [IMAGETOLED0] Total index number is: 1000 (memory: 1000). User sparse processing is: disabled, image size: 80 x 45, area number: 217 2023-01-18T20:48:21.306Z [WEBSERVER] Initialize Webserver 2023-01-18T20:48:21.307Z [WEBSERVER] Initialize Webserver 2023-01-18T20:48:21.346Z [V4L2:USB3.0 HD VIDE] (V4L2Grabber.cpp:1157) Worker's thread count = 4 2023-01-18T20:48:21.376Z [V4L2:USB3.0 HD Vide] Detected the video frame size changed (1280x720). Cache buffer was cleared. 2023-01-18T20:48:21.376Z [MUXER0] Priority 240 is now active 2023-01-18T20:48:21.406Z [WEBSERVER] Apply Webserver settings 2023-01-18T20:48:21.406Z [WEBSERVER] Apply Webserver settings 2023-01-18T20:48:21.406Z [WEBSERVER] Set document root to: :/webconfig 2023-01-18T20:48:21.406Z [WEBSERVER] Set document root to: :/webconfig 2023-01-18T20:48:21.407Z [WEBSERVER] Started on port 8090 name 'HyperHDR Webserver' 2023-01-18T20:48:21.429Z [WEBSERVER] Setup SSL certificate 2023-01-18T20:48:21.430Z [WEBSERVER] Setup private SSL key 2023-01-18T20:48:21.430Z [WEBSERVER] Started on port 8092 name 'HyperHDR Webserver' 2023-01-18T20:48:23.727Z [EFFECT0(Rainbo...)] The effect quits with priority: 0 2023-01-18T20:48:23.727Z [MUXER0] Removed source priority 0 2023-01-18T20:48:23.727Z [MUXER0] Set visible priority to 240 2023-01-18T20:48:23.727Z [SMOOTHING0] Clearing queued colors before: enabling. Smoothing configuration changed: restarting timer. 2023-01-18T20:48:23.727Z [SMOOTHING0] Smoothing queue is cleared 2023-01-18T20:48:23.727Z [SMOOTHING0] Selecting config (0) => type: Alternative, dirMode: false, pause: false, settlingTime: 150ms, interval: 20ms (50Hz), antiFlickTres: 255, antiFlickStep: 2, antiFlickTime: 300 2023-01-18T20:48:23.727Z [SMOOTHING0] Using alternative smoothing input (0)

Logs Finished

[stickmanbrad]

Although I did notice 39 msec which didn't seem as good as your 11 msec on the wiki :P lol

*Seems when the device goes to sleep and I re-wake it back up, I then get the error message again and it can't start it up.. Even flicking the LED device off and on again doesn't fix that. Seems a full reboot is needed... Strange :/

[awawa-dev]

You didnt answer my question and beta2 tag was present in githut earlier before the final release which contains some changes.

[awawa-dev]

Although I did notice 39 msec which didn't seem as good as your 11 msec on the wiki :P lol

it's a time after when the hello message was receive after the esp reset. Completely irrelevant.

[stickmanbrad]

You didnt answer my question and beta2 tag was present in githut earlier before the final release which contains some changes.

Downloaded the beta2 on the 13th Jan which was the day after the last commit/asset release. Am I correct in thinking that should be fine? Can't see anything later than that unless I'm missing something.

[awawa-dev]

ESP transmission to PC is not guarantee (and that how the firmware detection is done) and you cut off that part of important logs from connecting. Since it working and your problem with the flickering is in the thread other I'm closing this one. For others problems I can help with your description.

[stickmanbrad]

ESP transmission to PC is not guarantee (and that how the firmware detection is done) and you cut off that part of important logs from connecting. Since it working and your problem with the flickering is in the thread other I'm closing this one. For others problems I can help with your description.

I unfortunately would say this issue is not solved. Every time the capture device goes to sleep or literally 9 times out of 10 after a reboot, the device is not detected and the Led's fail to turn back on. Is there anything I might need to adjust on the Raspberry Pi 4 config to ensure it always comes back on and doesn't fail. It's only successfully recognized it with that success message once in the last hour. Have tried with both 2000000 bps and 4000000 with a CH9102x.

Kind Regards,

[awawa-dev]

You could try this patched version that increase boot time https://github.com/awawa-dev/HyperHDR/pull/468 . If the firmware is not detected but it is working then is not relevant. There is COMPLETELY NO guarantee that the hello message will be received by the device from ESP. CH9102x is generally well supported on MH ET Live board (if the board is not DOA), but there are some dreadful designed boards with CH9102x that don't work at all: https://github.com/awawa-dev/HyperHDR/discussions/401#discussioncomment-4653269 So again: no guarantee for your board unfortunately from my side.

[stickmanbrad]

You could try this patched version that increase boot time awawa-dev/HyperHDR#468 . If the firmware is not detected but it is working then is not relevant. There is COMPLETELY NO guarantee that the hello message will be received by the device from ESP. CH9102x is generally well supported on MH ET Live board (if the board is not DOA), but there are some dreadful designed boards with CH9102x that don't work at all: awawa-dev/HyperHDR#401 (comment) So again: no guarantee for your board unfortunately from my side.

Heya,

Thank you for the info. Couple of questions if that’s okay:

I didn’t quite realise that the HyperSerialESP32 method would be like this in terms of dropping its connection if I was to turn the capture device off and on or if it was to sleep. In my setup, I leave HyperHDR running, and simply watch TV and then turn off the source and TV after. I was sort of hoping that when I came back to watching the TV, when the LED device/capture device turns back on, it would work and pickup the ESP32. But as mentioned it doesn’t, and it seems the only way to get it back is with a reboot. Even with that thought, as mentioned above it won’t show the Hello message, and sometimes the LED’s still won’t work now. Am I correct in thinking that with the USB communication method, if it sleeps it likely wouldn’t wake up without a reboot again? - If that is the case it’s probably not the right method for me, as ideally I would like to be able to use the LED’s on demand like when consuming media on the TV. However, if that is completely possible and it’s just my setup, would you mind suggesting somewhere to purchase a known good ESP-WROOM-32 (compatible with this project)? I would be interested to know how it’s supposed to function, as I’m not sure if any of this is normal. As we had discussed before, the GPIO 18 raspberry pi direct option wasn’t ideal, so I just wondered what is the best option really. Happy to test the above firmware if the proposed solution is possible. I’m just not sure whether the USB communication is supposed to drop frequently or not.

Thanks again.

[awawa-dev]

I didn’t quite realise that the HyperSerialESP32 method would be like this in terms of dropping its connection if I was to turn the capture device off and on or if it was to sleep.

HyperHDR has a built-in mechanism to turn off LED device when the OS going to sleep and turn them on again from quite some time (https://github.com/awawa-dev/HyperHDR/releases/tag/v18.0.0.0) The problem can be only the device if it sleeps or wakes up as it should. Same as if it can reconnect without a problem. The 'ESP handshake' option performs hard reset of ESP device before connecting so after the boot it should sent a message to HyperHDR. But probably it doesn't work for you: either you need that patched HyperHDR version that could be download from the latest Github Action tab (maybe it's OS depended problem, it works without it on my Windows but the user reported it needs longer reset time on Linux/webOS) or your board is bad designed and it could not perform reset when trigger by software DTR/RST signal from HyperHDR (it requires special transistors and paths connected from the UART on the board, most boards have it).

[stickmanbrad]

I didn’t quite realise that the HyperSerialESP32 method would be like this in terms of dropping its connection if I was to turn the capture device off and on or if it was to sleep.

HyperHDR has a built-in mechanism to turn off LED device when the OS going to sleep and turn them on again from quite some time (https://github.com/awawa-dev/HyperHDR/releases/tag/v18.0.0.0) The problem can be only the device if it sleeps or wakes up as it should. Same as if it can reconnect without a problem. The 'ESP handshake' option performs hard reset of ESP device before connecting so after the boot it should sent a message to HyperHDR. But probably it doesn't work for you: either you need that patched HyperHDR version that could be download from the latest Github Action tab (maybe it's OS depended problem, it works without it on my Windows but the user reported it need longer reset time on Linux/webOS) or your board is bad design and it could not perform reset when trigger by software DTR/RST signal from HyperHDR (it requires special transistors and paths connected from the UART on the board, most boards have it).

Heya,

Thanks again. Is there by any chance a quick way to upload this alternative version without having to pull the SD card out of the Pi. It’s all tucked behind TV on wall you see. Just wondered if there was an easier way to do it over ssh or something like that? If not then it’s fine, just wanted to ask..

Kind regards

[awawa-dev]

You can get latest installers in 'artifacts' archive on that page (https://github.com/awawa-dev/HyperHDR/actions/runs/3960128586 will expire in future). Extract it, upload 'deb' file on Rpi and update it using manual in wiki: https://github.com/awawa-dev/HyperHDR/wiki/Installation#Linux if you want to use ws281x device from Rpi in the future you must switch the service again to the root but you've done it al least once (it's in the FAQ also)

[stickmanbrad]

You can get latest installers in 'artifacts' archive on that page (https://github.com/awawa-dev/HyperHDR/actions/runs/3960128586 will expire in future). Extract it, upload 'deb' file on Rpi and update it using manual in wiki: https://github.com/awawa-dev/HyperHDR/wiki/Installation#Linux if you want to use ws281x device from Rpi in the future you must switch the service again to the root but you've done it al least once (it's in the FAQ also)

Really sorry, but do you know which artefact it is for the Raspberry Pi 4? Presumably a 64bit image but there’s a few different ones there.

Kind regards

[awawa-dev]

Check which version of OS (32/64) you have already installed. At this point you dont have a choice and must select proper 32/64 installer for your OS.

[awawa-dev]

The info about your current OS should be in the HyperHDR advanced->about tab.

[stickmanbrad]

The info about your current OS should be in the HyperHDR advanced->about tab.

The HyperHDR service doesn't seem to start from boot. Is that normal behavour? Do I need to start it each time the pi reboots?

Kind Regards

[awawa-dev]

maybe you have installed the wrong version?

does it run at all?

[stickmanbrad]

maybe you have installed the wrong version?

does it run at all?

Yeah, it's working. But only when I run 'sudo service hyperhdr@pi restart' after each reboot. Not sure if that's expected.

Installed this version: Linux-bullseye-arm-aarch64-DEB-installer

I originally had the SD card version for raspberry pi 64bit

[awawa-dev]

if there is NO active service in os. sudo systemctl enable --now hyperhdr@pi (or root, chose only one, otherwise you must disable the other) sudo reboot

[awawa-dev]

if it that not helps you probably have other service already configured for other user and you must resolve it first (and check service logs also)

[stickmanbrad]

if it that not helps you probably have other service already configured for other user and you must resolve it first (and check service logs also)

On running systemctl after reboot this is the only thing I can see:

'system-hyperhdr.slice' under .slice

^ I tried running the command you suggested after a reboot (at this point web interface wasn't working). I'd say your right.. I think there is a broken service maybe? - It's still requiring me to enable the service manually.

[awawa-dev]

maybe its running at 8092? verify also journalctl

[stickmanbrad]

maybe its running at 8092? verify also journalctl

I would say it is still running somewhere (but no web panel on either ports)... Not sure how to fix this one :/

[awawa-dev]

Just after the boot, check ps to verify it and journalctl for latest events in logs

[awawa-dev]

Also systemctl show -pUser,UID hyperhdr