Hi! This project (LoRaBridge) was born few years ago as I was trying to figure out how to get data from the cheap Zigbee sensors in my cellar. In my case, the cellar is not immediately below the main living space, so the Zigbee range even with some repeater nodes was just not enough. One day, out of curiosity, I bought two LoRa modems, mounted one of them in the cellar and the second one in the 2nd floor of the house. I was blown away by the fact that I got a stable connection through so much concrete(!). That was pretty much the light bulb moment for how my solution would look like.
Fast forward 2-3 years, after a (funded!) open source project, there is now a way to mount Zigbee sensors in remote locations. Essentially the solution is a wireless bride, which works like this:
- A remote Raspberry PI unit collects&compresses zigbee data and transmits it over LoRaWAN
- LoRaWAN gateway/servers forward the data towards second PI, which decompresses the data ,takes care of the device management and sends the data further to, e.g., home assistant.
And as a bonus: The device joining process is as easy as it is with zigbee2mqtt ;)
The ability of LoRaWAN to transmit through almost anything is black magic. It works reliably down to 20 dB below the noise floor at maximum spreading factor. You can still get sporadic operation at -30 dB SNR.
We once tested putting sensors 8ft under ground, down a manhole for the water mains. They kept on working through dirt, steel and concrete even with the manhole cover in place.
Reminds me of the hoymiles inverter for solar panels. I'm using opendtu to read the data. The protocol is proprietary and was reverse engineered, I have no idea what it is, but the communication works from 1st to 5th floor. I don't even see the wifi beacons on the 3rd anymore.
I'm surprised to see the Pi in there; I would naively expect a microcontroller (my first thought today would be https://www.espressif.com/en/products/socs/esp32-c6 but there are options). Is this arrangement a matter of how easy it is to implement, age of the project (predating good MC options), or a harder technical/practical blocker?
We actually thought about a pure microcontroller solution, but stuffing a zigbee coordinator, a mqtt parser and a lorawan stack into an uC seemed a bit overwhelming. It is technically possible with beefier SoCs, but as most ingredients we needed were well available for a PI, we went this route while building the first prototype.
This is a fantastic idea, thanks for sharing. I feel like LoRaWAN and LoRAMESH are the perfect solution for shuffling messaging around for home and property sensors, easily traversing a couple miles in poor conditions.
Prior to seeing this I was thinking about how to use the Meshtastic [0] project to fundamentally provide simple UDP services for message brokering over LoRa. There are so many sensors that could easily hook or connect to devices acting as network routers that could bridge other protocols across long distances very easily.
Have you looked at doing something similar with ZWave at all?
Thanks! We haven't looked at Zwave yet, but meshtastic and some other lora based mesh network stacks are familiar. One more interesting project is Recticulum with its RNodes: https://unsigned.io/rnode/
Thank you! We received a Netidee grant (https://www.netidee.at/), which is a popular funding source for Austrian open source projects with a focus on Internet technologies.
I have around 30 YoLink sensors scattered about our house (mainly for detecting water leaks). And for a long time I only had the single hub in the basement on the complete opposite end of the house. I never had any signal issue and they've all worked flawlessly.
I haven't needed to change the batteries on a single sensor yet for multiple years. I did get 2 of their SpeakerHubs which also act range extenders, but it's completely unnecessary since the single hub is perfectly fine wherever you put it. I mainly use the SpeakerHubs as sirens, but they can also do text to speech, e.g. "(Loud Siren) Water Leak detected in master bath".
They've already saved me a couple of times.
I keep reading about all these standards for connected devices e.g. Matter, but in the end these just work perfectly for my use case.
LoRa is really a fantastic tool for outdoor sensing.
I built a (free! open source! 3d printable!) sensing platform on top of LoRa that I use all over my small farm. The nodes run on batteries and just send plaintext strings straight to InfluxDB. https://www.thingiverse.com/thing:6170483
Everything has been rock solid. Of the ten I've printed, only two have stopped working-- One of them got melted inside a compost pile, and the other got washed downstream during a flood.
Could you please expand a little on the setup of a hub/gateway in your project? I found the Arduino sketches for three sensors but it was not clear to me how one would go about the gateway those sensors would connect to.
This is great. I use Yolink because it’s one of the only Lora options. More options ways to use Lora that don’t require a cloud SaaS would be great. I’m considering getting a hubitat device which focuses on local operation but also has some integrations with Yolink and other devices
Would it be in theory possible to setup sensor's along rural area fences using solar to forward data from possible RFID tags or something?
Trying to think of a way to utilize ear tags for cattle getting loose. I'm sure setting up repeaters and could forward stuff over long range p2p wifi AP's.
Just thinking if anyone knows how to potentially pick up nfc or super basic equivalent that could be placed in the ear tag. Most solutions now have some sort of battery replacement which would have to replace ear tags. or have some bulky gps collar.
Waiting for some flexible solar panel printable? that could be placed on the ear tag and some antenna picking up the super low frequency emitted.
Great project! Is there any mechanism implemented to ensure compliance with the EU regional limitations of the maximum duty cycle in the 868-870 MHz bands? ZigBee can be quite chatty as it operates on the unrestricted 2.4 GHz bands.
I think this is handled by the radio modules or else they wouldn’t be certified, so you just have to make sure you don’t order a US-only module.
FYI there is also a 2.4GHz version of Lora. It has very high sensitivity modes close to the performance of the sub-GHz version, but also has high performance modes that give you up to 2Mbps.
Not necessarily. Often rf modules are pre-certified mostly to show that the hardware implementation and radio modulation and all that works as intended. Eg no spurious emissions, transmits at the freq you ask for etc.
What gp asks for is that regulation requires either polite transmissions aka listen before talk aka clear channel assessment, ie before we send, listen for a while and back off if channel is busy. If LBT isn't used, there's a maximum allowed transmission duty cycle stated.
Zigbee typically uses LBT, Lora doesn't. Hence, a clear zigbee channel may result in a very chatty lora channel.
And another problem is the difference in bandwidth, where zb uses 250kbit/s at 2.4 GHz and a transmission may take on the order of a millisecond, Lora even on minimum spread takes hundreds of ms, on max spread a single transmission can take several seconds.
This limits the scalability of lora networks in dense physical deployments. Lora primary use case is the once-a-day-ish sensor transmission.
Yes, in fact we actually re-transmit the absolute minimum information (device join/sensor values) to ensure that the LoRaWAN link does not saturate. Data compression helps too and a user can also disable re-transmission of some meta-data, like link quality/battery level.
I think it is somewhat common situation, when home zigbee network does not reach e.g. garage or some other near-distance building. Usually there is some ethernet/wifi network on the satellite building. So distances what LoRaWAN can reach, are not probably even needed.
Read a bit about the implementation, but I think it is easier to just ask:
Could this work over general TCP somehow?
Thanks! Your question is an interesting one: Forwarding TCP over LoRaWAN seems at first impossible due to large packet sizes (from LoRa perspective!). It turns out there have been some efforts to apply dictionary based compression methods to carry different protocols over LoRaWAN. You might want to check out RFC 8376 for details.
Helium project https://www.helium.com/lorawan IIRC it had a lorawan component and a 5G component. You had to buy their bridge/gateway and connect them to the internet. Then you got paid on (mined) something resembling check-ins from LoRa devices, multiplied by how 'underserved' that area was.
Then of course people were creating hacked clients that were capturing like 99% of the Helium coin or whatever it was.
Honestly, I'm not even sure it is a bad idea and they may have resolved some of the concerns by now. It seems like a good way to incentivize people to deploy and maintain the gateways.
First of all, this is not an attack or intended to be negative. I often get attacked or downvoted for constructive feedback on Show HN (where that's what it's here for). This is intended as feedback. I give feedback to the best projects and to the worst.
With that out of the way:
Many of us have never heard of LoRa. There is no way to know in 60 seconds what this project does, or why it is useful. I would recommend adding a sentence to the effect of:
"LoRa is a low-cost long-range wireless communications protocol. This project provides hardware and software to allow zigbee devices to communicate over LoRa, allowing placement of such devices far from the zigbee hub."
That's a small but big improvement. Next improvements:
- Discuss maximum range / interference
- Add an English option to the project page
- Minor: Reorganize the page to be more directive about how to get started ("Buy X, do Y, etc. in a tutorial format"). This can even just be a pointer to the relevant pages ("Buy the hardware list on [this page]. Install the software per [this page]")
That's a first impression. Feel free to post again. Show HN is a nice place to get first impressions, which have a surprisingly big impact on adoption.
I think my assumption came from two places: (1) My own bias (I use Zigbee) (2) Zigbee is big enough to have been sold in big box stores.
However, a rewrite which explains the global context would be even better, if it can be done concisely. You're right that many people won't know that. It's super-helpful to have a paragraph-length (max) description of any projects which is accessible to as broad an audience as possible.
Your points are valid. Especially the ones on educating an interested user about what the project is good for and how to get started. Thank you for the feedback!
Readit News
Fast forward 2-3 years, after a (funded!) open source project, there is now a way to mount Zigbee sensors in remote locations. Essentially the solution is a wireless bride, which works like this:
- A remote Raspberry PI unit collects&compresses zigbee data and transmits it over LoRaWAN
- LoRaWAN gateway/servers forward the data towards second PI, which decompresses the data ,takes care of the device management and sends the data further to, e.g., home assistant.
And as a bonus: The device joining process is as easy as it is with zigbee2mqtt ;)
We once tested putting sensors 8ft under ground, down a manhole for the water mains. They kept on working through dirt, steel and concrete even with the manhole cover in place.
Prior to seeing this I was thinking about how to use the Meshtastic [0] project to fundamentally provide simple UDP services for message brokering over LoRa. There are so many sensors that could easily hook or connect to devices acting as network routers that could bridge other protocols across long distances very easily.
Have you looked at doing something similar with ZWave at all?
[0] https://meshtastic.org/
I haven't needed to change the batteries on a single sensor yet for multiple years. I did get 2 of their SpeakerHubs which also act range extenders, but it's completely unnecessary since the single hub is perfectly fine wherever you put it. I mainly use the SpeakerHubs as sirens, but they can also do text to speech, e.g. "(Loud Siren) Water Leak detected in master bath".
They've already saved me a couple of times.
I keep reading about all these standards for connected devices e.g. Matter, but in the end these just work perfectly for my use case.
I built a (free! open source! 3d printable!) sensing platform on top of LoRa that I use all over my small farm. The nodes run on batteries and just send plaintext strings straight to InfluxDB. https://www.thingiverse.com/thing:6170483
Everything has been rock solid. Of the ten I've printed, only two have stopped working-- One of them got melted inside a compost pile, and the other got washed downstream during a flood.
I switched the main project page over to GitHub, since it's a little easier to navigate. Check it out here: https://github.com/alexose/3D-Printing/tree/main/Dorothy
Just thinking if anyone knows how to potentially pick up nfc or super basic equivalent that could be placed in the ear tag. Most solutions now have some sort of battery replacement which would have to replace ear tags. or have some bulky gps collar.
Waiting for some flexible solar panel printable? that could be placed on the ear tag and some antenna picking up the super low frequency emitted.
FYI there is also a 2.4GHz version of Lora. It has very high sensitivity modes close to the performance of the sub-GHz version, but also has high performance modes that give you up to 2Mbps.
What gp asks for is that regulation requires either polite transmissions aka listen before talk aka clear channel assessment, ie before we send, listen for a while and back off if channel is busy. If LBT isn't used, there's a maximum allowed transmission duty cycle stated.
Zigbee typically uses LBT, Lora doesn't. Hence, a clear zigbee channel may result in a very chatty lora channel.
And another problem is the difference in bandwidth, where zb uses 250kbit/s at 2.4 GHz and a transmission may take on the order of a millisecond, Lora even on minimum spread takes hundreds of ms, on max spread a single transmission can take several seconds.
This limits the scalability of lora networks in dense physical deployments. Lora primary use case is the once-a-day-ish sensor transmission.
I think it is somewhat common situation, when home zigbee network does not reach e.g. garage or some other near-distance building. Usually there is some ethernet/wifi network on the satellite building. So distances what LoRaWAN can reach, are not probably even needed.
Read a bit about the implementation, but I think it is easier to just ask: Could this work over general TCP somehow?
But I was mainly trying to think how to extend Zigbee-network over TCP (without LoRaWAN).
Currently it seems to be almost impossible.
Thats why it's been used to shill shitcoins in the past.
LoRa never needed crypto.
Then of course people were creating hacked clients that were capturing like 99% of the Helium coin or whatever it was.
Honestly, I'm not even sure it is a bad idea and they may have resolved some of the concerns by now. It seems like a good way to incentivize people to deploy and maintain the gateways.
Deleted Comment
With that out of the way:
Many of us have never heard of LoRa. There is no way to know in 60 seconds what this project does, or why it is useful. I would recommend adding a sentence to the effect of:
"LoRa is a low-cost long-range wireless communications protocol. This project provides hardware and software to allow zigbee devices to communicate over LoRa, allowing placement of such devices far from the zigbee hub."
That's a small but big improvement. Next improvements:
- Discuss maximum range / interference
- Add an English option to the project page
- Minor: Reorganize the page to be more directive about how to get started ("Buy X, do Y, etc. in a tutorial format"). This can even just be a pointer to the relevant pages ("Buy the hardware list on [this page]. Install the software per [this page]")
That's a first impression. Feel free to post again. Show HN is a nice place to get first impressions, which have a surprisingly big impact on adoption.
I think my assumption came from two places: (1) My own bias (I use Zigbee) (2) Zigbee is big enough to have been sold in big box stores.
However, a rewrite which explains the global context would be even better, if it can be done concisely. You're right that many people won't know that. It's super-helpful to have a paragraph-length (max) description of any projects which is accessible to as broad an audience as possible.