Heb jij ook ultra-wideband radio's op je afvalbakken?
Home Assistant weet al welke bakken (voor de internationale lezers: prullenbakken) aan de beurt zijn voor ophaling. Het kan me vertellen dat het 'bakkenavond' is, de juiste kleuren op een dashboard tonen en me een herinnering sturen. Wat het niet kan vertellen, is of ik er daadwerkelijk iets aan heb gedaan.
Ik vermoed dat de meeste mensen gewoon een terugkerende herinnering op hun telefoon zouden zetten. Zoals mijn vrouw me ongetwijfeld zal vertellen, ben ik niet zoals de meeste mensen. Sommigen zouden simpelweg onthouden de bakken buiten te zetten, zoals een normaal mens dat doet. Ik ben me er terdege van bewust dat ik dit belachelijk heb over-engineered. Ik sta zo ver af van 'normaal' dat zes radio-uitgeruste bakken me leken op een prettige manier om mijn avonden door te brengen.
Enkele jaren geleden had ik het idee om goedkope Bluetooth-tags op mijn kliko's te plakken en een outdoor Bluetooth-proxy te gebruiken om te bepalen of ze in de buurt waren. Dat was frustrerend. De batterijen raakten snel leeg, de nabijheidsmetingen fluctueerden en de proxy was onbetrouwbaar in die specifieke installatie. Ik wilde weten of een bak was verplaatst; in plaats daarvan hield ik vooral iets nieuws over om mee te prutsen.
AirTags waren het eerste dat mijn interesse wekte voor ultra-wideband radio, of UWB. Door meer te lezen over hoe dit werkte, kwam het idee voor de bakken terug. De afgelopen weken is dit uitgegroeid tot BinRange: een vast radio-anker, zes kleine batterij-tags en een Home Assistant-setup die combineert waar de bakken zijn gezien met wanneer ze opgehaald moeten worden. Er is een geprinte behuizing, custom firmware en draadloze updates. Alles bij elkaar een vrij substantiële oplossing voor de vraag: "Heb je de bakken al buiten gezet?"
Tijdens het bouwen heb ik zwaar geleund op Codex. Halverwege werd Astra beschikbaar, en ik was erg benieuwd hoe dat zou presteren. Wat ik geweldig vind aan werken met AI, is hoe snel ik een idee kan omzetten, reageren op het resultaat, feedback geven en iets nieuws kunnen proberen. Daar valt in andere artikelen genoeg over te schrijven. Voor nu: terug naar de bakken.
Zes bakken, verschillende schema's
Wij hebben één bak voor restafval, één voor GFT, één voor tuinafval, twee voor recycling en één voor glas. Zes bakken. Op één adres. Ze staan niet eens allemaal op hetzelfde ophaalschema. Ik ben dankbaar dat de Waste Collection Schedule-integratie voor Home Assistant de schema's van de gemeente uitleest en bijhoudt wat er aan de beurt is, want dat zelf recht houden is een klus op zich.
Bij de goedkope Bluetooth-tags was de manier om afstand te schatten via RSSI (received signal strength indication). Je meet hoe sterk het ontvangen signaal is en gebruikt dat om te gissen hoe ver de tag weg is. Het probleem is dat signaalsterkte van veel meer afhangt dan alleen afstand. Muren, geparkeerde auto's, reflecties, antenne-oriëntatie en verschillen tussen de radio's en hun antennes beïnvloeden dit allemaal. Zelfs de batterijspanning kan de zendkracht beïnvloeden, afhankelijk van het ontwerp van het apparaat. Een zwakker signaal kan betekenen dat de bak verder weg is, of dat er iets in de weg staat. Het is een zeer onnauwkeurige manier om afstand te schatten, wat verklaart waarom mijn oorspronkelijke setup zo frustrerend was.
UWB was interessant omdat het de tijd meet die radiosignalen nodig hebben om tussen apparaten te reizen. Dat geeft een afstandsmeting zonder dat je hoeft te gissen op basis van signaalsterkte. Natuurlijk moet het signaal nog steeds door de omgeving komen; een andere radio zorgt er niet voor dat geparkeerde auto's verdwijnen.
Ik ben ook een tijdje afgedwaald naar een academische vraag over hoeveel ankers ik nodig zou hebben om meer dimensies aan dat bewustzijn toe te voegen. Wat als ik ook de richting wilde weten, naast de afstand vanaf een punt? Of de exacte locatie van de bak — hoeveel vaste referentiepunten zou ik nodig hebben om deze op een 2D-vlak te trianguleren? Voor deze klus totaal niet de moeite waard, maar zijpaden zijn nu eenmaal zijpaden.
Voor de bakken hoefde ik alleen te weten of elke bak ver genoeg van zijn gebruikelijke opslagplaats was bewogen om als "Buiten" te tellen. Eén anker was voldoende om dat te testen. Ik gebruikte een grens van tien meter: binnen die grens is het "Thuis", daarbuiten is het "Buiten", zodra er een nieuwe meting is. Dit is specifiek voor mijn installatie, maar het betekende dat ik kon beginnen met één gevoede printplaat in plaats van de tuin in een positioneringstestgebied te veranderen.
Twee printplaten en een wandeling buiten
Het eerste experiment gebruikte twee Makerfabs ESP32-WROVER/DW3000-boards, beide gevoed via USB. Voordat ik iets slims met Home Assistant deed, wilde ik zien of ze afstand konden meten. Een lokale webview stelde me in staat om ze uit elkaar te bewegen en te observeren wat er gebeurde zonder dat er een USB-kabel tussen de twee gespannen moest worden.
De oriëntatie van de antenne maakte een verrassend groot verschil. Bij ongeveer tien meter zorgde het veranderen van de borden van plat naar rechtopstaand ervoor dat het waargenomen succespercentage in die test steeg van 37% naar 100%. Een langzamere radio-instelling met een langere preamble werkte ook op plekken waar de initiële snelle instelling moeite had. Dit waren nuttige ontdekkingen om te doen voordat ik iets zou ontwerpen op basis van het eerste resultaat.
De eerste keer dat ik het kalibreerde met een rolmaat en zag dat de gerapporteerde afstand minder dan twee centimeter afweek van mijn meting, was ik echt perplex. Twee kleine printplaten wisselden radiosignalen uit en waren het tot op die graad eens met een rolmaat.
In een later geregistreerde test produceerde een gemeten afstand van 10,1 meter een gemiddelde reading van ongeveer 10,09 meter, met een standaarddeviatie van drie centimeter. Dat was bemoedigend voor een project dat alleen maar hoefde te herkennen wanneer een bak een opslagruimte verlaat. Het resultaat van minder dan twee centimeter was wat ik zag bij die eerste kalibratie, en niet per se een belofte van die nauwkeurigheid voor elke tag, oriëntatie of buitenpositie.
De wandeling buiten was onthullender. Metingen waren betrouwbaar tot ongeveer dertig meter, daarna werden ze intermitterend. De verste geregistreerde meting was 37,28 meter, met gaten. Een auto kon het pad volledig blokkeren. Een bord rechtop in het open veld houden en een klein tagje onder de rand van een bak monteren, zouden duidelijk verschillende tests zijn.
Het anker publiceert zijn metingen via MQTT, en Home Assistant ontdekt een apart apparaat voor elke tag. Ik overwoog een ESPHome-component, maar dat voegde niet veel toe aan de gewenste opstelling. Er is geen extra BinRange-server of cloudservice, en de radio's kunnen blijven meten terwijl Home Assistant of de MQTT-verbinding onbeschikbaar is.
Iets kleins genoeg voor op een bak
De ontwikkelborden waren nuttig om de verbinding te bewijzen. Ik wilde niet dat er aan elke bak een bord zou hangen met een batterij en een geïmproviseerde doos. De hardware aan de bakzijde moest een kleine, zelfstandige 'puck' zijn.
Ik onderzocht custom tags en commerciële versies, waarbij de belangrijkste vraag was of ik mijn eigen firmware kon draaien en ze kon gebruiken met mijn eigen anker. Een kleine UWB-tag is niet automatisch compatibel met een ander UWB-product. De tags die ik uiteindelijk kocht waren KKM K4Ws, met een nRF52833-processor, een DW3110-radio en een LIS3DH-accelerometer. Ze maken gebruik van uitneembare CR2477-knoopcelbatterijen (die overigens behoorlijk stevige jongens zijn; ik had die nog nooit gezien).
De kosten van het experiment waren destijds als volgt:
- Twee Makerfabs-borden: US$ 123,64 (inclusief verzending).
- Tien sample-tags (US$ 25 per stuk), een programmeer-jig en verzending: US$ 330.
Dit zijn de kosten van het experiment, niet een huidige boodschappenlijst of de kosten van een complete kit voor zes bakken. Ik vermoed dat ik het beste kan vermijden om een terugverdientijd te berekenen.
De leverancier gaf aan dat de tags mijn firmware konden draaien en bood een jig aan om bij de programmeeraansluitingen te komen. Ik was vooral geïnteresseerd in de hardware en het feit dat de programmeertoegang niet was geblokkeerd. De bestaande softwarefuncties van de leverancier deden me niet interesseren. Beweringen over de batterijduur waren betekenisloos, aangezien ik degene zou zijn die beslist wanneer de CPU sliep en wat hem wakker maakte.
Ik ben goed bekend met nRF52-apparaten; ik gebruik ze al jaren. Het zijn briljante kleine energiezuinige microprocessoren die het grootste deel van hun leven in slaapstand kunnen doorbrengen. Als je slim bent met planning en interrupts, kun je deze dingen in de juiste toepassing jarenlang op een kleine batterij laten draaien.
Ik gebruikte een reserve Nesso-apparaat als programmeersonde voor de pogo-pin jig. Ik begon met een ontwikkel-tag en configureerde daarna de commerciële tags één voor één: programmeren, identiteit vaststellen, koppelen, labelen, toewijzen aan een bak en weer in elkaar zetten. Er zijn verschillende identiteiten betrokken, waaronder het geprinte label, de chip-identiteit en de adressen die door de radio's worden gebruikt.
Bijbehorende opmerking: de behuizingen van de tags hadden schijnbaar unieke serienummers met QR-codes. Ik kon geen associatie vinden met de MAC-adressen van de apparaten, dus waren ze voor mij in feite nutteloos.
De fabrikant had de interrupt-output van de accelerometer verbonden met een GPIO-pin op de nRF, wat ongelooflijk nuttig is. Dit betekent dat ik de nRF voor zeer lange perioden kan laten slapen zonder radioverkeer, en hem kan wekken wanneer er een fysieke gebeurtenis plaatsvindt. Zodra de situatie stabiliseert, keert hij terug naar incidentele check-ins, waarbij de UWB-radio tussen de pogingen door slaapt. De standaardinstelling is tien minuten wanneer de bak stilstaat; ik heb dit voor de huidige vloot via Home Assistant aangepast naar dertig minuten, terwijl de rapportages bij beweging elke vijf seconden blijven doorgaan.
Dit voorkomt dat de batterij wordt verbruikt door herhaaldelijk te rapporteren dat een bak nog steeds op dezelfde plek staat. Hoeveel levensduur dit precies oplevert, moet ik nog meten.
Zes bakken updaten zonder ze uit elkaar te halen
Zodra een tag is gemonteerd, is het niet erg aantrekkelijk om hem steeds open te maken en op de programmeer-jig te leggen voor softwarewijzigingen. Het anker kan nu ondertekende firmware-updates via Bluetooth leveren aan gekoppelde tags. De vorige applicatie wordt bewaard, zodat een slechte update kan worden teruggedraaid, en het systeem rapporteert pas succes wanneer de tag precies het verwachte image draait en zijn eigen gezondheid heeft bevestigd.
Het testen en itereren van dit soort zaken is een andere fantastische toepassing van AI. Codex hielp me bij het genereren en simuleren van een reeks testcondities en foutmodi, om het uitrollen van firmware over-the-air zo veilig mogelijk te maken. Ik testte corrupte images, onderbroken overdrachten, specifieke stroomuitvalmomenten en watchdog-herstel. Ook testte ik wat er gebeurde als het anker er niet was: de tag moet kunnen bevestigen dat hij gezond is zonder radio-antwoord, in plaats van werkende firmware te verlaten omdat hij het anker niet kan bereiken.
Bij de overstap van één naar meerdere tags ontstond er een ander probleem. Een record in de Bluetooth-bibliotheek was gedimensioneerd voor het aantal gelijktijdige verbindingen in plaats van het aantal gekoppelde apparaten. Het toevoegen van een extra tag kon falen, zelfs als de sleutels waren opgeslagen. Het oplossen hiervan zorgde ervoor dat een nieuwe fysieke tag kon koppelen zonder de bestaande te wissen. Zes bakken boden de software een betere test dan één meewerkende demo-tag.
Inmiddels heb ik het geïnstalleerde anker en alle zes de tags draadloos geüpdatet zonder ze opnieuw te koppelen.
De behuizing kostte meerdere pogingen
Het anker had een behuizing nodig, wat een project op zich werd. Het begon als een OpenSCAD-ontwerp met schroeven. De eerste pasvorm was veelbelovend, maar kleine moeren en bouten, PLA-toleranties en een printplaat die nog kon rammelen, maakten de assemblage vervelender dan ik wilde.
Ik wilde een behuizing die volledig uit geprint PLA bestond, zonder schroeven: taps toelopende positioneringspinnen voor de printplaat, geprinte veren om hem op zijn plaats te houden en een deksel dat bleef zitten. De pinnen en veren werkten, maar het deksel kon alle kanten op bewegen.
Een interne lip verbeterde de pasvorm. Diepere vergrendelingen verbeterden de retentie, maar ik kon het deksel nog steeds te gemakkelijk lostrekken. Toen ik de vergrendelingen zo diep maakte als de wand, braken beide wortels tijdens het plaatsen. Die versie was uitstekend in het worden van twee stukken gebroken plastic.
De betere aanpassing was om de wanden van de basis en het deksel te laten overlappen en meerdere ondiepe vergrendelingen te gebruiken. Na een paar tweaks aan de positioneringspinnen en ventilatieopeningen had ik een behuizing die de printplaat goed vasthield en dicht bleef.
De snelle loop met Codex was bijzonder prettig voor de behuizing: ik kon het ontwerp verfijnen, inspecteren en printen. Ik moest het resultaat nog steeds fysiek oppakken om te ontdekken of het deksel eraf viel. Een geometriecontrole kan vaststellen dat twee vormen in elkaar moeten passen; het vertelt me niet of een vergrendeling overleeft wanneer deze op zijn plaats wordt geduwd.
Het anker is nu aan de muur gemonteerd, met de geprinte behuizing in een grotere outdoor elektrische box samen met de stroomcomponenten. Hiervoor waren de volgende onderdelen nodig:
- Een outdoor elektrische box met transparante kap, IP67, 8,7 × 6,7 × 4,3 inch.
- Een DIN-gemonteerde 12V DC voeding.
- Een DC-naar-USB-C PD-module om de 12V voeding om te zetten naar USB-C stroom.
- Een Type A RCBO (aardlekschakelaar), 10A met 30mA reststroombeveiliging.
- Drie meter 2,5mm² tweader-kabel.
- Een rechthoekige USB-C stroomkabel (pigtail) van 25cm.
Die kleine USB-C PD-module is een cool, ongebruikelijk apparaat. Hij neemt de 12V voeding en levert USB-C Power Delivery.
Herinneringen en meldingen
De Waste Collection Schedule-integratie verdient hier veel credits. Het scrapen van het schema van de gemeente bespaart me het handmatig bijhouden van verschillende data. BinRange voegt fysieke informatie over de bakken toe, en Home Assistant brengt de twee samen.
Het gewone dashboard toont de volgende ophaling, compacte status van de bakken en alles wat aandacht nodig heeft. De bereiken en radio-diagnostiek hebben hun eigen weergave. Ik hou van de technische details, maar het controleren van de bakken voor morgen zou niet vereisen dat ik een radio-trace interpreteer.
De herinneringen zijn gegroepeerd in één bericht voor de relevante bakken: om 18:00 en 21:00 uur de avond voor de ophaling, en een laatste herinnering om 06:00 uur als ze nog steeds stellig "Thuis" zijn. Om 18:00 uur de volgende dag is er een herinnering om bakken die nog steeds "Buiten" staan, weer binnen te halen. De automatisering onthoudt zijn pogingen, zodat een herstart niet dezelfde berichten blijft sturen.
Een onbeschikbare meting mag niet leiden tot de beschuldiging dat iemand een bak is vergeten. Evenzo weet de herinnering om de bakken binnen te halen alleen dat de ophaling gepland stond en de bak nog buiten is; het weet niet of de vuilniswagen hem daadwerkelijk heeft geleegd.
Ik wilde ook een bericht krijgen wanneer de bakken net waren geleegd. De verleiding was groot om naar beweging, tijdstip en het schema te kijken, maar dat was onvoldoende. Een 'wake counter' kon me vertellen dat er activiteit was, maar niet wie de bak had gehanteerd of waarom.
De tags hadden al accelerometers, dus ik voegde een specifiekere aanwijzing toe. Ten opzichte van een gekalibreerde rechtopstaande positie wordt een aanhoudende kanteling van meer dan 90 graden geregistreerd als een 'tip-event'. De tag bewaart dit event tijdens een ontvangstgap en rapporteert de tijd ervan zodra hij het anker weer bereikt. Home Assistant kan een recente kanteling van een bak die op schema staat en "Buiten" is, interpreteren als de aanname dat deze is geleegd.
De eerste automatisering controleerde elke vijf seconden op tips. Dat voelde excessief voor iets dat een paar keer per week gebeurt, dus ik heb het veranderd naar een MQTT-eventflow met een timer die alleen draait wanneer er een deadline aanstaat.
Eerste test in productie
Op 28 september had ik een tuinafval-ophaling die ik goed kon observeren. De bak begon om ongeveer 07:05 uur te bewegen en passeerde kort daarna de grens van tien meter. Daarna stopten de rapportages terwijl de bak weg was. Toen hij om ongeveer 10:25 uur verscheen, bevatte hij een opgeslagen 'tip' van ongeveer 09:27 uur, waarna hij terugkeerde naar de "Thuis"-zone.
De tag had de kanteling gedetecteerd en bewaard. Vertrek en terugkeer waren zichtbaar. Maar de 'tip' was ongeveer 58 minuten oud op het moment dat Home Assistant hem ontving, wat buiten de limiet van 30 minuten van de automatisering viel. Het bericht "net geleegd" werd niet verzonden. Andere bakken bleven rapporteren, en er was geen MQTT-fout bij het anker tijdens de gap. Ik heb nog steeds geen sluitende verklaring voor het gebrek aan ontvangst van die tag op de ophaalpositie.
Dat was een nuttige correctie op mijn optimisme. De radio kon overtuigende metingen leveren, de tag kon een kanteling detecteren en het dashboard kon er correct uitzien, terwijl de telefoon nog steeds de melding over het legen miste. Een echte ophaling controleren gaf me een veel betere lijst van zaken die aandacht nodig hadden.
Het veranderde ook hoe ik een bak wilde weergeven die stil was geworden. Oorspronkelijk werd een "Buiten"-meting "Onbekend" zodra deze verouderd was. Dat was voorzichtig, maar na het zien van de bak vertrekken en vervolgens het contact verliezen bij de stoep, was het vervangen van "Buiten" door "Onbekend" niet erg behulpzaam.
De huidige setup onthoudt een waargenomen vertrek als "Vermoedelijk Buiten", zelfs bij contactverlies of een herstart van Home Assistant. De status van de ontvangst wordt apart getoond. Een verse meting binnen de grens is nodig om de bak weer op "Thuis" te zetten. Als hij voor het laatst "Thuis" is gezien en daarna stilvalt, wordt hij "Onbekend", omdat ik hem nooit heb zien vertrekken. Herinneringen om bakken binnen te halen kunnen gebruikmaken van "Vermoedelijk Buiten"; herinneringen om bakken buiten te zetten hebben nog steeds vers bewijs nodig dat de bak "Thuis" is.
Wachten op meer ophaaldagen
BinRange is geïnstalleerd en in gebruik. Er zijn nog enkele standaard observaties te doen: de dekking op elke opslag- en ophaalpositie, meerdere volledige cycli met de juiste meldingen, het batterijgedrag over weken en hoe de montage en behuizingen buiten presteren. Ook wil ik dat updates betrouwbaar verbinden zonder dat ik ze handmatig moet herhalen.
Ik bouw dit niet voor algemene consumptie door anderen, maar als anderen geïnspireerd raken of iets soortgelijks willen proberen, zijn ze (of hun robotvrienden) welkom. In de repository staan de firmware, behuizingsbestanden, gemeten resultaten en HomeAssistant-voorbeelden.
Natuurlijk, nu ik heb gezien wat UWB kan, vraag ik me af of ik tags op de halsbanden van de katten zou kunnen zetten en vier ankers in huis zou kunnen plaatsen om in kaart te brengen waar ze zijn. Zou ik katten-tracking op centimeterniveau kunnen realiseren? Ik heb dat nog niet getest, en de bakken hebben al aangetoond hoe belangrijk de omgeving en radio-dekking zijn. Maar ik ben zeer verleid.
De meeste mensen zouden waarschijnlijk gewoon naar de kat zoeken.
Heb jij ook ultra-wideband radio's op je afvalbakken?
Home Assistant weet al welke bakken (voor de internationale lezers: prullenbakken) aan de beurt zijn voor ophaling. Het kan me vertellen dat het 'bakkenavond' is, de juiste kleuren op een dashboard tonen en me een herinnering sturen. Wat het niet kan vertellen, is of ik er daadwerkelijk iets aan heb gedaan.
Ik vermoed dat de meeste mensen gewoon een terugkerende herinnering op hun telefoon zouden zetten. Zoals mijn vrouw me ongetwijfeld zal vertellen, ben ik niet zoals de meeste mensen. Sommigen zouden simpelweg onthouden de bakken buiten te zetten, zoals een normaal mens dat doet. Ik ben me er terdege van bewust dat ik dit belachelijk heb over-engineered. Ik sta zo ver af van 'normaal' dat zes radio-uitgeruste bakken me leken op een prettige manier om mijn avonden door te brengen.
Enkele jaren geleden had ik het idee om goedkope Bluetooth-tags op mijn kliko's te plakken en een outdoor Bluetooth-proxy te gebruiken om te bepalen of ze in de buurt waren. Dat was frustrerend. De batterijen raakten snel leeg, de nabijheidsmetingen fluctueerden en de proxy was onbetrouwbaar in die specifieke installatie. Ik wilde weten of een bak was verplaatst; in plaats daarvan hield ik vooral iets nieuws over om mee te prutsen.
AirTags waren het eerste dat mijn interesse wekte voor ultra-wideband radio, of UWB. Door meer te lezen over hoe dit werkte, kwam het idee voor de bakken terug. De afgelopen weken is dit uitgegroeid tot BinRange: een vast radio-anker, zes kleine batterij-tags en een Home Assistant-setup die combineert waar de bakken zijn gezien met wanneer ze opgehaald moeten worden. Er is een geprinte behuizing, custom firmware en draadloze updates. Alles bij elkaar een vrij substantiële oplossing voor de vraag: "Heb je de bakken al buiten gezet?"
Tijdens het bouwen heb ik zwaar geleund op Codex. Halverwege werd Astra beschikbaar, en ik was erg benieuwd hoe dat zou presteren. Wat ik geweldig vind aan werken met AI, is hoe snel ik een idee kan omzetten, reageren op het resultaat, feedback geven en iets nieuws kunnen proberen. Daar valt in andere artikelen genoeg over te schrijven. Voor nu: terug naar de bakken.
Zes bakken, verschillende schema's
Wij hebben één bak voor restafval, één voor GFT, één voor tuinafval, twee voor recycling en één voor glas. Zes bakken. Op één adres. Ze staan niet eens allemaal op hetzelfde ophaalschema. Ik ben dankbaar dat de Waste Collection Schedule-integratie voor Home Assistant de schema's van de gemeente uitleest en bijhoudt wat er aan de beurt is, want dat zelf recht houden is een klus op zich.
Bij de goedkope Bluetooth-tags was de manier om afstand te schatten via RSSI (received signal strength indication). Je meet hoe sterk het ontvangen signaal is en gebruikt dat om te gissen hoe ver de tag weg is. Het probleem is dat signaalsterkte van veel meer afhangt dan alleen afstand. Muren, geparkeerde auto's, reflecties, antenne-oriëntatie en verschillen tussen de radio's en hun antennes beïnvloeden dit allemaal. Zelfs de batterijspanning kan de zendkracht beïnvloeden, afhankelijk van het ontwerp van het apparaat. Een zwakker signaal kan betekenen dat de bak verder weg is, of dat er iets in de weg staat. Het is een zeer onnauwkeurige manier om afstand te schatten, wat verklaart waarom mijn oorspronkelijke setup zo frustrerend was.
UWB was interessant omdat het de tijd meet die radiosignalen nodig hebben om tussen apparaten te reizen. Dat geeft een afstandsmeting zonder dat je hoeft te gissen op basis van signaalsterkte. Natuurlijk moet het signaal nog steeds door de omgeving komen; een andere radio zorgt er niet voor dat geparkeerde auto's verdwijnen.
Ik ben ook een tijdje afgedwaald naar een academische vraag over hoeveel ankers ik nodig zou hebben om meer dimensies aan dat bewustzijn toe te voegen. Wat als ik ook de richting wilde weten, naast de afstand vanaf een punt? Of de exacte locatie van de bak — hoeveel vaste referentiepunten zou ik nodig hebben om deze op een 2D-vlak te trianguleren? Voor deze klus totaal niet de moeite waard, maar zijpaden zijn nu eenmaal zijpaden.
Voor de bakken hoefde ik alleen te weten of elke bak ver genoeg van zijn gebruikelijke opslagplaats was bewogen om als "Buiten" te tellen. Eén anker was voldoende om dat te testen. Ik gebruikte een grens van tien meter: binnen die grens is het "Thuis", daarbuiten is het "Buiten", zodra er een nieuwe meting is. Dit is specifiek voor mijn installatie, maar het betekende dat ik kon beginnen met één gevoede printplaat in plaats van de tuin in een positioneringstestgebied te veranderen.
Twee printplaten en een wandeling buiten
Het eerste experiment gebruikte twee Makerfabs ESP32-WROVER/DW3000-boards, beide gevoed via USB. Voordat ik iets slims met Home Assistant deed, wilde ik zien of ze afstand konden meten. Een lokale webview stelde me in staat om ze uit elkaar te bewegen en te observeren wat er gebeurde zonder dat er een USB-kabel tussen de twee gespannen moest worden.
De oriëntatie van de antenne maakte een verrassend groot verschil. Bij ongeveer tien meter zorgde het veranderen van de borden van plat naar rechtopstaand ervoor dat het waargenomen succespercentage in die test steeg van 37% naar 100%. Een langzamere radio-instelling met een langere preamble werkte ook op plekken waar de initiële snelle instelling moeite had. Dit waren nuttige ontdekkingen om te doen voordat ik iets zou ontwerpen op basis van het eerste resultaat.
De eerste keer dat ik het kalibreerde met een rolmaat en zag dat de gerapporteerde afstand minder dan twee centimeter afweek van mijn meting, was ik echt perplex. Twee kleine printplaten wisselden radiosignalen uit en waren het tot op die graad eens met een rolmaat.
In een later geregistreerde test produceerde een gemeten afstand van 10,1 meter een gemiddelde reading van ongeveer 10,09 meter, met een standaarddeviatie van drie centimeter. Dat was bemoedigend voor een project dat alleen maar hoefde te herkennen wanneer een bak een opslagruimte verlaat. Het resultaat van minder dan twee centimeter was wat ik zag bij die eerste kalibratie, en niet per se een belofte van die nauwkeurigheid voor elke tag, oriëntatie of buitenpositie.
De wandeling buiten was onthullender. Metingen waren betrouwbaar tot ongeveer dertig meter, daarna werden ze intermitterend. De verste geregistreerde meting was 37,28 meter, met gaten. Een auto kon het pad volledig blokkeren. Een bord rechtop in het open veld houden en een klein tagje onder de rand van een bak monteren, zouden duidelijk verschillende tests zijn.
Het anker publiceert zijn metingen via MQTT, en Home Assistant ontdekt een apart apparaat voor elke tag. Ik overwoog een ESPHome-component, maar dat voegde niet veel toe aan de gewenste opstelling. Er is geen extra BinRange-server of cloudservice, en de radio's kunnen blijven meten terwijl Home Assistant of de MQTT-verbinding onbeschikbaar is.
Iets kleins genoeg voor op een bak
De ontwikkelborden waren nuttig om de verbinding te bewijzen. Ik wilde niet dat er aan elke bak een bord zou hangen met een batterij en een geïmproviseerde doos. De hardware aan de bakzijde moest een kleine, zelfstandige 'puck' zijn.
Ik onderzocht custom tags en commerciële versies, waarbij de belangrijkste vraag was of ik mijn eigen firmware kon draaien en ze kon gebruiken met mijn eigen anker. Een kleine UWB-tag is niet automatisch compatibel met een ander UWB-product. De tags die ik uiteindelijk kocht waren KKM K4Ws, met een nRF52833-processor, een DW3110-radio en een LIS3DH-accelerometer. Ze maken gebruik van uitneembare CR2477-knoopcelbatterijen (die overigens behoorlijk stevige jongens zijn; ik had die nog nooit gezien).
De kosten van het experiment waren destijds als volgt:
- Twee Makerfabs-borden: US$ 123,64 (inclusief verzending).
- Tien sample-tags (US$ 25 per stuk), een programmeer-jig en verzending: US$ 330.
Dit zijn de kosten van het experiment, niet een huidige boodschappenlijst of de kosten van een complete kit voor zes bakken. Ik vermoed dat ik het beste kan vermijden om een terugverdientijd te berekenen.
De leverancier gaf aan dat de tags mijn firmware konden draaien en bood een jig aan om bij de programmeeraansluitingen te komen. Ik was vooral geïnteresseerd in de hardware en het feit dat de programmeertoegang niet was geblokkeerd. De bestaande softwarefuncties van de leverancier deden me niet interesseren. Beweringen over de batterijduur waren betekenisloos, aangezien ik degene zou zijn die beslist wanneer de CPU sliep en wat hem wakker maakte.
Ik ben goed bekend met nRF52-apparaten; ik gebruik ze al jaren. Het zijn briljante kleine energiezuinige microprocessoren die het grootste deel van hun leven in slaapstand kunnen doorbrengen. Als je slim bent met planning en interrupts, kun je deze dingen in de juiste toepassing jarenlang op een kleine batterij laten draaien.
Ik gebruikte een reserve Nesso-apparaat als programmeersonde voor de pogo-pin jig. Ik begon met een ontwikkel-tag en configureerde daarna de commerciële tags één voor één: programmeren, identiteit vaststellen, koppelen, labelen, toewijzen aan een bak en weer in elkaar zetten. Er zijn verschillende identiteiten betrokken, waaronder het geprinte label, de chip-identiteit en de adressen die door de radio's worden gebruikt.
Bijbehorende opmerking: de behuizingen van de tags hadden schijnbaar unieke serienummers met QR-codes. Ik kon geen associatie vinden met de MAC-adressen van de apparaten, dus waren ze voor mij in feite nutteloos.
De fabrikant had de interrupt-output van de accelerometer verbonden met een GPIO-pin op de nRF, wat ongelooflijk nuttig is. Dit betekent dat ik de nRF voor zeer lange perioden kan laten slapen zonder radioverkeer, en hem kan wekken wanneer er een fysieke gebeurtenis plaatsvindt. Zodra de situatie stabiliseert, keert hij terug naar incidentele check-ins, waarbij de UWB-radio tussen de pogingen door slaapt. De standaardinstelling is tien minuten wanneer de bak stilstaat; ik heb dit voor de huidige vloot via Home Assistant aangepast naar dertig minuten, terwijl de rapportages bij beweging elke vijf seconden blijven doorgaan.
Dit voorkomt dat de batterij wordt verbruikt door herhaaldelijk te rapporteren dat een bak nog steeds op dezelfde plek staat. Hoeveel levensduur dit precies oplevert, moet ik nog meten.
Zes bakken updaten zonder ze uit elkaar te halen
Zodra een tag is gemonteerd, is het niet erg aantrekkelijk om hem steeds open te maken en op de programmeer-jig te leggen voor softwarewijzigingen. Het anker kan nu ondertekende firmware-updates via Bluetooth leveren aan gekoppelde tags. De vorige applicatie wordt bewaard, zodat een slechte update kan worden teruggedraaid, en het systeem rapporteert pas succes wanneer de tag precies het verwachte image draait en zijn eigen gezondheid heeft bevestigd.
Het testen en itereren van dit soort zaken is een andere fantastische toepassing van AI. Codex hielp me bij het genereren en simuleren van een reeks testcondities en foutmodi, om het uitrollen van firmware over-the-air zo veilig mogelijk te maken. Ik testte corrupte images, onderbroken overdrachten, specifieke stroomuitvalmomenten en watchdog-herstel. Ook testte ik wat er gebeurde als het anker er niet was: de tag moet kunnen bevestigen dat hij gezond is zonder radio-antwoord, in plaats van werkende firmware te verlaten omdat hij het anker niet kan bereiken.
Bij de overstap van één naar meerdere tags ontstond er een ander probleem. Een record in de Bluetooth-bibliotheek was gedimensioneerd voor het aantal gelijktijdige verbindingen in plaats van het aantal gekoppelde apparaten. Het toevoegen van een extra tag kon falen, zelfs als de sleutels waren opgeslagen. Het oplossen hiervan zorgde ervoor dat een nieuwe fysieke tag kon koppelen zonder de bestaande te wissen. Zes bakken boden de software een betere test dan één meewerkende demo-tag.
Inmiddels heb ik het geïnstalleerde anker en alle zes de tags draadloos geüpdatet zonder ze opnieuw te koppelen.
De behuizing kostte meerdere pogingen
Het anker had een behuizing nodig, wat een project op zich werd. Het begon als een OpenSCAD-ontwerp met schroeven. De eerste pasvorm was veelbelovend, maar kleine moeren en bouten, PLA-toleranties en een printplaat die nog kon rammelen, maakten de assemblage vervelender dan ik wilde.
Ik wilde een behuizing die volledig uit geprint PLA bestond, zonder schroeven: taps toelopende positioneringspinnen voor de printplaat, geprinte veren om hem op zijn plaats te houden en een deksel dat bleef zitten. De pinnen en veren werkten, maar het deksel kon alle kanten op bewegen.
Een interne lip verbeterde de pasvorm. Diepere vergrendelingen verbeterden de retentie, maar ik kon het deksel nog steeds te gemakkelijk lostrekken. Toen ik de vergrendelingen zo diep maakte als de wand, braken beide wortels tijdens het plaatsen. Die versie was uitstekend in het worden van twee stukken gebroken plastic.
De betere aanpassing was om de wanden van de basis en het deksel te laten overlappen en meerdere ondiepe vergrendelingen te gebruiken. Na een paar tweaks aan de positioneringspinnen en ventilatieopeningen had ik een behuizing die de printplaat goed vasthield en dicht bleef.
De snelle loop met Codex was bijzonder prettig voor de behuizing: ik kon het ontwerp verfijnen, inspecteren en printen. Ik moest het resultaat nog steeds fysiek oppakken om te ontdekken of het deksel eraf viel. Een geometriecontrole kan vaststellen dat twee vormen in elkaar moeten passen; het vertelt me niet of een vergrendeling overleeft wanneer deze op zijn plaats wordt geduwd.
Het anker is nu aan de muur gemonteerd, met de geprinte behuizing in een grotere outdoor elektrische box samen met de stroomcomponenten. Hiervoor waren de volgende onderdelen nodig:
- Een outdoor elektrische box met transparante kap, IP67, 8,7 × 6,7 × 4,3 inch.
- Een DIN-gemonteerde 12V DC voeding.
- Een DC-naar-USB-C PD-module om de 12V voeding om te zetten naar USB-C stroom.
- Een Type A RCBO (aardlekschakelaar), 10A met 30mA reststroombeveiliging.
- Drie meter 2,5mm² tweader-kabel.
- Een rechthoekige USB-C stroomkabel (pigtail) van 25cm.
Die kleine USB-C PD-module is een cool, ongebruikelijk apparaat. Hij neemt de 12V voeding en levert USB-C Power Delivery.
Herinneringen en meldingen
De Waste Collection Schedule-integratie verdient hier veel credits. Het scrapen van het schema van de gemeente bespaart me het handmatig bijhouden van verschillende data. BinRange voegt fysieke informatie over de bakken toe, en Home Assistant brengt de twee samen.
Het gewone dashboard toont de volgende ophaling, compacte status van de bakken en alles wat aandacht nodig heeft. De bereiken en radio-diagnostiek hebben hun eigen weergave. Ik hou van de technische details, maar het controleren van de bakken voor morgen zou niet vereisen dat ik een radio-trace interpreteer.
De herinneringen zijn gegroepeerd in één bericht voor de relevante bakken: om 18:00 en 21:00 uur de avond voor de ophaling, en een laatste herinnering om 06:00 uur als ze nog steeds stellig "Thuis" zijn. Om 18:00 uur de volgende dag is er een herinnering om bakken die nog steeds "Buiten" staan, weer binnen te halen. De automatisering onthoudt zijn pogingen, zodat een herstart niet dezelfde berichten blijft sturen.
Een onbeschikbare meting mag niet leiden tot de beschuldiging dat iemand een bak is vergeten. Evenzo weet de herinnering om de bakken binnen te halen alleen dat de ophaling gepland stond en de bak nog buiten is; het weet niet of de vuilniswagen hem daadwerkelijk heeft geleegd.
Ik wilde ook een bericht krijgen wanneer de bakken net waren geleegd. De verleiding was groot om naar beweging, tijdstip en het schema te kijken, maar dat was onvoldoende. Een 'wake counter' kon me vertellen dat er activiteit was, maar niet wie de bak had gehanteerd of waarom.
De tags hadden al accelerometers, dus ik voegde een specifiekere aanwijzing toe. Ten opzichte van een gekalibreerde rechtopstaande positie wordt een aanhoudende kanteling van meer dan 90 graden geregistreerd als een 'tip-event'. De tag bewaart dit event tijdens een ontvangstgap en rapporteert de tijd ervan zodra hij het anker weer bereikt. Home Assistant kan een recente kanteling van een bak die op schema staat en "Buiten" is, interpreteren als de aanname dat deze is geleegd.
De eerste automatisering controleerde elke vijf seconden op tips. Dat voelde excessief voor iets dat een paar keer per week gebeurt, dus ik heb het veranderd naar een MQTT-eventflow met een timer die alleen draait wanneer er een deadline aanstaat.
Eerste test in productie
Op 28 september had ik een tuinafval-ophaling die ik goed kon observeren. De bak begon om ongeveer 07:05 uur te bewegen en passeerde kort daarna de grens van tien meter. Daarna stopten de rapportages terwijl de bak weg was. Toen hij om ongeveer 10:25 uur verscheen, bevatte hij een opgeslagen 'tip' van ongeveer 09:27 uur, waarna hij terugkeerde naar de "Thuis"-zone.
De tag had de kanteling gedetecteerd en bewaard. Vertrek en terugkeer waren zichtbaar. Maar de 'tip' was ongeveer 58 minuten oud op het moment dat Home Assistant hem ontving, wat buiten de limiet van 30 minuten van de automatisering viel. Het bericht "net geleegd" werd niet verzonden. Andere bakken bleven rapporteren, en er was geen MQTT-fout bij het anker tijdens de gap. Ik heb nog steeds geen sluitende verklaring voor het gebrek aan ontvangst van die tag op de ophaalpositie.
Dat was een nuttige correctie op mijn optimisme. De radio kon overtuigende metingen leveren, de tag kon een kanteling detecteren en het dashboard kon er correct uitzien, terwijl de telefoon nog steeds de melding over het legen miste. Een echte ophaling controleren gaf me een veel betere lijst van zaken die aandacht nodig hadden.
Het veranderde ook hoe ik een bak wilde weergeven die stil was geworden. Oorspronkelijk werd een "Buiten"-meting "Onbekend" zodra deze verouderd was. Dat was voorzichtig, maar na het zien van de bak vertrekken en vervolgens het contact verliezen bij de stoep, was het vervangen van "Buiten" door "Onbekend" niet erg behulpzaam.
De huidige setup onthoudt een waargenomen vertrek als "Vermoedelijk Buiten", zelfs bij contactverlies of een herstart van Home Assistant. De status van de ontvangst wordt apart getoond. Een verse meting binnen de grens is nodig om de bak weer op "Thuis" te zetten. Als hij voor het laatst "Thuis" is gezien en daarna stilvalt, wordt hij "Onbekend", omdat ik hem nooit heb zien vertrekken. Herinneringen om bakken binnen te halen kunnen gebruikmaken van "Vermoedelijk Buiten"; herinneringen om bakken buiten te zetten hebben nog steeds vers bewijs nodig dat de bak "Thuis" is.
Wachten op meer ophaaldagen
BinRange is geïnstalleerd en in gebruik. Er zijn nog enkele standaard observaties te doen: de dekking op elke opslag- en ophaalpositie, meerdere volledige cycli met de juiste meldingen, het batterijgedrag over weken en hoe de montage en behuizingen buiten presteren. Ook wil ik dat updates betrouwbaar verbinden zonder dat ik ze handmatig moet herhalen.
Ik bouw dit niet voor algemene consumptie door anderen, maar als anderen geïnspireerd raken of iets soortgelijks willen proberen, zijn ze (of hun robotvrienden) welkom. In de repository staan de firmware, behuizingsbestanden, gemeten resultaten en HomeAssistant-voorbeelden.
Natuurlijk, nu ik heb gezien wat UWB kan, vraag ik me af of ik tags op de halsbanden van de katten zou kunnen zetten en vier ankers in huis zou kunnen plaatsen om in kaart te brengen waar ze zijn. Zou ik katten-tracking op centimeterniveau kunnen realiseren? Ik heb dat nog niet getest, en de bakken hebben al aangetoond hoe belangrijk de omgeving en radio-dekking zijn. Maar ik ben zeer verleid.
De meeste mensen zouden waarschijnlijk gewoon naar de kat zoeken.