Announcement

Collapse
No announcement yet.

MQTTS and QOS on BRX

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

  • Andrew S
    started a topic MQTTS and QOS on BRX

    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.

  • Andrew S
    replied
    Gotcha. That's a reasonable format. As a possible future feature enhancement may I suggest allowing that field to be overridable. Some back-end systems require MQTT devices to have a specific format for their client-ID.

    Leave a comment:


  • BobO
    replied
    Originally posted by Andrew S View Post
    Can you confirm that the MQTT Client-ID is the device name? I need to set specific client-ids which cannot change over time.
    DOMORE_mmmmmm_iiii

    Where mmmmmm is the MAC address of the unit and iiii is the device ID of the MQTT device. Since there can be more than one device, it was necessary to use the device ID to make it unique.

    Leave a comment:


  • Andrew S
    replied
    Can you confirm that the MQTT Client-ID is the device name? I need to set specific client-ids which cannot change over time.

    Leave a comment:


  • BobO
    replied
    Originally posted by Andrew S View Post
    Looking great Bob. This is exciting. Will all of these changes make it into 2.4?
    That is the hope, barring testing issues.

    Leave a comment:


  • Andrew S
    replied
    Looking great Bob. This is exciting. Will all of these changes make it into 2.4?

    Leave a comment:


  • BobO
    replied
    Fyi...


    Click image for larger version

Name:	image_3784.png
Views:	17
Size:	36.9 KB
ID:	120495

    Leave a comment:


  • Andrew S
    replied
    Regarding the MQTT Client ID - it's exactly what you set in the Device Name field, right?

    Leave a comment:


  • Andrew S
    replied
    Great. Thanks Bob.

    Leave a comment:


  • BobO
    replied
    Originally posted by Andrew S View Post
    To give you an idea of the application - we have controllers in fairly hostile locations that tend to be in remote areas. It's not unusual for their network and power connections to be out on a regular basis. Regulatory requirements decree that we keep permanent logs of events (that typically get sent to the cloud via MQTT and then discarded on the controller). Thus we can't throw away messages unless we're sure they've been accepted at the far end. It's an interesting scenario but I suspect not terribly unusual in the IoT world.

    One other thing I just though of - would it be hard to expose the clean-session flag? Our requirement is to set it to false (ie persistent sessions) - I didn't see this in the BRX/MQTT video.
    It's hardcoded, but easy enough to change since we're already messing with the UI.

    Leave a comment:


  • Andrew S
    replied
    To give you an idea of the application - we have controllers in fairly hostile locations that tend to be in remote areas. It's not unusual for their network and power connections to be out on a regular basis. Regulatory requirements decree that we keep permanent logs of events (that typically get sent to the cloud via MQTT and then discarded on the controller). Thus we can't throw away messages unless we're sure they've been accepted at the far end. It's an interesting scenario but I suspect not terribly unusual in the IoT world.

    One other thing I just though of - would it be hard to expose the clean-session flag? Our requirement is to set it to false (ie persistent sessions) - I didn't see this in the BRX/MQTT video.

    Leave a comment:


  • BobO
    replied
    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.

    Leave a comment:


  • Andrew S
    replied
    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.

    Leave a comment:


  • BobO
    replied
    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.

    Leave a comment:


  • BobO
    replied
    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.

    Leave a comment:

Working...
X