Email when door left unlocked for X minutes, another when re-locked?

Developer's Corner General Dev Discussions
#1

I’m trying to setup a luup scene or the like to send out an email if the door stays unlocked for X minutes. I then want to send another email if the door get’s relocked only after the unlock email is sent out. So it would look something like this:

  1. Unlock door
    Wait 30 seconds
    Lock door
    ------ No Message -----

  2. Unlock door
    wait 2 minutes
    ------- Message ------
    wait 2 minutes
    lock door
    ------- Message ------

Here’s what I have for the code, but it seems to be hit and miss. I get random unlock messages durring the day, and the relocks only sometimes work. I have two locks, and a virtual switch that I use as the “I’ve sent a message” variable, and the trigger to do the notificaiton, so I don’t have to do that in code. I’m thinking part of my problem is that when the X minutes is up, the device may have been relocked, but not polled yet…

BTW, I’m also turning on a light if any of the doors are unlocked, so I can easily see if I’m all locked up.

[code]local FRONT_DOOR = luup.variable_get(“urn:micasaverde-com:serviceId:DoorLock1”, “Status”, 31)
local BACK_DOOR = luup.variable_get(“urn:micasaverde-com:serviceId:DoorLock1”, “Status”, 101)
local LIGHT_STATUS = 100

luup.log("Front Door " … FRONT_DOOR … " Back Door " … BACK_DOOR)

if ((FRONT_DOOR == “1”) and (BACK_DOOR == “1”)) then
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”, “SetTarget”, {newTargetValue = “0”}, LIGHT_STATUS )
else
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”, “SetTarget”, {newTargetValue = “1”}, LIGHT_STATUS )
luup.call_delay(“SendUnlockMessage”, 90, “”)
end

function SendUnlockMessage()
local DOOR_EMAIL = luup.variable_get(“urn:upnp-org:serviceId:SwitchPower1”, “Status”, 102)
local FRONT_DOOR_POLL = luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”, “Poll”, {}, 31)
local BACK_DOOR_POLL = luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”, “Poll”, {}, 101)
local VIRTUAL_SWITCH = 102

if ((FRONT_DOOR == "1") and (BACK_DOOR == "1")) then
    luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, VIRTUAL_SWITCH)
else
    luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "0"}, VIRTUAL_SWITCH)
end

end[/code]

#2

Wow, one week, ~60 views and nothing…

OK, lets try a different tac. My main problem is with reliability. I’ll unlock the door, then re-lock in within the X minute time frame, but I still get an unlocked email, followed by a re-lock email. I’m thinking it’s a polling issue.

How do I force Mi Casa Verde to poll the devices and wait to continue checking until the poll completes (preferably without halting all other processing while I wait)? After X minutes I’d like to force a poll, then wait until the polls are complete for both devices, then do my final check before emailing…

#3

PLEG is perfect for this type of problem. Much easier and as powerful as programming Lua, so a lot of folks use it instead.

http://forum.micasaverde.com/index.php/topic,21603.0.html

#4

(Would you have preferred 60 people all replying, “Sorry, don’t know”?)

If you have to poll, then you’re going to get false positives. Transient network failures and timing mean that there will always be a race condition in checking the state, you relocking the door and Vera sending the email. Vera is multi-threaded and there is no API to synchronize threads in Luup. There are ancient discussions about threading on the forum. If you can find them they are worth reading.

The luup.call_action() calls don’t block (as you’ve discovered), and since you check your variables immediately after firing off the polls, you won’t benefit from the results of the poll. In theory, the call_action starts what Vera calls a “Job”, and you can periodically check that job to see if it completes successfully or not. If you follow the Luup log and do a “Poll Now” from the Settings tab of the device, you’ll see a few seconds later the job complete with a log entry “<Job ID=…”. That’s how the web interface to Vera knows how to display the poll state and whether it succeeded or not.

While it’s in the web interface, I don’t know how completely this job model is exposed to Luup. The luup.call_action() function is supposed to return the job ID, and there’s a luup.job.status() function which might be helpful. But you will have to do this in a check-wait-check-wait loop, just as the Vera web interface does in JavaScript. There’s no way to register a Lua callback for when the job finishes. You’ll find yourself writing functions that schedule themselves to run again in a few seconds.

Truth is, I don’t think that anyone’s really done this kind of insistent polling from Luup. It’s likely to flood your Z-Wave mesh with requests and might interfere with other messages. If you can possibly avoid polling, do. That’s why the forum strongly recommends that people buy Z-wave devices with instant status reporting where possible. If your locks don’t have instant status, you may not be able to properly solve this problem.

#5

This.

The general solution is to do something like:

[ol][li]When the (instant-reporting) lock reports unlock, save the unlock time in a global variable.[/li]
[li]Create some quick-running lua code that runs once a minute. If the current time is greater than the unlock time plus N minutes, send a notification. You need to make sure that you don’t continually send a stream of notifications, every minute, but this can probably be handled by setting the unlock time to something special like -1.[/li][/ol]

