[Feature Request]: LoraWAN gateway module

[roha-github]

Platform

NRF52, ESP32

Description

The LoraWAN module sends sensor data from Meshtastic nodes to LoraWAN gateways in parallel.

The coverage with LoraWAN is sometimes much higher than with Meshtastic nodes with an active MQTT uplink to the Internet. A LoraWAN gateway module could take advantage of this and combine both approaches.

The advantage for Meshtastic is that sensors would also have a path via LoraWAN in remote areas without Internet. The LoraWAN gateway is the uplink for sensors. With the small payload for LoraWAN, this only makes sense for sensors, telemetry and possibly positions.

A central LoraWAN server that forwards the events to the Meshtastic MQTT would be conceivable as a supplement.

Idea adapted from https://meshtastic.discourse.group/t/integration-with-lorawan-gateways/12558/2

[meshtastic-bot]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/integration-with-lorawan-gateways/12558/3

[garthvh]

Meshtastic is not compatible with lorawan, can not communicate with lorawan gateways , you could do this with mqtt

[roha-github]

@garthvh Meshtastic based on LORA like LoraWAN do. You can implement a module for meshtastic that send frames for LoraWAN. Why this should not work?

https://github.com/HelTecAutomation/ESP32_LoRaWAN/blob/master/src/ESP32_LoRaWAN.h

https://github.com/ElectronicCats/Beelan-LoRaWAN

[roha-github]

@garthvh Too bad you closed the feature request so quickly. It seems to me that you didn't understand the implementation idea at all.

It is technically feasible and there would also be added value for Meshtastic.

[GUVWAF]

A node that has to listen to Meshtastic traffic cannot without reconfiguration uplink to a LoRaWAN gateway, so you'll always have a period where you'll miss packets.

This really needs to be done with two radios, and you can already do so now by connecting the second one via the SerialModule to the Meshtastic device.

[roha-github]

Sure, a simple "brigde" mode disconnect from meshtastic for seconds, change LORA config to LoraWAN, send out sensor data and reconfigure to meshtastic. In theory there are some seconds offline from meshtastic.

In my understanding the payload for LoraWAN is not usefull for chat. That's the reason I focus on sensor cases. LoraWAN don't have the mesh idea. In our local whatsapp group is a discussion of THW usecase to monitor diesel level of power generators via a Lora mesh.

[caveman99]

LoraP2P (Meshtastic) and LoraWAN are inherently different protocols built on the same transport layer (lora). The process you described (disconnect, reconfigure, send, reconfigure, reconnect) may sound logical to someone not too deeply involved in firmware and the radio protocol. Short assessment from my side: if someone is willing to implement this switcharoo mess, go for it. I see no chance this will ever be accepted into the main firmware, so you'd have to maintain your own fork.

This is like switching out the diesel engine from a car and changing to petrol while in motion.

[roha-github]

Thanks for this clear statement "no chance this will ever be accepted into the main firmware".

We can stop discuss that topic here. Meshtastic is designed as a synchronius mesh without resilience of temporary unreachable nodes. Store&Forward module goes a little into async and more resilient scenarios.