HTTP callbacks

HTTP callbacks

This week, we continue our "For the beginners" post series. Do you know that you can configure YoctoHubs so that they connect themselves directly to Cloud services? This feature is available on all the YoctoHubs and on the VirtualHub. Here is an overview of the supported Cloud services.




This post is part of the "For the beginners" series, but we assume that you already know how to use the basic features of our modules. If it is not the case, we recommend that you read the previous posts of this series, in particular those on the YoctoHubs and on the logical structure of Yoctopuce devices.

HTTP callback

The HTTP callback is a feature available on all the YoctoHubs which enables the latter to connect themselves directly to a server to post the current value of the connected Yoctopuce modules. You don't need to install an application or a service on a machine on the network. You simply need to configure the HTTP callback with the YoctoHub web interface.

Note that in this mode, the YoctoHub itself establishes the connection to the server, which avoids all the issues linked to firewall and other NAT filters. In other words, if the YoctoHub has access to the Internet, it can connect itself to the Cloud server.

The YoctoHub itself establishes the HTTP or TCP connection to the server
The YoctoHub itself establishes the HTTP or TCP connection to the server



Callback configuration panels


You perform the HTTP callback configuration in the YoctoHub web interface. In the YoctoHub configuration window, there is an Outgoing callbacks section which displays the current configuration of the HTTP callback.

The YoctoHub-Ethernet configuration window
The YoctoHub-Ethernet configuration window



Click on the edit button to access the HTTP callback configuration window. You can configure a callback to the following services:

Emoncms


Emoncms is an open-source Cloud service which enables you to post the data of Yoctopuce sensors and then to visualize them. You can also install your own server locally.

The parameters that you must provide are the Emoncms API key, the number of the node that you want to use, as well as the address of the Emoncms server if you use a local server.

The configuration window for Emoncms callbacks
The configuration window for Emoncms callbacks



For more information on how to use this service with our modules, you can refer to our post dedicated to Emoncms.

Valarm.net


Valarm is a professional Cloud service which allows you to store data from Yoctopuce sensors but provides you also with more elaborate features such as the possibility to geolocate the measures or to configure Yoctopuce modules remotely.

The only parameter that you need to provide is a Routing code to identify the YoctoHub.

The configuration window for Valarm callbacks
The configuration window for Valarm callbacks



For more information on how to use this service with our modules, you can refer to our post on the Valarm Cloud.

Xively


Xively is a fee-based Cloud service for large businesses and for EOM customers. It allows you to store the measures of Yoctopuce sensors.

The parameters are the Xively API key and the Feed ID.

The configuration window for Xively callbacks
The configuration window for Xively callbacks



For more information on how to use this service with our modules, you can refer to our post on Xively.

InfluxDB


InfluxDB is an open-source database dedicated specifically to time series of measures and events. Note that only local installations are supported. The "InfluxDB Cloud" service is not supported because it requires an SSL connection (see below).

The parameters for version 1.0 of InfluxDB are the address of the server and the name of the database. You can consult our post on InfluxDB 1.0 for more details.

The configuration window for InfluxDB 2.0 callbacks
The configuration window for InfluxDB 2.0 callbacks



Version 2.0 of InfluxDB uses a different API and the YoctoHub needs three parameters (organization, bucket, and token) as well as the server address. You can refer to the post from two weeks ago for more details on InfluxDB 2.0.

PRTG


PRTG is a commercial solution, designed to monitor systems and applications. You can store measures and obtain graphs of your sensors with this service.

The parameters that you must provide are the address of the PRTG server and the token to identify the YoctoHub.

The configuration window for PRTG callbacks
The configuration window for PRTG callbacks



For more information on how to use this solution with our modules, you can refer to our post on PRTG.

MQTT


MQTT is an Internet of Things protocol enabling sensors to communicate with a central server called MQTT broker. The YoctoHubs can transmit the values of Yoctopuce modules on an MQTT network, however they cannot receive commands through this channel. In other words, you cannot control Yoctopuce modules (for example a Yocto-Relay) with MQTT. Note that the MQTT protocol encapsulated into an SSL connection (such as AWS IoT Core) is not supported (see below).

The parameters that you must provide are the address of the MQTT broker, the client ID, a possible root topic, as well as authentication parameters.

The configuration window for MQTT callbacks
The configuration window for MQTT callbacks



For more information on the use of MQTT with our modules, you can read the following posts:
"Connecting a Yoctopuce sensor to an MQTT broker" and "Using Yoctopuce sensors in FRED".

Yocto-API


You can also use the callback mode directly with our API. In the opposite to other callbacks, the Yocto-API and Yocto-API-JZON protocols allow you to use all the features of the modules. You can for example switch the output of a relay depending on the value of a sensor.

However, you have to code you own service, in PHP, JavaScript (node.js), or Java. We have three tutorials which explain how to use the callbacks for these languages:


Interval between callbacks

The last section, which present in all types of callbacks, enables you to configure the interval between each callback trigger. You can define this interval in an absolute or in a relative way.

The interval between subsequent callbacks option allows you to specify a delay between each callback. That is, if you configure a 5 minute interval, the YoctoHub waits 5 minutes before triggering the next callback. If the first called back is triggered at 12h03, the next one is run at 12h08, and so on.

The absolute periodicity of callbacks option enables you to configure callbacks at a set time. That is, the callback is triggered each multiple of the configured delay. For example, a 5 minute delay triggers a callback at 8h00, 8h05, 8h10, and so on. Note that in this mode, you can also specify an offset with regards to the configured delay. For example, with a 24h delay, you can use an 8h offset to trigger the callback every day at 8am.

Note that you can also specify a shorter delay if the value of a sensor changes. This enables you to reduce network traffic if nothing happens.

Safety


As said above, as of now our modules can't crypt the content transmitted with SSL. SSL support would be too voluminous to be added as is in our modules and would required other more detrimental sacrifices. However, this doesn't mean that callbacks aren't safe. We have a post which explains in details how to secure the HTTP callback mode.

The VirtualHub


Everything we have said in this post is also valid for the VirtualHub which, as its name suggests it, is an application which allows you to transform any computer into a virtual YoctoHub. The callbacks work in exactly the same way on the YoctoHubs and on the VirtualHub.

Add a comment No comment yet Back to blog












Yoctopuce, get your stuff connected.