Did you know that you can enjoy many members-only features simply by quickly registering (no CAPTCHA!)?
Registering gives you access to our giveaways, forum features, increased search performance, access to our Download Library, create your own blog & gallery, and more!
Once you have registered, stop by in 'Hello World', and introduce yourself.
Posted 08 February 2012 - 02:10 PM
Ideally, I would like to have the ability for Premise to send out an email (dynamic for each zone if possible) whenever a zone on my M1 trips while the alarm is in an armed state. And another one to send at all times for my 24/7 sensors, such as water.
Posted 08 February 2012 - 09:21 PM
The attached file shows how to send an email whenever a SecurityZone is triggered and SecuritySystem is Armed.
- Right-click a SecurityZone and select New > Script > PropertyChange
- Select the SecurityZone's Triggered property.
- In the Content window, enter what you want to happen when the Triggered property is activated.
Here's what the example uses:
if sysevent.newVal = true then if Home.SecuritySystem.SecurityState = 0 then dim oMail set oMail = GetMailer() with oMail .From = "[email protected]" .To = "[email protected]" .Subject = this.path & " has triggered." .Body = this.path & " triggered at " & now .Server = "pop3.somewhere.com" .Send end with set oMail = nothing end if end if
Here's what it is doing:
- Confirming Triggered's state is true.
- Confirming the SecuritySystem's state is Armed.
- Sends email.
- Armed = 0
- Disarmed = 1
- StayArmed = 2
- Alarming = 3
- Disconnected = 4
The script uses the statement "this.Path". Here is what that means:
- "this" is the 'current object'. Another way of saying it is "me".
- "this.path" means the current object's full path name. The path of the example's SecurityZone is sys://Home/SecurityZone.
Edited by 123, 08 February 2012 - 09:28 PM.
Posted 09 February 2012 - 09:10 AM
Also, if I'm linking this script to each security zone, would I just use the 'this' statement since that is directly the zone I want to email status for?
Posted 09 February 2012 - 09:44 AM
Answer to question 1:
Use the expression this.path literally. It is is not a placeholder for you, video321, to put in something else. It is a placeholder for Premise to put the path of whatever object it is currently handling.
Answer to question 2:
I wrote the code so that it is 'portable' and can be used within the PropertyChange script of any SecurityZone object (or similar object). Here's what would've made it non-portable:
If I had used:
.Subject = "Home SecurityZone has triggered."
.Subject = this.Path & " has triggered."
it would only make sense for one object, namely the Home SecurityZone object.
The expression "this.path" means the current object's full path name: sys://Home/SecurityZone.
"this.name" would produce the current object's name: SecurityZone.
If I had used
if this.Triggered = true
if sysevent.newVal = true
it would work exclusively with objects having a Triggered property (i.e. SecurityZone objects). For example, a MotionDetector object has a MotionDetected property (i.e. no Triggered property).
"Sysevent.newVal" means "this is the new value of the property I am monitoring". "sysevent.oldVal" means "and here's the previous value of the property I am monitoring".
Edited by 123, 09 February 2012 - 09:45 AM.
Posted 09 February 2012 - 11:14 AM
Since you mentioned 'this.name' I'm sure I'd be better off using that since it will simply use the name of my security zone (Front_Door) instead of the full path within' Premise (sys://Home/SecuritySystem/Front_Door), right? Could I get it to use the 'Display Name' property (Front Door - with no underscore)?
Thanks, again, 123!
Posted 09 February 2012 - 03:11 PM
If I were to create a SecurityZone object in Home > Foyer, call it 'FrontDoor' and then give it a DisplayName of 'Our Front Door' here are what it's major properties would be:
DisplayName: Our Front Door
"Class" is what the object is derived from. In other words, 'class' is like a recipe for chocolate cake. It's not a real chocolate cake until you follow the recipe and bake one. After baking it, you have a chocolate cake "object".
"Name" is the object's name and has to comply with Visual Basic's naming rules (no spaces, no special characters, cannot start with a number, etc).
"DisplayName" is the object's name for display in Premise Browser and anywhere else where you want a less-stunted name. TIP: If you use this.DisplayName in a script and forget to enter something in DisplayName, don't worry because Premise will default to using this.Name (very convenient).
"Path" is where the object is located in "Premise Space". Everything in Premise Space is organized in a hierarchy where "SYS" is the first object.
Premise takes 'object oriented programming' to heart. Every object in Premise inherits from "PremiseObject". That means PremiseObject's properties and methods are available in all other objects. It's kind of like if your grand-dad had red hair, was a great skater, knew how to speak Farsi, and balance pick-axes on his head, so would you and your offspring.
The attached image is from Premise's online Help and shows the Properties and Methods of PremiseObject. You'll note it has Name, DisplayName, Path, and several other properties. The fun one is "Parent". Yes, you can navigate your way up the family tree and display the name, and other properties, of each relative.
In the previous post above, this.Parent.Name would produce "Home", this.Parent.Parent.Name produces "SYS" and that's the biblical equivalent of Adam. If you persist and ask for this.Parent.Parent.Parent.Name, the script debugger pops up and throws a lightning bolt.
Every object also inherits PremiseObject's Methods. Whereas Name is the equivalent of your grand-dad's red hair (a trait), "GetChildren" and "SetValue" are like his ability to bend spoons with his mind and juggle bowling balls (whatta guy!).
Edited by 123, 09 February 2012 - 03:23 PM.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users