WLED: Retry connection if WLED Device is not reachable.
Closed this issue · 5 comments
- I confirm that this is an issue rather than a question.
Bug report
Steps to reproduce
Start Hyperion
Start WLED device
What is expected?
If WLED device is not available at boot, retry until it is reached
What is actually happening?
WLED device stays in idle until Hyperion is restarted.
System
Hyperion Server:
- Build: ()
- Build time: Feb 19 2023 16:07:19
- Git Remote:
- Version: 2.0.15
- UI Lang: de (BrowserLang: de-DE)
- UI Access: default
- Avail Screen Cap.: framebuffer,x11,xcb,qt
- Avail Video Cap.: v4l2
- Avail Audio Cap.: audio
- Avail Services: boblight,cec,effectengine,forwarder,flatbuffer,protobuffer,mDNS,SSDP,borderdetection
- Config path: /root/.hyperion
- Database: read/write
Hyperion Server OS:
- Distribution: Debian GNU/Linux 10 (buster)
- Architecture: x86_64
You can already today define the number of retries and timeframe in between.
It is not unlimited retries, but you might just want to increase the number that fits your WLED.
In addition, there is no need to restart Hyperion, you can just enable the LEDDevice Component again to start the opening loop.
Besides that, I would advise that you check for any error messages in the log, in case there is a general problem with your WLED device.
I tried 99 retries and 5s retry time.
But the problem is that this doesn't work. I need to start Hyperion after the WLED strip, otherwise it won't be driven.
There is no problem with the WLED Device.
I have two different WLEDs with two different Hyperion instances suffering from the same problem.
There seems to be an initial check at boot up of Hyperion if the WLED device is available just once.
Problem seems to be the mdns name with .local that is used by the auto detector.
When I use the IP/DNS of my WLED device by setting it to custom it works fine.
@SciLor You reported the issue against 2.0.15.
Have you also tried 2.0.16 or the 2.0.17-beta?
There were some updates done since...
@Lord-Grey I tested this today on 2.0.16