WLED is a relatively new platform for communicating with and animating LED’s without requiring a PC to drive them. As a FastLED afficionado, I’ve been developing my own code to communicate with several displays. The summer of 2019 was spent implementing an MQTT infrastructure that would support my FastLED sketches and after MUCH trial and error, I got it to work as shown here:
As a result of the challenges I faced, this effort took several months and I still didn’t accomplish my goal at the end.
My Goal:
To control single or groups of animated lanterns in an ad hoc and non-contiguous setting using an Android phone, ESP8266 microcontrollers, WS2812 LED strips and without a lot of coding overhead.
In practice:
I was successful to the point that it worked, but not reliably and with more equipment than I would have preferred.
I initially settled on MQTT, which, unlike Infrared libraries, worked well with FastLED and WS2812’s. The most popular library was pubsubclient(), but unfortunately, that library halted the loop() and the animations if connectivity to the MQTT server/broker or the WiFi was broken. Despite using the library’s non-blocking example, my animations continued to stutter when connectivity was interrupted. I later used async-mqtt-client(), which overcame the issues I’d encountered with pubsubclient(). As a result of the library change, I had to learn and then re-write the communications code in my programs, which took a significant additional amount of time.
Since I required an MQTT server/broker and that my environment was non-contiguous, I had to look into extending the network. Initially, I was hoping that my Android’s WiFi hostspot capability would work for me, however it only supported 9 devices, so I ended up purchasing a D-Link router. To further extend the network, I purchased a couple of inexpensive USB WiFi extenders from aliexpress, but had significant problems getting them to work with the router. Not only was the interface of the extenders unreliable, but they wouldn’t connect to the D-Link when there was no Internet connection. . . something that I later rectified by using a loopback on the WAN interface of the router.
In the end, I got things running pretty reliably, but required more overhead than I’d prefer and I was still pretty unsure of the WiFi extension capability.
Enter WLED:
This library supports MULTIPLE methods of communicating with ESP8266’s and ESP32’s, such as MQTT, HTTP, Blynk, IR and more. The fact that it supports Infrared with ESP8266’s and WS2812’s is interesting because that is very problematic with FastLED. The reason is that FastLED uses interrupts with ESP8266’s, while WLED, which uses the Neopixel Bus library does not. WLED does, however, use FastLED math and palettes, so all is not lost on that front.
In the meantime, I’m now experimenting with WLED to see if it’s the platform I would like to migrate my LED displays over to. Thanks to the accompanying WLED app for Android, from a communications standpoint, WLED looks very promising. Developing animations for WLED and its’ Neopixel Bus/FastLED hybrid architecture is where the challenge lies.
Although WLED supports an ‘AP’ mode, other WLED displays cannot connect to that network. I did, however create a network with an inexpensive WiFi extender and have been able to have several devices communicate over that network and without requiring a router or a server. Making and controlling groups of displays is now as easy as changing the UDP communications port and performing a SYNC.
WLED is looking very promising, if only I can only adapt to WLED’s programming methodology.
Update: Less than one month later, I’m now using WLED almost exclusively. The fact that I don’t have to worry about interrupts on the ESP8266 is a huge factor in this decision.
Comments are closed.