The advantage here is that you can extend this to handle other time-delay-based notifications…

However, the disadvantages are that you have 1-minute granularity/jitter (i.e., notifications will occur somewhere between N and N+1 minutes), and that you need to have short, quick-running code (or you’re going to hammer the vera unit).

I’ve been thinking about doing something like this, but slightly different: send a notification if the lock has been unlocked for more than, oh, 10 minutes, it’s after sunset, and after 7pm.

#6

very easy with PLEG

Triggers

DoorUnlocked (Device is unlocked)

Schedule

IsAfterSeven (A schedule that begins at 19:00 and ends at 06:00)

Conditions

DoorOpenedTooLong = DoorUnlocked AND (DoorUnlocked; Now>10:00)
SendDoorAlert = DoorOpenedTooLong AND IsAfterSeven
SendDoorClosedAlert = !DoorUnlocked AND (!DoorUnlocked; Now < 1:30)

Actions

SendDoorOpenAlert (send a push notification by Vera Alerts, HomeWave, etc)
SendDoorClosedAlert (Send a push notification by…)

This will send a notification if the door remains unlocked for more than 10minutes and it is between the hours of 19:00 and 6:00
It will also send an alert if the door was just closed

#7

Thanks.

However, I’m probably the only person here who’s OK consorting with lua, and so I’ll stick with the lua approach (besides, I have to use lua for the notifications, anyway). ;D

#8

What type of notifications require LUA ?

#9

given the choice of a shovel or a bulldozer, feel free to pick the shovel. :wink:

and if it so happens that your notifications can only be sent by Lua, you can do that in PLEG too…

#10

Anything not supported by the vera or plugins. ;D In my case, prowl.

Now, there is a plugin that supposedly does support prowl, but it doesn’t support two key things that I need:

[ol][li]Notification rate limiting. I’m using altsteon, and there seems to be an issue where multiple (identical) events can be triggered, instead of just one. To prevent multiple notifications from these events, I’m rate-limiting the notifications (and the rate-limiting is done such that I can still send multiple simultaneous notifications, as long as they’re different).[/li]
[li]Notifications to multiple destinations. Plugins often assume that you have only one smartphone/person/account to notify or whatever. Unfortunately, this doesn’t work if you want to send notifications to multiple people (like members of a family).[/li][/ol]

#11

Yes, I know. I figure I’m already knee-deep. I might as well go all-in. ;D

Edit: also, while you could compare a shovel (lua) to a bulldozer, a better comparison would be “magic” to a bulldozer. While I might happen to have a shovel, now, I can transmogrify it into a bulldozer, a crane, a supersonic jet, or something else. The bulldozer, on the other hand, is still a bulldozer (a very powerful one, yes, but still a bulldozer). ;D

#12

Vera Alerts Supports Prowl and PushOver for IOS users.

#13

I’m using Lua to do the Prowl notifications, and just have my Wife’s iPhone use the same Prowl account. Prowl’s servers handle this nicely, and both devices get the same notification within a very short period of each other.

Obviously, not for everyone… but it’s simple/lightweight and works for a very common case (Wife asks “What’s Prowl?” :wink: )

#14

Edit: also, while you could compare a shovel (lua) to a bulldozer, a better comparison would be “magic” to a bulldozer. While I might happen to have a shovel, now, I can transmogrify it into a bulldozer, a crane, a supersonic jet, or something else. The bulldozer, on the other hand, is still a bulldozer (a very powerful one, yes, but still a bulldozer). ;D[/quote]

Yeah, I get it.

I’m an engineer, though. I see a nail, and I think hammer, even though I know I could do a whole lot more if I brought out the whole toolbox!

#15

Yeah, that works (and there’s nothing wrong with it).

I just like having a more general solution where I fill in the blanks (the engine code isn’t given, here):

local notifications = {
   {
      "1111111111111111111111111111111111111111", -- apikey
      0, -- priority
      "Front door", -- application name
      "Door opened", -- event text
      -- Description (multi-line is allowed):
      os.date("%I:%M:%S %p, %b %d, %Y"),
      10, "front_door" -- optional: rate limiting (seconds), class name
   },
   {
      "2222222222222222222222222222222222222222", -- apikey
      0, -- priority
      "Front door", -- application name
      "Door opened", -- event text
      -- Description (multi-line is allowed):
      os.date("%I:%M:%S %p, %b %d, %Y"),
      10, "front_door2" -- optional: rate limiting (seconds), class name
   },
}
#16

I just avoided this whole coding exercise by using the feature on my Yale Locks called “Autolock” and I can even define the time until it autolocks. My family had the habit of not locking the kitchen back door but closing the door and I solved this by enabling the autolock feature with 30 seconds.

Just don’t specify what door lock you have but maybe your door lock has a similar feature?