MQTT Network Controller

Learn how to publish and subscribe to messages sent via an MQTT message broker to be able to remotely control or monitor the status of devices, including Arduino, Raspberry Pi, Android, PC, and Wemos D1.

00:00 - 05:55 Introduction and Demonstration
05:56 - 07:34 Android client demonstration
07:35 - 13:03 Arduino, Wemos, and Raspberry Pi Wiring
13:04 - 20:01 Installing and testing the Mosquitto MQTT server
20:02 - 37:24 Code for Arduino Ethernet and MQTT client
37:25 - 43:05 Code for Wemos WiFi and MQTT client
43:06 - 48:33 Code for Raspberry Pi MQTT client
48:34 - 50:10 Android client (MQTT Dash)
50:11 - 51:12 Wrapup

[ValuedTeamMember]

6 years later and as interesting as it can get Your "one handed typing" is humbling. Nice on-screen graphics! Cheers from So.Ca.USA 3rd house on the left

[robertgilbert]

Well done! Clear and concise tuition. I’m moving away from Blynk into MQTT and this was probably the best 'first step’ that I’ve come across. That 'front end' that you spoke of at the end of your talk, I hope that it’s still a likely project. I eagerly await your updates.

[bradg]

I wish I had found this video a year or two ago. Nice description of the various different pieces of HW, and SW and how they differ. Well done.!!!

[hesperaux]

Firstly, thanks for the video. It is helpful and you obviously put lots of effort into it.
Just wanted to propose a suggestion. At around 29 minutes or so, you talk about using strings instead of integers for command indices for readability reasons. I would suggest having the best of both worlds: keep an enum with a list of names that correspond to integers. This makes your code safer because when you compile you are not allowed to have typos, and it is just as readable because the enum names, rather than the integer value of each enum, are what is in the code.
The only downside is that the same enum must be defined on all platforms involved in the network, but in my opinion it's worth it.

[deaneatsgreens]

Wonderful explanation! I loved the variation of devices used instead of the typical sole device, as well as the "puzzles"! Keep up the great videos!

[DigiRabit]

Thanks again for a very clear and understandable tutorial. With a few tweeks I managed to do the same with esp32.

[alarmitCreator]

you put the puzzle pieces together, good job, well done

[JavoCover]

Thank you, just what I was looking for!

[davidhargrove]

This video caught my eye --- long time MC programmer here for industrial controls. I wonder if you've considered the implications at putting something like a Beaglebone Black or another board with PRUs in the mix to control extremely time-sensitive devices/triggers? Great stuff, thanks. I like the way you've presented MQTT here.

[Lennings]

also just want to say great stuff you making.

[harrywhite]

Wow. This is a very detailed explanation. Thank you.

[quantumsensing]

Oh yes, I forgot to say thank you for the great video - I got a lot out of it.

[ovi_]

it is ''puzzling'' that you've called them actions '''puzzles''. Anyways...keep up the good work. And by the way, great video.

[PeterMisovicProfile]

Very clean and ubderstable video! Thank you 🙏

[Geeksmithing]

This is a very helpful video! Thanks! You def earned a sub!

[davecobb]

Hi Alastair, thanks for taking the time to explain mqtt in detail. I feel you've done a great job explaining it. In your code you reference a pulseCount var, but it's not used elsewhere. Can you explain how you would go about monitoring the heartbeat? I get the frequent publishing of the count and subscribing to it, just unclear as to how you would action an mqtt or WiFi failure. Also, have you had chance to play with micropython on the esp32 and mqtt? Cheers!

[SenthilKumar-vumf]

I found this video is fruitful and could learn the concept of MQTT and I have a question on deployment - what is the best practices of deploying the bug-fixes, updates of client software onto MQTT client devices?

[dionzand]

Hi, I just found out about your channel. Thanks for all the helpful tips I've already gotten from your videos. I am currently working on a project where I want to implement a MQTT-server. However, since MQTT works with a publish-subscribe principle, there is no real check if the message was received by a subscribed client. In escape rooms I believe this is a crucial part, since you want to make sure that a message has been received. How would you account for this?

[winfridfluggen]

super video ...really great!! thank you very much!

[vonries]

If you like the WeMos D1 mini or any esp8266 board for that matter you will LOVE, love, love the esp32! It runs much faster than any Arduino or Raspberry Pi. It has plenty of analog to digital pins as well as a single digital to analog pin. Three processors, security, deep sleep mode (to conserve battery life), Bluetooth, PWM, Mesh and much more. If you get one then you can replace the Raspberry Pi and then turn the Pi into your MQTT Broker (even a Raspberry Pi zero W will work). One final question that I may have missed. Did you send the message (i.e. payload) back to the MQTT Broker, so if it did not receive the message correctly or if it did not see the message at all the Broker could resend the message?