Add Siren Support in device sorting by Insteon Type and NodeDefID

[shbatm]

While debugging #72, identified that Insteon Sirens do not have the proper support in the newer sorting mechanisms.

DevTypeIds:
SirenArm
SirenAlert
Siren_ADV

Insteon Type: 7.30.70.0

Subnodes:
.1 Siren Trigger Home
.2 Siren Arm Home
.3 Siren Trigger Away
.4 Siren Arm Away
.5 Siren Trigger Both
.6 Siren Arm Both

_Originated from @derekatkins in #72

@derekatkins, I don't have a siren -- are these sorting properly for you now? What can you do with each subnode?

If you can actually control them directly, they can be added as a switch, if they just report a status, they should be a binary sensor.

[derekatkins]

I don't use the sirens directly from HA; I have scenes set up in the ISY so that I can send one command and control all of them.

Where should I look for the sorting? If I look at the Configuration -> Entities page, yes, they sort in order. (I didn't know they didn't sort in order before). Right now the Names are XX.YY.ZZ.1 Siren Trigger Home, XX.YY.ZZ.2 Siren Arm Home, XX.YY.ZZ.3 Siren Trigger Away, ... and are listed in that order in the Entities page.

But yes, you can send On/Off/Fast_On/Fast_Off to those entities in order to Arm/Disarm/Trigger the alarms, so those should probably be switch and not sensor objects. To Untrigger (turn off) the siren I think you need to send an Off/Fast_Off to the ARM target -- sending an Off to the Trigger target didn't seem to do anything, but I cannot test that right now (school is in session).

Thinking about this a bit more -- it would be nice if there were some way to show the "armed" status of the siren. I don't know if the Arm targets actually report the current status or not. There isn't anything visible in the ISY about it, except in the primary .1 (Trigger Home) node.

[shbatm]

Thanks for the info. I should have clarified: "sorting" refers to the methods that this integration uses to figure out what an ISY device is (binary_sensor, switch, light, lock, etc.).

I was curious if they were being labelled as switches when they should be binary_sensors, etc. In general, if you can control them with an ON/OFF command = switch, if they just report their status = binary_sensor. So yeah, looks like at least the "arm" should be switches (for now; these could eventually be added as an alarm_control_panel), the "trigger" could either be a switch or a service call.

The statuses are blank in what you sent me, but that could also be if they haven't been updated/triggered since the last ISY restart. You can always trigger one (after school) and see if the status is reported in the ISY. If so, we can set them up like motion/leak sensors, with an assumed initial state of "off".

Just FYI for anyone curious: there are 5 methods used, in order of most accurate to S.W.A.G.:

1. NodeDefID - ISYv5's Node Definition ID tag, most accurate for non-Z-Wave/NodeServer nodes
2. Insteon Device Types - pretty accurate for all Insteon devices, but subnodes cause kinks (e.g. FanLinc with a light and fan)
3. Z-Wave Device Categories - pretty accurate for all Z-Wave devices. This is what was not being triggered originally in this issue
4. Unit of Measurement ID - Guess what type based on the unit of measurement (e.g. if the UOM matches the climate operation modes, its probably a thermostat)
5. Unit of Measurement List - ISYv4 would use the list of possible options for the UOM, so "on/off/%" you could assume it was a device capable of dimming, but didn't know if it was something you could control or not, so it guessed switch.

[derekatkins]

My understanding is that currently nodes .2 through .6 are responders only. You can send on/off commands to them but there is no queriable data from them. All the "status" data is in .1.
I know that Arm takes both On/Off and FastOn -- It may take a FastOff but I haven't been able to verify that. I know that Triggers take On and possibly FastOn; I don't know if they take Off or FastOff.

[shbatm]

Moved to automicus/PyISY#270