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.

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!

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.

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.

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

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?

[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/

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.

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.

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