ricki-z
commented
7 years ago Flashing:
In most cases it's the USB cable. It shouldn't be longer than 50cm (standard USB cable). Otherwise you could try to flash at a lower serial speed. There is no other tool than the Arduino IDE that is available on mostly all platforms. Any other tools w found had some kind of issues.
Access point performance:
We could make it faster if we deactivate the search for available WiFi networks. But this is a help for users that are unsure about the name of their WiFi. Jumpers are just another part of hardware that people need to connect. And so another point of hardware failures.
Config flow:
There is not enough space on the NodeMCU to build to build a larger amount of pages. Normal users should only need to include the WiFi name and password and click the save button. This is mentioned on the config page ('Change only if ...'). Serial configuration could only be done by people with the suitable knowledge. This is the reason for the configuration via WiFi.
Auto update:
The updates are tested on more than 4 devices with different configurations. These devices are spread over germany (I need to know someone there, if there is a problem). So there should be only a small chance that devices are bricked by an update. The devices are mounted outdoor. So an LED is not very helpful to show the status. If you could see the LED you will need to make the LED waterproof. But you can check the sensor via http://feinstaubsensor-[chipID].local (chipID is the long number we need to include the sensor in our database).
As mentioned in our FAQ, you can reconfigure the sensor with the URL http://feinstaubsensor-[chipID].local
For flashing it should be possible to find someone who can do this for the people.
And if you test the configuration in a room with many active devices, yes, than there may be problems with wifi connections. As in any room with too many wifi routers around.
Cinezaster
At Civic labs Belgium, we recently tried to build 10 devices and to be honest the process was a bit hard and inconsistent.
Me, I'm using Platformio to configure and flash the ESP8266, and I'm editing the ext_def.h file. This is of course not the easiest route if we want to roll out these devices to none technical people.
Ideas for improvement
Flashing
There are a couple of projects like flasher.js a cross platform software tools to flash firmware onto ESP8266 already tried to convert this to push our firmware. Didn't work, but haven't got the time to debug it.
Better access point performance
I have not enough experience with the ESP8266 to know what we need to improve. I assume the access point/ server code is based on a working example that performs well? Next, loading the config page can take up to 30 seconds and often fails. Its this a limitation of the ESP? A solution could be splitting the forms into multiple pages so the amount of data per page is reduced? Using a jumper to force the device in access-point mode would also be very handy. That way we can keep it in access mode till we're done with configuring the device.
Config flow
A step by step flow would be preferable because now you have one page with 3 save buttons. Or we add configuration over the serial port and write a small cross platform app with electron, I did this before and it should be not so difficult.
Auto update
How do we know for sure, an auto update wouldn't brick all sensors out there? An LED or something else would be a nice addition to show the status of our device.