PLEG and iPhone Locator Muting

First one is easy - syntax. I’m assuming those should all be TLauraHome, not LauraHome.

Second one, I’m not so sure. Based on the message sounds like perhaps a device was put into lost mode? Or perhaps the device has been swapped out with a new one and requires remapping inside find my iphone? I can’t really help there as much but you are correct. That is coming from the Locator plugin not PLEG.

Oops that was embarrassing that I didn’t catch that. Changing the syntax fixed that error. I was also able to fix the iPhone Locator app error because I had two instances of iPhones for the app for my girlfriend’s phone – I forgot to remove her old, sold iPhone 4 from her iCloud so it thought that phone was ‘lost’.

Sadly the Mute/Unmute PLEG still isn’t working for some reason. It just worked for my girlfriend when she came home? the app muted after she was home for 3 minutes. But it hasn’t worked for me at all today, and not unmuting my girlfriend’s iPhone locator app does not throw it back into the mute condition even though she’s at home. It seems fairly unreliable so far unfortunately but I was really hoping it could work to preserve battery life.

@agoodman,

Keep in mind, PLEG is VERY logic based and for the most part pretty binary. It follows a set of simple rules through and through. The big thing to remember is that a condition needs to turn true, and then at some point turn false again. Without this, there is no “re-trigger” of the PLEG condition and the subsequent action associated. The action will happen when the condition becomes true. If it never becomes false, it will never trigger again. I think I now recall why I created 2 Mute conditions. As I describe below, your Condition1 will not become FALSE until you actually leave. So that’s why I combined my phone and my gf phone in one line for each sets of conditions. In this case, you will need to break out the two pieces. I think I was reading your condition and tried to mesh the two into one. My apologies there for the misdirection. It’s been awhile since I had this in my own environment.

Condition1: TAlexHome AND (TAlexHome; Now > 3:00)
Condition2: TBasement OR TFrontDoor OR TAlexAway
Action1: Mute iPhoneLocatorPlugin
Action2: Unmute iPhoneLocatorPlugin

If you were to be out (iPhoneLocator in Away state) then come home, as soon as you come home (TAlexHome = TRUE) a “counter” would start for 3 minutes from the timestamp of your TAlexHome last becoming true. In you’re latest status: 2014-01-29 20:53:15 or 8:53 local time. If this “counter” reaches 3 minutes of iPhoneLocator being Present (TAlexHome), then it will be TRUE. Condition1 = TRUE, phone muted, mission accomplished.

Now if you were to open one of the doors in Condition 2 (TBasement or TFrontDoor), this would make Condition2 = TRUE as well. This would then Unmute the phone. Mission accomplished. BUT, you’re phone will not Mute again until TAlexHome is no longer TRUE. TAlexHome = FALSE, is what will in turn make Condition1 = FALSE, which will then allow TAlexHome to then again mute your phone.

Try one of these instead:

CPhoneMuteAlex1 (TAlexHome AND (TAlexHome; Now > 3:00))
CPhoneMuteAlex2 (TAlexHome AND (CPhoneUnMuteAlex; Now > 3:00))
CPhoneUnmuteAlex TFrontDoor OR TBasementDoor OR TAlexAway
CPhoneMuteLaura (TLauraHome AND (TLauraHome; Now > 3:00))
CPhoneMuteLaura2 (TLauraHome AND (CPhoneUnMuteLaura; Now > 3:00))
CPhoneUnmuteLaura TFrontDoor OR TBasementDoor OR TLauraAway

----------------OR--------------

CPhoneMute1 (TAlexHome AND (TAlexHome; Now > 3:00)) OR (TLauraHome AND (TLauraHome; Now > 3:00))
CPhoneMute2 (TAlexHome AND (CPhoneUnMuteAlex; Now > 3:00)) OR (TLauraHome AND (TLauraHome; Now > 3:00))
CPhoneUnmute TFrontDoor OR TBasementDoor OR TAlexAway OR TLauraAway
If it never becomes false, it will never trigger again.

This is the default behavior. You can override it by starting the condition name with an underscore _XXX as opposed to XXX
In this case it will trigger ever time the condition evaluates to true.

