Eines vorweg: Ich war faul und habe alles mit KI gemacht. Auch diesen Blogbeitrag inklusive der reißerischen Überschrift. Für mich zählt das Ergebnis von einem Sonntag Nachmittag, mit dem ich zukünftig meine Wochenenden besser planen kann.
Screenshot
Kennst du das Gefühl, wenn du gerne wanderst oder Rad fährst, aber auf Karten schlicht den Überblick verlierst, wo du eigentlich schon überall unterwegs warst? Eine einfache Route anzuzeigen ist kein Problem – aber eine persönliche Abdeckungs-Heatmap („Wo war ich schon, wo fehlen noch weiße Flecken auf meiner Karte?“) ist oft gar nicht so leicht umzusetzen.
Genau dafür habe ich mein neues Projekt GeoTour ins Leben gerufen: Eine schlanke, lokale Webanwendung, die Komoot-Touren und GPX-Importe auf einer interaktiven Karte zusammenführt und visuell aufbereitet.
Das Besondere an diesem Projekt ist allerdings nicht nur das Ergebnis, sondern wie es entstanden ist: Ich habe GeoTour mithilfe eines Multi-Agenten-Systems auf Basis von OpenCode entwickelt.
In diesem Artikel nehme ich dich mit durch die Architektur, die Arbeitsweise des KI-Teams und die wichtigsten Erkenntnisse aus dem Projekt!
Das Ziel: Schlank, lokal & „Der Überblick muss sofort da sein“
Von Anfang an hatte das Projekt eine klare Leitlinie: Maximaler Nutzen bei minimaler Komplexität.
Direkter Fokus: „Der Überblick muss sofort da sein.“ – Fokus auf die Desktop-Nutzung, die mobile Ansicht liefert das Nötigste.
Kein Frontend-Build-Overhead: Keine Lust auf stundenlange npm build-Orgien oder komplizierte Toolchains. Als Frontend-Stack reichen Jinja2-Templates, Vanilla JS und Leaflet. Keine externen CDNs, keine unnötigen Node-Abhängigkeiten im Produktivcode.
Open Source & Kostenkontrolle: Das Multi-Agenten-System läuft in OpenCode ausschließlich mit freien KI-Modellen.
Lokal & Zukunftsfähig: Gestartet als lokales Tool, mit dem Ziel, später auf einen eigenen 1blu VPS umzuziehen.
Wie das Multi-Agenten-Team gearbeitet hat
Statt der KI einfach nur unstrukturierte Prompts zuzuwerfen, habe ich ein rollenbasiertes System in OpenCode aufgesetzt. Jede Rolle hatte klare Aufgaben und Befugnisse:
Der Architekt (@architect): Planer und Entscheider. Er hielt das „Produktgedächtnis“ sauber, traf Systementscheidungen und führte Architectural Decision Records (ADRs).
Die Coder (@coder): Zuständig für das Backend (FastAPI, Python) und Frontend (Leaflet, JS). Max. 2 Coder arbeiteten gleichzeitig, um Merge-Konflikte in Dateien zu vermeiden.
Der Protokollant (@scribe): Dokumentations-Guru für ADRs und Spezifikationen.
Der Tester (@reviewer-tester): Prüfte Code, deckte Kantenfälle auf und stellte sicher, dass die Testsuite grün blieb.
Disziplin ist alles: Klare Regeln für das KI-Team
Damit ein solches Multi-Agenten-System nicht im Chaos versinkt, gab es harte Projekt-Konventionen:
Verbindliche ADRs: Keine relevante technische Entscheidung blieb ungeklärt im Raum stehen. Jede Entscheidung wurde formell festgehalten.
Kompakte Feedback-Loops: Maximal zwei Nacharbeitsrunden pro Aufgabe.
Feste Arbeitsgrenzen: Der Coder durfte nur an App-Dateien arbeiten, der Architekt/Scribe nur an der Dokumentation.
Die Meilensteine & Iterationen
Die Entwicklung verlief in knackigen, fokussierten Iterationen:
M1 – Karte & GPX-Import: Basispfad aufbauen. GPX-Dateien hochladen, parsen und als farbige Linien auf der Leaflet-Karte darstellen.
M2 – Inkrementeller Komoot-Abgleich: Ein Anbindungs-Modul holt Touren direkt von Komoot. Dabei gab es spannende Erkenntnisse: Der Login-Schritt erwies sich bei genauer Analyse als GET mit Basic-Auth (statt des ursprünglich vermuteten POSTs), und bei REST-Anfragen verlangte die Schnittstelle präzise Accept-Header (application/hal+json).
M3 – Die Abdeckungs-Heatmap: Ein serverseitiges Raster unterteilt die Karte in Kacheln (Standard: 1 km²). Die Anwendung zählt, wie viele Touren eine Kachel kreuzen, und zieht eine sanfte, petrolfarbene Heatmap-Ebene drüber.
Technische Highlights & Features
Über die Zeit ist aus dem initialen Prototyp ein richtig runder Kartendienst geworden:
Smarte Heatmap: Eine transparente Petrol-Färbung (#0a5a69), die bewusst nicht mit der feurig-roten Auswahllinie kollidiert. Bereits ab 10 Touren pro Kachel erreicht die Farbe ihre volle Intensität.
Koppelung von Liste & Karte: Die Tourenliste in der Seitenleiste passt sich dynamisch dem sichtbaren Kartenausschnitt an. Ein Klick auf eine Tour zentriert die Karte mit passendem Zoom.
Volle Kontrolle über die Optik: Schieberegler für die Deckkraft von Touren und Heatmap sowie anpassbare Kachelgrößen direkt in der Oberfläche.
Robuste Löschfunktion: Touren werden „weich“ gelöscht (deleted_at). So bleibt ein Fingerprint erhalten, damit gelöschte Touren bei einem erneuten Komoot-Import nicht plötzlich wieder auftauchen.
Eigener UI-Verhaltensprüfstand: Ein extrem schneller JS-Harness testet die Leaflet-Oberfläche headless über Node-vm – ganz ohne schwerfälliges Browser-Automation-Tooling.
Meine wichtigsten Learnings
Klare Agenten-Rollen verhindern Verwirrung: KI-Modelle arbeiten um ein Vielfaches effizienter, wenn sie in engen Rollengrenzen agieren. Wenn der Architekt plant und der Coder nur baut, bleibt die Codebase sauber.
ADRs sparen KI-Kontext: Indem Architektentscheidungen in knappen Markdown-ADRs festgehalten werden, „vergisst“ das KI-System nie, warum eine Entscheidung so getroffen wurde.
Echte API-Recherche schlägt Annahmen: Schnittstellen wie Komoot verhalten sich manchmal anders als gedacht (z. B. HAL+JSON Header oder Basic-Auth Verhalten). Isolierte Tests vor der Anbindung sparen Frust.
Fehlende Node-Build-Tools sind eine Wohltat: Pure HTML/Jinja2-Templates mit nativem JavaScript und Leaflet machen das Projekt extrem leichtgewichtig, blitzschnell ausführbar und wartungsarm.
Stand & Ausblick
Der aktuelle Zwischenstand kann sich sehen lassen: 487 Backend-Tests grün, 31 Frontend-Harness-Szenarien bestanden und eine voll funktionsfähige Karte inklusive Heatmap und Komoot-Abgleich.
Als nächstes steht die visuelle Filter-Oberfläche (Filtern nach Status, Sportart und Zeitraum) auf dem Plan, bevor das Ganze für den Dauerbetrieb auf meinen 1blu VPS wandert.
Hast du Fragen zum Aufbau des Multi-Agenten-Systems oder zur Umsetzung mit OpenCode? Lass es mich gerne in den Kommentaren wissen!
Ziel: universelle Fernbedienung mit Alexa Integration
Mein Ziel ist es, dass ich eine universelle Fernbedienung mit Tasmota realisiere. Dazu verwende ich die auvisio WLAN Fernbedienung von Pearl, auch unter dem Namen URC-150.app. Die Produktseite ist hier zu finden https://www.pearl.de/a-NX4519-3103.shtml
Flashen der IR Fernbedienung mit Tasmota
Auch diese ungefähr Streichholzschachtel große Box basiert auf einem ESP8266 und der Tuya Software, mit den gleichen Sicherheitslücken wie etliche Steckdosen und kann mittels Tuya-Convert mit Tasmota geflasht werden. Wie das gemacht werden kann habe ich hier am Beispiel einer Teckin SP21 Steckdose beschrieben.
Das Flashen geht leicht von der Hand und klappte im zweiten Anlauf, nachdem ich den Resetknopf an der Unterseite der auvision WLAN Fernbedienung lange gedrückt hielt. Ggf. muss man hier etwas probieren (lange drücken, gedrückt halten bis der Flashvorgang startet, mehrfach drücken…. wer hier genaueres weiß gerne in die Kommentare schreiben).
Nach dem Flashen macht Tasmota wie gehabt einen WLAN Accesspoint TASMOTA-XXXX auf, mit dem man sich z.B. mit dem Handy verbindet und den Zugang zum lokalen WLAN konfiguriert. Anschließend startet Tasmota neu und ist ab sofort im lokalen WLAN unter der per DHCP zugewiesenen IP Adresse erreichbar.
Um die IP Adresse des neuen Geräts im lokalen Netzwerk herauszufinden schaut man im Router in der Liste der Netzwerkgeräte nach. Alternativ verwende ich dafür die App Fing die das lokale Netzwerk nach Geräten scannt. Schön ist, dass man hier auch gleich noch nach offenen Ports scannen kann uvm.
Hat man die IP des neuen Geräts herausgefunden ruft man diese im Browser auf und kann das Tasmota für die IR Fernbedienung konfigurieren.
Konfiguration von Tasmota für die IR Fernbedienung
Nach dem ersten Flashen mit tasmota.bin habe ich per Over The Air Update das tasmota-ir Binary geflasht. Ansonsten war das senden per irsend nicht möglich. Um das IR Binary einzuspielen muss nur unter Firmware Upgrade die OTA Url http://ota.tasmota.com/tasmota/release/tasmota-ir.bin angegeben werden,
Als Template habe ich unter Configuration / Configure Other das Template für auvisio S06 eingetragen (Haken „Activate“ nicht vergessen!):
Hier aktiviere ich auch MQTT, das ich für die Steuerung später benötige. Unter Configuration / Configure MQTT trage ich noch meinen MQTT Broker ein und vergebe ein Topic. In meinem Fall nenne ich das Topic infrarot.
Fernbedienung auslesen
Nun beginnt der spannende Teil, das Auslesen von Infrarot Kommandos. Dazu öffne in Tasmota die Console, halte die Fernbedienung in Richtung der auvisio Box und drücke die gewünschten Tasten an der Fernbedienung. In der Console werden daraufhin die empfangenen IR Kommandos geloggt. Diese Kommandos verwenden wir dann, um sie mit IRsend zu versenden. Beispielhaft habe ich nach dem Druck auf Taste 1 meiner Fernbedienung in der Console diese Ausgabe erhalten:
Um nun über die auvisio Box das Kommando für Taste 1 zu senden kann in der Console einfach das Kommando in der Form IRsend {"Protocol":"<value>","Bits":<value>,"Data":<value>} abgesetzt werden. Konkret für die oben empfangenen Daten also: IRsend {"Protocol":"RC5","Bits":12,"Data":0x201}, Auf der Konsole wird die Aktion entsprechend protokolliert und das Gerät entsprechend geschaltet:
Mit einer Fernbedienung für meinen Samsung Fernseher hatte ich die Schwierigkeit, dass als Protocol „unknown“ angezeigt wurde. Meine Recherche hat mich zur Möglichkeit Raw Daten auszulesen geführt. Hierzu wird über die Console mittels SetOption58 1(Doku zur Option hier) der Empfang von Raw-Daten eingeschaltet. Die Ausgabe unten zeigt, wie diese Raw Daten dann aussehen.
Header mark 4446 Header space 4468 Bit mark: 585 Zero space: 540 One space: 1650 Bitcode: 11100000111000000100000010111111
… um damit schließlich dieses Kommando abzusetzen IRsend raw,0,4446,4468,585,540,1650,11100000111000000100000010111111
Und siehe da – der Fernseher ging an. Yippieh!
Wie ich allerdings später festgestellt habe hätte ich mir das komplizierte Vorgehen auch sparen können. Ein langer Druck auf die entsprechenden Tasten auf der Fernbedienung führen dazu, dass einige Male das Protokoll als „Samsung“ erkannt wurde. Vielleicht hätte auch SetOption38 zur Anpassung der Protokoll-Erkenn-Empfindlichkeit weitergeholfen über die ich aber leider erst jetzt gestolpert bin.
Nun ja…. ging auch so … und ich habe einige über IR Protokolle gelernt.
Und jetzt wird per MQTT ferngesteuert
Auf der Console in Tasmota haben wir nun der Reihe nach alle Tasten gedrückt und uns alle benötigten Codes aus den „Data“ Strings besorgt. Wie wir sehen können werden sie über Tasmota dank eingeschaltetem MQTT auch direkt an das Topic tele/infrarot/RESULT gepublished.
Also versuchen wir jetzt einfach den anderen Weg und publishen an das cmnd Topic cmnd/infrarot/irsend {"Protocol":"RC5","Bits":12,"Data": 0x201}. Hierzu verwende ich zunächst den MQTT Explorer als Client.
Das klappt ja schon mal prima!
Mittlerweile habe ich Node Red installiert (bei mir als Service in IOBroker im Docker Container auf der Synology DS718+) und lege mir daher einen Flow für meine Fernbedienung an. Wer einen Einstieg in Node Red sucht, dem kann ich die Videos von haus-automatisierung.com zu Node Red sehr empfehlen.
Nun habe ich einen schönen Knopf auf meinem Node Red Dashboard, um meinen Fernseher ein- und auszuschalten. Aber ich will mehr: Jetzt soll AppleTV gesteuert werden.
AppleTV per MQTT fernsteuern
Der erste Versuch über den Node https://flows.nodered.org/node/node-red-contrib-apple-tv ist fehlgeschlagen. Node Red lief zu der Zeit auf einem Raspberry Pi und die Installation des Node ist bei sodium fehlgeschlagen. Hier dann einen für mich viel einfacheren Weg gegangen, indem ich die auvision Box als Fernbedienung im AppleTV angelernt habe. Hierzu habe ich mir eine Reihe von Codes „ausgedacht“, die ich per MQTT oder Tasmota Console wie oben beschrieben an das AppleTV geschickt habe.
Mit Alexa mache ich es mir jetzt einfach. Ich verwende den IOBroker Adapter Alexa2, der entsprechende Nodes in Node Red zur Verfügung stellt, mit denen ich auf Routinen zugreifen kann, die ich in der Alexa App angelegt habe. So habe ich mir Routinen für „Alexa, Fernseher Pause“ und „Alexa, Fernseher Wiedergabe“ angelegt. Auf diese kann ich in Node Red zugreifen und reagieren. Hierzu prüfe ich den Wert der Alexa Routine reagiere auf „true“, schreibe meine Payload, die ich an MQTT schicke und setzte den Wert der Alexa Routine nach einer Sekunde auf false zurück.
Wahrscheinlich etwas komplizierter als es sein müsste, aber es klappt.
Ziel erreicht
Nach einigem hin-und her hat es also schließlich geklappt und ich steuere mein AppleTV zumindest in den wesentlichsten Funktionen per Alexa. Über Kommentare zu einfacheren Wegen oder Anregungen würde ich mich freuen.
Viel Spaß damit!
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
