Tipping the scales

I am getting really good at upgrading the scales to do WiFi now, and read cards. The card of choice is a Monzo card which works perfectly well as an ID for weighing yourself. Notably Amex have an ID of 00000000 which is useless.

Really neat PCB, locking molex connectors, cables, the lot. It is working well. Marsden kindly sent the service manual so I can set to "kg" and "st/lb" modes for those that like old-school weights.

The system has a QR code on the scales, which allows you to register any card against your email address. You then weigh yourself and tap the card on the scales to record the weight.

When you tap the card it beeps to confirm it is working, and keep beeping until a stable weight is recorded over WiFi to the server. Simple UI if ever I made one!

Sadly, I have fried a couple of boards whilst doing these upgrades, but Marsden do spare parts (not cheap) and whilst I have a few clues what I may have done, I am not 100% sure of how I killed them. I think, with care, and anti-static, and being neat (avoiding any shorts, or diodes backwards) I can do this reliably now. Obviously very unofficial so I cannot expect any help from Marsden. They do make very nice scales though.

The next challenge is to make the web site that holds the data have graphs and sharing options and so on. At present it is just a list of weights. But even that is working for relatives using this solution.

This is turning in to the new fat-shamers club or something, not sure.

But what was the first thing on the web site? after registering the domain? well, it was getting an excellent lawyer to put together the privacy policy for us and ensuring we are GDPR compliant.

You have to love any lawyer that covers standing on scales with your pet cat as part of the privacy policy. Thank you Neil.

Door entry system

I have been playing with a door entry system, as you will have seen, and there are several steps like choosing processor, and voltage regulators, and relays, and so on. All good fun, but it gets a bit more interesting when you actually want to create some security.

But first, a couple of updates.

The Elechouse PN532 V4 cards really just work, they are excellent, talk to bank cards and MIFARE cards and fobs at a usable distance with no problem. Really impressed. I cannot stress this enough, buy these from Elechouse directly in China - they can ship in a few days - they work. But one extra bit, as I am using these on the "outside" part of the door system - I wanted an LED. It seems the PN532 has some GPIO pins, so a simple bi-colour LED and resistor directly on two of the pins (which the elechouse bring out to pad/holes) gives me a nice red/green LED (with various combinations of blinking as I like). On top of that the WiFi has been really reliable, but it seems that can improve when the next ESP8266 libraries are released soon. I have been using on one of my doors at home for a couple of weeks now, and it is working well.

On-line, and off-line operation

Even though the WiFi is working well, it remains an area of concern in terms of reliability and fallback for power failure, and vulnerability. The system is using TLS everywhere, so makes it pretty secure against infiltration, but not against disruptive attacks - a weakness of any RF based systems.

The simplest fallback is a system where one, or more, cards are configured in door(s) to be allowed to open the door off-line when no WiFi. Overall this is a good safety net, and the one or two cards with such an ID can be kept safe. As they would be my cards, and there is no door of which I should be locked out, this does not make this a work around of security. Even so, it is a bodge.

A better solution may be to allow off-line working of the doors. This is possible, of course. In fact, cards like the NXP MIFARE DESFire EV1 cards are ideal for this. Ideally you want a system that is at least mostly on-line allowing off-line but with logging, and controls - which suites WiFi well.

How would off-line work?

The trick with off-line is you need to somehow encode the rules for access in a way that does not need live access to a control system. This is complicated - it could be a large database, and what if you have a lot of people - do you literally have to sync a whole user access database in to every small door controller CPU/Flash? That would work, but is not that scaleable.

So code details in the card. Well, that is tricky if the card can be changed. Of course you want secure cards, and the DESFire cards allow this. They allow for a card you cannot copy or change, but allow lots of fields and "files" on the card which could encode details of times of day and day of week and expiry dates and which doors are allowed or barred.

Using details on a card, which can only be changed using a key, means that an off-line system can work with unlimited numbers of users - checking the credentials from the card for each door access, and ensuring very quick response and instant operation without waiting on an on-line system.

From a reliability point of view this is excellent. As long as the door has power (which is easy with 12V and battery boxes) it works! Of course you need a way to blacklist cards from a central control, but this is for exceptions only, and short expiry on cards can keep this to a minimum.

Partly on-line

Of course you can make things a tad more secure by having some things on-line. E.g. if a card has not been used for a few days - this allows for cards to need extra checking if someone has been on holiday, etc. You could also make some doors on-line for most users (except for me!) for added security. You could make doors on-line when "locked", i.e. alarm set, so first use of the day could have a lag if WiFi is iffy. All of these are good compromises for ensuring most, or all, doors are fast response and very reliable all day which few exceptions. Users get upset walking in to a door that did not open when expected - you really only have a few hundred ms to play with here :-)