@shmixx:

I tried modifying my conditions with your first set of code (it’s easier for me to split the conditions like that so I better understand what’s going on and it’s easier to assign the action to them) and so far it looks good! It seems like when I make changes it takes awhile for everything to sync because certain conditions need to become true or false to have everything sync up. Right now everything is muting and unmuting individually as it’s supposed to though.

I’m still trying to get the security arm/disarm to work properly depending on who’s home and who’s not but at least the mute PLEG seems like it’s working well again.

@RichardTSchaefer:

Do any of my current conditions require the underscore or will my conditions just continue to loop as they should without it?

@agoodman

Good to hear it’s working. What’d you whip up for the auto-arm/auto-disarm scene? It shouldn’t be much more than what you’ve already got. PS - Good thing you chose the first not the second, I just see now I made a goof in CPhoneMute2 at the end. Should be:
CPhoneMute2 (TAlexHome AND (CPhoneUnMute; Now > 3:00)) OR (TLauraHome AND (CPhoneUnMute; Now > 3:00))

In regards to RichardT comment - he illustrates the capability to override the default behavior of only carrying out the Action associated with a Condition when the condition becomes True, and not again until it becomes False first. If you were to use _CPhoneMute as the name, it would change the PLEG behavior to carry out the Action associated, EVERY TIME the condition is met.

In this instance taking
CPhoneMuteAlex1 (TAlexHome AND (TAlexHome; Now > 3:00))
CPhoneMuteAlex2 (TAlexHome AND (CPhoneUnMuteAlex; Now > 3:00))

And turning into
_CPhoneMuteAlex (TAlexHome AND (TAlexHome; Now > 3:00)) OR (TAlexHome AND (CPhoneUnMuteAlex; Now > 3:00))

Would accomplish the same thing. And would overcome the same problem we addressed by putting them into 2 separate conditions.

Thanks for the explanation, that actually is starting to make sense lol.

As for my arm/disarm scene, the only condition that isn’t working properly is if I’m home OR my girlfriend is home, and the other person leaves, I don’t want the security system to arm. My girlfriend just left the house, I’m still home (my iPhone is muted thanks to this PLEG but still shows as “present”) and unfortunately all the sensors just switched to “arm” again when she left my preset “home” distance. When both of us are gone, the alarm system arms perfectly or if we’re both home, obviously the sensors stay in bypassed mode. I’ve noticed that the conditions when we both leave or both come home make the system arm twice or disarm twice (I get two alert notifications each time) so I guess because of the actions the PLEG is treating us as individuals rather than treating us as all or nothing and only arming/disarming the sensors one time. I was hoping the SomeOneHome condition would be as simple as adding the “OR” conditional in there but I must be missing something:

[code]
PLEG Alarm Control

Device ID: 992014-02-01 11:32:12.679 PLC Version: 5.7

Triggers

Name Description State Last True Last False
AlexHome ()Alex's iPhone is present true 2014-01-31 21:39:39.802 2014-01-31 19:24:13.175
AlexAway (
)Alex's iPhone is away false 2014-01-31 19:24:13.175 2014-01-31 21:39:39.803
LauraHome ()Laura Fornaro?s iPhone is present false 2014-01-31 21:40:24.055 2014-02-01 11:28:57.046
LauraAway (
)Laura Fornaro?s iPhone is away true 2014-02-01 11:28:57.047 2014-01-31 21:40:24.056
Conditions

Name Expression State Last True Last False
CNobodyHome AlexAway AND LauraAway false 2014-01-31 19:24:26.402 2014-01-31 21:39:39.804
CSomeoneHome AlexHome OR LauraHome true 2014-01-31 21:39:39.805 2014-01-31 19:24:26.406
CEveryoneHome AlexHome AND LauraHome false 2014-01-31 21:40:24.059 2014-02-01 11:28:57.050
Actions

Actions for Condition: CNobodyHome

Immediate

