Having one device track the state of another - in 1 trigger

Posted on
Fri Jun 14, 2019 8:04 am
berkinet offline
User avatar
Posts: 3404
Joined: Nov 18, 2008
Location: Berkeley, CA, USA & Mougins, France

Having one device track the state of another - in 1 trigger

I have two devices (both Z-Wave controlled lights, but that shouldn't really make a difference for this case) and I would like light 2 two track the state of light 1. That is, whenever light 1 turns on, light 2 should turn on and when light 1 turns off, light 2 should turn off. Light 1 does not need to track the state of light 2 (I.e. they do not always need to be in synch).

I can do this with two triggers, one for light 1's on-state and the other for the off-state. And, I can do it in 1 trigger (on any state change) with a few lines of scripting.

My question is: Is it possible to do this in one trigger without scripting?

Posted on
Fri Jun 14, 2019 10:49 am
jay (support) offline
Site Admin
User avatar
Posts: 16265
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Having one device track the state of another - in 1 trig

If they are both dimmers, you can use the Match Brightness action I think. Probably should have a similar "Match On State" or something for non-dimmables (that's on the list already).

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Fri Jun 14, 2019 10:51 am
berkinet offline
User avatar
Posts: 3404
Joined: Nov 18, 2008
Location: Berkeley, CA, USA & Mougins, France

Re: Having one device track the state of another - in 1 trig

jay (support) wrote:
If they are both dimmers...
...Probably should have a similar "Match On State" or something for non-dimmables (that's on the list already).

They are on/off. Thanks for the response.

Posted on
Tue Jun 25, 2019 4:15 pm
mundmc offline
User avatar
Posts: 712
Joined: Sep 14, 2012

Re: Having one device track the state of another - in 1 trig

^ Just cut my triggers down by 5! Great question/ answer.

Posted on
Wed Jun 26, 2019 6:59 am
jalves offline
Posts: 588
Joined: Jun 16, 2013

Re: Having one device track the state of another - in 1 trig

jay (support) wrote:
If they are both dimmers, you can use the Match Brightness action I think. Probably should have a similar "Match On State" or something for non-dimmables (that's on the list already).

I wonder if the Match Brightness action would work for virtual 3-way switches to keep them in sync. Hmmmm....

Running Indigo 7.4.1 on a 27" iMac (mid-2017), 40G memory, 1T Fusion Drive, OS X 10.15.4
Jeff

Posted on
Mon Sep 30, 2019 4:07 pm
jay (support) offline
Site Admin
User avatar
Posts: 16265
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Having one device track the state of another - in 1 trig

berkinet wrote:
jay (support) wrote:
If they are both dimmers...
...Probably should have a similar "Match On State" or something for non-dimmables (that's on the list already).

They are on/off. Thanks for the response.


Indigo 7.4 now has Match On State to Device and Match On State to Variable actions as well as a new Match Brightness to Variable action.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Sat Apr 18, 2020 11:01 pm
dduff617 offline
Posts: 517
Joined: Jul 05, 2006

Re: Having one device track the state of another - in 1 trig

I was happy to learn the "Match..." actions were added. In many cases for me, this will cut in half the number of required triggers. However, on a few attempts to make use of this, I ran into issues.

First issue: I want to make an Indigo trigger so that when a particular KeypadLinc button "has any change", and then I want another device to match on state of this same KeypadLinc button. Indigo's interface for triggers let's me select both the KeypadLinc device and the specific button in the "trigger" part, but the interface for setting the source and destination states to sync in a "Match On State" action in the "action" part is more limited and does not afford the same flexibility. Specifically, I can select the KeypadLinc device but not the specific sub-state, i.e., the button. As far as I can tell, there should be no problems copying on/off state of a keypad button to another device. For that matter, it would be great if a keypad button could be selectable as a destination of a Match On State command as well (though it might complicate the existing multi-select type interface).

Second issue: I wanted to make an Indigo trigger that when a Z-wave switch on/off state "has any change", it turns on/off another device. Indigo lets me select the z-wave device in the trigger part of the UI, but (for reasons I don't understand), the same Z-wave switch does not appear in the set of devices I can select as the source for the "Match On State to Device" action. Seems like any device that has a state tracked by Indigo should be fair game here, no? The specific device I'm trying to use as the source for copying state is "Double Plug (ZEN25)" model z-wave device (Zooz brand).

What determines which devices appear and which don't? As an on/off device, I would certainly expect my Zooz z-wave module to appear. It doesn't, but I do see plenty of other z-wave devices and plenty of other "grouped" devices (such as multi sensors, dual OutletLinc's).

Posted on
Mon Apr 20, 2020 10:21 am
jay (support) offline
Site Admin
User avatar
Posts: 16265
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Having one device track the state of another - in 1 trig

dduff617 wrote:
First issue: I want to make an Indigo trigger so that when a particular KeypadLinc button "has any change", and then I want another device to match on state of this same KeypadLinc button. Indigo's interface for triggers let's me select both the KeypadLinc device and the specific button in the "trigger" part, but the interface for setting the source and destination states to sync in a "Match On State" action in the "action" part is more limited and does not afford the same flexibility. Specifically, I can select the KeypadLinc device but not the specific sub-state, i.e., the button. As far as I can tell, there should be no problems copying on/off state of a keypad button to another device. For that matter, it would be great if a keypad button could be selectable as a destination of a Match On State command as well (though it might complicate the existing multi-select type interface).


This is actually complicated because of how they implemented KeypadLinc buttons (i.e. badly). Those buttons aren't actual devices, but rather just kept as internal states on the KPL itself. If the button is linked in such a way as the PowerLinc gets notified when there's a change, then Indigo can then query the KPL to get the state of the buttons (all of them, not just one, because the state is stored as a bit mask). However, if you just directly linked a button to another Insteon device, the PowerLinc (and therefore Indigo) won't know that the state has changed.

We could attempt to make each button it's own device in Indigo, but that would require a lot of extra Insteon commands (exacerbating Insteon's inherent collision problem) and would still be error prone. So, bottom line, I don't think we'll be doing much more with them.

dduff617 wrote:
Second issue: I wanted to make an Indigo trigger that when a Z-wave switch on/off state "has any change", it turns on/off another device. Indigo lets me select the z-wave device in the trigger part of the UI, but (for reasons I don't understand), the same Z-wave switch does not appear in the set of devices I can select as the source for the "Match On State to Device" action. Seems like any device that has a state tracked by Indigo should be fair game here, no? The specific device I'm trying to use as the source for copying state is "Double Plug (ZEN25)" model z-wave device (Zooz brand).

What determines which devices appear and which don't? As an on/off device, I would certainly expect my Zooz z-wave module to appear. It doesn't, but I do see plenty of other z-wave devices and plenty of other "grouped" devices (such as multi sensors, dual OutletLinc's).


We filter the match on state based on the device type - so only devices which support an on state are shown (we wouldn't know how to interpret any other states). What is the exact type of the source device that's showing up in the trigger but not showing up in the source for the action?

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Mon Apr 20, 2020 11:13 am
dduff617 offline
Posts: 517
Joined: Jul 05, 2006

Re: Having one device track the state of another - in 1 trig

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.

Posted on
Mon Apr 20, 2020 5:53 pm
jay (support) offline
Site Admin
User avatar
Posts: 16265
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Having one device track the state of another - in 1 trig

Matt's looking into the Z-Wave device issue, and we'll take another look at adding the KPL buttons into the current Match On State to see if it can be done without too much distraction. As you say, Insteon is likely in its sunset period and given the metric ton of Z-Wave stuff along with all the non-technology specific stuff (Alexa, Google Home, etc) that gives us much higher bang for the buck, we just can't afford to spend too much time on additional Insteon-only features. We'll continue to implement workarounds for their API strangeness when adding new devices, but doing deeper integrations are not going to be a very high priority because of the reducing ROI.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Mon Apr 20, 2020 7:15 pm
matt (support) offline
Site Admin
User avatar
Posts: 20027
Joined: Jan 27, 2003
Location: Texas

Re: Having one device track the state of another - in 1 trig

dduff617 wrote:
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.

Definitely looks like a bug here – not all the devices are showing in that popup that should be. We'll definitely get that fixed.

Image

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 1 guest