Project Mercury Part II – Publishing MQTT Messages

In last week’s Part I of Project Mercury, I covered reading MQTT messages in VB.Net using the MQTTnet Nuget package. There aren’t any VB examples for an MQTT client floating around, so I put together a quick and dirty illustration. I completed the next section on the following day, but was promptly sidetracked with a trip into the wonderful world of SQL – one of the future parts of the program will be saving data to a database, which significantly enhances the value of the data! In any case, here’s an example of how to publish MQTT messages from your VB.Net app!

Before I went any farther, I made a few minor changes to the existing code. This app is really two different programs in one. The part that receives and displays messages (subscribes) listens passively without any input from the user. I changed variable names to reflect this is the receiving portion of the app. I also added a couple of additional topics (subscriptions) to illustrate that you’re not limited to one topic at a time. The screen shot does a bad job of showing me sending to three topics, but the three messages displayed are all from different MQTT topics!

The new addition publishes messages, requiring a value for the topic (default value is provided) and also for the message. If the message is blank when the user clicks Publish, nothing happens. In contrast to the listener, this function is limited to one topic at a time in my example, though you could send duplicate messages to multiple topics, if you want.

One minor note – I changed the Async Functions to Asyunc Subs. Since these are handling form.load or, we want a sub – a function would just ignore the task returned and any exceptions. What good are ignored exceptions? We WANT to know what is breaking so we can fix it!

One major note -I didn’t specify QoS (Quality of Service), Clean Session (True or False), or LWT (Last Will And Testament). These are important parameters that you should use when you implement a custom MQTT solution for your own home automation ecosystem and they’ll show up in the final stage of my project, but without much explanation.

HERE is some important reading that you need to dive into before starting on your own app!

Also, I ran into some interesting behavior with variations on the ClinetID – if you’ve got two connect objects with different clientIDs, they don’t play well together. I’d expected that if the clientID for both was the same, it would ignore any messages that came from the same clientID, but that’s not so. That would provide some value – I could subscribe to a topic but ignore any data sent from the app. Instead, I’ll need to use distinct topics to handle this need.

Finally, HERE is a link to a list of parameters for the MTQQnet library – since this is supposed to be just a quick example, there’s a ton that I didn’t touch.

Next time, we’re going to play around with SQL to save data, which paves the way for RFLink, and then combining everything (X10, RFLink, send/receive MQTT messages, and saving selected data to SQL) into one cohesive application! is the website for our Facebook community, The Smarter Home Club – which is an umbrella for all kinds of smart home technologies – home automation, security, custom electronics, weather stations, alternative energy, you name it. DIY focused.

If you’re interested in joining the Smarter Home Club’s Facebook group, please follow this link:

The Smarter Home Club on Facebook