I’ve made a great deal of progress on automating deployment of ESP based iot nodes on my personal network.
The problem I’ve set out to solve is being able to update firmware or other settings on nodes that check in infrequently, and also nodes that perform the same function but need different names / etc.
Rather than compile 5 different copies of the same firmware changing the hostname or mqtt topic, I can push out one firmware and assign the rest of the configuration from a database via JSON.
It is a two part system:
A. Generic sketch that is loaded onto the nodes as they are assembled. The sketch polls an auto-configuration server repeatedly waiting for an updated configuration or firmware.
B. A javascript server (node.js) delivers configuration via JSON as well as updated sketch binaries by way of the httpupdate library on the esp. The contents of the JSON are stored locally using SPIFFS, and a simple version number system updates the local copy as needed.
More details and a git page coming soon.
Doing something similar. I need to write some code to allow the nodes to hand “niave” nodes the wifi info cause I use about 10 of these per home
Why would you not use WPS to provision WPA2 keys? If I ever got anywhere with my ESP board, I’d try to build a pushbutton setup. So you’d only need to push the WPS button on your router and let the ESP do WPS and some autoconfig magic at the push of a button.
Is WPS supported by the SDK? I’m using WiFi manager for that phase of the setup. Wifi is a most minor portion of my in-house configuration.
WPS is not secure. I have the esp check for a connection and start access_point if no connection is found. That’s how the user gives the esp their wifi password.
I was thinking WPS push-button, not WPS PIN. While even WPS PBC has a window of opportunity for an attacker in the time it takes until you register your device or hit timeout, I don’t see how that makes a difference to transmitting your WPA2 password through the unencrypted Wifi your ESP opens if it can’t connect. Or did I miss something?
@Bjorn_Kaiser The password is being sent with WPA2 to the esp then it connects to the router. The method I’m describing can be automated so we can deploy several nodes in a more automated way than having to press the WPS button on a node then on the router…move to the next node…repeat vs me sitting on a laptop linking all the nodes. I can write a simple script to link the nodes automatically so installers can just click a button.
OK, I think I got the idea now. Your nodes connect to a hard coded setup AP. Makes sense for mass deployment.
I was thinking end-user plug-n-pray solution. There I would think WPS PBC is easy and secure enough. Plus you could program a function for a one-button setup in the ESP that first initiates WPS and then tries to autoconfig it’s controller/master etc.
@Bjorn_Kaiser The nodes connect to any access point not a predefined one - what do you mean by hard coded?
With hard coded I meant predefined in the firmware. Correct me if I’m wrong, but I understand the code like this:
Connect to known network, else start AP without encryption to allow the user to select the network and enter password.
We were talking about WPS being insecure, so I think I missed the point where the initial connection is encrypted. Because you don’t want to transmit your password for your wifi over an unencrypted connection.
You are correct. Add or uncomment WiFi.softAP(ap_ssid, ap_password) before you deploy it outside of development.
I would love to have the code for that. My current plan is to automatically build different firmware images. My nodes spent most of their time in deep sleep - once they wake up, they would check a sticky mqtt topic for a new firmware version.
How are the nodes identified in your scheme? Via the Mac address?
@Michael_Haas The firmware updating part is pretty straight forward. The httpupdate library on the esp does everything behind the scenes, you give it a url and a version number, and it does the rest. On the server, I run a javascript app (node/express/mysql) that responds to the httpupdate queries and passes along the correct file.
The part I haven’t figured out is the automatic building of different versions. That’s my fault for sticking with arduino instead of moving to the esp sdk and gcc. Some things I just can’t do programmatically in Arduino, a limitation of the simplistic libraries… like assign a different pin to the dallastemperature library, or toggle the internal adc voltage reference on/off… you have to bake those settings into the firmware.
I’m far to undisciplined a programmer to have any code worth sharing publicly but if you want to send a note to my http://gmail.com address gordonthree I’ll send you the relevant snippets that work for me.
@Michael_Haas Sorry forgot to answer your other question. Yes, I use mac address to identify the nodes. httpupdate library sends it automatically to the server, along with a bunch of other info about the esp and its firmware.
@Gordon_McLellan Thanks for the details on the HTTPupdate library. That sure sounds great. It will take me some time to put it into production - I still have to get some pcbs made 
In your original post, you mention that your nodes are pulling the config instead of pulling different images? If you put your code on github, I would be happy to help with the hard-coded defaults. Even if your code is not super beautiful 
If you decide to go down the route of compiling multiple images: I am going to try http://platform.io
Or perhaps just the arduino command line builder. Both can be scripted to build images with different configs
@Michael_Haas That sounds great, I may have to take you up on that offer.
I’ve been trying to develop a one firmware fits all package for my various projects. When they’re “new”, I upload a short auto-config firmware that runs WiFiManager to gather the wifi details, and then checks in with my api server to get the path to the real firmware, as well as configure mqtt settings, websocket settings, i2c pins, available features, etc.
As I fine tune the firmware, I compile it, put it on the api server and then update the firmware version for my nodes. As they check in overtime, they see new firmware and update automatically. Like you, I have many that spend most of their time sleeping, and they’re not easily accessible to just flash new firmware over serial.
@Gordon_McLellan Thanks for pointing me to Wifimanager. I will definitely be using that for the coffee machine controller, if I ever finish that…
Where are you storing the node settings? Spifffss or via the eeprom class?
Let me know once you have your code up. I will get back to software work once my pcb design is sent off for production. I will tackle the build process for multiple images then.
I store the settings in Spiffs. Originally I tried eeprom, but it seemed really fiddly, and it’s not dynamic like spiffs is. The arduinojson library has some spiffs support built in, making it easy to fetch a json from the api server and write it to spiffs.
That’s something http://platform.io might help with. The spiffs configuration (but not content) is baked into the firmware .bin file, if the config doesn’t match the actual ESP, for example uploading a 1M/128K ESP-07 firmware to an 4M/1M ESP-12 will destroy the filesystem on the esp-12, until you reflash with correctly formatted firmware. The httpupdate library has the ability to chose firmware based on flash size, so if http://platform.io can spit out a firmware bin for each flash size, that would be helpful indeed.