Dear Mr. Lavergne,

Thank you for taking your question to this forum. The setup you are proposing essentially uses LoRa as a backhaul between two KNX installations, right? While this is possible purely technically, LoRa was not designed for this and this will not work very well in practice, for a number of reasons:

1. Communication paradigm

LoRa and KNX differ significantly in communication paradigm. KNX is a publish/subscribe system where anyone can publish and anyone is free to listen to the bus. LoRa has a master/slave architecture where devices all communicate with a central application server (the Allorado Gateway), in a star topology.

To bring your setup into practice, one Allorado Gateway would work as application server and the second one would need to be set up as a LoRa end device so it can join the network as a slave. While technically possible, there is no implementation of this at the moment, since the gateway always works as an application server in current setups.

2. Throughput

Suppose one gateway would be set up as an end device, then LoRa communication would become possible between two Allorado Gateways. In NodeRED, you could then set up a KNXnet/IP connection to both installations on each gateway and transmit the messages over the LoRa link.

LoRa has a high latency compared to KNX (in the order of a a few seconds), so messages will flow rather slowly. In addition, LoRa is a medium with very little throughput and quite strict airtime regulations (a device can only transmit 1% or 10% of the time depending on the frequency band, according to EU regulations). That means you’re left with 1,83 bytes / second on average for the highest range at 10% airtime or 60,56 bytes / second on average for the lowest range at 10% airtime [1].

If you periodically want to send over data from a single or a few group addresses, that might just work fine. LoRa is however not up to the task of bridging two complete KNX installations, that’s a recipe for frustration.

3. Alternatives

For your specific setup, a proper Wi-Fi network might be more up to the task. Wi-Fi throughput and its paradigm are a better fit for bridging KNX installations. If proper antennae are used, Wi-Fi can go quite far as well. It depends of course on the setting (open space, concrete walls, machinery in between).

Thank you for your inquiry in any case. If a project comes a long where LoRa is the best fit for the job, we’ll be happy to advise you.

[1] J. Petäjäjärvi, K. Mikhaylov, M. Pettissalo, J. Janhunen, and J. Iinatti, “Performance of a low-power wide-area network based on LoRa technology: Doppler robustness, scalability, and coverage,” International Journal of Distributed Sensor Networks, vol. 13, no. 3, p. 155014771769941, Mar. 2017, doi: https://doi.org/10.1177/1550147717699412.
‌

Great to hear you’ve already gotten some LoRa devices working. We implemented the Thermokon sensors earlier this week actually, doing some final tests today. Later today, we will release an updated version of the decoder library with full support for Thermokon. I will keep you updated on this.

Good to know about the NAT, I can see why you might want to change the UDP port. Great suggestion, we plan to add this a setting in the next release (1.4). This release also contains the manual choice of object IDs and object names for BACnet.

As I mentioned, we’re doing final tests on release 1.4 and plan to start shipping it out in April. We look forward to getting our new software into everyone’s hands! Your feedback is much appreciated.

Have a great weekend
Bram