Device Action Arguments
Basement Door SetArmed newArmedValue=1
Basement Window Left SetArmed newArmedValue=1
Basement Window Middle SetArmed newArmedValue=1
Basement Window Right SetArmed newArmedValue=1
Camera - Basement Motion Sensor SetArmed newArmedValue=1
Half Bath Window SetArmed newArmedValue=1
Laundry Room Light SetLoadLevelTarget newLoadlevelTarget=0
Master Bedroom Light SetLoadLevelTarget newLoadlevelTarget=0
Office Window Left SetArmed newArmedValue=1
Office Window Right SetArmed newArmedValue=1
Kitchen Door SetArmed newArmedValue=1
Kitchen Window Left SetArmed newArmedValue=1
Kitchen Window Right SetArmed newArmedValue=1
Bay Window Left 1 SetArmed newArmedValue=1
Bay Window Left 2 SetArmed newArmedValue=1
Bay Window Right 1 SetArmed newArmedValue=1
Bay Window Right 2 SetArmed newArmedValue=1
Camera - Living Room Motion Sensor SetArmed newArmedValue=1
Front Door SetArmed newArmedValue=1
Front Door Lock SetTarget newTargetValue=1

Actions for Condition: CSomeoneHome

Immediate

Device Action Arguments
Basement Door SetArmed newArmedValue=0
Basement Window Left SetArmed newArmedValue=0
Basement Window Middle SetArmed newArmedValue=0
Basement Window Right SetArmed newArmedValue=0
Camera - Basement Motion Sensor SetArmed newArmedValue=0
Half Bath Window SetArmed newArmedValue=0
Office Window Left SetArmed newArmedValue=0
Office Window Right SetArmed newArmedValue=0
Kitchen Door SetArmed newArmedValue=0
Kitchen Window Left SetArmed newArmedValue=0
Kitchen Window Right SetArmed newArmedValue=0
Bay Window Left 1 SetArmed newArmedValue=0
Bay Window Left 2 SetArmed newArmedValue=0
Bay Window Right 1 SetArmed newArmedValue=0
Bay Window Right 2 SetArmed newArmedValue=0
Camera - Living Room Motion Sensor SetArmed newArmedValue=0
Front Door SetArmed newArmedValue=0[/code]

Are you using an actual Alarm System with multiple sensors? Something like an ADT or Honeywell system?
I have a similar setup with a Honeywell Vista 21iP. I use the AD2USB device to connect into it. If this is the case, you only need to ARM the main panel device. Arm/Bypass the individual sensors isn’t really that useful unless you have specific cases to Bypass a particular sensor when arming, and such. So I just set the system to ARM as the 1 Action for the condition. Leaving sensors armed when the alarm panel isn’t armed, doesn’t cause anything to go off or fault in the panel. Or another option is to create a scene (turn off all lights, lower thermostats, lock front door, arm alarm, etc) and initiate that scene from PLEG. Just some thought on that piece.

For the double notification part, do you have alerts set up in other places perhaps? Maybe you set a notification for the PLEG condition being satisfied, and a notification from the Alarm Panel device to notify you when it becomes Armed/Disarmed? Might just be a double up somewhere. It could also be another scene, condition, or trigger that is being initiated in the same way? Think a scene that has a trigger involved in the actions of your PLEG for the condition. Say turning off a certain light, causes another scene to ARM the alarm. Both the PLEG is doing it, and one of your actions is triggering a Scene that also ARM’s the alarm. Also, if you have Actions for CEveryoneHome (which I don’t see here) that include Disarming everything, this could also be the culprit since both CSomeone and CEveryone will be triggered when you both come home at the same time.

As for the system arming when your GF left, I don’t see that happening based on the 3 conditions you have listed. Looking at the timestamps, the CNobody is the one I imagine that sets the status to Arm, and by looking at the timestamps, I can see 2014-01-31 19:24:26.402 for a timestamp of last time it was TRUE. Meaning yesterday ~7:24PM you left and it automatically armed for you. When you came home ~9:40PM, CSomeone and CEveryone tripped which would cause the disarm from CSomeone (and CEveryone assuming there are Actions missing below, and this would definitely cause the Double disarm and notification).

