Bluetooth Low Energy DEFCON

I have been meaning to get my head around Bluetooth for some time, and I think I have finally come up with a project idea which is a bit whacky, but I think should work.

I have discovered that Bluetooth Low Energy (BLE) is different from full bluetooth, something I had not realised, but that BLE should do what I want. The little ESP32 chips with which I am very familiar can do BLE, so this should be simple (LOL).

So here is the idea - DEFCON box. I have one of these at home :-

The way this works is that it shows a DEFCON level depending on who is in the house, so each of the kids has a level, and the lowest level shows. It beeps and the lights click as the go off and on to change levels. All good fun. We know who is about to open the door just before they do...

However, the way it actually works is quite complex. It works on WiFi and MQTT and is told by an MQTT command what level to show. The command comes from a FireBrick, which uses its profiles to decide what level applies. It does that based on the DHCP leases for people's phones on the WiFi. It is really quick to pick up people arriving, but takes the DHCP lease timeout to realise they have gone. But in spite of this complexity it works.

I did think it would make a fun present for someone, but the complexity of WiFi, MQTT, FireBrick and so on makes it really not simple to set up at all.

So this is where BLE comes in...

The idea is that it would scan for BLE devices and pick up phones being present directly. Of course BLE is designed to not allow you to track people, so needs a bit more, and it needs a simple way to tell it which phones are which DEFCON level.

The idea is a button, you press it, and press it repeatedly to pick a level that will flash. The device would be BLE discoverable so show on a phone, and the phone then connects and bonds with the DEFCON device. It then remembers the phone and the level. Because (I hope) the bonding will have an identity resolution key for the phone, it should be possible to passively scan and work out when each phone is present or not.

This makes for a really simple user interface - one button and bond from a phone.

Of course I may face issues with the libraries. A passive scan to find a device you know may not be possible as normally when found you connect to confirm the device is not a fluke random match (which, for this application I am not really too worried about). I'm also assuming a phone will tell my device a key for this - it may not, or may only if it thinks the device is something it expects to want to request a connection. But even so, I can try, and this should cover quite a lot of BLE learning.

So, watch this space :-)

Update1: Demo code works - but I need to advertise only when adding a phone, and as something an iPhone would want to connect to, this was pair using a BLE app not the main settings menu. And I need to work out scanning. Much to do.


  1. One thing to consider (as a complement to DHCP leases) is listening for ARP announcements for the MAC address. My understanding is that these are broadcast so can be picked up by any device on the network, and they seem to be sent quite regularly. You're looking for the absence of packets, so it's still not real time but you could probably set it for less than 10 minutes

    1. You tend to see ARP "announce" only when allocating an address and not as a regular thing, and less so from something like a mobile phone.

    2. Not sure whether I have something set up wrong then, but on my network I get frequent ARP lookup requests (eg when a device wants to talk to the internet it asks for the MAC address of the router by ARP broadcast), and Gratuitous ARP announcements (iDevices at least seem to send these out periodically). It does look like these only get sent regularly when the device is actively in use though.

      I would imagine you'd also get them when roaming between access points.

      Looking forward to what you discover with BLE though, have wanted to build something similar to this myself for a while

    3. Ah, that is not an ARP "announce", and yes you will see those, but should only be when the phone is active doing something.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

ISO8601 is wasted

Why did we even bother? Why create ISO8601? A new API, new this year, as an industry standard, has JSON fields like this "nextAccessTim...