Column - Phil on IoT

Part 3, man o man, who would have thought that I would already be into my third article here.

In my April 2016 column, Exploring the World of IoT – Part 2 , I discussed standards bodies and the three primary frameworks within the IoT space. This month’s column is going to take a deep look at the protocols that exist within the Internet of Things.

I almost considered not including the Protocols in this column because of how damn hard it is to write about this layer. I mean how do you take something as wonderfully exciting as an Request for Comments (RFC) and turn it into a blog post?

That is a challenge I faced and I promise you this post will be the most exciting article on IoT protocols you’ve ever read.

CoAP- Constrained Application Protocol
This protocol is like a weed, no matter how many times I think I’ve seen the end of it. It keeps coming up. The CoAP Protocol was designed with resource constrained devices in mind and in certain IoT spaces it makes great sense.

However, I’m struggling to understand the why when it comes to Building Automation.

From a technical perspective the solution looks like BACnet and HTTP got together and gave birth to a protocol.

From the HTTP perspective the protocol supports the common verbs one would expect with a Restful Protocol. However, the solution is purely UDP and supports discovery and change of value subscription which are unique BACnet properties.

While the dual nature of this protocol is fascinating it is equally frustrating. I often find myself saying “Is it a bird, is it a plane, nope it’s just CoAP."

This is a protocol that can do so much yet it's doing stuff that BACnet and HTTP/2 already do quite well.

And therein lies my struggle, why am I going to reengineer my building automation system to accommodate a protocol that my device already has similar feature sets to?

Therefore my plea to software/hardware manufacturers. Think long and hard before you think of introducing other protocols into the BAS eco-system. I have yet to see a compelling reason to adopt CoAP.

HTTP – Hypertext Transport Protocol 2

HTTP the Dos! (that’s Spanish for two :-D ). HTTP 2, ah, it's everything HTTP should have been but wasn’t! With so many capabilities where does one start? How about we look at the three main features that matter to building automation systems?

Multiplexed Streams-
Some of you may be saying to me “Phil what the hell are you talking about”? Multiplexed Streams are essentially the combination of two or more data message sessions. Think about it this way. You’ve got a phone line leaving an office building and it is a single line. You have 10 people on the phone. The phone system tags each conversation as a stream and then puts it on the wire.

Well with HTTP 2 you have a way to combine messaging to deliver a single frame that contains multiple messages. Schweet! and very useful for high-traffic IP busses.

Prioritization-
For so long we have relied on the BACnet priority property to communicate to other systems, however once that hits the application layer all bets are off. Fortunately, with HTTP 2 we have a way to prioritize systems by adding a priority flag. This enables the priority of our messages to be communicated to devices that may not understand how to interpret the BACnet priority flag.

MQTT

No IoT conversation would be complete without a mention of Message Queue Telemetry Transport or MQTT for short. MQTT is the original Message Broker for IoT. If you buy into this concept that millions of devices will be communicating to one another then you need some sort of governor to keep the messages from colliding each other to death.

Enter the Message Broker. You may have heard the term Pub-Sub. No, this does not mean that your regular English bartender is out sick today. Publish and Subscribe is a way to, wait a minute….

Publish data and subscriber to data publishers. It’s that simple! MQTT allows devices to publish or to subscribe to data. So essentially you could add a sensor and it could automatically begin to publish its data to a mid-level broker who then could take all his publishers and publish to a top level broker.

Think of MQTT as the Ponzi scheme of IoT. All data is gradually summarized as it moves up the chain towards top level brokers.

Web Socket

Web socket provides speed. It is valuable to IoT because of how it goes about its messaging. If you think of HTTP, it is what is called an asynchronous protocol. Somewhere sitting in the cloud is a server. This server is lonely and it is waiting for folks to talk to it.

When it receives a message it looks at the message and returns a resource (think HTML file) to the sender. This goes back and forth but it requires some overhead to maintain the TCP stream.

Web socket however uses full-duplex communication. This means that while the client is sending the server can be sending also. You can imagine how on a massive controller network this would be preferred over standard HTTP.

But wait there’s more! One of the things that constrained HTTP was the TCP handshake and Header overhead. When you have millions of messages this can end up eating bandwidth. To counter this Web socket avoids the three step handshake and simply shares a web socket key called “Sec-Websocket-Key” (who says engineers can’t be in the creative naming business”).

From this point on the client and server are able to communicate using full-duplex communication.

This protocol has been around for a while and I see it popping up all over the IoT landscape. XMPP is an open protocol and it structures data for real-time exchange.

So think about it, so far the protocols we discussed above take data and sling it out onto the wire. It is up to the end devices to then take that data and make heads or tails of the formatting.

When accuracy matters you want to use a formatted protocol. Imagine the difference between a poorly coded HTTP message that mixes your 72 degree set point and your 32% chiller signal up, oppsy!

XMPP avoids this by using a familiar Key : Value structure based on XML. The beauty of this is that you can have a solution whose data is easy to digest.

However, there is a dark side to this beast in that XML requires more processing. Whereas HTTP is simply communicating a stream of data XMPP is requiring that data to be formatted and structured.

Someone has to do this work and that someone often happens to be the device. If your devices can handle the resource cost of implementing XMPP then you should use it, it makes data consumption so much easier.

Wow! That was a lot, you still with me there? The finish line is in sight just stick with me for a few more seconds!

In this column you learned about the current state of IoT standards, applications, and protocols. I provided many links for those of you who want to take a deeper dive into these technologies.

In next month’s column I will be discussing a few technologies that exist right now that you can implement in your new construction or retrofit projects. I will lay out a plan for assessing these technologies and provide a step by step process for aligning these technologies with your desired outcomes.

I appreciate you reading this article and if you have any questions for me please don’t hesitate to reach out to me on my blog or email me let me know your thoughts!

Phil has been working with technology for the past 14 years. He is the creator of Building Automation Monthly and is currently a Senior Technology Program Manager for Johnson Controls. In this role he manages multiple products and technical programs. He also works as a liaison between marketing, sales, and engineering in order to translate sales and technical speak to meet customer needs.

Phil is known for his variety of knowledge. He is fluent in several programming languages, has designed the IT Infrastructure for several of Johnson Controls customers, and has worked on and integrated almost every Building Controls Product in existence.

Phil runs the popular blog Building Automation Monthly at http://buildingautomationmonthly.com and has written for the ASHRAE Journal as well as other trade magazines and has spoken at IBCon. In his off time he likes to program, write, and spend time with his wife and three young children.
______________

As always, the views expressed in this column are mine and do not necessarily represent Johnson Controls Inc. or any other organization. If you want to send comments to me directly, feel free to email me at Phil@philzito.com

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources