Hi,
i’m running a ambilight setup which has 4 WLED instances - i configured them normally via wifi - each instance runs a Wemos D1. Unfortunately i kept having annoying connection issues (some Instance always dropped out / lost connection/is freezing) and I couldn’t find out the reason (router / controller / hyperion whatever …).
So i was thinking about trying wired connections.
I’m aware that it can be done wia ethernet board (wanted to upgrade to ESP32 anyway) and via SPI connection.
What would be better? (latency/performance wise …)
Ethernet seems nice as you can use switches / many instances and it has a huge bandtwidth but you need ugly cables everywhere …
SPI also seems nice but: how would I connect several instances to one ESP32? Would it be fast enough? And there would also be lots of cables …
I think there’s much more experience/support here for ethernet than there is for SPI, which may be a factor worth considering! Plus, there’s off-the-shelf solutions for ethernet boards, such as the digiquad.
Before you make the leap, make sure you’ve tried disabling “wifi sleep,” as lots of folks have issues with wifi sleep causing multi-instance installations to fail. Probably won’t fix it all, but it might help!
If you have connection issues, try upgrading to a bin from Serg. They are compiled with the new core which sacrifices a bit of frame-rate for Wi-Fi performance in some setups.
Thanks for your reply … i’ll give disabling wifi sleep a try …
what exactly does it do?
Here’s what’s NOT working via Wifi:
sometimes anything works fine - but after some time one instance starts bugging like extreme delay and updating only each ~5 seconds - and i can’t reset it, even when unplugging it and restarting the software. When this happens, also the Webinterface is not reachable anymore and it seems like if the D1 loses wifi connection / sth is completely scrambled …
I also had the opposite thing happening … anything was screwed up and i didn’t change anything and after ~30 minutes the buggy instance worked again as if nothing happened …
EDIT: i tried disabling wifi sleep with all instances, anything worked fine at the beginning. then i added a 3rd instance (turned it on) and all the problems were back one instant goes crazy and the 3rd instance loses connection to the Web-UI …
The ESP families have a low-power mode that can cause some undesirable behavior, especially with multi-instance installs. Disabling this will slightly increase the power consumption of the esp, but it’s connection should be much more stable. You also might try enabling “send notifications twice” on your master controller. This will duplicate all your UDP packets, helping to lessen the dropped packets.
Unfortunately, these may not help as it sounds like your issue is… something else. Is it always the same instance that misbehaves? Have you tried re-flashing the instance?
(see updated message above)
yes, first i thought it’s an older wled version and updated all instances, didn’t help.
and yes, seems like it’s always the same instance. and as i said, the instances seem to interfere and disturb each other … very strange.
what imo does not make any sense at all, that the “buggy” instance has a lag of about 5 seconds + updating only each 3-5 seconds … as if it’s a puffer problem.
and even when disabling / turning off the 3rd instance which is causing the problem, the buggy one still is bugged and i can’t get it back to work even with unplugging und restarting ambilight software …
I’ve had one or two ESP32’s end up with poor filesystems that caused me issues.
Might be worth a reload from USB using the Web Installer (you’ll probably need a backup).
And definitely to 0.13.0-b6.
i tried both … OTA and via USB. didn’t seem to make a difference.
i’m assuming it could be the D1 itself (maybe?) … ordered it from Aliexpress.
That it’s having hardware / wifi issues …
If you have a single ESP with multiple power supplies, you absolutely need to connect the GND (0V or -) outputs of all power supplies together somehow. If you already have that, it might sound strange, but try connecting the 0V (GND) to actual GND input to the supply. If the supply does not accept an external ground, take the ground wire from the power cable and bolt it to the chassis, and then connect a wire to the 0V output to that same chassis bolt (might need a slightly longer bolt).
That helps to eliminate random voltage drift problems that in some situations where things are mounted to metal or affixed to metal anywhere along the strip could cause noise on the 0V line which affects how the RGB chips interpret the data signal. It is not a common problem, but in an electrically “noisy” environment, every little bit helps.
To test whether grounding or bonding of a DC supply will help, you can use a multi-meter set to measure VOLTAGE, and measure voltage from earth ground to the 0V DC output.
The value does not matter. If the LED behavior changes (and improves), it will benefit from a grounded 0V DC output.
I’ve only seen this to be a problem in marine or aero industries where they are not connected to the earth. In those cases, bonding to “ground” actually increases the noise in many cases.
Thanks
one instant goes crazy and the 3rd instance loses connection to the Web-UI …