If you’re working on a home automation project, you’re probably knee-deep into MQTT by now. If not, you should be. The lightweight messaging protocol is an ideal choice for getting your “Things” on the Internet, and controlling them all can be done easily through a simple web interface or an application on your mobile device. Or if you’re [serverframework], you make yourself a handsome little all-in-one MQTT remote.
The hardware here is pretty simple; inside there’s just a NodeMCU ESP8266 development board, some buttons, an RGB LED to give feedback, and a 3.7v 1200mAh LiPo battery with associated charging module. Everything is held inside a nice little wooden box that looks like it would fit right in with the living room decor. We’d like to see some kind of a cover over the exposed perfboard the circuit is assembled on, but that’s arguably a personal preference kind of thing.
Most of the magic in this project is actually happening on the software side. Not only does the provided source code handle all the MQTT communications with Home Assistant, but it provides a clever user interface that allows [serverframework] to perform 25 functions with just five buttons. No, you aren’t seeing things. There are actually six buttons on the device, but one of them is a dedicated “power” button that wakes the remote out of deep sleep.
If you’d like to learn more about getting this protocol working for you, our resident MQTT guru [Elliot Williams] has plenty of thoughts on the subject. From his talk at the 2017 Hackaday Supercon to his home automation tutorial series, there’s plenty of information to get you started.
MQTT is so 2017… Just use Esphome with home assistant and you’re done…. ;) Seriously though, this is awesome work.
Esphome isn’t as stable or reliable as mqtt, and that way one can use HA NodeRed and anything else 🙂
“If you’re working on a home automation project, you’re probably knee-deep into MQTT by now. If not, you should be.”
Oh geez. No.
My stuff is reliable without any IoT or TCP/IP madness. 37 nodes and counting. No problems.
using what method ???
First pass was based on openhab, but was the code was too messy and required a little too much processing power; and I do not like java.
Second pass is just UDP riding on a current loop and tokens. Simple stuff for my simple mind.
current loop as in 4-20mA? running a custom token based Ethernet hardware layer??? please explain the details, and why is it simpler
???
Wired point to point? Daisy chained? Hub-n-Spoke?
Understand I already have a wired Ethernet network (and WiFi) so MQTT fits nicely. I also have devices that can go from serial to IP (RS232, RS485 and logic levels). Getting it from IP to MQTT (and all the rest of my automation) is simply a translator. And before anyone freaks out: “Look Ma, no cloud!”. ;-)
I have automaton software from the late 80’s still running. I’ve retired all the Insteon and X10. I’m now using a mix of wired and wireless technologies. I hope to be able to present this at the Trenton Computer Festival ( https://tcf-nj.org – March 21st).
Yeah, TCP/IP is definitely just a fad. It’ll never catch on.
Xod-Node-red-Mqtt-broker previously ftw. Esphome is still pretty simple and great as well. But I didn’t like the fact that it was the only reason I was keeping hassio. You can now control everything thru Alexa(and other) now since someone figured out how to made an esp8266 emulate a Belkin wemo device. So now just upload the fauxmo sketch onto a d1mini, nodemcu, etc board>open Alexa app> add device> select other > scan and find your device. No need for node-red nor mqtt anymore, xod is still viable of course. Have fun!
*Don’t forget the other needed Arduino libraries.
I thought fauxmo wasnt working anymore
This would be such a different world with indoor location awareness…
Ah, the times when I used to design my home automation so that only I would need to understand it… that was before I got married and had kids. Nowadays, I always factor in usability by other family members and boy has it improved my overall design of user interfaces, also for those I only use myself. That being said, this remote doesn’t look too promising in that regard…
What is your approach? I also need it to be wife/kids friendly.
My two doubts.
1) Why still unsecured protocols in 2020? Why still using simple MQTT instead of MQTTS? (I am not talking about MQTT-S, I am talking about MQTT over TLS/SSL)
2) Consequently, why still ESP-8266 instead of ESP32? Moreover, this is a prototype, so a few dollars cannot make the difference if you have more performance for SSL and so on.
If you are on TCP, you cannot neglect the importance of SSL.
This is just a TV remote? Well, I can monitor what you see on TV. Maybe I can turn on special features. Even watch what you see on TV or send images to your TV. If you aren’t on SSL protocols.
First let me say that I agree with you in principle.
1) Why still unsecured protocols in 2020?
My opinion is that there are no easy to use secure SSL/TLS libraries and setup procedures for this. I think we’re at the point where this should happen. Also signing the data. The CPUs have enough horsepower for this.
2) Consequently, why still ESP-8266 instead of ESP32?
I think you’ve come to a false conclusion that an ESP8266 is less capable than the ESP32 when it come to the instructions. The ESP32 has advantages but for some things the ESP8266 works well enough (it can handle SSL/TLS).
Also if secure protocols are your only line of defense then you still have a long way to go. I am looking into this for my 2020 Trenton Computer Festival Presentation but I already have a lot of material and I’m not sure I can squeeze it in and give it the attention it deserves.
If it’s just about a remote control translated to MQTT messages, then the Sonoff RF Bridge 433 flashed with ESPurna firmware ( https://github.com/xoseperez/espurna ) can do that easily. The best part of it, is that the remote control can be any old 433 remote control (like the ones used to control power plugs decades ago), which is way more efficient regarding batteries.