A standard Panel Tamper was reporting in ADC as unresolved.
Can you provide a picture of this alert, along with a picture of the modifications that were made to the panel itself?
Pictures attached. I had the panel apart earlier today and did have a standard panel tamper, which is now showing resolved on my end. Now only the siren tamper alert is persisting.
Sorry, i should have clarified, can you take a picture of the internals, without the back plate.
Did the trouble alert occur after physically altering the panel case? Did you make any programming changes?
To troubleshoot, physically power down the system by unplugging the transformer from its outlet, then unplug the internal battery. Unplug the siren wires (red and black pair with white connector) and reinsert them firmly in place.
Power up the panel, battery first followed by power supply. Does this error come back?
Additionally, you can run both antenna from the 4g LTE out the back of the panel and mount the antennas inside the wall, one doesnt need to go into the antenna housing on the side of the panel.
I went through the check you recommended of full power down, unplug and reseat of the siren connector, re-powered, and the error came back. I then accomplished the check again with the antenna routed out the back of the panel (both out the back), and the error still persists.
I can’t say with certainty that the error wasn’t there before modifying the plastic last night. The panel had been stored away for a couple of years after a recent move until I got it out last week and learned in a few sensors. I had been programming in the sensors while the panel was removed from its backplate and I know I was ignoring the panel tamper alert as it had been expected. Then, last night I signed up for service with surety, updated the panel firmware to 1.19.3.1. and installed a new LTE communicator, and went through the setup steps.
Here are a few closeups of the modified plastic - it doesn’t look like there are any wires or active components in this area that could have been easily bumped, cut, etc. I suspect that the issue is unrelated to the cutting of the plastic in this area.
Thank you for that informaiton. I think we have come across this trouble condition one other time but no resolution was documented.
I have reached out to 2GIG to see what steps can be taken to resolve, if any. I will follow up here as soon as I have that information.
Does the siren work?
Yes, the siren works.
I really appreciate your prompt replies and efforts to help me resolve this issue! I want to point out that I DO have access to a second GC2 panel that I will consider switching to if it seems that there will not be a quick or simple fix to this problem. I initially wanted to avoid that as I’d like to avoid relearning all of the sensors into a second panel. Couple of questions about moving to a new panel:
- Is there a way to save the current sensor programming information on alarm.com or in a config file on my computer that I can use to quickly mirror my current setup onto a replacement panel?
- Is switching to a new panel as simple as powering down my current panel, moving my communicator to the new panel (with same firmware) and powering that one up? Would this be seamless with Surety and alarm.com or do any explicit back-end actions need to be coordinated through and taken by Surety and/or alarm.com?
2GIG states the that Panel Siren Tamper is indicative of hardware failure of the control board itself. Unfortunately, there is not any troubleshooting that can be recommended, replacement is advised.
- Is there a way to save the current sensor programming information on alarm.com or in a config file on my computer that I can use to quickly mirror my current setup onto a replacement panel?
A backup of current sensor programming and users can be run, this can then be applied to another GC2. Would you like me to run a backup now?
The backup restore process can be done during normal business hours we must initiate it… Both panels would need to be completely off (after a backup is run) and the 4G LTE module installed in the new panel. The new panel will need to be at firmware version 1.19+ in order to work with the module, this needs to be done prior to the swap.
Yes, please run a backup now. I am available all day today and hope that we can complete during today’s business hours.
Please advise once complete and I’ll power down units and move the communicator to the replacement panel. Both panels are running 1.19.3.1.
A backup has been run successfully. At this time, make sure there are no sensors or devices programmed into the new GC2 panel (this can cause errors during the resotral process), then disarm and power down both panels comletely power supply first then the internal battery.
Once both panels are off, move the 4G LTE module to the new panel but leave it powered off. Let us know once this is done and we can send the restoral.
All steps completed. Both units powered down. Sensors removed from new unit and communicator moved to new unit.
Commands have been sent at thie time. Power up the new panel completely. Once booted up, wait about 20-30 minutes for restoral commands to take effect. You will know the process is nearing completion when the last of the sensors populates. Wait about 5 minutes after that for Users to populate.
The panel may reboot on its own, signfying completion. Afterwards run a cell test to verify communication.
Then you can add any additional sensors or Z-Wave devices as necesary.
GC2 programming can be found below:
You’re not going to believe this - now the same alert is displayed on the new console (Console: Panel Siren Tamper). This was definitely not occurring on the second/current panel earlier. It seems that there is something in software that was transferred from the old unit to the new, which is driving this alert. Is it possible that one of the zones has residual programming that could be causing this? Any ideas? Is there a way to interrogate each zone for residual programming other than clicking the down arrow on each, which would be very tedious. I only have active programmed devices at zones 01, 02, 03, 06 and 07 - is there a way to globally erase all other zones? If not, is there a way to globally erase ALL zones and I can just reprogram these?
According to 2GIG techs, its a hardware failure issue. We’re in unchartered territory when it comes to seeing this error transfer from one panel to another via software backup/restoral. Based on 2GIGs response, its not something I would expect to see.
There are no options in sensor programming that would cause the Panel Siren Tamper specifically so i could not point to a specific programming selection that would fix the issue.
Deleting sensors would be one by one, or all at once. You can seletct Restore Defaults from the Installer Toolbox to delete all Zones This wont reset firmware but it will change codes and it will default programming choices if you select Console.
The problem seems to be resolved after I restored CONSOLE to default. I did NOT restore zones so I was able to keep the programming you transferred over. It doesn’t seem that it was really a hardware problem and hopefully, this information can help someone in the future. I haven’t yet made any changes on the old panel, and if you want me to look at any particular settings before doing a console reset to default on that one I’ll be happy to look. Could be interesting to know which setting caused the unit to go off into the weeds, if able. Otherwise, I will plan to continue using this unit and reset the other unit to defaults in the near future so I can pass it along to someone who can use it.
Thanks again for your help.
Interesting and thank you for this information. It is possible that there was a software issue that was passed from the old panel to the new via the transfer (as panel settings, users, and sensor programming are all passed).
Let us know if you get a chance to default that other panel. There are no settings in programming that would cause a tamper like that but its possible one of the siren related programming questions was altered previously
I found the problem! Q21 is “Select siren supervision time (0 to 3)”. The old panel, which was still flagging the alert, had “(2) 30 seconds” selected, and the new panel, no alert, has (0) disabled selected. I assume that this setting had been mirrored on the new panel yesterday after the restore when I was seeing the issue on that panel. I’m confused a bit because I only restored defaults to the CONSOLE, but had not defaulted the zones - I would have expected the need to default the zones to clear this setting. In any case, I just changed Q21 to “(0) disabled” on the old panel and the siren tamper alert is no longer occurring. So here’s a case where “Panel Siren Tamper” is NOT a hardware problem, at least not a hardware failure of the panel’s control board as they had stated to you yesterday. Its disappointing that 2GIG did not ask you to check these two settings.
From what I gather, Q21 and Q78 are related to external sirens. According to the article below, Q21 controls the bell output, and Q78 controls the open collector output. I never had an external siren connected to my original panel, so perhaps the setting had been changed by mistake.
https://www.alarmgrid.com/faq/can-i-use-a-wired-siren-with-a-2gig-gocontrol
Interesting, thank you for following up with this. I was able to confirm on a test panel that q21 is the cause. Outside of local changes, not sure how that would have been changed initally on the first panel.