Is anyone around here familiar with the esp2866, pi zero w or similar?
I’ve got quite a nice RGBW mood light, but it doesn’t do much other than fade through colours. Id like to be able to change brightness or change mode, but the ultimate aim is to get two or more to talk to each other and sync up, whether iot/wifi is the best solution for this is up for debate. I’ve heard some random thing a while ago about ultrasonic pings being used for wireless communication, but working out how to do that seems more complicated that buying a board with a Wi-Fi chip.
WiFi is probably the simplest and I’d suggest maybe using MQTT messaging between them. You could have a Raspberry Pi set up to act as a wireless access point and configure it to also act as a DHCP server. ESP8266 or Pi Zero W clients would then connect to the network and be allocated an IP address.
The “master” Pi, which could probably also be a Zero W, would then run mosquitto MQTT broker (server) also. A script running on this or another system, e.g. a PC, smartphone or yet another Pi, would submit messages to topics on the broker, commanding colour changes etc. The client devices that have the LEDs attached would subscribe to those topics on the broker and upon receiving a message would change colours etc.
There are lots of other wireless systems you could use. What is best depends on range and power etc. (whether on a mains supply or battery) requirements. Bluetooth could be another option, but it can be a bit complicated as it supports lots of different “profiles” for e.g. fitness trackers, mice and keyboards etc. The simplest is probably the UART profile, which basically uses Bluetooth to provide a wireless serial connection. I.e. you use it to just stream data between two points in a very simplistic way. Someone may well have done a simply library to make use of it. I think the BT stack is called BlueZ on Linux, so you could google that and your language of choice to look for examples.
May be worth looking into whether there is some simple, open source wireless DMX software/library you could use, as that would be the “proper” thing for controlling lights I guess.
You should also check out Node-RED as a potential environment for writing apps. This sits nicely on top of MQTT and can be used to implement the logic and interface with web sites, Twitter, e-mail etc.
Thanks for the swift response, I think the MQTT system would be very interesting to explore, and potentially have one sender and a bunch of subscribers, like cheap NodeMCU’s receiving messages from a master Pi. The thing that confuses me if I take this route is getting a smart phone to control or send messages to the master Pi. Would all of these devices be on the say the local Wi-Fi network? Or would they be their own closed network? Just trying to get my head around this. Would the phone potentially need to log into the improvised network to send messages?
I don’t mind language, I’ve read Lua is used for NodeMCU, and if raspi I’m gonna have to learn python to some extent. I only know bits of C arduino and C# with a bit more authority.
Any WiFi network you like. I was assuming for some reason that you wanted a standalone solution, e.g. for an installation. If using an existing network you don’t need to configure a Pi as an access point or DHCP server.
Here’s an example of a connected greenhouse we built using MQTT for integration.
The sensors, fan vent motor, fan and horticultural LED module were connected to one system (an Intel Edison, but a Pi could be used instead). Then a 2nd system read inputs from switches and drove LED displays. They both communicated via a “cloud” system (a little PC running Linux, Mosquitto and Node-RED). The logic was implemented in Node-RED, which would subscribe and public to topics. The code is at:
We later added a “bridge” that was built using a Raspberry Pi. This republished messages to/from topics on the broker which ran on the local cloud PC, via a 2nd connection to an instance of Mosquitto plus Node-RED on the Internet. This was used to provide a graphical dashboard online, with temp and humidity etc. data. Doing it this way meant that if you lost the Internet connection (it was all installed inside a truck touring the UK) it would carry on working, via the local cloud.
Writing Python code to MQTT pub/sub is dead easy.
A quick search turned up a few Android MQTT clients you could use, e.g.:]
There seem to be code examples too, so you could make a custom app. But also if you use Node-RED for the logic, there are tons of other interfaces available too. So for the control/user interface side you could drive it all via e.g. a web page, a database, Twitter etc. You can browser the available nodes (e.g. input, output and function) and flows (a Node-RED app is called a “flow”) via:
Thank you very much for the excellent information. The green house project looks amazing, really well done.
For my project I’ve reverse engineered a popular “smart” light: https://youtu.be/kKtEr4nDfhE (in a hopefully non copywrite infringing way)
I’m thinking about open sourcing and optimising for extensibility and hackability. I would like to provide a basic framework with which to work with that includes a basic set up for Wi-Fi and potentially use a teensy for FFT audio analysis to make the project audio reactive.
Is it possible to just use a whole bunch of ESP2866/NodeMCU’s without a main raspi being the broker? Sorry if this is a dumb question but is there a specific advantage to throwing a raspi into the mix?
Not sure if anyone has ported Mosquitto, or written some other MQTT broker for, NodeMCU.
Never used NodeMCU myself, but seems one other option would be to use built in UDP client/server to pass messages:
You could have all those with LEDs to drive configured as servers, and another configured as a client and pushing out messages to them. Or indeed a simple Android app that is a UDP client.
Using a very simple UDP client/server system would be more lightweight than using MQTT and having a broker such as Mosquitto, but then that does offer a system with more ability to easily integrate NodeRED applications and standard client libraries for lots of languages. Depends what you want to achieve. If cost is main concern and NodeMCU is the preferred platform, UDP client/server model could be the way to go.
If doing audio FFT I’m guessing RasPi will be easier to integrate a mic/line in and obviously has a bit more processing power for analysis. In fact, if you wanted to get really fancy, I think someone has created an OpenCL implementation for the Pi’s GPU, meaning it may be possible to utilise this for accelerating such tasks. That said, I’ve never done any OpenCL programming and suspect it’s not for the faint of heart.
Well thank you very much, just got an SD card reader/writer today so I could flash a SD card with raspbian (the annoying final bit of gear, holding me back from doing anything), had a Pi knocking around but never used it, got two boards called wemos £5 ish couple of days ago, with an esp32 on board and basically by the end of the day without knowledge of Pi or Linux or node red have everything set up and running, reading from esp32 and sending information to/from node red using MQTT and mosquitto server running on the Pi. Sounds way more complicated than it turned out to be!
Writing the esps like normal arduino using a pubsub library and using 1 Pi for the broker and bam super easy internet of things.
I have a Pi zero, haven’t used it yet, I assume I can just pass across the SD card I’ve been working on and it should work fine?
Surprised how far I got, the last part would be some sort of interface, but that’s for another day!
I’m wondering if this stuff is very portable, like unplugging and taking round a mates house, I’ve pretty much hard coded all the passwords and network credentials and IPs, i dont know how I’d be able to change them easily without reuploading the firmware every time the device is in a new network! Have you got any ideas by any chance?
The other question is if I could use th Pi zero W as a hotspot to send data locally but without internet. I think that could work, but quite uncertain.
Congrats! Yep, MQTT and NodeRED make all this so easy to do.
Should do.
Raspbian should have Avahi/Zeroconf running by default, which means that provided you give them all unique hostnames (edit /etc/hostname and /etc/hosts) you can reference them by “hostname.local”. E.g. with the default hostname you can ping raspberrypi.local from another Linux system. Windows/Mac possibly doesn’t use the “.local” and may work without it. So that sorts the IPs bit out.
WiFi SSID configuration is a bit harder and you’d need some way of selecting the network and entering a passphrase. No doubt someone has done a nice hardware interface with a little display and keypad or similar. Actually, maybe someone has worked out how to set a Pi up to do WPS, where you just push a button, on the router I think. Worth looking into. Though in general with stuff like this I prefer to just take the network with me, I.e. have an access point, such as a Pi set up with host AP and a DHCP server running.
One other thing… Linux systems don’t like just having the power pulled, so if you are taking the setup from place to place and not able to log in via attached keyboard/monitor else SSH, I would highly recommend configure the card to be read-only after the software is all set up. There are quite a few steps involved, as some system process need to write to a filesystem somewhere, so the solution is generally to set up a RAM disk for these to use. See, for example: