What can I use with ESPHome for communication where Wifi or BT don’t have enough range? Are there any mesh -type protocols for longer distances? What other options are there that don’t currently work on ESPHome? It doesn’t necessarily need to be on ESPHome, as long as I can integrate it with Home-assistant.
LoRa is being worked on, but is it is not available yet.
2 Likes
Do you know where I could get started with LoRa while waiting for an esphome implementation? Is there any relatively easy to use software and hardware; similar to esphome or tasmota on esp chips?
1 Like
There’s the Things Network:
2 Likes
As far as I know there is none equivalent of ESPhome that would handle Lora chipsets unhappy 
You’ll have to find sample codes on internet for it and play a little with platform.io or Arduino IDE 
For ESP modules with Lora you can find some at SeeedStudio, Rakwireless with very good quality 
2 Likes
Depends on how you define ‘enough range’. I have been using the HC-12 modules for a long time now with excellent results. Range is about 1km, sometimes more if you have clear line of sight and a good antenna. I wrote my own mesh network running on top of these, but you don’t have to go all that way. They’re just serial UART devices, extremely easy to use for point to point communication. I don’t know if there is any ESPHome support for those, I don’t use ESPHome.
If you need more range, then LoRa is the way to go.
2 Likes
nilux,
not sure the range you want but I just swapped out an esp8266 nodemcu for an esp32 with external antennae for a project. The first would not connect being about 70m from a unifi outdoor AP. The second gave me a 40% signal and was easily able to update OTA.
I haven’t tried to see what range I might get because the 70m is about the range that I need.
Pat
1 Like
I need no more than 200m. But I’m sure lots of people have the same problem with remote or otherwise difficult locations, and I didn’t find a good thread about the long-range solutions/alternatives to wifi/esphome. So thanks for the suggestions!
Based on the input, the relevant options are:
- The Things Network. It seems to be a LoRa → WAN gateway and ecosystem with ready made proprietary products. I didn’t yet find if it can provide me with a cheap diy solution. Must read more.
- ESP32/LoRa board with Arduino Software (remote unit) plus some LoRa to Home-assistant unit (which I didn’t yet find how to do, maybe esphome with template sensors?)
- HC-12 with arduino or other rf-868 module with esphome, using hand crafted unencrypted communication
- Zigbee mesh with enough repeaters to cover the distance. I’m pretty sceptical of this.
- Wait for some nice Thread package and hope it works well over multiple hops.
- Wait for LoRa on Esphome
So it seems like there’s no solution yet for long range communication that doesn’t either cost plenty or require quite some learning. Or maybe it’s just my confusion because of the paradox of choice. On the other hand, it just highlights how nice ESPHome actually is 
It’s an excellent starting point that gives me confidence that it can be done with my skills and that it integrates seamlessly with HA.
1 Like
May I ask you a little more?
Do all your HC-12 devices broadcast to all? Is it so that you pick a channel and all devices receive everything?
Does a certain device react to a certain hard-coded message regardless of where it came from?
Do they communicate with Home-assistant? How?
1 Like
DIY but not exactly cheap: Arduino MKR WAN 1310
1 Like
Yeah all HC-12 modules transmit on the same channel. The module itself is pretty dumb, it transmits the raw serial data you feed it with. If you only have a single link between two modules, then that’s all you need. If you have more, than you need create your own protocol and transmission control layer in software. That’s actually pretty fun to develop and a very nice learning experience.
There are lots of different ways to implement this with various stages of complexity. Mine is a node architecture. Every node has a unique address. There’s a master controller node with address 0 that manages the network. Transmitted data is encapsulated into routing packets that contain, amongst other things, the address of the source and destination nodes. Every transmitted packet is acknowledged by the destination node (bi-directional communication) and resent if needed for reliable data delivery and over the air QoS metrics. Nodes only transmit when the channel is clear (clear channel assessment) to minimize interference and packet repetitions.
There are special broadcast / multicast addresses that all / multiple nodes react on.
Once the basic transmission control layer works, you can go crazy with things like mesh routing, frequency hopping, dynamic best route finding, etc. Purely optional, but fun stuff to mess around with, if you’re into that sort of development.
The master controller node implements an MQTT interface which is used to communicate with HA.
3 Likes
Andreas Spiess does a lot of Lora projects, including solar powered battery ones.
Probably worth searching his channel and checking out a few.
1 Like
That’s impressive! I feel like taking 6 months off my job to do the same 
I’m sure I’ll never get that far, but just out of interest, could you share what a single message/sequence looks like? Does the sender collect different items for a while, compile it into a message, put it in a queue, send it and mark it as unconfirmed? Does the receiving side use the same functions/code in reverse; take a package from the receiving queue, figure out whether or not its the proper recipient, acknowledge, then act on the message? Do you have a public repo?
I was looking for a readily implemented communication protocol that a dummy like me could use, but now I’m beginning to understand something, and it’s intriguing.
If indeed the HC-12 just wirelessly transmits whatever it receives through serial, then shouldn’t that part be easy to implement in ESPHome using the uart_bus?
Doesn’t take 6 months You can have something up and running in a few days if you have prior dev experience.
At the most basic level, with only direct routing (no mesh) and without CCA, a transmission packet would look like this:
[0] Sync sequence
[1] Destination node address
[2] Source node address
[3] Packet ID and retry counter
[4] Packet type
[5] Payload length
[6] Payload
[7] Checksum
[8] Packet end identifier
To keep it easy, each data entry can be a single byte. That also keeps the packet small and less likely to be corrupted. The sync sequence at the beginning is a unique bitcode that won’t appear anywhere else in the data stream. This is used by the receiver to determine when a packet starts. The packet ID and retry counts are used by the receiver to determine if the same packet was received multiple times (maybe because the sender didn’t receive the ACK and resent it by mistake) and to sort out duplicates. The retry counter can also be used to create some basic transmission quality metrics and see how reliable your signal is (how many retries the link needs on average until it gets the data through). The checksum is obvious here.
It’s important to keep in mind that you’re dealing with an unreliable transmission mode here. Packets can be corrupted, you can only get partial packets, etc. Your code needs to deal with this.
Say you have a temperature sensor that wants to send the current temperature every 10 minutes. So it starts by packing up its payload (the temperature) and encapsulates it into a packet. It will set its own node ID into the source field. It also sets the destination node address to 0, because the recipient of the message is the master controller node. All other fields are generated accordingly and the entire encapsulated packet is sent as raw data out into the air.
All nodes will receive and decode the packet. But only the node with a matching destination ID will process it further. Nodes that are not the intended recipient will discard it. The recipient node will process it, check the CRC, etc. If all is good, it will send an ACK packet. The structure is exactly the same, only with a special packet type identifying it as an ACK packet without payload. This time the roles are reversed - the source address is 0 (the packet comes from the master controller) and the destination is the ID of the temperature sensor. The latter will receive the ACK packet and can now be sure its temperature data was well received by the recipient and it was not corrupted.
If the original sender node (the temperature sensor) does not receive the ACK packet within a given timeframe, it will try to resend the packet a predefined number of times before it gives up.
On the receiver side, the payload is extracted from the decoded packet, processed and repackaged into an MQTT message to HA. A queue is used for incoming messages to handle heavy traffic situations.
Nah, not for this. Honestly, handling support for this would be too time consuming.
There are existing libraries that do this (and more), like RadioHead or MySensors. I never really tried them though, I thought it more challenging and fun to build my own.
I suppose ? I never used ESPHome, so I don’t know how it supports UARTs. But yeah, if you only have a point to point link, then it’s just a simple serial connection. It can still be corrupted though, so you should at least add a checksum. You can have multiple independent point to point links on separate channels. Just note that the HC-12 supports a lot of channels that are beyond the unlicensed frequencies of the 433MHz band.
1 Like
Wow, that was a satisfying answer. Thank you! And no, I have very little developer experience, which is exactly why I’m looking for an ESPHome equivalent or implementation for LoRa. I could probably do something in Python - which I expect to be useless for this purpose.
I’m watching his videos now. They are very informative indeed.
1 Like
Here is a LoRa mailbox sensor project for HA.
I’ve actually been working on this one the last couple of weeks. You don’t need really any programming experience for it. His particular hardware setup requires a fair bit of work because his project is trying to save a lot on battery life. If battery life is not so much an issue, I would think you could buy an off-the-shelf ESP LoRA board instead of using his hardware setup and just tweak his mailbox sensor code. Its very simple.
Here is a companion video to show what the software setup is like.
And here is another HA LoRa project:
Thanks for the suggestions! My conclusion is that for devices too far for Wifi, all communication options are pretty unrelated to / independent of esphome. I can have home-assistant communicate with a gateway (mqtt), which communicates with the remote device using any of the possible long-range communication protocols/chips: LoRa, RF, light pulses, sound waves, morse, whatever :-).
And for that purpose I can hand-craft communication or use another project like TTN, OpenMqttGateway, MySensors.
I’m really looking forward to ESPHome implementing some long-range communication protocol.
2 Likes
I achieved this range (and even a bit more) outside with two d1 mini’s (pcb antenna) while using esp-now (no additional hardware needed)
It’s not (yet) in esphome “stable” but there are various implementations for it around in the wild (custom components), just two drop two links:
2 Likes