Shelly1 on 12V

I have used Shelly1 for a while, and have loads of them in use.

One of the nice features is they can run from 12V. Well, actually, they can run from mains, 24V-60V DC, 12V DC, or (via connector pins) 3.3V DC. You move a link for 12V working. Pretty versatile.

I have used them in the house here on my door bell circuit which runs from a standard alarm system 12V battery box. All fine.

I planned to use with an alarm system as well, running from the 12V battery box. First two were fine, but then the next did not work. I tried another and it also did not work.

I did some googling and people report that the 12V is meant to be exactly 12V. I must ask Shelly to confirm really, but the comments were 12V and not a battery (which is 13.8V). My example use was actually 14V. It would be a pain if it could not run from a standard 12V battery box.

Well, pushed for time, I found some 12V LDO linear regulators and got for next day. Oddly when installing these to give an exact 12V clean DC for the Shelly, the ones that were not working still did not work?!? I tried yet more, and they did work.

What is even weirder is one that was working off 14V did not work off 12V, so I had to find another. It is a good job I had 20 of them.

So it seems the 12V working, is, err, fussy, and inconsistent.

Anyone else seen this?

What a week!

This has been a hell of a week, and far more actual hard work than I am used too, and after it all (averaging over 15k steps a day) I have not even lost any weight!

The plan was simple, replace existing 7 door system, and PIRs and exit contacts, and so on. 28 modules in total. I have carefully made and tested all the modules and spares. All ready to go.

But I ended up making work for myself by tidying the wiring. The new system just needs power, so ended up with 6 battery boxes, and removing the old power and bus wiring. Much neater. I also needed to change the exits from rangers (that were unreliable) to new exit buttons, and hence also needed to change the break-glass boxes as they were integral. And I wanted to move the break-glasses further from the letter box (for obvious reasons). This meant running wires down the aluminium door frames on the front doors (to be tidy), which is easier said than door. I probably wasted a day on that (and I had some help). I can recommend NYLON CABLE & FLEX DRAW TAPE 30M (98FT) (screwfix 75807) for the job :-)

Finding the cable runs to bell boxes was also fun, and I gave up chasing wires to original PIR and door sensors and just ran new cables. Ceiling tiles for the win.

We actually have a mystery - the original alarm when we moved in was removed something like a decade ago, but the PIRs were still in place. When the new galaxy alarm was installed new PIRs were put in. I have actually put in new PIRs this time with integral ESP32 WiFi modules in the PIR. Part of the work was removing the galaxy system which replaced have already replaced what was there before, and removing all the old battery boxes. The original PIRs still have power and blink when people move? But there are *NO* battery boxes nor alarm panels in the building at all. I have literally removed them all, and the new battery boxes only go to my new kit. So WTAF. If I had time I'd have investigated further, but it is a mystery!

The result is it took a whole week, and I have to admit I was losing my enthusiasm somewhat during the week.

What did not help is finding some bugs and issues. I expected some, and a couple of small snags were simple, but the biggest issue was the wifi mesh being unstable. It was fine at the start but got worse during the week. I found issues with multiple wifi channels (2.4GHz) which I fixed with config changes on the APs. But I would find the mesh unstable. Reseting the wifi could fix, but not always, and changes to wifi config helped, but not in a concrete way. I wasted a lot of time on that. But ploughed on with the installed.

But Friday it was clear the problem was now intractable - the modules were all resetting every 30 seconds or so. The nice thing is the system was still usable. People in the office could come and go, as it resets very quickly and works autonomously. But it cannot work as an alarm if the mesh is not working.

It seems (and I have to do a lot more bench test and investigation to be sure) that the modules may be running out of memory when the mesh gets beyond around 12 units. This is very disappointing as I I can't see why the mesh would need much memory at all - each routing entry is a 6 byte MAC and very little else. It will be interesting to investigate.

