Hello, I’m Marc from Live Objects.
I propose you to present the features of the new version of Live
Objects. Let’s start now with several functionalities for the device
management, starting with a unified interface of command management
that allows you a more precise display of the steps for the commands sent
to your object, and this for all the connectivity. You can see here an example
for a LoRa device and a command that has been through different stages
until the object. Here you have an example of an MQTT device and a
command that could not be sent and which therefore stopped along the way.
You see it gives you a real opportunity to have a precise follow-up of the different status of your commands.
And of course you can find the status repeated in the list of commands.
Two new other functionalities: those are confirmations
of the commands, either network confirmation
for LoRa network for example or application for MQTT devices.
In this case the answer is managed by the firmware of the device.
The other novelty is the possibility to precise a timeout for
the commands and avoid from persisting in the platform if they are not
received by the devices. I’ll make you a demo with the Android simulator
available on Google Play. If you have not yet watched
Eric’s video that explains how to use this app
I invite you to do it: you’ll find the link in the comments
section. To note that the app is also
available on iOS, contact us if you want more
information. We’ll create a new command for this device. The command’s name is
“Buzzer”, we don’t need to put any arguments and here you have
2 new fields. So the first field is is the Timeout of the
command, I can leave it at 1 minute and the second field is the field
Acknowledgment you want to have. So you can either choose to have one
or not. Here, the Android app
will generate the acknowledgment. So i create the command,
In the waiting status and we see that for the moment it did not progress.
I just need to connect the simulator and we’ll see that
the command will be processed and an acknowledgement has been produced: it appears here.
When we come back to the list of commands, we see that the status has
been updated we see immediately that this command had been processed
correctly. Next novelty, we continue the development of
external connectors we already talked to you about few time ago.
Reminder: this connectors allow you to link devices that don’t talk
the MQTT as understood by Live Objects or
use proprietary protocols. So you already could send status
and data to Live Objects thanks to such connector. The novelty is
that now you can send commands to your devices through
connectors. We saw that we could send commands to any type of
device no matter the connectivity, the problematic that could arise
is when you have an important fleet and naturally a lot of commands
to send. For this you have a helping hand in the campaign manager, that already
existed for LoRa devices. That’s is now available for
all the connectivity. You will find the campaign manager in
the Park menu and as I told you it works with all types of
connectivity. We’ll be able to see it through an example.
Firstly you will select the connectivity you
want to work with. Define the target devices for
your campaign, either with a predefined list
that has been imported or a static one, either with A dynamic list, that is to say that all
the devices that will be provisioned in the future and that match with
the criterias will be addressed by this campaign. For this demo I will
take a static list, I will choose a group of sensors, I can add a condition to
refine the target. In the step 2, I specify
the command I need to send. Then we set
the time to live and acknowledgment for this command,
I can also add a retry policy, and then precise the start and end
date for this campaign. Here you see the campaign planned,
it’s currently setting out and here you have it. It’s available here and
we find the devices that are target by the campaign but also
the progression of the campaign. We find below all the details
of the campaign that you have set previously, and if we take a look at the campaign
that have been executed in the past, we see for example here a campaign that worked
correctly with commands that have been delivered.
And another one here, a campaign on which there was
a problem: the command could not de delivered to one device.
All this functionalities I presented are available
in the new API “Commands v1”. To note that the previsous version “Commands v0”
is still available but it is deprecated, I strongly encourage you
to use or migrate to the new version of the API. With this new
version you’ll find a better follow up of your device’s connectivity,
as we can see it here for LoRa devices on the portal and by API.
You will find all the different status that your devices
can take depending on their life cycle.
You’ll also find it for MQTT and SMS devices. It will allow to
have an quick view on the connectivity status of your park.
Live Objects will allow you to automate the management
of your park, especially by using routing rules. You simply need
to create a rule as you maybe already used to do.
You have multiple choices that allows you to route
device status events. The rest of the setting is
similar to what you were used to, with the possibility to filter either on
specific devices or on your entire fleet. Thanks to this you can
route these events either toward HTTP push but also a FIFO.
This allows you to process the events
in your business app and to apply the processig
of your choice. You will of course find all the
features in the API “Trigger & Actions” with, in bonus,
more filtering possibilities than proposed on the portal. I really advice
you to take a look at it. You will find:
commandStatus and the deviceStatus which allows you to
select status events related to commands or devices, but
also to filter messages according to the status you are interested in.
I would like to take this opportunity to clarify that the logs of your objects are now accessible
directly from the device information page, which allows you to have a
synthetic view of all the logs of a specific object.
Of course you’ll find the entirety of your logs in the Data menu
with all your devices’ logs. Let me reprecise also that you have a lot
of informations for LoRa devices. For MQTT devices, you’ll only
see errors, unless you activate the debug mode on some of your devices.
Another novelty, if you use private gateways, you can monitor
their status on Live Objects, know if they are connected
or not, and access their logs.
Finally concerning firmware update over the air, you surely know
that it was already available on MQTT devices. You
can now send update commands with SMS. Note that the
download of the firmware itself is still done over http or https,
which is also a novelty of this version. Let’s move now to the
data management on Live Objects. Let’s start with decoders, which are
now accessible for all your connectivity. For
LoRa or SMS devices, you have to specify the decoder when provisioning the object.
For MQTT devices, devices that are connected through
an external connector or when injecting data using REST APIs, you have
now the possibility to specify explicitly the decoder you want to use
in the payload. For MQTT devices, you need to use
a specific topic, which is dev/v1/data/binary/ followed by the name of your
decoder. When using external connectors or inserting data with REST API, you have to add some properties in your
payload, namely ‘metadata.encoding’ to define the decoder you are willing to
use, and ‘value.payload’ that will store your encoded payload.
I take this opportunity to inform you that the Decoder menu has been
moved, you can now find it in the Data menu,
then Decoder item here in the left. Still talking about
decoders, here’s an evolution of Live Objects portal for LoRa devices.
We can now suggest one or several decoders
depending on the profile of the object you provision. For instance if we add a LoRa device
with profile ‘pyrescom’, you will see that when I want to select
the decoders, the portal suggests the decoder ‘Pyrescom Class’Air’
which corresponds to the device I just selected. You have also
the possibility with Live Objects to send your data to a third party
cloud for an advanced processing of your data, or if you
want to process them with services hosted in these clouds.
We already had connectors to Azure Event Hub AWS SQS, now you also have
a connector for Azure IoT Hub. The code of these
connectors are available open source on Github.
You will find the link in comments. Let’s finish with multiples
evolutions on Live Objects portal which improve Data visualization.
First of all an evolution which allows the ease of message copying if you
want to extract JSON data. You’ll find now a Copy button
tat allows you to copy the integrality of the message. Also several developments on
dashboards, that allows you to them use a little more freely.
You can now reorganize dashboards in the tab bar.
You can also select with the pin icon the dashboard you
want to display by default upon connection. Let me remind you that
you have the possibility to set an automatic refresh which
allows you to have a regular refresh of you data on your dashboards.
We reached the end of the tour of the new features of the release 2.8 of Live
Objects. You will find the comment section all the references to the subjects
we talked about in this video. Don’t hesitate to comment the video or ask any
question in our LinkedIn group “IoT enthusiasts – Datavenue ready”. See you!