Hmm. As much as I enjoy a challenge, this is not working out as easily as I had hoped. Thank you anyway.
Would you like me to whip you up a piston real quick?
Very kind of you. Thank you. I would be glad to give it a try.
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.
I tried to use STHM (away) switch as being on.
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!
This should work, as long as the logic for that switch is kept outside of this piston.
Happy to give it a shot (and learn something new). Thank you.
Sure thing! Lots of great people here willing to help!!
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)