Announcement

Collapse
No announcement yet.

MQTTS and QOS on BRX

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

  • BobO
    replied
    Originally posted by dslusser View Post
    Does the BRX support the use of custom client certificates for an MQTT connection? We’d like to connect the BRX directly to AWS IoT, which requires client certs for authorization.
    Not yet, but that is something we will likely be addressing.

    Leave a comment:


  • dslusser
    replied
    Does the BRX support the use of custom client certificates for an MQTT connection? We’d like to connect the BRX directly to AWS IoT, which requires client certs for authorization.

    Leave a comment:


  • franji1
    replied
    MQTTS was added when we added QoS 1.

    Do-more/BRX is continuously being enhanced, and so there ends up being a bunch of features, so many "get lost" in the shuffle. The Updates.pdf file highlights all the features. It can be accessed via Designer's Start Page. Click on the What's New? Yellow Star in the top left corner of the Start Page. This will work for any version of Designer (you don't have to have 2.6.2 installed to see What's New, but you will have to have Internet access if you do not).

    Here's the Release Notes in the section for 2.5.2 release in Updates.pdf regarding MQTTS:

    Do-more Updates Rel 2.5.2, April 22, 2019

    5. Enhancements
    a. BRX MQTT Client expanded to include MQTTS, QoS 1, and Persistent Session Type
    The previous version only supported unsecured MQTT, using QoS Level 0 (At Most Once), with Clean session type. BRX Do-more Technology Version 2.5 adds support for:
    o MQTTS using secured TLS / SSL encryption, port 8883
    o QoS Level 1 (At Least Once)
    o Persistent Session (Subscriptions and their QoS state are maintained)

    Here's a link to the latest Updates.pdf:
    https://forum.hosteng.com/wndm/Updates.pdf

    Leave a comment:


  • BobO
    replied
    Originally posted by dslusser View Post

    Whelp....I must of missed something. I'll be back at it tomorrow. Sorry for the inconvenience.
    No inconvenience. The protocol drop list in the MQTT device config allows you to select MQTT or MQTTS.

    Leave a comment:


  • dslusser
    replied
    Originally posted by BobO View Post

    MQTTS is already supported.
    Whelp....I must of missed something. I'll be back at it tomorrow. Sorry for the inconvenience.

    Leave a comment:


  • BobO
    replied
    Originally posted by dslusser View Post

    BobO, any movement on SSL support? We have a few BRX's that we would like to do MQTT with but require SSL.

    edit: BobO, I skipped past your last post (#27) above. Our company would be interested in seeing SSL support.
    MQTTS is already supported.

    Leave a comment:


  • dslusser
    replied
    Originally posted by BobO View Post
    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.
    BobO, any movement on SSL support? We have a few BRX's that we would like to do MQTT with but require SSL.

    edit: BobO, I skipped past your last post (#27) above. Our company would be interested in seeing SSL support.
    Last edited by dslusser; 01-16-2020, 04:09 PM.

    Leave a comment:


  • Dirtybeef
    replied
    Thanks BobO.

    Not that there's anything wrong with TLS alone, but it would help in our situation where the MQTT server is not public. (And apparently our system Admin would like this)

    We are also going to experiment using the smaller BX-DM1E-10ER3-D as a basic datalogger/"IOT" device (even though this is wayyyy overkill, but we really like the software and 1 trip to fix something in a remote area makes up the price difference. We'll see how these do when our solar power starts underperforming, our only concern.)

    Leave a comment:


  • BobO
    replied
    Originally posted by Dirtybeef View Post
    Any plan to add certificates to the MQTTS implementation?
    Plans? No, but we're willing to consider it.

    There is a significant increase in user effort to manage, use, and maintain certificates, which most users really don't want to do (it should just work, right). We were able to bury that for SMTP, but there wasn't an easy way to do so for other services. We have talked about using the SD card as an optional way of providing a certificate, but have not pursued it.

    Leave a comment:


  • Dirtybeef
    replied
    Any plan to add certificates to the MQTTS implementation?

    Leave a comment:


  • 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:

Working...
X