So the holy grail (of the week) is a flexible way to present IoT devices using MQTT messages as Indigo devices. So that's what this plugin does. I don't promise that it will work with ALL MQTT payloads, but I think you can make it work with most and I'm looking for specific payloads that won't so I can do more with them.
This works hand-in-hand with the MQTT plugin. But the protocol used is deliberately designed so that it doesn't preclude the use of other plugins or scripts. Documentation is non-existent at the moment, so I'm going to do a walk-through on configuring a couple devices. This is a long post. Sorry, but don't try to skip around. Read it all the way through carefully.
Note: The most up-to-date version of these instructions is in the Wiki.
First, you need some IoT devices publishing messages, and an MQTT Broker. And the MQTT plugin. Get all of that working first. For this example, I'm going to use messages that publish a topic and payload like this example provided in another thread. In this payload, the device-specific name is the "wemos1" part of the topic.
- Code: Select all
devices/wemos1/tele/SENSOR =
{
"Time":"2019-08-04T09:16:14",
"BME280":{
"Temperature":84.3,
"Humidity":31.3,
"Pressure":995.74
},
"TempUnit":"F"
}
We have one device with three useful data items in the payload. We'll create THREE indigo devices, each representing one payload value. As a bonus, all three devices will have all three values as states.
First, make sure that the MQTT plugin Broker devices is subscribed to the topic:
- Screen Shot 2019-08-10 at 3.00.55 PM.png (50.48 KiB) Viewed 4436 times
You could do a more specific subscription, but then you would need one for each device.
Next, we need a trigger for this topic to tell the MQTT plugin to do something with it when it's received. I considered automatically creating a trigger for each subscribed topic, but it's not possible with the current API.
- Screen Shot 2019-08-10 at 3.06.17 PM.png (144.21 KiB) Viewed 4436 times
This is a "Topic Component Match" trigger. You need to pick the Broker device, then build a list of topic component match items. Each item in the list (going down) matches a component of the topic string (delimited by the slashes, left to right). So this matches the topic string for "wemos1", with a wild-card in the second spot. Which means it'll match "wemos1" or anything with an otherwise identical topic string. Again, it could have been designed to exactly match this one payload, but it's not required. To change the topic list, just delete components and add them back in. Unfortunately, I couldn't figure out a way to allow re-ordering of the list items.
At the bottom of this panel is a shortcut that performs an operation which would normally be done within the action list associated with this Trigger. It's here because 99% of the time you're going to want it, and because by doing this during trigger processing we're avoiding a race condition which could potentially change the data in the Broker device before the action would get performed. The last item here is the "Message Type". This is another field where I'm not sure what the best name is. It's a string that is a unique identifier for the kind of payload message this is. It's used to filter the messages obtained by the recipient device/script. Payloads with similar structures can use the same identifier. The Shims plugin is flexible enough that it doesn't require a unique identifier for every device. Just similar devices.
That's it for setup in MQTT. Next is to configure the Shims plugin. First release is available here: https://github.com/FlyingDiver/Indigo-S ... /tag/0.0.0
The devices we want to create to represent the wemos1 IoT devices are all Sensor devices with values (not just on/off). So create a Shims->Value Sensor Device.
- Screen Shot 2019-08-10 at 3.32.51 PM.png (162.35 KiB) Viewed 4436 times
Select the MQTT Broker device that's used for this IoT device. Enter the same Message Type you put in the Trigger. Now you need to tell the plugin where the unique identifier for this devices is, and where the state value is.
The unique identifier (name) of the device is in the second component of the payload, so make sure "Topic Component" is selected, and put a 1 in the field. I was being lazy when I coded this, so I didn't convert from 0-based array counting.
Then put in the value that's going to be in that location that's unique for THIS device. Alternatively, the unique identifier could have been in the payload, so there's another option on the "Unique ID Location" popup. It works like we'll be doing in the next section. We're done with the Unique Identifier section.Now we tell the plugin where the state value is. It could be in the topic (unlikely) or in the payload. Select "Payload Fields" for the "State Value Location" popup. Select type JSON. Now we get to a tricky field. Go back and look at the JSON payload for this topic. The data we want is in a nested dictionary. In Python, this would be "payload['BM280"]["Temperature"]. Since there are two dictionary keys involved, the "key" to reach this data is "BM280.Temperature". Yes, this will break if there are keys in the JSON data with periods in them. I did some research, and can't find any characters that aren't allowed, so I picked something that is unlikely. My second choice was ":". If this turns out to be a problem, I'll change this to allow specifying the delimiter you're using on a case by case basis.
Then pick the type of sensor. I've included all the ones that I did for the Masquerade plugin. If you need something else, just file an issue on the GitHub page. Please specify units and hopefully an existing state image to be used.
Lastly, we have a key to reach a dictionary of data to be presented as additional states for the device. In this case, specifying "BME280" tells the plugin to take all the entries in this dict in the payload and make them states in the devices.
And that's it. Save the device, enable the IoT device and both plugins, and let it rip....
