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?
DIY but not exactly cheap: Arduino MKR WAN 1310
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.
Andreas Spiess does a lot of Lora projects, including solar powered battery ones.
Probably worth searching his channel and checking out a few.
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.
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.
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.
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:
The https://www.home-assistant.io/integrations/mysensors/ integration connects to sensors connected to arduino pro minis using cheap NRF24L01+ transmitters.
The project website is a bit difficult to navigate but an associated site has lots of hardware examples.
mysensors also runs on esp8266’s
hi
i am searching some info for transmiting data to HA over air distance max 1km
i will send info about bees : weight, temp, hum.
all hadrware is complete on ESPhome and work over wifi only at home, but the bees are a 1km out of house . please give me more info .thy in andvace
As I said in the post you quoted, I don’t use ESPHome. I’m afraid I can’t help with that.
There is ZWave Long Range as well . I don’t know how well or if at all it is supported with Home Assistant
You could try a YAGI. Under $10 on Aliexpress or there is a video for a home-brew one:
This is fairly new; not a lot of devices out there at the moment with this z-wave 800 chip.
But I believe Zooz would have the USB stick (search " ZST39 LR") with a 800 chip inside, available today (Feb-2023).
And then looks like Inovelli is about to roll out switch(es) with this z-wave 800 chip in a few more weeks (April?).
So I wouldn’t call this z-wave long range being “ready” just yet.
… Although it does has the potential… we will just have to see:
Sorry I don’t use Z-Wave LR but had garnered an impression it was implemented in the 700 series chip. There are a few node devices available.