Thankfully the site is two distinct adjacent units, so the fix was to make it two sites. That is a pain, as it means provisioning fobs for two sites, and if someone had not mistakenly ordered only 2k DESFire fobs, that would be easy, so new fobs were programmed, again! Just means slightly more admin. I cut down the sites slightly and ended with both sides with 12 units. When one had 13 it was not quite stable, but 12 seems fine. So we have a work around.

It may be that in longer term we need some modules using ESPs with extra RAM to act as root nodes, something to consider if I cannot track down the memory footprint problem.

Even so, the end result seems really good. Time will tell.

P.S. I have improved stability a lot with some tweaks to the way we work the mesh, but not solved the underlying issue. I suspect big step will be waiting for mesh code in ESP IDF to mature a little. Like cheese.

Solar System goes live

As I have said, I have been working on a number of boards as part of a project that provides access control and alarm functions in a modular way: https://github.com/revk/SolarSystem

I have test systems on my bench, and I now have a small system at home. It is all working well and has helped me iron out some of the bugs.

But this week is the first proper system with 28 live WiFi nodes, meshed, and linked to the back-end cloud control. Scary stuff. It has bell boxes, keypads, PIRs, reed switches on doors, fire alarm inputs, even a panic button in a disabled toilet. Importantly it has a lot of doors. The design is pretty robust, and the whole project is all open source.

My case is packed, and boxes of tools and parts are all ready. It was a lot of work making all the modules. A lot of time with a steady hand with tweezers. I even have half a dozen spares, just in case.

So the night before I head off to start the install, I have imposter syndrome kicking in. How did I think I could possibly design and make a complete access control and alarm system from scratch (PCBs and s/w)? Well, seriously, I need to give myself a kick - I have been doing this shit long enough to know this is bullshit. It will be fine.

Assuming all is well (and I know there will be teething problems, bugs, and features, all of which will need addressing), my next big challenge is whether I can progress this in to a proper product to sell. At the very least, to make the modules (as pictured above) something we can legally sell.

In the mean time, other hackspaces that are interested, do get in touch, and I can help you set up such a system.

NHS covid pass

I decided to check how I get an NHS COVID19 pass / QR code.

Update: Thanks to all that pointed out the couple of subtle clues on how to get an NHS login, which I missed initially.

I googled, and it seems you can ask for a letter or get it digitally, cool. But you need an "NHS login".

Well, I don't know what an NHS login is, but there is this helpful site, https://help.login.nhs.uk which tells you all about it. Nice.

This looks comprehensive. But I don't have an "NHS login", so let's try the "How to set up [an] NHS login"... https://help.login.nhs.uk/setupnhslogin/

OK, we have "What is NHS login" and "What you need to set up an NHS login" (yes, an "an" this time). There are other pages with more information on how to prove who you are, etc. There is the "Where can you use NHS login". OK, good.

Update: For those saying "just use the NHS app", I'm in Wales now, and it does not work!

Update: Oooh, it says clicking the button lets you create a login there, missed that the first time, but the the actual login page does not say that.

But call me thick, and maybe I am being blind here, but where is the "Register for an NHS login" or "Create an NHS login" link or "how to" on that? I looked around and cannot find it. It does not seem to actually tell you "How to set up NHS login" at all, missing that one crucial step of how you start the process!

I kept looking and I found the NHS COVID pass page, https://covid-status.service.nhsx.nhs.uk which has a login link.

Nothing about registering or creating an NHS login on there either. What am I missing.

Well, on a whim, I clicked on the "Continue with NHS login" link, even though I don't have one. Is continuing with NHS login when I don't have one "hacking"? A breach of The Computer Misuse Act 1990 maybe? You then get a login page...

Well, I don't have an "NHS login". What I did not spot initially was the "If you do not have an NHS login" bit. This seems to be the first clue that maybe I can make one if I enter my email address anyway. Why is this hidden away behind a "Continue with NHS login" link?

So now I get the option to "Set up a new NHS login". This is what I had been looking for all along. How the hell is this not on the the help site, or, well, anywhere before you actually try and "login"?

