I april 2026 er combotto.io live som den fokuserede retning for mit arbejde med IoT, embedded software og system programmering i Rust.
Det betyder noget for mig, fordi Combotto ikke er noget der bare er opstået fra den ene dag til den anden. Det er en fortsættelse af en retning, jeg har bevæget mig i gennem flere år, og jeg vil gerne gøre den udvikling tydelig - også her på tbcoding.dk, hvor jeg typisk forklarer den tekniske side mere direkte.
Denne retning har været længe undervejs
Tilbage i april 2022 udgav jeg Combotto - Aggregator software, hvor jeg beskrev Combotto som et nyt projekt knyttet til mit arbejde med aggregatorsoftware og virtual powerplants. Det indlæg var en direkte forlængelse af mit speciale om digital twin-data-modellering med IoT-streamingtelemetri til peak shaving i virtual powerplants, som jeg afsluttede tidligere samme år.
Specialet handlede om, hvordan opkoblede enheder, telemetri og softwaremodeller kan bruges til at repræsentere og koordinere energiaktiver mere intelligent. I praksis var det et tidligt, konkret arbejde med distribuerede fysiske systemer, streamingdata og software omkring edge og cloud.
Det er vigtigt som baggrund, fordi den oprindelige Combotto-retning ikke kom ud af ingenting. Den voksede ud af reel akademisk og teknisk erfaring med opkoblede systemer, telemetri og software til distribueret infrastruktur.
På det tidspunkt var retningen stadig mere snævert centreret omkring energi, digitale tvillinger, aggregatorsoftware og virtual powerplants. Siden da er den tekniske interesse blevet tydeligere og mere moden:
- edge-to-cloud systemdesign
- driftssikkerhed i reelle distribuerede systemer
- sikker transport og operationel sikring
- evidensdrevne audit- og forbedringsforløb
- praktisk system programmering til IoT-infrastruktur
Det er den retning, Combotto repræsenterer i dag.
Den professionelle side af det er heller ikke ny for mig. Jeg arbejdede fuldtid som freelancekonsulent fra august 2015 til august 2018, hvor jeg begyndte med blandt andet webdesign og bredere softwareopgaver for kunder.
Det der har ændret sig over tid, er min specialisering. Gennem universitetet, gennem min bachelor og kandidat og gennem arbejde med telekommunikation og sikker kommunikation bevægede jeg mig dybere ind i distribuerede systemer, it-sikkerhed og IoT-relateret software.
IoT er heller ikke noget, jeg først lige har opdaget. Det blev allerede et tydeligere spor under min datamatikeruddannelse i Aalborg fra 2013 til 2016, hvor jeg arbejdede med robotteknologi.
Den retning fortsatte, da jeg flyttede til Odense i 2018 for at færdiggøre min professionsbachelor i softwareudvikling. Her kom jeg længere ned i systemsiden gennem arbejde med Linux-miljøer, ROS og robotorienteret software, white-box-test i C++, microservice-lignende backend-design og senere Kafka-baserede datasystemer. Man kan se noget af den udvikling i Migrering af en IoT audit engine fra Scala ZIO til Java 21 Spring Boot og i mit bachelorprojekt Skalerbar IoT data streaming platform til transport-industrien med Apache Kafka & Confluent Platform.
Derfor føles Combotto naturligt for mig. Det er ikke en tilfældig genopfindelse eller et pludseligt hop til en ny professionel retning. Det er en fortsættelse af tidligere kundeopgaver og tidligere teknisk specialisering, nu fokuseret mere bevidst omkring IoT-nichen og edge-to-cloud systemer.
Hvad jeg har bygget mere målrettet siden august 2025
Siden august 2025 har jeg bevidst valgt at gå dybere ned i IoT og embedded software i stedet for primært at behandle det på et overordnet niveau.
En del af det skift er også påvirket af AI. Når software bliver lettere at bygge med stærkere AI-værktøjer, synes jeg det bliver endnu mere værdifuldt at forstå hardwaresiden bedre og arbejde mere bevidst med samspillet mellem hardware og software i integrerede systemer.
Det er en af grundene til, at jeg også har brugt mere tid på at styrke min forståelse af laget under applikationssoftwaren. Onur Mutlus online kursusmateriale om digital design og computerarkitektur har været særligt nyttigt her, fordi det har tvunget mig til at tænke klarere om hele stakken fra lavere hardwarefundamenter og op gennem softwarelaget.
Det har betydet mere tid på de dele, som virkelig betyder noget, når opkoblede systemer skal fungere i virkeligheden:
- embedded Rust
- dybere hardwareforståelse
- sensorintegrationer
- sikre forbindelser mellem enheder og cloud
- OTA-opdateringsflow
- gatewayens runtime-adfærd
- sporbarhed
- sikker softwareudvikling og håndtering af sårbarheder
Jeg havde ikke lyst til, at Combotto skulle blive et site bygget på generisk positionering. Jeg ville hellere bygge det på reelt arbejde, jeg selv har udført og kan forklare i detaljer.
Hvad jeg har bygget omkring Combotto indtil nu
De vigtigste ting jeg har bygget, er konkrete tekniske materialer, som understøtter den måde, jeg gerne vil arbejde på langsigtet.
1. Fra embedded læring til mere konkret arbejde med enheder
Et vigtigt skift for mig har været at bevæge mig fra arkitekturinteresse til mere praktisk arbejde med embedded software og selve enhederne.
Jeg har arbejdet med STM32-baseret hardware, lært Rust dybere i en embedded kontekst, integreret sensorer og bygget en mere komplet firmware-livscyklus omkring mine egne enheder. Det har blandt andet inkluderet secure boot-forudsætninger, signeret firmware, over-the-air-opdateringer og telemetri fra fysiske enheder op i skyen.
Den del af rejsen beskriver jeg mere detaljeret i Operational lessons from running an edge IoT gateway 24/7.
Det arbejde har været vigtigt, fordi det tvang mig til at lære ikke kun softwarearkitektur, men også de fysiske og operationelle realiteter bag IoT-systemer: sensorkvalitet, genopkoblingsadfærd, certifikater, beskedernes holdbarhed og hvad der faktisk sker, når en enhed eller gateway skal køre kontinuerligt i stedet for kun i en lokal demo.
2. Min egen Rust-baserede gateway og den dybere systemarkitektur bag den
Derfra byggede jeg min egen gateway som grænselag mellem enheder og cloud.
Det arbejde beskriver jeg i Design af en sikker Rust-IoT-gateway: Arkitektur fra edge til cloud, og det blev et vigtigt vendepunkt for, hvordan jeg tænker min konsulentretning.
Gateway-arbejdet trak mig dybere ind i:
- system programmering i Rust
- MQTT og meddelelsesudveksling fra edge til cloud
- buffering og WAL-baseret gendannelse
- observability med traces og metrics
- sikker transport med TLS og mTLS
- runtime-adfærd på mere realistisk edge-hardware
Det er præcis den slags systemarbejde, jeg gerne vil lave mere af: praktisk arbejde tæt på runtime-laget og forankret i hvordan systemer opfører sig under reelle fejlscenarier.
3. En audit engine til at inspicere mit eget arbejde og gøre det mere evidensbaseret
Et af de vigtigste næste skridt var at bygge en auditfunktion, som kunne inspicere den type systemer, jeg selv arbejdede på.
Det skrev jeg om i Design af en evidensbaseret audit engine til IoT-sikkerhed & driftssikkerhed.
Den korte version er, at jeg ønskede mere systematiske værktøjer og en mere tydelig metode omkring sikker softwareudvikling i stedet for ad hoc analyse og screenshots. Jeg ville have et audit-flow, der kunne:
- indsamle teknisk evidens fra reelle systemer
- vurdere fund mere konsistent
- producere en prioriteret backlog
- understøtte genkørsler, differencer og opfølgende verifikation
Det betyder noget for mig, fordi det flytter arbejdet fra “her er nogle tanker” til en mere disciplineret vej fra evidens til fund og videre til målrettet forbedring.
4. Sikker udvikling, sårbarhedshåndtering og compliance-orienteret parathed
En anden grund til at Combotto er blevet mere fokuseret, er at jeg i stigende grad forbinder det tekniske arbejde med det sikkerheds- og compliance-pres, som opkoblede produkter møder i dag.
Det gælder blandt andet arbejde omkring:
- SBOM og releasedokumentation
- arbejdsgange for håndtering af sårbarheder
- sikre rapporteringsveje
- en mere eksplicit disciplin i softwareudviklingslivscyklussen
- praktisk parathed til NIS2, CRA og kundedrevet sikkerhedspres
Jeg har skrevet mere om den retning i IoT Cyber Resilience Act readiness: security reporting, release evidence, and verified fixes.
Det er ikke fordi jeg vil gøre Combotto til en generisk complianceydelse. Det er fordi jeg tror, at mere IoT-arbejde kommer til at ligge i krydsfeltet mellem arkitektur, runtime-adfærd, dokumentation for softwareforsyningskæden og sikker leverancedisciplin.
5. IoT-feltprototyper: fra én enhed til tre og videre mod sub-GHz telemetri
Jeg ville også have mere erfaring med, hvordan IoT-systemer opfører sig i mere realistiske feltopsætninger.
Jeg tror meget på at have mit eget hardware- og IoT-miljø til rådighed i en slags laboratorieopsætning, hvor jeg kan øve mig, lave fejl og opbygge mere praktisk erfaring ved at se, hvordan systemerne rent faktisk opfører sig.
Det førte til en opsætning med tre enheder, en Raspberry Pi 5-gateway og STM32-enheder, inklusive et CO2-sensorspor og et mere realistisk telemetriforløb med flere enheder. Det tydeligste offentlige eksempel er Rust IoT Gateway Field Demo: Raspberry Pi 5, 3 STM32 Devices, MQTT/TLS Recovery.
Den slags feltprototypearbejde er vigtigt, fordi det er her spørgsmål om driftssikkerhed begynder at blive virkelige: identitet, backlog-vækst, gendannelsesadfærd og om evidenssporet stadig giver mening efter fejl og genopretning.
Mit nuværende næste skridt er at arbejde mere med telemetri over længere afstande via sub-GHz-radio. Den retning har jeg beskrevet i Planning a Longer-Range 868 MHz STM32 Telemetry Demo with SPSGRF-868 and Raspberry Pi 5.
Det er den slags udvikling, jeg gerne vil have, at Combotto afspejler: ikke kun cloudnær software, men reelle spørgsmål om enheder, transport, gateways og evidens på tværs af hele edge-to-cloud-kæden.
6. Et fokuseret site og en mere tydelig leverancemodel
Det synlige præsentationslag for alt dette er selve combotto.io.
Sitet præsenterer nu Combotto som et mere fokuseret hjem for denne IoT-retning med en tydelig leverancevej:
- Audit
- Sprint
- Retainer
Det er vigtigt, fordi jeg ikke vil have, at arbejdet stopper ved generel rådgivning eller bliver til åben timefakturering uden retning. Jeg vil hellere have en mere struktureret konsulent- og freelance-model, hvor hver fase bygger videre på den forrige: evidensbaseret arbejde der starter med et audit, fortsætter i et fokuseret hardening- eller implementationssprint og kan udvikle sig til et længere samarbejde, når teams har brug for opfølgning på sikkerhed, driftssikkerhed og observability på tværs af edge og cloud.
Hvis du vil se den direkte kommercielle indgang til det arbejde, er det nu rollen for combotto.io og især IoT Audit-siden.
7. Portfolio, teknisk skrivning og genbrugelig autoritet
En anden vigtig del af Combotto er, at jeg bevidst har omsat reelt implementeringsarbejde til genbrugeligt portfoliomateriale:
- tekniske blogindlæg
- arkitekturdiagrammer
- cases
- audit- og rapporteksempler
- referencemateriale fra feltforsøg og gateway-arbejde
Det er helt med vilje. Jeg vil gerne have, at Combotto er bakket op af synlig teknisk dybde, og jeg vil gerne have, at tbcoding.dk fortsat er et sted, hvor den dybde kan forklares enklere og mere teknisk detaljeret.
En anden stor ændring: agentisk udvikling fra november 2025 til midten af februar 2026
En anden vigtig del af denne overgang er, hvordan jeg bygger software i dag.
I slutningen af november 2025 opdagede jeg bedre AI-modeller, der gav mig væsentligt mere løft end det, jeg tidligere havde brugt. I løbet af vinteren trænede jeg mig mere bevidst i agentiske arbejdsformer, og omkring midten af februar 2026 var jeg gået langt mere seriøst over til agentisk udvikling med Codex.
Det ændrede min arbejdsform markant.
I stedet for at bruge AI som autoudfyldning eller en chat i siden bruger jeg det nu som en del af selve udviklingssystemet:
- Codex sammen med ChatGPT Pro som reel implementeringsarbejdsform
- orkestrering af flere agenter til afgrænset parallelt arbejde
- repo-specifikke
SKILL.md-arbejdsgange for mere reproducerbar eksekvering - Beads som opgave- og statuslag med Dolt-baseret persistens
PLAN.md,AGENTS.mdog specs som mere holdbar hukommelse mellem iterationer
Det har gjort en reel forskel for, hvor hurtigt jeg kan bevæge mig fra idé til implementering til verifikation.
Jeg er ikke interesseret i at bruge agenter til bare at producere mere tilfældig output hurtigere. Jeg er interesseret i at bruge dem til at øge udviklingshastigheden samtidig med at processen bliver mere struktureret:
- klarere planlægning
- tydeligere opgavestyring
- bedre overlevering mellem iterationer
- strammere review loops
- mere reproducerbar verifikation
- stærkere sikkerhedsdisciplin i selve udviklingspipelinen
I praksis er det blevet en vigtig del af, hvorfor Combotto-arbejdet har accelereret. Meget af den aktuelle implementering foregår nu i en agentisk udviklingsstil, og jeg er aktivt i gang med at udforske, hvordan den stil kan blive både hurtigere og sikrere:
- hvordan planlægning bør fungere
- hvordan review bør fungere
- hvordan arbejde med flere agenter bør afgrænses
- hvordan køtilstand og hukommelse skal forblive troværdig
- hvordan pipelinen forbliver sikker, når agentisk udvikling overtager mere af det daglige arbejde
Det skift kan se separat ud fra IoT på overfladen, men for mig hænger det sammen. Det er en del af den samme langsigtede retning: at bygge svære tekniske systemer med mere løft, mere struktur og en mere bevidst udviklingsproces.
Hvordan jeg ser relationen mellem siderne nu
Jeg vil gerne gøre opdelingen tydeligere fremover.
På tbcoding.dk forklarer jeg de tekniske emner mere direkte: arkitektur, implementering, driftssikkerhed, sikker udvikling og de erfaringer, der opstår, når systemer faktisk skal fungere i praksis.
combotto.io er nu det fokuserede site for min retning inden for IoT-systemer. Det er stedet for edge-to-cloud IoT-arbejde, audits af sikkerhed, driftssikkerhed og observability, hardening-forløb samt portfolio- og referencemateriale knyttet til opkoblede systemer.
For mig hænger de to lag sammen sådan her:
- tbcoding.dk forklarer den tekniske dybde og implementeringserfaringerne
- combotto.io samler den fokuserede IoT-retning og den konkrete leverancemodel
Min langsigtede retning
Når jeg kigger fremad, ser jeg Combotto som hovedkøretøjet for min IoT-fokuserede systems-retning.
Det inkluderer arbejde med:
- gennemgange af IoT-sikkerhed og driftssikkerhed
- gateway- og edge-arkitektur
- operationel sikring
- evidensbaserede tekniske audits
- system programmering hvor softwarekvalitet og runtime-adfærd betyder noget
Så selv om tbcoding.dk fortsat er vigtigt for mig som stedet, hvor jeg kan forklare og dokumentere det tekniske arbejde, er Combotto dér, hvor jeg samler den mere specialiserede retning, jeg vil bygge videre på de kommende år.
Hvis du læser med her fra tbcoding.dk
Hvis du følger med her for de tekniske forklaringer, arkitekturartiklerne og de mere konkrete implementeringserfaringer, så er det stadig præcis rollen for tbcoding.dk.
Men hvis problemet specifikt handler om IoT, opkoblede enheder, gateways, telemetripipelines eller edge-to-cloud-sikkerhed og driftssikkerhed, så er combotto.io nu det mest relevante næste skridt.
Det er dér, jeg samler den mere fokuserede del af arbejdet, og jeg ville gerne gøre den udvikling synlig også på dansk.
