-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DSC Alarm Panel in Home.app doesn't notice if arming attempt errors #87
Comments
How coincidental, i noticed that last night and was going to report it this morning. (So confirmed from my side of things) |
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. |
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. |
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? |
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. |
Fair enough. So would access to my system help at all? |
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 ;) |
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. |
Ok I’m gonna make myself a cuppa tea and do this now. |
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) |
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. |
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.
|
* **NOTE** As stated earlier, the entire HomeKit engine is being optimized and rewritten for various reasons. There is a new plugin configuration option that allows you to revert to the previous method if the new method is causing problem, but this is on a release-by-release basis, meaning that only changes in **this** release will roll back to using the old methods, the next release will not be able to roll back anything from this release. The functions impacted will be noted in the release notes as 'Library Change'. Please report any issues that are caused by the new library that are resolved by returning to the old methods. * Added error trapping around building the camera configuration in case there's an odd setup that may cause the camera build to fail it will not impact the rest of the homekit devices * Added new action under device actions to [restart an individual server](https://github.com/Colorado4Wheeler/HomeKit-Bridge/wiki/Actions# restart-accessory-server) * Added new action in the action root to [restart all running servers](https://github.com/Colorado4Wheeler/HomeKit-Bridge/wiki/Actions #restart-all-accessory-servers) * Added new action under device actions to [force a HomeKit refresh for a device](https://github.com/Colorado4Wheeler/HomeKit-Bridge/wiki/Actions# force-homekit-refresh) - this may help with [Issue #87](#87) * Added new action in the action root to [force a HomeKit refresh for all devices on a server](https://github.com/Colorado4Wheeler/HomeKit-Bridge/wiki/Actions# force-homekit-refresh-on-all-items) * Library Change: Added minimum and maximum values to the API payload so Homebridge can dynamically change the ranges as needed - particularly in situations where the built-in ranges were incorrect, such as temperature values that couldn't go below 50F or above 100F. * Library Change: Optimized API payload processing method, API calls will only return what Homebridge wants with no extra fields and does it far more efficiently * Library Change: Moved API payload processing to new factory package * Library Change: Experimental change to not wait for commands to run - this may be restored in the next release but I believe waiting is unnecessary because HomeKit will be updated when the command completes anyway, the benefit of this is faster response (and if you use slow devices like curtain controls it will prevent Siri from saying 'some of your devices are not responding') * Library Change: Started adding the underlying structure to test the _possibility_ of using Indigo variables as HomeKit devices * Library Change: Cache HomeKit devices and update dynamically, improved API performance by 600%
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. The stay/away arming is handled separately: |
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. |
In the scenario where arming the system shows an error like this:
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.
The text was updated successfully, but these errors were encountered: