Announcement

Collapse
No announcement yet.

FACTS P1AM Example Series #1 - MQTT Call and Response

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

  • FACTS P1AM Example Series #1 - MQTT Call and Response

    Purpose:
    This example uses an MQTT broker to update the outputs of a P1-08TRS the inputs of a P1-08SIM. You can easily switch these out for any discrete input or output module.

    I used shiftr.io for this example. This is a free MQTT broker that provides visualisation and is great for testing. If you want to use a different broker, update the broker string to the proper URL and update any login credentials.

    Both the sending and receiving portions are included in this code, but these could be separated out into separate P1AM units or web interfaces.

    With a little bit of modification, you can turn this example into a remote monitoring or combine it with Modbus TCP and connect an aging PLC to the cloud.

    Dependencies:
    P1AM - In the library manager or or on GitHub: https://github.com/facts-engineering/P1AM
    ArduinoMqttClient - In the library manager or on GitHub: https://github.com/arduino-libraries/ArduinoMqttClient

    Products Used:
    P1AM-100
    P1AM-ETH
    P1-08SIM
    P1-08TRS

    Check out the code here:
    https://github.com/AutomationDirect/...d_Response.ino
    Last edited by FACTS_ENG_TEAM1; 03-02-2020, 01:24 PM.

  • #2
    What about using ssl?

    Comment


    • #3
      I think you should be able to do it, but I haven't personally.
      You'll need an SSL library like this one: https://github.com/arduino-libraries/ArduinoBearSSL
      For that particular library, it relies on a crypto-auth chip which Adafruit sells a version of: https://www.adafruit.com/product/4314

      Comment


      • #4
        Yeah, that was what I thought. I'm just using a local broker on a secured network and then a bridge to the Google Cloud IOT core.

        Have you had any luck using the Arduino IOT cloud? They've got a library that supposedly does encryption (but not SSL) for the smaller devices. I think it's called "ArduinoCloudIOT".

        Comment


        • #5
          Looks like the "SSLClient" library is working to connect to Google.com via SSL over HTTPS with the SAMD21-based units. I'll have to see if I can bridge that to an online MQTT broker after I get some actual work done today!

          Comment


          • #6
            I think I played with ArduinoCloud and Adafruit's cloud platform a while back. I don't remember anything about the encryption/SSL features though. I want to say Arduino Cloud supported boards typically have a ATECC508A chip, so that might be part of it.

            Are you looking at this library? https://github.com/OPEnSLab-OSU/SSLClient
            That one seems pretty promising and doesn't seem like it needs any hardware for the SSL.

            Comment


            • #7
              I'm able to run the example that uses SSL to connect to www.arduino.cc, which took ~15s to establish the SSL connection, so I don't think it will work within my task structure (since there's no pre-emptive interrupts for the other tasks to fire.)

              Trying to connect to Google.com gave me a "404: Page Not Found" error.

              Comment


              • #8
                Yeah I'm just going to run a ThingsBoard.io instance locally. Even if the unit had the ECCX chip, initiating an SSL handshake every time I want to send/receive isn't how we're doing it in the high-dollar automation industry so it's probably not a great solution here either.

                It really gives some perspective as to what's actually happening on that ECCX chip that it's taking the SAMD21 CPU >8s to make an SSL handshake. Entirely too long for this project! (Couldn't imagine a hang of 8s while my auto-feeder is going.)

                I haven't seen any calls to the MQTT library blocking the task scheduler (Arkhipenko's) so I'll just keep running ThingsBoard locally.

                Comment


                • #9
                  Those chips are definitely solid. What library are you using that requires the handshake every send/receive? Have you looked at Arduino's WifiNINA library or their port of bearSSL. I would assume those work fine with Ethernet since everything is based on their stream/client classes still.

                  Comment


                  • #10
                    I'm just using the plain "SSLClient" library linked above. I was opening and closing the connection each time I wanted to send data rather than sending the "keep-alive" message. SSL requires a message encode/decode handshake that's apparently pretty intensive without the ECCX chip.

                    I haven't used the WifiNINA library because I've never used a Wifi-enabled Arduino. Since I'm including an Ubuntu server as an MQTT bridge, I've just got a single Ethernet cable running from the P1AM to the IOT Server, and I let the IOT Server manage SSL handshakes to the cloud platform. I've been able to bridge ThingsBoard to Google Cloud IOT, but we're trending more towards using Azure at work so I'm going to take a look at some of the Azure services.

                    Comment


                    • #11
                      The WiFi enabled Arduino's all use a variation of this chip(the ECCX chip) to my knowledge: https://www.adafruit.com/product/4314
                      This would be a pretty inexpensive way to play around with those features. I thinkit has azure certificates already burned in. Adafruit is on essential service order's only, but you can probably find this breakout through other vendors/amazon.

                      Comment

                      Working...
                      X