[Feature Request]: Basic send/receive messages via access point on ESP32

[redfast00]

Platform

ESP32

Description

Is there any work on making an ESP32 meshtastic node start an AP, host a web server and small web UI to send/receive messages? The advantage over having to use bluetooth and the meshtastic app, is that you don't need the meshtastic app, so you can hand out nodes to people and they can use them from their phone.

Someone told me that this used to be supported, but was cut in the 2.0 release because it didn't work very well. What is the main blocker to implement this?

[madeofstown]

Get an Android device. ESP32 devices support WiFi already, it's the the Apple App that does not support connecting with IP address.

You can also connect and manage the device from the Meshtastic web interface if you run it from a machine on your network.

[caveman99]

Someone told me that this used to be supported, but was cut in the 2.0 release because it didn't work very well. What is the main blocker to implement this?

The Node runs really hot in AP mode which makes it unstable. Also people were having expectations it would never be able to meet. AP Mode in ESP32 is essentially a way to configure it, while people were hpoping for some kind of hub to share the one radio connection.

[redfast00]

@caveman99 I'm willing to look into reducing AP mode power consumption: I'm one of the lead developers of esp32-open-mac, where we reverse engineer the ESP32 wifi peripheral, so I know quite a bit about Wi-Fi on the ESP32.

For my usecase, it would serve as a way to use Meshtastic from a phone/computer without having to install any software, not to share the one radio connection.

As I said, I'm willing to look at reducing AP mode power consumption, but only if AP mode would be on the table for Meshtastic (not saying you have to re-implement it again, just that there is no blocker against it). If power consumption were about equal to or less than STA mode, would AP mode be on the table again?

If not in Meshtastic itself, is there a way to have it as a plugin or external code or something?

[garthvh]

The he issue is not power consumption, the captive portal and bad user experience of being connected to an ap with no internet is the issue.

[redfast00]

@garthvh how I envision this, is that it's not for regular users to use, they would still use the app + Bluetooth; but in emergency situations where there is no internet, you can hand out nodes to people without having them have to install a new app (which they can't do since there is no internet).

[redfast00]

The web interface could even say 'This is not the best way to use Meshtastic, for a better interface, please use the app' or something

[fifieldt]

@redfast00 what about pre-configuring the nodes to connect to a specific SSID, then setting up a hotspot on the phone with that SSID?

[redfast00]

@fifieldt that's a useful alternative, but it's a lot harder to do for non-tech savvy users: instead of just tapping a network to connect and entering the password (an action they do regularly), they have to set up an access point, configure it right, somehow find the IP of the mesh node, enter that in their browser (possibly also with a port number, but I guess we could make this :80). On my phone (which is a pretty recent Android phone), setting up a hotspot does not work.

I'm looking for something I can just hand out with minimal instructions or handholding needed.

[garthvh]

Esp32 ap mode is all handholding, is a really bad user experience with modern phones, it won't work as you are expecting.

[fifieldt]

@redfast00 had a look at esp32-open-mac, nice work! Based on your experience, would you be able to estimate how much extra resource would be required on an esp32 device to enable AP mode? Our firmware is packed in pretty tight.

[fifieldt]

old softAP thread , for reference #1835

[redfast00]

@redfast00 had a look at esp32-open-mac, nice work! Based on your experience, would you be able to estimate how much extra resource would be required on an esp32 device to enable AP mode? Our firmware is packed in pretty tight.

Sure :) As far as I know, the main resource use with SoftAP mode is not CPU/RAM, but the amount of packets it sends: in the default configuration, it will send a beacon packet every 100ms, so 10 times per second where it uses the 2.4GHz radio to transmit. I haven't tested this (for lack of a power profiler) but I suspect that reducing the beacon interval will reduce the power consumption by a lot. I'd also have to check what hardware filter configuration they use: the hardware supports filtering packets based on MAC address to reduce the amount of packets they have to handle in software.

[fifieldt]

I'm guessing you'd also need a dhcp server and maybe a DNS server, as well as captive portal software to redirect the initial http requests to the dashboard?

[redfast00]

Ah, fair point, I forgot about those since most of my work is on the lower layers. The captive portal software should be very minimal though, it basically just redirects all web requests to the local web server

[redfast00]

So, as far as I can see, the main drawbacks to implementing AP mode with a UI to send messages are:

• "Modern phones make connecting to a self signed cert / wifi with no internet problematic" -> this is two separate issues, I think:
  • the access point has no internet access, so phones might complain and connect to a different network when available
  • the web interface has a self-signed certificate -> this can be solved by using HTTP instead ofself-signed HTTPS
• "a lot of users assume this is an off the grid way they can serve the webui to a number of devices which has never worked in my testing" -> I think this is either a technical issue, or an issue of expectation management; both can be solved by minimizing the functionality that is available over SoftAP to not much more than transmit/receive, and explaining that other features are available by using the app
• the ESP32 chips get hot in AP mode -> this is a technical issue, I can look at solving it; likely by buying a power profiler and doing some experiments

I agree that the user experience is not as good as with the app, but this would be a feature for people who can't install the app. I'd really like to have a node I can just hand out to people in an emergency situation without them having to install an app.

[fifieldt]

I think we also have code that limits API connections to one at a time. For example with stand-alone devices using the meshtastic UI, there's no Bluetooth or wifi since that "connection" is used by the UI code. So an AP might have to be single connection to deal with that too.

[thebentern]

Indeed, and Meshtastic has always been a 1 <-> 1 relationship between Node to User. Even if a Web UI is able to serve multiple clients in the interface sense, you will appear as a single user on the mesh. The concept of this use case is more in line with how Disaster.radio was setup from what I can remember about that project.

[garthvh]

It was removed because while it existed there was no way to manage the expectations, the experience is awful. The ap function exists as a way to set Wi-Fi credentials and then boot into that network, which does none of the things you want. Sounds good in theory and is a technical and support nightmare.