Custom Plugin for an Alarm System

Hi everyone,

I spent the better part of today going in the bowels of the Indigo plugin architecture and trying to come out with something useful.

My ultimate goal is to create an Indigo plugin that will talk to an Arduino to get alarm state, AND talk to HomeKit via the HomeKit Bridge plug-in.

For now, I'm just trying to get a custom plug-in created. The plug-in needs to handle four states:

0- Stay Armed
1- Away Armed
2- Night Armed
3- Disarmed

In my Devices.xml file, I have:

Code: Select all

   -->
   <Device type="custom" id="myCustomAlarmType">
      <Name>Custom Alarm State</Name>
      <ConfigUI>
         <Field id="address" type="textfield" defaultValue="192.168.0.30">
            <Label>IP Address:</Label>
         </Field>
         <Field id="SupportsSensorValue" type="checkbox" hidden="false" defaultValue="true">
            <Label>Supports sensor value</Label>
         </Field>
         <Field id="initialValueObtained" type="checkbox" hidden="true" defaultValue="true">
            <Label>Has the initial value been obtained?</Label>
         </Field>
         <Field id="tag" type="textfield" defaultValue="a">
            <Label>Tag:</Label>
         </Field>
      </ConfigUI>
      <States>
         <State id="sensorValue">
            <ValueType>
               <List>
                  <Option value="stay">Stay Arm</Option>
                  <Option value="away">Away Arm</Option>
                  <Option value="night">Night Arm</Option>
                  <Option value="disarm">Disarm</Option>
               </List>
            </ValueType>
            <TriggerLabel>Alarm State Changed</TriggerLabel>
                <TriggerLabelPrefix>Alarm Changed to</TriggerLabelPrefix>
            <ControlPageLabel>Alarm State</ControlPageLabel>
                <ControlPageLabelPrefix>Alarm state is</ControlPageLabelPrefix>
         </State>
      </States>
   </Device>


My Actions.xml file looks like this:

Code: Select all

   <Action id="setCustomAlarmState" deviceFilter="self">
      <Name>Set Custom Alarm State</Name>
      <CallbackMethod>setCustomAlarmState</CallbackMethod>
      <ConfigUI>
         <Field id="description" type="textfield" hidden="true">
            <Label>runtime calculated</Label>
         </Field>
         <Field type="menu" id="sensorValue" defaultValue="0">
            <Label>Alarm State:</Label>
            <List>
               <Option value="stay">Stay Arm</Option>
               <Option value="away">Away Arm</Option>
               <Option value="night">Night Arm</Option>
               <Option value="disarm">Disarm</Option>
            </List>
         </Field>
      </ConfigUI>
   </Action>
</Actions>


I create a device of type "Custom Alarm State" and it shows up in my device list. I also created a control page and tied four controls to each of the actions.

One thing that doesn't appear to be working is the device state and icon aren't updating in the device list. I'm still trying to troubleshoot that.

My main question is: am I taking the correct approach here by creating a custom device? I don't see an "alarm" device in the Indigo Object Model.

Seems like a reasonable approach. There's a fairly short list of "native" Indigo device types. Alarm would be nice. But "Door" and "Shade" would be even more useful.

You should change the name of the state, though. "sensorValue" is used for standard devices that have an analog state value. You might be confusing the plugin base code. Try something like:

Code: Select all

   <Device type="custom" id="myCustomAlarmType">
      <Name>Custom Alarm State</Name>
      <ConfigUI>
         <Field id="address" type="textfield" defaultValue="192.168.0.30">
            <Label>IP Address:</Label>
         </Field>
         <Field id="initialValueObtained" type="checkbox" hidden="true" defaultValue="true"/>
         <Field id="tag" type="textfield" defaultValue="a">
            <Label>Tag:</Label>
         </Field>
      </ConfigUI>
      <States>
         <State id="alarmState">
            <ValueType>
               <List>
                  <Option value="stay">Stay Arm</Option>
                  <Option value="away">Away Arm</Option>
                  <Option value="night">Night Arm</Option>
                  <Option value="disarm">Disarm</Option>
               </List>
            </ValueType>
            <TriggerLabel>Alarm State Changed</TriggerLabel>
                <TriggerLabelPrefix>Alarm Changed to</TriggerLabelPrefix>
            <ControlPageLabel>Alarm State</ControlPageLabel>
                <ControlPageLabelPrefix>Alarm state is</ControlPageLabelPrefix>
         </State>
      </States>
       <UiDisplayStateId>alarmState</UiDisplayStateId>
   </Device>


How are you updating the state in the plugin code? Should be something like:

Code: Select all

                        dev.updateStateOnServer(key="alarmState", value=state)


Thanks Joe. Getting away from the "sensorValue" name and moving to "alarmState" seems to have done the trick in that I'm now seeing the state and the icon showing up in the device list.

Since my post, I did some more tinkering. Because this is a custom device, I'm relegated to actions to change the state and cannot manipulate it directly (like say, a switch).

That being the case, I don't think the HomeKit Bridge plugin is going to work because there is no way to tie the alarm device in HomeKit to an action (AFAIK).

Wouldn't that require some native "first class" support for Alarm types, as you indicate?

Thanks Joe. Getting away from the "sensorValue" name and moving to "alarmState" seems to have done the trick in that I'm now seeing the state and the icon showing up in the device list.

Since my post, I did some more tinkering. Because this is a custom device, I'm relegated to actions to change the state and cannot manipulate it directly (like say, a switch).

That being the case, I don't think the HomeKit Bridge plugin is going to work because there is no way to tie the alarm device in HomeKit to an action (AFAIK).

Wouldn't that require some native "first class" support for Alarm types, as you indicate?

Maybe. Depends on how the Bridge handles that device type. If C4W specified a set of actions and states that HKB was looking for, it's possible. IOW, define a "standard" for alarm types. But since I have no experience with how HomeKit handles alarms in the first place, I don't know what that would look like.

Yep. I'm going to get with him and see what we can work up. Thanks again!

Now that I'm toying with things more, I think it may make more sense to keep the alarm state as a variable in Indigo *IF* the HomeKit Bridge plugin can be extended to interact with a variable as the alarm state.

I'm also using your UDP listener to parse the JSON that comes from the Arduino when the door opens. This is cool because I don't have to put the alarm logic in the Arduino itself. Instead I can model the alarm logic in Python scripts and have Indigo manage it.

You should be able to use a Virtual Device based on the variable. Really depends on what HKB needs from the device.


Sent from my iPhone using Tapatalk

Thanks. I started playing around with virtual devices and action groups. HomeKit's security states are multi-valued: 0=stay arm, 1=away arm, 2=night arm, 3=disarm. Since it's not a strictly on/off system, it doesn't quite fit nicely in a virtual on/off device.

An update on this thread.

I managed to create four Action Group items:

1. Set the Security System to Stay
2. Set the Security System to Away
3. Set the Securt to Night
4. Disarm the Alarm

Each of these simply sets a variable in my variable list called 'alarmState' to 0, 1, 2, and 3, respectively.

In HomeKit Bridge, I added these four Action groups as Switches with HomeKit Names:

1. Arm to Stay
2. Arm to Away
3. Arm to Night
4. Disarm

So I can say "Hey Siri, arm to stay" and the security system is armed in stay mode. Or I can say "Hey Siri, disarm" and the security system is disarmed.

Of course, since this is a switch, Siri responds with "Ok, the arm for night is on" or "Ok, the disarm is on". And I can't query Siri to determine the state of the alarm.

So work continues to see how to fully integrate the HomeKit security system feature.