RFID/NFC Access System

1,065 views
Skip to first unread message

Mathew McBride

unread,
Aug 6, 2012, 5:39:14 AM8/6/12
to connected-commu...@googlegroups.com

Hi Everyone,

Has anyone done research on the NFC/RFID access system? (It was on the
wish list board when I last visited).
I'm aware we have an Adafruit PN532 NFC breakout board, along with a box
of MiFare Keychain fobs, in the hackerspace, and having done previous
NFC work with libnfc, I'd love to take a look at the 'access control'
side - hopefully someone here knows more about controlling locks
electronically.

- Matt

Andy Gelme

unread,
Aug 6, 2012, 9:19:31 PM8/6/12
to connected-commu...@googlegroups.com, Mathew McBride
hi Mathew,

On 2012-08-6 19:39 , Mathew McBride wrote:
> Has anyone done research on the NFC/RFID access system? (It was on the
> wish list board when I last visited).

There has been some idle discussion, but it is time to get serious.

> I'm aware we have an Adafruit PN532 NFC breakout board, along with a
> box of MiFare Keychain fobs, in the hackerspace

Yes, I bought those. There are available to play with ... just let me know.

> and having done previous NFC work with libnfc, I'd love to take a look
> at the 'access control' side - hopefully someone here knows more about
> controlling locks electronically.

We're at the point where organizing the next round of working bees makes
sense.

Sorting out the complete access system, including the mechanical /
physical works, power supply, electronics, software (firmware /
back-end) and communication (notifications) ... will be high on the list.

Given the number of different people (different skills) and tasks
involved ... it will be important to have someone "lead the charge" on
getting this planned, costed and underway.

