Monitoring old alarm system

[rdagger]

I’m trying to integrate my 25 year old home alarm system with Home Assistant.  The alarm has 8 output pins that are pulled up to 12 V.  You can program each pin so any alarm condition will set it low.  I built a circuit using a Raspberry Pi Zero to monitor the pins.  I’m using PC817 optocouplers to isolate the 12 V alarm pins from the 3.3 V Pi pins.   Everything works but occasionally I’ll get a false alarm condition.  I don’t know why.  Are there any modifications that would make the circuit more reliable?

[SeanB]

Likely noise on the pins, as the alarm controller normally drives these using a shift register. Try soldering a 100n ceramic capacitor across the LED pins of each optocoupler, which should reduce the spurious pulses a lot.

[jonpaul]

a 25 yrs old alm panel will fail...lytics, ICs, PSU.

Get a new panel/sys, most had RF control/sensors

We use Ademco/Honeywell.

J

[dobsonr741]

How long is the wiring to the Pi? If not next to it / 5cm try moving closer, capacitors won’t hurt either. The LED side of the optocouplers tolerate long wires much better.

[floobydust]

Assuming it's the hardware causing the false triggers, you can measure the voltages at the opto-phototransistor to see if the on/off levels are correct. The board looks OK- IF you have the right pull-up resistors to +3.3V on the Pi end, I don't see them on your board. The 1kΩ don't do much other than provide short-circuit protection between the opto's and the Rpi, I would not use them.
Enabling RPi internal pull-ups e.g. pullUpDnControl(17, PUD_UP); gives you around 50kΩ. But this is too high for any off board connections.
A ribbon cable is basically an antenna, worse so with WiFi TX packets nearby. So you will pickup noise.
To fix that, I would add capacitors on the RPi DI's to GND around 10-100nF to shunt RF close to the Pi connector, and low value pull-up resistors 4k7-10kΩ.

Your software should debounce over a long time. For alarms I use a debounce time about 1 second (or say 10 scans) to filter out noise.

[rdagger]

Thanks guys for all the feedback!

Likely noise on the pins, as the alarm controller normally drives these using a shift register. Try soldering a 100n ceramic capacitor across the LED pins of each optocoupler, which should reduce the spurious pulses a lot.

I added 100nF caps to the emitter side of the optoscouplers.

a 25 yrs old alm panel will fail...lytics, ICs, PSU.  Get a new panel/sys, most had RF control/sensors

Despite its age, the Napco P3200 alarm appears to be a very well built.  The company is in New York and the alarm was built in North America.  The alarm components are very modular and still available.  If there’s a problem, it will tell you exactly which board is at fault and the alarm also came with full schematics.

How long is the wiring to the Pi? If not next to it / 5cm try moving closer, capacitors won’t hurt either. The LED side of the optocouplers tolerate long wires much better.

The pi header was broken out using a breakout board with paddle switches and about a foot of wire.  I redesigned so the Pi now plugs directly into the PCB.

A ribbon cable is basically an antenna, worse so with WiFi TX packets nearby. So you will pickup noise.
To fix that, I would add capacitors on the RPi DI's to GND around 10-100nF to shunt RF close to the Pi connector, and low value pull-up resistors 4k7-10kΩ.
Your software should debounce over a long time. For alarms I use a debounce time about 1 second (or say 10 scans) to filter out noise.

The breakout board did have a foot long ribbon cable.  The code already had deboucing which only causes further state changes on the input pin to be ignored.  I'm not having those type of issues.  However, I will look at the timing of the alarm pulses and add some code to verify the pulse length.

Here's my redisigned board.  The Pi is very close to the optocouplers.

[floobydust]

The capacitors are in the wrong place, they should be on the opto-transistor side, across C-E pins 3,4.
It's likely nothing wrong with the H/W now that the ribbon cable is apparently gone and you've checked the alarm outputs are not leaving the opto LED's partially on.

[rdagger]

The capacitors are in the wrong place, they should be on the opto-transistor side, across C-E pins 3,4.
It's likely nothing wrong with the H/W now that the ribbon cable is apparently gone and you've checked the alarm outputs are not leaving the opto LED's partially on.

I didn't think I needed caps on the detector side now because they are so close to the GPIO pins.  I added caps to the emitter side based on SeanB's recommendation above to address noise caused by alarm controllers normally driving these outputs using a shift register.

I never had a problem with the opto's being left on.  My only issue was about 1 random false positive a month usually indicating a nonexistent burglar or fire alarm.  It's hard to troubleshoot because of the infrequent nature.  The ribbon cable was only 15 cm (6 inches) long so I'm not sure it's the sole culprit.

[floobydust]

The Pi inputs are much higher impedance than the LED's, so more sensitive to noise and that's why I put the cap there. Although your debounce algorithm should filter it as well.
I use the debounce integrator approach, as well as a blip counter to track noisy inputs. I can tell which sensor is noisy but will not trip until the debounce period.
It did fail me once, a thief was hammering the door and the door switch was going on and off and did not trip the alarm. It would only trip after being open for about 0.8 second, which does not happen with a hammer and body slam. So I turfed the shift-register debounce algorithm (crap), rolled back the time... and he came back for Round #2 and it tripped like it should. I debounce relatively long, which commercial panels do, to filter out cell-phone and lightning impulses etc.

Did you measure the opto-coupler's voltages with the alarm on/off? Just to make sure the LED is actually turning on/off properly. I can't see this H/W being the problem, unless the grounding with RPi power supply is clashing with the alarm panel's power supply.
It can also be the alarm panel making a blip once in a while, don't assume they are glitch free.

[rdagger]

Did you measure the opto-coupler's voltages with the alarm on/off? Just to make sure the LED is actually turning on/off properly. I can't see this H/W being the problem, unless the grounding with RPi power supply is clashing with the alarm panel's power supply.
It can also be the alarm panel making a blip once in a while, don't assume they are glitch free.

I've only measured when the alarm is off (about 12.9 V on the emitter side and a little over 3.2 V on the detector side.  I did test the optocouplers out of circuit with a bench power supply.  That's how I came up with the 4.7K ohm resistors.  The alarm outputs have a maximum current rating of 150 mA per output (900 mA combined).  The PC817's are efficient and operate well at less than 5 mA.  I'm not having any issues with the GPIO pins not triggering or staying triggered.

The actual burglar or fire alarm does not sound or show up on any of the keypads when a false positive occurs.  Therefore, I don't think there are any problem with the main panel.  The output terminals are on a separate programmable output module.  I suppose I could try swapping out this board if none of the hardware or software fixes work.  It's slow to troubleshoot because the problem is so infrequent.

I'm using Home Assistant to track the state of multiple alarm conditions in addition to fire and burglary.  For example, fountains are turned on by motion detectors, I get a warning if I forget to close the garage door, yard lighting comes on at night when outside doors are opened, etc.

[floobydust]

You can take an ohmmeter between the alarm panel ground and the Rpi ground and see if there is a connection, see if things are truly isolated or not.
If it's the same input channel getting false-triggered verses random channels, that could help. But it's sounding like software, maybe try a different DI in case it's getting shared.