MQTT Plugin

I'd like to request a new feature. I would like to see an MQTT Bridge added. I want to publish and consume messages to/from an external MQTT Broker. There are two such bridge plugins that exist today. The GreenSkyMQTTBridge lacks any documentation and is very specific to the schema used by SmartThings and HA. For mqttGateway, it just crashes. When I setup a new Device for Topic Subscription, no matter what I fill in or don't fill in for the configuration I get:

Code: Select all

mqttGateway Debug               validating configUi
mqttGateway Error               Error in plugin execution UiValidate:

Traceback (most recent call last):
  File "plugin.py", line 383, in validateDeviceConfigUi
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1335, in _execute_child
OSError: [Errno 2] No such file or directory


Thanks,
Matt

Got an MQTT broker in mind? I might take a look at it if I can find a use case.

Hello Joe,
Thanks for the reply. I am currently using Mosquitto for my broker.

Code: Select all

mosquitto version 1.4.15
mosquitto is an MQTT v3.1.1/v3.1 broker.


As my sensor network expands beyond Indigo (to include remote weather stations, Home Assistant for a sensor running off a Raspberry Pi, etc), I want to be able to abstract my Command and Control architecture away from solely talking to Indigo. Having Indigo publish to and consume from topics from the new C&C architecture (aka Mosquitto) is where I am headed.

In another case, I FINALLY got account linking working for a native Alexa Smart Home Skill (because they greatly simplified the process if you choose to use Amazon as your identity provider), which means I will take my https://github.com/msreynolds/askIndigo skill and make it work without having to invoke the "indigo" skill name. So we can just say Alexa, turn on the kitchen light, etc. To make this skill even better, instead of talking directly to Indigo via its public Reflector URL, I could send the commands to the MQTT broker instead. Were an Indigo bridge subscribed to the right topics, it could respond as needed.

As a user I want to:
1) Configure a MQTT Bridge plugin for Indigo to point to a given MQTT server URL (with username/password) TLS or WSS
2) Publish messages to a configurable topic when a given device changes state.
3) Publish messages to a configurable topic when a given action is run.
4) Publish messages to a configurable topic when a given variables change value.
5) Subscribe to a configurable topic and in response to incoming messages, run a custom script (I would create 3 of these instances, one custom script for each to handle devices, actions and variables)

There is nothing inherent about the MQTT schema being used, only referenced in the configurable topics and likely within the script that runs when an incoming message is received.

Hope thats enough to go on? I have private hosting/repos on GitHub, let me know if you need or want to collaborate there?

Thanks,
Matt

One does no run properly with the latest indigo. The other ... is very specific to the schema used by SmartThings and HA.

+1. I've had a couple of instances lately where I've needed to consume Mqtt data into Indigo.

I played with both the existing plugins and found it challenging to get the results I wanted. I needed to do two things. The first was to feed the data from a topic into indigo triggers so I could take action if the topic equalled X. The second was to set the data from a topic into an Indigo variable so I could have another trigger react to it (set the brightness level of a light). The existing "mqttGateway" plugin allowed me to achieve the latter. It just took a while to figure it out.

Got an MQTT broker in mind?

If you need a local Mqtt broker then Mosquitto seems to be the best option for a Mac. Being command line driven it's not difficult but not super simple to get working. A plugin that included the Mosquitto broker as an option would be amazing.

As a user I want to:
1) Configure a MQTT Bridge plugin for Indigo to point to a given MQTT server URL (with username/password) TLS or WSS

OK, that seems clear enough. Someone else asked for an internal broker (one provided by the plugin). Is that useful?

2) Publish messages to a configurable topic when a given device changes state.

Does the device state monitoring need to be part of the MQTT plugin, or is a publish action that can be called from a standard Indigo "device state changed" trigger action sufficient?

3) Publish messages to a configurable topic when a given action is run.

Is adding the publish action to whatever schedule/trigger/group sufficient? I don't know that there's any way to monitor actions.

4) Publish messages to a configurable topic when a given variables change value.

Same as for #2.

5) Subscribe to a configurable topic and in response to incoming messages, run a custom script (I would create 3 of these instances, one custom script for each to handle devices, actions and variables)

A trigger configurable for specific topics and (possibly) content would allow executing any action, including a script.

