Skip to first unread message
rwkiii
Mar 22, 2016, 2:14:31 PM3/22/16
to 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, BUT, it is a pretty cool idea! 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?
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.
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?
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, BUT, it is a pretty cool idea! 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?
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.
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?
rwkiii
Mar 22, 2016, 2:31:04 PM3/22/16
to MQTT
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?
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?
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?
Dougie Lawson
Mar 23, 2016, 6:14:44 AM3/23/16
to mq...@googlegroups.com
Hi,
If your ESP8266 can run a wall clock with local time then you can easily synchronise them to your RPi (which is already sync'd to an NTP server on the public internet). You just need to develop something like htpdate (but using an MQTT subscription to retrieve the current time). http://www.vervest.org/htp/
If your ESP8266 can run a wall clock with local time then you can easily synchronise them to your RPi (which is already sync'd to an NTP server on the public internet). You just need to develop something like htpdate (but using an MQTT subscription to retrieve the current time). http://www.vervest.org/htp/
If I have enough spare time over Easter I might take a look at doing that with one of my raspberries and one of my ESP8266s.
Then the messages sent to control your lights have a payload of "AT 22:21 UTC DO SOMETHING" (using military time for ease of parsing and UTC so you don't have to worry about DST) , that can be sent any time before 5:21pm EST (for example) and the ESP8266 will run the script (to "DO SOMETHING") when it's local RTC reaches the right time. Even with some drift of the clocks your lights will respond within microseconds of one another.
It's a bit like running the AT command on Linux, you simply queue up commands that are scheduled to execute some time in the future and each remote station does the work when its local clock reaches the appointed time.
You're still using MQTT for the command and control system, but your commands are queued. The local timer ensures they run synchronously.
HTH, Dougie
On 22 March 2016 at 18:31, rwkiii <rwkram...@customdesigns.com> wrote:
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?
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?
--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.
--
rwkiii
Mar 23, 2016, 11:04:13 AM3/23/16
to MQTT
I think you're right with this approach and I don't think I have a lot of questions right now as to how to code this.
My thought on this was how well each light would synchronize - how closely could their on/off and color changes be timed. You mentioned that I might expect a difference of a few milliseconds. At some point a few milliseconds would throw a pattern off.
Just as an example, suppose I would want to set all lights to the same HSB, let's say all red and 100% brightness. Then specify that each light should light up purple for a short time and then go back to red/100. Each light would have a different delay so that the effect would show a purple light traveling around the deck. Of course, we see this being done all the time with hardwired led strips.
Or another example would be to simply alternate 2 colors - every other light and then flash every other light in unison. With a dozen or two dozen lights I am wondering how graceful this will look.
Anyway, you did answer my question and confirm what I was thinking. Just didn't want to go this route if there was already a library for this type of need.
Once I get more 5050s I can put together 3 or 4 of these lights and try some of this. I'll let you know how I make out. I'll be anxious to hear how you make out on Easter!
Thanks.
My thought on this was how well each light would synchronize - how closely could their on/off and color changes be timed. You mentioned that I might expect a difference of a few milliseconds. At some point a few milliseconds would throw a pattern off.
Just as an example, suppose I would want to set all lights to the same HSB, let's say all red and 100% brightness. Then specify that each light should light up purple for a short time and then go back to red/100. Each light would have a different delay so that the effect would show a purple light traveling around the deck. Of course, we see this being done all the time with hardwired led strips.
Or another example would be to simply alternate 2 colors - every other light and then flash every other light in unison. With a dozen or two dozen lights I am wondering how graceful this will look.
Anyway, you did answer my question and confirm what I was thinking. Just didn't want to go this route if there was already a library for this type of need.
Once I get more 5050s I can put together 3 or 4 of these lights and try some of this. I'll let you know how I make out. I'll be anxious to hear how you make out on Easter!
Thanks.
Reply all
Reply to author
Forward
0 new messages