I haven't found out yet al the features, for now I'm using it to monitor my door sensors and eagle eye's.This works well.The part where you can use the switchboard in the trigger menu of Indigo 5 I don't understand.Where can you define the state of the mentioned items in the trigger menu ?

what i found out is that if you have a door sensor you first had to define it as a "monitored device" with the right id (seen in your event log from the sensor) in the device section of indigo.Then you have to determine what you want to do with this signal. I have made a trigger which determines the status of my door i.e. open or close. This variable is used for multiple purposes again.

I created a X10 Monitored device for each key fob (2)I created a Monitored Device Group and added each key fob to it and turned on Action Group Support to a group called AlarmI created an Action Group for Alarm_Armed and Alarm_Disarmed The Alarm_Armed action group sends an All Lights Off commandThe Alarm_Disarmed action group executes another Action Group which turns on the living room lights.

Here's the next step: I only want the living room lights to come on if it is dark.

what i found out is that if you have a door sensor you first had to define it as a "monitored device" with the right id (seen in your event log from the sensor) in the device section of indigo.Then you have to determine what you want to do with this signal. I have made a trigger which determines the status of my door i.e. open or close. This variable is used for multiple purposes again.

v0.55 does allow the X10 devices to be updated, if they are outside of a Monitored Group.... But, the intended workflow is for a device to be in a Monitored Device Group.

I'm not clear on how to add security devices and then set up the actions. I think I've got my two key fobs added and a front door sensor added as devices but what do I do next?

The Switchboard plugin is intended to "Oversee" those devices by placing them into a Monitored Device Group...

Keep in mind, there are 4 different devices in the plugin.

* Monitored Device Groups - This is a grouping of devices that you want to trigger an "action". So for example, The Exterior doors of the house. Or the Lights in the Recreation room being turned off. Or the heat lamps in the Fish / Turtle Tank. This device contains the information for what is going to happen. For example, trigger an Action Group to be fired off. It also contains the optional settings (Speak something when this is triggered, Send an email, etc)

The Monitored Device Groups, are really the brains of the plugin. The idea is that in most cases, you don't have a single sensor that only does one specific thing. For example, you may have multiple exterior doors.... (I happen to have 3). In most cases, you will want to monitor those common sensors in the same way, so you create a Monitored Device Group (let's say, outside doors), and add those XX sensors into that group.

Once added, any of those sensors will trigger off the Action Group defined in the Monitored Device Group, and/or the Timed Profile devices that are defined.

This way you do not need to create custom triggers, etc....

* X10 Monitored Device - Optional - Since there is no native X10 Security devices, I have created a X10 place holder. Define the X10 Security ID, and the system will monitor for that ID. (The intention is for this to be added to A Monitored Device Group.)

* Timed Profile(s) - Optional - When a Monitored Device group is triggered, one option is for a "Timed Activation Device" to be triggered. For example, in my configuration, my Timed Activation Device is an X10 Chime that will alert us when an exterior door is opened. You can set how long the device is left on, along with preventing the timed device from activating if it has been triggered within the last X minutes... This allows you to configure the device once, and use it within multiple Monitored Device Groups. (Or youcan configure multiple variants, and use them as needed....)

* Security Center - Optional - The newest device in the Switchboard Plugin. It acts as a overseer to the X10 Security Commands. It monitors for Panic requests, Arms, Disarms, etc. This way you can easily see if a panic state is active, or arm your house. The state is recorded in the Security Center, and trigger actions can be created against the Armed status, etc...

So for your devices, you will want to create a monitored device group, and add them in....

what i found out is that if you have a door sensor you first had to define it as a "monitored device" with the right id (seen in your event log from the sensor) in the device section of indigo.Then you have to determine what you want to do with this signal. I have made a trigger which determines the status of my door i.e. open or close. This variable is used for multiple purposes again.

You can do that... But the Monitored Device group also can eliminate the need for the trigger....

There is two ways to use an "automatic" trigger that switchboard manages.

1) Timed Device Profiles. This is an optional device in the plugin, but is quite powerful... When a Monitored Device group is triggered, one option is for a "Timed Activation Device" to be triggered. For example, in my configuration, my Timed Activation Device is an X10 Chime that will alert us when an exterior door is opened. You can set how long the device is left on, along with preventing the timed device from activating if it has been triggered within the last X minutes... This allows you to configure the device once, and use it within multiple Monitored Device Groups. (Or you can configure multiple variants, and use them as needed....)

2) Action Group Support - Each Monitored Device Group has an option "Turn On Action Group Support". When turned on, type in the name of an Action Group (See below), and it will be triggered when a monitored device is triggered.... In many cases, this can replace the need for a Indigo trigger.

Now, I've simplified it. This action group support is slightly more complex, due to the naming of the action group. Let's say you have a Door sensor. It has two different states, Open, and Closed. The action group in my example will be "Exterior Doors".

When an Open state is detected, the action group that is triggered will be called "Exterior Doors_Open", and if a closed state is detected it would be "Exterior Doors_Closed".

This works with Keyfobs, for example, "Exterior Doors_Panic" for the panic signal from the key fobs.

Now, switchboard is smart enough to not to trigger an action group that doesn't exist. So if you only wanted an action to occur on opening the door, just create the *_Open action group.

Switchboard supports the following states with the Action group feature:

* Open* Closed* Armed* Disarm* Panic* LightsOn* LightsOff

Why not use Indigo Triggers? Go right ahead....

The main concern I had was the upkeep of those triggers. In my exterior door case, I have three exterior doors... If I wanted an action to occur on the opening of those doors, I would need to create 3 Indigo triggers. For switchboard, it's simple a checkbox, and the name of the action group. Even more so, if I included closed actions, which would increase it to 6 Indigo triggers....

And if you wanted to make any changes to those triggers, it would then be 3 or 6 triggers to update... Unless you were simply calling an Action group from the trigger... (And if so, then why not skip the middleman?)

The major advantage that Indigo Triggers currently have is that you can place conditions on the trigger, for example, Now, one thing Switchboard doesn't support is conditional Action Groups, for example, only trigger the action group at night...

That's something that might be worthwhile for certain conditions (i.e. Night Only, Daylight Only, Armed, Disarmed, Panic, ???) but that would be a future enhancement. If there is demand, I will certainly consider moving that up in the schedule...

The changes are as follows: • v0.551 - 1/15/2012 - Third Public Release (Beta 3) ⁃ Bug fix, was attempting to update the security center device, even if it didn't exist. ⁃ Fixed DeviceStopCom, it wasn't updating the internal lookups when a device was being removed.

Overall, no major differences... Just the fix for the security center issue... And a tweak to the devicestopcom routine...