Door control system/Logbook

All changes/problems reported with the door entry system. See also http://github.com/londonhackspace/Doorbot/commits/master and https://github.com/londonhackspace/Doorbot/issues/

2019-11-17

Building front door reader was not being recognized. Moved it to a shorter lead and it worked fine, so reader itself is fine. Re-crimped connector at reader end, and it worked a treat.

2019-11-12

Added doorbell button to ground floor workshops door. At the moment, we don't have appropriate audio in the middle workshop, but this is in hand. It currently rings the bell on the 1st floor, which is not ideal, but will work on an audio announcer in there.

2019-04-26

Liam noticed that the workshops doorbot wasn't reading cards or letting anyone in. Still on the network, still sending "I'm still alive" status messages. Talked Liam through how to reboot it. Problem appears to have been with the reader which had locked up. Rebooting cured it. Simon Hewison (talk)

2019-02-02

Back gate reader replaced with genuine Elechouse NFC Module V4. Now reads all tested cards and fobs successfully at a reasonable range.

2019-01-27

Maglocks and Cisa latch replaced with Gianni EB300 solenoid bolts on back door, workshops door and 1st floor entrance. Landlord's maglock replaced with much stronger one.

2019-01-15

Doorbot fitted and active on the rear cage gate. Doorbell button not functioning, reports that the reader is too weak to energise any RFID cards (including Oyster), but works for fobs. Have looked into possible solutions, including boosting the Vcc to the reader with a boost converter (which will be fitted at next visit, regardless), and possibly replacing the inductors on the pn532 module board as per [Michael Turner].

2018-12-10

Reports from SamuelKF that the doorbot in the radio room was generating RF noise on 40m band when the maglock was energised. Cepmenderer twiddled the tuning knobs, and found that there was indeed some interference on 7.180MHz. Fitted ferrite rings on the 12V DC output from the switched mode power-supply, on the 230V AC supply input, and on the 12V DC output to the maglock. Any QRM was hugely reduced.

Suggest any future builds using switched mode power supplies should use ferrite rings in a similar configuration.

2018-11-03

1st Floor doorbot reset itself. On investigating, it was found that the regulator on the PSU was overheating. even when loaded within limits, resulting in a serious undervoltage. The only thing that was keeping the doorbot working was the SLA 12V battery. PSU was replaced with a switched-mode PSU that we found that should be capable of 3A at 12V. New PSU runs a lot cooler. Software update applied to 1st floor doorbot and back doorbot. Doorbell button implemented.

2015-8-5

