Apologies and another question

I feel guilty coming to the well here so often for help with my Elk but this seems to be the best source that i can find for answers and I appreciate it. 
 
I'll start by saying that I have solved my own problem by restarting the system but that leaves me feeling  that it may return. I resorted to restarting the system because I could find nothing wrong with the system to correct. The symptom was that every time I armed Area 2, after the exit count expired and it completed arming the Elk voice would chime a zone name in Area 1. The only unique thing about that particular chimed zone  is that it is  the first wireless zone in the system (elk 2way).
 
I checked to see that each and every wire was tight with a needle nose plier and I plugged and unplugged all rj-45 plugs. Everything seemed fine. the wiring logic hasn't changed and the system has been working correctly for a month or so just the way it is.
 
Now some background....The symptom appeared immediately after I had powered the system down to move an output on the output expansion board. The output board is powered by a secondary power supply.  I have a wireless door opener wired to the elk output and I needed to lengthen the wire to locate the wireless opener closer to the door motors. When I powered the system back up the errant zone chime appeared. 
 
So my question - Is the Elk control  known to have a bad start now and then? Does it matter if the second power supply is started before or after the Elk control? Do all zones need to be secured before powering up?
 
Any thought? Mike.
 

What are you using for the chime/voice announcements? OUT1? If so, OUT1 does annunciate ALL Area/Zone announcements. Without more information on the system, I'm not sure why it would announce the first wireless zone, but that does seem odd.
 
I assume when you moved the output board (XOVR?) you didn't change it's address.
 
The Elk control should not have any errant starts, but I won't say that it's not possible. I haven't seen any.
 
I prefer that the secondary supply be ON before powering the Elk, but not sure if that is the recommended method. My thoughts is that if all secondary equipment is already powered on, the Elk will be able to recognize those components during it's boot process.
 
Zones should not need to be secure before powering up; Elk shouldn't care about the status of the zones at this point, but rather simply begin to monitor them once booted. Again, I won't claim to be an expert on this, but rather providing my thoughts and logic.

drvnbysound said:

What are you using for the chime/voice announcements? OUT1? If so, OUT1 does annunciate ALL Area/Zone announcements. Without more information on the system, I'm not sure why it would announce the first wireless zone, but that does seem odd.
 
I assume when you moved the output board (XOVR?) you didn't change it's address.
 
The Elk control should not have any errant starts, but I won't say that it's not possible. I haven't seen any.
 
I prefer that the secondary supply be ON before powering the Elk, but not sure if that is the recommended method. My thoughts is that if all secondary equipment is already powered on, the Elk will be able to recognize those components during it's boot process.
 
Zones should not need to be secure before powering up; Elk shouldn't care about the status of the zones at this point, but rather simply begin to monitor them once booted. Again, I won't claim to be an expert on this, but rather providing my thoughts and logic.

Click to expand...

 
1
 
Yes it is out1. The problem is not the fact that it announced the zone, the problem is that it announced the zone when there was no reason to announce the zone. 
 
2
I did not move the ovr. I only extended the length of the cable on three of it's output 
 
3
As for errant starts, it makes sense to bring up the peripherals first and I can't remember if I did that or not when the problem occurred. As to the zones being secured on start-up I am beginning to think that it might make a difference to the elk two way wireless zones. I'll have to do some testing of that.
 
Mike.

I've been using the XRFTW on a secondary power supply at an installation (not my house)... I leave the secondary supply running when I've needed to restart the panel for any reason. It doesn't announce any zone upon initial boot.

Is the secondary supply electrically common to the M1? That would be an item that would be a "best practice" to eliminate some variables.
 
This would lead me to believe there's something going on more with the bidirectional RF if it's a RF zone being announced. More like the bidirectional check-in after the system is armed.

DELInstallations said:

Is the secondary supply electrically common to the M1? That would be an item that would be a "best practice" to eliminate some variables.
 
This would lead me to believe there's something going on more with the bidirectional RF if it's a RF zone being announced. More like the bidirectional check-in after the system is armed.

Click to expand...

Yes the two power sources have their commons tied together. I used a cat5e for the data bus between the control and the power supply and twisted the brown pair together on each end and used them together as the common.
 
The wireless tranceiver is connected to and powered by the control, not the auxiliary. Keep in mind that the problem disappeared when I cycled the power on both the auxiliary power supply and the control(auxiliary first). It would occur consistently each and every time I armed the area and now after a re-boot it seems fine. All I can think to do is wait and see if it occurs again.
 
