Door signing in/out rfid type system
Matthew Daubney
following proposal.
We'll need 1xlaptop or something to act as a server and to give a nice
big screen to display info on -> Think I have one I can donate to the
cause
1xArduino ethernet with rfid shield (these are normally mifare type
rfid cards) and some kind of door open sensor (reed switch and a
magnet?) -> £50 odd
Lots of rfid cards with stuff printed on them (hackspace logo, if
lost, blah blah) -> Get about 100 for £200 with 4 colour printing on
both sides. That was just looking at one place, so might be cheaper
The laptop contains the database of members and the unique serials on
the card (we need to put two numbers on the cards, more on that in a
minute). So when a member walks in the door the screen turns orange
and flashes a "Please scan card" message. If no response in 60
seconds, screen turns red with an angry smiley and pings relevant
people an email/sms/whatever. Otherwise, member scans card on arduino
scanner, light on scanner turns red to show busy. Scanner sends serial
1 to the server -> server responds with serial 2 or a string of 0's to
indicate an auth failure. If failure go to angry
face/email/sms/whatever. Otherwise server sends mqtt message stating
auth success and light on scanner goes green to auth next person. If
auth success, if person not already signed into room, signs them in,
otherwise signs them out.
With the MQTT bit on, we can set things like IRC bots to pick up when
people walk in/out of the space. We could get the arduino to do the
mqtt and do the whole process over that, as we could stick the relay
on an mqtt topic too for that bit of information.
Suggestions for improvements? Other ideas?
-Matt Daubney
Tom Allen
Sounds like your doing good research here!
The London backspace use a USB reader I think. There whole door bot project code is on there git hub account if you have time to look over there findings.
As for hardware i can donate the computer and lcd screen. Or maybe we can do my favourite laptop hack and remove the screen hindges and flip the screen and wall mount it. I have a box of no less than 14 laptops of different (old) ages begging for a use, the laptop option gives us built in ups too.
Oh and for the cards. Can we not laser engrave them? Or i have a bulk full colour sticker printing system here too that costs me less the a penny each.
Lets make this happen!
Matthew Daubney
> Sounds like your doing good research here!
> The London backspace use a USB reader I think. There whole door bot project
> code is on there git hub account if you have time to look over there
> findings.
I've also got the code from the one they had at Swansea Uni computing
society, who also use a USB rfid reader. The idea behind putting it on
an arduino ethernet was that we're not bound by the length of a USB
cable. We could run it over cat5, so the laptop/servery portion could
be anywhere. It would also make it easy to hack the output from it
into other things.
> As for hardware i can donate the computer and lcd screen. Or maybe we can do
> my favourite laptop hack and remove the screen hindges and flip the screen
> and wall mount it. I have a box of no less than 14 laptops of different
> (old) ages begging for a use, the laptop option gives us built in ups too.
Yes, an old laptop would be ace
> Oh and for the cards. Can we not laser engrave them? Or i have a bulk full
> colour sticker printing system here too that costs me less the a penny each.
I had a think about this in the car this morning, the other option is
to laser cut a stencil and then just spray them. Nothing stopping us
having 2 or 3 stencils, one for each colour.
-Matt Daubney
Matthew Daubney
After looking over the London Hackspace page, do we want to decide on
some sort of naming convention for machines/doowhatsits we put on the
network in the space? They use "people involved in computing", so I
think we could do with something better. Maybe more Reading related
(list of famous-ish people from Reading
http://en.wikipedia.org/wiki/List_of_people_from_Reading,_Berkshire or
we could do villages in West Berkshire, or rivers, or ship names from
the amazing Culture books, or celestial objects........)
-Matt Daubney
Tom Allen
Laser cut stencils? Awesome idea!
Ryan .
goes the problem isn't the software or the token we use for access,
it's the physical implementation of a secure locking system.
The only solution I can think of that fits is an electronic key safe
that sounds alarm bells if the keys aren't replaced in a timely
fashion. That, combined with a tracking system that requires
individual users to swipe-in when they enter or exit will provide all
the security we need, as well as the ability to track usage and keep
an eye on safety.
The doors in that space likely won't support mag-locks, solenoid bolts
or a solenoid striker plate. The main concerns are that we don't
really want to make too huge a capital investment in the place, and
that door is our only fire exit.
I'll say that one again, nice and slow, THAT DOOR IS OUR ONLY FIRE
EXIT. Anything we do to that door needs to be top-notch and safe, yet
secure when noone's in the place. That's the main reason I think an
electronic key-safe is the best way to do this.
I haven't seen an electronic key-safe that can be opened by a remote
trigger yet. Project??
Requirements:
Secure to some standard
Opens by RFID
Closes when it's supposed to
Bitches if it's left without the key in it for too long.
anything else?
Matthew Daubney
with the key safe idea then just use an rfid thing to log people
in/out of the space? So the key/keysafe would be seperate to the
signing in/out? Or did I misunderstand?
Tom Allen
I was also thinking we should take a headshot of every member which i can print on a sticker for the card and would show up on the check in screen and the web interface to see who is in the space. The web interface being for members only of course. Main reason is that london recently decided they regretted not doing this earlier and now they have 300+members the sign in list is pretty meaningless and verifying its accurate involves the awkward task of asking people at the table next to you to remind you of there name...
Matthew Daubney
normal pin based key safe and then extend the system at a later date
when someone figures out how to make an RFID based key safe that's
secure :)
Matthew Daubney
with a key that's stored in a normal key safe.
Ryan .
Matthew Daubney
Some of it's been back ordered, but will hopefully arrive next week
\o/
Tom Allen
Nice one. The cost of the parts will be covered by peoples joining fee once we combine it with the cost of this key box thingy.
Thanks for taking in initiative on this!
Alan Wood
Matthew Daubney
moment it doesn't support MQTT (though someones working on it) and
getting that to work is a bit beyond my competence level :) If anyone
wants a go, I can bring it to the space for someone to have a play
with.
Alan Wood
Yeah, I've got one of those sat at home. The problem is that at the
moment it doesn't support MQTT (though someones working on it) and
getting that to work is a bit beyond my competence level :) If anyone
wants a go, I can bring it to the space for someone to have a play
with.
Matthew Daubney
the system. MQTT being such a lovely publish/subscribe protocol lets
more or less anything bolt onto the system with no change required on
the server. If you did a GET or POST other items wouldn't be able to
subscribe as easily, they'd all have to poll. It's a small thing, but
makes a big difference. If I had a spare weekend I'd look at porting
MQTT to the nanode, but based on the fact 2 or 3 others have tried and
not got anywhere... I'm thinking it may be beyond me.
-Matt Daubney
Norro
Matthew Daubney
subscribed to the server and had stuff pushed to them.
Tom Allen
Streaming,Pub/Sub,Push = Good :)
This is what I spend half my week telling the developers here....
(zeebox.com) (ten points to anyone who can spot the hideous 5 second
poll in the web app)
Tom
Alan Wood
It would do initially, but the problems come when you want to extend
the system. MQTT being such a lovely publish/subscribe protocol lets
more or less anything bolt onto the system with no change required on
the server. If you did a GET or POST other items wouldn't be able to
subscribe as easily, they'd all have to poll. It's a small thing, but
makes a big difference. If I had a spare weekend I'd look at porting
MQTT to the nanode, but based on the fact 2 or 3 others have tried and
not got anywhere... I'm thinking it may be beyond me.
-Matt Daubney
mikethebee
be incorporated into the 'full system' later.
Matthew Daubney
>
>
> On Fri, Nov 11, 2011 at 12:38 PM, Matthew Daubney <ma...@daubers.co.uk>
> wrote:
>>
>> It would do initially, but the problems come when you want to extend
>> the system. MQTT being such a lovely publish/subscribe protocol lets
>> more or less anything bolt onto the system with no change required on
>> the server. If you did a GET or POST other items wouldn't be able to
>> subscribe as easily, they'd all have to poll. It's a small thing, but
>> makes a big difference. If I had a spare weekend I'd look at porting
>> MQTT to the nanode, but based on the fact 2 or 3 others have tried and
>> not got anywhere... I'm thinking it may be beyond me.
>>
>> -Matt Daubney
>
> Well you could use a HTTP GET for now from the Nanode RF to the linux system
> which in turn could generate the MQTT packets very simply (at least on
> linux). Then when the MQTT nut is cracked do the MQTT packets directly and
> loose the psuedo http:get proxy.
>
> regards
> Al
You can only really have a one way conversation in that case. In some
situations I'd quite like to be able to ask the system if the door is
closed or some such, unless we also implement an HTTP system in the
nanode this would be difficult. It also means that the client software
asking the question would need to know 2 pieces of information (the
MQTT server to subscribe to and the IP address of the Nanode to send
it direct requests) rather than one.
In a way this conversation is taking the system design backwards. What
should be done is the system designed with protocols and stuff set,
and then the hardware worked to the system design. Not the system
being designed to fit given hardware. The other point is that we don't
really need the RF stuff on that board.
I know the Nanode is a London Hackspace project, but damaging the
ability of a system just for (what essentially is) political reasons
doesn't really seem like a good idea.
-Matt Daubney
Norro
Stuart Ward
And we can just open the door remotely if someone turns up at the space? ;-)
Stuart
Alan Wood
Matthew Daubney
<snip>
> Oh I didn't realise you were implementing an MQTT server on the Arduino, I
> was assuming client only, my bad.
It would be useful to use MQTT over an HTTP based protocol as MQTT
also allows you "will" messages. I.e. if the device hasn't sent a keep
alive signal in so many seconds, a message is sent to a given topic.
This would allow us to know if the scanner has failed without having
to do continuous polling of the device to check it's alive. We can
also get the device to subscribe to topics so we can command it to do
stuff (i.e. write these numbers to the next available card) without
needing a second access channel. All of these things are done by a
client (as you can both publish and subscribe to topics). So it's a
lot more versatile then having a "dumb" device that just pushes to a
web service.
I'm happy to prototype the system then spend a couple of hours one
evening at the space going through how it all works and why MQTT is a
better choice than HTTP based stuff if that would help?
-Matt Daubney
Tom Allen
computers, but have no experience with them on embedded systems, this is
seriously cool and will do wonders for the project I am planning so am
very keen to learn from you on this project.
Tom
Alan Wood
The issue is that Nick O'Leary's MQTT library for Arduino uses the
Ethernet client library which uses the Wiznet TCP/IP socket API - more
Layer 3 based.
The Nanode uses the ENC28J60 Ethernet shield library - which is more Layer
2 based.
Tom Allen
Matthew Daubney
> seems nottinghack are using mqtt and nanode maybe (they just told me on IRC)
>
>
> http://wiki.nottinghack.org.uk/wiki/Gatekeeper
>
Their git logs suggest they're not using the library associated with
the wireless chip on the Nanode.... are we sure that's a safe idea?
The testing images in their image gallery also have arduinos in, not
nanodes (you can tell by the lack of ethernet port and the blue
colour). The git commits also end just before they started porting
MQTT, and a twitter exchange I had earlier suggests that didn't get
far because of problems with the Ethernet library itself (memory
footprint to do with multiple TCP streams).
-Matt Daubney
Matthew Daubney
> I'm not doubting That MQTT is the best thing for the Job, Clearly it is. But
> you asked for 'suggestions for improvements' hence my response about Nanode
> as it has ethernet built in meaning one less shield.
Sorry, I did take the suggestion onboard, but without MQTT
compatibility, it's a bit of a non starter. There is an arduino with
ethernet built in, so the one less shield thing isn't really an issue.
Just a bit of a misunderstanding there I think :)
> The problem with nanode
> and MQTT appears to be related to below:
>>
>> The issue is that Nick O'Leary's MQTT library for Arduino uses the
>> Ethernet client library which uses the Wiznet TCP/IP socket API - more
>> Layer 3 based.
>> The Nanode uses the ENC28J60 Ethernet shield library - which is more Layer
>> 2 based.
>
> Having studied Nicks MQTT client it's simple enough, but the differences
> between Arduino Wiznet client library and the ENC28J60 shield library are
> more of a mystery to me, anyone else know the finer details about the
> history/differences between these 2?
As I've stated further down, I think it comes down to the number of
TCP sessions you can have open. The Wiznet chip seems to be able to
deal with more streams with less mucking around than the ENC28J60.
-Matt Daubney
Matthew Daubney
Sorry, meant ethernet chip, not wireless. My bad.
-Matt Daubney
Alan Wood
The Nanode only has 2k RAM. By default uIP is configured to support three TCP connections; each connection requires 30 bytes plus the application state size. If you just increase TCP_APP_STATE_SIZE to 500, you'd need 1590 bytes of RAM just for TCP connections. There's also a packet buffer of around 420 bytes (shared between all applications), plus the resolver cache, misc other state, and necessary things like the stack.
If you really need 500 bytes of connection state, you'll have to reduce the maximum number of TCP connections to 1. This is the UIP_CONF_MAX_CONNECTIONS parameter in uip-conf.h
They are obvious using UIP and having issues squeezing it all into the ATmega328 memory, which chimes with a conversation I have with a colleague recently who was having similar issues with his network project on Nanode. That doesn't mean its impossible for MQTT as it needs very little memory for its packets. It does however suggest a very different implementation of the library from the Arduino ethernet 'Client' to 'UIP' sockets like approach perhaps. Frankly I am staggered that they are getting even UIP to work in such a minute footprint!
Tom Allen
Personally i have never used any duino which wasnt a mega. They are so cheap i didnt see the point for single boards projects.
Ryan
Can we have a meeting at the space sometime to nail down a design for
this system and start getting bits together? I know the lack of
internet is the key sticking point in all of it, but ...
a) it should be able to work without it
b) it will take a while to get right, and we need it working so we can
just plug it in and go when the internet arrives.
I'm sure we've either got everything we need or we have the tools to
make whatever we need, so lets get building and make it happen!
(w00t group project!)
On Nov 11, 2:48 pm, Stuart Ward <stuart.ward...@gmail.com> wrote:
> http://arstechnica.com/business/news/2011/11/vulnerabilities-give-hac...
Matthew Daubney
> Hey all!
>
> Can we have a meeting at the space sometime to nail down a design for
> this system and start getting bits together? I know the lack of
> internet is the key sticking point in all of it, but ...
>
> a) it should be able to work without it
> b) it will take a while to get right, and we need it working so we can
> just plug it in and go when the internet arrives.
>
> I'm sure we've either got everything we need or we have the tools to
> make whatever we need, so lets get building and make it happen!
>
> (w00t group project!)
Hey Ryan,
I've got the RFID stuff on it's way to me (apparently it's left Hong
Kong, but thats as far as I can track it) The remaining stuff we'll
need is an arduino ethernet and one of the old laptops we have setup
as an intelligent screen. We might want to cut some perspex or
something to make a nice frame/case for the stuff :) I'm intending to
head to the space this evening to do a few bits so can get a pile of
bits together and some sketches too.
-Matt Daubney
Matthew Daubney
https://code.launchpad.net/~daubers/+junk/rdghackauthbot
-Matt Daubney
Matthew Daubney
the rfid reader/writer, the arduino is on it's way and some other
sensors I might attach to the board (temp/light/etc)) what I really
need is someone who can make it look awesome to make it look awesome
:)
The list of things that need to be done to get this complete is as follows:
1. We need to butcher a laptop to make it into an "intelligent sign".
There's at least one in the space we could use for this, if anyones
done this before or is a bit handy at this kind of specialised
butchery, please go ahead :) Some kind of awesome frame to hide it's
crappy laptop origins would also be ace. We also need to code the
clever sign bit up.
2. We need some kind of platform for the rfid aerial to be placed
under. Ideally I'd like this to be some form of clear _something_ to
show the circuitry through and to make it look awesome. I'll measure
the aerial and pop up some pictures tomorrow, and when the arduino
bits arrive I'll put them together and pop them up too as we'll need a
box or something for those.
3. The arduino needs to be programmed (I'll write a bit on that tomorrow)
4. We need to get some cat5 run to the place where the sign will live
and the reader will live.
5. We need a HUGE stack of mifare type rfid cards for the hundreds of
members we'll be welcoming through the door.
6. We need a design to go on the cards :)
I'm hoping to be down the space on Wednesday evening about 7pm, and
I'll bring as much of this as I have together with me, with the aim
of having the Arduino programmed by then so I can leave that part down
there for people to hack the rest up with :)
Let's really make this amazing!
-Matt Daubney
Alan Wood
As an update to this, I now have all the electronic components (i.e.
the rfid reader/writer, the arduino is on it's way and some other
sensors I might attach to the board (temp/light/etc)) what I really
need is someone who can make it look awesome to make it look awesome
:)
The list of things that need to be done to get this complete is as follows:
1. We need to butcher a laptop to make it into an "intelligent sign".
There's at least one in the space we could use for this, if anyones
done this before or is a bit handy at this kind of specialised
butchery, please go ahead :) Some kind of awesome frame to hide it's
crappy laptop origins would also be ace. We also need to code the
clever sign bit up.
2. We need some kind of platform for the rfid aerial to be placed
under. Ideally I'd like this to be some form of clear _something_ to
show the circuitry through and to make it look awesome. I'll measure
the aerial and pop up some pictures tomorrow, and when the arduino
bits arrive I'll put them together and pop them up too as we'll need a
box or something for those.
3. The arduino needs to be programmed (I'll write a bit on that tomorrow)
4. We need to get some cat5 run to the place where the sign will live
and the reader will live.
Norro
Matthew Daubney
> So we'll have a picture frame with it all built in that you tap your card
> against?
More or less, I thought it would be a good idea to have the card
reader sit out flat, so you could place the card on it if you wanted.
Ryan .
some sketches and things so we can get a design going for the
mechanical bits?
Matthew Daubney
the laptop I was thinking of using :) Hopefully the arduino bits will
arrive this evening so I can get that lot measured up for an enclosure
too.
Tom Allen
Unfortunatley i have to stay late at work(again) tonight so wont be able to join you. I do have a crate of 14 laptops which i want to see hacked tho. They are begging for it! I have a spare duino too. Although this is all useless until i can actually drop them off... Damn stupid forced unpaid overtime! If only i was unionised...
Ryan .
can catch up with us re. laptop+'duino tings yeah?
We should also do some sketches and design and make them available online yeah?
Matthew Daubney
getting IPv6 net, we should try and make sure this is all IPv6
compatible.
Ryan .
project ever, proper photographs from start to finish, all this
preliminary design discussion is already online obvs. so we can just
carry on as we are with it)
Also, Mr. Jones, do you have those RFID cards? We should start
figuring out how to print on them/laser engrave them/whatever them if
you do, and if you don't we need to find another source!
:)
Matthew Daubney
acquired http://www.seeedstudio.com/wiki/index.php?title=13.56Mhz_RFID_module_-_IOS/IEC_14443_type_a
and I've also got a single mifare ONE type rfid card.
I think I've already posted the code here before, but the code I've
been working on can be found at
https://code.launchpad.net/~daubers/+junk/rdghackauthbot this acts as
a bridge between the MQTT system and a SQL database, so the
reader/write can check a serial number against the database. I've just
started on the database model (which is in that bzr repo. it's a
MySQL Workbench file type) with the eventual idea that that database
should be stored centrally (on whatever ends up being the hackspace
internal server) and store all the members credentials.
I've not started on the arduino code, but
http://knolleary.net/arduino-client-for-mqtt/ is the mqtt library and
the wiki above contains information on the RFID module protocol. I'd
also like to stick a temperature sensor on the board (I've got a few
TMP36 sensors lying around http://oomlout.com/TMP36/TMP36-Guide.pdf
for a nice guide on using them) just because more than anything else!
As for the sensor for opening/closing the door, CPC have got this
http://cpc.farnell.com/elmdene/4s/4-wire-switch-plastic-contact/dp/SR02967
which would be ideal (I think) but I've not yet ordered any. Or maplin
has http://www.maplin.co.uk/miniature-contact-switch-12565 or
http://www.maplin.co.uk/heavy-duty-reed-switch-22576 and both of those
are anti-tamper. Reading don't have either of these in stock, so we'd
have to order them
I was also going to put 5 leds on the rfid/door sensor control panel,
a "door open" LED, a "card detected" LED, a "Waiting for card to
write" LED, a "system on" LED and an "error" LED, hopefully these can
be mounted into card swiping area frame thing :)
Matthew Daubney
tomorrow now. I'll put an order in for the door switch(s) this
morning.