Meshtastic Client?

[g0730n]

I have written a few basic apps for personal use for my JS2 using espruino IDE. Some simple games, a password generator with selectable seed pin, etc...

I spent some time trying to commumicate via BLE with one of my meshtastic devices that I normally use an android app for.

It was some time ago but I shelved it because I was not able to figure out how to impliment the correct BLE communication.

Before I tackle this again, wanted to ask here:

Is there any reason why this woudn't be possible?

The devices I am wanting to interface with are also NRF52840. It is possible i had the JS2 side of things right but was not understanding the meshtastic side, so will have to read more.

I want to make a basic app I can view messages the meshtastic device receives and send some basic preset messages, or plugin one of the keyboard apps to send custom ones.

[gfwilliams]

I had a quick peek at what they've written at https://meshtastic.org/docs/development/device/client-api/#bluetooth-meshbluetoothservice and as far as I can see there's no reason why it shouldn't work.

Bangle.js can't do the 512b MTUs which they ask, but it'll do 120ish bytes, which should still be enough.

One thing to watch out for - BLE devices are supposed to define a single 128 bit UUID, and then just modify the second 16 bits of it for each characteristic, but meshtastic have just defined a ton of different UUIDs - and Bangle only has memory for a certain number of them.

It looks like you only need to connect to 5 of them at most so I think you'll be fine though.

[gfwilliams]

A very quick example. Not tested, but hopefully it'll get you started

var device, service, fromRadio, toRadio, packetNum;
NRF.connect(device_address).then(function(d) {
  device = d;
  return d.getPrimaryService("6ba1b218-15a8-461f-9fa8-5dcae273eafd");
}).then(function(s) {
  service = s;
  console.log("Service ",s);
  return service.getCharacteristic("2c55e69e-4993-11ed-b878-0242ac120002");
}).then(function(c) {
  fromRadio = c;
  return service.getCharacteristic("f75c76d2-129e-4dad-a1dd-7866124401e7");
}).then(function(c) {
  toRadio = c;
  return service.getCharacteristic("ed9da18c-a800-4f66-a670-aa7547e34453");
}).then(function(c) {
  packetNum = c;
  packetNum.on('characteristicvaluechanged', function(event) {
    console.log("New Packet -> ",event.target.value); // this is a DataView
  });
  return packetNum.startNotifications();
}).then(function() {
   fromRadio.readValue().then(d => console.log("Got:", JSON.stringify(d.buffer)));
   // toRadio.writeValue("something...")
   // do readValue until you get a 0 length buffer? Then do it when you get the `New Packet ` message
  //device.disconnect();
}).catch(function() {
  console.log("Something's broken.");
});

[g0730n]

Thanks! I will try out this code snippit this weekend just to verify if it works or not, and if not will tweak it and repost a working version for proof of concept.

After I posted this question last night, I revisited the project as I had left it, and after some debugging realized one of the main issues why I was having no success was I had a pairing pin set on meshtastic device. For now I disabled it and have been able to pair, and from there I have a very rough client running. I will try and figure out pairing with a PIN later.

As far as the MTU, it seems like it is capped at 130 bytes. Thankfully in the packets coming from meshtastic device, MOST of the essential data is in that first 120-130 bytes. But unfortunately it seems the node names usually land outside of that, so I just have it truncate at 130, and then decode the usable data. I wrote a function that determines if we have a valid name, and if not, set one from node ID. So most of the radios show up with the last 4 hex characters of their node ID.

So far I have a status bar showing node name and battery voltage of connected device, as well as a rolling list of last seen radios based on incoming packets.

Also added a chat pane showing last 12 messages, with a prefix of channel and node they were sent by, as well as time they were received on watch.

[g0730n]

I published this app in my fork of BangleApps: https://github.com/g0730n/BangleApps/tree/master/apps/meshclient, thanks for the help and info!

[gfwilliams]

That's great, thanks! When you feel happy with it, it'd be great if you could submit that to the main app loader. It could be really useful for folks with meshtastic devices.

The MTU issue is a pain - it feels like it's not great design on the part of Meshtastic, as it's easy enough to work around without requiring the connecting device to have a high MTU. Many bluetooth devices default to 23 byte MTUs, so the Bangle's 130 is already pretty high, and asking for 512 is pretty extreme! I guess they were only really thinking about connecting their radios to phones though, and not anything else.

[g0730n]

Sounds good.
I have been using it for a few days to work out any bugs or feature changes, then I will submit it.

The MTU limit may not be a huge issue, the main issue I am tryingto figure out is the one where when connecting to the radio, the initial nodeinfo list packets exceed MTU, so we can not parse node names, and substitute the 4 hex of ID. Which is a bit confusing if there is a lot of traffic, know who's who...

But I think there are packet types that get passed over the mesh that are smaller and contain the names. I need to read more on the meshtastic protobuf documentation. If so I am going to try to have it update the names when those packets arrive. That is an inconvenience, but it's still a functional app at this point.

[g0730n]

I figured out a solution for the naming. NodeInfo packets have the long name in position before the shortname. Becaude the shortnames are often a single emoji, and outside of mtu size. I completely dropped looking for shortname and if possible use the longname in node list before defaulting to hex id.
This seems a better solution and any nodes in list that get populated from a node info broadcast seem to show the name.

I have two other apps in my repository I am getting ready, before doing PR. These were the first 2 apps I made and didn't want to submit them in their current state.

[gfwilliams]

That sounds great, thanks!

You can always do a branch off the main app loader, copy just one app's files into that branch and do a PR - you don't have to submit everything at once (in fact for us it's better if submit apps one at a time really)

[g0730n]

Sounds good. I am not too familiar with github procedures but I will do the proper research on how to do all this and you wil get a PR shortly.

[thyttan]

PR at espruino/BangleApps#4368 .