Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bolt 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?
-
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.
-
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.
-
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.
-
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 :) )
-
Azure is the easiest to get going by far, there's an instruction sheet here
https://forum.hosteng.com/index.php?topic=3204 (https://forum.hosteng.com/index.php?topic=3204)
-
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?
-
Yes, it's still valid, it's not uncommon for API's to persist for years and years. Quite preferred, actually!