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)