Front door bot is failing repeatedly. Green light is permanently on and its not accepting cards. Power cycling restores functionality temporarily. Replacement power supply with GPIO header plug procured but needs installation. (Ideally, Equipment/Wilkes should be put in a case and mounted ABOVE the door and not inside the door where it is hard to reach/modify/upgrade.

Power supply was upgraded and installed on 8-8-2015 by kraptv

2015-8-4

Back door bot is borked. Green light is permanently on and its not accepting cards.

2015-7-25

The strike plate/doorlock was getting worn and acting up so we replaced it with a maglock, see Equipment/Wilkes for a bit more info.

2014-2-15

Same error as yesterday, remedied around 16:50

2014-2-14

Doorbot recognises cards and makes noises correctly, but door does not open.

fixed by re-plugging the arduino's usb cable + the 12V battery charger.

2014-2-1

Fault: Doorbot and doorbell didn't work

Restarted doorbot service and all is well.

2014-1-29

Fault: Doorbot and doorbell didn't work

Actions taken:

Reconnecting the USB cable and restarting "doorbot" service on hemming fixed the issue.

Both doorbell and doorbot work well now. But noticed that logs are not being written to /var/log/doorbot.log since 2013-10-12 22:54:46

2014-1-25

Space painting day so time to play with frontdoorbot again :(

Fault: front doorbell doesn't work.

Previously when this has happened taking it all apart and putting it back together again fixes it. But it than fails again in ~48 hours.

Actions taken:

Frontdoorbot taken to pieces and assembled on a bench.

Doorbell works fine. Will leave it for a bit to see if it stops working.

2013-9-27

backdoorbot (Wilson) dyeing, symptoms:

ping ~ 1000ms
very slow
doorbot dosen't work
errors in dmesg:

[18205.183744] smsc95xx 1-1.1:1.0: eth0: Timed out reading MII reg 01
[18387.907848] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
[18387.907882] smsc95xx 1-1.1:1.0: eth0: Error reading MII_ACCESS
[18387.907917] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
[18459.729447] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
[18459.729479] smsc95xx 1-1.1:1.0: eth0: Error reading MII_ACCESS
[18459.729497] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
[18543.731314] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
[18543.731363] smsc95xx 1-1.1:1.0: eth0: Error writing MII_ADDR
[18572.071941] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
[18572.071973] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA

possible causes (recent changes):

upgrading packages
enabling ipv6
playing with ansible/apt-cacher (??!?!?)

tried:

swapping readers and relay
lots of fiddling about

Appears to be issue with new version of raspbian not likeing the card reader.

2013-9-11

Front door (Bell?) not opening the door, or announcing people coming in, the bell also doesn't work. Logged into Bell, tried to open the door manually, nothing happened.

2013-5-8

PC01 error https://github.com/londonhackspace/Doorbot/issues/23

2011-10-2

Doorbot started spamming the channel (please set /mode +q robonaut temporarily while fixing it). Turns out it was due to church's dnssec failing again, so the cron job was clearing out the carddb.json. This will be fixed by the new refreshing system.

Restarted bind9 on church to fix.

2011-9-25

Now switched over to a hybrid of the json DB from Turing and the cards that we haven't been able to identify. This will last a week or so.

2011-5-14

Operator: Mark

Doorbot stopped responding to cards again, but this time it was the RFID reader:

May 14 05:29:06 bell pcscd: commands.c:1295:CCID_Receive() Not enough data received: 0 bytes
May 14 05:29:06 bell pcscd: ifdwrapper.c:722:IFDTransmit() Card not transacted: 612
May 14 05:29:06 bell pcscd: winscard.c:1675:SCardTransmit() Card not transacted: 0x80100016
May 14 05:29:06 bell pcscd: commands.c:997:CmdGetSlotStatus() Not enough data received: 0 bytes
May 14 05:29:06 bell pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
May 14 05:29:06 bell pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00
May 14 05:29:06 bell pcscd: commands.c:219:CmdPowerOn() Not enough data received: 0 bytes
May 14 05:29:06 bell pcscd: ifdhandler.c:1096:IFDHPowerICC() PowerUp failed
May 14 05:29:06 bell pcscd: eventhandler.c:443:EHStatusHandlerThread() Error powering up card.

and then:

May 14 05:29:07 bell pcscd: commands.c:997:CmdGetSlotStatus() Not enough data received: 0 bytes
May 14 05:29:07 bell pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
May 14 05:29:07 bell pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00

periodically (every card read?), until I rebooted it:

May 14 23:27:23 bell pcscd: commands.c:873:CmdPowerOff() Not enough data received: 0 bytes
May 14 23:27:23 bell pcscd: ifdhandler.c:1058:IFDHPowerICC() PowerDown failed
May 14 23:27:45 bell pcscd: commands.c:1295:CCID_Receive() Not enough data received: 0 bytes
May 14 23:27:45 bell pcscd: ifdwrapper.c:722:IFDTransmit() Card not transacted: 612
May 14 23:27:45 bell pcscd: winscard.c:1675:SCardTransmit() Card not transacted: 0x80100016
May 14 23:27:45 bell pcscd: commands.c:997:CmdGetSlotStatus() Not enough data received: 0 bytes
May 14 23:27:45 bell pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
May 14 23:27:45 bell pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00
May 14 23:32:14 bell pcscd: commands.c:873:CmdPowerOff() Not enough data received: 0 bytes
May 14 23:32:14 bell pcscd: ifdhandler.c:1058:IFDHPowerICC() PowerDown failed
May 14 23:32:54 bell shutdown[1323]: shutting down for system reboot

Also set up ntp (times are a couple of minutes off).

2011-5-14

Operator: Mark

Doorbot ran out of space (Jonty noticed this on Tuesday and may have fixed it once). Moved the wavefiles for Glados to Babbage, mounted over NFS. It now has 23MB free. I didn't realise it still wasn't responding to cards.

2011-4-20

Operator: Mark

Relay disconnected, doorbot unable to open door.

This was due to me telling Aden he could take the 12v-5v converter, thinking it was no longer needed. Fortunately, I had a spare in my box. Guess that means we need to buy a new spare. Removed some redundant parts from the stripboard.

2011-4-1

Operator: Mark

Although Jonty thinks it should be on a separate machine, set up glados on Bell. Uses "aoss bplay", as that uses the least space.

2011-3-31

Operator: Jonty

Moved doorbot to bell, Jonty's old dumb terminal. Farewell flowers.

2011-3-21

Glados appears to be down. No screen session called glados. Doorbot and powerd still working.

2011-3-14

While testing xTwi7ch's glados entry, we used

send-debug-broadcast.py RFID '' ''

and it opened the door. We can't reproduce this, so I wonder whether Doorbot/arduino got stuck somehow.

2011-3-10

Doorbot stopped seeing rfid cards at approximately 23:00 the night before. Unlocking from the inside works, with the expected info shown in the SCREEN session, using openDoor.py also works, as does the doorbell. Doorbot was re-started by Solexious. Ciemon 06:40, 10 March 2011 (UTC)

I think it was actually around 12:30am, and was noticed by Phil at 1:55am. Phil replugged USB at 4am, but it still didn't work until Doorbot was restarted at 6:45am.

^CTraceback (most recent call last):
  File "./doorbot.py", line 123, in <module>
    checkForCard(card, ser)
  File "./doorbot.py", line 77, in checkForCard
    time.sleep(0.2)
KeyboardInterrupt
Exception smartcard.Exceptions.CardConnectionException: <smartcard.Exceptions.CardConnectionException instance at 0x9fa930c> in <bound method  PCSCCardConnection.__del__ of <smartcard.pcsc.PCSCCardConnection.PCSCCardConnection instance at 0xa06f3ac>> ignored
Doorbot exited. Restarting shortly...

Looks like PCSC hung due to a communication failure.

From syslog:

Mar 10 00:24:32 flowers pcscd: commands.c:1295:CCID_Receive() Not enough data received: 0 bytes
Mar 10 00:24:32 flowers pcscd: ifdwrapper.c:722:IFDTransmit() Card not transacted: 612
Mar 10 00:24:32 flowers pcscd: winscard.c:1671:SCardTransmit() Card not transacted: 0x80100016
Mar 10 00:24:32 flowers kernel: [2036155.844390] usb 1-4.1: clear tt 1 (9072) error -71
Mar 10 00:24:32 flowers pcscd: commands.c:1295:CCID_Receive() Not enough data received: 0 bytes
Mar 10 00:24:32 flowers pcscd: ifdwrapper.c:722:IFDTransmit() Card not transacted: 612
Mar 10 00:24:32 flowers pcscd: winscard.c:1671:SCardTransmit() Card not transacted: 0x80100016

and then:

Mar 10 00:24:32 flowers kernel: [2036156.079362] usb 1-4.1: clear tt 1 (1072) error -71
Mar 10 00:24:32 flowers kernel: [2036156.110358] usb 1-4.1: clear tt 1 (9072) error -71
Mar 10 00:24:32 flowers pcscd: commands.c:997:CmdGetSlotStatus() Not enough data received: 0 bytes
Mar 10 00:24:32 flowers pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
Mar 10 00:24:32 flowers pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00

repeated every second until:

Mar 10 00:28:37 flowers kernel: [2036401.072205] usb 1-4.1: clear tt 1 (1072) error -71
Mar 10 00:28:37 flowers kernel: [2036401.107457] usb 1-4.1: clear tt 1 (9072) error -71
Mar 10 00:28:38 flowers kernel: [2036401.353500] usb 1-4.1.4: USB disconnect, address 7
Mar 10 00:28:38 flowers kernel: [2036401.428684] usb 1-4.1: reset high speed USB device using ehci_hcd and address 5
Mar 10 00:28:38 flowers pcscd: ccid_usb.c:596:WriteUSB() usb_bulk_write(001/007): No such device
Mar 10 00:28:38 flowers pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 617
Mar 10 00:28:38 flowers kernel: [2036401.800646] usb 1-4.1.4: new full speed USB device using ehci_hcd and address 15
Mar 10 00:28:38 flowers kernel: [2036401.896902] usb 1-4.1.4: configuration #1 chosen from 1 choice
Mar 10 00:28:39 flowers pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00
Mar 10 00:28:39 flowers pcscd: ccid_usb.c:596:WriteUSB() usb_bulk_write(001/007): No such device

Mar 10 01:15:23 flowers kernel: [2039207.115530] usb 1-4.1.4: USB disconnect, address 15
Mar 10 01:15:24 flowers pcscd: ccid_usb.c:596:WriteUSB() usb_bulk_write(001/015): No such device
Mar 10 01:15:24 flowers pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 617
Mar 10 01:15:25 flowers pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00
Mar 10 01:15:25 flowers kernel: [2039208.592767] usb 1-4.1.4: new full speed USB device using ehci_hcd and address 16
Mar 10 01:15:25 flowers kernel: [2039208.687914] usb 1-4.1.4: configuration #1 chosen from 1 choice
Mar 10 01:15:25 flowers pcscd: ccid_usb.c:596:WriteUSB() usb_bulk_write(001/015): No such device

And then the replug:

Mar 10 04:03:30 flowers kernel: [2049293.631083] usb 1-4.1.4: USB disconnect, address 16
Mar 10 04:03:30 flowers pcscd: ccid_usb.c:634:ReadUSB() usb_bulk_read(001/016): No such device
Mar 10 04:03:30 flowers pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
Mar 10 04:03:30 flowers pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00
Mar 10 04:03:30 flowers pcscd: ccid_usb.c:596:WriteUSB() usb_bulk_write(001/016): No such device
Mar 10 04:03:30 flowers pcscd: ifdwrapper.c:469:IFDStatusICC() Card not transacted: 617
Mar 10 04:03:31 flowers pcscd: eventhandler.c:333:EHStatusHandlerThread() Error communicating to: ACS ACR 38U-CCID 00 00
Mar 10 04:03:32 flowers pcscd: ccid_usb.c:596:WriteUSB() usb_bulk_write(001/016): No such device
Mar 10 04:03:32 flowers kernel: [2049295.621281] usb 1-4.1.4: new full speed USB device using ehci_hcd and address 17
Mar 10 04:03:32 flowers kernel: [2049295.716433] usb 1-4.1.4: configuration #1 chosen from 1 choice

I think something's swallowing exceptions. Ms7821 09:56, 10 March 2011 (UTC)

2011-2-26

Pulled the refactored-glados branch from git to test it before merging with master. Restarted glados. The branch adds auto-reloading the wavetable.dat file, and the ability to have a sound playing in the background while being greeted (docs in the wavetable.dat). Also removed soundplayer.py it uses solely mplayer for sounds now .--Eb4890 01:40, 26 February 2011 (UTC)

2011-1-19

Doorbot stoped working at midnightish on the 18th, i joined the screen session and hit ctrl-C. doorbot was restarted and afterwards worked fine. JasperWallace

Interesting... try stracing it if you catch it happening again Ms7821 10:30, 19 January 2011 (UTC)

2010-12-20

Doorbot got jammed on Tuesday, so we're going to rework it so that only unlocking is done realtime. Everything else can subscribe to network broadcasts.

2010-10-26

Tried adding a card as per the instructions. It failed with the following reason:

babbage:/usr/local/bin/Doorbot$ sudo ./addid.sh
Name to authorise:
softhook
ssh: Could not resolve hostname bell.lan: Name or service not known
ssh: Could not resolve hostname bell.lan: Name or service not known
lost connection
Card EAFE09B1 is now authorised to softhook

Using the IP address for bell manually also failed. What's the new procedure for adding members' cards?

The door is no longer being run by bell, references should be changed to connect to flowers instead. Robert 22:23, 26 October 2010 (UTC)

2010-10-12

People are reporting the solenoid not triggering properly. This could be the bolt getting caught against the strike plate, so will test tonight.
- This is due to people not disengaging the door wedge before closing it. If this is done correctly then the bolt disengages correctly. Solexious 00:58, 16 October 2010 (UTC)

Added a diode across the solenoid (there was already one over the relay to protect the transistor). This stops a large negative voltage spike from being transmitted down the wires and potentially burning of the relay contacts, but note that this spike only appears on the opened relay contact - it does not reach the circuit except via capacitative coupling or contact arcing. The diode was fitted after the reports of the solenoid not triggering, but if it needs to be removed it is fitted to the chocblock just above the letterbox and can be disconnected easily. - artag

2010-10-06

Operator: Mark

Doorbot died at 10:04. Apparently shorting the pins wasn't it.

2010-10-05

Operator: Mark

Swapped out the hub with Oni's. It's much nicer, so we should try to find another similar.
At Jonty's suggestion, swapped out Bifferboard for his spare
While doing this, we suddenly realised what might have been causing all the problems: the tape beneath the bifferboard had been scraped away by the pins, so they were touching metal case. This explains all the random failure issues below.
We've put it in its own plastic case

2010-10-02

Operator: Jasper

noticed doorbot & door not working
as per instructions form irc power cycled the usb hub and bifferboard
door now working.
the door stopper needs a big arrow or something, it's easy to miss it and that it's down which makes the door hard to close
the speaker wires need a better way to get out of the door bot box, as the case is opened and closed it will damage the wires.

2010-09-30

Operator: Solexious

Rootfs went away at 10:30 when samthetechie tried to enter the space. Bifferboard restarted, but didn't boot.
Reboot of usb hub fixed biffer booting
- ~~The USB hub has been unplugged from its own power supply, in the hope that this will let the bifferboard reset the USB drive on failure.~~ Left plugged in, because the reader seems to fail.
  - maybe we should power it off the main 5V supply, but arrange to switch it off when USB power goes away. Then it would reset with the bifferboard.
Phase 1 of the doorbell completed
Arduino sends a 1 over serial when the door bell is pressed
LED lights green during solenoid pulse
Red/Green LED can be controlled by sending numbers to the arduino
- 2 Green on
- 3 Green off
- 4 Red on
- 5 Red off
There is also a speaker in the doorbell, this is not yet implemented

2010-09-29

Operator: Solexious

Worked out why avrdude stopped working - Mark fixed Doorbot to keep the serial port open!
Wired the door bell up

2010-09-28

Operator: Artag (write-up by Mark)

Replaced the chocblock with a lovely 25 pin D-Type connector, with soldered joints and heat-shrink.

Started testing on the scope, but couldn't find a suitable way of using the trigger feature.

Suggestions for improvements:
- See whether PWM/AC requires less current to trigger the solenoid
  - PWM the relay? What? Russ 23:20, 29 September 2010 (UTC)
  - It followed on from a discussion about solid-state relays (>500Hz SSRs exist), but there's probably a suitable mosfet. Ms7821 08:33, 30 September 2010 (UTC)

                 10:16:40 < artag> russss: re your query on the doorbot solenoid driver, I was 
                 thinking that if we replaced the relay with opto+fet, we 
                 could drive the solenoid with chopped dc or even ac (h-bridge 
                 drive). Because of the inductance, this might turn out to be 
                 significantly less current than 12V dc.

- See whether the 5v supply is having difficulty when the reader is powered
- If so, isolate it and use a hefty capacitor to keep that going (rather than supporting the solenoid)

2010-09-27

Operator: Mark

Problem 1

Identified by Solexious at the weekend

~~Arduino resets on serial open() from bifferboard~~
Arduino flashes digital outputs high on reset
Digital output flashing high triggers door open (this seems to be getting worse over time)

Tried:

Disabling DTS (didn't work)
Pull-down resistor (10k to 1k)
Physical reset button on arduino (it also makes the pins flash)
120 ohm resistor between 5V and RSET on arduino - works :D

The board no longer flashes the outputs on boot, but still does when the reset button is pressed.

Workaround:

Open serial port on boot
Hope it doesn't restart

To try:

Check voltage during boot, so see whether either line is spiking
Replace diode on solenoid
Resistors to reduce sensitivity of darlington
Use a capacitor to smooth over the reset pulse, requiring > 1 second to trigger relay
Rebuild darlington/relay board
Use a solid state relay (no darlington required)

~~Problem 2~~
~~Chocolate block "plug" is loose, sometimes causing loss of power at slightest touch~~

To try:

~~Replace with header/plugs (we'll try a D-type on Tuesday)~~

Fixed by Artag

~~Problem 3~~
~~Flashing arduino has stopped working (stk500v1: no response)~~

To try:

~~Another arduinio (Solexious will bring one on Tuesday)~~

This was because doorbot had the serial port open

Problem 4

Rootfs went away at 4:04am

This might have been the sensitive chocblock again, as there were people in the space.

Previous problems

Progressive failure overnight before Sunday of the Arduino talk - very bad. After investigation it was found that the original alarm charger was outputting 6v, so the Nneil donated a wall charger to replace it.

Numerous bifferboards were destroyed by cigarette lighter regulators which spontaneously become zero ohm resistors when a large (> 0.6A) current is pulled through them.

The original spec for a 7805 did not take into account the amount of current passed. 7V * 0.8A = a small radiator.

The original transistors we tried were not enough to trigger the relay, so were replaced with Darlingtons.