Update: One page for COVID19 Pass does say "You will need an NHS login to use these services. You'll be asked to create one if you do not have an NHS login already" but the page you then go to does not say that, just "continue with NHS login".

Anyway, I continued to create an NHS login. You go on through a few info pages, and create a password, and then this error...

Well, that is helpful. Giving that the previous page was password selection, and I used the browsers password manager to make a "secure" password, I naturally assume it is as password issue. So I try entering a password manually. I tried several passwords, simpler and simpler, and no joy. It simply would not work.

Then, on a whim, I tried a different email address. Just to be clear, that first page does do some validation on email addresses, e.g. ...

So I really had no reason to expect that it was unhappy with my valid email address. But indeed, using a different email address, it actually allowed me to proceed beyond the password set up. I have emailed them asking that they correct my email address, obviously.

When it came to mobile checking, I decided to use an 07 number, rather than trying 01 number, as clearly it is a stupid web site.

The domestic (48 hour!) QR code does not need any more than name, DOB, NHS number. The other longer pass needs ID image and a video and I'm waiting for that to be confirmed now. However, having seen someone else's, I note that the document says this...

OK, so it has an expiry, but how exactly does that expiry "protect you data privacy". The barcode does not fade after 30 days. The "data" is still in the expired barcode, and can still be read. So how exactly does the expiry protection anything - how does it do any more than cause inconvenience for the user?

Indeed, I am told if you request a COVID letter, there is no expiry - so do they not care about your data privacy when sending a letter, or was that just a lie? Having an expiry actually makes "data privacy" worse - if you printed the QR code, you will have to dispose of that securely somehow every time it expires. Why not just be honest?

And finally... The Welsh site https://gov.wales/nhs-covid-pass-prove-your-vaccination-status says :-

But the "domestic" QR code it gives you says ...

So how do I get a QR code valid in Wales?

Review how emergency services handle location data from the public.

I found an interesting web site which does rather highlight some of the issues with what 3 words, w3w.me.ss. Well worth a look.

Sign the petition!

Whilst it is a fun application, a novelty, I personally do not feel it has any place being promoted by emergency services. And this post is my honestly held personal opinion, as always.

If they want to "handle" w3w addresses from the public, that may make some sense, as it is popular. If the app if given to them free of charge (as seems to be the case), and if they take any w3w address with some caution, checking the location by other means if possible, then yes, fine.

But reports on social media (including from people I personally know) suggest that w3w is not just "promoted" by emergency services but actively preferred to the extent that call handles will refuse to take simple o/s grid references and insist on a w3w address. For one recent case, the police force in question confirmed that they should have taken an o/s grid reference. But in practice this seems not to be the case.

What seems worse is stories of people being talked through downloading the app on an emergency call. This is quite incomprehensible. Even if you want a w3w address for some reason, it is far quicker to send someone to the w3w web page (what3words.com) which shows your location. The only possible reason to download the app is so the user has the app on their phone. It is a purely marketing activity, as someone is more likely to use w3w if they have the app. Do we really want emergency services actively engaged in time consuming marketing activity for third party closed commercial apps, during an emergency call?

As I say, much of this is anecdotal, but social media is full of this, as highlighted by w3w.me.ss.

What is especially odd is that w3w's own terms and conditions are not consistent with use in an emergency. They expect you to read, understand, and agree many thousands of words before use, and expect you to check the terms before every use. This is not sensible for the caller, and the emergency call handling staff, to do in an emergency situation where time is critical. Also, the terms prohibit use where it could lead to someone dying, which is often the case in an emergency. Given these clear terms, it makes no sense emergency services would even be considering w3w usage, let alone promoting it. It is almost as if they did no checks at all on how it works or even just reading the terms.

There are ways to get location from callers, not just (long standing, open standard) alternatives like o/s grid references or even simple latitude/longitude, but means that don't involve any reading out, like SARLOC or AML. These should be available to emergency services. Even if there is need for a caller to give a different location, knowing where the caller is puts that in context and helps eliminate errors, whatever format is used.

