Timing synchronization with ESP-connected devices and MQTT

  • My wife has been purchasing these little solar devices that light up around the yard at night. They stick in the ground and have a white led and a photoelectric cell. They usually have a couple of 1.5v AA rechargeables. You know the type.

    She also purchased some deck post caps of similar design. In particular, these deck post light caps got me to thinking... one by one they were failing. The batteries are cheap and don't last long. The wiring rusts/corrodes and literally falls off of terminals. So they fail.

    Our home has many decks, multi-level and a couple of them are fairly large and lengthy.

    I took one of these deck post caps apart. It's original circuit ran on 1.5v and the solar panel generated 2.38v in bright sunlight. I degutted the unit and cleaned it all off so that I can design my own IoT-enabled deck post caps.

    Initially I am taking the easy way (and probably more expensive). I hooked up a Sparkfun Thing ESP8266 dev board. This little thing has a LiPo charger built in. It runs on 3.3v and can be put in deepsleep mode to save battery. I connected a 5050 RGB SMD led to the Thing and wrote an Arduino sketch w/WiFi and MQTT support that controls the led colors and brightness. The only one I had came with a 37-in-1 Sensor kit I bought cheap. It works and it's pretty cool! Since this led is rated at 5v (with limiting resistors) I was able to connect it directly to the Thing which runs at 3.3v. It's been running for days and I haven't burnt it out yet.

    I ordered a strip of 100 addressable WS2812B 5050 RGB led chips with a WS2811 built in. I may end up using 2 leds per deck post cap since I would like to be able to crank up the lights while cleaning up or when company is leaving. I'll experiment with this and the battery/solar requirements.

    My server consists of a Raspberry Pi 2 Model B with Raspian, Mosquitto and Openhab. This Pi also acts as a WiFi AP for my IoT network. Ethernet is connected to my local LAN which has public Internet. MQTT is configured and working. As soon as I receive the new leds I'll be able to create a few more of these prototyped lights.

    Creating and controlling a single light/device is fairly straightforward, but after seeing the inherent delays of WiFi, Openhab and MQTT I am beginning to realize there is going to be timing and client id issues.

    For example, if I have a deck that is 50 feet long with an additional 25 feet wrapping around the corner of the home, I have 75 feet of deck rail with a deck post cap light every 6 feet. This deck will require about 13 lights.

    I expect I'll have no problem configuring and coding them to all turn on with a single MQTT message, but each light will receive that message at different times. Consider a movie theater... all of the lights are synchronized to go bright or fade all at the same time.

    I don't intend on configuring my deck lights to dance and flash by default, BUT, it is a pretty cool idea for a project! And so I am considering how this can be done as though they were all still connected in the strip and independently addressable. You can make patterns, alternate colors and even perhaps make a 'flicker' to simulate a burning candle flame. This is an easy thing to do with a strip of addressable leds, but how is timing handled with MQTT commands to a group of devices independently connected to the network over WiFi? Is there already a software library or technique that addresses this?

    The client ID issue can be resolved by appending some or all of the client's MAC address, but I setup the MQTT server to require authentication. I would like to avoid manually connecting each light to program/configure it. Preferably it can associate to the WiFi, publish/subscribe to MQTT with all devices using an identical sketch. It would seem this has already been done, but I haven't found a good example of it. I would also like to avoid manually configuring Mosquittos .acl and .pw files if possible, but still have security. How is this done?

    Also, another consideration is the arrangement of these lights. If I were to create dance the lights and make patterns it would be critical to know each light's position/order - 1, 2, 3, 4, etc. I think a 4 or 6 position DIP switch will work out the positioning issue. Each post cap can read the DIP configuration and know where it is positioned in the line of post caps. I've never worked with a DIP switch like this but it should work so that each light can publish this to the MQTT server?

    My thoughts on this have leaned toward sending MQTT commands that synchronize device timers. Perhaps sending a JSON packet that contains colors, timing settings, scheduling, etc. but the additional control information adds yet more delay - ever so slight, but it's crucial to the timing of these lights.

    Anyone have any suggestions or pointers on how this can be done?

  • Admin

    The ESP can fetch time from a NTP server. You might be able to send a command to them saying "start program X exactly 12:34:23". Where the time is just enough to be sure every node gets it.

  • @hek Pretty familiar with NTP/NTPD, but I'm doubtful that I can get a response time in milliseconds for activating the program. It will probably take a second or two. That's ok to begin some sort of flashing sequence by clicking a single button, but the colorpicker sends messages nonstop while moving around the wheel. I've seen those messages get queued and take many seconds to catch up after color selection has stopped. As quick as it is, it's just not quick enough!

    Then there is the precision. I wonder how well 13 devices can be synchronized on time? Milliseconds in difference will cause patterns to break, of course.