--
-O- cheers = /\ /\/ /) `/ =
--O -- http://www.geekscape.org --
OOO -- an...@geekscape.org -- http://twitter.com/geekscape --

Grant Diffey

unread,
Aug 7, 2012, 12:20:15 AM8/7/12
to connected-commu...@googlegroups.com
On Tue, Aug 7, 2012 at 11:19 AM, Andy Gelme <an...@geekscape.org> wrote:
[SNIP SNIP]

Sorting out the complete access system, including the mechanical /
physical works, power supply, electronics, software (firmware /
back-end) and communication (notifications) ... will be high on the list.

What did you have in mind for notifications/comms?

Does twitter/irc integration make sense?

as in "Fred just entered the hackerspace"

or is that too creepy?

Grant.
 


Andy Gelme

unread,
Aug 7, 2012, 1:21:53 AM8/7/12
to connected-commu...@googlegroups.com
hi All,

On 2012-08-7 14:20 , Grant Diffey wrote:
On Tue, Aug 7, 2012 at 11:19 AM, Andy Gelme <an...@geekscape.org> wrote:Sorting out the complete access system, including the mechanical /

physical works, power supply, electronics, software (firmware /
back-end) and communication (notifications) ... will be high on the list.

What did you have in mind for notifications/comms ?

Initially, for door access ...

General ...

- Notify an email list (not the main list, too much noise) and IRC channel with "generic" HackerSpace is open / closed messages.

Security ...

- Notify committee via email and OTA push to mobile phones, if the HackerSpace is opened at unusual times, e.g early hours of the morning ... in case we are being broken into.

- Heartbeat: Security system and Internet connection are okay (no news is bad news).

There will also be PIRs and a web-camera, which will have communications requirements.

Does twitter/irc integration make sense ?

Yes for IRC.

I'd be a little careful with Twitter, because the open / close messages give precise access information to anyone bad who is lurking.

The web-site (and other places) do state the meeting times, but they are a general guide and we do access the space at other times.  Specific tweets stating exactly when the space is unoccupied is probably giving too much away via a communications medium that is the number one place for that type of data analysis, e.g are home owners on holiday.


as in "Fred just entered the hackerspace"
or is that too creepy ?

Yes ... is creepy (IMO).  Particularly as we don't have any members named "Fred" (AFAIK).

I believe the default would be that members do NOT want their movements publicly announced.

However, if someone specifically requested that for themselves, then we could enable it just for them.

The only general case that I can think of now ... would be just for the specific duty member opening a specific session, e.g ...

- Stuart opened the HackerSpace for Monday night 3D printing.
- Andy opened the HackerSpace for Tuesday night general session.

... this information would hardly be a surprise.

Tim Krins

unread,
Aug 7, 2012, 4:26:03 PM8/7/12
to connected-commu...@googlegroups.com
Rather than RFID, has anyone considered a secure version of something like Noisebridge's system?

They have a variety of methods to access their space, including a 6 digit key code typed into a dialpad outside, or a web application with a remote trigger.

These methods don't require any particular physical item or piece of fancy NFC technology, and still enable secure access to the space.

For example, the members have an individual keycode they can create and type into either the door keypad or have a link to the webserver on their phone.

You could even easily implement a two-factor system (two people need to confirm access to the space at odd times) or timed access systems.
RFID could be used with these ideas, but seems like it would be more difficult to manage in the long term (losing cards, registering, buying more etc).
However, still better than physical keys ;) ...

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Tim K
Current Location: Somewhere in the Northern Hemisphere

Shival Wolf

unread,
Aug 7, 2012, 5:36:13 PM8/7/12
to connected-commu...@googlegroups.com
I have been doing a little fiddling with NFC stuff recently myself mainly with my phone but I have the arduino shield from adafruit and a serial based NFC reader/writer but i haven't had time to fiddle with them much. I wanted to see what i could do with works door system but it turns out its not NFC. you can do some fun stuff with the android NFC stuff chip, though there arn't many apps at this time for doing anything but reading. The ADK for the NFC chip is capable of sending standard messages but it cant be used to clone or impersonate other cards. Java isn't my strong point so I have not had a chance to see what i can make yet with that.

There is tools out there for making NFC security cards and making them actually secure by setting the A and B keys properly so not just anyone can read/write the data on the different sectors of the card.
Sure the mifare classic cheap cards are cracked but I don't think you would need to worry about that too much unless someone at the space was doing card cloning, It would be easier to become a member then trying to steal an access card and clone it. It could also be possible to make a door app for anyone with higher end smartphones. Authenticate to the APP against a server and then touch the phone and it authenticates you to the door.


On a random side note of NFC.
They started putting up smart ad boards at places like Chadstone. you scan the NFC token and it takes you to the website (instead of using the QR code)
Some of them are unlocked which is kind of amusing as it allows you to rewrite them in less then a second to go to a different URL.
Most seem locked though.

On another random note.
Digital passports contain some fascinating information.
There is the general ID stuff, but it also includes a digital copy of the persons photo inside the NFC data that you can pull across.
Also some light travel history with destination country and dates there to.

Mathew McBride

unread,
Aug 8, 2012, 12:39:12 AM8/8/12
to connected-commu...@googlegroups.com

On 8/08/12 7:36 AM, Shival Wolf wrote:
>
> There is tools out there for making NFC security cards and making them
> actually secure by setting the A and B keys properly so not just
> anyone can read/write the data on the different sectors of the card.
> Sure the mifare classic cheap cards are cracked but I don't think you
> would need to worry about that too much unless someone at the space
> was doing card cloning, It would be easier to become a member then
> trying to steal an access card and clone it. It could also be possible
> to make a door app for anyone with higher end smartphones.
> Authenticate to the APP against a server and then touch the phone and
> it authenticates you to the door.
>
The best assumption to make about security with NFC is to assume the
plaintext on the card will eventually become available to an attacker,
no matter how good the encryption is. So having a database of cards on
the server would be my plan, plus a protected sector on the card to
which only the server will know the passphrase for the particular card.
Any cards that are lost could be then revoked.

Accommodating NFC smartphones is definitely one of my goals, but I don't
have a phone with NFC (yet). The easiest method would be if the phone
would emulate a Mifare card, but from what Shiva has quoted above, and
from further research, it appears this isn't doable out of the box on
Android?

I had a chat to Andy last night, he mentioned MQTT (with the Mosquito
server) as the mechanism by which events can be communicated between
devices - I still need to study this more but it sounds like the ideal
way to integrate everything.
> On another random note.
> Digital passports contain some fascinating information.
> There is the general ID stuff, but it also includes a digital copy of
> the persons photo inside the NFC data that you can pull across.
> Also some light travel history with destination country and dates
> there to.
Has anyone been able to read NFC-enabled Australian passports with an
off-the-shelf reader? It hasn't worked with my reader.

Shival Wolf

unread,
Aug 8, 2012, 1:11:09 AM8/8/12
to connected-commu...@googlegroups.com
From what i understand of the NFC API you can push data there seems to be the ability for some manipulation of the card type but i think sending is limited to NdefMessage 's

You could have the app on the phone once authed send a 1 time use code that is sent via the NDEF message as text and the door could read that message and let you in.



AUS passports I am not sure on i Could not read mine but the one of my NZ and GB house mate read fine.

Shival Wolf

unread,
Aug 9, 2012, 2:26:37 AM8/9/12
to connected-commu...@googlegroups.com
Very nifty, going to have to do some experimenting.

Barbara

unread,
Aug 9, 2012, 6:31:50 AM8/9/12
to connected-commu...@googlegroups.com
Hello all,

sorry I'm joining late into this conversation... I'm so busy writing
applications and studying these days....

but the company I just left, of course, makes a security/access system.

I'd just like to share how that system addresses these questions. For
example, we have one of these systems in our house.

>> What did you have in mind for notifications/comms ?
>
> Initially, for door access ...
>
> General ...
>
> - Notify an email list (not the main list, too much noise) and IRC
> channel with "generic" HackerSpace is open / closed messages.
>
> Security ...
>
> - Notify committee via email and OTA push to mobile phones, if the
> HackerSpace is opened at unusual times, e.g early hours of the
> morning
> ... in case we are being broken into.

The way how it works in our house:
Any events -- like door open, closed, movement sensed with a PIR,
anything -- is logged to a database internal to the system.
Every now and again I connect the system to a PC and download the
information. The system could also permanently be connected to a server
and log the access logs there.
But only when the system is specifically "on alert", called "armed",
these events generate "alarms". Otherwise, they don't.
The last person to leave would "arm" the system. If anyone of us enters
legitimately, they
would know how to "disarm" the system and do that as the first thing.

When the system is "armedt" and generates an alarm, that alarm can take
several forms. E.g., we could have e-mails sent or SMSes pushed to
somewhere.

In addition, for example, when user Fred opened the door and set the
system "disarmed", then the system could be set up to notify Fred
himself.
If Fred actually is just walking into the space, he can ignore it, but
if not, if someone has faked Fred's ID -- then Fred would know about
that, and could tell Andy or the police.

The system I have worked with can take both access cards, FOBs, and
also PIN numbers typed into a terminal. There are weatherproof
terminals.
We generally found PIN numbers less secure than cards, because people
choose the PIN numbers themselves, and you can get PIN number clashes.

We do have an an option to require two different users to enter their
credentials, or for a user to both present a card and enter a PIN
number, for certain high-security actions, like opening the safe or the
reactor room... of which we have neither in the hackerspace...

> - Heartbeat: Security system and Internet connection are okay (no
> news
> is bad news).

In our house, our system has a battery and continues to work when the
power is off, but then we get an SMS. If the battery was fed via solar,
this would make it totally independent.

By what I mean -- yes, watchdog, in the sense that it could raise an
alarm if power off, internet connection broken, etc. (well -- unless
someone has de-alerted it specifically, because they are just setting up
a new router, or because there is the general activity in the 'space and
it can be just expected from time to time that someone will cause a
short...)

>> Does twitter/irc integration make sense ?
>
> Yes for IRC.
>
> I'd be a little careful with Twitter, because the open / close
> messages
> give precise access information to anyone bad who is lurking.
>
> The web-site (and other places) do state the meeting times, but they
> are
> a general guide and we do access the space at other times. Specific
> tweets stating exactly when the space is unoccupied is probably
> giving
> too much away via a communications medium that is the number one
> place
> for that type of data analysis, e.g are home owners on holiday.

Yes. I guess detailed movement logs of specific people should at least
not be public.

But even if general logs were: The idea is that the system would
protect the space even if people know that the place is empty -- because
it could send an alarm and, more importantly, take pictures of the
intruder, for police.


So... I still have an electronic lock lying around somewhere and will
try to bring it next time.


Cheers

Barbara

Mathew McBride

unread,
Aug 17, 2012, 11:44:21 PM8/17/12
to connected-commu...@googlegroups.com

I played with the Adafruit kit on Tuesday and managed to get it working,
reading/writing data to the tags. Figuring out the sector authentication
system on the MiFare classic was a bit harder; for a while I thought I
permanently locked out a sector on the tag!

Here is the example code I created using libfreefare and libnfc (in C).
The Makefile will need to be edited depending on your environment
https://gitorious.org/mifare-classic-example/mifare-classic-example

And the Google Doc with my notes (which I hope to shift to the wiki)
https://docs.google.com/document/d/15enfKf73n6hZtvrYu6y81xpJyEm3LNZb3DU_7WIWa20/edit?pli=1

As for the gameplan:
- It will probably be easier to use a small Linux device like a RasPi
than an Arduino - the high level libfreefare library makes things
easier, and gives more versatility to support other NFC tag types in the
future. Also, we can use some of the other PN53x based NFC readers out
there that may be more convenient to integrate (size-wise)

What needs to be done:
- Define a data format for the NFC tags, including security measures
- Create the frontend (reader) code
- Link it to a database so tags can be revoked if lost/compromised.
- Define events for Mosquito/MQTT that happen when door is opened etc.
- Interface with a door lock/opening mechanism.

- Matt

Steve Oxley

unread,
Aug 22, 2012, 8:38:46 PM8/22/12
to connected-commu...@googlegroups.com
Morning all,

I found this interesting RFID door access build - is it any use to the group?

http://staticfree.info/projects/rfid_front_door/

Cheers,
Steve


--
Stephen Oxley, ICT IT Security & Risk Section, eSolutions,
Monash University, Clayton, Victoria, Australia.

Geoff

unread,
Aug 23, 2012, 1:47:26 AM8/23/12
to connected-commu...@googlegroups.com
This ACR122U Contactless NFC Card Reader USB for AU $60 looks a more complete and reliable option. 

Mathew McBride

unread,
Aug 23, 2012, 3:46:41 AM8/23/12
to connected-commu...@googlegroups.com
On 23/08/12 3:47 PM, Geoff wrote:
This ACR122U Contactless NFC Card Reader USB for AU $60 looks a more complete and reliable option. 

While the ACR122x series is fairly easy to obtain, the libnfc developers recommend against it, as the NFC chip has to be tunneled through a traditional smartcard protocol (PCSC). There are other readers that could be very convenient for this use case, but the downside is that one would have to write all the code from scratch.

The recommended hardware if libnfc is listed at [1]. The SCL3711 can be obtained off eBay, Snapper in Wellington is willing to send you their 'Snapper Feeder' dongle at cost+post if you ask nicely (mention libnfc and open source) and the Adafruit NFC board can be obtained fairly easily, of course.



I found this interesting RFID door access build - is it any use to the group?

http://staticfree.info/projects/rfid_front_door/
Looks like a very nifty set up, but there are some issues:
1) It uses the UID of the card as the only identification. UIDs can be spoofed quite easily (especially when 'Chinese clone' cards exist), and can be read easily (think some mischievous person waving their NFC phone over your back pocket). For security, there must be some further interrogation of the card itself
2) It uses some sort of premade uC that limits the supported cards down to the Mifare Classic series
3) To extend on the above point further, the advantage of the RasPi+libNFC solution is that other card types can be easily supported in the future. This might come into play for cases such as using your NFC phone for entry. libfreefare (on top of libnfc) gives us an easily library for reading/writing any of the common Mifare series without manually constructing packets etc.

On the plus side, it does have quite a nice case!

--

Geoff and I did some planning on this Tuesday night. The result being a there is a much bigger picture that might incorporate security and other systems should the Hackerspace get them. Quite a bit of paper was consumed, and once I get a chance, I'll post that to the list.

One thing that we are on the lookout for is a robust notification system, something that can listen for heartbeats from say, the RasPi in the door reader and determine if it needs to be reset. (A watchdog is needed as well).

[1] http://www.libnfc.org/documentation/hardware/compatibility

Geoff

unread,
Aug 24, 2012, 1:02:27 AM8/24/12
to connected-commu...@googlegroups.com
Is there a NFC Card Reader this is packaged like the ACR122U?

I have seen some readers that can be used at a small distance, if we could use the reader though the window packaging would be easier?

Mathew McBride

unread,
Aug 24, 2012, 8:57:24 AM8/24/12
to connected-commu...@googlegroups.com
On 24/08/12 3:02 PM, Geoff wrote:
Is there a NFC Card Reader this is packaged like the ACR122U?

I have seen some readers that can be used at a small distance, if we could use the reader though the window packaging would be easier?

Some other desktop form ones are listed at http://www.libnfc.org/documentation/hardware/compatibility, as well as some 'OEM' modules that would do the trick. I'm not sure if they are easily obtainable in small quantities (some may be EOL), except this one:
http://www.identivenfc.com/nfc-readers/nfc-reader-usb.htm ($92.50 USD)

The Adafruit/Microbuilder design is open hardware, maybe modifying it to our needs could be a good option..

Mathew McBride

unread,
Aug 28, 2012, 7:19:00 AM8/28/12
to connected-commu...@googlegroups.com

There is now a page (better late than never) on the wiki for this
project, based on what Geoff and I wrote up last week:

http://www.hackmelbourne.org/wiki/index.php/Access_System

- Mathew

Luke Weston

unread,
Aug 29, 2012, 5:40:17 AM8/29/12
to connected-commu...@googlegroups.com
OK, so, what do you need in terms of electronic hardware? I imagine it's something like this:

12-30V DC comes in from plugpack. The voltage is really just determined by the solenoid voltage, it's some high voltage, it doesn't matter exactly what it is, probably 12V or 24V.

The high voltage rail is regulated down to 3.3V for the PN532 and 5V for the Raspberry Pi as well as going to the solenoid.

The Raspberry Pi is connected to ethernet, and the PN532's UART lines are connected to the Raspberry Pi. (Note that the PN532 runs at 3.3V and level translation is not needed.) Alternatively you could use SPI to interface the PN532 to the Raspberry Pi if you wanted, but the UART is probably much easier.

The Raspberry Pi drives a LED and/or small piezo buzzer with its GPIO pins to provide output to the user, as well as driving a power FET that drives the solenoid.

All this stuff could be on a small PCB that plugs into the Raspberry Pi and the Adafruit PN532 board, or it could be incorporated with the PN532 on a single board that plugs into the Raspberry Pi.

Sound about right?

Mathew McBride

unread,
Aug 29, 2012, 6:24:04 AM8/29/12
to connected-commu...@googlegroups.com

On 29/08/12 7:40 PM, Luke Weston wrote:
> 12-30V DC comes in from plugpack. The voltage is really just
> determined by the solenoid voltage, it's some high voltage, it doesn't
> matter exactly what it is, probably 12V or 24V.
>
The one Geoff showed me can operate on both, but yes, 12 or 24V DC.
>
> The Raspberry Pi is connected to ethernet, and the PN532's UART lines
> are connected to the Raspberry Pi. (Note that the PN532 runs at 3.3V
> and level translation is not needed.) Alternatively you could use SPI
> to interface the PN532 to the Raspberry Pi if you wanted, but the UART
> is probably much easier.
>
We'd have to stick to UART as that is what libnfc supports.
> The Raspberry Pi drives a LED and/or small piezo buzzer with its GPIO
> pins to provide output to the user, as well as driving a power FET
> that drives the solenoid.
>
> All this stuff could be on a small PCB that plugs into the Raspberry
> Pi and the Adafruit PN532 board, or it could be incorporated with the
> PN532 on a single board that plugs into the Raspberry Pi.
>
> Sound about right?
About right.

If building a single board is an option, LED, speaker (we thought
playing actual sound from the RasPi would be fun), PN532 (don't forget
the antenna) could sit on a single board (for the 'outside' bits), with
a wire running to the Raspberri Pi on the other side of the door.

Zac Watts

unread,
Aug 29, 2012, 6:36:32 AM8/29/12
to connected-commu...@googlegroups.com
On Wed, Aug 29, 2012 at 8:24 PM, Mathew McBride <ma...@bionicmessage.net> wrote:

If building a single board is an option, LED, speaker (we thought playing actual sound from the RasPi would be fun), PN532 (don't forget the antenna) could sit on a single board (for the 'outside' bits), with a wire running to the Raspberri Pi on the other side of the door.


I understand the festival test-to-speech engine works on the pi, It'd be neat to be greeted by name, or get a HALish 'I'm sorry, <NAME>, I'm afraid I can't do that." after an error.

Luke Weston

unread,
Aug 30, 2012, 1:09:27 AM8/30/12
to connected-commu...@googlegroups.com
I think we should be mindful here of not overengineering it, not endlessly feature-creeping it, and letting it drag on forever without actually getting done.

It should be the minimum viable system which actually does the job of allowing people to use the space at whatever flexible day suits them, not just one or two fixed meetings per week. This is important in significantly increasing the value that CCHS offers to a paid member, therefore increasing the value that people can get out of it and the number of people who can get value out of it, and the number of people willing to be paid members.

It can be expanded or added to later, and it can be designed in a way that doesn't prevent expansion or added functionality being added later, but the important basic core functionality of the system should not be delayed by unimportant features or ideas.

Cheers,
  Luke

Michael Sullivan

unread,
Aug 30, 2012, 1:17:50 AM8/30/12
to connected-commu...@googlegroups.com

I 100% agree

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.

Geoff

unread,
Aug 31, 2012, 12:45:39 PM8/31/12
to connected-commu...@googlegroups.com
Luke

Thank you for point out some key spec's.

There are endless studies showing errors in the system specifications are the most costly, so putting a reasonable amount of time into the system specifications, is the most productive approach.

For a system to be "designed in a way that doesn't prevent expansion or added functionality being added later", some idea of what is likely to change is required. This is why having people come up with ideas early is important, even if they are not core features or functionality. 

And doing a rough prototype is a good way to generate ideas and identify important functionality.   


Regards
Geoff 

Geoff

unread,
Aug 31, 2012, 1:19:34 PM8/31/12
to connected-commu...@googlegroups.com
"... We'd have to stick to UART as that is what libnfc supports."

Could please quantified how much work would it require to, say add another type of reader or use GPIO? 

It seams that this " libnfc" is a limiting factor in this project.

Mathew McBride

unread,
Sep 2, 2012, 8:56:22 AM9/2/12
to connected-commu...@googlegroups.com

On 1/09/12 3:19 AM, Geoff wrote:
> "... We'd have to stick to UART as that is what libnfc supports."
>
> Could please quantified how much work would it require to, say add
> another type of reader or use GPIO?
>
> It seams that this " libnfc" is a limiting factor in this project.
To add another reader we'd have to write all the NFC protocol code from
the ground up*,or even lower, depending on what reader one chooses and
the interfaces for taking to said reader. The side effect may be to lock
the project to a certain hardware model - I'm not aware of any
code/libraries that can be used to talk to the non-PN53x hardware out
there.

To recap, libnfc - and the associated libfreefare gives us a nice API to
talk to the reader and then do common operations, effectively hiding the
"Layer 1-6" of the NFC hardware.
IMO if there is a compelling piece of hardware out there there, would
the advantages would outweigh the extra software work?

I imagine making libnfc talk to a PN532 chip over SPI rather than UART
would be doable by writing the relevant code - it already abstracts
between native access over USB, UART - see for yourself at
https://code.google.com/p/libnfc/source/browse/ on svn/trunk/libnfc/drivers

* this would involve initializing the reader, listing tags, sending NFC
protocol packets and then the protocol of the tags themselves.

Geoff

unread,
Sep 3, 2012, 1:35:09 AM9/3/12
to connected-commu...@googlegroups.com
Thank you for your explanation, this has help my understanding of the issues to do with using NFC. 

"I imagine making libnfc talk to a PN532 chip over SPI rather than UART 
would be doable by writing the relevant code - it already abstracts 
between native access over USB, UART  - see for yourself at 
https://code.google.com/p/libnfc/source/browse/ on svn/trunk/libnfc/drivers "

I had a quick look at this reference and I did not see an easy or quick way to use the GPIO and libnfc.

Would it be best to accept the Adafruit "PN532 NFC/RFID controller breakout board - v1.3" as the one we go with, given the comments in the libnfc wiki?

Mathew McBride

unread,
Sep 3, 2012, 2:28:38 AM9/3/12
to connected-commu...@googlegroups.com
On 3/09/12 3:35 PM, Geoff wrote:
Thank you for your explanation, this has help my understanding of the issues to do with using NFC. 

"I imagine making libnfc talk to a PN532 chip over SPI rather than UART 
would be doable by writing the relevant code - it already abstracts 
between native access over USB, UART  - see for yourself at 
https://code.google.com/p/libnfc/source/browse/ on svn/trunk/libnfc/drivers "

I had a quick look at this reference and I did not see an easy or quick way to use the GPIO and libnfc.

Would it be best to accept the Adafruit "PN532 NFC/RFID controller breakout board - v1.3" as the one we go with, given the comments in the libnfc wiki?
 
I was speaking in general terms there - my understanding is that should one want to access the chip via SPI or I2C rather than UART or USB, all that needs to be done is to write the code for libnfc to talk over that (all it does is manipulate registers on the PN53x chip).
I'm not familiar with the RasPi, so I hope there is userspace GPIO/SPI/etc. access available!

It seems the Adafruit board is the best way to go - it is open hardware so we can take it and adopt it to our needs if required.

Stuart Young

unread,
Sep 3, 2012, 2:34:42 AM9/3/12
to connected-commu...@googlegroups.com
I would add that since Adafruit seem to be very keen on the RasPi, you may find some support for the PN532 breakout board appear, either directly from Adafruit, or from someone aiming to use it in a similar manner.

--
Stuart Young (aka Cefiar)

Mathew McBride

unread,
Sep 3, 2012, 5:44:21 AM9/3/12
to connected-commu...@googlegroups.com

On 3/09/12 4:34 PM, Stuart Young wrote:
> I would add that since Adafruit seem to be very keen on the RasPi, you
> may find some support for the PN532 breakout board appear, either
> directly from Adafruit, or from someone aiming to use it in a similar
> manner.
They already have, in a way, using UART - the downside appears to be the
loss of the serial console?

http://learn.adafruit.com/adafruit-nfc-rfid-on-raspberry-pi

Geoff

unread,
Sep 7, 2012, 3:05:33 PM9/7/12
to connected-commu...@googlegroups.com
Could we please revisit the justification for using a Pi to chat to the NFC adafruit and the lock?

The main motivation is the best case power use of the Pi is 120mA. This is an excessive amount of power to chew though 24/7 and It limits the the time the backup power will last.
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=9089&p=107169&hilit=turn+on+unplug+power#p115844 

Is it possible for us to use a Freetronics EtherTen or EtherMega if we more resources (I should declare that I got some free stuff from Freetronics a month or two ago). There are other options eg Spinneret Web Server (this looks like a good option).

tubular

unread,
Sep 7, 2012, 5:03:08 PM9/7/12
to connected-commu...@googlegroups.com
Hi Geoff

I have a Spinneret and matching metal case to donate if you want to go that way, or play with etc 

Luke Weston

unread,
Sep 7, 2012, 6:24:53 PM9/7/12
to connected-commu...@googlegroups.com

 It limits the the time the backup power will last.

Has anybody, in the above discussion, actually mentioned any need for anything to do with any kind of "backup power"? There's nothing of the sort mentioned in any of the above hardware specification discussion.

Mathew McBride

unread,
Sep 7, 2012, 7:21:32 PM9/7/12
to connected-commu...@googlegroups.com

On 8/09/12 5:05 AM, Geoff wrote:
> Could we please revisit the justification for using a Pi to chat to
> the NFC adafruit and the lock?
>
> The main motivation is the best case power use of the Pi is 120mA.
> This is an excessive amount of power to chew though 24/7 and It limits
> the the time the backup power will last.
> http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=9089&p=107169&hilit=turn+on+unplug+power#p115844
>
>
> Is it possible for us to use a Freetronics EtherTen or EtherMega if we
> more resources (I should declare that I got some free stuff from
> Freetronics a month or two ago). There are other options eg Spinneret
> Web Server (this looks like a good option).
> http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/32203-SpinneretWebServerDoc-v1.1.pdf
>
I was seriously considering it at the start - there are pros and cons to
each. I'll admit personal bias to the 'high-level' RasPi/libnfc approach
given that I've played with that software library extensively in the past.

Reasons for/against Arduino:
+ More lightweight
+ There is an existing i2c library for the Adafruit hardware which can
operate on MiFare classic cards
- No possibility of crypto. Can't upgrade to more secure tag types
(UltraLight C or DESFire) in the future (should price become cheap
enough). Can't roll our own encryption scheme
- Slower performance

Reasons for/against RasPi:
+ High level libnfc/libfreefare library already there - it works, little
debugging needed. Does everything we want in terms of reading/writing
data to tags. Already has support for the advanced tag types.
+ More possibilities software wise - already have networking,
cryptography, mosquito libs.
+ Being a full Linux system, the RasPi could hold a replicated
copy of the key database for continued operation if the main server goes
down.
+ Faster
- Not as good for low level electronics stuff. (GPIOs, Interrupts)
- More power consumption.

Performance may be a sticking point - I started working on a prototype
frontend/backend system on Tuesday - just polling the PN532 to check if
there are tags in the field took 5% of my laptops CPU. I'd like to play
on an actual RasPi to see what the 'idle' CPU usage would be.

Making an Arduino-based prototype would be a good idea as well - see how
far we get when it comes to responsiveness in terms of when a NFC tag is
presented and how fast it can obtain responses from a server.

Also check to see what happens if multiple cards are in the field (we
would all have existing NFC tags - myki, PayWave/PayPass in our wallets)
- it appears the Adafruit library has a hardcoded limitation of 1 tag at
a time*. The libnfc-based software already handles this.


On 8/09/12 8:24 AM, Luke Weston wrote:
> Has anybody, in the above discussion, actually mentioned any need for
> anything to do with any kind of "backup power"? There's nothing of the
> sort mentioned in any of the above hardware specification discussion.
Was discussed on the initial planning session - I think that falls under
a hypothetical 'Kent Lane Security System' rather than just the 'Access
System' itself.

How do we want to handle power events? - being able to ride through
small disruptions in power supply is desirable (a UPS suffices); If the
power is out for extended periods I assume access would still be
available with a normal key - and that there would be gear in the space
to tell the appropriate people of such an event.

- Mathew

*
https://github.com/adafruit/Adafruit_NFCShield_I2C/blob/master/Adafruit_NFCShield_I2C.cpp
see Adafruit_NFCShield_I2C::readPassiveTargetID

Stuart Young

unread,
Sep 7, 2012, 8:15:00 PM9/7/12
to connected-commu...@googlegroups.com
As regards to the power...

140mA should not really be an issue in our application, as we definitely have a backup plan.

There is a keysafe near the back door. The code for this is only known by a small group of people.

Should the place be open, either one of the keybearing members will be on duty, and can lock up, or one of the members can ring a set of telephone numbers and get the code for the keysafe, lock up, and then put the keys back in the keysafe.

If people turn up and can't unlock, and it's urgent, they can call one of the same members and open the keysafe.

The keys are secured to the door of the keysafe, so it's unlikely they will be taken anywhere and copied.

If the keysafe code is given out, it is the responsibility of the keybearing member who gives out the keysafe details to change the code on the keysafe at the earliest opportunity.

Yes, having to use keys is a pain, but we have a defined backup plan, and it should work.

Notes:
 Yes, this means you MUST be able to unlock the side door with a key. ALWAYS. Whether the system works or not.
 It is advisable to have the Pi shut down if the battery gets low.
 We have a large amount of space in the rack that could store batteries, to be held in charge for such an event.

Geoff

unread,
Sep 8, 2012, 3:00:01 AM9/8/12
to connected-commu...@googlegroups.com
Yes, thank you.

I think the Spinneret could be a good fit if we go the non-Pi way. We may try the EtherTen as some one has done something very close to what we are seeking to do and we could get it running soon. 

Luke Weston

unread,
Sep 9, 2012, 2:35:29 AM9/9/12
to connected-commu...@googlegroups.com
I don't think the extra hardware cost and complexity and stuffing around associated with adding some sort of uninterruptible power supply or battery backup is required.

Standard solenoid door strike plates unlock when power is applied to them - so, in the event of power failure (which itself is a rare case) they remain secure, but the door can still be unlocked using a key. I can't see how that's not sufficient to meet our needs.

Geoff

unread,
Sep 9, 2012, 3:38:47 AM9/9/12
to connected-commu...@googlegroups.com
What I am saying is that we take a more detailed look at the requirements of the NFC reader and that it is prudent to do this now. We also need to look at doing a quick prototype of the NFC reader (and I believe it will need to be a writer as well).

I am not saying that we must include a UPS now (or even later) but only that our current path is making this option more difficult (costly). Also, I do find designing systems that unnecessarily wast power objectionable (this is a personal bias).

Tim Krins

unread,
Sep 9, 2012, 6:06:03 AM9/9/12
to connected-commu...@googlegroups.com

I think that if the RaspPi does not have the required mains power to open an automated door latch, we have more pressing issues ;-)

IMO, I would rather go somewhere else than try and use the HackerSpace without power.

In the case of mains power failing, somebody who knows the key code for the padlock box could be sent an email to investigate, therefore eliminating the need for a battery backup of any sort.

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.

Luke Weston

unread,
Sep 9, 2012, 10:02:21 AM9/9/12
to connected-commu...@googlegroups.com
The Raspberry Pi is not a power inefficient device. It's very power efficient for what it can do.

I don't see why this system needs to be optimised for extremely low power. It's not a portable battery-operated device, it's a mains-powered device.

Seems like there are basically just a couple of decisions to make here in terms of hardware specification:

Core hardware architecture:
a) PN532 --> Raspberry Pi
b)  PN532 --> ATmega328 --> Wiznet W5100

a) Use off-the-shelf development modules/boards, eg. Adafruit PN532 board, EtherTen etc and wire them together with the extra bits required.
b) Custom bespoke PCB that nicely integrates everything required?

So, what other peripheral electronics is needed?

12V comes in from a mains plugpack. (I assume it's 12V for a 12V door strike, but it could be higher, say 24V or something, if that's what was required for a particular door strike / solenoid.)

(Keep in mind that the plugpack needs to have sufficient current capacity to run the solenoid as well as the other electronics.)

That 12V rail is supplied to the solenoid, which is low-side switched with an open-drain output switched from the Raspberry Pi or AVR - i.e. a suitably rated N-channel power FET.

The 12V also needs to be regulated down to 5V and 3.3V for the Raspberry Pi and PN532 or AVR and W5100.

An Arduino (including EtherTen, etc.) can obviously accommodate a 12V input directly and regulate it down, and it can also supply a 5V rail and 3.3V rail (depending on the Arduino model, many of them have no 3.3V rail available, or just the FT232RL's internal 3.3V reference, which has negligible current capacity) out to the PN532.

The Adafruit PN532 board has a 3.3V regulator on it... it needs to be supplied with 5V, and a Raspberry Pi needs to be supplied with regulated 5V too.

And you want a little bit of peripheral hardware for status output to the user too - like a LED or two, and/or a small piezo buzzer, switched by digital GPIOs on the Raspberry Pi or AVR.

So, personally, that's what I think the hardware will look like.

Geoff

unread,
Sep 9, 2012, 12:50:43 PM9/9/12
to connected-commu...@googlegroups.com
Thank you for your post.

You have mostly nailed the hardware for the first prototype:-)

The key matters, as I see it, that need to be address are:

1. Which option can be quickly implemented and will help in the development of latter implementations.

2. Which option can be quickly implemented and will provide a reasonably easy to use, interface for administration eg adding cards, deleting cards, changing card properties, flag as a lost card, etc. 

3. Which option can be quickly implemented and will comply with other requirements eg insurance, OH&S, building codes, landlord, etc. 


Notes on the hardware: the Adafruit PN532 board may require level translation depending on the interface that is used. The solenoid needs a free wheeling diode across its input. Option 'a' or 'b' will need to be connected to a server (one is being built at the moment for general use which could be used). If a software admin system is chosen, then no additional hardware will be needed, else other hardware will be required (and there may be no requirement to connect to a server) for system admin.

Luke Weston

unread,
Sep 9, 2012, 6:17:43 PM9/9/12
to connected-commu...@googlegroups.com
Do we really need a "first prototype", as opposed to specifying it and doing it properly so that it's done right the first time, or as close to done right as can possibly be specified, designed and planned in advance?

There's no point in spending the time, resources and money to do it twice if you don't have to.

Geoff

unread,
Sep 9, 2012, 10:28:27 PM9/9/12
to connected-commu...@googlegroups.com
"Do we really need a "first prototype", "

Generally yes, it is often part of the specification process. 

Clifford Heath

unread,
Sep 9, 2012, 11:07:17 PM9/9/12
to connected-commu...@googlegroups.com
On 10/09/2012, at 12:28 PM, Geoff <geoff.le...@gmail.com> wrote:
> "Do we really need a "first prototype", "
> Generally yes, it is often part of the specification process.

You're not specifying a new kind of space shuttle here guys!
This is all terrain that's been trod a million times before, just
do it.

Paul Szymkowiak

unread,
Sep 9, 2012, 11:10:48 PM9/9/12
to connected-commu...@googlegroups.com

On 10/09/2012, at 12:28 PM, Geoff <geoff.le...@gmail.com> wrote:

"Do we really need a "first prototype", "

Generally yes, it is often part of the specification process. 

Hi Geoff,

I'm a firm believer in prototyping, and I teach it as a technique, however I don't believe it's true to claim it's a general practice, and there are various contexts, including this one, where I don't think it's applicable.

Why not? Well:

 - This is not a new, unproven project or technology. 

 - There are various existing prototype examples available via google foo that can be referenced, if not for the whole system, then at least the core subsystems.

 - We're not designing for a product, or even a kit that might be produced and used by many people. To all practical purposes, this is a one off.

 - We have an established cultural precedent at CCHS of not doing staged protyping. Instead, we might optionally breadboard or veroboard a simple first prototype when trying out new components. But often, even if producing a PCB, we simply check and review the eagle schematics, and get boards produced.

 - it's the "hacker way" to hack a thing: to build a thing and then fix and improve it until it works. We've produced PCB's in quantities before, and needed to fix small oversights and mistakes. The problems are typically small, and can generally be corrected without significant drama.


Paul


On Monday, 10 September 2012 08:17:43 UTC+10, Luke Weston wrote:
Do we really need a "first prototype", as opposed to specifying it and doing it properly so that it's done right the first time, or as close to done right as can possibly be specified, designed and planned in advance?

There's no point in spending the time, resources and money to do it twice if you don't have to.

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.

tubular

unread,
Sep 10, 2012, 2:24:11 AM9/10/12
to connected-commu...@googlegroups.com
Geoff I think what you're doing experimenting with the door bolts, and how they work differently when installed upright or upside down, what current they draw, is really good experimenting (or call it prototyping if you dare).  It does helps define what's required.  

@CCHS committee - is there a current "procedure" for opening up the hackerspace and ensuring two exit points etc?   We will need to ensure that whoever opens up the space does this, or that there is a system that helps to enforce this.  This requirement is probably buried in the BCA but I'm not sure whose responsibility it is (landlord vs tenant making modifications).  A sign on the door may be sufficient, but it will need to come from the top, and be readable under all conditions.

I just found out Jaycar sell two versions of the electronic door strikes - fail secure and fail safe.  Fail secure can still allow exit if you have a latch (not deadlatch) with a rotary knob on back.    

I cannot think of a way of implementing what is required on the side door with the existing deadlatch - it will need replacing with a latch & electronic strike style lock as far as I can tell. Anyone see another way? 

Did anyone else know Samsung, makers of almost everything, also make RFID based deadlatches? 

Not that hackable though, presumably.  

Lachlan 


Stefan Lacombe

unread,
Sep 10, 2012, 2:42:23 AM9/10/12
to connected-commu...@googlegroups.com

I work fo a constuction company and have a bit of experiance with electronic strikes. The come in 6, 12 and 24v options and the majority are fail secure. The current drawn for the strikes ranges from 0.1A to 2.4A but most are belo 1A. I suspect the higher current units relate to their holding strength. The tech data can be downloaded from the Dorma or Assa abloy websites who are the main companies that are used on the projects I've been involved in.

Stefan




--
You received this message because you are subscribed to the Google Groups "Connected Communit...

To view this discussion on the web, visit https://groups.google.com/d/msg/connected-community-hackerspace/-/7FTsnH4bcTUJ.

Geoff

unread,
Sep 10, 2012, 3:49:47 AM9/10/12
to connected-commu...@googlegroups.com
Hi Paul

Thank you for your post.

The motivation in doing a staged prototype is to implement a subset of the requirements, that is sufficient to enable the system to be used to make the space available 24/7 as fast as possible.

" - This is not a new, unproven project or technology. "

This project is new to both Mathew and I, or a good part of this project.

" - We're not designing for a product, or even a kit that might be produced and used by many people. To all practical purposes, this is a one off."

It was proposed to use a number of readers to control access to items in CCHS. I also know of two other groups interested in this project.

The "hacker way" is what I would also call prototyping. 

Both Mathew and I are engineering students and this is for me at lest, a chance to test (prototype:-) the theory.
 
I do lean towards staged prototyping rather than a fully specified system, having seen students take the fully specified way and build good looking projects that do not work!


Geoff

On Monday, 10 September 2012 13:11:10 UTC+10, Paul Zee wrote:

On 10/09/2012, at 12:28 PM, Geoff <geoff.le...@gmail.com> wrote:

"Do we really need a "first prototype", "

Generally yes, it is often part of the specification process. 

Hi Geoff,

I'm a firm believer in prototyping, and I teach it as a technique, however I don't believe it's true to claim it's a general practice, and there are various contexts, including this one, where I don't think it's applicable.

Why not? Well:

 - This is not a new, unproven project or technology. 

 - There are various existing prototype examples available via google foo that can be referenced, if not for the whole system, then at least the core subsystems.

 - We're not designing for a product, or even a kit that might be produced and used by many people. To all practical purposes, this is a one off.

 - We have an established cultural precedent at CCHS of not doing staged protyping. Instead, we might optionally breadboard or veroboard a simple first prototype when trying out new components. But often, even if producing a PCB, we simply check and review the eagle schematics, and get boards produced.

 - it's the "hacker way" to hack a thing: to build a thing and then fix and improve it until it works. We've produced PCB's in quantities before, and needed to fix small oversights and mistakes. The problems are typically small, and can generally be corrected without significant drama.


Paul


On Monday, 10 September 2012 08:17:43 UTC+10, Luke Weston wrote:
Do we really need a "first prototype", as opposed to specifying it and doing it properly so that it's done right the first time, or as close to done right as can possibly be specified, designed and planned in advance?

There's no point in spending the time, resources and money to do it twice if you don't have to.

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-community-hacke...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-hackerspace+unsubscribe@googlegroups.com.

tubular

unread,
Sep 10, 2012, 7:53:57 AM9/10/12
to connected-commu...@googlegroups.com
Is there any sub-task that we could get started on while the software and micro is being sorted out? 

Would replacing the side door deadlatch with a latch & electronic strike (fail-secure) be worthwhile yet, or is it too early?  Keep the key barrel the same, so the door could still be opened manually until the smarts are ready to deploy


Stefan Lacombe

unread,
Sep 10, 2012, 8:49:00 AM9/10/12
to connected-commu...@googlegroups.com

An Electronic strike can be used as a normal strike. When it is not powered, the door can still be opened normally by key or lever as that retracts the tongue of the lock from the strike.

Also, an electronic strike doesn't need to be installed by a lock smith. A competant carpenter or handy man shouldn't have any trouble installing a strike. It just takes a bit of care and attention.

Stefan

On 10/09/2012 9:53 PM, "tubular" <lac...@tubularcontrols.com> wrote:

Is there any sub-task that we could get started on while the software and micro is being sorted out? 

Would replacing the side door deadlatch with a latch & electronic strike (fail-secure) be worthwhile yet, or is it too early?  Keep the key barrel the same, so the door could still be opened manually until the smarts are ready to deploy




--
You received this message because you are subscribed to the Google Groups "Connected Communit...

To view this discussion on the web, visit https://groups.google.com/d/msg/connected-community-hackerspace/-/SFiYmIbWCkgJ.

Geoff

unread,
Sep 10, 2012, 10:49:13 AM9/10/12
to connected-commu...@googlegroups.com
Thank you for your offer and yes we could do with some help from someone who is able to install a latch and strike. 

We are waiting on the OK from the landlord.

I will be at the space Tuesday if you would like to chat. 


Geoff

Geoff

unread,
Sep 10, 2012, 11:00:11 AM9/10/12
to connected-commu...@googlegroups.com
Thank you for this information, plain to checkout Dorma and Assa abloy websites. 

Barbara

unread,
Sep 10, 2012, 7:17:08 PM9/10/12
to connected-commu...@googlegroups.com

Just so... I have already donated a new electronic strike, something like this http://img.diytrade.com/cdimg/804427/7038585/0/1223110971/Electric_strike_lock.jpg -- don't hold me to it, I don't know the brand exactly, I think it was a 12V one. It's in the space somewhere.

It has a tongue sense inside and so can "know" whether the door is open or shut (respectively, whether someone clamps back the tongue sense with a finger).

Any chance to get involved in this project?

Cheers

Barbara

You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.

Jonathan Oxer

unread,
Sep 10, 2012, 7:18:05 PM9/10/12
to connected-commu...@googlegroups.com
Perhaps this has already been discussed and dismissed, but just in
case anyone here isn't aware of it there's also the SNARC project at
Hackerspace Brisbane:

http://www.hsbne.org/projects/SNARC

I'm on both mailing lists and there's been a remarkably similar
discussion happening in parallel on both lists, with the difference
that HSBNE started the process significantly earlier and are more
progressed. They've gone through a couple of generations of hardware
to end up with the board shown on the page above. Perhaps it's worth
joining forces?

Lemming and co have done some *really* cool stuff on the software
side, too, such as linking it to Google Docs so the list of card
holders can be maintained simply by updating a spreadsheet.

Cheers

Jon

Stefan Lacombe

unread,
Sep 10, 2012, 7:52:34 PM9/10/12
to connected-commu...@googlegroups.com

There is another thing to consider with an E strike, does it work with the lock being used? If the current lock is a dead latch mountes on the surface of the door, then a surface mounted strike is required.  To use the donated strike which is installed in a rebate in the door frame would require a morticed lock installed in the edge of the door which is more work. It also depends on whether the door swings in or out.  I've also noticed that the door frame is loose in the brickwork.  A couple of Dyna bolts will need to be installed to make it secure again.

Architects always make mistakes with door hardware as it can be more complex than most people expect. I will try to drop by the space tonight but i'll only be in briefly.

Stefan


--
You received this message because you are subscribed to the Google Groups "Connected Community ...

Stuart Young

unread,
Sep 10, 2012, 8:33:43 PM9/10/12
to connected-commu...@googlegroups.com
On 11 September 2012 09:52, Stefan Lacombe <stefan...@gmail.com> wrote:

There is another thing to consider with an E strike, does it work with the lock being used?


We will have to replace the lock anyway, as the current lock is an E-shape vertical deadbolt (aka a copy of a Lockwood 355), which I believe there isn't an electronics strike option for (we all looked, a lot).
 

If the current lock is a dead latch mountes on the surface of the door, then a surface mounted strike is required.  To use the donated strike which is installed in a rebate in the door frame would require a morticed lock installed in the edge of the door which is more work.


You can get surface mounted bolts for outward opening doors, like the Lockwood 509: http://www.lockweb.com.au/en/site/lockweb/Products/?groupId=473&productId=753

That said, there are other requirements hat may rule out that sort of lock.

IMO the strike won't fit in a standard morticed configuration. The frame is too thin, and we'd have to cut into the brick to get it in place, which I wouldn't recommend even trying given how tough the brick has proved when we put up the shelving.

It also depends on whether the door swings in or out.


Door swings out. Yes this makes it difficult IMO.
 

  I've also noticed that the door frame is loose in the brickwork.  A couple of Dyna bolts will need to be installed to make it secure again.


Already planned, but nothing done as yet. Didn't want to go ahead and do something, then find we'd put the dyna bolts in the wrong place (eg: if the door needed to be re-hung).
 

tubular

unread,
Sep 10, 2012, 9:02:05 PM9/10/12
to connected-commu...@googlegroups.com
On Tuesday, 11 September 2012 10:34:05 UTC+10, Cefiar wrote:
On 11 September 2012 09:52, Stefan Lacombe <stefan...@gmail.com> wrote:

There is another thing to consider with an E strike, does it work with the lock being used?


We will have to replace the lock anyway, as the current lock is an E-shape vertical deadbolt (aka a copy of a Lockwood 355), which I believe there isn't an electronics strike option for (we all looked, a lot).
 

If the current lock is a dead latch mountes on the surface of the door, then a surface mounted strike is required.  To use the donated strike which is installed in a rebate in the door frame would require a morticed lock installed in the edge of the door which is more work.


You can get surface mounted bolts for outward opening doors, like the Lockwood 509: http://www.lockweb.com.au/en/site/lockweb/Products/?groupId=473&productId=753

That said, there are other requirements hat may rule out that sort of lock.

IMO the strike won't fit in a standard morticed configuration. The frame is too thin, and we'd have to cut into the brick to get it in place, which I wouldn't recommend even trying given how tough the brick has proved when we put up the shelving.


How about we just mount Barbara's strike in its own ~35mm deep rebated wooden block, then this can be screwed to the existing frame with countersunk screws, so we don't have to get into the brickwork, and wouldn't have to make a potential mess that the landlord could object to?   

It would cut down the opening slightly, but its a very wide door, wider than the access path I think. 

The electronic strike and latch can be located below the existing deadlock, we can just remove the old catch once we cut over to our new system 

Does anyone have a latch spare to donate?  Or is there budget for this?   I have suitable hole saws

 

It also depends on whether the door swings in or out.


Door swings out. Yes this makes it difficult IMO.

The side door is a bit unusual, but the latch doesn't have to be at the very perimeter, it'll work fine inset

Stefan Lacombe

unread,
Sep 10, 2012, 10:38:57 PM9/10/12
to connected-commu...@googlegroups.com

Sorry, mounting the strike we have on a block is unlikly to work as it has to sit at least 2mm clear of of the edge of the door.  Creating a pocket in the brick work isn't a huge drama provided you have the appropriate tools.

I'll be at the space at about 6 for half an hour or so to get a better idea of what we have and what we need re the hardware.

As the door has an E type lock, we'll have to change everything on this door to make any Elec strike work.

Stefan

On 11/09/2012 11:02 AM, "tubular" <lac...@tubularcontrols.com> wrote:

On Tuesday, 11 September 2012 10:34:05 UTC+10, Cefiar wrote:


>
> On 11 September 2012 09:52, Stefan Lacombe <stefan...@gmail.com> wrote:
>>

>> There is another ...

How about we just mount Barbara's strike in its own ~35mm deep rebated wooden block, then this can be screwed to the existing frame with countersunk screws, so we don't have to get into the brickwork, and wouldn't have to make a potential mess that the landlord could object to?   

It would cut down the opening slightly, but its a very wide door, wider than the access path I think. 

The electronic strike and latch can be located below the existing deadlock, we can just remove the old catch once we cut over to our new system 

Does anyone have a latch spare to donate?  Or is there budget for this?   I have suitable hole saws



 
>>
>> It also depends on whether the door swings in or out.
>
>

> Door swings out. Yes this make...

The side door is a bit unusual, but the latch doesn't have to be at the very perimeter, it'll work fine inset

--
You received this message because you are subscribed to the Google Groups "Connected Community...

To view this discussion on the web, visit https://groups.google.com/d/msg/connected-community-hackerspace/-/y-io60P1eFUJ.

Geoff

unread,
Sep 11, 2012, 1:59:57 AM9/11/12
to connected-commu...@googlegroups.com
Hi Jon

Thank you for this info.

To the best of my knowledge we did not know about this project at Hackerspace Brisbane. 

In hindsight I should have been looking at other Hackerspaces, thank you again for spotting this very apt project. 


Regards
Geoff

Geoff

unread,
Sep 11, 2012, 2:06:39 AM9/11/12
to connected-commu...@googlegroups.com, barbara-h...@wolffh.de
Hi Barbara,

"Any chance to get involved in this project?"

Yes, we meet to work on the project on Tuesdays nights.


Regards
Geoff
To post to this group, send an email to connected-community-hacke...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-hackerspace+unsubscribe@googlegroups.com.

tubular

unread,
Sep 11, 2012, 2:26:53 AM9/11/12
to connected-commu...@googlegroups.com
On Tuesday, 11 September 2012 12:38:58 UTC+10, StefanL wrote:

Sorry, mounting the strike we have on a block is unlikly to work as it has to sit at least 2mm clear of of the edge of the door.  Creating a pocket in the brick work isn't a huge drama provided you have the appropriate tools.

I'll be at the space at about 6 for half an hour or so to get a better idea of what we have and what we need re the hardware.

It doesn't have to be at the edge, in a similar way the existing E-style deadlock is not at the edge, but is set in from the edge.  Provided both the lock and electric strike are offset appropriately it'll still work. 

I can also swing past at 6 for up to an hour, lets have a close look at it, get some photos, see what we can do to help Geoff and Mathew too

Geoff

unread,
Sep 11, 2012, 2:56:29 AM9/11/12
to connected-commu...@googlegroups.com
Thank you

Andy Gelme

unread,
Sep 11, 2012, 2:56:53 AM9/11/12
to connected-commu...@googlegroups.com
hi All,

On 2012-09-11 09:18 , Jonathan Oxer wrote:
> Perhaps this has already been discussed and dismissed, but just in
> case anyone here isn't aware of it there's also the SNARC project at
> Hackerspace Brisbane:

I bought one of the early SNARC prototype boards. I'll bring it in so
people can have a look.

In comparison, learning about NFC seems like a timely thing to do.

It would appear that the most significant and costly exercise will be
the mechanical design around the installation of the electric lock / strike.

--
-O- cheers = /\ /\/ /) `/ =
--O -- http://www.geekscape.org --
OOO -- an...@geekscape.org -- http://twitter.com/geekscape --

