Janus: The God Of Doorways, or The ACM Door Lock Controller

We have our own door controller, janus.acm.jhu.edu! Isn’t that exciting.

Theory Of Operation

Our door lock knows all about or LDAP database and is, in fact, a replica thereof (see LDAP for details). There are attributes in LDAP that store PBKDF2-mangled data from the card reader, against which we perform search actions. Success results in commanding a relay to close, which releases the door lock.


Bill Of Materials

  • Raspberry Pi (any similarly-sized computer would have done fine; we used a RasPi because we didn’t need the gobs of I/O provided by the BBBs)
  • Breakout board (brings GPIO headers to screw terminals)
  • DC-DC power converter: Murata Power Solutions Okami OKI-78SR-5/1.5-W36-C. Good to up to 36VDC input, 5V @ 1.5A output. This is a switching regulator (much more efficient than a 7805 linear regulator, though it still gets a little warm to the touch)
  • Relay module. We used a COTS relay+transistor+flyback board rather than putting one together ourselves.
  • Two demarcation bus strips.
  • Three-track USB-connected magstrip reader.
  • Double-gang outdoor outlet box, w/ extension unit. (Box does not accomodate RPi w/o extension, sadly!)

BlackBoard-provided Equipment

As we are replacing a BlackBoard reader, they were nice enough to let us use their box, PSU, and wire. (Nice probably had nothing to do with it, so much as the thought that we might eventually move offices.)

In particular, we have access to:

  • A 24VDC PSU.
  • A two-conductor 18AWG wire to the door lock mechanism (LK: Red, Black).
  • A two-conductor 24AWG wire to the door closed sensor (a reed switch; RS: Red, Black).
  • A four-conductor 18AWG wire to the exterior box (BP: Red, Black, White, Green).
  • A ten-conductor 24AWG wire to the exterior box (BL: Red, Black, White, Green, Brown, Blue, Grey, Yellow, Orange, Purple)
  • A cat-5 cable over to JHU IT’s networking rack.

We use our two demark strips to bridge our gear to theirs, thus:

In Blackboard Closet

On their side, we have a demark wired up as:

Power 24VCD PSU +V rail (red) BP Red, BP White
Ground 24VDC PSU -V rail (black) BP Black, LK Black, RS Black
Lock LK Red BP Green
Sensor RS Red BL Purple
Ethernet Green BL Blue
Ethernet White/Green BL Grey
Ethernet Orange BL Orange
Ethernet White/Orange BL Yellow

This leaves us with five un-used logic-level conductors, all on BL: Red, Black, White, Green, Brown, in case we need to bring additional logic in from the network closet. (Though what that could be is an interesting question, as the purpose of putting everything on our side was to make their box as dumb as possible.)


If we suddenly get a need, we could free up one of BP White or BP Red, but bringing two 24V feeds in made life easier on the demark inside our box by the door.

In Our Box

The demark in our box is wired up as:

Power BP Red To voltage regulator input
Ground BP Black To RPi BoB GND
Ethernet BL Yellow To RJ45, White/Orange
Ethernet BP Orange To RJ45, Orange
Ethernet BP Grey To RJ45, White/Green
Ethernet BP Blue To RJ45, Green
Sensor BP Purple To RPi BoB GPIO 25

The relay module is controlled by RPi GPIO 4, via the BoB screw terminal. Its power and ground inputs are brought up to 3.3V and GND on the BoB.

BP White and BP Green are connected directly (i.e. without demark) to the center and NO positions of the relay module’s screw terminal.

Expansion Options

The RPi is mostly unused. One of its USB connectors is free, as are most of its GPIO, TTL serial, I2C, NTSC, HDMI, and audio. It’s very easy to get additional wires into and out of our box, as it has four pre-drilled, threaded, plugged 1” inner diameter conduit landings, all of which are unused. There is not a great deal of room inside the box, but additional boxes could be mounted.


It might be nice to add a webcam?



The remainder of the software is to be documented.


Janus is set up to accept remctl janus open commands to open the door. This at the moment is restricted to /admin hats, but in principle could be extended to any additional kind of automation.


To see the relevant logs on Janus, it may be best to run:

journalctl -u gpiod -u swiped -u jhu-ldapd

Network Configuration

JHU IT provided us port “10/46” in the closet (Malone Hall G02) on VLAN 159, the CS private VLAN. We statically configure Janus’s IP address from our pre-allocated block on this VLAN. See Allocations.


As described in the theory of operation, Janus is a LDAP replica in the hope that it continues to function even if network connectivity or our LDAP servers are lost briefly. This is as with all of the other replicas (as per Replication and the rest of LDAP).

For contactless auth (newer touch cards–sometimes referred to as Felica/Sony cards), a new attributeType was added to LDAP called jhuacmFelicaIdm (under the objectClass named jhuacmFelicaMixin). This attribute holds the base64-encoded PBKDF2-HMAC’d (the same way card swipes are hashed) IDm of the contactless card (the IDm is similar to the swipe code, but unfortunately is not available in JHU LDAP). As such, it is necessary for this value to be inserted manually. Bailey is currently working on a script to automate this.

Integration with JHED

The JHU AD group has created a service account with read-only access to the JHU AD. Kerberos understands this account as acmjanus@WIN.AD.JHU.EDU while LDAP uses the more descriptive CN=acmjanus,OU=ACM,OU=AuthN,DC=win,DC=ad,DC=jhu,DC=edu.

See LDAP for additional details of the JHU AD LDAP database.