Show HN: Extend Zigbee sensor range with LoRaWAN | Hacker News Reader

Show HN: Extend Zigbee sensor range with LoRaWAN

github.com

219 pointsha_ru48 comments

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 ;)

That's awesome. How did you fund the project?

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.

Cool story! Was there a reason using existing LoRa sensors was off the table? YoLink and maybe others are cheap.

Yolink requires cloud.

Kind of. I use their waterleak sensors and pair them directly with their YoLink Siren. The siren will go off without cloud, internet, or even power (until the batteries run out).

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.

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.

and LoRa technology was bought only 60 millions by samtec. Sounds really cheap.

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.

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?

[0] https://meshtastic.org/

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/

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.

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.

Coming from AI where LoRa means something else, I am very excited to try some of these application to my ZigBee setup.

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.

Yes, definitely. Thanks for motivating me to improve the documentation!

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

thanks a lot. I am looking for the longest time to get temperature sensors for the various radiators of our house's heating system (temperature of pipes entering/leaving each radiator plus room temperature, wall temperature). I found no suitable ready-made Zigbee sensors and developing my own seemed like a daunting task. Your setup looks like a very realistic option for my project.

That's a cool use case. You should be able to use several DHT22 sensors per unit without too much trouble. If I were you, I'd consider mounting the unit on the wall near your radiator, then running some flexible 3 wire cable to all your various sensors.

I'd say the strength of my project is that it's fully open source and designed for casual hackers. The code is only a few hundred lines, and the hardware is all cheap commodity stuff.

The downside is that you'll need to get your hands dirty to set it up. But, there's a big upside in that you'll never get locked in to a proprietary service.

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

If you need only LoRa connectivity, Mikrotik has options for that. Then you can hook up bog standard IP devices to those.

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.

LoRa is also used in latency sensitive environments, eg. Crossfire, R9 and ExpressLRS for racing drone control links. This is even with LBT enabled.

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.

This is great, thanks for doing this!

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.

Ah yep.

But I was mainly trying to think how to extend Zigbee-network over TCP (without LoRaWAN).

Currently it seems to be almost impossible.

If you have multiple LAN Zigbee controllers, like a ZigStar UZG-01, you can use multiple instances of zigbee2mqtt and hook 'em all into Home Assistant.

Yes, thats true, but that also means multiple zigbee networks.

Goal here would be one zigbee network which is extended to satellite location over TCP.

LoRa WAN is a promising technology in general.

Thats why it's been used to shill shitcoins in the past.

LoRa never needed crypto.

Can you elaborate? I have never heard anything crypto related with LoRa.

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.

It’s interesting that you draw the line after Zigbee, but before LoRa. Why is it presumed that LoRa is unknown, and Zigbee is known?

Good point!

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.

adding to this, as a software engineer casually dabbling in home automation, i’ve come across the word zigbee hundreds of times. I see zigbee products recommended all the time. LoRa? it’s my first time hearing about this…

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!

What in the sam hill is a "LoRaWAN GPS Concentrator"?

> Sam Hill

Thanks, TIL this phrase.

> LoRaWAN GPS Concentrator

So the "GPS" is oddly placed in the name, it just means "using a GPS receiver to have accurate clock on the gateway".

The "Concentrator" part is just another name for gateway, but specifically one that receives data from different devices over LoRaWAN, collects the data into packets and sends it on to a database or other application somewhere - typically over 4G/5G or wired internet.

>"GPS" is oddly placed in the name

Thanks, that was what confused me I guess. I saw results for "LoRaWAN Concentrator" that mostly made sense, but "GPS Concentrator" was throwing me for a loop.

Is there a protocol that has LoRas ability to get through anything but with more bandwidth? Even at WiFi, or less, ranges it would be very useful.

Very nice work!!

I've been very interested in LoRaWAN ever since I first heard about it, and I am excited to see more projects like this pop up!

Same! LoRaWAN is IMO one of the most underrated technologies. And I think it enables more things than most people realise

Interesting, might be useful to have in your small farm while monitoring (maybe controlling) the irrigation system in there!

Reply on news.ycombinator.com