Of course one trick is "normally on-line" only falling back to off-line working (where allowed) if response takes more than X milliseconds.


It is not as simple as one would like. Making all of this work at a technical level, making PCBs, making readers, and 3D printed cases, and firmware - all pretty straight forward. Even the low level comms to the DESFire cards is not that hard (with help from datasheets and some internet blogs).

However, the bigger issue is how you manage the cards.

The DESFire cards do not use public/private key logic, which is a shame. If they did, all readers could have public keys with no concern on these leaking, whilst the cards have embedded secret keys used to answer a challenge from the reader. Unfortunately the DESFire authentication is mutual / symmetric, so the same key is needed in the card and the reader.

  • Do you have a per card master key, or a common master key? (I'd say per card), but where do you store that?
  • Do you have per card keys per application for updating permissions?
  • What of a key that can write to a counter and a log?
  • What of the key just to validate the application/card.
  • How do you handle multiple applications on a card?

The validation is perhaps the most annoying - as you want to avoid a complete database of all cards in every lock with the key for that card. Indeed, that means more keys in more places that could be compromised (physically steal a door control board and re-flash to dump keys). It does not help over having a common key.

So in practice, for each application, you need an authentication key that is stored in the locks if they are to work off line at all. You could have different doors/locks on different applications where there are different levels of security or sensitivity in an organisation. That helps.

That also means communicating the key to the locks (let's use TLS shall we). Does it mean storing in the lock? We could put in flash, or maybe we deliberately store only in RAM and need to be on-line once after any reboot before we can work off line. Remember, if someone gets a key, they can make cards, so no level of fallback key is any good if it could be compromised.

And then the whole access control rights are more complex - not just which doors and what times, but also who has controls to change access on people's cards. The NP532 has a nice feature where you can talk to two cards in RF field at once, so you can make it that programming any card means applying that target card and the card of the HR person that has authority to make changes at the same time on a reader on a desk. Not sure if that is more than a gimmick though. Even so, you can use the cards as part of login processes for management of cards, and should do as at least two factor auth.

A lot of the work on this project will be the management system for cards, and logging, and security (and GDPR).

You also need to consider compromises - what if someone did steal a reader off a door - can you re-issue TLS/MQTT credentials to all readers? Can you update keys? How does that process work. The simple case of a lost card is easy by comparison (blacklist on all readers for X days). Do you roll over keys anyway and have a system to update on next use? All good fun.

Alternative on-line?

There is a way to be on-line and not WiFi - I could install an RS485 driver and have the reader look like a normal Max reader to a Galaxy alarm system - doing the off-line control (all set up over wifi) and reporting a simple "key fob" number to the alarm / door system if all OK. Viable and quick.

Is there a product in this?

It would be easy to make a product - an external reader based on PN532 with LEDs, perhaps a beeper, and an internal unit with contact inputs, solid state really output, RS485 for talking to Galaxy panel, WiFi, 12V power, and even a programming header for hobbyist market.

It would be massively more secure than Max readers, as using proper DESFire cards and keys, and the external unit not housing the relay even. Isolate its power and control lines and you cannot "break" the door control from outside. Nice.

It would cost (mainly in the CE marking, safety and EMC testing). It could be neat, and a drop in high security system for an existing RS485 based door/alarm system, or a WiFi based system. Whilst we spend a lot on R&D, this would be perhaps a tad too speculative for now. Of course if you are a large company with many offices and staff and interested in a serious bespoke entry control system - let me know - we have the technology now.

For now, I expect this is for my home, and maybe office later, not a product. But still, a big step forward in terms of security.

All of this, including manuals, PCB layouts, pictures, and code, are being kept up on GitHub... All part of A&A giving back to open source.



In doing a door entry / alarm system, one thing you need is outputs that control things, like a door lock. Whilst we have nice motorised locks for external doors, we also have mag locks for internal doors, but either way you need 12V and some reasonable current (around 0.5A). You cannot do that from a 3.3V output pin that can sink 20mA max.

So you use a relay, obviously.

Mk1: ILS relay board

First off, I found a nice, and reasonably small relay board. It works off 12V and designed to take an ESP-01. It even comes with one.

All I need to do is add my own firmware and I have a 12V powered relay on the WiFi. Simple.

There are a lot of advantages, obviously :-
  • Simple single complete module for relay control
  • Comes with ESP-01
  • Runs off the voltage we are using (be careful, there are 5V versions too)
  • No wiring, no PCBs, just load my own firmware
  • Also available in 2 and 4 relay modules

Mk2: More connectors

Unfortunately I don't just want a relay output, I want a door control. So I made a PCB that allowed an ESP-12F and hence more connectors. With some careful design I made it fit on top of the relay board!

This works. But is starting to get quite bulky. Bear in mind these usually have to fit in the back of a electrical outlet box, e.g. with an "Exit" button or similar. I was also not happy at how warm the main relay board got - it uses a simple linear regulator.

Mk3: Separate 3.3V relay

Time to try using the nice Pololu regulator boards. With a regulator I don't need to use the 12V relay board, I can have a stand alone board. But I still need a relay. So time to use an off the shelf 3.3V relay.

Mk4: Solid state relay

That worked, but really it is still rather chunky. After a bit of hunting around I found some nice solid state relays by Omron. I have always seen solid state relays as quite chunky, but it seems they can come in quite a small package, more than adequate for 12V at a few amps even...

The result, as you see, is a relatively small PCB, with regulator, and header to connect to the NFC reader (it does just fit passed the regulator, honest), and contacts for 12V in, exit button, door closed reed, and lock engaged contacts, as well as a relay output.

Now I just need the sort the right NFC reader and change over one of my doors :-)

Mk5: A remote I/O board (RIO)


PCB Milling bits

I have been playing with milling PCBs, and the issue is working out what bit to to use for milling PCBs.

The CNC 3018 I got comes with some fine tipped bits, they are cheap, and sharp..,

They are indeed pointy. If you try milling, they break, as they seem to in a slight breeze. They may have uses for wood or something, but for PCB they do not.

Broken bit

Even broken, they have some use, but the width depends on where they broke. And you have to start the cut again once it breaks. Bugger.

Flat end mill

You can get flat end mill bits...

These are not bad, but as you can see, the end is quite long. This is a 0.5mm diameter bit, which is still quite chunky, but it can cut the copper off a board.

The problem is they snap, and do so easily. It is a tad obvious from the design. So not so good.

What they do work really well for is drilling a hole and moving around to make a larger hole. All of the holes I make are done with this 0.5mm bit.

Bigger bit

I also have a 1mm version...

This is something I use for cutting the PCB outline. Works well.

Cutting the board.

What I found works well is a wider bit...

The issue here is depth control. At 45 degrees it means cutting down an extra 0.05mm means an extra 0.1mm width.

The trick is Z axis levelling, which bCNC can do. I added to my CNC 3018...

I initially tried to connect the wires to "Z" on the controller, but missed and was connected to next pins which are "A5", but it seems they worked and "Z" (I assumed Z end stop) did not work. The bCNC code just worked (with "A5"), and did auto levelling. Wow.

End result is I can cut tracks between 0.1" pitch pins!

I have been getting good at single sided designs with no links, but this makes it that bit easier.

P.S. Designs and code on GitHub... @aaisp giving back to open source.

It is funny how old-school lead(+silver) solder is easier to use...


I've got the power!

In messing with bits for a door entry / alarm system, everything is currently powered with 12V. However, these little ESP8266 processors are 3.3V.

Obviously I need a regulator, and as I am making these up using a milling machine, a small self contained module I can solder on to a PCB as a single component is the obvious choice. Back to Amazon, and I find something simple and cheap :-

It has three 0.1" pitch leads, and so easily mounts on the PCB. It has an offset with a header as it has components both sides. Works well though.

However, I noticed it gets a bit warm. Not really a huge surprise, but even when just powering from 5V in my Galaxy keypad design it still is a touch warm.

So I did a bit more research and found these tiny switch mode supplies, Pololu D24V5F3. A few pounds more expensive, also available from Amazon, but really really nice:-

  • Still a very small design 0.4" by 0.5" (yes, bloody inches!).
  • Components only one side, so can mount flush to my PCB making easy for something like an ESP-01 to fly over it and save more space.
  • Cool. I mean really cool. They say 2mA, and given that my ESP-12F plus RC522, running off 12V on one of these is 30mA total, I am impressed. I was seeing 140mA previously.
  • It also has a shutdown input - which I suspect I could use with a button on a battery powered device so you can power up and then have s/w power down. I wonder if I can even do something clever with sleep mode on an ESP8266 shutting down its own power while it sleeps - may need a capacitor somewhere in that :-)
  • Will accept from around 3.5V up to 36V as input!
  • They do other voltages, and current ratings as well, and step-up regulators.
