IIOT/MQTT discussion

With the newly released MQTT modules for Ignition, I wanted to reach out to the community and see who is actually using MQTT or IIOT technologies along with answering some of my own questions.

It seems like alot of companies are talking about IIOT and MQTT, but it just doesnt seem to be something that the end user is adopting… yet. Is this something that will actually catch on? Are these technologies readily used by IT departments to connect to information already?

I think it is really cool that the tags are created for you which on the surface seems like it would save you time. But it seems like you are just moving the tag creation process from the Ignition Gateway to the Edge Gateway, which may or may not be more efficient. This wasnt shown in the webinar, but how tedious of a process is this? Also, can you still add documentation, scaling, alarming, metadata, etc to the tags that are created by the mqtt module? if so, is this information held in the ignition tag database? For instance, I go setup documentation on each tag. I then have to change mqtt servers or take a mqtt server offline or something like that, will my tag documentation stay intact?

Are there ways to control what constitutes enough of a change in a value to push a change from the device to the mqtt server? If you have a device with 100 analog values, lets say pressures, you are going to have values that are constantly changing. From what I understand, this methodology is supposed to save on bandwidth. If you have your subscribe time set to every 5 seconds and you have 100 values that are making very slight changes, unless there is some metric to say only push new values if it is over a certain % change, it seems like you are going to be using a ton of bandwidth. Bandwidth is important to me, as I use alot of cellular. Cellular data is cheaper than ever. Traditional polling fits well for me because I can choose a data plan based on number of tags x number of polls per day to determine what size plan I need. IIOT/MQTT seems like it would be great to be able to “poll” more frequently, but just getting more data doesn’t necessarily mean it is relevant data that is useful. If a pressure is constantly changing by less than a psi, it seems like we are just collecting alot of data for no good reason. If there is a metric that allows you to determine the amount of change before pushing the value, then that allows you to collect data that is relevant and not eat up bandwidth and database space just collecting minute changes in a process.

With that said, I think these technologies can be very beneficial. Id like to learn more about it. Id love to hear from anyone that is currently using it to see what their thoughts are.

We are using ActiveMQ to broker messages from multiple Kepware servers to the datacenter over the WAN. Our MS BizTalk server subscribes to various channels and shoves the data to enterprise and analysis systems.

MQTT is a nice step up from HTTP, but we do not see ourselves publishing data to users over MQTT any time soon.

I looked at the Elecsys devices and I didn’t really see a manual, but the specs do mention “report by exception” or push data only if it has changed. If there is a deadband setting then that’s great.

What is nice about publish/subscribe, out in the field, is that you get your data immediately instead of waiting for the next poll.

[quote=“cmisztur2”]

I looked at the Elecsys devices and I didn’t really see a manual, but the specs do mention “report by exception” or push data only if it has changed. If there is a deadband setting then that’s great.

What is nice about publish/subscribe, out in the field, is that you get your data immediately instead of waiting for the next poll.[/quote]

Yeah… I mean I dont see the point if there is no deadband. Not many analog readings stay at a static number. you will always have some bounce even if it is just a fraction of the reading. No deadband would absolutely kill the idea of saving on bandwidth when it comes to analog readings.

I like the concept, but this thread was about learning more to see how well the implementation works and see if anyone else is even using it.

Your previous post about collecting the data and storing from multiple kepservers makes sense and seems like a good implementation.