Luke Weston

unread,
Sep 11, 2012, 5:33:53 AM9/11/12
to connected-commu...@googlegroups.com
Hi Jon,

There are a couple of unacceptable problems with this, in my opinion:

a) Doesn't have rounded corners.
b) Ugly boring green soldermask.



Kidding. :P

On Tuesday, 11 September 2012 09:18:07 UTC+10, Jonathan Oxer wrote:

Stuart Young

unread,
Sep 11, 2012, 7:18:34 AM9/11/12
to connected-commu...@googlegroups.com
Just a note for those working on the CCHS setup.

We've moved the wiki page. It's now properly classed as a project in the wiki and linked off the front page of the wiki.

Mathew McBride

unread,
Sep 11, 2012, 10:18:39 AM9/11/12
to connected-commu...@googlegroups.com

Lots of progress was made tonight - quite a few people had a look in
with regards to fitting a strike to the door, and as I understand it,
plans for modification need to be drawn up and approved by the landlord.

I started writing a prototype of both the backend and frontend software
last week, and got them in a working state tonight. They are now both on
gitorious:

https://gitorious.org/mcbridematt-nfc-stuff/cchs-security-backend
https://gitorious.org/mcbridematt-nfc-stuff/cchs-security-frontend

The backend is currently a simple Django app - at the moment it consists
of two tables - cards and the event log. One could add cards via
Django's inbuilt admin interface.

