Anyone care to collaborate on a UI for WiFi Chat Interface

Anyone care to collaborate on a simple UI for a WiFi Chat Interface?

Here’s what I have – it doesn’t look great:

What I’d like to do is to provide two JSON end points – one for the chat history and one to submit messages.

I think this would need some combination of HTML, CSS, JavaScript with xmlhttprequest to get updates from the device and send messages. No graphics at this point. Everything has to be very lean and small in footprint.

Everything needs to be hosted directly from the embedded web server, nothing from the internet. Using jQuery or other big frameworks would be discouraged, but feel free to make a case for it.



@mc-hamster I may be able to assist with some guidance


Which lora hardware do you have? I’ll send you the latest firmware.

Also, are you on Windows, Mac or Linux?

Let’s start with getting you able to use the WiFi firmware builds and I’ll show you what’s there.

Thanks mate!

Good point - I think everything being client side HTML/Javascript is a great way to go. And then have that code to PUT/POST/GET to a small number of REST endpoints.

1 Like

@mc-hamster First the bad news - I ordered my T-Beams 3 weeks ago. Delivery expected Sep 29 - Oct 20. I’m in Australia. Our postal system is overwhelmed for the lock-down in Melbourne.

I prefer Windows, but can use Ubuntu if prefered at your end.

I’ll send a message with further details.

1 Like

We’re on the same page.

Hi people.
I was away for a while for work, I didn’t have much time to discuss here on the forums.
Returning to @mc-hamster question.
Give me the pixel display dial of the web Ui you want, also tell me the things you want to put inside (1-2-3-4…) the Ui so I can draw something by hand.

Hey TT,

@chucknitro Has started working on the basic 1.0 html chat UI and there’s the start of a conversation of frameworks to use in Slack.

Join us in slack :slight_smile:

  • Jm

Are you looking to build this while the device is connected over serial?

We have builds with this working on WiFi but development still happens over the serial boot loader.

1 Like

Just having a guess (correct me if I am wrong) the new firmware also broadcasts an wlan-ap and simple web server and you’re looking to serve webpacked/wasm files on the server that will call the python/c++ library through REST?

Almost exactly spot on.


Oh interesting, how much space on the target? I haven’t used vanilla in a while mostly targetting arm6/7 and x86 these days :slight_smile:

The target is the esp32.

It’s a fairly capable and inexpensive chip that does a whole lot. You can get development boards with all the supporting components for about $3 or $4 shipped.

1 Like

I think I have 3 Esp-Node MCU’s lying around somewhere collecting dust. I shelved it after having issues with getting rust to run even blinky on it. Is there a git somewhere, could contribute outside my 9-5

That’s what I started with for the esp32 a few years back. The tool chains are easier now.

1 Like

Keep in mind, the target is ESP32 which already has Mestastic-device installed/running, right?

I think (for the the TBeams at least) that means 4MB of Flash and 500-ishKB of RAM - and the device firmware is already about 1.1MB (in v0.9.1).

I can’t quickly see anything in the source code that looks like a webserver, so that remaining 2.9MB (or possibly way less if Meshtastic supports any devices running 2MB variants of ESP32) will need to contain both the webapp with all it’s assets and the webserver binary code added in to the mestastic-device firmware.

So no, it’s not going to end up being a modern cool front-end Reactjs or Fluttr SPA with a meg or so of minified js to make it work… :slight_smile:

Well I digged up at ESP32 and have a webserver using ESPAsyncWebServer, uploaded to the FS, a html/css/js file through Platform IO and is working fine reaching out to C++ and JS on the FS. Just scouring through the device code and android app unfortunately not a java/kotlin dev so just looking at the messaging fragment to understand how the calls are being made probably irrelevant because I’m guessing BLE.

Not sure of the design language maybe just the barebone material assets to make it look like the android app perhaps? or size limitation but I would assume worst case. I suspect I should be looking at the gRPC files too…

Okay just saw the dev-wifi branch silly me.

I decided to use the synchronous web server in the SDK because there’s so much other things going on with the project that I wanted something simple to debug. Responding to requests is a blocking call and on my todo is to move the server into a FreeRTOS thread to reduce the risk of this non-critical piece getting in the way of the Lora / Mesh functions.

If you think we can use the async server, after implementing a few json end points and the first pass of the UI, I’m totally down to work on switching it over with you. From experience with the pre 2.0.0 SDK, I thought performance would be really bad but after doing some profiling a few days ago with the updated SDK, I’m seeing the ability to respond to requests in well under a second (about 300ms avg) – and that is with the WiFi power saving enabled.