I should’ve specified. I don’t have a dedicated alarm system like Elk or ADT. I have several z-wave sensors and other devices (Aeon Labs door sensors, foscam cameras, Yale locks and z-wave siren) that I’ve rigged together as an alarm system. I understand the limitations and downfalls of using z-wave sensors but so far it’s working quite well for me. I put all the sensors into two scenes using the Vera UI: Armed - Away & Home - Bypassed. I think an issues I had was that I had the PLEG running and the Vera scenes running at the same time, both using the iPhone Locator plugin as the triggers. Today when I figured out how to make a Vera scene an action in PLEG, I disabled the triggers within the scenes themselves and instead let PLEG utilize the iPhone Locator app as the triggers with the two scenes themselves being the actions for the triggers when the conditions were met (home/away for disarm/arm). After doing this, for the first time I got the PLEG to work correctly in that the sensors would not arm if one iPhone was still located at home. I still need to run for a few more days under different conditions to make sure it wasn’t a fluke but so far the mute/unmute PLEG is co-existing very nicely with my alarm PLEG to arm and disarm the sensors properly as we come and go throughout the day :slight_smile:

Alex - glad to hear. It takes a bit to get going and get ahead of the learning curve. Once you do, you wonder how you did without this stuff previously! :slight_smile:

What you described around the scenes and PLEG interacting with the alarm makes sense for the double alarm/disarm as well as the entanglement for arming when the GF left but you were still home. Adjusting that approach (having PLEG actions to run a scene) also makes it easier to manage the PLEG actions and such. I try to reduce my clutter as much as I can by combining things like scenes with conditions, etc. Happy we could get you to the final result successfully. Now keep an eye on the battery life of those phones! :wink:

Yes, battery life is now the only limiting factor! 8)

Thanks for all the help Shmixx. I had been wanting to set these advanced scenes up for the longest time now but was very intimidated by PLEG. It’s an extremely powerful plugin, especially when paired with the iPhone Locator plugin for scenes. Seeing as there is no z-wave equivalent for an alarm keypad and voice commands for z-wave devices/scenes I believe are only possible with tasked for android phones, this was definitely the best solution for my setup. Now that I know I can reliably trust the iPhone locator plugin and the mute/unmute PLEG it’s been pretty easy to manually mute/unmute the iPhone locator plugin if I know I’ll be away from the house for a long time. Even if I don’t, I believe I’ve set up some optimal polling distances/times that conserve battery life enough but also allow for accurate pings so that the sensors are bypassed when I reach my pre-set home range.

Seeing as you’ve used PLEG for awhile now do you find it less clutter to use a PLEG only for advanced scene setups and leave the simple stuff to Vera’s built-in scene scripting? I know multiple PLEGs start to draw a bit of memory and I too only have a Vera Lite so I know there is a limit to devices/scenes I can have running at any one time.

@agoodman82: Check out http://forum.micasaverde.com/index.php/topic,22616.0.html , I am currently looking for testers for the iPhone app that I am working on that does handle voice control. Currently it does more than just voice control and would like input from users, I will be opening up to beta testers in the next couple of weeks and expect a GA release in a month or so.

@agoodman - NP, glad we got your there. I had to lean on some others like RichardT as I was getting it perfected. It’s quite difficult sometimes to describe our issues, our end goal, and hope someone is able to help in a quick enough fashion that we aren’t just hanging.

I generally try to put almost ALL of my automation into PLEG. Realistically the small stuff as separate scenes, is likely taking up more memory than just adding another condition to my PLEG. I’ve only got 2 PLEG devices: 1 for Thermostat and temperature related settings (since this one has lots of conditions/actions - think my daily schedules x 3 zones), and 1 which has all my other automation actions. I’ve got something like 15 conditions in it currently. I often don’t touch anything, but here and there I tweak some things as I think of it.

@jpete - you’ve got a private message! I’m quite intrigued by the app you describe in your thread. Sign me up!