I'm not sure if it will remain a Django app - a simpler,
direct-to-database architecture is what I have in mind - using the Kyoto
Tycoon[1] database software (which speaks HTTP natively). The readers
could then be made robust against backend server outages by
participating in database replication with the main server.

The frontend is written in C using libnfc/libfreefare and libcurl (to
communicate with the backend over HTTP).

I managed to get it running on a Raspberry Pi (thanks to Zac for lending
his). It was still quite responsive - around 2sec between successive
authentication events[2] - and this was through an FTDI USB dongle
rather than the native serial (I didn't have any jumpers/cables around
for that). This is with communication to the server on my laptop every
time a card is presented as well.

For a proof of concept I added hooks to send a character across the
serial port to an Arduino - to blink a LED if the presented card was
accepted.

Geoff is working on a control board for the door strike - once that is
available, we can make a working prototype, for the Raspberry-Pi based
route.

[1] - http://fallabs.com/kyototycoon/spex.html
[2] - in comparison, my laptop can do around 10 authenticate actions per
second. I added a simple 'debounce' function to ensure calls aren't made
if the same card remains on the reader for up to two seconds. This would
need to be made more intelligent - i.e ignore any cards on the reader if
the door latch is open as a result of an action in the past X seconds.
I hope using UART directly will be faster - but these times are fast
enough already :)

