Closed nlakamsany closed 7 years ago
@nlakamsany As I don't have peripheral accessories tied to Alarm.com, I am unable to test any of that functionality, which was originally implemented by @yungsters. Your issue may be related to #42, but I can't be certain. Has anyone else experienced this?
@nlakamsany Just to be clear, have you cloned all of the necessary WrapAPI calls, as mentioned in the readme?
Yes and I just verified. Also, I notice that when I open home app, it takes a while to update Schlage lock and alarmdotcom status saying that it is updating but my hue is up to date. Is there an issue on my end? This happens all the time. Just wondering, if a poll can be added to check every couple of seconds and cache this in the cloud?
@nlakamsany It sounds like you're describing something similar to #32.
Thank You @bryanbartow ! So, I am curios to know how do you arm your alarm when you leave your house as it takes time to get the status in home app?
@nlakamsany It takes less than 2 seconds, on average, for the Home app to get the status of my system. I just open the app and arm the system or use an automation. Maybe I'm missing something from your question?
i think what @nlakamsany is asking is if you exclusively arm/disarm via home kit or if you also use your physical panel.
The issue #32 will allow the state to update and notify/trigger closer to realtime (within a few seconds depending on polling interval).
I think the other issue described here is how opening the Home app puts all homebridge devices into an 'Updating' state, before the current actual state is reflected and displayed. I think this might be an issue with home bridge itself though not caching current state properly. Or it may be that the alarmdotcom plugin needs to cache for > 5000ms.
@amitgandhinz Maybe, although I'm not sure how me using my physical panel or not is relevant. I don't have any "proper" HomeKit devices, so I don't know how they operate, but I'd have to guess that the initial update of accessories when opening the Home app happens regardless. Unless the iOS device is acting as a server/cache to store accessory state, I don't see how else it could work.
@amitgandhinz - My question was about using arm/disarm via homekit. I feel it takes longer than using alarm.com mobile app. Just wanted to make sure that I am not the only experiencing this issue. For the third question - I do not see this issue with Hue lights but I do see it with Schlage sense lock which directly works with Homekit. So, my guess is probably time for caching and re-polling it continuously as in #32.
Thanks @bryanbartow for all your hard work.
@nlakamsany Back to your original question about the light(s), can you confirm that you are experiencing the same issue as described in #42? I'd like to close this issue if it's a duplicate.
Yes, it is the same issue.
On Feb 27, 2017, at 9:34 PM, Bryan Bartow notifications@github.com wrote:
@nlakamsany Back to your original question about the light(s), can you confirm that you are experiencing the same issue as described in #42? I'd like to close this issue if it's a duplicate.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I have added all the api's yesterday and security panel is working fine on home app. I just added a light to the panel and changed lights to true but I cannot see it in home app. Can you please let me know if I am missing something here.