Thanks, for sharing your thoughts, Jay.
Following up on the second issue first. I have a couple of the Zooz Zen25 double plug z-wave models. As a multi-headed device, aka "device group" type device, this device ends up creating a primary device and three secondary devices. Two of the secondary devices are on/off switches which control the separate outputs on the module. Support was added for this module in a recent release.
So I create a device-state-changed type trigger. For the "trigger" part, I use one of the secondary on/off devices from a Zooz module and select "has any change". Then in the action part of the trigger, I create an action of type "Match On State to Device". for the Device part (pull-down menu), I attempt to select the same device I used in the trigger, but it doesn't show up in this menu. Based on another comment I saw elsewhere I also look for primary device, but I find that it does not appear either. So offhand, it appears there may be something wrong with the filtering logic here.
The specific device details:
- Code: Select all
Z-Wave Indigo Device "NBR Combined Air Cleaner and Humidifier" Z-Wave Properties:
Indigo Z-Wave Version: 7.4.1
Node ID: 65
Model: Double Plug (ZEN25)
Model ID: A000A003
Manufacturer: Zooz
Manufacturer ID: 027A
Protocol Version: 5.03
Application Version: 2.00
Model Definition Version: 1
Library Type: 3
Class Name: Relay Power Switch
Class Hierarchy: 04 : 10 : 01
Command Class Base: 25
Command Versions: 20v1 60v4 25v1 86v1 27v1 6Cv1 72v1 8Ev1 70v1 71v1 32v4 73v1 55v1 59v1 5Av1 85v1 7Av1 5Ev1 9Fv1
Encryption Status: Not Supported
Multi-Endpoint Types: 1:(10 : 01), 2:(10 : 01), 3:(10 : 01)
Multi-Endpoint Classes: 1:[5E 85 59 8E 25 32 6C 9F], 2:[5E 85 59 8E 25 32 6C 9F], 3:[5E 85 59 8E 25 32 6C 9F]
Multi-Instance Counts: - none -
Features: routing, beaming, energyMeter
Neighbors: 27, 38
Associations: 1:[1] 2:[] 3:[]
Config Values: 1:0 2:0 3:3600 4:3600 16:1 17:2
Now, circling back to the first point. I understand there's complexity and some messy special-case stuff to support KeypadLincs and perhaps also a general trend in the direction away from the primacy of Insteon generally... However, it seems to me that Indigo already has what it needs to make this work better. Specifically, Indigo is already handling the state-change trigger part of the problem for KeyapdLinc's perfectly -- that seems like the "hard part". All that is needed is a way to make it more convenient for users to tap into the info Indigo already has. To state it succinctly, I can (already in today's Indigo) write two separate triggers that will do what I want. That is, to turn another device on/off based on detected change of state of a keypad button. It seems like the spirit of the new "Match..." actions is to ease the burden of having to have two actions where one can accomplish the same thing.
So maybe instead of trying to complicate the UI to generalize the new Match... commands so that they can work with Keypadlinc, how about an alternative of creating another separate action type called "Match On State to KPL Button"? That by itself would be useful. It would be a bonus if "Match KPL Button to On State" and/or "Match KPL Button States" are also included - I realize that's where some of the messy bits of the KPL interface start to kick in...
My assumption was that "Match On State to KPL Button" would be done
without Indigo having to do an extra over-the-wire command to actively test the state of the button, but would instead just read the state as contained in Indigo's "model" of device states. I guess now I'm getting to the meat of what you were driving at - i.e., that perhaps Indigo for some reason
does not save the on/off state of individual buttons the same way it saves the on/off state of devices - is that the issue here? Seems like that can't be the issue, though, as how Indigo could possibly implement the "Device State Changed" and allow me to specify a keypad device and a particular button to monitor for change... I.e., how could "change" be detected if Indigo were not saving/modeling the current state of the button?
Sorry if I'm belaboring this a bit, but I make use of keypads a fair bit in my house. looks like I
first submitted request for related feature back in 2015.