- Matt

Luke Weston

unread,
Sep 11, 2012, 11:32:51 AM9/11/12
to connected-commu...@googlegroups.com


For a proof of concept I added hooks to send a character across the
serial port to an Arduino - to blink a LED if the presented card was
accepted.


Seems like a waste of an Arduino, what's your reasoning behind not simply driving the LED off the RP GPIOs?

Cheers,
  Luke 

George Patterson

unread,
Sep 11, 2012, 4:34:43 PM9/11/12
to connected-commu...@googlegroups.com
On 12 September 2012 00:18, Mathew McBride <ma...@bionicmessage.net> wrote:
>
> Lots of progress was made tonight - quite a few people had a look in with
> regards to fitting a strike to the door, and as I understand it, plans for
> modification need to be drawn up and approved by the landlord.
>
> I started writing a prototype of both the backend and frontend software last
> week, and got them in a working state tonight. They are now both on
> gitorious:
>
> https://gitorious.org/mcbridematt-nfc-stuff/cchs-security-backend
> https://gitorious.org/mcbridematt-nfc-stuff/cchs-security-frontend
>

Eeek! Nice work but with a possible gotchya...

> The backend is currently a simple Django app - at the moment it consists of
> two tables - cards and the event log. One could add cards via Django's
> inbuilt admin interface.

Ideally the security/door access system should rely on the CCHS
Membership CMS system that I believe Chris Pendlebury was
recommending. Otherwise it's another system that a time-stressed
committee member will have to maintain and remember to revoke a card
when necessary while amending the membership record.

Regards


George

Mathew McBride

unread,
Sep 11, 2012, 6:38:58 PM9/11/12
to connected-commu...@googlegroups.com
Didn't have any connectors around - and I had actually done that on my laptop before porting it over. It is merely a proof of concept to ensure other peripherals can be plugged in. The finished product would use the GPIOs directly.

That was actually the first time I had played with a Pi.. Is someone in a better position to write code that manipulates the GPIOs from userspace?

On 12/09/12 6:34 AM, George Patterson wrote:

Ideally the security/door access system should rely on the CCHS
Membership CMS system that I believe Chris Pendlebury was
recommending. Otherwise it's another system that a time-stressed
committee member will have to maintain and remember to revoke a card
when necessary while amending the membership record.

Regards


George

Can we integrate it into there somehow? Good that it has come up now before I write any code that depends on backend features.
A backend will need to store other card details, possibly including a salt or other details used to determine the validity of the card.


Stuart Young

unread,
Sep 11, 2012, 7:28:59 PM9/11/12
to connected-commu...@googlegroups.com
On 12 September 2012 08:38, Mathew McBride <ma...@bionicmessage.net> wrote:
On 12/09/12 6:34 AM, George Patterson wrote:

      
Ideally the security/door access system should rely on the CCHS
Membership CMS system that I believe Chris Pendlebury was
recommending. Otherwise it's another system that a time-stressed
committee member will have to maintain and remember to revoke a card
when necessary while amending the membership record.