I have checked for errors on the rs-485 and there are 45 errors on T2A2 (xin area2) since 9am this morning.
 
Mike.

DEL
 
It was after arming area 2 that it would voice the wireless zone in area 1. It was  a completely inappropriate chime. I said that It was better after cycling the power this morning and it was but I just tested it again and it is back.
 
I armed area2 and it armed and then announced a zone open in area1. So I closed that zone and tried again and again it armed area two correctly but voiced a different zone in area1 that is open. This one is giving me a hard time.
 
Mike.

OK I just got a new clue. My rules seem to have been damaged in elkrp. I use comments at the start of each rule and the comments have been moved around. The rules have each other's comments. I remember trying to receive all recently and got an error that I could not receive rules because some rules were disabled. Maybe that had something to do with it? I tried disabling all rules temporarily and it did not help at all.
 
Mike.

I just cleaned up the comments in the rules and sent them to the control, cycled the power on the control and it armed normally three times in a row. It did the same this morning so I'll wait a while and test again and check back here to see if anyone has any ideas.
 
I'm getting close to just rebuilding the account for my system. Can I rebuild the database or somehow repair a database or account that may be damaged? Or do I need to start a new account and re-enter my system details?

Comments for rules are not stored or saved in the control, they are local to the RP DB and only on that DB...so if you connected to the panel from a different machine and RP and connected to it, the comments do not exist. The only way comments exist in the DB is if you sync multiple DB's across RP.
 
Possibly a corrupt DB given what hints have been put out there so far.
 
Do you have a copy of it before the last changes or before the last download? That would be my first place to start to try to diagnose what's going on.
 
Off the top of my head, I don't think there's a repair on RP for an individual account. I'd grab a fresh copy out of the panel and then go through it with a fine tooth comb, otherwise it's looking like you might need to rebuild the program on a fresh DB.

mikefamig said:

Yes the two power sources have their commons tied together. I used a cat5e for the data bus between the control and the power supply and twisted the brown pair together on each end and used them together as the common.

Click to expand...

 
Is this Cat5E then terminated into a DBH? Understand that this is not the standard wiring practice provided by Elk.
 
I understand that the databus doesn't care what color the wire is, but it can certainly make it harder to troubleshoot. Elk wiring suggests using the brown pair for power of the databus; assuming 568A termination at the DBH.

Regarding a possibly corrupt DB, the way to attempt to repair is to leave your existing account in ElkRP - this will be your backup for now.
 
Create a new account - naming it something else (e.g. Mike8-25-2014). You will need to enter the serial number and your RP Access Code. Then select the option for creating a Default 5.x.x account. Connect to the panel and do a RECEIVE ALL with the conflicts.

drvnbysound said:

Is this Cat5E then terminated into a DBH? Understand that this is not the standard wiring practice provided by Elk.
 
I understand that the databus doesn't care what color the wire is, but it can certainly make it harder to troubleshoot. Elk wiring suggests using the brown pair for power of the databus; assuming 568A termination at the DBH.

Click to expand...

 
At the control the cat5 has the two green data wires connected to A and B data and the two brown wires twisted together and connected to common or 12v-. At the garage the same cat5 has the two green A and B data wires connected to the A and B data on the supervised p212s power supply and the brown pair connected to the common on the p212s power supply(no termination).  The data bus then leaves there and goes to the dbh which in turn connects a keypad, a xin and an ovr and terminates with the debh terminator plug.
 
Mike.
 
The brown pair is used for power....solid brown for + and striped for common. I used the standard striped brown and added the solid brown to it, It doubles the ampacity and parked the wires neatly. I figured it couldn't hurt.

Something just occured to me. Just before this began I turned on teh voice chime at the garage keypad. Is it possible that this is normal and caused simply by me turning on the chime at the second keypad?
 
This stuff can become incredibly complicated. Is there any bottom to it?

drvnbysound said:

Regarding a possibly corrupt DB, the way to attempt to repair is to leave your existing account in ElkRP - this will be your backup for now.
 
Create a new account - naming it something else (e.g. Mike8-25-2014). You will need to enter the serial number and your RP Access Code. Then select the option for creating a Default 5.x.x account. Connect to the panel and do a RECEIVE ALL with the conflicts.

Click to expand...

I tried this and it was still the same.