Strategies for MQTT devices

I just downloaded FlyingDiver's MQTT broker and connector plugins. Currently I'm using an ESP32 and a breakout board to plan my door state sensors for the home project coming up. Up to this point I was using the UDP Listener plug-in to listen for UDP packets from the ESP32, which would send out a JSON payload when a door state changed.

With MQTT I can eliminate the UDP approach and use a tool like MQTT Explorer to see the state of the broker, which is very nice for debugging.

I've organized my doors states like so:

home/door/utility/state
home/door/front/state
home/door/rear/state

and so on. The value of each of these is 0 (closed) or 1 (open)

What I'm wondering about now is how to organize my 21 door states. Should I create a separate MQTT connector device for each door state, or should I create one MQTT connector that subscribes to all 21 door states? In any case, I'm going to need to setup a trigger to run a script on receipt of a specific topic match. Thoughts?

And finally, thank you FlyingDiver for these excellent plugins!

You want one connector device for the connection to the broker. You want a shim device for each door. You’ll need one trigger to handle all the door devices. You’ll use the door name as the unique id for the devices.


Sent from my iPhone using Tapatalk

And just subscribe to home/#.


Sent from my iPhone using Tapatalk

Ok, I didn't know I needed the Shims plugin. That's installed now.

Just to be clear, this is how I have things setup right now... I have a MQTT Connector subscribed to cdb/# (not using home anymore, using cdb instead).

I also have an MQTT shim for a particular door, but am not sure how to configure that.

And just so you know how I'm publishing, here's. a screenshot of the door states from MQTT Explorer:

Start with this thread post and see if it answers your questions.

viewtopic.php?f=316&t=26171#p210518

Also this guide is in the Shims wiki.

https://github.com/FlyingDiver/Indigo-S ... asic-Setup

Thanks for pointing me to those resources. After reading and trying a few things, I now have it working, though I'm not quite sure how

Following up with some food for thought.

I'm wondering the best way to structure my MQTT tree. What I have so far are three levels that comprise an object:

Level 0: Home name ('cdb' in my case)
Level 1: the item type ('door', 'window', or whatever)
Level 2: the name ('utility', 'front', 'rear', etc)

And then under there, either raw or JSON data for specific attributes for that object.

Is there a better, more granular way?

That seems perfectly reasonable. The alternative I've seen is to have sub-topics for each possible attribute, with only raw payloads. But since we can deal with JSON payloads fairly easily, I wouldn't do that.

If you have all the attributes of a device in a simple JSON dict, then you can use the mutli-states key field (with a "." in the field) to put all the attributes in device states.

Excellent. I'm now going to retire UDP Listener, which I was using to listen for messages from the Arduino and then process them through a Python script.

Thank you FlyingDiver for making great plugins.

...
I've organized my doors states like so:

home/door/utility/state
home/door/front/state
home/door/rear/state
...

I have only now stared working my way back through older posts to see what I can learn and I came across your post. I don't know if you knew about this, but there are two forms of wild cards in MQTT. The # as noted already in this thread, and the +.

The + may be used to replace any single level in a topic. So, the pattern home/door/+/state would match all 3 of your topics.