Regards


George

Can we integrate it into there somehow? Good that it has come up now before I write any code that depends on backend features.
A backend will need to store other card details, possibly including a salt or other details used to determine the validity of the card.

The CMS runs physically outside the space, so the best way would be to extract data from the CMS regularly (eg: every hour?), with the CMS being the authorative system for the data. This way, if the update process fails, the cards as of that point will be authorative.

FWIW: We could also have a 'core set' of cards (eg: Committee et al) that are the only ones allowed if the update process fails for more than a set time (eg: 1-2 days) - effectively reducing access issues due to problems caused by out-of-date data.

Really, for security, we definitely want this process to be one-way, so that there is no way for the system to be 'hacked' to put data back into the CMS (ie: for it to manipulate the authorative data permanently). All the data should be synced (it won't be that big), as that way if the data gets corrupted/altered, the next update fixes it.

This of course means that we DO need a way to load this data into the CMS using a NFC interface say plugged into a PC to read the necessary details, which are then loaded into the CMS (eg: manually).

I know we can create custom fields in the DB, so we should then be able to create fields that will contain the card data. Of course this means that the data needs to be maintained, but this way it'll all be in one place, and just pushed down to the system at Kent Lane.

Mathew McBride

unread,
Sep 11, 2012, 7:53:55 PM9/11/12
to connected-commu...@googlegroups.com
On 12/09/12 9:28 AM, Stuart Young wrote:
Can we integrate it into there somehow? Good that it has come up now before I write any code that depends on backend features.
A backend will need to store other card details, possibly including a salt or other details used to determine the validity of the card.

The CMS runs physically outside the space, so the best way would be to extract data from the CMS regularly (eg: every hour?), with the CMS being the authorative system for the data. This way, if the update process fails, the cards as of that point will be authorative.

FWIW: We could also have a 'core set' of cards (eg: Committee et al) that are the only ones allowed if the update process fails for more than a set time (eg: 1-2 days) - effectively reducing access issues due to problems caused by out-of-date data.

Really, for security, we definitely want this process to be one-way, so that there is no way for the system to be 'hacked' to put data back into the CMS (ie: for it to manipulate the authorative data permanently). All the data should be synced (it won't be that big), as that way if the data gets corrupted/altered, the next update fixes it.

This of course means that we DO need a way to load this data into the CMS using a NFC interface say plugged into a PC to read the necessary details, which are then loaded into the CMS (eg: manually).

I know we can create custom fields in the DB, so we should then be able to create fields that will contain the card data. Of course this means that the data needs to be maintained, but this way it'll all be in one place, and just pushed down to the system at Kent Lane.

Sounds like a workable solution.

Ideally a card would need to be 'formatted' before use (set security bits on the card etc.) - would having a dedicated* PC at the space with a NFC reader attached be acceptable for provisioning? It would format the card as well as telling which details would need to be loaded into the CMS.

* dedicated or otherwise secure enough so that sensitive details (such as security keys) aren't accessible to anybody who walks along.

tubular

unread,
Sep 11, 2012, 7:59:10 PM9/11/12
to connected-commu...@googlegroups.com
Here's the "hardware" plan as I understand it from last night: 

* We resolved to use Barbara's electric strike, as there is enough meat on the door frame to mount it nicely, and its a good quality unit.   Thanks Barbara

* We're looking for a suitable latch, like this one:- 

* Stefan is looking to see if he has something similar left over from a building project.   Failing that we'll ask for a donation (of latch, or money to buy one) 

* The RFID reader will be in window area next to the door.  

* I have a 3U rack plate (front panel), which I'll mount a power supply onto with correct earthing, strain relief etc.  The Raspberry Pi / Spinneret / SPARC and Geoff's driver board can be mounted on there.  I'll drill holes to suit the new v2 Pi mounting holes even though we might just d/s tape a pi box on for now to make mounting easier.  

* The power supply is a jaycar 60w - puts out 5v at 4 amps and 12v at 3 amps, which should be plenty for what we're currently planning plus some expansion.   I'll check its no load consumption today. 

* We'll have a mini working bee some Saturday arvo, when Rasp Jam aren't using the space, to install, and dynabolt reinforce the frame which is a bit loose.  We'll also run some cables in a surface duct for the RFID reader (PN532), electric strike, indicator lights/lcd etc.  

* For the landlord's approval:- 
We propose to add a single cylinder deadlatch and electric strike above the existing E style lock.   The Electric strike is a "fail secure" model, so can be used just like a normal door strike in the absence of any electric control signal.   The existing double cylinder E lock will be left in place, locked in the open position.  

wes Black

unread,
Sep 11, 2012, 8:26:31 PM9/11/12
to connected-commu...@googlegroups.com
Are you all reading the wiki page and google doc on this?

Much has been discussed there. And there are photos.

Also, keep in mind we need to ensure that no-one can break the window to reach through and open the door via the handle that must be free to open at all times esp. in event of fire/smoke, etc.

The E-rim is not compatible with this paradigm.

Please check the pertinent pages after the hackmelb.org server picks itself up, dusts self off (seems to be having problems at the moment, otherwise I'd include links).

Wes

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msg/connected-community-hackerspace/-/6KSAZwgx5WwJ.

Andy Gelme

unread,
Sep 11, 2012, 9:19:13 PM9/11/12
to connected-commu...@googlegroups.com
hi All,


On 2012-09-12 10:26 , wes Black wrote:
Please check the pertinent pages after the hackmelb.org server picks itself up, dusts self off (seems to be having problems at the moment, otherwise I'd include links).

The CCHS web server is http://hackmelbourne.org (which does appear to be having trouble).



On 12 September 2012 09:59, tubular <lac...@tubularcontrols.com> wrote:
* The RFID reader will be in window area next to the door.

NFC reader.


* We'll have a mini working bee some Saturday arvo, when Rasp Jam aren't using the space, to install, and dynabolt reinforce the frame which is a bit loose.  We'll also run some cables in a surface duct for the RFID reader (PN532), electric strike, indicator lights/lcd etc.

Not RFID ... NFC.


* For the landlord's approval:- 
We propose to add a single cylinder deadlatch and electric strike above the existing E style lock.   The Electric strike is a "fail secure" model, so can be used just like a normal door strike in the absence of any electric control signal.   The existing double cylinder E lock will be left in place, locked in the open position.

Thanks.

Apart from applying dynabolts to reinforce the door frame and running cabling ... is there any other proposed works, e.g changes to the door, door frame or surrounding areas ?

tubular

unread,
Sep 11, 2012, 10:10:41 PM9/11/12
to connected-commu...@googlegroups.com, Andy Gelme
Not RFID ... NFC.


Yes, NFC.  Even better :) 

Apart from applying dynabolts to reinforce the door frame and running cabling ... is there any other proposed works, e.g changes to the door, door frame or surrounding areas ?


I think this is the minimum, and we should focus on the minimum until we get something running.   Exterior lighting may not be as big an issue with evening light getting longer

How about we also get approval for boarding up the inside of the window with some thick MDF or similar, to prevent Wes's concern about being able to smash the window and open the door?  It could just cover the half of window closest to the door, or cover the full width but with a small cutout for PN532 board.

Hackmelbourne seems to still be down, but are there links to the google doc?  

Stuart Young

unread,
Sep 12, 2012, 1:04:08 AM9/12/12
to connected-commu...@googlegroups.com

Sounds good to me.

FWIW: As I was typing the above email, I was actually just about to walk into a work meeting and wanted to get my thoughts out for discussion. As Wes says, we need to document stuff. However this should only happen once some sort of consensus is reached, which was the whole point of putting the info out there - for discussion. I have since updated the wiki page as appropriate, with a new section at the bottom for "Discussed Ideas".

wes Black

unread,
Sep 12, 2012, 7:31:20 PM9/12/12
to connected-commu...@googlegroups.com
Nice wadge of clear polycarbonate over a a good proportion of the window at RHS... or even replacing the glass entirely would prevent forced entry by smashing glass, reaching in and activating handle.

Easier than changing the door hinges/geometry.

Also, maybe not so good having door hinges swapped to other side given the wall on that side may cause bottleneck for rapid egress of estimated/proposed max number of people in Hackerspace.

W


--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.

Stuart Young

unread,
Sep 12, 2012, 8:06:36 PM9/12/12
to connected-commu...@googlegroups.com
On 13 September 2012 09:31, wes Black <wesd...@gmail.com> wrote:
Nice wadge of clear polycarbonate over a a good proportion of the window at RHS... or even replacing the glass entirely would prevent forced entry by smashing glass, reaching in and activating handle.

Assuming we can get hold of a free piece of polycarbonate the size of the window - and unless it's free it definitely won't be cheap.

We have wood on hand so we'll probably use that, at least in the interim. We can always replace/augment it down the track.

Note that we'll probably just place the wood BEHIND the existing glass, as then we don't have to remove the actual glass (and it'll protect the wood from exposure).
 
Easier than changing the door hinges/geometry.

Also, maybe not so good having door hinges swapped to other side given the wall on that side may cause bottleneck for rapid egress of estimated/proposed max number of people in Hackerspace.

This has been discussed a number of times beforehand (on list and off) and on Tuesday night.

We had pretty much already determined on list, even before Tuesday, that we can add a new lock in parallel to the existing lock, and cover the window, without having to re-hang the door. This was confirmed as 100% feasible on Tuesday night. This way, we don't have to remove the old lock, just leave it permanently unlocked. It also gives us a fallback if the new lock mechanism for whatever reason doesn't engage (eg: tongue on the strike breaks/sticks in an unlock position), so we can lock the space.

FWIW: Lachlan and Stefan are running with the lock installation stuff. This still needs to be approved by the landlord, so they're coming up with a plan to present to the landlord while working on smaller stuff that also needs to be done (such as running cabling, boxing up the electronic stuff into a nice rack-mount unit, etc). The smaller stuff will need to be done regardless, and isn't dependant on us waiting for approval from the landlord. I won't speak on their behalf as to details, but they have a plan.

The wiki page hasn't been updated to reflect any of these facts (that I can see). I know that Lachlan has only just gotten access to the wiki, and is probably going through brushing up on all the basic syntax and stuff to put in decent looking content.

Note: I updated the wiki page with the stuff I contributed on the mailing list about data flow between the CMS and the access system that will be located in the space. I don't want to put in stuff that I wasn't 100% involved in. I was only involved in some parts of it, as I was busy doing other stuff as well.

tubular

unread,
Sep 12, 2012, 9:30:47 PM9/12/12
to connected-commu...@googlegroups.com
6mm clear polycarbonate, cut to size is about $200 a square metre.  We have a sheet at work that could be cut up, but it would need to be paid for, and I think it really falls into the luxury category.   Also if (when) we outgrow the space, we can take the security assets but improvements that get left behind are wasted dollars.  

If we go with some thick MDF and cover say the 75% of window nearest the door, it would still let us reach in from the open 25% to mount the PN532 and usage notes/conditions that would be visible from the window.  

Re-reading Andy's email above, and including Wes's comments, how about we seek Landlord approval for... 

* We propose to add a single cylinder deadlatch and electric strike above the existing E style lock.   The Electric strike is a "fail secure" model, so can be used just like a normal door strike in the absence of any electric control signal.   The existing double cylinder E lock will be left in place, locked in the open position.   
* Reinforcing the existing loose door frame with 2 or 3 dynabolts into the brickwork
* Covering approximately 75% (50~90%) of the window adjacent to the door with thick MDF board, to improve security against people reaching through broken window to open the door handle inside
* Mount some cable duct along the existing wall using nails & masonry plugs for the security electrics


Andy Gelme

unread,
Sep 12, 2012, 10:42:50 PM9/12/12
to connected-commu...@googlegroups.com
hi Lachlan,

On 2012-09-13 11:30 , tubular wrote:
> Re-reading Andy's email above, and including Wes's comments, how about
> we seek Landlord approval for...
>
> * We propose to add a single cylinder deadlatch and electric strike
> above the existing E style lock. The Electric strike is a "fail
> secure" model, so can be used just like a normal door strike in the
> absence of any electric control signal. The existing double cylinder
> E lock will be left in place, locked in the open position.
> * Reinforcing the existing loose door frame with 2 or 3 dynabolts into
> the brickwork
> * Covering approximately 75% (50~90%) of the window adjacent to the
> door with thick MDF board, to improve security against people reaching
> through broken window to open the door handle inside
> * Mount some cable duct along the existing wall using nails & masonry
> plugs for the security electrics

Great, let's run with that.

Barbara

unread,
Sep 12, 2012, 10:44:02 PM9/12/12
to connected-commu...@googlegroups.com
Thanks, Matt, for posting the repository.

Summary:

-------------------------
Architecture:

Current prototype: Server written in Python talking to a (currently
django) database on the same machine.
It runs on a laptop PC. Client written in C and running on a
Raspberry PI that gets input from a card reader,
asks the server whether the card is valid, does some action
accordingly, and logs the event back to the
server. Action is currently just an LED, but

Planned:
* control board attached to the door strike, connected to Raspberry
PI as "output" unit, to open the door(or not).
* "valid card database" to be gotten/compiled at regular intervals
from the CCHS membership list on www.hackmelbourne.org.

Questions:

* Where would the Raspberry PI be mounted? Where would the server be
located?

* Note that there is not necessarily a 1-to-1 relationship between
CCHS members and cards.
Some members may have more than one card, some members may have
none, some members may even share cards
(say, Holger and Barbara)

--------------------------
What do we want to do with this? Maybe we could formulate some user
stories?
I have some like these in mind:

- Fred presents a card, door unlocks for 5 or 10 seconds, and locks
again when Fred is through and
closes it again.
- Gretchen presents a card (and does something else?) and the door
unlocks permanently, for everyone to follow
that afternoon. For example, she might present the card 3 times in a
row.
- Henry presents a card (and does something else?) and the door now
locks permanently until the next
card access. For example, she might present the card 3 times in a
row.
- Inez gets a new card out of the box, formats it, reads it into the
system and "assigns it to Jason" so
that Jason is now in the CCHS membership list and the card in the
valid card database.
- Keilor is moving to Sydney and is considerate enough to return his
card, which should now be "de-assigned"
and can be given to someone else.
- Lara has disappeared, has not paid membership fees for the last half
year, and we don't know where her card
is; we need to make it invalid and remember that somehow, so no one
can get through the door with this card.
- Lara appears again, dutifully pays her membership fees and wants to
get access again with her card.
- Michael has lost his card, we need to mark his card as invalid and
give him a new one.
- Natalie wants to look up who last unlocked the door, and when it was
last locked.
- Oren wants to know which cards have not been seen at the door for
the last half year.
- Phoebe has just left the space and driven 5 km and now wants to
check if she actually locked the door.


Just for discussion -- are there more? Are all of these wanted? What
are the priorities?

Barbara Maren

Am 12.09.2012 00:18, schrieb Mathew McBride:
..,

Paul Szymkowiak

unread,
Sep 12, 2012, 11:03:45 PM9/12/12
to connected-commu...@googlegroups.com
Good start

> Just for discussion -- are there more? Are all of these wanted? What are the priorities? 

 - A card that has been marked invalid (such as the one Michael lost, or assigned to a member similar to Lara with unpaid facilities fees), is presented at the door. (I assume this access attempt would be logged, but should the system alert anyone, including the person the card is assigned to?)



Paul


--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-community-hacke...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-hackerspace+unsubscribe@googlegroups.com.

tubular

unread,
Sep 13, 2012, 1:09:59 AM9/13/12
to connected-commu...@googlegroups.com
Regarding where to mount the Pi, I see two options 

1) Near the electric door strike, perhaps on the back of the mdf we're about to cover the window with.   Advantages are
- Could have a transparent box to show off as a completed working project
- Easier to work on as a complete system outside the hackerspace, 
- Could add a small composite video display for the Pi, to show status, welcome messages etc
Disadvantage: security (someone could just replace the SD card with something that logged details etc) 

2) Inside the server rack
- This is where the power supply is planned to be 
- Less security risk, assuming the rack can be locked
- Can still see through the rack grille to view the finished project.  Could illuminate it with leds, or still have a composite display
- Central point for extending future functionality, eg picking up status from other hackerspace equipment 

Cabling wise there is not a huge difference - if the Pi is in the field it needs power and ethernet.   And if it isn't the cables are Strike power, Strike Status, PN532. 

George Patterson

unread,
Sep 13, 2012, 1:13:53 AM9/13/12
to connected-commu...@googlegroups.com
On 13 September 2012 13:03, Paul Szymkowiak <paul...@gmail.com> wrote:
> Good start
>
>> Just for discussion -- are there more? Are all of these wanted? What are
>> the priorities?
>
> - A card that has been marked invalid (such as the one Michael lost, or
> assigned to a member similar to Lara with unpaid facilities fees), is
> presented at the door. (I assume this access attempt would be logged, but
> should the system alert anyone, including the person the card is assigned
> to?)
>

It may be more sensible to not reuse the same card identifier,
though dependent on how large the unique identifier is for the
cards. Perhaps write a larger identifier to the card so if the short
id matches, the system also checks the larger identifier.

So in the scenario that Paul outlined:

Person Short id long id
Lara 0100 92e56412-3514-47d6-8717-103405757dba
Mike 0100 c35a855d-5f30-4482-9409-91118415dbd1

Note: The long id above were generated using uuidgen on a Linux
machine. It has been dependable enough when I have used it in the past.

Regards



George

Mathew McBride

unread,
Sep 13, 2012, 4:25:21 AM9/13/12
to connected-commu...@googlegroups.com

On 13/09/12 3:13 PM, George Patterson wrote:
> On 13 September 2012 13:03, Paul Szymkowiak <paul...@gmail.com> wrote:
>> Good start
>>
>>> Just for discussion -- are there more? Are all of these wanted? What are
>>> the priorities?
>> - A card that has been marked invalid (such as the one Michael lost, or
>> assigned to a member similar to Lara with unpaid facilities fees), is
>> presented at the door. (I assume this access attempt would be logged, but
>> should the system alert anyone, including the person the card is assigned
>> to?)
>>
> It may be more sensible to not reuse the same card identifier,
> though dependent on how large the unique identifier is for the
> cards. [snip]
>

The cards we are using have a hard coded 4 byte serial UID (think MAC
address), which will form one part of the authentication procedure.
Spoofing the above identifier is possible with home built kit (i.e a
ProxMark) or 'non-genuine' tags. (This is why I don't propose reusing
other NFC cards, i.e myki, from elsewhere)

The next part is to have the 'passwords' on the card based on a
derivation of the UID+a unique salt stored on the server. And possibly a
counter or other random data on there which is replaced on every
transaction and logged to the server on next access just to check no one
has had their card tampered or cloned while they weren't looking.

At the low prices the cards are available for (less than $1 in bulk),
I'm not sure the effort to 'recycle' the cards is worth it in light of
security considerations. They could definitely be wiped and made
available as test cards for future development or for anyone who wishes
to play around with NFC technologies...

Allowing for NFC-based phones in the future may present further
complications..
On 13/09/12 3:09 PM, tubular wrote:
> 1) Near the electric door strike, perhaps on the back of the mdf we're
> about to cover the window with. Advantages are
> - Could have a transparent box to show off as a completed working project
> - Easier to work on as a complete system outside the hackerspace,
> - Could add a small composite video display for the Pi, to show
> status, welcome messages etc
> Disadvantage: security (someone could just replace the SD card with
> something that logged details etc)
>
Some discussions I had with Geoff a week or two ago headed in the
direction of a 3d-printed sealed box (allowing for ventilation) that
would have some physical security features. We could take a lead from
the EFTPOS terminal industry - if the case gets opened, disable the
hardware.
http://hackaday.com/2011/11/23/name-these-parts-verifone-payment-module-tear-down/

Also, the intention is to present some kind of user feedback, via LEDs
or speakers.., as well as "reset" and other useful buttons.
> 2) Inside the server rack
> - This is where the power supply is planned to be
> - Less security risk, assuming the rack can be locked
> - Can still see through the rack grille to view the finished project.
> Could illuminate it with leds, or still have a composite display
> - Central point for extending future functionality, eg picking up
> status from other hackerspace equipment
>
> Cabling wise there is not a huge difference - if the Pi is in the
> field it needs power and ethernet. And if it isn't the cables are
> Strike power, Strike Status, PN532.
Be mindful there may be maximum wire length distances for the signals
between the Pi and associated electronics. I don't have any hard numbers
with me. The PN532<->Pi would be 3.3V @115200bps and the rest of the
factors would depend on the cable type.
We could easily get around that with additional electronics at both ends
of the cable.

