As an answer to recurring requests to Yoctopuce support, we added this week two important improvements to the YoctoHubs and to the VirtualHub to make it easier for you to use Yoctopuce sensors. The first one is the addition of an interface enabling you to configure the data logger and to retrieve recorded data in a CSV format. The second one is a new strategy for planning fixed-time HTTP callbacks.
These improvements are available from version 26552 of the VirtualHub, available as of today, as well as with firmware 26562 and following of the YoctoHub-Ethernet, YoctoHub-Wireless-g, YoctoHub-GSM-2G, YoctoHub-GSM-3G-EU, and YoctoHub-GSM-3G-NA.
Interface for the data logger
With this new version, when you open the configuration window for any Yoctopuce module with a data logger, the following section is displayed:
The configure button allows you to set the parameters of the data logger:
Data logger configuration interface
You can therefore easily change the recording rate and select to record only some sensors. Changes are applied as soon as you click the Ok button.
When your sensor has data in its flash memory, two buttons are displayed in the summary view:
If you click on the download CSV link, all the data in the data logger are automatically downloaded from the module by your browser as a CSV file: the first column contains the UNIX timestamp of each measure; the second column contains the date and the hour, in the ISO 8601 format; the following columns contain the data of each sensor. Each column is separated by a semicolon, which should allow you to easily import the file with Microsoft Excel or LibreOffice, for example.
Importing the CSV file into LibreOffice
Planning HTTP callbacks
As a reminder, HTTP callbacks enable the Yoctopuce hubs to connect themselves spontaneously on a web server to post current values of connected sensors, and even to receive remote commands from the web server. The frequency of HTTP callbacks can vary dynamically depending on new measures that need to be reported or if nothing changed since the latest HTTP callback.
Until now, you could configure the frequency of HTTP callbacks in only one way:
- Minimum wait between two HTTP callback, when a measure has changed
- Maximum wait between two HTTP callbacks, when nothing new happened
The first parameter is used to limit the network load, while the second one enables you to make sure that you regularly monitor the good health of the system, even when nothing changes.
Customers have requested the possibility to select a precise time at which the hubs perform their callbacks, rather than an interval between the callbacks. Indeed, by parameterizing only the interval, you can't guarantee that the HTTP callbacks are performed every day at the same time, for example.
Now, you can therefore select between two planning methods: the existing method, by interval, and the absolute periodicity method, to obtain callbacks at fixed times. You can now specify the interval between callbacks in seconds, minutes, or hours, and it is not restricted to 18 hours as before. And when you select to perform callbacks at fixed times (for example once a day), you can indicate a shift with regards to the selected granularity (for example 8 a.m.):
Configuring an HTTP callback for 8 a.m.
You can explicitly select if you want the HTTP callback frequency to vary when no new measure is detected:
Selecting whether to adapt the frequency of HTTP callbacks
One more thing about this new alignment feature: if you setup many hubs to make an HTTP callback at the same time, you may create a load peak on your web server. So make sure to use the shift parameter to balance load over time.
That's all for this week, folks! And don't hesitate to contact us if you have suggestions to improve our products, we'll always pay attention to what you have to tell us.
