Announcement

Collapse
No announcement yet.

MQTTS and QOS on BRX

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • MQTTS and QOS on BRX

    I'm very interested in using MQTT on the BRX for my existing IoT project but we'd need MQTTS - are there any plans for this? Similarly we need QoS 2 - I don't see anything mentioned about QoS so am I right in assuming it's QoS 1 only right now? Any plans to add QoS 1 and 2?

    I saw mention that JSON support is coming - I want to give a thumbs-up for this - it will definitely be useful for our project.

    Thanks. Andrew.


  • #2
    We do not currently have plans for QoS 2. Since QoS 2 was more transaction centric, we felt that for recurrent PLC data it didn't make as much sense. We could revisit that if there is enough interest.

    Next release will include instructions for parsing and building JSON records, as well as an HTTP command instruction for accessing REST APIs.

    Comment



    • #3
      MQTTS might happen. The big issue is that we have limited resource for SSL, and the features that currently use it share well. MQTTS doesn't, and would require a dedicated SSL function, since the session stays open. We recognize the need though, and would like to see if we could make it happen.

      Comment



      • #4
        Thanks for the feedback Bob. I might be able to live with QOS 1. Is that a possibility?

        My thoughts about QOS 1 and especially 2 are that they are not needed in a high-quality network environment, so if you're doing factory automation etc. I agree with you that it's not really needed. However, in environments with marginal network quality (think IoT in isolated environments) you may need a higher QoS level in order to ensure that the message gets picked up by the broker. My current application requires guarantees of message delivery so I need to use QOS 2. If a secure (MQTTS) and reliable (QOS 2 (or at least 1)) delivery option was available I could use a lot of these PLCs.

        Comment



        • #5
          We currently support QoS 1, which is at least 1 delivery. For recurrent PLC data, there are many such deliveries as data is changing and/or on a timed basis. Unless you are doing financial transactions where you need exactly 1 delivery, QoS 1 is generally good enough.

          I'm willing to look more closely at MQTTS.

          Comment



          • #6
            That sounds good Bob. I look forward to hearing more about MQTTS on BRX.
            Regards, Andrew.

            Comment



            • #7
              Originally posted by Andrew S View Post
              That sounds good Bob. I look forward to hearing more about MQTTS on BRX.
              Regards, Andrew.
              Already looking at it. Don't think it's gonna be a big deal to add.

              Comment



              • #8
                Well...I misremembered.

                The released hardware does contain support for QoS 1, that was right, but DmD doesn't provide a method for enabling it. I forgot that detail. The reasoning is that it really doesn't give you what you think it does. The intent of QoS 1 is to ensure that every state change gets reported at least once, but for that to make sense, you have to cache every state change. That's fine and dandy in certain environments, but less so in a PLC. So our QoS 1 implementation really ended up being QoS 0 in practice. So we removed the selection.

                Since our implementation is constantly reporting on a timed basis, reliability isn't an issue for general status. If you are wanting something to handle reliable event reporting, our implementation is probably not going to work for you. I could probably conjure a workaround for reliable event reporting, but it would some additional PLC code.

                As for MQTTS, that's working now and should be in the upcoming 2.4 release.

                Comment



                • #9
                  Good news on MQTTS.

                  Regarding QoS 1 - this can't really be simulated in code using QoS 0 since the PLC has no way to know that the broker has successfully stored the message. There's no mechanism to get that PUBACK back in QoS 0. There's also the (lesser) issue of increased PLC code complexity.

                  I'd respectfully ask you to revisit the issue of QoS 1. Perhaps you could use the microSD card to store the cached messages? I understand that this isn't exclusively a coding exercise for you but for reliable communication in poor-quality network conditions I think it's a must-have. I know it's possible on a PLC since other vendors have this capability.

                  Given that this PLC is otherwise ideal for IoT deployment it seems to me that your market for the product would be larger with this capability.

                  Comment



                  • #10
                    Originally posted by Andrew S View Post
                    Good news on MQTTS.

                    Regarding QoS 1 - this can't really be simulated in code using QoS 0 since the PLC has no way to know that the broker has successfully stored the message. There's no mechanism to get that PUBACK back in QoS 0. There's also the (lesser) issue of increased PLC code complexity.

                    I'd respectfully ask you to revisit the issue of QoS 1. Perhaps you could use the microSD card to store the cached messages? I understand that this isn't exclusively a coding exercise for you but for reliable communication in poor-quality network conditions I think it's a must-have. I know it's possible on a PLC since other vendors have this capability.

                    Given that this PLC is otherwise ideal for IoT deployment it seems to me that your market for the product would be larger with this capability.
                    The PUBACK isn't the issue, that's easy, the issue is the caching. It would be a big job that we simply don't have the resources for right now.

                    Comment



                    • #11
                      Understood. Would it be possible to simulate QoS 1 using PLC code? We'd need to (1) set the QoS flag to 1, (2) listen for the PUBACK response, (3) Queue and retry if necessary. I know that (3) is possible in code but I'm unsure whether there's a way to do (1) and (2). I'm willing to put in the extra effort on my end if necessary to make this work since the lack of reliable messaging is the only thing now stopping me from moving forward on this platform.

                      Comment



                      • #12
                        Originally posted by Andrew S View Post
                        Understood. Would it be possible to simulate QoS 1 using PLC code? We'd need to (1) set the QoS flag to 1, (2) listen for the PUBACK response, (3) Queue and retry if necessary. I know that (3) is possible in code but I'm unsure whether there's a way to do (1) and (2). I'm willing to put in the extra effort on my end if necessary to make this work since the lack of reliable messaging is the only thing now stopping me from moving forward on this platform.
                        I will look at what it takes to add QoS 1 in a way that would allow you to know if it failed. That may be kinda clunky though, where you set up the MQTTPUB as a one off and put exactly one entry in the table. Success means it went and was acked.

                        Comment



                        • #13
                          Looking back through some of the code and starting to remember why I thought this was an issue. MQTT is designed to work independent of the network medium/transport, so it provides its own ack/nak mechanism. When used with TCP, there is already a reliability mechanism in the transport protocol, so at the app level, if a packet fails to get there, it is generally presented as a failed connection. When I started trying to implement the MQTT level timeout/retry, it really didn't make sense, since the only way to not deliver was if the socket itself had failed, which was being handled at a higher level.

                          As it stands, I think that if I turn on QoS 1, the instruction will wait for the PUBACK before declaring the topic as being sent, but if we don't receive the PUBACK, I'm not sure that any form of timeout/retry makes sense. I think it will end up failing due to the busted network connection, which will terminate the instruction On Error. That should actually still give you what you want, but isn't strictly what I had intended.

                          Comment



                          • #14
                            The thing to remember with MQTT is that the resilience mechanism is end-to-end and not just for the network link. If the broker is not working correctly (I've come across this more than once) you would not receive a PUBACK even if the network connection is good. So I agree that TCP handles certain retries but that's Layer 4 whereas we really need L7 reliability.
                            With that said I'm definitely open to trying things to see if we can get the appropriate behavior. I appreciate you spending time trying to figure out a workable solution.

                            Comment



                            • #15
                              Originally posted by Andrew S View Post
                              The thing to remember with MQTT is that the resilience mechanism is end-to-end and not just for the network link. If the broker is not working correctly (I've come across this more than once) you would not receive a PUBACK even if the network connection is good. So I agree that TCP handles certain retries but that's Layer 4 whereas we really need L7 reliability.
                              With that said I'm definitely open to trying things to see if we can get the appropriate behavior. I appreciate you spending time trying to figure out a workable solution.
                              I put the timeout back in, so if the broker goes stupid on a good link, we'll retry up to 2 times (which could easily be higher), after which we dump the connection and report an error. It's currently hardcoded at 5 seconds, but could also be some subset of the specified keep alive. We do that with the PING. It's set to 75% of the keep alive time. I'm a PLC comm guy...a relic of the past...so I have opinions about what works well in a PLC, but I'll be the first to admit that the world outside is different.

                              Comment

                              Working...
                              X