Love stuff like this. Years ago I lived in an apartment building where the main entrance was controlled by an analog phone system with an extra pair of wires. All the handsets in the unit were connected to a speaker/microphone outside the door (directly; there was no enable/disable when your unit was or was not getting buzzed), and there was an extra pair of wires for activating the door unlock.
I wanted to give my partner (and houseguests) the ability to come and go as they pleased without having to give them a building key (I only had one spare key provided by my landlord, and it was expensive to replace if lost). I bought a relay and grabbed an old Raspberry Pi, hooked the relay to the Pi's GPIO pins, and opened up the intercom phone and found the wires that activated the door unlock. Wrote a little HTTP server in python that would enable the GPIO pins for 10 seconds to unlock the door, and wired that up to my home automation system (openHAB). I got a Twilio phone number, and set it up so it would respond to particular PIN codes from specific phone numbers. When I was hosting someone for a weekend, I'd generate a random 8-digit PIN code and add that and their phone number to a config file on the Pi.
At the time I hadn't realized there were smart relays; otherwise this maybe would have required less work. This was 6 years or so ago, though, so maybe they weren't really a thing back then.
You added your own automated control to your shared apartment buildings main gate? And your landlord agreed to this? I mean, I hope you got their permission…
Would it have been different if they'd put stuck a Switchbot on there to push the button on the intercom instead of wiring in their own relay, and thus leaving the wiring intact?
Why, or why not?
Or, perhaps absurdly: Would it have been different if they'd hired someone to (at least in part) hang out and push the button on command, instead?
I don't think the hired help is any more absurd, given that the primary perceived problem would be the increased likelihood that a bad actor exploits the system. I think that's what would keep a landlord up at night far more than an impermanent modification to the real property. Either way, it removes the resident's own judgement from the request/response cycle. But then again, so does the resident handing out copies of keys, which has a very different but still substantial attack surface.
No matter what, the main gate still keeps out random people who aren't sophisticated in their attack, which is all it ever did in the first place, so there's really not much going on here.
That was the basis of my (rather open) question: Whether the primary perceived problem would be the increased potential for bad actors to do bad things, or whether the primary perceived problem would be the fact that a tenant modified the wiring inside of their own unit.
I agree that bad actors are the worst concern, since bypassing a switch with a relay on a low-voltage circuit is about as non-invasive as wiring mods can ever get.
So. Assuming that there aren't purely-technical failure modes that can results in an improperly-closed relay, we can ask: Does having per-user codes and a wired-in relay result in a worse security scenario for the building than lending the [singular] spare key to a friend does?
Sure, it's easy enough to give someone else instructions and a code, while it can be hard to copy [some] keys.
But it's also easy to disable a code when that visitor has left or is no longer welcome (and thus also disable all copies of that code), whereas it is hard to disable a copy of a key.
And OP went a step further than mere codes by also validating inbound phone numbers, as a form of 2FA. This second factor is also possible to duplicate by a bad actor, but we're well into the realm of requiring some sophistication (or brazen theft) for that to happen.
(All said, based on the description I think they did pretty good with their hack.)
On my initial reading, it sounded like they had modified the wiring on the gate itself, which would be more alarming. Now that you mention it, it does sound like they might have instead accessed wiring within their own unit. I’m used to access systems that just dial out to residents’ phone numbers, so when they talked about accessing the intercom wired to the gate, I assumed they were talking about the public call box at the gate itself.
I've only lived in one apartment that had such a system, and it was probably the nicest solution to the problem.
The only issue was that it took awhile for the landlord to change the phone number for our unit to ours, and similarly when we moved out - I kept getting phone calls for that door for months.
1. These gate systems usually have dry contact outputs as well, and you can get the gate motor’s idea as to whether the gate is open. You’ll need a smart relay with inputs :)
2. Home Assistant’s “cover” entities are a bit silly in that they don’t let you open a cover that is already 100% open. If you have a gate with an automatic close timer, you might want to send the open command even when it’s open to delay closing. You can fudge this by reporting the cover 99% open when it’s open instead of 100% open.
Took a slightly different approach for my gate, about a decade ago. Took apart one of the RF controller fobs, and wired it using a cheap relay from Aliexpress, and hooked it up to a Rpi's GPIO pins. Wrote a simple python code to control the open/close using the WiringPi library, with Alexa control achieved via the HA Bridge open source Philips HUE bridge software. Added Siri/Homekit control using HomeBridge.
Recently added two cheap outdoor cameras from Aliexpress with HLS streaming capabilities (and PoE) and wrote a simple iOS app that offers two different views (inside and outside gate), with a simple toggle button to open/close the gate. Backend hosted on a cheap $8 per month OVH instance with secure Tailscale access to the Rpi at home. This way, I can monitor my gate remotely from anywhere and open/close as required.
So all it takes to open this model of gate is someone to know to pry off that plastic motor cover thats only held on with 2 little screws, and short two pins of the connector right there on top which looks to be reachable through the bars of the gate from the other side.
I feel I'd want the motor controls in a more secured box if I was the type of person who needed one of these gates.
The gates exist to keep out people who don’t know how to do that. The people with that level of skill+motivation are _going_ to get in, and shorting some contacts is probably a less destructive way for them to do it.
And your front door lock is easy to pick, so what?
These gates are like having a garage door, they are not meant to be ultra high security. Most of the models I know of in the US use a key and lock to open the box but again, not really meant to be high security.
In the US there is no shortage of “smart” garage door integration devices (mine are HomeKit compatible from Meross) that can both trigger an open signal (short circuit, as in the post) and be wired with an optional open/closed sensor which can tell you the true state of the door.
You’d need extra bits and pieces to monitor those things, or if the gate controller monitors those things already, figure out how to read that information.
You could add a current transformer around the motor conductors to handle the ‘is_moving?’ case. If there’s measurable current flowing through the motor leads, the motor is turning. That’s how you determine the on/off status of a fan or pump motor in a building automation system.
Magnetic contacts or end switches on either end of the gate could handle the ‘open’ and ‘closed’ cases. Magnetic contacts are widely used in commercial doors for access control, and end switches are used for air damper open/closed status in building automation systems, to give a couple examples.
Not sure about the ‘blocked’ case, that would depend on what the gate motor controller does when the gate is blocked. Some kind of sensor that uses the photoelectric effect, I would imagine.
I’ve poked at some BFT boards. The ones I’ve looked at do have outputs, but they’re configure oddly by default. You can go through the menu and reprogram them. Warning: the modes may not all do what the manual says. Test them. If one mode doesn’t do what you want, try another mode.
The PCB stores the state persistently, but it doesn't expose it. After all, how would it? ADC, I2C, SPI, PWM? Those pins cost unjustified $, what percentage of buyers would even know what those letters mean?
You can check state persistence by cutting the gate's power during operation. When the power comes back on, your next button press will trigger the next operation in order, not the previous one (if you cut the power during opening, the next button press closes it and viceversa).
According to the manufacturer-supplied diagram shown (and the video of the board in-situ), the gate control board knows that the gate is open or closed based on the status of two limit switch inputs, labeled SWO and SWC.
Such an interface cannot get any more exposed than that. There's no reason to throw a stew of TLAs at the problem.
(I have a strong suspicion that nobody responding here actually -- you know -- looked at this problem as it actually exists before deciding that it somehow cannot be resolved.)
These switches do expose their state over Zigbee, it's just that their state is only on when the door is moving (I believe). Other than that, they don't know what the door's status is, that's why the OP had a door sensor.
The gate electronics has sensors on board to detect actuators status, along with presence between the gates, but they're not exposed to the remotes to minimize costs. The signals however could be available on the gate controller board, although it would then need something bigger than that ZigBee switch to report them back. In this case a small SBC with the necessary gpio lines could be interfaced with said signals and drive an external ZigBee (or wiFi) dongle.
What happens if the 2nd signal (after the 200ms delay) is never received? Would keeping the relay closed like that cause any issues?
I wonder if a more "robust" way to handle this would be a custom microcontroller on the receiving end that receives a single Zigbee signal and implements the 200ms delay internally.
It's possible it just melts the relay, possible there is logic to notice and open it, or possible just nothing happens.
There are other products I've used (https://www.amazon.com/MultiRelay-ZEN16-Sprinklers-Fireplace...) which don't have that issue because they handle the pulse logic internally, you set a z-wave option which says "pulse output 1 for 200ms" and then you call a trigger which says "pulse output 1" vs "output 1 on, wait 200ms, output 1 off"
Using that for some years on my garage door opener to make my "smart" garage door smart without paying them $20/month or whatever the stupid fee was.
I wanted to give my partner (and houseguests) the ability to come and go as they pleased without having to give them a building key (I only had one spare key provided by my landlord, and it was expensive to replace if lost). I bought a relay and grabbed an old Raspberry Pi, hooked the relay to the Pi's GPIO pins, and opened up the intercom phone and found the wires that activated the door unlock. Wrote a little HTTP server in python that would enable the GPIO pins for 10 seconds to unlock the door, and wired that up to my home automation system (openHAB). I got a Twilio phone number, and set it up so it would respond to particular PIN codes from specific phone numbers. When I was hosting someone for a weekend, I'd generate a random 8-digit PIN code and add that and their phone number to a config file on the Pi.
At the time I hadn't realized there were smart relays; otherwise this maybe would have required less work. This was 6 years or so ago, though, so maybe they weren't really a thing back then.