So, in order to try and address this, I have made a petition. It calls for "Review how emergency services handle location data from the public." which I think is fair.

Sign here! And do share the link to get some traction, if you agree this needs reviewing. Of course, if you feel strongly enough, it is also worth contacting your MP over this.

[non] changes to Highway Code rule 170

There is a lot of talk of changes to the Highway Code that are happening, notable rule 170.

Some motorists are really cross at the "new rule". There is always some bad feeling between cyclists and motorists, but this is especially odd, as the "change" is not really a change at all. So the only people cross over it are those that clearly have no clue the rule already exists.

How is it not a change?

The existing rule says "watch out for cyclists, motorcyclists, powered wheelchairs/mobility scooters and pedestrians as they are not always easy to see" so motorists already have to be on the look out for pedestrians when at side roads.

It also says "watch out for pedestrians crossing a road into which you are turning. If they have started to cross they have priority, so give way". It makes it very clear a pedestrian crossing a side road has priority.

The "new rule" only makes a very tiny change to this, as it requires motorists to give way to pedestrians "about to cross the road".

But it is hard to see how that is not, in effect, already the rule. Motorists already have to watch out for pedestrians, and a pedestrian can change from "about to cross the road" to "crossing the road" in a tiny fraction of a second by putting their foot out. I mean, this can happen far quicker than a car getting to the pedestrian, so the motorist (watching out for pedestrians) has to allow for that happening and be prepared to give way to the pedestrian crossing the road at a moments notice. It is hard to see how this is different to the new rule. So in that respect the rule has not really changed. The only other aspect of this change is from the pedestrian point of view where they may feel empowered to cross a side road rather than wait for a car - but, as always, pedestrians have to be on the look out for motorists unaware of, or ignoring, the rules.

All of the back-lash I have seen on this ignores the fact that pedestrians crossing a side road ALREADY HAVE PRIORITY over vehicles turning in to the side road.

The Highway code even has an image showing a pedestrian that would not see the car is planning to turn (even if they looked a moment before), which is, I am sure, why the rule exists.

Publicity

It is obvious from the posts on social media that a lot of motorists have no clue about rule 170. I also see this every day as I cross a side road on my walk. The typical scenario is a car, STATIONARY on the main road, waiting for traffic the other way, and I start to cross the side road. The car then expects me to stop in the middle of the road to let them turn in to the side road because of a gap in the motor traffic. I don't try to get run over, but I do make it clear that, obviously (as per the Highway Code), I am not expecting to stop. This has led to enough drivers getting cross (apparently they never read the Highway Code) that I even have cards with rule 170 printed on them to hand out.

So this non-change to the rules makes no difference on its own. What will make a difference is all the publicity it generates. Hopefully it will make drivers aware of the rule that has always existed, and the somewhat cosmetic change to that rule, and they can start giving way to pedestrians at side roads as they always should have.

Anomalies...

I do hope they clear up two anomalies I have noticed in the rules though...

• Pedestrians crossing the side road have clear priority over vehicles turning in to the side road, but I don't see anything saying they have priority over vehicles leaving the side road. So in effect they have priority over half the road. This seems like a mistake, and maybe there is some other bit of the highway code that even I have missed that says this. It would be nice to make the priority apply for the whole width of the road.
• The priority is over vehicles "turning" in to the side road - but what of a cross roads or a side road on a bend where no "turning" is needed. As written, the rule does not apply in that case. I hope the new rule makes that clearer, maybe using "entering" the side road, or "entering or existing" (as above).
• It is not entirely clear if the rule covers things that may not really be a "side road", such as an entrance to a private car park, etc. I assume they are a "side road", but are they? I am not sure, so maybe the new rules could make that clear too.

Fun with DHCP

We have had a slight issue at the house here, we have some Apple HomePod things. My son decided to put several in the house when staying here and now my wife is using one.

The snag is that they keep falling off the internet! A power cycle fixes, but it is very frustrating.

I have found the solution though, and I think it points a finger at the cause.

