Actually i just had another thought.. instead of just having "settings on condition start" and "settings on condition end" what if there was a way to create as many "settings groups" as you wanted.

to create a settings group you would be prompted for x y and z:

run z times, every y minutes, starting x minutes after condition start/end
*note z can be infinite and can't be zero
*note y isnt necessary if z=1
*there could also be an option to abort the x delayed event if the condition becomes true again, i.e. if i leave work but i'm back before the x time is up then don't do the settings change

so to create a settings group of "run once on condition start" (this is what locale does now) you would choose x=0, z=1, y=doesnt matter since we're only running once

the biggest benefit to this isnt really repeating actions (i'm not sure many people would use this) but rather the delaying by a certain number of minutes and more importantly aborting the action if the condition changes. so if i have something set to change 5 minutes after i get home but i leave home within 3 minutes, then the action shouldnt happen

wouldnt it be smarter to have a 3rd section when you add a situation to locale? currently for each situation we have conditions and settings. immagine we had instead conditions, settings on condtion start, settings on condition end.

this way we could say when the condition begins (location equals home) turn on my wifi, but when this condition ends (is no longer true, i.e. when i leave home) turn off the wifi.

this is similar to defaults but we can set things to happen when specific conditions end. for example when the condition "location = work" ends i could send an SMS saying "leaving work" but I don't want to use the defaults for that since I don't want to send that SMS when i leave home.

this would also work well with time based events. i use my calendar to trigger events more often than I use location. when an event (say, a class, where I have my phone set to go on silent automatically) is over I can set my phone to turn back up.

i think this solution would be more effective than having a "not" condition and more effective than using the defaults.

also there is a problem with using the variables plugin to do this. you have to set the variables to turn back to false or reset to zero when a condition ends otherwise they continue to be true (is this incorrect? i have used the variables plugin only a little but this is the conclusion i have come to). by having an "settings on condition end" section we can reset variables that were set up in "settings on condition start"

i think this really is the best way to roll a few requests into one, namely the "not" and the "on condition end" ideas