Closed rexy666 closed 5 years ago
Not really! I am also using a DIY solution and setting the target state in some cases results in an immediate change of the current state as well (disarm and stay for example). In this case what I see on my phone is that when I change the state in the Home app, it immediately shows the state as changed, skipping the "arming / disarming" period.
Im seeing the same thing. As an interim I just reduced the polling interval to 5 seconds as this particular system is not that busy at this stage of deployment. Seems to mitigate the problem to a reasonable level.
I'll investigate this again but I suppose I'd have to read up more on HomeKit docs. The problem is that when you set the targetState to ARMED, then it's the target state that was changed. I don't know of a way of communicating it back to HomeKit that not only did the action succeed, but there was also a change in the state of the current state. I could try pulling the current state right after a target state change (without waiting for the timer), it may or may not work... I'll report my findings here.
I gave it a try and it seems to be working! I pushed a new version to the develop branch, can you give it a spin? The change you should be seeing is that once you set the state of the system to AWAY (or whatever you like) the status should update almost immediately. There is still a short delay (100ms or so) but this is due to the fact that there are multiple network requests fired after each other.
Thanks for the quick response. It looks good to me :)
I tested it on both rpi and windows 10 homebridge platforms and no issues on either!!!!
Wish my code was that predictable.
Glenn Christiansen
On May 12, 2019, at 15:34, codetwice notifications@github.com wrote:
I gave it a try and it seems to be working! I pushed a new version to the develop branch, can you give it a spin? The change you should be seeing is that once you set the state of the system to AWAY (or whatever you like) the status should update almost immediately. There is still a short delay (100ms or so) but this is due to the fact that there are multiple network requests fired after each other.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Excellent, thanks for trying! I'm merging the change to the master branch and pushing a new version to npm.
I'm trying to link my DYI alarm system with homekit using your plugin, everything seems to work perfect except for the fact than when changing states, it will be stuck in a constant spinning circle saying "ARMING" or "DISARMING" until the next polling interval comes in and reads the status again from the server. is this a normal behavior?