Setting up a simple alarm system

Plugins & Plugin Development General Plugin Discussion
1

  1. Create a virtual state device ‘Home occupied’.

  2. Create a virtual state device ‘Home armed’.

  3. Create a scene ‘Home occupied: on’:
    Events: sensor is tripped (add all sensors that should be part of the alarm system)
    Commands: Set device ‘Home occupied’ to ON.

  4. Create a scene ‘Home occupied: off’
    Events: sensor is un-tripped (add all sensors that should be part of the alarm system)
    Commands: Set device ‘Home occupied’ to OFF
    Luup: return “all sensors are not tripped”

  5. Create a scene ‘Alarm’ which sends an email if the house gets occupied while armed.
    Events: ‘Home occupied’ is turned ON.
    Luup: Send ALARM email, if device ‘Home armed’ is ON.

I’m using denix’s StateDevice (http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104), and I’m encountering the following problems:

[ul][li]Cannot set virtual state devices to ON/OFF via ‘Commands’ tab (workaround: use luup.variable_set on ‘Luup’ tab).[/li]

[li]The event “‘Home occupied’ is turned ON” (step 5) doesn’t fire (no workaround - besides integrating the alarm code into the scene ‘Home occupied: on’ …).[/li][/ul]

Which changes to denix’s StateDevice are required to make the StateDevice fire events and to make the StateDevice usable from the ‘Commands’ tab?

2

@Ap15e,
Have you considered implementing the “v1” (and future “v2”) Alarm interfaces as a Virtual Alarm Plugin?

With some reasonable parameters, one could “associate” a set of one or more Motion-Sensor devices with a Virtual Alarm device (using a parameter that lists their DeviceId’s) and then completely simulate an Alarm Panel.

You’d use the [tt]luup.variable_watch[/tt] to “monitor” the [tt]Tripped[/tt] state of these various (user-supplied) motion sensor devices and then have it trigger the Virtual alarm
http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_variable_watch

Once we standardize v2, and get a few CP’s to implement it, your Virtual Alarm would work just like any of ours (in terms of notifications, setup, and “remote” control via iPhone/Android/WinX)

Anyhow, if you’re interested, you could start with the “v1” interfaces that @futzle’s GE code and my Paradox Panels both use ([tt]S_AlarmPanel1.xml[/tt], [tt]D_AlarmPanel1.json[/tt], and the associated serviceId’s)

What do you think?

3

@guessed,

One could even go a step further and automatically ‘collect’ all sensors via [tt]luup.device_supports_service[/tt] (and let the user remove sensors from the Virtual Alarm Device (VAD :))).

But:
[tt]luup.device_supports_service[/tt] doesn’t work reliably (as a workaround you could check whether Luup/UPnP variables related to sensors exist).

As I don’t have an urgent need for a full blown alarm system, I’d prefer leaving the implementation of VAD to someone more knowledgeable in this area. The main challenge is to come up with a nice state diagram for VAD.

Any ideas about my problems with the the StateDevice?

4

I don’t know what’s up with the StateDevice code, I can’t even unpack it on my Mac. Tried a little, but then gave up on the non-standard packaging.

Have a look at this common file used by the Alarm units:
http://code.mios.com/trac/mios_paradox-alarm/browser/D_AlarmPartition1.json

This sets up the various “Tabs” for the Device, including notifications, along with most of the Scene and Event logic. It also has the state tracking stuff on the buttons so they “glow” when you’re in a given state.

eg. The PadLock changes to “closed” or “open” depending upon the AlarmPartition1 “disarmed” state, the “(Armed)” button will glow if the [tt]AlarmPartition1[/tt] “armed” state is set (etc).

btw, the minimalist [tt]AlarmPartition1[/tt] implementation need only implement “Armed” and “Disarmed” (states and actions) and then the .json above kicks in and handles the UI and Events. Basically “Armed and Disarmed” are the minimalist states for a starter panel, the resulting transition diagram becomes really simple :wink:

Of course, not a sub for a real Alarm, but it does represent the “Home” (“Disarmed”) or “Away” (“Armed”) states, and a few other bits to go with it.

5

If you can get this working, I would very much like to do something similar to my setup. Please keep us posted and maybe add the luup code as well?

  • Garrett
6

@guessed

I’ve attached denix’ StateDevice files.

Have you considered augmenting physical alarm panels with sensors connected to Vera (Z-Wave, Insteon, …)?

7

It’s missing the JSON that drives the UI, along with the Toggle implementation. There should be a declaration indicating which JSON to use, along with the actual JSON file.

It was probably built for UI2, and not adapted to UI4. There are a bunch of additions that need to be made to have it work correctly under UI4 (see the various code examples on code.mios.com that have been upgraded to UI4 standards.

Looking at D_BinaryLight1.xml, I think the DeviceType is incorrect in this file.

I have no idea what this does:

[tt] state-toggle
OFF
[/tt]

You can definitely have a tag instead of a tag, to do stuff async, but probably no point here since it’s just running [local] code that shouldn’t have any significant “delays” in execution.

Whilst you’re at it, might as well move the variable_get that reads the “Reversed” status up to a Local in the startup method, will save you jumping to C each time the executes.

I would start with the built-in D_BinaryLight1.{xml,json} and implement from there. Technically you don’t need a new D_BinaryLight1.xml, as you can have one device with multiple implementations, so you’d only need to write the one file (I_Whatever1.xml). If you did this, you’d just need to remember to enter both the DeviceSpec and DeviceImpl when creating the device.

8

Speaking for myself … I would think a virtual alarm device for those of us with a vacation home that needs monitoring on an notification basis would be great. Right now I use home/away scenes but a centralized device would be great. Thanks for the thoughts:-)