Use Meshtastic Radio as a Library (Refactor or Rewrite Radio Code?)

[broglep]

This is a continuation of https://meshtastic.discourse.group/t/how-to-use-meshtastic-as-a-library/8294

I would also like to be able to use the meshtastic radio part independent of the rest of the meshtastic firmware.

If we find enough people interested in this, maybe we could think about an coordinated effort to untagle the firmware and separate the MeshService and RadioInterface? Or even extract / rewrite parts of that radio code as a library to serve as a stable future foundation for expansion of the Meshtastic ecosystem (both for the device firmware as well as other use cases)

The current firmware shows quite a lot of signs of organic growth over the past years and would probably benefit from bit of untangling.

[seagull9000]

I think this has a lot of merit. I've been grappling with a couple of projects where I haved wanted to use meshtastic, but would require a separate MCU like an attiny85 paired with a meshtastic device to make work.

A Meshtastic library would allow the host MCU to perform multiple functions and use the meshtastic network to communicate.
It would also help where super low powerered nodes need to be deployed where solar is not an option.

[seagull9000]

Perhaps even just a skinny library that formats messages and sends them with the correct prefix.

What would be the bare minimum needed?

• Selectable destination node/channel
• prefix
• public key
• max hop count
• retries
• ack required

????

[GUVWAF]

Indeed, it would be very nice to have it working as library, but I expect it to be a lot of refactoring work.

There is, however, another approach by using the secondary core, e.g. on an ESP32 or RP2040. The Meshtastic UI uses a PacketAPI (it's not yet in master, see #5571) that communicates with the Meshtastic firmware running on the other core.

For the time being, the Module API could be used to run your own code that e.g. periodically sends data, or reacts upon receiving other packets. Or, indeed using a secondary MCU that interacts with it, e.g. using the Arduino client library if your code does some heavy processing.

[broglep]

I think re-implementing receiving and sending of mesh messages as a library would be the best achievable goal.
If you only want to use the library "at the edge" of the mesh, you would not need all the routing complexity and can rely on other meshtasic nodes to do this for you. Big chunk of radio complexity is already abstracted away by RadioLib, ideally one could extract the meshtastic layer on top of RadioLib from the current firmware so that configuration of the library feels familiar & is similar to regular meshtastic firmware (e.g. lora config like frequency and spreading factor via meshtasic modem presets). And then what is left is some meshtatic protocol specifics like protobuf serialization/deserialization, channels, maybe PKI, etc.

Refactoring the current code base will be a huge effort, but it might be necessary at some point in the future for the project to have a long term future

[GUVWAF]

It's also a bit hard to judge what will suffice as a library. For example, in principle NodeInfo is not necessary for receiving and sending messages, but it's very convenient to know who's sending something. Another example is traceroute, which people expect to work if you see a Meshtastic node.

[seagull9000]

If it makes any difference, I have an idea that developers using the library would mainly be using private channels for their projects, but I guess that wouldn't always be the case.
A minimal initial library implementation would likely identify and evolve to adopt the must haves / nice to haves over time.