New features in the VirtualHub and in the YoctoHubs

New features in the VirtualHub and in the YoctoHubs

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
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
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:

  1. Minimum wait between two HTTP callback, when a measure has changed
  2. 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.
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
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.

1 - Pat Chandler Tuesday,april 25,2017 6H52

Useful additions. But people have different requirements. For me, the following features would be much more desirable:

"Minimum wait between two HTTP callback, when a measure has changed" lacks a very important parameter - how _much_ change is needed to trigger a transmission. If you measures temperatures to 2 decimal places then you will never see "no change".

Another thing that I really want is having the switching between slow and fast transmission being controlled by the _value_ of what is being measured, e.g. transmit more frequently when the value is above 50.

Please consider these important improvements.

2 - mvuilleu (Yocto-Team)Tuesday,april 25,2017 6H55

@Pat Thanks for the comment. Regarding your first suggestion, this can be achieved by changing the resolution setting on the temperature function. If you set the resolution to 0.5 for instance, you will only get a "new" value when the value has changed by 0.5 degrees. But you will always be able to read the exact value using get_rawValue.

Yoctopuce, get your stuff connected.