[Imported] MQTT Driver

[sbeadle]

>>Message imported from previous forum - Category:ClearSCADA Software<<
User: florian, originally posted: 2018-10-24 21:02:03 Id:204
This is a re-posting from the obsoleted (October 2018) "Schneider Electric Telemetry & SCADA" forum.

--------------

**_sbeadle:_**
**_There is an MQTT Driver available on the tools and samples page of the Resource Center:_**

**_http://resourcecenter.controlmicrosystems.com/pages/viewpage.action?pageId=40535951_**

**_Please post here any questions._**

------------------

du5tin:
Hi,

I played with a beta version of this a few months ago. It was good. However, a lot of vendors pushing data to MQTT brokers are doing so with JSON strings, so the data is wrapped up, not in a MQTT topic by itself. Kepware, Simark's SCADAPack MQTT driver, etc. all do this to some extent.

Do you have plans to decode JSON to get values, units, full/zero scale, and maybe timestamps?

-D

--------------------

**_sbeadle:_**
**_This could be done. Is there a specific format?The sparkplug format could be used, but this is not JSON - it's protobuf._**

------------

pbeutel:
Hi,

Yes support for JSON strings would be great - this would enable the timestamp to come through with any values.

I'm trying the new version of the driver with CS2015R2 (77.5882).

I get the error 'DDK Coding Error - Field 'xxxx' not found' for all the analog MQTT points I'm trying to monitor - I didn't see this in the earlier releases. This was when using RabbitMQ with MQTT enabled.

Double checking using the Mosquitto broker it stays the same, CS reports the connection is good but Mosquitto reports a socket error on connect from CS and I don't see any subscriptions to the topics the MQTT analog points are subscribing to.

Cheers,
Phil

---------------------

du5tin:
Therein lies the rub... 🙂 The JSON format is always different! Some vendors use:

_{_
_"D": timestamp,_
_"V": value_
_}_

and others might use:

_{
_"timestamp": timestamp,_
_"value": value_
_}_

To get data in JSON the mechanism should probably be customizable and flexible.

I find it funny that even with new tech which is supposed to help move data with context, we're back at "how do we represent or structure the data".

I'll find some of the default formats for a few different platforms and post them back here.

[sbeadle]

>>Responses imported from previous forum

Reply From User: rifqi, posted: 2018-11-25 02:42:01
Instead using MQTT with JSON format, why don't we use MQTT with Modbus or DNP3 formating? so we can use existing device with modbus protocol or DNP3. then we just need some gateway in device side.

I try encapsulating/wrapping Modbus over MQTT here https://www.youtube.com/watch?v=KY4FZba-wFM I'm using node-red, but theoretically it can be implement anywhere.

Reply From User: adamwoodland, posted: 2018-11-25 21:41:16
The thing about MQTT is the payload can be whatever you like: JSON, ASCII or binary, it makes the development much harder as it needs to be device specific. The other issue I've come across in my MQTT development is that some devices don't always include the device as either part of the topic or each payload, so with a proper subscribed client to a broker you don't know where the data is from.