Actually a D24V6F3, the D24V5F3 are on order
Basically, I am working through the total maze of too much information trying to weed out the good from the bad and work out what sort of components are good. I think this comes in to the "good" category for voltage regulator.


New life for old tech (Galaxy keypad)

I wanted to convert a Honeywell Galaxy alarm panel keypad to be on WiFi.

Simples :-)

Start with a keypad :-

Open it up...

There is not a lot of space...

(This had a proxy reader, which I removed)

We'll need a few parts, including a freshly milled PCB. All from GitHub.

No space for the spacer...

Fits nicely...

Not forgetting a wire link - sadly I could not manage a layout without this...

Add the RS485 convertor and power regulator and some wires, crop the leads nicely...

Looks tidy... (I then sprayed the bare copper with clear lacquer, by the way).

They keypad has handy 5V pads...

And the A/B wires...

And it fits in nicely...

Put back together...

And it works!

PN532 Disappointing electronics

Playing around with some electronics is fun, and usually things work well, but I have hit a slight snag.

I am trying to make a more secure door entry reader using NFC. The main idea is to work with Mifare DESFire EV1 cards using AES. This would be secure.

The first reader I tried was an MFR522. This works well on the Mifare Classic cards, and it is easy to make something that uses the card ID (4 bytes) as an access control. But they can be copied. Even using the encryption is pointless as Mifare Classic cards have been well cracked.

