Sonoff dimmer control with MQTT Shims

[wasimpson]

Well i experimented and failed
I have no idea how to match the trigger to get the device details to update

I can literally build and launch satellites but this is not intuitive at all

[FlyingDiver]

If you don't understand MQTT at all, then you could have an issue. You need to know what MQTT topics and payloads the devices uses for both control (received by the device) and status reports (sent by the device). I think you said that you have controlling the device from Indigo working, which means you have the first set working. It's the second set that's the issue, right?

First thing to keep in mind that is these two sets of topics (and payloads) are totally separate. The may look similar, but the plugin doesn't use one for the other. The second thing is that the trigger is ONLY used for (and is based on) the topic for the status updates.

A couple posts back you posted the content of the status update payload, but you didn't post the actual topic it was received under. Is it actually 'tele/Study_Lamp/STATE' or was that a generic name? I ask because it's very unusual for an IOT device to use an all-caps term like that.

BTW, I am an actual rocket scientist. BS in Aeronautical Engineering, anyway.

[wasimpson]

I am a satellite and launcher manager for the European Space Agency, in November launched a satellite on a Falcon-9
I used to program in basic, ETOL & C++ which is why i am annoyed with myself at this.
Passing things as variables or stream and sockets is easy

The passing of data for the commands makes sense
I get the idea that the trigger is for the telemetry but i just need an example to make sense of it.

The tele/Study_Lamp/STATE will then give you the RESULT which is an array of all the parameters

What i am missing is the link how in the case of the Device Details the values of POWER and Dimmer are passed to the broker and then extracted by the trigger to be used as values in indigo

And thanks for your patience

[FlyingDiver]

First, use the right terms so that we're all on the same page. The telemetry messages from the device consist of a TOPIC and a PAYLOAD. As you say, the TOPIC is "tele/Study_Lamp/STATE" where "Study_Lamp" is actually the name of the device and used in the Shim plugin as the "UniqueID". So the MQTT broker needs to be subscribed to "tele/#" which is "tele" followed by anything. '#' is the MQTT wildcard.

Next, you need a trigger that will recognize this topic and queue the message up for the Shims plugin. There's a couple ways to do this, depending on how many devices you have, and if they're different types or not. But the simplest way is for the trigger to look for that exact topic:

Match: "tele"
Match: "Study_Lamp"
Match: "STATE"
End:

Then provide a message type which (in this case) will be unique to this one device: "##Study_Lamp##". Not that the hash marks are purely my convention and don't really mean anything. It's just a unique string for this specific device type.

And don't call the payload a RESULT, or imply it's an array of data. It's neither. In this case, it's a JSON string representing a Dict (nested Dicts, actually). So key/value pairs, not an array.

Based on this, and the payload you gave earlier, your shim would look like this:

Screen Shot 2021-01-19 at 3.57.03 PM.png (175.76 KiB) Viewed 2978 times

I did not show the bottom part of that dialog, because most of it is for the sending commands part, which you already have working. There's a section below that which is actually related to the status (input) messages, and should be relocated towards the top. It's down there because I added that functionality later and didn't think to group it properly. One of these days I'll clean all that up.

I honestly thought that the writeup in the wiki had sufficient detail on how this all works. It would really help me and other users if you can tell me where the gaps are in that article that caused you to get lost.

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

[FlyingDiver]

What i am missing is the link how in the case of the Device Details the values of POWER and Dimmer are passed to the broker and then extracted by the trigger to be used as values in indigo

Let me drill down on this a little more. The device sends a status message (which they call a telemetry message) with a whole bunch of data, of which POWER and Dimmer are just a couple. So it's sent to the MQTT broker as the payload of a message with the tele topic. I'd hesitate to use the term "passed" because that usually used in the context of a subroutine or function call. Which this isn't. It's more of a network broadcast message, because any client of that broker (in this case, the MQTT Broker plugin) can receive that message.

Next, the trigger doesn't do any extraction. It's just a filtering mechanism to identify specific MQTT message topics and queue (hold) them for any MQTT Shim device that wants messages with that specific topic. It uses the message type to advertise that specific message. It doesn't know or care about the content of the payload.

Lastly, there's a Shim device which is looking for any messages with a specific message type. It gets them from the Broker plugin, then looks at the payload and decides what to do with it.

There's a little extra complexity here, mostly for the cases where you have multiples of the same device type, all with unique names, which you want to handle identically. So you only need one trigger to feed multiple Indigo Shim devices. Yeah, I could have written it so that there had to be a trigger for EACH device, but that seemed wasteful. My example above is written to do it that way, and it's an OK start. But if you have many devices, consolidating triggers is probably the way to go.

I don't have enough MQTT devices to do a stress test doing it different ways. I have a few Shelly devices, most of which I actually use Aaron's plugin to handle. And I have a remote rPi system with some Z-wave devices connected to it, and I use node-red on that system to resend the Z-wave device reports via MQTT to Indigo, where I have Shim devices set up.

[wasimpson]

Well your explanation was clear and makes sense but nothing i enter changes the device details
I tried exactly what you sent

So i tried just one topic
From MQTT Explorer I see if i just switch the power i see

stat/Study_Lamp/POWER
And the state changer from OFF to ON etc

So i set Trigger to match
stat
Study_Lamp
Power

Still no joy
This is exasperating

[FlyingDiver]

From MQTT Explorer I see if i just switch the power i see

stat/Study_Lamp/POWER
And the state changer from OFF to ON etc

State of what? You mean the payload of the message, right?

So i set Trigger to match
stat
Study_Lamp
Power

Does the trigger not execute? What do you see in the Indigo log?

[wasimpson]

from the indigo device panel if i turn on or off the device i see the values in MQTT explorer change
Nothing is shown in the LOG

If i then press Send Status Request the log shows

21 Jan 2021 at 13:12:37
MQTT Shims Sent 'Study Lamp' Status Request

but nothing else

[FlyingDiver]

Are you sure the MQTT Connector device is subscribed to the "tele/#" topic?

[wasimpson]

Finally cracked it!!
You gave me the clue

actually needed stat/#

Thanks again for your patience
If you are lucky you will not hear from me for a while