Hi All,
I thought I would share an interesting read regarding small change I made to my system that resulted in quite a unique situation and maybe get some feedback regarding what I may have done wrong?
After having my OmniPro II installed for over 4 years, it has been completely stable and I have never had any major issues with it.
Last night I made the smallest of changes to some automation blocks which caused a complete system meltdown. Something completely unexpected and never seen before.
I have Clipsal Cbus installed to control my lighting and it is connected to the controller. What I wanted to do was have a Cbus switch control a HAI relay...something very simple even though at this point I have had only the Cbus switches driving the Cbus dimmers and Cbus Relays with control integration through the OPII.
I first added the correct unit number into the OPII database (obviously to match the Lighting Group in the Cbus database) then setup the HAI program as such:
When the Cbus switch is pressed (XX lighting group) is ON > then turn ON the HAI relay. This worked fine when pressing the switch and it updated the status on the controller to reflect the ON/Off State of that unit.
The OPII system was working fine at this point.
Then I saw that if I initiated an ON or OFF command via Snaplink or the Omnitouch software, the relay would turn ON/OFF fine but the physical switch would not illuminate to reflect the change of state which I thought would happen. If the switch LED was OFF it would remain OFF regardless of the HAI relay state.
I.e. Command from software/Touch screen: Control>Unit No.> Turn Unit ON
So I added two more programming lines to try and force the physical switch to follow the relay’s status which was as follows:
When HAI Relay is ON > Turn ON Unit No XX
When HAI Relay is OFF > Turn OFF Unit No. XX
I downloaded the programming and tested....this is where the problems started.
I pressed the switch and it turn ON/Illuminated then immediately turned OFF so out of curiosity I pressed it several more times to try and work out what was going on and it kept doing the same thing.
Obviously, something to do with the new line of program that I was misinterpreting.
Then, all of a sudden the following occurred with the entire system:
· The external siren activated and the internal siren commenced the “Woop Woop” sound typical of a fire zone going into alarm
· All AUX zones residing on the OPII board went into tamper which included the 3 x smoke detectors and zones on the 16 zone expander cards
· The touch screens started beeping indicating the zones were tripped
· I lost all network connectivity via PC Access/Iphone/Omnitouch etc.,
· All access control readers started making faint beeping noises without any LED indications and would not read the access tags
· When I tried to access the controller through the smaller 32A00-1 touch screen it would make strange keysounds upon each press and there was a definite lag navigating the on-screen menus
Basically, the entire system went into complete meltdown and I had no idea what caused it or how to fix it.
One thing I noticed was the serial expansion board RX/TX lights were flashing in unison with the Cbus serial interface indicating to me that there was some form of a constant command stream cycling between the two systems.
I then did the following:
Disconnected the battery and recycled power to the system. After the system powered up and stabilised for about 5 seconds, the sirens started again and all zones went into tamper which meant every time I tried to go into the keypads, the screen would be overwritten by the red “Alarm” screen and prevent me from clean access to the system for diagnosis.
Between trying to acknowledge every alarm by going through the disarm procedure, I tried to bypass the zones that kept creating an alarm event so I could have clear access to the screen menus.
Once I managed to stem the flow of zone alarms I checked the system which still was doing everything outlined above.
I resorted to resetting the EEPROM and RAM on the controller. Even after doing this, the alarms occurred again and the issues did not resolve. This step, however, allowed me to obtain network connectivity to the controller.
I went into PC Access and deleted the programming that I had recently done, saved it and did a completely fresh download. This download took quite a while because of the alarms and events the panel was trying to process at the same time.
At this stage I had disconnected the internal & external sirens and also disconnected the serial expansion board from the controller bus.
After a full download of the system programming, the above issues were still present so amongst navigating through the alarm screen and cancelling phone calls from the controller, I bypassed all the necessary zones again and decided to do a firmware upgrade to hopefully stabilise the panel. I was running 3.14 firmware at this point.
By now, I thought the OPII was cooked and I was up for a replacement board. All this occurring whilst running in and out of the house to check on the meat and snags cooking on the BBQ! Talk about crap timing for a catastrophic failure.
Finally! After the firmware update completed, it appeared that the system had returned to normal. I connected back to the controller with PC Access and verified the firmware in the panel was now 3.15. I restored all zones and reconnected all peripheral equipment along with the serial board and Cbus link.
The comms between the two systems had stabilised and the access control readers were back to normal.
To be thorough, I did another full download of the system programming.
I completed further testing whilst eating cold sausages and left the system run overnight without the sirens connected. From testing and visual inspection, it appears that the panel is now operating as normal and I am stumped as to what caused such a major panel issue.
One thing is for certain, I will not try to duplicate the problem again and leave the Cbus to drive Cbus equipment. I thought what was such a simple idea turned into complete chaos and a burnt steak.
Cheers
Travis
OZ
I thought I would share an interesting read regarding small change I made to my system that resulted in quite a unique situation and maybe get some feedback regarding what I may have done wrong?
After having my OmniPro II installed for over 4 years, it has been completely stable and I have never had any major issues with it.
Last night I made the smallest of changes to some automation blocks which caused a complete system meltdown. Something completely unexpected and never seen before.
I have Clipsal Cbus installed to control my lighting and it is connected to the controller. What I wanted to do was have a Cbus switch control a HAI relay...something very simple even though at this point I have had only the Cbus switches driving the Cbus dimmers and Cbus Relays with control integration through the OPII.
I first added the correct unit number into the OPII database (obviously to match the Lighting Group in the Cbus database) then setup the HAI program as such:
When the Cbus switch is pressed (XX lighting group) is ON > then turn ON the HAI relay. This worked fine when pressing the switch and it updated the status on the controller to reflect the ON/Off State of that unit.
The OPII system was working fine at this point.
Then I saw that if I initiated an ON or OFF command via Snaplink or the Omnitouch software, the relay would turn ON/OFF fine but the physical switch would not illuminate to reflect the change of state which I thought would happen. If the switch LED was OFF it would remain OFF regardless of the HAI relay state.
I.e. Command from software/Touch screen: Control>Unit No.> Turn Unit ON
So I added two more programming lines to try and force the physical switch to follow the relay’s status which was as follows:
When HAI Relay is ON > Turn ON Unit No XX
When HAI Relay is OFF > Turn OFF Unit No. XX
I downloaded the programming and tested....this is where the problems started.
I pressed the switch and it turn ON/Illuminated then immediately turned OFF so out of curiosity I pressed it several more times to try and work out what was going on and it kept doing the same thing.
Obviously, something to do with the new line of program that I was misinterpreting.
Then, all of a sudden the following occurred with the entire system:
· The external siren activated and the internal siren commenced the “Woop Woop” sound typical of a fire zone going into alarm
· All AUX zones residing on the OPII board went into tamper which included the 3 x smoke detectors and zones on the 16 zone expander cards
· The touch screens started beeping indicating the zones were tripped
· I lost all network connectivity via PC Access/Iphone/Omnitouch etc.,
· All access control readers started making faint beeping noises without any LED indications and would not read the access tags
· When I tried to access the controller through the smaller 32A00-1 touch screen it would make strange keysounds upon each press and there was a definite lag navigating the on-screen menus
Basically, the entire system went into complete meltdown and I had no idea what caused it or how to fix it.
One thing I noticed was the serial expansion board RX/TX lights were flashing in unison with the Cbus serial interface indicating to me that there was some form of a constant command stream cycling between the two systems.
I then did the following:
Disconnected the battery and recycled power to the system. After the system powered up and stabilised for about 5 seconds, the sirens started again and all zones went into tamper which meant every time I tried to go into the keypads, the screen would be overwritten by the red “Alarm” screen and prevent me from clean access to the system for diagnosis.
Between trying to acknowledge every alarm by going through the disarm procedure, I tried to bypass the zones that kept creating an alarm event so I could have clear access to the screen menus.
Once I managed to stem the flow of zone alarms I checked the system which still was doing everything outlined above.
I resorted to resetting the EEPROM and RAM on the controller. Even after doing this, the alarms occurred again and the issues did not resolve. This step, however, allowed me to obtain network connectivity to the controller.
I went into PC Access and deleted the programming that I had recently done, saved it and did a completely fresh download. This download took quite a while because of the alarms and events the panel was trying to process at the same time.
At this stage I had disconnected the internal & external sirens and also disconnected the serial expansion board from the controller bus.
After a full download of the system programming, the above issues were still present so amongst navigating through the alarm screen and cancelling phone calls from the controller, I bypassed all the necessary zones again and decided to do a firmware upgrade to hopefully stabilise the panel. I was running 3.14 firmware at this point.
By now, I thought the OPII was cooked and I was up for a replacement board. All this occurring whilst running in and out of the house to check on the meat and snags cooking on the BBQ! Talk about crap timing for a catastrophic failure.
Finally! After the firmware update completed, it appeared that the system had returned to normal. I connected back to the controller with PC Access and verified the firmware in the panel was now 3.15. I restored all zones and reconnected all peripheral equipment along with the serial board and Cbus link.
The comms between the two systems had stabilised and the access control readers were back to normal.
To be thorough, I did another full download of the system programming.
I completed further testing whilst eating cold sausages and left the system run overnight without the sirens connected. From testing and visual inspection, it appears that the panel is now operating as normal and I am stumped as to what caused such a major panel issue.
One thing is for certain, I will not try to duplicate the problem again and leave the Cbus to drive Cbus equipment. I thought what was such a simple idea turned into complete chaos and a burnt steak.
Cheers
Travis
OZ
