So I have used a different approach.įor this discussion, the CRON script uses php to interface both with ThingSpeak and a mySQL database. Sure, a proxy interface could be developed using a php script, that would unnecessarily complicate the design. And ThingSpeak does not provide an API for that purpose. You see, in my case, I also need to interface with a mySQL database. ThingHTTP interacts with the micro-controller using http GET or POST.īut there is a limitation with this approach… This, along with the ThingSpeak ThingHTTP App is all that is needed. Organically, ThingSpeak provides the TimerControl App to perform an action at a specific time or on a regular schedule. There are a couple of options available to deploy automated scripts for data exchange to a ThingSpeak channel. In this case, it is simply a service provide by the web host to automatically execute a script at a predetermined time. Any MCU capable of these two functions can be used.ĬRON originated in the Unix world. It should be noted here that this is not limited to an ESP8266. In this capacity, the server responds to http GET requests, returning sensor and system values in JSON format. This process runs on an internally registered timer callback. Periodically, it refreshes sensor readings and various system parameters, including the MCU run time since the last reset. The ESP8266 runs it’s own firmware serving two primary purposes. The CRON script is the key component used to move the information from the ESP8266 to the ThingSpeak channel. The system is comprised of an ESP8266, a web host server capable of running CRON scripts, and a ThingSpeak channel.
The script is executed once every 20 minutes. This requires a CRON script running on my web server. So I came up with a simple solution…Ī method of comparing each new ESP8266 reading with the maximum value saved in a ThingSpeak channel field. What I found was that reading all of the captured data and searching through it for a maximum value became increasingly slower as my database record count grew.
This, along with the sensor data is added to the channel data once each hour. The value is saved to the ThingSpeak channel in a field containing the ESP8266 ms running time.
One of my key data points of interest is the lapse time between ESP8266 resets. Both ESP8266 System Status and Sensor data are collected. You see, like many users, my ThingSpeak channel receives data captured by an ESP8266 micro-control unit (MCU). Just retrieve the data points and search for the maximum among them. So what’s the big deal? You’ve got all the data captured. This article provides a method to capture and store the maximum value reached in a ThingSpeak channel field.
0 kommentar(er)
