Android Question WiFi configuration

[johnf2013]

I have an app which consists of an Android device that processes real time data sent in large packets to it by an esp8266 over wifi. The app also send a few simple commands to the esp from time to time. This all works very well. It has been easy to get the wifi working in various forms using the assistance of this forum, but I am locked in to hard coded parameters.

So now my problem is how to set it all up for real users. Most people using this app will not know the difference between a mac address and a mac feast. I can hardly ask them to enter ssid, password and ip address.

After a lot (lots) of searching and reading I still do not have a definitive idea of the "recipe" to use. Almost all samples use hard coded ssid and other parameters, which is of course useless in production. What is the method typically used?

If I assume the user has a wifi then the esp is a station, and so is the android. This works and I use async streams, but how do I setup the esp in the first instance, ie. when the user first purchases the gizmo with the esp embedded in it. And even then, when the esp is setup, how does the android find it since it is likely to be on a dynamic address. I have tried using host name and that works but every device has a different name since it is composed of part of the mac address.

Or do I run the esp in ap mode and connect the android directly to its private network. Then I seem to be stuck with just a single default gateway.

I just need some direction here. How is this "usually" done?

If someone can point me in the right direction I expect no problems with the coding.

 

[Didier9]

I have an app which consists of an Android device that processes real time data sent in large packets to it by an esp8266 over wifi. The app also send a few simple commands to the esp from time to time. This all works very well. It has been easy to get the wifi working in various forms using the assistance of this forum, but I am locked in to hard coded parameters.

So now my problem is how to set it all up for real users. Most people using this app will not know the difference between a mac address and a mac feast. I can hardly ask them to enter ssid, password and ip address.

After a lot (lots) of searching and reading I still do not have a definitive idea of the "recipe" to use. Almost all samples use hard coded ssid and other parameters, which is of course useless in production. What is the method typically used?

If I assume the user has a wifi then the esp is a station, and so is the android. This works and I use async streams, but how do I setup the esp in the first instance, ie. when the user first purchases the gizmo with the esp embedded in it. And even then, when the esp is setup, how does the android find it since it is likely to be on a dynamic address. I have tried using host name and that works but every device has a different name since it is composed of part of the mac address.

Or do I run the esp in ap mode and connect the android directly to its private network. Then I seem to be stuck with just a single default gateway.

I just need some direction here. How is this "usually" done?

If someone can point me in the right direction I expect no problems with the coding.

One solution is to use the AP mode on the ESP8266 directly as you suggested but when you do that you will not have internet access on your phone or tablet. I use this in my apps but not with ESP8266 modules, I use other modules. I use this for things like remote control where you want very low latency and you do not need internet access on the phone or tablet while you use your app.

Another is to use the AP mode of the ESP8266 to configure it with your network parameters (the user has to know these) and once the ESP8266 has rebooted and connected to your network, open an unusual port >32768 on the ESP8266 with a function that provides a unique response and in your app, create a search function in your app where you quickly scan all the IP addresses within the range of the router (typically a Class C network) for something that answers on that port with that unique response. When you get the response, you know you found your device.
The problem with that is that your device may not always get the same IP address so it may be irritating to your user if the app does not connect every time and they have to use the search function periodically.

Another solution I have used is to connect the ESP8266 to your router with a fixed IP address, typically an address outside the range used by the router for dynamic addressing, or use an address way up in the range, like 192.168.1.200. But you have to know that this address will not be used by another device. This may work in your home but not be practical in a business setting.