Apparently the RC522 cannot handle the better cards, so I got a PN532 based reader. One of these red ones...

They are readily available on Amazon (with a header, card, and fob).

I got one, tried it, it worked. It would read a card or a fob, and would read the 7 byte ID from the better Mifare DESFire EV1 tags. This is excellent. It even got an ID (randomised) from my passport!

I then 3D printed a nice case for it, and reconnected it, backwards! I have since changed to properly polarised connectors, but I was cursing. It stopped working, unsurprisingly.

So I got another one. It reads the Mifare classic cards, but has to be very close to the reader. It won't read the Mifare classic fob that came with it even. It won't read my passport not the Mifare DESFire EV1 card.

So I got another one, and the same. Arrrg!

So I got another make, a keyestudio one. It won't read the Mifare DESfire EV1.

This is really frustrating. Looking around the internet it seems some of the red boards work and some don't. There are reports of changing some components on them. There is talk of cheap Chinese clones which don't work well. The elechouse website even has details of the cheap copies being sold.

However, it seems I can buy genuine parts from elechouse, so I'll try that. Fingers crossed.


It is Holiday of Labor's Day here.
We will ship your order next week. The shipping would take 5~7 days.


WiFi for an alarm system?

I'll post more details later I am sure, but I have again been working on my "Solar System" door entry and alarm system.

The existing system works using Galaxy RS485 peripherals like a "Max Reader". This works, but is there a better way.

Well, WiFi, maybe...

This is a tricky matter to consider. We know WiFi is not as "contained" as wires, meaning more vulnerable to attack and disruption, to say the least.

So, let's consider some pros and cons.


  • Generally very reliable as wires usually are - that said, it has limitations - notably number of devices on the bus (both in terms of physical aspects of RS485, and polling time constraints).
  • Hard to access if in the walls, inside the building, but things like Max Readers expose the bus externally (albeit at cost of tripping tamper).
  • With any access (e.g. Max Reader) very easy to disrupt (albeit with tripping tamper).
  • Very insecure - I have done a proof of concept with access to the bus that can inject messages to open doors, etc, without the slightest hint of a tamper alert from the Galaxy panel.
  • Slow
  • Needs wiring back to the panel.
  • Vulnerable to snooping if you get physical access to bus
  • Hard to do redundancy


  • Vulnerable to RF level attacks (albeit tripping tamper)
  • Vulnerable to protocol level disruption (if you get in to WiFi) such as WiFi disconnects or IP flooding or TSP RST flooding.
  • Secure if using TLS. Cannot be snooped or faked.
  • Fast
  • No need to wire back to the panel
  • Easy to add a lot of devices (subject to access points that allow lots of associations)
  • Harder to do battery backup, but possible - need 12V access points - can be done.
  • Possible to do multiple AP fallback and redundancy
So I am making my SolarSystem GitHub project handle WiFi connected devices as an option.
  • ESP8266 code for modules
  • PCB layouts for modules
  • 3D printed cases for modules
  • TLS MQTT over WiFi with certificate pinning and checking
  • SolarSystem code allows mix and match of RS485 and WiFi connected modules
Not finished yet, but most of the device code in place. I even have a way to use a Galaxy keypad on WiFi!

The door control logic is a relay board with NFC reader, and I am working on proper AES secured cards. The 125kHz proxy cards are stupidly easy to copy!

TOTSCO moving goal posts, again!

One of the big issues I had in initial coding was the use of correlationID on messages. The test cases showed it being used the same on a se...