How do you use MQTT?

Blynk 2.0
1

Hey Blynkers,

We are thinking about implementing MQTT and would like to hear your input. Basically, how do you use it today, how do you structure your topics, which configurations are usually needed, etc.

If you have any particular ideas on how it can be implemented in Blynk so that it flexible enough for majority of use-cases, let us know.

Thanks!

1 Like
2

Let’s start with how similar MQTT and Blynk are…

MQTT is very similar to Blynk. There’s a server/device relationship (in MQTT speak the server is know as the Broker) that maintains a connection with a heartbeat, and the server has the ability to know when a device has disappeared off the radar.
The server can then update a topic to indicate that the device is offline (dead). This is known as the Last Will and Testament and is very similar to Blynk’s Online/Offline indication functionality.

With MQTT the device can subscribe to topics (more about those below), and when a message appears on that topic it triggers a callback. The value sent in the message can be retrieved and used in the code that you want to execute when the message arrives.
This is virtually identical to the BLYNK_WRITE(vPin) and param.asString() functionality in Blynk.

Devices can write to topics - known as “Publishing” in MQTT speak - and this is virtually identical to the Blynk.virtualWrite() functionality in Blynk.

Because of these similarities, the logical implementation would be to allow devices to subscribe to datastreams on the Blynk server, so the device is notified when a datastream value changes, and to publish data to datastreams. The datastreams would therefore be your topics.

Topics in MQTT
Topics are very similar to a folder structure in Windows. Everyone designs their folder structure to (hopefully) provide a logical structure to organise your data, depending on what you’re trying to achieve.

Also like Windows you can use wildcards in MQTT. This is where the implementation in Blynk could get messy - but maybe not.

Imagine you have a situation where you have 6 lamps in your living room, which are all controlled by different devices, and you want the ability to turn them all on or off with a single command.
MQTT allows you to structure your topics like this:

Livingroom/Lamp1
          /Lamp2
          /Lamp3
          /Lamp4
          /Lamp5
          /Lamp6

and allows you to issue a wildcard command at the Livingroom level that will be cascaded down to all of the child devices, which could be used to turn them all on or off.

To achieve this in Blynk you’d need a structure - similar to the organisation structure - to allow you to group datastreams. I don’t see how this could easily be implemented and TBH I dont think it’s that desirable.

So, I think the Blynk implementation of MQTT shouldn’t support wildcards.

If you did want to implement it, then you’d probably need to allow each datastream to have an MQTT topic defined for it, but that still looks very messy to me - especially from a server-side processing perspective.

I don’t personally use a topic structure that lends itself to wildcards, and in the above example I don’t have a problem with writing to six consecutive topics with an on or off command, in the same way that would in Blynk with six consecutive Blynk.virtualWrite commands.

Therefore, my preferred method of referencing the Blynk datastreams wold be to treat them as topics grouped by device. I think I’d like to see the topic being:

auth_token/vPin/value when you’re writing data to it, and:

auth_token/vpin when you’re subscribing to it.

This would make the implementation far simpler from Blynk’s point of view.

EDITED TO ADD…

Something I forgot to mention is that you’d probably need to add the facility to do things like Log an Event, Sync a virtual pin, Set a widget property etc via an MQTT command. I guess all of the things that you can do via the REST API.

As Events are Template based you might do this by sending the command to a MQTT topic like this:

event_code/event_text

The datastream specific commands like setProperty might be something like this:

auth_token/vPin/setProperty/OnColor/value

End of Edit

Hopefully this helps. I’d be very than happy to share more info or get involved in testing.

Pete.

3 Likes
3

Adding to what Pete said (great summary by the way), MQTT would be a great addition to the already awesome platform.
A few items to take into consideration when implementing MQTT.

  1. MQTT Server - Most IOT connections make use of a dynamic IP, and even though IP reservation is possible in some routers we found it stays a problem to keep a connection. Similar to saving the SSID to EEPROM/Preferences, so should the server IP be saved and have the function to either dynamically update or have the function from the App to manually update the IP.
  2. Blynk.virtualWrite() - Data Volume. Here the limitation is that with a local MQTT server and local IOT device, a lot of data can be shared (subscribe and publish) between, the limitation or warning is writing that data back to Blynk, the sheer volume may bring the IOT processor to stop responding.
  3. MQTT Version - It’s important to support both MQTT 3.1 and 5.0.

I hope this helps,

Cheers, Pieter

2 Likes
4

I have used MQTT in different ways with promamable logic controllers, PLCs, and was excited to see that it can be implemented into Arduino devices.
I like the way Blynk works with Arduinos and am looking forward to be able to incorporate MQTT with Blynk.
It’s a good idea but, keep it simple to use.

Joe

2 Likes
5

@pieteroosthuizen @JoeCool

This will be rolled out in a week or so:

1 Like