[Feature Request]: Meshtasticd as central daemon for dumb nodes

[nmaas87]

Platform

Cross-Platform

Description

Dear all,
coming from more of an LoRaWAN background and running some LoRa concentrators I am proposing following idea: Running a concentrator can be basically achieved by pluging in a USB concentrator into any ARM based SBC and running the packet-forwarder. The same kind of ease is currently missing for Meshtastic. Yes, we can run Meshtasticd if we got an SPI connected HAT/LoRa Radio - or we can run the Python API to talk to some complete Meshtastic node. However, the "middleway" is missing: An integration into Meshtasticd which would allow to integrate one or more USB/Serial connected Meshtastic nodes (be it with directed or omnidirectional antennas) into it and allow those to be used via Python API or Webclient. That would allow to use a node, e.g. a RAK11300 (which is only allowing USB/UART as an interface and does not poses a display, BT/WIFI or anything) as a stationary "accesspoint" to be run as a LoRaWAN concentrator while still having the mangement features if a normal node - and the ability to log data and manage that node directly via the SBC it is attached to.

[garthvh]

Concentrators are explicitly not supported by Lora p2p

[nmaas87]

While I understand the notion of a decentralizied, mobile network, there are obvious advantages to fixed position, decentralizied nodes within that network running via powersocket/UPS and having bigger antennas to connect mobile clients over a bigger area.. These clients do not pose a disadvantage to this network but instead elevate it. Germany has had a huge success with the Freifunk network, a decentralizied network allowing users to share their ISP access via WIFI. Taking a leason from this network, Meshtastic could grow faster with more fixed clients/repeaters to allow the network to grow and fix gap between volunteers spinning up their mobile clients. However, these fixed positions also need a management interface, which this issue tries to gain. If not possible, this will be managed by just using the Python API and growing "rogue" fixed access points, as the lack of such access points is the mayor reason why meshtastic is thought to be negligible within all of the european continent and will stay that way.

[caveman99]

every client is also a router. exposed nodes (poles, really high buildings, mountaintops) can be switched to a special role to assume an infrastructure node. All aspects of these routers can be changed via remote admin protocol. The only thing that is missing out of your Lorawan packet forwarder scenario is a central backhaul packet broker, which needs to be connected via traditional IP anyway.

We could do that with MQTT, or opt for a router backbone, like several regions are running already, self organized. Please tell me what component is missing in Meshtastic to meet your vision?

[nmaas87]

What I am currently thinking to be missing would be daemon that would run a Meshtastic Hardware client attached to an SBC/Computer in a more service oriented way. A daemon that would record all received and re-transmitted messages (be it even a statistic if not to be decrypted for most messages), giving statistics about uptime/throughput/positions and most distances covered (if not encrypted, idea taken from the visualization of the tinyGS network). Also, this daemon should be accessible in the same way as a normal node via e.g. Python API to allow for interfacing with the network the same as every node - to e.g. receive data from Meshtastic sensor nodes and integrate them easier into other systems. Hence, the meshtasticd seemed to be a good starting point: Allowing meshtasticd to not only use directly attached SPI LoRaWAN modems, but also "normal" Meshtastic Clients, attached via USB/Serial would probably solve this already. This would allow homeowners to easier install Meshtastic clients and keep an eye on them in terms of "are they used?" and running them more as an infrastructure in your private home and company than just a conversation starter on your EDC :).

[garthvh]

Lora p2p is not compatible with lorawan concentrators at all best case meshtastic could use one radio.

[fifieldt]

If you know Python, ripping some code out of https://github.com/fifieldt/meshtastic-map-backend might give you a start -- this thing can connect to a node directly and process packets you could then make stats and other things with. Pipe non-local nodes to an MQTT server and you can get those packets too.

[nmaas87]

Thank you, that might be a good starting point 👍🏻

[caveman99]

Also see https://github.com/beegee-tokyo/Meshtastic-Sensor-Network - i still don't see what this has either to do with LoraWAN (Hub/Spoke vs. Mesh) or better management. All the tools are there, you just have to plug them together.

[nmaas87]

Thank you very much for the information. My initial idea did not have anything to do with LoRaWAN, other than expressing that projects like TinyGS/LoRaWAN/Freifunk provide easy management/transparency of their networks to allow the base-/groundstation operator to see that these systems are actually used by the community and hence are worth the effort/energy to keep them up running / giving a good feeling to be actually doing something worthwhile and not tearing them down as soon as enerycosts explode again. It was more of making the handling easier and improving acceptance.