And it is all down to DHCP. Yep, not DNS this time. Not IPv6 even. DHCP!

So what's the problem?

First off, what's the kit?

• FireBrick doing DHCP and Internet gateway
• Aruba APs
• Apple HomePods

The failure did not seem to be all the time, but could be. Sandra has almost given up using them as they never work. But it seems it can usually renew its DHCP without problems, but sometimes it gets stuck. The logs on the FireBrick showed we kept sending a DHCP "Offer" to the HomePo, but it keeps asking.

I added lots of debug, and confirmed that the request being sent, the DHCP "Discover", does not request a broadcast reply, which is fine, so we send the reply to the MAC of the HomePod and its "new" IP address. This is normal.

On a whim, I decided to try fudging the code to treat the discovery as if it has asked for a broadcast reply. This then meant a Discover, Offer, Request, and Ack - but the HomePod did not see the Ack and so kept asking. I then forced the broadcast on the Ack as well, and bingo, it worked. So the issue is the broadcast used for Offer and Ack.

This is a massive clue.

So more investigating.

The RFC says the broadcast request is in the left most bit of a 16 bit flag field.

PLEASE DO NOT DO SPECIFICATIONS LIKE THIS!

I fully understand that bits in a byte may be sent "on the wire" low or high bit first, or high to low bit first. I fully understand that bytes in a word may be ordered big endian or little endian. The above diagram is for a 16 bit "network byte order" value (i.e. big endian).

They number the bits from 0 to 15. Actually they number the gaps between the bits 0 to 15.

In my view there is only one way you should number bits - by their binary power of two value. I would always write that in the way we write numbers, most significant first, so would write that as bits 15 to 0, and it is bit 15 that is the B flag. I don't mind if showing as bits 15 to 8, and 7 to 0 (big endian) or even as 7 to 0, 15 to 8 (little endian), but number each bit by its power of two value, please!

Some people number as order on the wire, starting from 1. So 1 to 8 may be 0 to 7 or 7 to 0, who knows! Please do not do that. But at least if numbering bits 1 to 8, you have some clue that something is wrong.

So, to be quite frank, I actually do not know if this is bit 0 or 15 in a network byte order (big endian) 2 byte (16 bit) value. We assumed it is bit 15, i.e. bit 7 in the first byte. But seriously, from bits numbered 0 to 15 and a reference to "left most bit" I don't actually know for sure. I started to doubt we had read the RFC correctly!

Thankfully empirical testing shows the flags as 0x8000 from other devices, so either it is bit 7 of first byte, or other devices have the same fun reading the RFC. 

So who is at fault here?

Well, my son has the same FireBrick and the same HomePods, but different APs. That all works. That is another clue.

My Aruba APs are set up to inject data in the DHCP, which is good. I get details of the AP and SSID, and can even tell the FireBrick to allocate based on SSID even if different SSIDs on the same physical network. All good.

It may be that it is stripping the broadcast bit, bit that does not explain why it works after a power cycle. Interestingly the working DHCP renewals did not have the injected AP details, it seems. This points further to the AP being "special"

My son does have different network switches as well, so it is just remotely possible that it is a switch level issue, but that seems unlikely - the DHCP discovers are from the right MAC so all switch learning should be fine.

P.S. Yes, I had changed the filtering to disabled already.

The work around...

FireBricks now have an option to force broadcast reply. And it works. Alpha out soon.

Freestyle Libre vs Dexcom

I have used freestyle libre CGMs for a long time.

Yes, obviously, I’m diabetic, but I have always felt like a sort of amateur diabetic! I take one injection of slow acting insulin a day, not like real diabetics that have match a dose to what they eat every meal. I did not know imposter syndrome was a thing with diseases :-) However, having seen the CGM readings for a couple of non diabetics now I can see that my blood glucose is very different to “normal” and feel a tad more “legit”…

