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.
Topic: MQTT Best Practices (Read 2396 times)