We now offer one-time commands and weekly recurring schedules for commands. TimeControl is a web service hosted by ThingSpeak that executes any type of HTTP service call at predetermined times or schedules. We are happy to announce today that we are releasing a new app and we are excited to see what you do with it! Introducing TimeControl…

include('sensors_weather_save_utils.A ThingSpeak App is a service offered by ThingSpeak that runs in the cloud to help you build connected projects and release connected products for the Internet of Things.Write the other sensor and status values to ThingSpeak.Evaluate whether current value for run-time is greater than the max value saved.Read the max run-time value from ThingSpeak.Write the Sensor and status values to ThingSpeak.Read the current ESP8266 Sensor and status values (HTTP GET).The script tasks are simple and straight-forward… For this simple case, less than 10 seconds should be required. The job should execute and complete within a “reasonable” amount of time. The other stipulation is that the scripts cannot run continuously. In order to prevent excessive resource consumption, my web host limits my account to three scheduled scripts. This eliminates the need for a proxy to overcome the ThingSpeak App’s lack of a mySQL interface. But even this approach comes with restrictions… 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.

Thingspeak timecontrol limitations