Surely you have ultra-wideband radios on your bins too?

How I massively over-engineered a trivial problem again because I just can't help myself

Home Assistant already knows which bins (trash cans, for the international readers) are due for collection. It can tell me it’s bin night, put the right colours on a dashboard, and send me a reminder. What it can’t tell me is whether I’ve actually done anything about it.

I’m pretty sure most folk would just set a recurring reminder on their phone. As my wife will no doubt tell you, I am not most people. Some would just remember to put the bins out, like a normal person. I’m well aware that I’ve ridiculously over-engineered this. I’m also so far from normal that six radio-equipped bins seemed like an enjoyable way to spend my evenings ;)

I had an idea a number of years ago to stick cheap Bluetooth tags on my wheelie bins and use an outdoor Bluetooth proxy to work out whether they were nearby. It was frustrating. The batteries drained quickly, the proximity readings wandered about, and the proxy was unreliable in that particular installation. I wanted to know whether a bin had moved. I mostly acquired another thing to fiddle with.

AirTags were what first got me intrigued by ultra-wideband radio, or UWB. Reading more about how it worked brought the bin idea back. Over the last few weeks it’s become BinRange: a fixed radio anchor, six little battery tags, and a Home Assistant setup that combines where the bins have been seen with when they’re due. There’s a printed enclosure, custom firmware, and wireless updates as well. All of which is a fairly substantial answer to “have you put the bins out?” :D

I leaned heavily on Codex throughout the build. Astra became available part-way through, and I was really curious to see how it would do. What I love about working with AI is how quickly I can take an idea, react to the result, give it some feedback, and have something else to try. There’s plenty to write about that in other articles. For now, back to the bins.

There you go, some bins. Beautiful, right?

We have one general waste bin, one food compost bin, one garden waste bin, two recycling bins, and a glass bin. Six bins. At one house. They’re not even all on the same collection schedule. I’m grateful that the Waste Collection Schedule integration for Home Assistant scrapes the council’s schedules and keeps track of what’s due, because keeping that straight is a job in itself.

With the cheap Bluetooth tags, the way to estimate distance was RSSI - received signal strength indication. You measure how strong the received signal is and use that to guess how far away the tag might be. The trouble is that signal strength depends on far more than distance. Walls, parked cars, reflections, antenna orientation, and differences between the radios and their antennas all affect it. Even battery voltage can affect the transmit power on some hardware, depending on how the device is designed. A weaker signal could mean the bin has moved further away, or it could mean something got in the way. It’s a very imprecise way to estimate distance, which explained why my original setup was so frustrating.

UWB was interesting because it measures the time taken by radio signals to travel between devices. That gives a distance measurement without having to guess it from signal strength. It still has to get a signal through the surroundings, of course. Choosing a different radio doesn’t make parked cars disappear.

I also spent a while detoured into an academic question about how many anchors I’d need to add more dimensions to that awareness. What if I wanted to know the direction as well as the distance from a point? Or the bin’s precise location - how many fixed reference points would I need to triangulate it on a 2D plane? Totally not worth it for this job, but tangential thoughts be tangential thoughts.

For the bins, I only needed to know whether each one had moved far enough from its usual storage area to count as Out. One anchor was enough to start testing that. I used a ten-metre boundary: inside is Home, beyond it is Out, when there’s a fresh reading. It’s specific to my installation, but it meant I could start with one powered board rather than turn the garden into a positioning test range.

The first experiment used two Makerfabs ESP32-WROVER/DW3000 boards, both powered over USB. Before doing anything clever with Home Assistant, I wanted to see them measure a distance. A local web view let me separate them and watch what happened without needing a USB cable stretched between the two.

One of the development boards. This is the DW3000 model used in the experiment. Hardware reference.

The antenna orientation made a surprisingly large difference. At about ten metres, changing the boards from flat to upright took the observed success rate from 37% to 100% in that test. A slower radio setting with a longer preamble also worked where the initial fast setting struggled. These were useful discoveries to make before designing anything around the first result.

The first time I calibrated it with a tape measure and watched the reported distance differ from my measurement by less than two centimetres, my mind was utterly blown. Two little boards were exchanging radio signals and agreeing with a tape measure to that degree.

In the later recorded test, a measured gap of 10.1 metres produced an average reading of about 10.09 metres, with a standard deviation of three centimetres. That was encouraging for a project which only needed to recognise a bin leaving a storage area. The under-two-centimetre result was what I saw in that first calibration, rather than a promise of that accuracy for every tag, orientation, or outdoor position.

The outdoor walk was more revealing. Readings were reliable to roughly thirty metres, then intermittent further out. The furthest recorded reading was 37.28 metres, with gaps. A car could block the path completely. Holding a board upright in the open and mounting a little tag beneath a bin rim were clearly going to be different tests.

