A lot of our competitors try to lock you up into their total monitoring solution, we don’t. We obviously believe in total monitoring solutions as well, but it should be one preferred by you and suiting your line of work. We just want to supply you the components to get your measurements acquired and delivered at your disposal by several common data transfer methods and open file formats.
Our data loggers support the MQTT protocol, opening a new IoT world of flexibility. The MQTT protocol implements a publish/subscribe messaging model, making it possible to flexible distribute and share information. In example, an IoT energy monitoring system could subscribe to the log data from an energy monitoring data logger, while your cloud based inventory management systems could subscribe to the log data from a tank level data logger, which could actually be the same data logger.
MQTT messages app
Your service engineers can, with an MQTT messages app on their smart phone, subscribe to system alarm messages (e.g. a failing sensor) and your process engineers to operational alarm messages (e.g. a Low tank level reached). The data logger on its turn subscribes to remote configuration and FW updates and as MQTT is not a peer-to-peer protocol, these updates don’t have to come from your central monitoring system, but can be initiated from a separated source. You can use ydocTerminal to publish configuration and FW files by MQTT or even use ydocTerminal to setup a secure communication channel for interactive “hands-on” configuration.
When looking for an IoT Device management, data collection, processing and visualization platform, you might consider the ThingsBoard which comes with powerful data integration and automation tools, MQTT and JSON support.
Setting up alarm messages from your data logger
If you have a limited number of sites to monitor, you might not even need a monitoring system and all you require is a generic MQTT IoT app on your smart phone. When searching the Android Playstore, we are sure you will find one suiting your purpose, for instance “MQTT Dashboard”. Such generic app’s will probably not be able to interpret the “Log data” published by our data loggers, but they will not have much difficulties with interpreting the published “Actual sensor values” or “Alarm messages”.
Our data logger can also act as a Sparkplug B Edge of Network Node (EoN). The goal of the Sparkplug B definition is to make interoperability between devices and SCADA & IIoT systems easier. If your SCADA system does not support Sparkplug B yet, you could opt to use a real-time middlewae like the Cogent DataHub® in between.
It’s also possible to send data to connected serial devices or smart sensors with the integrated “MQTT serial communication bridge”.
Getting the MQTT protocol up and running
At regular intervals or when necessary the data logger tries to connect, thru the LTE-M or NB-IoT mobile network, to a so called MQTT broker (e.g. www.cloudMQTT.com). Once connected the logger will publish its “Actual sensor values”, “Log data”, “Camera pictures” and/or “Alarm messages” to the MQTT broker, which will pass it on his turn to one or several subscribers. If available, the broker will transfer any configuration or firmware files to the data logger.
The MQTT protocol works with so called “Topics” and MQTT clients can subscribe to the “Topics” of their interest (of course in the domain they have access to, you don’t want unauthorized entities to subscribe to publications from your equipment).
Within the data logger you can define a “Root topic”, which is used as prefix for all “Sub topics”. The default “Root topic” is “YDOC/<device serial number>”, but it can be changed according to your wishes. E.g. you could define a “Root topic” starting with your own company identification code, followed by some device classification code and your own chosen station identification code.
In example: (ACME/METEOSTATIONS/STATION_001). Your central monitoring system could subscribe to all topics starting with ACME and when a logger publishes for the first time, then your system could create a profile for “STATION_001” based on the specified “METEOSTATIONS” classification.
The logger uses the following publishing topics:
- <root>/sensors/<parameter code> to publish an “Actual value” of a specific parameter.
- <root>/data/jsn to publish the “Log data” in JSON format.
- <root>/data/csv to publish the “Log data” in CSV file format.
- <root>/data/txt to publish the “Log data” in YDOC native text format.
- <root>/alarm/sys to publish “System alarms” in plain text, e.g. about a failing sensor.
- <root>/alarm/data to publish “Data alarms” in plain text, e.g. about reaching a low tank level.
- <root>/jpg/<yymmdd_hhmmss> to publish “Camera pictures with timestamp” in JPEG format.
- <root>/status/time the time of the logger at start of an MQTT session, format is yyyy/mm/dd hh:mm:ss