Help syncing between SHM and Alarm

#1

1) Give a description of the problem
I am trying to create a 2 way sync between SHM (smart home monitoring) and my alarm - they both have the same states being OFF, HOME and AWAY

2) What is the expected behaviour?
Setting one of the 3 states from either the physical alarm panel or SHM should keep the second device in sync

3) What is happening/not happening?
I was able to get SHM to set the physical alarm states correctly, but when I tried adding the other way (physical alarm sets SHM state) it all broke. Also when I changed state using the physical alarm I started getting continuous notifications for multiple alternating states… I suspect I am not capturing correctly just when the state of any of the devices change and these continue to execute continuously…

4) Post a Green Snapshot of the pistonimage

webcore
webcore.png1178Ă—990 169 KB

#2

Syncing two devices (with one as the master) is easy…
But your current goals can be a real pain to get right…

In other words, I would never do this:

IF Device1 changes
    Then change Device2
END IF

IF Device2 changes
    Then change Device1
END IF

This can easily create an infinite loop…
(each trigger creates an additional trigger… ad infinitum)

You may have to unplug your hub to regain your sanity…

Side Note:

From your code, it looks like they are different. (siren/strobe etc)

#3

is there a way to get around this infinite loop, I am having the same issue with a couple of things and so far have been unsuccessful in preventing it. I tried cancelling all pending tasks, I have yet to test that command though.

#4

Yes, re-think your strategy, LOL

Think about it for a minute… Lets say you have two kids, and you tell Billy to follow Susie, and you tell Susie to follow Billy… Imagine the chaos!

It is much better to have one master (leader) and the rest following.

#5

yes absolutely, if only there was a way to prevent a re-trigger from happening in special circumstances then this would prevent this from happening.

I guess you could create two switches, and set one or the other in the code, then use built in ST features to mirror the switches.

Might be worth a try :). but like you said, probably easier to re-think the strategy…

#6

I hear you… but any line with a lightning bolt will execute anytime that attribute changes at all (in any direction)

So, for example, the code:
IF Device changes to siren, Then do X
will run thru the entire piston if that device changes to siren, OR if it changes to strobe, OR if it changes to off, OR if it changes to banana etc

#7

There is a complex method that does work, but it can be a lot of code:

Piston #1 

IF SHM changes to Disarmed
    Then turn on SimSwitchDisarm
END IF

Piston #2 

IF Alarm changes to off
    Then turn on SimSwitchDisarm   (same device as Piston1)
END IF

Piston #3 

IF SimSwitchDisarm changes to on
Then 
    Set SHM to Disarm
    Set Alarm to off
END IF

Using the Simulated Switch as the middle man keeps it from looping… but you also have to add code for turning off the SimSwitch.

Please keep in mind this reduces your home security though… Criminals only need to “outsmart” one device to automatically disarm the other…

I guess all of this is just a fancy way of saying that there is no point in having two security devices if one cancels out the other… Better to just stick with one

#8

Thanks very much for the tips.
I like the simulated switch solution - can you help me understand why this needs to be divided into 3 pistons rather than holding all code in a single one?
Thanks!

#9

Whenever possible, I tend to use only one trigger (or less) in the same piston… It allows for more streamlined code… quicker execution… and allows the complexity to grow more in the future… (old time coders may use this concept like the GOTO command. IF X happens, GOTO pistonB)

On the other hand, when you combine multiple triggers in the same piston, then whenever ANY of the triggers fires, the ENTIRE piston runs top to bottom, and executes anything not blocked by conditions. This also means that unnecessary code is processed at each trigger.

In this case, if you combine them, then one trigger will change something that will fire another trigger, which starts the piston all over from the top again, and changes something that will execute ANOTHER trigger… which will start the code all over from the top…bleh…

But again, I think it is worth repeating: