How to use the "extended" payload information

[MrGibbage]

My first time seeing this "discussion" part of github too!

So far, my experience with insteon-mqtt (for that matter, anything with mqtt) has been limited to some node-red flows and some entries in my configuration.yaml that look like this:

light:
  - platform: mqtt
    schema: json
    brightness: true
    command_topic: 'insteon/57.a1.28/level'
    state_topic: 'insteon/57.a1.28/state'
    unique_id: 'diningroomchandelier'
    name: 'Dining Room Chandelier'

But when I look at the documentation for insteon-mqtt, I see that there seems to be a lot more that I can do. For example, many of the devices (such as dimmers and switches) have a "reason" variable, which I think can be used to figure out if the light came on because of an actual device tap, or a scene, or whatever. I'd like to do that. But when I look at the payload sent when I tap on a light switch, all I see is a state/brightness payload. I'd really like to be able to tell when a switch was physically used so I can use it for triggers.

Specifically, I want to be able to tell when one of the scene buttons has been tapped on a KPL. Is that possible right now?

[MrGibbage]

@krkeegan , do you have any suggestions?

[TD22057]

You can use the reason field in HA automations. So you could have something reads the same MQTT message an if the reason is some value, use that to trigger other commands inside HA.

[MrGibbage]

What I am trying to say is, I am not seeing the reason field populated when I watch the messages in MQTT explorer. For example, when I tap on a switch, shouldn't I see the "reason : device" along with the the rest of the state message?

[krkeegan]

2 things:

1. I still can't say that the reason attribute has been fully populated everywhere, I am working on that, but doing some significant yak shearing in the process.
2. What does the output payload template look like for that topic?

[MrGibbage]

I wasn't sure if your question was directed to me or not. I'm still learning about templates here. I don't think I am using a template for that switch at all. Here's what I have in my configuration.yaml:

  - platform: mqtt
    schema: json
    brightness: true
    command_topic: 'insteon/4c.f9.cb/set/1'
    state_topic: 'insteon/4c.f9.cb/set/1'
    unique_id: 'familyroomkpl'
    name: 'Family Room Fan Light'

Now, I have seen that I can change that schema to "template", and there are a lot of configuration changes I could make, hence my question. Are you suggesting that I could make a change here and the "reason" message would be available? If so, that would be great!

Please keep on shearing that yak! Unless I am mistaken, I don't think I can reliably detect a switch tap any other way.

[TD22057]

That's the HA template. You have to change the insteon-mqtt state_payload config.yaml entry to include the reason field. The default looks something like:
{ "state" : "{{on_str.upper()}}", "brightness" : {{level_255}} }
You'll have to add a reason:
{ "state" : "{{on_str.upper()}}", "brightness" : {{level_255}}, "reason" : {{reason}} }

[MrGibbage]

My KPL settings in my config.yaml did not have a "state_payload" entry, but it did have "btn_state_payload". I changed it as you suggested, and when I press the button now, it does indeed send the JSON as expected, including the reason. But I have my KPL configured for ceiling fan control and the four buttons are configured as radio buttons (I did this using the insteon app). So when a button is pressed, the light under that button turns on, and whichever other button light was on turns off. But when it turns off, it does not send a state change message at all. I was expecting the state: OFF message to come on for whatever button was illuminated previously.

I'm going to do some testing and see if I can set up the automations I want with the way things are currently working, so no hurry--don't try to fix anything (unless it is me that needs fixing... still a good chance I'm the one that's doing it wrong here).

[krkeegan]

I don't think you are doing anything wrong. #18 (an oldie but a goodie) hasn't been closed because I don't think that support has fully been added. I am pretty confident that we are not publishing a change in the button state caused by the radio button setup. That is something that we need to add still.

[krkeegan]

This should work now. Let me know if it isn't.