- Mathew

tubular

unread,
Sep 13, 2012, 6:59:28 AM9/13/12
to connected-commu...@googlegroups.com
On Thursday, 13 September 2012 18:25:42 UTC+10, Mathew McBride wrote:
Some discussions I had with Geoff a week or two ago headed in the
direction of a 3d-printed sealed box (allowing for ventilation) that
would have some physical security features. We could take a lead from
the EFTPOS terminal industry - if the case gets opened, disable the
hardware.
http://hackaday.com/2011/11/23/name-these-parts-verifone-payment-module-tear-down/

Also, the intention is to present some kind of user feedback, via LEDs
or speakers.., as well as "reset" and other useful buttons.
 ...
Be mindful there may be maximum wire length distances for the signals
between the Pi and associated electronics. I don't have any hard numbers
with me. The PN532<->Pi would be 3.3V @115200bps and the rest of the
factors would depend on the cable type.
We could easily get around that with additional electronics at both ends
of the cable.

- Mathew

Ok.  Lets run a Cat5e and 7 core DC power cable (trailer cable) out to surface block on the MDF covering the window.   

The trailer cable is good for low voltage drop, and colours can be same as PC power supplies - Black/Red 5v/Yellow 12v.  The other cores can be future i/o or expansion.   


Message has been deleted

Geoff

unread,
Sep 13, 2012, 2:12:04 PM9/13/12
to connected-commu...@googlegroups.com

Your option one is what we have been planning on doing.

By putting the Pi in with the NFC reader we do not need to be concerned about exposing the connections, also protecting the box from being tampered with, we will know that someone may have replace the SD card.  


Jonathan Oxer wrote:

Perhaps this has already been discussed and dismissed, but just in 
case anyone here isn't aware of it there's also the SNARC project at 
Hackerspace Brisbane: 
http://www.hsbne.org/projects/SNARC 
I'm on both mailing lists and there's been a remarkably similar 
discussion happening in parallel on both lists, with the difference 
that HSBNE started the process significantly earlier and are more 
progressed. They've gone through a couple of generations of hardware 
to end up with the board shown on the page above. Perhaps it's worth 
joining forces? 
Lemming and co have done some *really* cool stuff on the software 
side, too, such as linking it to Google Docs so the list of card 
holders can be maintained simply by updating a spreadsheet.  

Option one is a proven approach. 


Regards
Geoff
Message has been deleted

Geoff

unread,
Sep 13, 2012, 3:52:27 PM9/13/12
to connected-commu...@googlegroups.com, Andy Gelme
Hi Andy

I was away from the google groups for two days and missed the lasted posts.

That list you have is for modification is incomplete, I posted the following but it seems to have been over looked:

Please add items 2, 3, and 4.

And could we please also look at adding:

Painting the door (may be police box blue?-)
A door-handle. 
And mounting a box for speaker/buzzer and led's. 


Regards
Geoff

PS: We need to know if the door is open or not. And if we mount a speaker/buzzer inside, people working near the door will get annoyed when the place is busy.

Barbara

unread,
Sep 13, 2012, 7:38:37 PM9/13/12
to connected-commu...@googlegroups.com

Hello Geoff,

I hope I'm not repeating myself... I thought people had decided to go with the electric door strike I donated for the rear door.

If so, the door strike can tell whether it's locked or not (i.e., whether the door strike engages, or not), and whether the tongue sense  inside the door strike is pushed back, or not (could be meaning that the door is actually shut), it has a tongue sense.

