I am about to create a network of smoke detectors with ESP MCUs that must be able to keep communicating even if HA goes down. So I am looking for a reliable and future proof way to implement ESP-to-ESP communication. I am NOT looking for any broker based solution (like MQTT) because I do not want to create another single point of failure.
Use ESP-Now integration as discussed in several ESPHome feature requests, i.e. this one. There are custom components in alpha state created by @iphong and @moto2000 (motwok) for this but further development seems to have stalled for close to a year now.
Try to use ESPHome’s Native API Component to create a client-to-client communication (actually server-2-server because the ESPs have the server role here). This sounds like the most interesting way to me. But up to now I don’t have a clue whether this is possible and how to subscribe to the Native API of one ESP from another ESP.
What I would actually love is a solution that allows for undirected broadcasts (like MQTT does). AFAIK none of the above options does that.
Any thoughts on this? Other options? Am I overlooking something?
Thanks!
I actually tested the (old) esp-now integration from @iphong and it worked quite good. I’m planning to deploy a test project with the new work from @moto2000 (pr here and docs here).
If you are willing to invest in additional hardware you could also think of using RF (433,868,…) and use the remote transmitter and remote receiver component. Another option which is in the pipeline could be utilizing lora component.
Using gsm could be another (not to cost effective) option
I haven’t had any luck with that. I tried to get this working with stock ESPHome, but the main problem is that the same physical radio is used for both WiFi and Bluetooth. Recent work on esp-idf shows some low level support for coexist mode, but that is not readily available from within ESPHome.
The general solution seems to be to add a second ESP, and let that communicate with the first one through serial, I2C or whatever.
Thanks for your suggestions. I think Bluetooth is no solution in this case. I know that BLE can establish one-to-many scenarios in a main / sub relation with up to 7 subs. But what I need here is many-to-many without a main (= server) role and with over 10 nodes.
Another rather limiting factor – at least for my current project – is space. There is hardly any room for additional hardware. This rules out any additional protocols that are based on hardware add-ons. Even an ESP32 will probably not fit. I had to cut off an edge of the D1 mini already. Even the available height is limited to only 5.5 mm (0.2 inch). See pics with transistors lying flat an the backside of the circuit board. (Unfortunately I have no tools to solder SMDs.)
I also think that my problem is a rather generic requirement. It should be generally possible to establish inter-node communication without additional hardware. Judging by the feature requests this is quite a common need.
Has anybody thought about using the Native API approach? As I said it might be really promising to build an ESP-2-ESP communication based on that. But so far I did not find any hints how to do it.
Yes. These are cheap wire bound detectors at about 10€ each. All they can do through the wire is activate their sirens in sync if one of them detects smoke. When I’m done they will have the following additional functions:
Show in HA which detector/s has/have fired
Mute the synced sirens through HA so only the detector that sees smoke keeps on chirping and stress levels go down
Activate all sirens through HA on other alarms (i.e. intruder alert, so stress level of intruder goes up :o)
Read out detector battery voltages in HA
The white/yellow wires will be reused to provide 5V for the MCU.
But this is all stuff for another posting or project report…
beside that it’s not (yet) available for interconnections between esphome nodes without ha (see #52 and #46) and you are planing running the esp’s of battery?
Then forget this approach (which is not available anyway )
For battery powered nodes the only feasible approach will be esp-now (see the docs how it works) at the moment
It may not be an acceptable option but you could use a round wiremold box under the fire alarm to give you room. A buck transformer and what ever radio equipment. Just keep a battery for back up?
I do apartment retro fits and have used wiremold to meet ac fire alarm requirements. Drops it down about an inch and is pretty much the same size. So aesthetically they really don’t look like an eye sore.
Not in the concept of what is wanted, but i would like to propose some other alternative:
Since you have cables pre installed in smoke detector locations; why don’t you use those cables to connect a cheap smoke detector to a cheap analog house alarm; ie Crow Runner, DSC, Honeywell etc. That will provide an advantage of a standalone system which has a connection to Home Assistant. So even if HA goes offline, the alarm system will still continue to function even on power cut; with the in battery.
You can also have a DIY nodemcu or official IP module of that alarm and connect it to HA.
That is the most stable smart home system in my house so far; wired connections are always the best. Using a crow runner 8/16 alarm with AAP IP Module. It can work standalone and also it works perfectly in combination with HA (Zero downtime for months-years, even though my HA goes offline every other week).
The cost will be a little higher; you can find an analog alarm system under 75USD, or even 10 USD if it is second hand. Just make sure you can interface it with HA.
EDIT: I can do all your requirements and more within HA with my current Crow/AAP setup.
You might want to check with your homeowners insurer to be sure that something automatically disabling sirens isn’t going to disqualify you for coverage if something awful should happen where the siren would have helped.
Guys, thanks for all your good advice. I value your input but I don’t want to get into a discussion about smoke detectors here. (My wiring is not star-shaped. Muting will not be possible for the initial alarm. MCUs will not run on battery. Insurance requirements are met in my country.)
Please let us focus on the MCU-2-MCU communication here. This is where I really need your advice.
Still the following question to answer to have an idea what the esp-2-esp should do at all:
Also what I wonder (but what might not work as you say it’s not shaped): Couldn’t you use one esp and have all the signal wires connected to it? Still you can’t mute a smoke detector than - so probably not what you want anyway…
Btw.: I’m building something similar with 1€ smoke detectors (not interconnected like yours) but have the challenge that the esp needs to run of batteries too. I will go with esp-now just because it easily consumes 10 times less energy (most energy consuming for “normal” ap-wifi is actually the wifi handshake and tcp stack which easily takes a second or two).
The system will definitely implement a mix of HA logic and direct communication. I plan the direct communication to enable the detectors to chirp in sync when one of them detects smoke. This is exactly the one function that these cheap detectors can normally do through their wire connection. It is security relevant and so I want to give it an extra layer of stability by establishing it outside of HA.
This actually was my plan at first. As you already said, this needs a star-shaped wiring. I have that only in part, because some of my outlets are branched instead of starred. (This is a result of the fact that the whole wiring was planned for KNX which does not need a star topology.) Still I considered a central ESP in the beginning. I had already sketched a method to wire the detectors in a way that their normal wire function remains intact while at the same time the MCU could determine, which detector has fired. (This is possible because the detectors don’t need full voltage on their control wire to activate their siren. With a bit of analog logic it is possible to tell, which detector has created the original signal on the wire.)
But again: This needs a fully star-shaped topology. And I would lose the muting and I could not monitor the battery status of the detectors. So I switched plans to use one MCU per detector and use the wire only for power supply of the MCUs. This entails a somewhat reduced reliability when forwarding an alarm to other detectors. But the risk is small and if it really fails the detector that sees smoke will still sound its alarm. So I accept the small degradation.
So did you give esp-now (docs) finally a try? Should be exactly what you want because one esp can broadcast it’s alarm state and many (all other) can receive and “process” (ring the alarm ) too.
I’m not aware of any other software only solution which does not rely on a full ap wifi setup and tcp.
This looks extremely promising. I will definitely give it a try as soon as I have mounted the next detectors. (Right now I have built but the prototype. Parts for 11 more specimen will arrive this week.)
Most interesting is the fact that ESP-now seems capable of multicasting/broadcasting. At least kind of. I was not aware of that. Really sounds like the perfect solution. I only hope it is already stable enough.
Littlebit of old school idea.
If you still have the wifi access point it maybe possible to send udp packaged to the broadcast address. That would work if you have a “normal” home network".
But that would probably involve writing a custom component. Udp broadcast has actually some delivery control on wifi compared to wired network. Then every esp could listen to the broadcast address and port.
I did something like that ages ago when we used computers with wifi as a iot test wifi mesh setup.
This is not a very optimal solution in a network point of view but if its a fire that take president.
But I agree that the esp-now solution looks much cooler.
Good luck with your project.
Oh, I’m surprised that UDP has some kind of handshake. Never knew that. I thought this was just the main difference to TCP. Interesting.
But as you said: ESP-now sounds like the perfect match.
Normally udp has no delivery control. I think that delivery control is part of the wifi lower level message passing. It cause a lot of trouble for us when we did our experiment. Because we wanted just drop if it failed.
Let us now how the esp-now goes.
)
shaped): Couldn’t you use one esp and have all the signal wires connected to it? Still you can’t mute a smoke detector than - so probably not what you want anyway…
) too.