Match actual device states to "group" device states. (Switch on/off)


#1

1) Give a description of the problem

So, there are two parts of me: The one that likes to label physical devices accurately, and the part of me that likes a simple descriptions for use with Alexa and the “Rooms” feature of the Hubitat app. (which also increases the Spousal Approval Factor). While this system generally works, I’m beginning to understand that for Hubitat groups, I can only choose one of the two options:

Indicate if a "Use Group Device to Indicate that members are ON"
Indicate if a "Use Group Device to Indicate that members are OFF"

While I understand the reason why these scenarios are an either/or with multiple devices in a group, I wish there was a way to choose BOTH scenarios for a “group” consisting of a single device.

2) What is the expected behaviour?

I’d like to create a piston that turns off the Group device when the corresponding actual device is turned off, so the Hubitat app shows the appropriate state of the device. I’m thinking that I could create two arrays: (A) one with the actual devices, and (B) one with the “group” devices. If Device A changes to OFF, then the piston will turn off the appropriate group device in array B. I’ve just never created a piston that can choose the correct group device in one array based on the selected physical device in another array.

Any guidance or ideas would be appreciated.


#2

So, I’m taking a different route…I’m getting rid of Groups, and created this piston to reset all pertaining devices, virtual and actual, when a switch is thrown. It kinda works (I’m getting some weird behavior like other light switches being turned on…not quite sure why, so I threw in some piston/console logs to see what’s going on).

The biggest issue is, I’m trying to get it to run once in each instance, but it’s not working. I tried creating the BYPASS variable so that only the first device switch/level change would do the work, but ignore the subsequent changes. Then I tried it in the piston, then I moved the BYPASS=False to the end. I still get multiple runs. Not sure what I’m doing wrong here.

12/26/2021, 7:00:13 AM +775ms
+46ms ║Kitchen Light Switch is off
+46ms ║Kitchen Light is off
+46ms ║Kitchen is off at 7:00 A.M. on Sun, 12/26/2022
+50ms ║False
+57ms ║False
12/26/2021, 7:00:13 AM +468ms
+253ms ║Kitchen Light Switch is off
+253ms ║Kitchen Light is off
+253ms ║Kitchen is off at 7:00 A.M. on Sun, 12/26/2022
+257ms ║True
+264ms ║False
12/26/2021, 7:00:13 AM +170ms
+240ms ║Kitchen Light Switch is off
+240ms ║Kitchen Light is on
+240ms ║Kitchen is off at 7:00 A.M. on Sun, 12/26/2022
+245ms ║True
+252ms ║False
12/26/2021, 6:52:36 AM +887ms
+53ms ║Kitchen Light Switch is on
+53ms ║Kitchen Light is on
+53ms ║Kitchen is on at 6:52 A.M. on Sun, 12/26/2022
+57ms ║False
+65ms ║False
12/26/2021, 6:52:36 AM +644ms
+189ms ║Kitchen Light Switch is on
+189ms ║Kitchen Light is on
+189ms ║Kitchen is on at 6:52 A.M. on Sun, 12/26/2022
+193ms ║True
+200ms ║False
12/26/2021, 6:52:36 AM +294ms
+184ms ║Kitchen Light Switch is on
+184ms ║Kitchen Light is off
+184ms ║Kitchen is on at 6:52 A.M. on Sun, 12/26/2022
+189ms ║True
+196ms ║False
12/26/2021, 6:09:57 AM +837ms
+87ms ║Back Patio Light Switch is off
+87ms ║Back Patio is off at 6:09 A.M. on Sun, 12/26/2022
+92ms ║True
+98ms ║False
12/26/2021, 6:09:57 AM +273ms
+490ms ║Back Patio Light Switch is off
+490ms ║Back Patio is off at 6:09 A.M. on Sun, 12/26/2022
+495ms ║True
+508ms ║False
12/26/2021, 6:06:34 AM +563ms
+334ms ║Back Patio Light Switch is on
+334ms ║Back Patio is on at 6:06 A.M. on Sun, 12/26/2022
+342ms ║True
+351ms ║False
12/26/2021, 6:06:34 AM +5ms
+395ms ║Back Patio Light Switch is on
+395ms ║Back Patio is off at 6:06 A.M. on Sun, 12/26/2022
+411ms ║True
+458ms ║False

[EDIT] Kinda weird…I put in a WAIT, and at some point, BYPASS turns into a NULL.

12/26/2021, 10:24:02 AM +118ms
+482ms ║Fan Computer Light Switch is on
+482ms ║Computer Light is on
+482ms ║Computer is on at 10:20 A.M. on Sun, 12/26/2022
+508ms ║null
+515ms ║False


#3

Well, it would appear that throwing a 1-sec WAIT in each device section of the piston is sufficient. I guess the variable wasn’t changing fast enough. Weird.