Hackspace access control

I'm a trustee at East Essex Hackspace which is currently discussing buying a fibre laser and it's rekindled the desire for 'toolbots' to control access to things. Originally I was looking at this over a year ago but got busy with other things so shelved it and then the need suddenly seemed less urgent.

One of our challenges is that when we opened we used some Wiegand RFID readers for our door entry system and fed the UIDs they gave into our membership database. Later on we found out that these UIDs weren't the same as the UIDs other things reported. I did some fiddling around and realised a simple XOR and byte reshuffle that fixed this so we were back in business until I built something using this and found it wasn't right for some issued cards. 

Then the access control project got shelved.

Having dug out my access control mockup again I armed myself with a pile of cards that I know don't map IDs how I thought and quickly realised if they have a 7-byte UID then the byte order reshuffle is different than for a 4-byte UID. So we're potentially back in business.

For the hardware I've taken a bit of an executive decision on the basis that whoever does the work gets to say how it's done, otherwise endless bikeshedding occurs. The hardware will be based on an Olimex ESP32-EVB which is an ESP32 dev board with Ethernet, onboard relays and a bunch of hardware we probably don't need. They're reliably available and properly certified.

To add the RFID reader I've designed a little 'shield' that plugs into the UEXT connector on the EVB which I'll solder some cheap MRC522 boards to.

It also breaks out some GPIO and has LEDs and somewhere to connect a sounder. I'm not even sure if we'll use a sounder, but I just wanted to get the board ordered.

Work on the software has been ongoing for ages but I've started poking at it again and one of the other Trustees already did a bunch of stuff in our membership database so I'm hoping this project can get done without too much pain.

Each tool will have different ways of limiting its use but my expectation most will already have an interlock or emergency stop that can be connected to one of the onboard relays of the EVB. I'd not expect these devices to control the main power feed to the tool unless it's a very small one.

An open source prop: Part 1

After going to Alone: Discord LARP I ended up chatting with the organisers on social media. They had some 'hackable locks' in the game that worked OK but were really just touching a couple of pads with a wire to make a beep and change an LED.

There were several game organisers playing and chat turned to making a generic 'hackable lock' for modern/sci-fi LARPs. It's something lots of LARPs will have needed or reinvented over the years. We might use them ourselves in March.

So I'm now smashing away at code for a generic lock prop based around the old favourite of an RC522 RFID reader, WeMOS D1 mini, LEDs and a piezo sounder.

The plan is to totally open source everything, with a build guide, 3D printed case, software that is pretty flexible and can be tweaked to behave in different ways.

This has already spawned two Arduino libraries. A tap code library for taking input codes on a single button (for hacking/admin) and an RFID authorisation library. The big plan is for a Web Portal interface, probably using ESPUI again.

Churning out some libraries means the main chunk of code for the prop is much less spaghetti-like and the libraries should be eminently re-usable. I really need to do this with lots of other things I've made or started to make.

Oh and obviously the Cyberdeck prop is on hold again, with no game to use it at for a while.

Mesh networked computer terminals with RFID logon - part 6

Going back a few weeks I was having trouble with stability of the RFID readers. Which I've now fixed with a far less complicated solution.

The library has an option to turn the RFID antenna on and off. Simply shutting it off and turning back on to check the card periodically seems a 100% stable solution.

Obviously you should also check the card hasn't been swapped by checking the ID hasn't changed but here is a a minimal sketch to do this. As checking for a card stops it appearing as new it's easy to get the logic messed up but this is a tested and working example.

Note to self: start putting stuff on GutHub.

#include <SPI.h>

#include <MFRC522.h>

const uint8_t SS_PIN = D8;    //My example code is for a WeMos D1 mini, change these to match your setup

const uint8_t RST_PIN = D0;   //My example code is for a WeMos D1 mini, change these to match your setup

 

MFRC522 rfid(SS_PIN, RST_PIN);

bool cardPresentWhenLastChecked = false;

bool antennaEnabled = true;

uint32_t cardCheckTimer = 0;

void setup()

{ 

  Serial.begin(115200);

  SPI.begin();

  rfid.PCD_Init();

  Serial.println(F("Checking for RFID card removal"));

}

 

void loop()

