EDIT: after the below exchange, I found that I did not quite have it all figured out.
But now I do… and have changed the thread title accordingly. Getting virtual contact sensors/locks to report correctly without changing overall functionality, while being immune to accidental change, is a more detailed endeavor than I imagined. Not complex, but you have to test and account for every permutation.
Examples to follow in below posts 5 and 6.
I have a few simulated contacts in my system now. One instance is called ‘allwindows’. If the actual physical contact sensors on all my windows are closed, then allwindows shows as closed. If any one physical sensor is not closed, then allwindows shows as open.
The problem is that by accidentally tapping the ‘allwindows’ icon in the mobile app, I override that information. I no longer have any way to really know if those windows are closed.
So I’m imagining a variable reference process. Instead of the current piston setting the simulated ‘allwindows’ contact, it simply sets a variable: perhaps status=closed.
A second piston handles the actual simulated contact sensor.
Upon any change in the status variable, the piston sets the simulated sensor accordingly.
AND… any time the allwindows sensor is changed, the piston goes and compares it to the variable. If they are in sync, no action. If they are out of sync, the piston sets allwindows to the state contained in the variable.
I’d hope that could work without endless looping.