The two-board walk test. It established a useful starting point; it doesn’t establish coverage for the installed bins. Recorded findings.

The anchor publishes its readings over MQTT, and Home Assistant discovers a separate device for each tag. I considered an ESPHome component, but it wasn’t adding much to the arrangement I wanted. There’s no extra BinRange server or cloud service, and the radios can keep ranging while Home Assistant or the MQTT connection is unavailable.

The development boards were useful for proving the link. I didn’t want one hanging off every bin, with a battery and an improvised box attached. The bin-side hardware needed to be a small, self-contained puck.

I explored custom tags and commercial ones, with the important question being whether I could run my own firmware and use them with my own anchor. A small UWB tag isn’t automatically compatible with another UWB product. The packaged tags I eventually bought were KKM K4Ws, with an nRF52833 processor, a DW3110 radio and a LIS3DH accelerometer. They take removable CR2477 coin cells (which, btw, are some chonky boy coin cells! I’ve not seen them before, thems fat).

The two Makerfabs boards came to US$123.64 including shipping. Ten sample tags at US$25 each, a programming jig and shipping came to another US$330. Those are what the experiment cost at the time, rather than a current shopping list or the cost of a finished six-bin kit. I suspect I should avoid calculating a payback period.

The supplier said the tags could run my firmware and offered a jig to reach the programming connections. I was far more interested in the hardware they were supplying and knowing that programming access wasn’t locked out in some way. None of their existing software features mattered to me. Claims about battery life were meaningless for my use once I was going to be the one deciding when the CPU slept and what woke it up.

I’m pretty familiar with nRF52 devices. I’ve used them for years, going back to my time at rlab. They make brilliant little low-power microprocessors, happy to spend most of their lives asleep. If you’re clever with your scheduling and interrupts, you can drag these things out for years on a small battery in the right application. That was much more interesting to me than whatever the supplied firmware happened to do.

I used a spare Nesso device as a programming probe for the pogo-pin jig. I started with a development tag, then commissioned the packaged ones one at a time: programme it, establish its identity, pair it, label it, assign it to a bin, and put it back together. There are several identities involved, including the printed label, the chip identity, and the addresses used by the radios.

Side note: the cases the tags were supplied in had seemingly unique serial numbers printed on them, with QR codes containing those serials. Presumably they serve some purpose in the supplier’s stock firmware and software. I couldn’t find any association with the embedded devices’ MAC addresses or similar identifiers, so they were essentially useless to me. Which is a shame really - if they’d been the radio MAC addresses, for example, that would have been useful!

Close-up of the bin tags stuck to the bins. You can see how chonky they are, those batteries are big! They fit nicely under the rim though, which will keep rain mostly off.

The manufacturer had connected the accelerometer’s interrupt output to a GPIO pin on the nRF, which is incredibly useful. It means I can let the nRF sleep for very long periods, send no radio traffic during that sleep, and wake it up when a physical event happens. Once things settle down, it returns to occasional check-ins, with the UWB radio sleeping between attempts. The firmware default is ten minutes when stationary; I’ve since changed the installed fleet to thirty minutes using controls in Home Assistant, while keeping the five-second moving reports.

That should avoid spending the battery repeatedly reporting that a bin is still sitting where it was. How much life it actually buys is something I still need to measure. I’m collecting voltage and activity information, but a short, fairly flat voltage trace doesn’t give me a defensible estimate in months or years. I’m definitely not interested in using the majority of the battery’s life reporting its own voltage. That seems low value ;)

Once a tag is mounted, opening it up and putting it back on the programming jig every time I change the software becomes rather unappealing. The anchor can now deliver signed firmware updates to paired tags over Bluetooth. The previous application is retained so a bad update can roll back, and the system only reports success once the tag is running the exact expected image and has confirmed its own health.

Testing and iterating on this sort of thing is another fantastic use of AI. Codex helped me generate and simulate a whole range of test conditions and failure modes, then work through them to make deploying firmware to one of these things over the air as safe as possible. I tested corrupt images, interrupted transfers, selected power-loss points, and watchdog recovery. I also tested what happened when the anchor wasn’t there: the tag needs to confirm that it’s healthy without a radio reply, rather than abandon working firmware because it can’t reach the anchor.

Going from one tag to several found a different sort of problem. A record in the Bluetooth library had been sized for the number of simultaneous connections rather than the number of paired devices. Adding a further tag could fail even though its keys had been stored. Fixing that meant a new physical tag could pair without clearing the existing ones. Six bins gave the software a better interrogation than one agreeable demo tag.

I’ve since updated the installed anchor and all six tags wirelessly without re-pairing them or reaching for the jig. I’m pleased about that. Some earlier connection attempts neede