How do users connect IOT device to WiFi?

[frozenfrogz]

Search the web for ESP8266 WiFi manager. There are a couple of options. I like running the device in AP mode without password on first boot (and accessible via button, optional), connect to the web server running on it, input the WiFi credentials it should connect to and then let it reboot into client mode.

There are various options, but that is my preferred way.

[soldar]

You might want to have a look at https://en.wikipedia.org/wiki/Wi-Fi_Direct

[Kasper]

Now that summer is over, I am being a bit more productive lately.  Got the access point and webpage solution working fairly well except I need to read IP addresses from serial monitor and only works on local network.  This is how it works:

1 - Hold button on power on to enter AP mode
2 - ESP creates network and webpage for wifi credential entry
3 - On user's device, join ESP32's network
4 - Read IP address from serial monitor
5 - Enter IP address in browser
6 - Enter wifi credentials for home network into ESP32's webpage
7 - ESP32 saves wifi credentials in EEPROM
8 - Reboot ESP32
9 - ESP32 joins home network and creates webpage
10 - On user's device, join home network
11 - Read IP address from serial monitor
12 - Enter IP address in browser to go to ESP32's webpage and control it

Next problems are with steps 4 and 11.

Problem a: consumers can't read IP address from serial monitor.
Problem b: I don't know how to access ESP32's webpages from outside my home network.

Solution:
Learn about DNS? 
I think DNS is what I need but the tutorials I am seeing are not something I can expect consumers to do, they download software onto a local PC that is always on and get into home networks router settings.  There must be a better way.  Do I just need to learn more about DNS or is there some other way to do this?

How do users know how to find the ESP32's webpages?

How do I make those webpages accessible from anywhere?

How do I make them unique so all the units I sell won't all have the same address?

[antintedo]

For initial configuration: implement a captive portal. Good OS support and easy to use, users don't have to type in the IP.
For device discovery in LAN: mDNS and/or SSDP. ESP SDK seems to support mDNS and there are libraries for the other. Obviously both will be able to differentiate between multiple devices of the same model.
For access outside LAN: reverse proxy server on the internet that each ESP connects to. MQTT is used in many IoT devices but it does not fit the use case with the webpage.

[Kasper]

Thank you for the suggestion. mDNS looks like it should work for LAN side of things.

For access outside the LAN, are you saying I need to run a server that all my users use? There's got to be an easier solution. I think users should be able to type their home network address and the name of my product into their browser and get access to it. Is that not possible? 

Please feel free to dumb it down for me. I am not familiar with internet, took one networking class in college 15 years ago and haven't touched it since.

[sokoloff]

Think of it this way; your users have overwhelmingly configured their home network such that devices on their network can reach the internet. Far fewer of them (almost none) have configured their network to allow inbound access to your device.

Take advantage and make use of this natural condition. Run a server (or API gateway) in the Internet. You can do that super cheaply and easily nowadays with any number of cloud providers. I happen to have chosen AWS, but loads of options are other there.

[Kasper]

Even if it is easy and cheap to run a server, does that not mean I have to keep it running through the lifespan of my product?

[sokoloff]

For users to use whatever functions require internet connectivity, yes.

[Kasper]

That'd be a 10 - 20 year commitment. Are there really no other options?

[jhpadjustable]

mDNS resolves names on the LAN. UPnP (where permitted) enables the firewall to translate requests from the WAN address to the LAN address space. The problem is that the WAN address is not guaranteed not to change from day to day. Users may not know their home IP address from day to day, or properly, the address of the WAN interface on their router from the perspective of the global Internet, and may not be inclined to set up their network for a dynamic DNS service of their choice (no-ip, Dyn, etc.). Perhaps your UI can offer them a way to automate that setup, but then you're depending on you and/or the companies who offer it collectively maintaining a 10-20 year commitment to those services.

One other option is to just be like Revolv, get bought by Google, and let them take the heat for bricking your product 

[sokoloff]

It’s probably cheaper to plan to run the server for 20 years than to engineer and customer support a way around that.

[Kasper]

ugh, I can hear the shelf calling my project back to its resting place.

If I make an app instead of using a webpage for control, that would not solve this problen would it?

[cyberfish]

There's really no need to have a manual way to enter configuration mode. Just try to connect with stored SSID/password, and enter configuration mode (AP mode) if connection is unsuccessful (or non-existent on first boot).

