Understanding MQTT: How Smart Home Devices Communicate

today on the hookup we're gonna take a detailed look at the lightweight Internet of Things messaging platform known as n QT t n QT t is a lightweight messaging protocol that allows your smart home devices to communicate with home assistant or any other mqtt broker haseo has a mosquito MQTT broker as an add-on and I highly recommend that everyone running home assistant is also running an mqtt broker you could use a remote broker like cloud mqtt but I really try to handle everything in-house so I'm not relying on cloud services for my smart home functionality also because everything in my smart home is within my network there's no reason to do any port forwarding to expose my MQTT broker or my specific devices to the rest of the internet giving me a little extra peace of mind each MQTT message contains three parts the message the topic and the quality of service or QoS packet will talk more about QoS later for now let's say I want to turn on my hallway light I would publish the message on to the topic lights hallway this process involves three steps first I'll need to use a client like node-red or home assistant to publish my message this message is sent to my MQTT broker and that broker will then post the message to that specific topic in my hallway lights which are subscribed to that topic will then receive the message and turn on your NQ titi broker knows a lot about its clients an MQTT broker knows which clients have connected to it in the past and it remembers them by their client ID it also knows which clients are subscribed at which topics and it knows which clients are currently connected because those clients send a keep alive message to the broker at a specific time interval the keepalive timeout is set by the mqtt broker and by default is 60 seconds in mosquito if a client goes 60 seconds without sending an MQTT message mosquito will then ping that clients IP address to see if it's still connected it's an for an N qtt broker to know if a client is connected this is because each client can also have a birth message in a last will and testament message the birth message will be published every time a client reconnects to the broker this is a neat feature but nothing mind-blowing the last will and testament is a lot cooler using the last will and testament or LWT message you can have a device alert you that it's gone offline but how does an offline device alert you the MQTT broker stores that last will and testament message for each of the clients that connects to it and when that client disconnects the broker then publishes that message to the specified topic let's take a look at one of my favorite mqtt clients no dread in no dread you've got two major nodes relating to MQTT one is the published node and the other is the subscribe node let's start with the publish node in this node you can send any message you'd like to any topic for testing out specific payloads it's useful to pair this with an inject node and then select string from the drop-down menu within the publish node you'll see a few options the first is QoS then we said that stood for quality of service which along with total message size is a huge advantage of using MQTT over something like HTTP quality of service has three levels QoS zero is often called fire-and-forget let's say my wife has tasked me with getting my daughter to clean up her room QoS zero would be like me blindly saying hey Scarlett go clean your room without actually knowing or caring whether or not she heard me I said it and that's enough QoS one is a bit different it's generally referred to as at least once this would be like me saying Scarlett go clean your room and then continuing to say it until I hear her say okay dad I heard you the problem with this is that if she's responding saying I heard you and I can't hear her respond I will continue to say clean your room and she'll think that I'm telling her to clean her room again rather than just knowing that it's the same original message QoS - is the final and most data heavy pub it's known as exactly once this means that I say scarlet clean your room she says I heard you I say thanks I won't tell you again and she says wonderful conversation that means that the transaction is complete let's say I didn't hear her say I heard you and I said scarlet go clean your room she would know that because I didn't say ok I'm done telling you in between those messages that I must not have heard her acknowledge me and then I'm not telling her to clean her room again I'm just repeating the first message that I said in most home automation cases QoS 2 makes the most sense because we're not really concerned about how much data we're sending if you're using cellular you might want to use QoS 0 or QoS 1 but the amount of data we need to transfer won't even be noticeable compared to the rest of our network traffic in addition to QoS you can also choose to send a retain flag the difference between QoS and the retain flag is that QoS only applies to currently connected clients if a client is offline during a publish it will never receive the message a retained flag tells your MQTT broker which is mosquito in my case to hold on to the last message in each topic in case a new client subscribes to it let me show you the difference using node-red first I'll pair an MQTT send node with an inject node and I'll select string for my inject payload let's call this payload not retained you can also see that there's an option here to set the topic in the inject node you can also set the topic in the MQTT send node which is what I'm gonna do next I'm gonna jump over to that send node and I'll select QoS - and false for the retain flag I'm gonna pair an mqt subscribed node with a debug node so I can see what's going to be sent to my Internet of Things devices I'll set the topic to mqtt tests and the QoS - - before I deploy this I'm going to cut this subscribe node out so we don't actually connect to it let's deploy and send our message as expected we can't see anything in our debug window because we're not actually subscribed to this topic let's paste our subscribe sequence back in and deploy as expected we still don't see anything because we sent our MQTT message while our client was not subscribed to the topic now let's look at a retained message I'll change my inject node string to retained and I'll change my MQTT publish node retain flag from false to true I'm gonna cut out my subscribe node again and deploy now we can send our retained message as expected we still can't see anything in our debug window because we aren't subscribed to that topic but here's where things get interesting let's paste our SUBSCRIBE sequence back in and redeploy as soon as weary subscribe the last message in that topic was sent to us let's cut out the sequence again deploy to unsubscribe and then paste it back in and deploy to re-subscribe you can see that the message gets resent any time the client connects to that topic this can sometimes cause an issue let's say i've misconfigured some of my devices and some of them send retained messages and some of them don't i'm going to send the message not retained to this topic with the false retain flag let's send it while we're subscribed as expected it comes through no problem but let's simulate the device disconnecting and reconnecting you can see that instead of the last message sent which was not retained we instead get the message retained this could cause a real issue if your device needs to have that not retained message sent to it to work as intended the only way to clear a retain message from a topic is to send a blank retained message to that same topic we'll just clear out our string select true for our retained flag and send it out you can see that my simulated device disconnect and reconnect now results in no message being sent maybe you've done your homework and you were under the impression that QoS 2 would ensure delivery of a message even to offline clients this does work but only under a few circumstances that aren't actually all that common in IOT devices number one the client must have previously been connected to the broker so that its client ID and subscribed topics are stored and number two the client must have connected with what's called a non clean or persistent session the most popular mqtt library used in IOT projects is the pub/sub client which is a really great library written by Nick O'Leary who's the same guy that actually wrote note read the pub/sub client library doesn't support persistent sessions which means that every IOT device that uses it which includes Taz mota does not support QoS to persistence so you're much better off using the retain flag instead if you want those messages to be delivered to offline clients the last thing I want to talk about is my MQTT topic schema if you followed my channel you've seen projects where I've used both schema types in my wireless doorbell video I published the state of the front-door two doors front / front where I put the topic type first and the specific device second but in my Rumba control video the topics were rumba front / command's rumba front / status and rumba front / charging having a consistent MQTT schema lets you debug your messages much more easily using topic wildcards let's head back over to node red and look at how to properly use wildcards for the window sensors in my house each of them sends a retained message to the topic window status / and then the specific window name by subscribing to the window status / pound sign topic it will act as a multi-level wildcard that picks up messages from each of my windows and since all those messages are retained they will come through at the same time once I subscribe to that topic using the other schema allows you to isolate a specific device and see all the MQTT messages sent from that device by subscribing to rumba / pound I can see any information sent from that specific device it's up to you which schema you want to use but I recommend you pick a single schema and stick with it unlike me if I had to pick a single one I'd say defining the device first and then the topic subject second is the superior method using this method for my windows I would define a single level wildcard using the plus signal so I could subscribe to family room windows status and kitchen windows status using the wild-card + front slash window status understanding mqtt will allow you to make interesting programming decisions when writing programs for your sensors if I knew then what I know now I would have done a few things differently when programming some of my smart home devices but that's all part of the fun I guess if you have any other questions about mqtt or you've got a suggestion for another video about MQTT in home automation leave them down in the comments if you enjoyed this video please consider subscribing and as always thanks for watching the hook-up [Music]

Channel: The Hook Up

Views: 249,827

Keywords: home assistant, hassio, home automation, hass.io, smart home, diy, electronics, arduino, esp8266, nodemcu, wemos d1, automation, mqtt, mosquitto, Iot, internet of things

Id: NjKK5ab0-Kk

Length: 12min 4sec (724 seconds)

Published: Tue Jul 03 2018