OMG that sounds amazing (and quick!). As soon as you have anything (even super rough) up on github I’d love to try it out. Also @jeksys I bet would be willing to take that code and build it for iOS? I suspect we could fairly quickly grow your app so it becomes quite a nice cross platform (Android + iOS) client.
ionic is better more community nd easier for developers
Though I’m in favor of whoever starts coding pick what they want to use. . I’ll learn it and help their app.
I can provide MacBook pro with iPhone attached via TeamViewer (or anything else) every day 08:00 - 16:00 (UTC +1)
It’s not about that, going straight to coding in this case can do more harm than good. We should consider how many within the community can help with app development (not testing) and whether we have the expertise to bring it to a functional state without requiring external input.
I am very interested to switch to another app development to support iOS.
I see the tons of commits from @geeksville to fix the bluetooth issues to support phone with Android 5 to Android 10. I can test with Android 6 and Android 10, my fear is to not be able to help fixing issues happening for iOS phones.
It gaves us an opportunity to keep the things simple and find a way to give the devs a better feedback system for bug fixing.
Agree. And such feedback is useful. But fundamentally if someone says they are willing to start coding a new app and they want to use technology A vs approximately equivalent technology B:
(Personally) I’m going to help them in either case. Because it is rare for people to step up at that level and it gives me an excuse to learn something new.
And by popularity it seems like flutter is doing quite well (higher than ionic and going up - and ionic seems trending the opposite direction)
Interesting. I assumed React native would be higher but going off of Google trends it looks like its somewhere in the middle.
Actually flutter is backed by Google
Anyway whatever technology works, it’s fine as long as it solves the problem of having a multi-platform app.
From my personal side I can develop the skeleton in Ionic but the implementation of Bluetooth and mesh protocols is something I’ve never done.
Hey sorry guys I haven’t said anything since then. I haven’t been able to get started yet but I was getting back in the hang of Flutter last night by finishing a feature I had long forgotten about. Just to temper expectations: for now I’m just wanting to make an app that does the first stage to show in theory that it will work. It isn’t gonna be written to handle the usecases of the Meshtastic app, at least not for now.
The biggest challenge is that I’m gonna be writing this blind and working just off the protocol, python implementation, and API notes that geeksville has thankfully written. I can’t guarantee when I’ll be done, but I’ll keep you all posted.
Edit: I’ve started writing the app. Right now it doesn’t do much: just searches for BLE devices and highlights those that match Meshtastic’s service ID.
I won’t bother putting out test APKs until I get some Meshtastic-specific functionality implemented.
@Anelito, Luckily Meshtastic-devices handle the mesh automatically. The app has to be able to pair with Bluetooth, send user+channel settings (a certain packet/message) to the device, read packets (messages) from and write packets to the device.
Fortunately, @geeksville have documented these operations well. https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/bluetooth-api.md
Good luck with the app!
I was wondering how big of a deal would it be to add a XMPP server in the ESP32/Meshtastic code so users could use ANY XMPP client to interface with a Meshtastic device? I have been working some ESP32 code that establishes a connection with Astra chat on my iPhone, but I don’t have a good understanding of XMPP yet and I definitely don’t have a good enough understanding of Meshtastic to integrate something like this into that code.
I like the idea, but XMPP servers are fairly complex, so it would be difficult to put one on the ESP32 or any of the currently supported Meshtastic targets. The ESP32 is fairly constrained (as are most of the other Meshtastic targets) in resources – at best, you’ll have a few megabytes of RAM to work with, as opposed to the tens to hundreds of megabytes of RAM needed to run most XMPP servers. This doesn’t even factor in the considerations for storage, which are extremely limited on current Meshtastic targets.
If you’re looking to interface XMPP to Meshtastic (as a network), consider bridging MQTT to XMPP, as there is some preliminary work on enabling MQTT on Meshtastic, as well as some future work planned for Meshtastic to bridge to Matrix. Another approach would be to take advantage of the TUN support in Meshtastic – attach a Meshtastic node to a PC running XMPP, and start the TUN adapter via the Python CLI.
Note that it’s possible to make an XMPP client (which is much simpler) on the ESP32 – and it appears that there have already been several projects for this. Interfacing with this would require an external server – and it sounds like that’s not what you’re trying to do.
If you’re looking for an app-free experience on a phone, @sachaw is working hard at making a web-based GUI, accessible from a browser, hosted directly on Meshtastic devices. (From what I understand, it offloads much of the computational tasks to the web browser/client, which would be awkward for XMPP.)
Yeah, currently a PWA is the easiest way forward, looking for contributes on my repo hopefully we can start bundling it with device firmware soon.
I guess I should clarify a bit. I was not thinking a full blown XMPP server that would handle multiple users/clients. My thought was just enough of a server to manage handshaking with one client connecting to it so a user could download any XMPP client app(like Astra Chat) and have a familiar UI. My desire would be to get notifications on the phone(the phone buzzes or beeps in my pocket) when a message was received from the Meshtastic device. My intended application is to provided text message functionality on youth camp campground for the staff. The campground is basically off grid, out in the sticks as we say it. The campground is about a half mile square. I have done some testing on site with my Tbeam and TTGO LORA32 and basically covered from one side to the other. i can only imagine coverage would be even better with meshing. I am thinking around 10 or 20 devices (one for each staff member) total covering the area, but notification is NEEDED for this application.
Maybe run the ‘full stack’ for XMPP servers on raspberry pi zeros and use Meshtastic to link the individual servers using the MQTT features recently added.
What would be really cool is what was mentioned before, a PWA (Progressive Web App) that has a richer chat interface / features and allows more than one user / identity to natively use a node over wifi.
Something that should be easily possible for a single connected user per node.
I have not been able to follow as closely as I use to as of late but from what I remember the underlying layers assume there is only one users per node / phone. I’m not sure if that was changed in the 1.2 branch but I do distinctly remember it being discussed as a bit of a limitation a long time ago.
As much as I’d love to bring XMPP into the mix, “just enough” XMPP server for an XMPP client to connect to it would be fairly difficult on the ESP32, still. Doing so would cut down on the RAM footprint (as you’d no longer need to support multiple users on one connection), but you’d need to translate XMPP concepts onto Meshtastic concepts. I don’t think that would be trivial to do (I know of no XMPP servers that I could trim down to less than 4 or 8 MB of RAM).
For example, while such a stub server wouldn’t need to maintain multiple connections locally for each user, it may still need to create phantom users for each remote node on the mesh. Messages could be relatively straight forward to translate, along with message acknowledgements
Sport7biker’s idea for multiple full-stack XMPP servers would be more feasible, as you’d have a more capable Raspberry Pi running the XMPP server – but I’m not sure it would make a lot of sense for this particular deployment to have multiple (federated?) XMPP servers.
But if you can have one Raspberry Pi (say, Raspberry Pi Zero W) per mesh node, that gives you a lot more flexibility. Given the amount of resources available to a Raspberry Pi Zero W, you could, in fact, gut an existing XMPP server and replace the core communications with whatever you want – including a backend supporting Meshtastic, which would allow you to connect with a conventional XMPP client. Unfortunately, there’s a huge drawback to this; the power requirements for the Raspberry Pi Zero W are enormous compared to Meshtastic.
Running a single XMPP server on a single Raspberry Pi attached to a Meshtastic node would be fairly simple; its biggest limitation here would be a single point of failure, and reachability (direct or mesh-routed) to that node would be necessary for communications.
I’m still inclined to say that your best bet is probably the webapp. I hear sachaw welcomes PRs.
@jdstroy thanks for sharing your opinion with me regarding my idea. I had no idea how feasible it would be. I understand memory is very valuable in this project. There is a lot going on in that ESP32. I have played around with ejabberd on a raspberry pi in the past and that was very easy to set up. I may have to dig out that old RPi and play around with that.
Just a thought, have you used the Meshtastic Android client? Would it suit your needs?
If you have to have something that’s more familiar and you already have the hardware (which, it sounds to me like you already do), I think the approach of using Meshtastic as an IP layer transport for XMPP might be worthwhile.
You’ll need something like two Raspberry Pi devices, and perhaps three Meshtastic nodes. The logical topology would look something like:
[Meshtastic Node 1] <<--[serial link]->> [Raspberry Pi client XMPP] ^ | [RF link] | v [Meshtastic Node 2] ^ | [RF link] | v [Meshtastic Node 3] <<--[serial link]-->> [Raspberry Pi XMPP server]
If that works reasonably well, I think I recall someone interested in implementing a TUN client on Android for Meshtastic. You’ll probably want to run some kind of duplex testing (perhaps a bot that sends unsolicited timestamps every 15 seconds) to see how congestion impacts XMPP traffic on Meshtastic as well. (Don’t forget to factor in TLS overhead if you want C<->S privacy.)
For some idea on power consumption, take a look at:
In the hypothetical case where you have a gutted XMPP server running in under 4 MB of RAM on an ESP32 on the T-Beam, you’ll need to keep Wi-Fi on, which will also mean drastically higher power consumption, as (IIRC) the ESP32’s power domains would require the Xtensa core to remain on as well for Wi-Fi as with BT.