That is, we'd already have the strike and sensor  in one -- but not the lock (handle with keyed lock and bolt), of course.

If we need one of the sensors in your point 2 (http://www.dinodirect.com/Embedded-Door-Sensor-MC-36.html?cur=AUD&AFFID=97&utm_source=myshopping&utm_medium=cpc&utm_campaign=Security+Systems+and+Surveillance&utm_term=Embedded+Magnetic+Sensor+Alarm+Door+Security+System+MC+36), I think I might still have one lying around somewhere.

Regards

Barbara

 

Am 14.09.2012 03:45, schrieb Geoff:

Hi Andy
 
I was away from the google groups for two days and missed the lasted posts.
 
That list you have is for modification is incomplete, I posted the following but it seems to have been over looked:
 
Please add items 2, 3, and 4.
 
Regards
Geoff


On Thursday, 13 September 2012 12:43:02 UTC+10, andyg (@geekscape) wrote:

 

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.

tubular

unread,
Sep 13, 2012, 7:58:29 PM9/13/12
to connected-commu...@googlegroups.com, barbara-h...@wolffh.de
On Friday, 14 September 2012 09:38:39 UTC+10, Barbara wrote:

Hello Geoff,

I hope I'm not repeating myself... I thought people had decided to go with the electric door strike I donated for the rear door.

If so, the door strike can tell whether it's locked or not (i.e., whether the door strike engages, or not), and whether the tongue sense  inside the door strike is pushed back, or not (could be meaning that the door is actually shut), it has a tongue sense.

That is, we'd already have the strike and sensor  in one -- but not the lock (handle with keyed lock and bolt), of course.

We're going to use your strike on the side door, where it is relatively easy to add a latch.  We've confirmed it will fit nicely in the door frame.

Geoff's asking that we don't forget about some works at the rear (roller) door too.   Checking the open / closed status of the roller door should be easy enough and helps us to know if the space is closed 
That would be great if you could find one or two.  We'll find a way to interface it/them to the roller door. 


Am 14.09.2012 03:45, schrieb Geoff:

Please add items 2, 3, and 4.
 
Regards
Geoff


Geoff I need some more details on this 
- where are the wires to run to exactly?  Near the letterbox hatch?  
- what cables do you need - is it just for switch status, or do you want DC power for leds or a second card reader as well?  
- do you want the other end of the cables to go to your proposed Pi box near the window of the side door? 

Does anyone know of an easy way to allow the roller to be opened from the inside? 

Lachlan 

Andy Gelme

unread,
Sep 13, 2012, 8:26:51 PM9/13/12
to connected-commu...@googlegroups.com
hi Geoff,

On 2012-09-14 05:52 , Geoff wrote:
> 2. Add door sensors (to indicator an open door) eg.
> http://www.dinodirect.com/Embedded-Door-Sensor-MC-36.html?cur=AUD&AFFID=97&utm_source=myshopping&utm_medium=cpc&utm_campaign=Security+Systems+and+Surveillance&utm_term=Embedded+Magnetic+Sensor+Alarm+Door+Security+System+MC+36
>
>
> 3. To run some wires though to the outside near the rear door.
>
> 4. To modify the roller so it may be unlocked from the inside.
>
> Please add items 2, 3, and 4.
> And could we please also look at adding:
>
> Painting the door (may be police box blue?-)
> A door-handle.
> And mounting a box for speaker/buzzer and led's.

Okay.

Please keep in mind that the landlord is primarily interested in the
high-level details that affect the building in a significant way that
matters to him. Some of the low-level details, e.g low-impact non-240V
cabling or a buzzer ... really don't need to be churned over on this
email list in regards to what goes into the letter to the landlord.
Let's take this off-line, get it sorted and then report back to the
email list with the final decision. It'll drive everyone nuts ... if
every tiny detail is covered here. I think it is great that there is
lots of discussion and it's all moving forward ... but, there are around
500 people on this email list !

Regarding the roller door: That doesn't appear to have been figured out
to the point where we can proceed (unlike the side door). I think it is
better to ask the landlord ... once the plans for the roller door have
firmed up some more. I'd suggest that the side-door should get sorted
out first. Note: Installing a sensor (especially as a prototype) to
determine the roller door position shouldn't be an issue ... compared to
more significant works on the roller door (such as locks or changes to
the mechanical attachments) for which we should ask permission.

Luke Weston

unread,
Sep 14, 2012, 7:13:25 AM9/14/12
to connected-commu...@googlegroups.com
OK, so, I wasn't really sure whether people really have a strong preference one way or the other for either an AVR based system (with W5100 etc.) or the alternative which is the Raspberry Pi.

It wasn't really clear to me one way or the other from reading all these emails, and personally I think a Raspberry Pi is a little bit of overkill, so I decided to just draw up the schematic for the AVR based approach. (No-one really disagreed or said in any of these emails that there's any reason why an AVR-based system is bad, it's perfectly capable of doing the simple job required.)

The AVR --> PN532 interface is SPI in this case, because I thought it would be nice to remain consistent with the Adafruit PN532/Arduino tutorial pages and example code, which all use an SPI interface between PN532 and an Arduino.


The complete schematic is there in the PDF. (Obviously the PCB layout is farrr from complete at this point.)

I hope this is helpful.

Cheers,
  Luke

On Monday, 10 September 2012 00:02:22 UTC+10, Luke Weston wrote:
The Raspberry Pi is not a power inefficient device. It's very power efficient for what it can do.

I don't see why this system needs to be optimised for extremely low power. It's not a portable battery-operated device, it's a mains-powered device.

Seems like there are basically just a couple of decisions to make here in terms of hardware specification:

Core hardware architecture:
a) PN532 --> Raspberry Pi
b)  PN532 --> ATmega328 --> Wiznet W5100

a) Use off-the-shelf development modules/boards, eg. Adafruit PN532 board, EtherTen etc and wire them together with the extra bits required.
b) Custom bespoke PCB that nicely integrates everything required?

So, what other peripheral electronics is needed?

12V comes in from a mains plugpack. (I assume it's 12V for a 12V door strike, but it could be higher, say 24V or something, if that's what was required for a particular door strike / solenoid.)

(Keep in mind that the plugpack needs to have sufficient current capacity to run the solenoid as well as the other electronics.)

That 12V rail is supplied to the solenoid, which is low-side switched with an open-drain output switched from the Raspberry Pi or AVR - i.e. a suitably rated N-channel power FET.

The 12V also needs to be regulated down to 5V and 3.3V for the Raspberry Pi and PN532 or AVR and W5100.

An Arduino (including EtherTen, etc.) can obviously accommodate a 12V input directly and regulate it down, and it can also supply a 5V rail and 3.3V rail (depending on the Arduino model, many of them have no 3.3V rail available, or just the FT232RL's internal 3.3V reference, which has negligible current capacity) out to the PN532.

The Adafruit PN532 board has a 3.3V regulator on it... it needs to be supplied with 5V, and a Raspberry Pi needs to be supplied with regulated 5V too.

And you want a little bit of peripheral hardware for status output to the user too - like a LED or two, and/or a small piezo buzzer, switched by digital GPIOs on the Raspberry Pi or AVR.

So, personally, that's what I think the hardware will look like.

Luke Weston

unread,
Sep 14, 2012, 7:19:54 AM9/14/12
to connected-commu...@googlegroups.com
Hmm, the SilverTel Ag5100 802.3af POE negotiator/regulator has a maximum power output of 30W, which is 2.5A at 12V.

Will that be enough to run the solenoid? (let's say 2A for the solenoid, leaving 500 mA for the other electronics.)

If so, then 802.3 will work, meaning that there's no need to run any other power wiring or supplies. Our switch supports it, right?

Cheers,
  Luke

Geoff

unread,
Sep 14, 2012, 7:57:37 AM9/14/12
to connected-commu...@googlegroups.com, barbara-h...@wolffh.de
Yes, we will be going with your kindly donated door strike.

The thing with them is, they are easily seen, easy to play with (and to bypass), we need to know if the door is open or not. 

The door switch in the latch and a sensor provide more information on which to decide the state of the door:
1. door closed
2. door open
3. door latch switch has been duck tapped.

You may say that the sensor could be bypassed; but sensor is not in plain sight (could be painted over) and it has some protection by the bricks. And we could add an other sensor with no magnet to see if someone is trying to bypass the sensors (this may be going to far).    


Regards
Geoff

On Friday, 14 September 2012 09:38:39 UTC+10, Barbara wrote:
To post to this group, send an email to connected-community-hacke...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-hackerspace+unsubscribe@googlegroups.com.

Geoff

unread,
Sep 14, 2012, 8:10:29 AM9/14/12
to connected-commu...@googlegroups.com, Andy Gelme
Hi Andy

Could we (including who will be emailing the landlord so everything is clear) please book some time to meet face to face next Tuesday night at the space to chat about the details for the landlord?

On the matter of the roller door, it can not be opened from the inside, this is the only change we need to make now. 

Regards
Geoff

Stuart Young

unread,
Sep 14, 2012, 9:48:37 AM9/14/12
to connected-commu...@googlegroups.com

The 802.3af spec has a max guaranteed power output of 12.95W at the device end. At 12V this is just over 1A max. You might get 14.5W if you are lucky.

Anything more than this is out of spec for 802.3af (either vendor specific stuff or 802.3at qualifies). Our switch is only marked for 802.3af that I am aware of.

Unless you know the switch will put out more than this, I would assume that is the max you will get.

PS: This is why I always doubt vendor specs.

PPS: The Wikipedia page for 802.3af covers all the gotchas for power limits.

--
Cef

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To post to this group, send an email to connected-commu...@googlegroups.com.
To unsubscribe from this group, send email to connected-community-h...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msg/connected-community-hackerspace/-/kLGnuyAdUlEJ.

Zac Faragher

unread,
Sep 14, 2012, 9:59:52 AM9/14/12
to connected-commu...@googlegroups.com
If you only want to run 10/100, and I don't see why you would need anything higher, you could do a "homebrew" PoE a la http://tuxgraphics.org/electronics/200903/hobby-poe.shtml

Using this, you could also set the voltage required by the end components, rather than the 48V specified by 802.3af.

Zac

Luke Weston

unread,
Sep 14, 2012, 2:12:30 PM9/14/12
to connected-commu...@googlegroups.com
"Hacker-style" POE at 12 volts, with sufficient current to run the solenoid and other electronics, is not a bad idea...  if we're certain that the ethernet cable going to the door access control system won't be repurposed or reused for anything, and it is well-documented that that ethernet cable has the POE on it, and no other ethernet cables or ethernet ports on the space have non-standard hacker-style POE.

I'm usually not a huge fan of that sort of POE in an environment like the hackerspace... if you plug a device in to a powered ethernet port of that nature and you're not expecting it to be powered, because it's not labelled, documented etc., and it's not "proper" negotiated 802.3 POE, then you can blow up your computer hardware.

But just for the specific case of the cable going to the door access control system it's perhaps not a bad idea.

Cheers,
  Luke

On Monday, 6 August 2012 19:39:14 UTC+10, Mathew McBride wrote:

Hi Everyone,

Has anyone done research on the NFC/RFID access system? (It was on the
wish list board when I last visited).
I'm aware we have an Adafruit PN532 NFC breakout board, along with a box
of MiFare Keychain fobs, in the hackerspace, and having done previous
NFC work with libnfc, I'd love to take a look at the 'access control'
side - hopefully someone here knows more about controlling locks
electronically.

- Matt

tubular

unread,
Sep 14, 2012, 6:48:53 PM9/14/12
to connected-commu...@googlegroups.com
PoE would be a wonderful addition if we can make it work.   Any surplus power we have can be used for some external led lighting. 

The Ag5100 looks good so I've ordered one for Tuesday.  If it works I can keep my rack enclosure and PSU for something else, and the cabling is slightly simpler. 

How do we implement the centre tap of the pulse transformers shown in figure 8 of the datasheet?  Could we get that from the Pi, or scrounge some transformers off a separate NIC or something?

regards
Lachlan
It is loading more messages.
0 new messages