I have also used a registry service with a server on the LAN, like a Raspberry Pi, or even an outside server on the Internet that you own or rent. This is useful if you have many devices connected on one LAN. The Raspberry Pi needs to be at a known address (the outside server could be accessed via DNS), the ESP8266 uses dynamic IP and once connected to your router it sends a message to the Raspberry Pi with its MAC address which allows the Raspberry Pi to create a table connecting the MAC address of the device with its IP address. Your app connects to the Raspberry Pi, downloads the table and the user knows which IP address corresponds to which MAC address. I use that method with data loggers. I have half a dozen devices collecting data throughout my property and they send their data to the Raspberry Pi which runs a web server creating on the fly plots of the data, kinda like ThingSpeak. It has been working well for several years. It is the best method for things like data logging or home automation (the Raspberry Pi can send commands back to the ESP8266 in response to the ESP8266 uploading data), but it is a little more complicated to setup. Once it works, it is pretty foolproof and extremely convenient.

The best way may be to use Wireless Protected Setup but I have not looked if this is supported in the ESP8266 and I am not familiar with it.

I have used all these methods aside from WPS. Bottom line, there is no simple, obvious solution which is why I also uses Bluetooth. It is quite a bit simpler for the end user.

Late addition: following a post from another member, he has a simple way to be able to communicate with an IoT device that uses DHCP and has no way to display its IP address. The device (an ESP8266) is configured to listen to UDP packets on a certain port. The app sends a UDP broadcast message to that port number, the device responds to the UDP broadcast. Very simple to setup, works even if the device uses DHCP and gets a different IP address each time. The only issue is that UDP broadcast only work on the local subnet. For most home applications, it's not a problem but you won't be able to control the lights via the Internet. If you have multiple devices, assign each one a serial number that the app embeds in the UDP broadcast message so that only that device responds. Very simple and requires little setup as long as the device connects to the access point.

 

[johnf2013]

Thanks for your answer. I will look into wps - good idea.

My intent was to use the 8266 because it simplified the hardware. I need to get data from two a/d converters and one optical pulse sensor. I also need to send a pwm signal to a motor driver (ssw), or an on/off to a solenoid valve depending on user configuration. These are very simple requirements and easily handled by the 8266. I also need lots of grunt. The proc must run 720 instances of a fir filter - one per degree from 2 sensors. This works (without the filters) on an Arduino Nano sending the data to a pc by usb. The pc implements the filters which it does with ease.

I will research further the use of wifi. Wifi's only issue is setting up the android and the 8266 in such a way that non-technical users can get it going.

Bt is easier as you say and should work fine. The obvious is to use an esp32. There could then be a choice of wifi or bt. Having read a lot on this forum I am not convinced the esp32 environment is mature enough yet.

Or, I could use an stm32 and connect a bt module. This is simple and cheap.

Or the whole thing gets trivial if the android runs the fir filters, but I have not tried this yet. Performance is the key. The data plot is refreshed at 50Hz and this is working on simulated data - two traces of 720 16bit integers. Maybe I should brush up on threading.

If I find a way to make this simple I will write it up here. It may be useful to others.

 

[Didier9]

I did not see anything in your response that would make WiFi preferable over Bluetooth (like distance, access across networks, multiple clients access to the same target). It seems you want to replace a single cable between an Android unit and an embedded system. Personally I would try Bluetooth. The advantage is that you would still have WiFi to connect to a PC since it looks like you may need to do that as well.

I have not compared the data rates of the two because my applications need short latency but data rate is not critical. Generally WiFi can be much faster but that depends a lot on the implementation, and Bluetooth may be sufficient for your application.

Anyhow, as you can see from my first post, WiFi can be used in a variety of ways that all have advantages and drawbacks, but none is generally perfect and all are a little bit of a pain to setup. This is not to say that Bluetooth does not have its own problems. BT can be finicky to setup and prone to disconnect or not want to reconnect for no good reason.

 

[Didier9]

Further reading your response, it looks like to want to do a fair amount of data crunching on the ESP8266. I am curious to see how that works. The ESP8266 has program storage in an external serial flash and it has a relatively small internal instruction cache in RAM (forgot how big). It seems that it could be prone to spend good amount of time reloading its instruction cache and that would put a real damper on most real time tasks you are asking it to do.
In my applications, I use a dedicated WiFi module for communication (not an ESP8266 but I am looking at it as a lower cost replacement) and a microcontroller for everything else. The two communicate serially at 115,200 bauds. So the microcontroller is available for all the real time stuff.

 

