DSC Alarm Panel in Home.app doesn't notice if arming attempt errors

[blysik]

In the scenario where arming the system shows an error like this:

 DSC Alarm                       Arming Alarm in Stay Mode. (Partition 1 'Default')
 DSC Alarm Error                 IT-100/Envisalink Error (024): API System Not Ready to Arm (not secure, in delay, or already armed)
DSC Alarm Error                 Received system error after sending command, aborting.

The Home.app arm action just says "Arming..." for a very long time. (I'm still waiting for it to stop.)

The plugin should report back to Homekit that the arming action failed.

[durosity]

How coincidental, i noticed that last night and was going to report it this morning. (So confirmed from my side of things)

[Colorado4Wheeler]

I'm assuming this is no change in how it worked before since DSC is only somewhat supported in the plugin. With complications coming out I'm not going to work on this issue at the moment since I would have to re-do any work I did in a few releases anyway. If complications work without any major issues then it should be fairly simple to get all these various plugin devices operational.

[Colorado4Wheeler]

Ok, since complications have been pulled for the time being and I'm back to square one (well since 0.20.0 anyway), and since I don't have a DSC, I need someone to explain to me precisely what needs to change here.

For me to best try to support this I'll need to know what state changes to what value during each operation (disarm, stay, away, tripped). If it gets stuck saying 'arming' then that means it's not getting the proper response back from the plugin and that's probably because I don't really know what I'm looking for.

[durosity]

Well realistically if the change doesn’t happen it needs to go back to its original state. If you’d like you could remote onto my system and I could create some dummy events for you to monitor?

[Colorado4Wheeler]

Yes, and that is what I expect will happen if we fix this part. To explain: if HomeKit asks the plugin to Arm then it needs a reply back that it was armed or that it failed. The failed part is probably too complicated for me to write in at the moment given the very basic DSC support I've added in, but it's OK because if it doesn't work then within a second or two it will report back that it failed - however if I don't monitor the proper state and HomeKit simply beachballs waiting for a reply then it will never get the callback a second or two later because it's "busy". Make sense?

Granted, I can write a much more robust integration for DSC and it wouldn't be all that difficult but given that I'm going back to the drawing board with complications I don't want to add bulk to the plugin because I'll end up moving or scrapping it in the next couple of weeks anyway.

[durosity]

Fair enough. So would access to my system help at all?

[Colorado4Wheeler]

Maybe but I don't want to get that deep into this right now. When you get a chance just expand the UI to show you the states and note the state changes as you experiment with the system. It's OK if you want to give me all the various states that may not change, just make note of the states, hit arm, make note of the states, etc. It's more of a homework assignment rather than a teacher led demonstration ;)

[Colorado4Wheeler]

I'm more interested in getting the motion sensor question I asked the other issue so I can release an update. If you are able to provide me the information for THIS one too, great, otherwise it'll make it to 0.20.2. No big deal, but it's been a week and I want to get an update out that resolves a couple annoyances for people.

[durosity]

Ok I’m gonna make myself a cuppa tea and do this now.

[durosity]

Isn’t she a peach?

[durosity]

OK no states change in the DSC alarm panel in indigo if there’s a failure to arm. However the plugin knows that it has failed as there’s a trigger option for the plugin called “Alarm failed to arm” (which I use to send a Pushover notification for). Perhaps something could be used to subscribe to states for that.. or @monstergerm might be able to add an extra state into the alarm panel device for failedtoarm: true (which would need to reset itself after a a few seconds else you’d just end up with the same issue again even if the fault had been cleared)

[Monstergerm]

I took a quick look at this. The "failed to arm" notification is not really a state change. It is an API notification from the alarm panel that something went wrong. It does not tell you which partition is affected either. So, I am not sure adding a new state that would have to apply to all partitions (affected or not affected) does make sense. Also, there is a whole bunch of those API notifications, all of which would need to be captured. For instance sending a disarm command to an already disarmed partition will presumably also make HomeKit actions being stuck on "disarming".

[Colorado4Wheeler]

I think it may be one of those things that once we get a bit further into the plugin, closer to release and into complications that this may be easier to deal with. It isn’t difficult for me to create listeners or triggers or actions that allow the user to do updates based on the action of another device or plugin but it’s not there yet.

[durosity]

I wasn’t sure if I should put this as a new issue or on this one as it’s linked. I had an issue today where the panel tripped and I couldn’t disarm it in Home because it already believed it was off. I’m guessing it was because the state had changed from away to tripped the plugin was stating to the alarm it was off as it was no longer in stay or away modes.. but of course that then locks out the ability to turn the damn thing off!

[Monstergerm]

I am not sure about this one. I think this is a new issue. The plugin captures zone violations and alarm panel(s) getting tripped. This is where Indigo is so much better since you can capture different scenarios including panic, fire, duress etc. I don't see why HomeKit is reporting the state as Off since the DSC panel will stay armed even if an alarm is running and after the bell timeout it will continue being armed. The plugin changes the alarm panel state from "armed" to "tripped" and presumably back to "armed" after the bell timeout (never tested this). So HomeKit should read "tripped" as still being armed. These are the possible alarm panel states for a DSC indigo device: kAlarmStateDisarmed = u'disarmed' kAlarmStateExitDelay = u'exitDelay' kAlarmStateArmed = u'armed' kAlarmStateEntryDelay = u'entryDelay' kAlarmStateTripped = u'tripped'

The stay/away arming is handled separately: kAlarmArmedStateStay = u'stay' kAlarmArmedStateAway = u'away'

[joshsnelling]

I've just opened PR #135 that could fix both of the problems described in this issue. I didn't test for these cases explicitly, but I faced similar problems that ultimately were fixed by the changes I made in the PR.