But not having to match insulin to every meal (I take tablets with meals to help) I’m not the normal target for a CGM. However, if you can afford them, I would recommend them for anyone who is diabetic even if like me it is more “mild”. Indeed, perhaps even more so where I cannot easily compensate for eating the wrong thing, the CGM has helped me get my diet right (on most days). My reaction to carbohydrates is far from obvious as some simple things can send my sugar spiking but others are no problem. The CGM helps me learn the problem foods and drinks, and what is not a problem. Even so, that is not always consistent, and can have surprises...

For example:-

• The small hump on the left last night was an evening meal with loads of rice and vegetables.
• The big spike in the middle was breakfast, which was a single sandwich (i.e. one slice of bread cut in two) and bacon, with a tablet even. No idea why so high!
• The small hump on the right was a large roast beef dinner, vegetables, and even a nice cherry cheese cake with syrup - which I expected to be a "problem"...

Not an ideal day for sensible diet, but the effect is not anything like obvious from the meals!

However, one issue with the freestyle is they occasionally screw up and don't work. Yes, in theory, I could send them back, but it got so annoying I decided to try a Dexcom instead.

Freestyle libre

• Each sensor lasts 14 days - means changing on same say of week.
• Takes one hour to warm up at start.
• Has to be scanned regularly, and only holds last 8 hours. Any older data lost if not scanned.
• Works out around £25 a week.
• The newest model has alerts for low/high but still needs scanning for readings.
• Occasionally screws up and you waste a £50 sensor. Yes, could send it back.

Dexcom

• Sensors lasts only 10 days.
• Works out around £37 a week (on yearly plan).
• Takes two hours to warm up at start.
• Updates phone via Bluetooth so no scanning. Seems to catch up if not near phone for a bit, but no idea how much memory.
• Has alerts for low/high, or soon to be low/high.

The actual sensors are different, the Dexcom has sensor and transmitter. It is bigger, has a bigger sticky patch, and thicker. The transmitter is silly - 3 month life limit and buy a new one (I included in above price), but seriously, in one off, it is £200! Why not 50p for a new button cell? And it is not like it is more complex that the whole freestyle sensor which is £50. Definitely some level of price gouging there, in my opinion.

Having said that, their web site makes no sense - you can buy packages, or individual sensors as it says "You can always choose to pay as you go, purchasing Dexcom products whenever you need them". However, the individual sensors say "Limit: 1 per user". So do they mean you can only buy "one at a time", or "one, ever". I assume "one at a time", but if that is the case the Starter pack (3 sensors and transmitter for £159) which says "Limit: 1 per user" would be the best deal of all, if it means "one at a time", so I have no idea!

The other thing that is interesting is the difference in the actual readings... Here is the last 24 hours on Dexcom and Freestyle.

The breakfast peak shows as 15.3mmol/l on the Dexcom, and under 13 on the Freestyle. The dips over night (that caused an alarm) shows as 3.1mmol/l on the Dexcom, and nearer 4 on the freestyle.

Scaling and overlaying you can see they are close, but not quite the same.

Problems!

The sensor lasts 10 days, well should do. I managed 5 days before it was too painful, and I removed it. The start pack has three, so I'll try one on my arm, but if that does the same I'm going to ask for a refund. Never had this with the FreeStyle Libre.

FYI, a week later this is still not healed properly - it is getting there but pretty serious reaction. I tried on my arm, and whilst the reaction was a lot less severe, I had to remove it as it was too irritating after a few days.

Dexcom are being slow to do anything. I've filed an MHRA report anyway.

Is this getting boring?

I have been working for two weeks on this cloud based management for my access control system and it is going well.

There have been a couple of days of total head-bang-against-wall stupidity, but mostly going well. I ended up making a new MQTT client module for my ESP32 as part of it even. The practice in MQTT server and client code bodes well for my putting MQTT in FireBricks, by the way.

One of the things I did was send a controller to someone from a hackspace and I have to say that was a great decision. He is making helpful suggestions and finding bugs and asking sensible questions. If you want the perfect tame customer, they are the ones!

I have some shiny new boards, yay!

So yes, that is progress.