[johnf2013]

Further reading....

You are absolutely correct. Well, it was good brain food while it lasted. I have a number of esp-01's which I have flashed with micropython and also put bigger flash chips on. They are fun to play with but it seems not very useful for doing fast things. The esp32 is better by running user code in a separate thread, though probably overkill for this project.

I did manage to get the wifi configuration working by modifying some excellent code from Erel - ESPConfigureWiFi.b4r, but have decided I can't justify wifi for this app - to much trouble and not enough benefits. I will save this technique for a rainy day.

After evaluating everything and reading helpful replies I have gone right off the esp8266 and the esp32 for this application. I will do it your way, which is what I had in mind weeks ago before I started playing with the esp's. I will use an stm32 (blue pill) and a bt module. I may need to add a small flash chip too because there is none on the blue pill. This is a very low cost solution. No matter what solution I choose I need a custom pcb to manage motor drive, optical sensor, and power supply so whether I solder an esp-01 or a blue pill to the board matters little.

One other option I will look at is using the nrf51822 bt4 module. I have a couple of these and a small development motherboard for them. They can be setup with an arduino bootloader. I have nano code which works for this project so it should not be too difficult to get this going on the nrf. Again, the issue of performance will need to be looked at and how user code will interfere with the bt thread. Any thoughts on this would be appreciated.

Note, this product is not very cost sensitive. My partner and I don't expect to sell very many, however there is a significant manufacturing cost in the associated hardware. The control app is free. A little extra for the electronics is not a real problem.

 

[Didier9]

No matter what solution I choose I need a custom pcb to manage motor drive, optical sensor, and power supply so whether I solder an esp-01 or a blue pill to the board matters little.

My feeling exactly. I am in the same boat with my projects. I had to explain to my customer that I would not save anything by replacing my 8051 with an Arduino because the Arduino board will only replace the one 8051 chip, I still need a custom PWB for all the high current IOs, protection switches, LED indicators, switching regulator, XBee radio module socket (I use one of those too because some remote stuff is half a mile away), hex switches to select options, screw terminals to connect the wires, a convenient socket for the optional LCD display and so on. So at best I would replace a $3 chip with a $15 board which may or may not be available next year and will make my product larger. Right now, the entire board is smaller than the plain Arduino Uno. There is no room for even a Teensy or the blue pill. I have attached a picture of one of my boards that has both a WiFi module and an XBee long range radio. This is one of the two boards I make that work with an Android app.

 

[johnf2013]

...I have attached a picture of one of my boards that has both a WiFi module and an XBee long range radio. This is one of the two boards I make that work with an Android app.

Nice looking board.

I have been using the 3DR 915MHz modules for long range radio and have been very satisfied with their performance. I try to avoid 433MHz here in Oz because I consider it crowded. The 3DR modules are spread spectrum and the 900meg band is less crowded. I have a 9 element yagi on a homemade tracker and that gives me kilometers of range!!

I spent all night reading up on the nrf51x. This looks really good and is quite inexpensive. It is certainly overkill for most apps. There are some limitations. For an old 8/16bit developer like me the interrupt response times are appalling - hundreds of microseconds. Seems it is very busy doing its bt stuff. This may not be a serious problem. There is enough programmable connectivity between peripherals to maybe avoid the need for interrupts. It may be worth the trouble to make some wrappers for its libraries, and for its replacement, the nrf52x.

They are certainly easy and inexpensive to work with. A development motherboard is only a few dollars and includes usb, swd, and battery backup. You can program them with a cheap st-link v2 or go all out with an arm-usb-ocd-h (+adapter) or segger j-link.

I will flash one today with a soft device and see how it runs.

It is looking more and more like the best solution is KISS. A proc to do the number crunching and manage sensors, connected to a dumb bt module. No complications. Just stream the data out of the usart and forget about it.