Hmm. As much as I enjoy a challenge, this is not working out as easily as I had hoped. Thank you anyway.
Why is this “false”?
OK, quick question first…
Do you want secondary conditions
before the alert? (such as location mode)
Or do you simply want to be alerted when the contacts open?
You are still typing, but here is a starter piston:
A few notes:
Please pause any other pistons triggering off of those contact sensors to get a proper test.
I added two optional “Logs” that should help with troubleshooting.
This structure can be “complexified”, but should be tested at this early stage first.
I’m not sure of the terminology but there would be two conditions: (1) alarm system set to Stay OR away (I think this might be done through location?) AND contact sensors A, OR B, OR C, OR D are open.
Alarms are not really integrated in the new platform…
So the alarm system workaround is not mentioned above.
I used the “Location mode” to determine if the message should be sent or not.
It would require another, (entirely independent) piston to properly set your location mode.
Oh, I should have added: when both conditions have been met, something happens: a sound, or voice message, or something, on Sonos, my Amazon Fire, and/or an email to me. That’s it.
If I may be a bit blunt, I think these are the steps I would take (in order)
(1) Program a new piston to change location mode based on X, Y and Z.
(2) Test this for a few days to make sure it changes properly at the correct times
(3) Import and test my sample piston above
(4) Once you are happy with the sample piston, you can focus on the alert method, and make the piston more complex.
Note: Sound, voice, Sonos and Fire Tablets are all possible, but if this is your first time experimenting with these, I would create ANOTHER test piston, with only a single line command. This lets you press Test to quickly see if it is working on your end.
Once you have a working alert method, then simply insert that single command in my sample piston, and you are good to go!
Oh, and one more thing…
Samsung is going thru some pretty major changes at the moment…
Getting alerts about security events is smart, but I am not sure if I would rely on Samsung for total security over the next X weeks…
On third thought, this is over my head. As handicapped as ST is, I was able to set intrusion alarms up in about five minutes (had to do several because ST can’t handle “OR”). The attraction of WC was learning something new (I hoped) and setting my alarms up in one piston. I appreciate your patience but I am afraid I will stick with ST and hope it evolves into something better. Thanks again!
Sorry if my descriptions were overwhelming…
(I did not mean to chase you off)
For what it’s worth, new users often want a single piston that does everything… This means a lot of wasted processing power, a sluggish system, semaphore delays, and a lot of triggers
stepping on each other’s toes…
Personally, I tend to program very differently. I typically only have a single trigger
in each piston. (with one piston basically “setting the stage” for another piston) Many smaller pistons means that each event is processed quicker, with less hassles. (but it does require foresight)