Sporadic "no response" in HomeKit #15
Comments
|
I've been getting "No response" messages too. In my case, it seems like the "No Response" is only happening when the system is armed. It will work fine when disarmed, with the alarm accessory correctly showing the disarmed state (and the individual sensors all correctly updating when faulted). If I use the Home app to arm the system to "Home", it will correctly arm the system to STAY and initially show the updated state, but eventually the Alarm System accessory icon will show "No response." The Homebridge log doesn't indicate any issue and continues to display messages received from the Alarm system. I can't use the Home app to disarm the system, but as soon as I disarm it (e.g., using a physical keypad or the Web App), the Alarm System accessory becomes responsive again in HomeKit. Is that similar to what you are seeing? I'm running Homebridge on HOOBS (latest version 3.2.3) with version 3.1.5 of this Alarmdecoder platform plugin. This is the kind of message I'm seeing in the logs when the Alarm Homekit accessory is non-responsive: 5/5/2020, 9:10:14 PM [Alarm System] {"last_message_received":"[00100001000000003A--],008,[f70600ff1008008c08020000000000],"ARMED STAY "","panel_alarming":false,"panel_armed":false,"panel_armed_stay":true,"panel_battery_trouble":false,"panel_bypassed":{},"panel_chime":false,"panel_entry_delay_off":false,"panel_exit":false,"panel_fire_detected":false,"panel_panicked":false,"panel_perimeter_only":false,"panel_powered":true,"panel_ready":false,"panel_relay_status":[],"panel_type":"ADEMCO","panel_zones_faulted":[]} And here's what it shows when it is disarmed and responsive: 5/5/2020, 9:03:07 PM [Alarm System] {"last_message_received":"[10000001000000003A--],008,[f70600ff1008001c08020000000000],"DISARMED Ready to Arm "","panel_alarming":false,"panel_armed":false,"panel_armed_stay":false,"panel_battery_trouble":false,"panel_bypassed":{},"panel_chime":false,"panel_entry_delay_off":false,"panel_exit":false,"panel_fire_detected":false,"panel_panicked":false,"panel_perimeter_only":false,"panel_powered":true,"panel_ready":true,"panel_relay_status":[],"panel_type":"ADEMCO","panel_zones_faulted":[]} I'll keep testing and see if I can figure anything else out, but I'm not sure how best to go about debugging this. |
|
No, I have not found any correlation that would indicate what is going on.
During the CV, I tend to arm it when going to bed, and disarm it when I
first need to go out of the home. I've seen it both at night and in the
morning.
Jon Thompson
Evolve
515 360 1351
www.dmevolve.com
…On Wed, May 6, 2020 at 2:07 PM Antoine McNamara ***@***.***> wrote:
I've been getting "No response" messages too.
In my case, it seems like the "No Response" is only happening when the
system is armed. It will work fine when disarmed, with the alarm accessory
correctly showing the disarmed state (and the individual sensors all
correctly updating when faulted).
If I use the Home app to arm the system to "Home", it will correctly arm
the system to STAY and initially show the updated state, but eventually the
Alarm System accessory icon will show "No response." The Homebridge log
doesn't indicate any issue and continues to display messages received from
the Alarm system. I can't use the Home app to disarm the system, but as
soon as I disarm it (e.g., using a physical keypad or the Web App), the
Alarm System accessory becomes responsive again in HomeKit.
Is that similar to what you are seeing?
I'm running Homebridge on HOOBS (latest version 3.2.3) with version 3.1.5
of this Alarmdecoder platform plugin.
This is the kind of message I'm seeing in the logs when the Alarm Homekit
accessory is non-responsive:
5/5/2020, 9:10:14 PM [Alarm System]
{"last_message_received":"[00100001000000003A--],008,[f70600ff1008008c08020000000000],"ARMED
*STAY*
"","panel_alarming":false,"panel_armed":false,"panel_armed_stay":true,"panel_battery_trouble":false,"panel_bypassed":{},"panel_chime":false,"panel_entry_delay_off":false,"panel_exit":false,"panel_fire_detected":false,"panel_panicked":false,"panel_perimeter_only":false,"panel_powered":true,"panel_ready":false,"panel_relay_status":[],"panel_type":"ADEMCO","panel_zones_faulted":[]}
And here's what it shows when it is disarmed and responsive:
5/5/2020, 9:03:07 PM [Alarm System]
{"last_message_received":"[10000001000000003A--],008,[f70600ff1008001c08020000000000],"
*DISARMED* Ready to Arm
"","panel_alarming":false,"panel_armed":false,"panel_armed_stay":false,"panel_battery_trouble":false,"panel_bypassed":{},"panel_chime":false,"panel_entry_delay_off":false,"panel_exit":false,"panel_fire_detected":false,"panel_panicked":false,"panel_perimeter_only":false,"panel_powered":true,"panel_ready":true,"panel_relay_status":[],"panel_type":"ADEMCO","panel_zones_faulted":[]}
I'll keep testing and see if I can figure anything else out, but I'm not
sure how best to go about debugging this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCJHKPKURNVCBCC4KN3ML3RQGYNNANCNFSM4MZ5XNCA>
.
|
|
I haven't seen that issue. I have struggled from time-to-time with my network seemingly losing the ability to resolve mDNS names. I just moved everything to static DNS entries and that seemed to have sorted that problem (that and a router reboot every once-in-awhile). I wonder with all the versioning whether there's something in the accessories or persist cache that's causing the problem. Could you spin up a container with a new homebridge and see if that helps? (or nuke accessories/persist from homebridge) |
|
Mine is running on the raspberry pi that has the alarmdecoder board on it, so not sure if I can spin up a container or not. Either way, It was the first module I installed in homebridge, and has had this behavior since installation at least a month ago. I just didn’t bring it up because I thought it was homebridge not communicating. However, since then I’ve added control for my thermostat, which does not disconnect when AD is disconnected, so it clearly is not a Pi issue, nor a homebridge one.
…--
Jon Thompson
Evolve
515 360 1351
On May 6, 2020, at 2:35 PM, aficustree ***@***.***> wrote:
I haven't seen that issue. I have struggled from time-to-time with my network seemingly losing the ability to resolve mDNS names. I just moved everything to static DNS entries and that seemed to have sorted that problem (that and a router reboot every once-in-awhile).
I wonder with all the versioning whether there's something in the accessories or persist cache that's causing the problem. Could you spin up a container with a new homebridge and see if that helps? (or nuke accessories/persist from homebridge)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
This thread has some possible things to try and resolve this issue. I'll update when it occurs again and am able to test some of them. Particularly, the idea that the Pi processors are overloaded sounds particularly interesting, given that I haven't found any pattern to when it is offline and when it isn't. homebridge/homebridge#1801 |
|
I just tried wiping the persist and accessories cache on my home bridge installation and re-adding just this plugin and it still has the same behavior. And I have static IP addresses and ports explicitly specified in both directions between the home bridge plugin and the Alarmdecoder web app, so I don't think it's an mDNS issue (unless I'm misunderstanding). Anyway, it sounds like I've having a different issue than what was specified above since mine is perfectly reproducible and happens whenever the alarm system is armed to Home / Stay. I'll try it out on a new home bridge installation. If I can't figure out what is going on, I'll start a separate issue. |
|
Closing this, as it is the same as #17 |
I'm not sure what's going on, but occasionally I will get a "not connected" on the icon for my Ademco->AlarmDecoder Board/Raspberry Pi->Alarmdecoder software->homebridge-alarmdecoder-platform->homebridge.
Troubleshooting has been:
So, the only thing that could be causing the "not communicating" is something going on with the homebridge-alarmdecoder-platform software. However, I don't see anything in the logs to tell me there is anything wrong, and rebooting homebridge doesn't seem to make any difference.
At one point I thought it was my use of IPv6 on my network, but it's not that, as this would keep the pi and/or homebridge itself from communicating.
Anyhow, this can go on for hours, and really makes it difficult to be able to trust my alarm system for automations.
The text was updated successfully, but these errors were encountered: