Custom HTTP Endpoints

Autodog · December 27, 2020, 12:09am

Greetings,

When a new device is provisioned with a device in AP mode, mDash creates an HTTP server with the /setup and /GetKey endpoints to interact with the user’s WebApp. This works, but we’d like to create additional endpoints to improve the provisioning process. This would enable us to convey additional data with the user.

Question: Is possible to add custom HTTP endpoints with mDash?

If we create an endpoint using conventional esp-idf HTTP libraries they don’t work as it appears mDash intercepts all HTTP traffic to the device.

Thank in advance!
-AD

lsm · December 27, 2020, 11:45am

The HTTP handler is defined in the guts of mdash library, it uses data structures that are not exported to the user. So the short answer is “no, not possible”.

Could you elaborate more on what do you intend to implement, please?

Autodog · December 27, 2020, 4:32pm

Our intention is to implement an HTTP SSE endpoint to report WiFi scanning details (SSID & RSSI) to improve the WiFi configuration process. We’ll also have an endpoint that declares the FW rev so that the WebApp can know the device capabilities.

Would something like this need to be integrated into mDash or is there a way for new endpoints external to mDash to coexist with the mDash library?

-AD

lsm · December 29, 2020, 7:11pm

These things - WiFi scanning, and reporting some configurable value, sound like a generic features that belong to the mdash library.
We’ll implement that for the next release, expected in Q1 2021.

Autodog · December 29, 2020, 7:45pm

That would be a very welcome and valuable addition.

We might suggest implementing an SSE endpoint that includes SSID and RSSI values in a JSON object that represent a quasi-realtime view of the device’s WiFi scan results.

If we were to implement something like this external to mDash in the interim, is there a way to temporarily stop/restart the mDash library and/or start mDash w/o WiFi?

-AD

lsm · January 1, 2021, 3:38pm

Why SSE, not a regular REST? The scanning might take a couple of seconds, is that a too high price to pay?

If you want to manage WiFi separately, take a look at mdash.h:

github.com

cesanta/mDash/blob/master/src/mDash.h#L36-L44


// mDash housekeeping
void mDashInitWithWifi(void (*fn)(const char *wifi_name, const char *wifi_pass),
                       const char *wifi_name, const char *wifi_pass,
                       const char *device_id, const char *device_pass,
                       const char *app_name, const char *build_time,
                       const char *framework);
void mDashInit(const char *device_id, const char *device_pass,
               const char *app_name, const char *build_time,
               const char *framework);

Specifically, the mdashInit() function assumes that WiFi is set by some external way. Do whatever discovery is required, join WiFi, and when IP address is obtained, call mDashInit() to connect to mDash.

Autodog · January 4, 2021, 6:46pm

Thanks for the advice regarding mDashInit() - we’ll take a look.

As for SSE vs. a REST endpoint, SSE seems like an elegant way to implement a quasi-realtime streaming of scan results (SSID + RSSI) without requiring the client to continually poll. If there is significant overhead or other negatives implementing SSE in the device FW that would be good to know.

-AD

lsm · January 9, 2021, 3:28pm

Thanks.
The IDF API returns scanned network list in one go, not one by one. See ESP-IDF API reference
How do you see a quasi-realtime approach applied in that situation?

Autodog · January 14, 2021, 4:40am

Yes, esp-idf does return scanned results in one go as you’ve noted.

So perhaps “quasi-realtime” is not the best terminology, but SSE gives us a way to push this streaming data to the client and it seems to work well enough.

I’m sure that polling a GET endpoint could achieve similar results. SSE does have new data for each update whereas that may not be the case for async client polling.

-AD