Next week I have other work to do, but I'll come back to this with feedback from the first couple of real users, including a hackspace.

New door entry and alarm system

I am thinking of the next generation of my SolarSystem alarm system.

It started as RS485, a slot in replacement for a Galaxy system using the same external devices, and running on a Raspberry Pi with USB RS485 adaptors. It worked quite well.

The next generation used ESP8266, then ESP32 based WiFi connected devices. This works well.

Next generation

I am now planning to get rid of the Raspberry Pi and RS485 completely. The idea is the ESP32 modules work together over a mesh WiFi. Yes, one of them would connect to a conventional WiFi access point, but they can work without that - off 12V battery backup if needed, with no "controller" as such.

This is not that complex - devices need to know what inputs and outputs link to what areas and states in the system, and broadcast information to allow every unit to know when alarm armed, or triggered, etc. Using secure AES encrypted DESFire key fobs on door controllers the alarm can be set and unset.

There would still be a "controller" to configure the system, program fobs, record logs, and so on. But this could be a cloud based service. Some of you know my love of cloud based services (not), and as this is all open source it would allow the cloud service to be run locally. But the server is not a "live" part of the system - it allows config, and so on - via a simple web page. Obviously communications would then be secure to the server.

This makes everything simpler to set up as you just need a local WiFI internet access.

To make it work I now have designs (and several prototype boards and cases) for key components:

• Door controller module and NFC reader (can be used as 6 input 1 output module)
• Bell box module (also usable as a 2 input 4 output module)
• General purpose I/O (5 GPIO with ADC if needed)
• Keypad module (fits in galaxy keypad and talks RS485 to it locally)

The nice thing is that just one of these, eg door control, can be set up to talk to local WiFi/NAT and connect to a cloud service allowing configuration of an access system. But you can then add other modules, and set up a whole alarm system if you want. The key fobs have access controls such as which doors, and times of day and days of week that are allowed.

More serious work needed

The issue is that I need to do quite a lot to complete the design and coding for this - not just in the modules, but the controller system and database back end. This is all pure R&D work at present with no concrete customers for the system (though we have had some interest), which can make it a bit hard getting the motivation - but a real customer would also help ensure we are steering the project in the right direction.

Bootstrapping security

One of the design challenges is bootstrapping the security of key fobs and controllers. They need AES keys, and these need to be secure, and need to get in to devices and fobs.

In simple practical terms, you can just buy fobs from the likes of Amazon, and then use one one of the NFC modules - e.g. one of the doors - to program the fob. Similarly you can make ESP32 modules, or use off the shelf modules like nodemcu and flash the code.

But you have to be very sure that this is actually being done by someone authorised to program fobs. Even then, if someone wanted to, they could capture that initial config and get the AES key used. Once the AES key is know the system for a whole site can be compromised.

Once the fob is programmed, any capture of the communications does not help you, but the initial set up of a fob is inherently insecure - this is the bootstrap problem - it has to be insecure as the fob is blank and it has to get the keys - so someone can "pretend to be a blank fob" and get the keys in the same way.

You have the same issue with end devices and a cloud system - you have to be sure the device is the device you think it is. If someone can get a fake device on a system it can get keys. So the devices need a secure client identity too.

I suspect the answer is simple - design the system so that the controller will only do initial config of devices and fobs locally (e.g. USB connected). The controller then sends out the devices and fobs pre-set for the site. Of course this means for a cloud based service the service operator provides the devices and fobs - which may make it more commercially viable to operate a cloud service.

Security

Of course any system has to consider security - the AES/DESFire fobs are massively more secure than 125kHz fobs used by Galaxy Max readers. The WiFi is a bit of a trade off: It is way more secure using WIFi and TLS than RS485 (Galaxy modules can have messages inserted on the bus without it noticing!). It is possible to disrupt (just as cutting an RS485 bus is, which is exposed on outside of building if using Max readers), but like RS485 it would trigger an alarm. At the end of the day you have to be more secure than breaking a window.