I’d love to see this too. There are a couple of others available but they’re not very intuitive nor terribly reliable. The best I’ve cobbled together so far is a node red instance running in between indigo and the MQTT broker. I’m currently investigating all of the WiFi switches available now and the popular alternative firmware (Tasmota) uses MQTT. I’m also looking at an automated camper project that could use a solid MQTT indigo plugin!

Terry


Sent from my iPhone using Tapatalk

OK, that seems clear enough. Someone else asked for an internal broker (one provided by the plugin). Is that useful?

It certainly could be. I want a broker that is publicly available so my remote weather stations can talk to it as well. I suppose that is possible with an internal broker via NATing, etc.

Does the device state monitoring need to be part of the MQTT plugin, or is a publish action that can be called from a standard Indigo "device state changed" trigger action sufficient?

The later would be sufficient. Better still would be an option for All Devices, and All Variables. ie. When any Devices changes state, dispatch to this topic with a custom payload with details about the device (name, id, state, etc). Having to setup a trigger for every device to publish its state change would become tedious, but that would certainly be a great place to start!

Is adding the publish action to whatever schedule/trigger/group sufficient? I don't know that there's any way to monitor actions.

Yes, having a publish action that can be added to schedules/triggers/groups would certainly do the trick.

A trigger configurable for specific topics and (possibly) content would allow executing any action, including a script.

Ahh, thats right. Even better! Sounds almost easy

Matt

Last question for now - if I wanted to use MQTT, what devices use it? I'll need something for testing, and I'm not sure if I have anything that does MQTT now. Maybe I do and just don't know it.

If you have nothing handy you could use this app to simulate messages? https://apps.apple.com/au/app/mqttbox/id1165784816?mt=12

Yes, I am using MQTTBox for Mac as well, so far so good!

@FlyingDiver what you really need is the broker (if its not included in your proposed plugin) and two clients, with this Indigo plugin being one of the clients. MQTTBox would suffice for the other client in your testing.

For the broker, you could
1) Include Mosquitto in the plugin with an option to run local or enter info for a remote MQTT Broker server.
2) Run Mosquitto on localhost with a little setup effort just to get started.
3) Sign up for any number of free tier mqtt broker services in the cloud.

Thanks!
Matt

I've already installed Eclipse Mosquitto in a Docker container on my Synology server, so that should suffice for testing purposes.

I'll grab MQTTBox to play with.

Seems like most everything could be accomplished with Triggers.

Trigger Type: Topic Subscription
(Enter Topic path)
Condition: If message contains...
Action: All the usual stuff
(except that access to the incoming message for its payload would be needed in the action... worst case, would Execute Script have this data available?)

OR

Trigger Type: All the usual stuff
Condition: All the usual stuff
Action: Topic Publish
(Enter Topic path)
(Enter custom message payload with access to fields from the appropriate item that caused the trigger)

The later would be sufficient. Better still would be an option for All Devices, and All Variables. ie. When any Devices changes state, dispatch to this topic with a custom payload with details about the device (name, id, state, etc). Having to setup a trigger for every device to publish its state change would become tedious, but that would certainly be a great place to start!

I'm not sure that's practical. I've got hundreds of devices, some of which update every 2-3 seconds. That would be a huge amount of traffic. Maybe for a selected list of devices. I'll have to think about that.

If you have nothing handy you could use this app to simulate messages? https://apps.apple.com/au/app/mqttbox/id1165784816?mt=12

I looked at it. Electron apps in general aren't great, but that one is really bad.

MQTT Explorer is still Electron with some quirks, but it's better than MQTTBox (IMHO).

I'm not sure that's practical. I've got hundreds of devices, some of which update every 2-3 seconds. That would be a huge amount of traffic. Maybe for a selected list of devices. I'll have to think about that.

That is a pretty standard use case for MQTT - 100's of devices reporting status every few seconds. List of Devices would be perfect. Right now, there is very little need for me to report device changes outward (to MQTT) from within Indigo, but it would be nice. The whole point would be that the MQTT Broker is the centralized Command and Control for all things.

Imagine the possibilities... if two or more instances of Indigo used the same MQTT Broker...

A web application could show the aggregate of all devices/actions/variables in real time between multiple locations...
You could keep multiple instances of Indigo in complete sync!
...

Matt