News:

  • October 13, 2025, 03:26:42 PM

Login with username, password and session length

Author Topic: MQTT Best Practices  (Read 2379 times)

Bolt

  • Hero Member
  • *****
  • Posts: 591
MQTT Best Practices
« on: July 23, 2022, 01:40:58 PM »
I'm starting to get serious about using MQTT to communicate to the cloud from several BRX's.  I have some questions about best practices on the PLC.

1. Protocol. MQTTS is an option, but where do I store the TLS certificates, etc?

2. QoS. If I set QoS to 1, does it queue publish messages internally?  What is the capacity of this queue?
2a. I'm guessing that creating a FIFO sequence to queue messages to publish is best?  Any time delays needed between PUB's? Are there any caveats to using Stages with the MQTT instructions?

3. Session Type. Say I wanted the PLC to subscribe to a topic. If the PLC is off line for whatever reason, I would not want it to receive "old" data upon re-connecting.  Am I correct that 'Clean' would take care of this for me?  Or does QoS 0 take care of this?
3a. Would it be better to create 2 MQTT devices, one for publishing, other for subscribing? That way one could queue and publish all data QoS 1, and the other would only subscribe to new data if connected?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6126
  • Yes Pinky, Do-more will control the world!
Re: MQTT Best Practices
« Reply #1 on: July 23, 2022, 02:23:07 PM »
1. Protocol. MQTTS is an option, but where do I store the TLS certificates, etc?

Certificates are only used to verify the identity of the server and aren't required to make any TLS connection work. Currently, the only certificate BRX uses is for SMTP, and that is handled automatically when you configure the device. We will be adding a certificate database in the next release and make it available to apps that currently don't use them.

2. QoS. If I set QoS to 1, does it queue publish messages internally?  What is the capacity of this queue?

QoS1 just handshakes the publish to ensure delivery. Queuing isn't part of that, and generally doesn't need to be for publishing the "current" state of something. In general, QoS2 is for transactional publishing, where it is critical that each state change being published exactly one time. We don't support QoS2 specifically because of the issues of storing all states and guaranteeing delivery. On a PC where you have effectively infinite memory, it's no big deal, but for a small PLC, it leads to issues we didn't want to deal with. If you do want to ensure all states get published "at least once", then use a FIFO or a disk file to cache.

2a. I'm guessing that creating a FIFO sequence to queue messages to publish is best?  Any time delays needed between PUB's? Are there any caveats to using Stages with the MQTT instructions?

Yes.
No.
Not really, just be sure you understand what completion means in the context of what you are doing. Recurrent comm functions act a little different, so with stages, you need to do it as a single event and not transition until complete.

3. Session Type. Say I wanted the PLC to subscribe to a topic. If the PLC is off line for whatever reason, I would not want it to receive "old" data upon re-connecting.  Am I correct that 'Clean' would take care of this for me?  Or does QoS 0 take care of this?

Best thing to do it play with it and get comfortable with the behavior of the broker you want to use.

3a. Would it be better to create 2 MQTT devices, one for publishing, other for subscribing? That way one could queue and publish all data QoS 1, and the other would only subscribe to new data if connected?

QoS1 just handshakes and retries, while QoS0 doesn't. I don't think it changes whether something is published or not. Best thing is just to play with it.


And a caveat...I learned MQTT well enough to write the implementation...but I am absolutely not an expert and don't use it for anything other than testing. Others on here probably understand it far better than me.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Bolt

  • Hero Member
  • *****
  • Posts: 591
Re: MQTT Best Practices
« Reply #2 on: July 23, 2022, 03:29:08 PM »
Thank you for your perspective.  I played with it on the Sim, got comfortable, then rolled it out to a few production machines to get a feel for it with real data quantities and rates.  Now I see room to improve, and it's hard to do in production of course, because it requires a Program Mode transition.  Back to the Sim I go.

Bolt

  • Hero Member
  • *****
  • Posts: 591
Re: MQTT Best Practices
« Reply #3 on: July 23, 2022, 03:30:47 PM »
We will be adding a certificate database in the next release and make it available to apps that currently don't use them.

I like the sound of this.  I've tried too many cloud API type scenarios where I ran into a CA roadblock.

Kristjan

  • Sr. Member
  • ****
  • Posts: 67
    • Idnadartaekni ehf
Re: MQTT Best Practices
« Reply #4 on: August 25, 2022, 06:35:02 PM »
I'm starting to get serious about using MQTT to communicate to the cloud from several BRX's.
Which cloud services are you using?

I am currently developing a solution with Node-RED on Raspberry Pi, getting a very flexible and responsive dashboard. I would like to investigate cloud services for better/easier access from outside the LAN (I know - I am playing with fire  :) )

Bolt

  • Hero Member
  • *****
  • Posts: 591
Re: MQTT Best Practices
« Reply #5 on: August 26, 2022, 11:06:39 PM »
Azure is the easiest to get going by far, there's an instruction sheet here

https://forum.hosteng.com/index.php?topic=3204

Kristjan

  • Sr. Member
  • ****
  • Posts: 67
    • Idnadartaekni ehf
Re: MQTT Best Practices
« Reply #6 on: August 27, 2022, 05:48:31 AM »
Wow, at first glance it didn't look too easy to me  :-\ But great to know this has been adressed.

There is a reference in there to "api-version=2018-06-30". Is this still valid?

So are you only running your MQTT broker on Azure? Or do you also have some sort of a user interface?

Bolt

  • Hero Member
  • *****
  • Posts: 591
Re: MQTT Best Practices
« Reply #7 on: September 01, 2022, 01:06:34 PM »
Yes, it's still valid, it's not uncommon for API's to persist for years and years. Quite preferred, actually!