Most common reason why users need to change SSID/password is if they upgrade their router, or move somewhere else. In both those cases, the connection will fail, and the user can put in a new one.

If a power user wants to switch the device from one router to another, she can just turn the old router off for a moment and restart the device.

This only doesn't work if the neighbour decides to set up a network with your old SSID/password that you can't power off, but this is rare enough that it's probably not worth worrying about.

This is what the Chromecast does.

[sokoloff]

Chromecast also has a factory reset mode. (Hold button for 25 seconds to forget all user data.)

[Kasper]

Think of it this way; your users have overwhelmingly configured their home network such that devices on their network can reach the internet. Far fewer of them (almost none) have configured their network to allow inbound access to your device.

Take advantage and make use of this natural condition. Run a server (or API gateway) in the Internet. You can do that super cheaply and easily nowadays with any number of cloud providers. I happen to have chosen AWS, but loads of options are other there.

This seems strange to me but thanks for your explanation I guess it makes sense.

I have no idea what to look for in a cloud provider.  I dont think I need anything fancy. My products will probably need less than 10 bytes of data a day from each user. I'd like to get one at a price that works for very low sales volume but can scale if sales go well.

What should I look for? Where is a good place to learn about servers or API gateways?

[Kasper]

There's really no need to have a manual way to enter configuration mode. Just try to connect with stored SSID/password, and enter configuration mode (AP mode) if connection is unsuccessful (or non-existent on first boot).

Most common reason why users need to change SSID/password is if they upgrade their router, or move somewhere else. In both those cases, the connection will fail, and the user can put in a new one.

If a power user wants to switch the device from one router to another, she can just turn the old router off for a moment and restart the device.

This only doesn't work if the neighbour decides to set up a network with your old SSID/password that you can't power off, but this is rare enough that it's probably not worth worrying about.

This is what the Chromecast does.

That sounds like a nice addition.  Thank you.

[Kasper]

For initial configuration: implement a captive portal. Good OS support and easy to use, users don't have to type in the IP.
For device discovery in LAN: mDNS and/or SSDP. ESP SDK seems to support mDNS and there are libraries for the other. Obviously both will be able to differentiate between multiple devices of the same model.
For access outside LAN: reverse proxy server on the internet that each ESP connects to. MQTT is used in many IoT devices but it does not fit the use case with the webpage.

mDNS was very easy to add to my arduino code.  Worked right away on my windows PC and iPad but does not work on android. 

Bonjour app: saw this recommended on various forums for mDNS on android but didn't work.  Wouldn't discover anything, just gave spinning dots.

Fing app: this works for android.  Lists IPs for everything on my network.  Android users must take IP from there and type it into browser.

And with that, I have an MVP (minimum viable product).  Not very smooth on android but it is easier than setup for my sonos speaker.

Thanks again for the help.  I think I will stick with this and make my initial goal be a product that works only on LAN and have stretch goal of remote access.  That way I can have a low initial goal and hopefully get some of these out there before I need to commit to a server which I really don't want to do if I only sell 10 of these.

[TomS_]

I'm so tired of the prevalence of apps and companies insisting that you must install their app to do rudimentary (and often, duplicate) things.\

Apps can do things that web pages cant.

For example, as long as the device is connected to the same network as your phone, you can simply open up the app, let it discover the things on your network, and you can then do stuff with them. That is convenient for most people who dont even know what an IP address is.

What are you going to do, tell your users to save a list of bookmarks to IP addresses for their things, that might change each time their router reboots because most of them also dont know what static DHCP leases are; or
Have an app that can talk to the device "by magic" (as far as the user is concerned)?

Personally I am all for the latter.

You have to consider who the target market is and what their skills and knowledge are. If your audience is purely technical, sure, forego the app and let them configure it via serial console or USB thumdrive or whatever. If your audience is consumer, you have to get a bit smarter or your product will probably be considered clunky in this day.

[sokoloff]

The other thing to consider is that almost any customer contact or question is going to kill your profit on that sale. Maybe something you choose to ignore in a learning or Kickstarter phase of the product, but at scale, you’ve got to drive customer contacts to near zero for most IoT type of products.

[Kasper]

Ive been the one taking the phone calls and handelling returns, I am familiar with what a nightmare it can become and I want none of that. Hoping simple operation and a good user guide will minimize it.