{

  if(millis() > cardCheckTimer)

  {

    //Start a check of the card

    if(antennaEnabled == false)

    {

        //Turn the antenna back on

        rfid.PCD_AntennaOn();

        antennaEnabled = true;

        //It takes time to wake up the RFID card so the sketch needs to wait before checking for it

        cardCheckTimer = millis() + 20ul;

    }

    else if(antennaEnabled == true)

    {

      if(millis() > cardCheckTimer)

      {

        //Check for a card after a delay for it to power up

        if(rfid.PICC_IsNewCardPresent() == true)

        {

          if(cardPresentWhenLastChecked == false)

          {

            //Card was absent but has been presented

            Serial.println(F("Card presented"));

            cardPresentWhenLastChecked = true;

          }

        }

        else if(rfid.PICC_IsNewCardPresent() == false && cardPresentWhenLastChecked == true)

        {

          //The card was present but has been removed

          Serial.println("Card removed");

          cardPresentWhenLastChecked = false;

        }

        //Switch off the antenna, otherwise the card will not show as 'new' when checked again

        rfid.PCD_AntennaOff();

        antennaEnabled = false;

        //Wait before checking the card again

        cardCheckTimer = millis() + 100ul;

      }

    }

  }

}

Mesh networked computer terminals with RFID logon - part 5

After a chunk of work I've got file syncing working fully. The code does a simple manifest of everything on the SD card except for the irritating "System Volume Information" directory Windows puts on there if you view the card on a Windows system.

As my mesh network isn't designed to be high bandwidth and I'm not expecting the files on there to change often, this is a slow, lightweight process. After all it's only running on an ESP8266, don't expect BitTorrent.

The steps the mesh takes to sync are broadly...

• Recursively iterate the whole file system on the SD card
• Open each file and do a CRC16 of it
• Store the full path and filename, size and CRC16 in a data structure
• Write this to a simple flat file to save this across restarts. Each file is given a sequence number starting at one that increments with each change
• Once all the files have been read, XOR all their CRC16s together and store it
• The total number of files and this XOR of the CRC16s are advertised periodically by each node flooding the whole mesh
• If a node receives a XOR that doesn't match its own it asks for the CRC16, size and sequence number of each file on the other node, one at a time
• Some simple if/then/else logic decides if it needs the other node's version of the file
• Files are transferred 64 bytes at a time in a TFTP-esque manner
• Once the XOR and number of files match the two nodes are considered synced and stop
• To detect change from an initially synced state, if a file is changed the new CRC16, size and sequence number are flooded to the whole mesh immediately
• Notification of deleted files use a similar mechanism and stay in the data structure
• There are timeouts and retries on the various steps in the process so it will fail fairly gracefully and restart

This is probably full of edge case horrors and has no way to handle file conflict resolution. I don't care, this is not an enterprise class distributed file system, it's a bunch of microcontrollers in a field that I need to have the same files on, mostly, and stay in sync, mostly.

Watch the awesome log output!

Mesh networked computer terminals with RFID logon - part 4

This is another little update, I have basic file transfers working, woohoo!

There is no authentication but some basic sanity checking of the data, ie. is the packet from the station it expects, for a file it expects and the chunk it expects next. It's pretty much like TFTP but done over my proprietary mesh network stuff.

I'm currently only shipping 64 bytes at a time, inefficiently packed too, so it's going to suck for large files but the process works and will chunk through a queue of files happily grabbing them.

Now the code needs cleaning up and to allow for things like failed transfers.

I also need to go back to the file manifest handling as it handles change, but not initial seeding. However this is a really positive step forwards.

Mesh networked computer terminals with RFID logon - part 3

The last couple of days I've been messing around with code for building a 'manifest' of the file system on the SD card then notifying changes to other stations.

This has taken a lot of time as I had a few false starts in my reinvention of this particular wheel. I think I trashed my plan and started again at least three times and it's probably still a quite naive scheme. As things stand it's just notification of change, the other station knows if there's an updated file but there's no method to transfer the file as yet.

Oddly I don't think file transfer will be hard. The way I've put my mesh library together makes it quite easy to push arbitrary data around. It will just need to be chopped up into chunks and sent. Maybe also 'lock' the file to prevent local changes while any transfer occurs, just in case.

Mesh networked computer terminals with RFID logon - part 2

Progress on the messaging application is going OK.

I'm having a little aggro with RFID. It works, but not reliably so after 3-4 uses of the card it becomes unresponsive. This may be related to the code I've cribbed from an example to continuously poll the card and check if it's been removed. This might crash the reader but I'm not 100% sure. It's also quite possible I've messed up the state machine that handles the logon process in some way related to idle logoffs.

