It’s occurred to me that the ESP possible with the addition of an SD card or extra flash could be used to buffer data before posting to emoncms. In the event of network failure, data could be buffered locally on the ESP then bulk uploaded with emoncms connection to restored.
What do you think of the feasibility of this feature? It would be really great not to have to relay on the quality of a network connection to obtain good quality monitoring data. There could even be potential for the ESP to operate in ‘offline’ mode logging to an SD card for later data upload.
Even without the SD card/flash this would be a useful feature, with the free memory I am typically seeing (at least 10Kb) you should be able to store data for around 40 minutes without even trying (10 data points, 4 bytes each = 40 bytes a sample, 10KB / 40B gives you storage for 256 samples, 2560 seconds or 42 mins).
I say larger but it probably is not that bigger deal. A kind of hacky way of extending the current bulk upload may be to have some magic value for the time that indicates the values are names not values, eg ["names",0,"ct1","ct2","ct3","ct4","vrms","pulse","t0"]
I nicer solution would probably involve coming up with a new schema on a different endpoint.
Is not part of the trouble that generally, the ESP is used without the concept of time? It just sends the data now?
ESP can get time via NTP, but that is a whole new set of issues.
You also need to use the HTTP API rather than MQTT as the emoncms input MQTT process can get overwhelmed unless you throttle it. That format is also much larger in terms of storage.
Final thought, we relied on 433 for many years, is Wi-Fi any less reliable?
Household microwave ovens operate at 2.45 GHz.
To put that in perspective, Wi-Fi channel 9 is at 2.452 GHz, a scant 2 MHz away.
The higher the frequency, the more “reflective” the signal becomes. i.e. objects a 433 MHz signal
would ordinarily penetrate, act like an RF mirror to signals at 2.4 GHz.