We’ve been unable to replicate except by the standard reasons for system status announcement, which all include either panel reboot or interacting with the panel locally.
I am talking with ADC to see if there is a way to get additional info from the panel during these events.
Alright, the enhanced data capture won’t tell us much as it is more specific to Z-wave rules as I suspected, but I am expecting word from ADC engineers on the possible causes of a non-manually invoked reboot.
One thing to check is your Radio Modem Network Failure time. As a test could you set Q23 to 5?
This will be an extremely short comm check interval and if trouble occurs shortly before a reboot it will tell me I am looking in the right direction currently with possible module causes.
I am not sure what this does or exactly what you are talking about in terms of your “direction”? But I changed Q23 to 5
Please let me know when I can change it back to 255
This change will provide extremely sensitive cell connection status, so you are much more likely to see Radio Modem Network Failure. All evidence points to a panel reboot, and we want to see if there is any correlation with signalling.
Do I need to keep this q23 at 5 or can I change it back to 255? Not sure if it matters. Did you gain any insight so far from having this changed? Or will it only be helpful if the problem occurs again.
The problem has not occurred again since the last posting which would tend to suggest this is not a hardware issue?
Or will it only be helpful if the problem occurs again.
This. It will only provide proof or denial of suspected cause if the issue occurs again.
This issue has not re-occured since the last posting of it occurring on this thread. Don’t you think this would be an indicator that this is an issue with ADC and not my hardware?
Don’t you think this would be an indicator that this is an issue with ADC and not my hardware?
No, all evidence seen pretty much rules that out. Based on all signals we’ve seen it appears to have had a local cause. It is good to hear that the issue has stopped.
Aside from intermittent power issues (which are likely impossible given the back-up battery), on board communication between panel and module and firmware glitches are being looked into, but we’ve not been able to recreate.
If you notice it again, please let us know so we can check signaling.
This happened again last night after a long stretch of many days without it happening. Same time as well around 2:45 AM.
I had open windows and doors that were bypassed and the alarm was not armed as I had guests over. The open windows and door “reannounced” themselves indicating to me that the panel power cycled itself.
I am hoping with the change in q23 you are able to determine what is going on here.
Looking into signaling now, although there was not the expected error preceding the event (made more sensitive by the Q change).
We are forwarding the info to ADC as well to go over.
The open windows and door “reannounced” themselves indicating to me that the panel power cycled itself.
Did the panel announce sensor status around the same time (2:45ish) or was it later? If the system was not armed I would expect open sensors to re-announce at their normal supervision interval, long after the panel would boot up saying “System Disarmed, Ready to Arm”
The sensor status announced later. its in the logs on my account. 15 minutes or so… This is typical though. For example if you have a door open and cycle your alarm panel manually by unplugging it, it will initially show all doors closed. Gradually and one by one, it will announce that they are open.
Again, the fact that this happens at the same time (panel cycling) plus the fact that it has not happened for so many days until last night, would seem to indicate this is not a hardware defect.
Again, the fact that this happens at the same time (panel cycling) plus the fact that it has not happened for so many days until last night, would seem to indicate this is not a hardware defect.
Whether hardware or software based, no remote commands are affecting a power cycle, so as before this is certainly a local cause.
Have you noticed the issue on two separate firmware versions, or has it always been the current version?
It’s a recent issue. I am not sure but I think it’s occurring on the latest firmware. I have a go bridge so you can try and push the latest firmware if there is a more current one than the one I have. I am not home so I am unsure of the version I have. I think it’s 1.14.
1.14 is the latest OTA available version.
Looking back at the history it looks like the last update was an OTA, and it happened prior to the start of this thread, so the issue has only been occurring on the current firmware.
We will try to narrow it down and discuss with 2GIG.
Can I change q23 back to the default setting?
Yes, you can change Q23.
Currently awaiting follow up from 2GIG. So far the suggestions have been to replace the module as that is the most likely culprit, but if the panel only started doing this on 1.14, it could be the panel itself, or it could be an issue caused by or exacerbated by 1.14.
Warren,
I am not trying to be combative here, but I have been through a similar issue that took about a year to resolve. ADC told me it was a “local issue” as well. I had countless calls with them and emails. There were even a couple of threads on it here at Surety https://suretyhome.com/forums/topic/lights-dont-come-on-after-daylight-savings-change/
Finally they realized it was on their end and I have not had the Daylight Savings problem again.
If there was a hardware issue, I doubt it would be happening at the same time. I also feel the time spread between occurrences to point to a problem outside of hardware. If hardware were failing, it would become more frequent (logically)
Now they are saying to replace the module. I am assuming this is the GC2? If so will they refund my money if the problem occurs with the new panel? Also due to their late rollout of firware fixes and secondary panels for the GC3, this makes this change a highly undesirable option. If I was going to change, I would want to go with the GC3 as most people would, but its not ready yet (per your post on missing comparability)
I realize one issue is with 2GIG and the other is with ADC, but I am not following the logic of how this is not an ADC issue due to the issue occurring at the same time, history of their responses that eventually point to ADC as the issue, and the infrequency of occurrence.
I realize one issue is with 2GIG and the other is with ADC, but I am not following the logic of how this is not an ADC issue due to the issue occurring at the same time, history of their responses that eventually point to ADC as the issue, and the infrequency of occurrence.
There is no link between the two issues so I would urge separation.
If there was a hardware issue, I doubt it would be happening at the same time.
We can’t say there is a definitive hardware issue, but we cannot rule that out based on the information available so far. The only thing we can completely rule out in fact is an acute remote cause.
If I had to guess, I would agree with the above statement that the firmware version played a role in the cause. Since it is not a common issue and has not been replicated, there is something specific to the system which lends to the issue.
Also due to their late rollout of firware fixes and secondary panels for the GC3, this makes this change a highly undesirable option
While we are also very eager for the firmware effects, the timeline is fairly standard for the manufacturer, and secondary panels have been released roughly a year or more after the primary panel for almost every system. If January is accurate, that’s actually a little quicker than precedent.
Unfortunately I realize that makes the GC3 a difficult replacement now if you have components which require an update. I do wish they had verified complete Z-wave compatibility, but similarly, there is no precedent for that with any other system.
but I am not following the logic of how this is not an ADC issue due to the issue occurring at the same time, history of their responses that eventually point to ADC as the issue, and the infrequency of occurrence.
The issue occurring at a similar time intermittently actually very strongly suggests a panel process is at fault.
I presume you mean the DST issue regarding the history. While I do not have specific details regarding what developers needed to change, the issue was not universal. It was an issue that appeared to largely affect older systems. (Simon panels predominantly, and some older model Go!Control panels). I’m not sure the resolution was the same between the different panels (it very likely was not), but most likely the rules created needed to be finely adjusted to account for hardware differences.
Unfortunately the infrequency of this makes it harder to track, as there may be things you could test or observe that may help if you had a realistic expectation of when it would next happen. Going off of the time of occurrence and knowing it is resulting in a reboot, it’s likely a panel software process error.
2GIG suggested replacing the communication module as a test at first, but I would not suggest that myself yet. We are still discussing the issue with the manufacturer. I think the post above was just meant as an update.
This occurred again last night, right around the exact same time.
is it possible to resend the latest firmware update via my Go Bridge? Maybe we can try that? Maybe the firmware did not get written correctly the first time?
Any updates from ADC?
Any updates from ADC?
We’ll follow up to see if there is anything new or any other similar reports recently.
is it possible to resend the latest firmware update via my Go Bridge? Maybe we can try that? Maybe the firmware did not get written correctly the first time?
No, the same firmware cannot be sent OTA. Flashing locally via update cable would be an option.
It is possible that firmware is causing the issue, considering it was not noticed until after the OTA push. It is probably a good next step. 1.16 firmware is available from 2GIG (we’ve not added it yet to our firmware archive as it does not affect ADC at all or add any usable features, just adds support for other back-end services, but I can get it added should you want to try.)