What is going quite nicely is building a file structure on the SD card with global, per-station and per-user configuration files. This is massively old-school way of doing things but is easily human-readable without writing an admin interface.

An easy example, above, is the 'message of the day' above where the cyan text is 'global' and the 'green' per-station.

I'm now working on an interface for users to display their stored files. Once this is done I would like to make it sync across the workstations with a TFTP-esque setup where the station with the highest sequence numbered file distributes it to the others. This needs to be in place for persistent messaging across different workstations, but will make the configuration more easily maintainable. It's probably going to need metadata stored in each directory, hidden from the user and I can see myself using JSON for that.

Mesh networked computer terminals with RFID logon - part 1

I may have bitten off more than I can chew, but let's see if this works out.

While I've been developing my ESP8266 mesh network library one of the demo applications I've written for it is an IRC-esque chat client with an ncurses terminal interface. It mostly works, but needs some polishing.

This application means you can connect an ESP8266 board into any computer that will run a terminal emulator and chat with other nodes with no infrastructure at all, not even local Wi-Fi. It's completely self-contained, an actual VT100 dumb terminal would work, for that matter, with a little level-shifting of the serial port.

When I went away to Odysseus LARP, they had a forum-esque system that had in-game use, for communication between players, with the GMs and as a source of information. This was an unexpectedly good experience adding to gameplay and was the basis of the in-game hacking mechanic.

For the sci-fi LARP I'm helping run in March while chatting during a writing session we decided to see if we could offer something similar. Odysseus was indoors with a big IT back-end, large player base and huge development team. Our event is mostly outdoors, about 20 players and three GMs plus a few more people helping with props, so tiny by comparison.

Nonetheless I've got a working chat application and want to use the mesh network for other stuff in the game already. Stick some chat nodes connected to laptops in the covered areas where there's power and you're getting there.

Key things I need to add are...

• Logon credentials/tokens
• Persistence of messages across logons at different terminals
• A way to store and show files
• A 'hacking' mechanic for this that is in keeping with the game

So I've spent a bunch of time this weekend messing around with using RFID cards as logon tokens, storing structured info in JSON files on SD cards, planning and thinking things through a lot.

I think it will work, let's see.

Using ESP8266, NodeMCU and MQTT to create a wirelessly connected 'installation' - paused

It's been a while since an update. We had been due to play the game I was building for at the end of June but we've had to postpone.

My friend Mik, who is the driving force behind the game, became very ill and while we could have finished off the work and played it didn't seem right.

Nonetheless I've now got ten Wifi connected RFID readers that talk MQTT and emulate the sort of thing you see on security doors. Blinkenlight, buzzers etc.

They're a bit chunky but then they're hand built from hobbyist modules and have a 3xAA batteries in to drive them. So chunk was kind of unavoidable.

Also I've built a faux CCTV system with some Wifi IP cameras and a 'portal' that uses the same RFID cards to log you in. The portal is a single page full of JavaScript which links to the various cameras and either shows or hides them based on which card you present. So it's not really secure but it's for a game after all.

The setup uses a cheap eBay USB card reader and these just emulate a keyboard. When you present a card it sends the card ID and presses enter. A little bit of JavaScript to capture this and it looks like magic.

Implementing this all in JavaScript worked way more easily than I expected and I'm really looking forward to using this in a game.

We were throwing away two prehistoric Compaq TC1100 Wintel slate PCs from work and I managed to grab them. With Ubuntu Mate installed they work just great, even the horrible stylus is functional. What's great about them is it stops me building a 'high tech terminal' prop as they look like one without really looking exactly like a conventional laptop.

The whole thing isn't 100% finished, I'd been burning the midnight oil a bit and when it got postponed I stopped. Once we've got a new date for the game I'll get back on the horse.

In the meantime though I presented at the London Arduino Meetup about some of my previous work.

There's a video of my full presentation here, but DON'T WATCH THIS IF YOU PLAN TO PLAY THE NEXT WAYWARD SONS GAME AS THERE ARE MASSIVE SPOILERS IN THE Q&A.

Presentation Spoiler: I say 'um' too much.

There are also some nice photos on the organiser's flickr feed.

Now I'm freed up to work on other things, we've got the season of Lasertag LARP ahead and I seem to have managed to break/kill several of my 'tag weapons. I think I'll be fixing these this weekend.