mDash WebApp custom upload - what is it expecting?

Questions & Answers
#1

I’ve been looking at the WebApp hosting functionality of mDash but can’t seem to get a result based on what I’ve tried.

I’m building my PWA in flutter, and when hosting the app locally am getting the result I expect.
When zipping it up and using the “upload mobile app .zip file” to publish, I see nothing in the little preview box or in the unique link, just a white screen.

The only way I’m able to reproduce this is to open the index.html file in my browser and I see the plain white screen.

Not sure what I’m missing, can anyone tell me how they are developing/publishing their PWA with mDash?

#2

We started using the mDash WebApp hosting initially but quickly moved it offsite as it was fairly limited its capabilities. We wanted a custom domain name and CI/CD deployment which were not viable if hosted on mDash.

We opted to go with Netlify and have no regrets. It’s a fabulous platform and free to use for modest sized sites.

The only caveat here is that Netlify (and most other top-tier hosts) force the use of HTTPS for all connections for security reasons. They won’t allow you to make unsecured HTTP connections to your ESP32 which is needed to provision WiFi credentials and register devices. We had to move the Add Device / Registration functionality to a separately-hosted site that will allow this. Forge is one such host that will allow mixed HTTPS/HTTP connections.

-AD

#3

Just the person I was hoping to hear from, thanks for your input @Autodog.

Hmm I had just assumed I’d have to do this using GATT Bluetooth - can you share more about the provisioning process you mention here that requires HTTP?

I’m starting out with Flutter, would appreciate any feedback/shortfalls/lessons you might have around working with mDash.

#4

WiFi device provisioning is probably the single biggest pain point in launching an IoT product. There are so many ways to do it and all of them seem to have drawbacks. When it’s not done well it drives customers nuts.

For an ESP32 + mDash solution, there are several options:

Web App + HTTP
This is the method used by the Smart Light example. Basically the firmware implements a WiFi AP + simple HTTP web server. The user interacts with a publicly-hosted Web App. When time to provision the device, the customer must switch their phone/PC WiFi settings to connect to the device AP network. The Web App then writes WiFi credentials to the device via HTTP and then reads back the device’s public key which is then used to register with mDash (after switching WiFi connections again).

It’s not very user-friendly, but it does work - at least until Chrome implemented their new Private Network Access policy which effectively kills this whole method (as noted in this thread).

I would strongly recommend against this implementation.

Captive Portal
This can be much nicer user experience as there are numerous, mature ESP32 libraries that do this quite well. As noted here, mDash adds some complexity as you still need a way to read back the device public key and register it with mDash. Not sure how to do that yet, but if there’s a clean way to do so it could be a good solution as no custom app development would be needed.

BLE
BLE holds the promise for a very nice user experience as there is no WiFi switching that often trips up users. Of course this means you need to roll your own BLE-enabled app which may have its own challenges: iOS and Android have their own BLE quirks, nevermind trying to support MacOS or Windows.

Flutter may hold some promise here if you can find a solid & reliable BLE plugin.

Smart Config
SmartConfig (aka ESP-Touch) is a wildcard that holds promise as no BLE is required, nor does it require WiFi switching. Also allows the potential to provision multiple devices at once. The challenge I see is that there are relatively few libraries out there to use with multi-platform frameworks like Ionic or Flutter so building a SmartConfig-enabledapp may not be easy.

Hope this helps!
-AD

#5

Thanks for the detailed response.
It really feels like a “choose your own adventure” and work out which has the acceptable roadblocks.

Looks like this option has been removed?I might rename the thread as I feel like it’s morphing as I gain more knowledge, but here is the landscape as I see it right now as someone new. Again would love your opinion on the flavour of roadblock I might see.

Web App + HTTP
I saw your other thread @Autodog saying this method is getting stitched up so probably worth staying away from this one.

Captive Portal
This has been great for me so far, but I’ve not yet had to register customers so have not experienced the mDash registration nuance. I feel like this method will likely hang around for a while since most public WiFi services seem to use this method.

Long shot but I did a little mucking around and it appears that while my phone was “setting up” the device I was still getting notifications, so both network connections were maintained. I doubt it but might be something there.

Re-reading your “Web App + HTTP” feels very much the same as this method, I wonder if there might be some overlap to be able to do what I’ve mentioned just above.

BLE
For a small product/team I feel like the only viable option would be some platform like flutter that would enable multi-device support from a single code base, so the notes below are based on that.

  1. Custom app implementing BLE for iOS/Android
    I’ve heard good things about flutter_ble_reactive but from what I can tell only Android and iOS are supported, not web.
    Releasing and maintaining this sounds like a real PITA though.

  2. Web app implementing BLE that could be run from Android/iOS device or Laptop
    I’ve just tried the flutter_web_bluetooth package and while it works from my laptop it doesn’t seem to have good support from mobile browsers, especially iOS

Lots to think about and explore

#6

Indeed.

If you’re debating between Captive Portal and BLE, the big difference is where do you spend your development?

  • Captive Portal everything is in firmware so there is no app to write (at least for WiFi provisioning) which is a big plus.
  • Flutter + BLE means you’re now a mobile app developer with all the fun that entails. Maybe you already have to write a mobile app anyway for other reasons in which case might as well add in the BLE capability. I would avoid web BLE, however, since Apple seems to have no intent to ever support it on iOS

If we were to start again today (and we may have to thanks to Chrome/CORS) I think we’d focus on the Captive Portal approach - if we can figure out how to make that work with mDash registration.

-AD

#7

Yeah it’s a slippery slope.

Now that I think about it, the main reason I considered an App was to allow customers to view their data! And now I’ve spent days thinking about provisioning which is already solved (have not had anyone complain about it) using captive portal.

Please circle back here if you figure it out and tell us all how to do it!