Announcement

Collapse
No announcement yet.

IOT Protocols

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

    IOT Protocols

    I see there's an IFTT integration thread, but considering my investigation into micro-controllers led me to this question, I think it should be here. Anyways, what's IFTT vs JSON vs MQTT vs REST? I don't have any interaction with anything yet other than Blue-Iris uses JSON which is a (WebRequest?). It looks like this: Now I see it leads off with http so now the WebRequest makes sense.

    The MQTT with the servers and Brokers seem to me something I would want to stay away from, but, I'm totally not sure. I ran into this MQTT vs REST post, and to me REST wins the day.

    http://www.rfwireless-world.com/Term...T-vs-REST.html

    Does/can HS support REST? If I get into ESP32's and Adafruit Arduino boards I don't have to do MQTT do I? MQTT can comms just from the ESP/Arduino to HS and not use some Hosted Webserver right?
    Finally, what's IFTT? Can someone post some example code from whatever protocol youre using like the JSON Request I posted above?
    I guess all these ESP/Arduino boards have these libraries and they basically can speak whichever protocol you install right?

    #2
    COAP is the IOT flavor or RESTful. It is used in the IKEA HA. It is point to point with ability to discover what the COAP server has to offer. It is like a client-server model with a protocol (e.g. get) as part of the standard. It may or may not be cloud based.

    IFTT is a cloud-based service that operates as a simple event engine where you connect to the cloud with a trigger condition (e.g. and IOT device senses motion) and the cloud will spawn an action (e.g. send SMS message). It often is not real-time.

    MQTT uses the subscription model. The MQTT broker acts much like a COAP server in getting data to those who ask (subscribe), but has the added responsibility to assure a Quality Of Service that is well-suited to IOT devices that often go offline either because of poor connection of intentionally to save battery life. The broker will recognize a client has been offline and when it comes back online it will provide the data that it missed.

    JSON is an encoding mechanism for payloads. It is relatively independent of the protocol or architecture. It is up to the end points (servers, brokers and clients) to recognize or not recognize JSON encoding. Same concept as the content-type of the HTTP encoding where some clients will recognize multimedia and others will not.

    There is overlap in COAP and MQTT with no "best". Each has strengths and weaknesses. Generally it affects what needs to be be implemented at the application level vs. what is inherent in the protocol. If your architecture generally pulls data as in a client-server scenario then COAP with its GET will fit with other things in your architecture. If your architecture is distributed with less reliance on a central decision maker then MQTT will satisfy your needs better.

    With mcsMQTT plugin the discovery aspect of COAP has been implemented above the MQTT protocol layer so the end user does not need to have application layer provisions to get this capability.

    HS Server has not implemented RESTful protocol as part of their server. I believe there is a user that has put a RESTful wrapper around HS, but I have no details. HS has connected to IFTT in the cloud, but again I have no details since I have not had a need for this capability.

    Comment


      #3
      The link to RESTFul API is here : https://forums.homeseer.com/showthread.php?t=163200


      Eman.
      TinkerLand : Life's Choices,"No One Size Fits All"

      Comment


        #4
        Picture a Deer in Headlights. What? lol
        With mcsMQTT plugin the discovery aspect of COAP has been implemented above the MQTT protocol layer so the end user does not need to have application layer provisions to get this capability.
        You're saying you implemented REST to some degree in your plugin?
        I have a couple of ESP32's in route, and your plugin can communicate with these things, and HS without the need for any cloud servers? I'm in!

        Comment


          #5
          You're saying you implemented REST to some degree in your plugin?
          I have a couple of ESP32's in route, and your plugin can communicate with these things, and HS without the need for any cloud servers? I'm in!
          When comparing apples to apples one should compare COAP and MQTT. COAP implements REST, but also integrates discovery. MQTT does not have discovery as part of the protocol so a discovery wrapper was build upon MQTT as part of mcsMQTT.

          REST has a server that is able to understand GET, PUT, POST and DELETE. The HTTP servers that have been around before machine to machine was a big deal has similar verbiage and concepts. It is essentially a model of big horesepower server and multiple clients each using the server as a means to have a common point of communication.

          MQTT is not a client-server paradigm so does not make sense to consider using REST methodology with MQTT. When a MQTT client has something to communicate it sends it to the broker/server. It does not PUT it to the broker, because it is implicit in the protocol. When a client needs information it does not make a GET request to the broker/server. It will already have this information because the broker/server will have already given it the most current update when it was published.

          MQTT is generally a local network protocol. The cloud is not involved. The broker/server exists somewhere on the network and can be on the same processor as other software such as the processor running HS. I use a RPi-like processor for my broker/server and its resource utilization is barely noticeable. There can be a network of brokers/servers with MQTT and these can span the internet, but this is generally not the typical use.

          You will be running some firmware on your ESP32. If your firmware understand REST then you need to find an environment where other things understand REST. mcsMQTT does not understand REST. If your firmware understands MQTT the mcsMQTT can be used to make a easy integration of HS and ESP32.

          The bottom line is that what is most important is the ubiquity of the protocol you select. You want something that is well adopted in the community you participate. Any of these protocols will suit your needs as the differences are really minor when it comes down to the user experience. Look around at the devices you expect to add to your HA environment and see what protocol seems to dominate. If it turns out there is this one killer device you want tomorrow that does not communicate using your protocol of choice it is likely that a bridge exists or could be written to make it part of your family.

          Comment


            #6
            Ok, I'm following a little. My initial projects are all about HS telling the ESPs to turn the connected relays On or Off, and I have a need to control addressable Led strips in some way. We'll see how it goes. I'm awfully determined to get coms to my fairy lights.

            Comment


              #7
              Are you going to roll your own firmware in the ESP or are you going to leverage off of what others have done? If you are doing your own then you have the option of not using a defined standard, but following something like is done for Arduino plugin.

              I have been working with Tasmota, but the port from 8266 to 32 is not yet complete. I have not followed very closely, but I doubt if any other 8266 versions such as ESPEasy or ESPurina are being migrated.

              I have the addressable LED strip for use in fake TV and in this case it was dedicated so just used a Uno and minimal firmware invoking the Adafruit library for the LED control.

              Comment


                #8
                I don't have the skills to roll my own firmware, i'll have to 'Borrow' someone's code off the Net. Luckily, my first couple of projects should be relatively easy, and i'm throwing that out there awfully loosely, but ESP+Latching relay Featherwing+led fairy light. I mean dang, that's right out of the Cub-Scouts IOT beginner merit badge kit. I can do this (Positive reinforcement!). The second project is two simple states of slow chasing 1ft long addressable strips where HS changes the routine. So there's an Arduino plugin? I'll have to investigate what it does, and the difference between mcsMQTT and it.

                Comment


                  #9
                  Looking at the Arduino Plugin description, it didn't say it was compatible with WiFi, so I guess I won't be able to use it for my applications I don't think.

                  Comment


                    #10
                    Guys,

                    This one is : https://www.youtube.com/watch?v=z5EXNfHYPfQ off topic but one to check out!



                    Eman.
                    TinkerLand : Life's Choices,"No One Size Fits All"

                    Comment

                    Working...
                    X