@shmixx: The best part about Vera is this forum and people like you and RichardT that are willing to help new guys like me learn something. HA is definitely a strong community of people looking to try new things and learn from each other. I definitely learn something new each time I check out the boards here. With the mute/unmute PLEG I have noticed that if I mute or unmute one of the iPhones “manually” by selecting that option on the iPhone Locator app itself it “breaks the cycle” of the PLEG and won’t fall back in cycle until one of the conditions are met. For example if I’m home and have been for over 5 minutes, my iPhone is muted because of the PLEG. If I manually unmute the phone though the plugin however, the phone will not remute on its own after five minutes, and requires me to use one of the triggers like opening the back door to reset the plugin back into the PLEG cycle. It’s not a big deal but I guess it happens because the conditions don’t allow for it to fall back into the cycle until one of the conditions changes due to a trigger. I have had one or two hiccups with it over the past day or two where for example my girlfriend would be at work and her iPhone locator app would be muted even though it showed her as being away. If its only the occasional issues I can live with that :stuck_out_tongue:

@jpete I replied to your thread about your new app and am quite interested! If you need more people for testing count me in!

You are right on in why that’s happening. Because there is no condition to look for an Unmute device, it won’t trigger a reset. With regard to the GF being away and muted, this could be if you combined the devices into one PLEG. When I did this, this was the desired state. (I’m home, GF at work, both phones muted). They would BOTH Unmute though, if I was to leave and actually be marked AWAY. So it worked well to help ensure battery saving.

If you want to avoid this you could add the respective status into the logic (TAlexMute or TAlexUnMute) as a trigger. Then leveraging this, you can ensure the proper sync happens. The only reason I don’t like this, is if I want to manually override, I’d have to modify my PLEG to make sure it doesn’t counteract my manual overrides. Especially as you said if you know you will be away for awhile (vacation say) then you can manually Mute it to save on location services draining you.

Also as an FYI - if you have a Trigger (TAlexAway) you can always use a NOT to negate the trigger in your logic as well. So instead of requiring TAlexAway and TAlexHome, you can use TAlexAway and NOT TAlexAway. Basically the binary type of logic with only one trigger instead of a need for two if you’re just using true/false logic anyway.

Good to see I am finally beginning to understand some of the logic the proper way lol. I actually like the way the PLEG is set up with the ability to manually over-ride the conditions manually by muting the plugin to avoid battery drain. There are so many possible “conditions” like for example, I could be away from home, but so close that my iPhone is being polled often but yet in a static location and not moving vs if I was that same distance but returning home. I’d imagine that if I were superb at understanding PLEG and all its uses I could add in additional complex conditions like that, but its just as easy to manually override it and then when I am actually returning home, just reset the PLEG to return to its normally functioning cycle. It’s working so well I’d be afraid of breaking something at this point lol.

Also I totally see what you mean about simply negating a trigger and then I could cut my triggers in half. It was easier for me to set up the opposite condition triggers just so I could see it when I was first playing with all of this but in the future I think I can just use the NOT in that way to cut down on the work. Thanks for the help!

You are spot on in your explanation. I had this exact issue as I work from home. Where I live, I’m very close to home when I’m at the local market, deli, coffee shop, etc. So I often venture out in a day to these places, but they are so close, I can’t really reduce the polling without affecting normal travel times. This is part of the reason iPhone Locator in the long run wasn’t working as well for me. I have great hope for the app that jpete is working on. The location capabilities and a virtual switch with some PLEG should help really make it easier to handle and salvage battery life greatly!

Just to update on this thread on comments about iViri and shmixx. iViri is available in the App Store and can be used as a good replacement to the iPhone locator plugin. You will see how much more accurate it is along with saving battery life that the locator seemed to swallow up. Also allows for voice control. I am the developer of this app.

I couldn’t tell from the iTunes screens if this app supports the ademco alarm devices such as the panel and sensors, allowing me to both see the status of the alarm as well as change it. i.e. set the alarm to stay, disarm, etc.

If the ademoco alarm device adheres to the “urn:micasaverde-com:serviceId:AlarmPartition2” standards then it will be supported. Also just to note I will be willing to work with you if you do encounter any issues. The other cool part about iViri is it allows you to store the PIN code so you don’t have to enter it every time you change your alarm state, however, if you want to enter it each time you will be prompted each time that you take an action on your Alarm Partition.