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.
Das Community Paket mosquitto auf der Synology installieren
Per SSH auf der Synology einloggen und die mosquitto.conf anpassen (allow_anonymous false und password_file <PFAD ZUR PASSWORTDATEI>)
mosquitto über Paketmanager starten
Um einen Blick auf den Datentransfer zu werfen nutze ich den MQTT Client MQTT Explorer von Thomas Nordquist http://mqtt-explorer.com/
Domosticz installieren
Zunächst habe ich Domosticz ebenfalls auf der Synology installiert wie hier beschrieben: https://www.domoticz.com/wiki/Synology . Allerdings schien mir das System etwas instabil und daher entscheide ich mich doch für einen Raspberry B, der hier noch rumliegt.
Jetzt müssen nur noch die mit Tasmota geflashten Steckdosen für MQTT aktiviert und für Domoticz eingerichtet werden.
In Tasmota unter Configuration / Configure other => MQTT enable anhaken. Dann unter Configuration / Configure MQTT den Hostnamen (bei mir die IP der Diskstation) und Port sowie User und Passwort, die in der mosquitto Passwortdatei eingetragen wurden angeben. Als Topic habe ich zunächst tasmota eingetragen gelassen.
Anschließend in Domoticz (bei mir im Browser unter der IP meines Raspberry PI mit dem bei der Installation angegebenen Port zu erreichen) eine Hardware konfigurieren wie hier https://github.com/arendst/Tasmota/wiki/Domoticz beschrieben (Hardware / Client Gateway with LAN interface und Hardware / Dummy (used for virtual switches) hinzufügen und konfigurieren. Virtual Sensor erzeugen und unter Setup / Devices die Idx der Steckdose herausfinden. Das erste Device bekommt die Idx 1 und dann wird hochgezählt.
Im Tab Switches von Domoticz stehen die Devices zur Verfügung. Devices, die als Favorit markiert sind (Stern), stehen im Dashboard zur Verfügung und können dort mit einem Klick auf das Symbolbild später geschaltet werden.
Zurück zum Tasmota Gerät. Dort die Configuration / Cofigure Domoticz aufrufen und die Idx im entsprechenden Feld angeben. Speichern und fertig. Jetzt sollte mit einem Klick auf das Bild im Dashboard von Domotoicz die Steckdose geschaltet werden können.
Aufruf per App
Schlussendlich sollen die Steckdosen noch per App geschaltet werden können. Hierzu installiere ich die Domoticz App, konfiguriere IP und Port. Fertig. Schon stehen die Favoriten aus Domoticz zum Schalten zur Verfügung.
Raspberry Pi mit WLAN Adapter TL-WN823N von TP-Link vorbereiten
Ich verwende einen Raspberry Pi mit WLAN Adapter. Hierzu habe ich den TL-WN823N von TP-Link verwendet, der allerdings vom Raspian nicht automatisch erkannt wurde. Damit er funktioniert habe ich das bei http://romcheckfail.com/tl-wn823n-raspberry-pi-3-wireless-fix/ beschriebene Script installiert.
Teckin SP21 flashen
Anschließend das Script aus dem Github Repository des VTRUST / c’t Projektes ins aktuelle Verzeichnis auf dem Raspberry klonen und das Vorbereitungsscript ausführen und den Anweisungen des Scriptes folgen.
# git clone https://github.com/ct-Open-Source/tuya-convert
# cd tuya-convert
# ./install_prereq.sh
Durch das Script wird ein WLAN Access Point mit dem Namen vtrust-flash geöffnet. Mit diesem verbindet man sich nun mit einem Smartphone.
Ist das geschehen startet man den eigentlichen Flash-Vorgang mittels ./start-flash.sh. Die Teckin SP21 muss dazu in eine Steckdose gesteckt werden. Die blinkende blaue LED zeigt an, dass die Dose im Konfigurationsmodus ist.
Tasmota konfigurieren
Während des Flash Vorganges kann Tasmota oder Espurna als Firmware ausgewählt werden. Ich habe mich für Tasmota entschieden. Nach dem Flashvorgang öffnet der ESP8266 des Teckin SP21 einen WLAN Accesspoint mit Namen „Tasmota-XXXX“. Mit diesem verbinden wir uns nun. Ich verwende das gleiche Smartphone, das ich schon für den VTRUST Accesspoint verwendet habe.
Auf der Startseite des Accesspoint kann nun der Zugang zum eigenen WLAN-Router konfiguriert werden. Die Teckin Steckdose wird so in das eigene Netz gebracht. Nachdem die Zugangsdaten gespeichert wurden taucht die Steckdose mit eigener IP-Adresse im Router auf. Mit einem iPhone und der App „Fing“ kann man ebenfalls schnell das Netz scannen und die IP Adresse herausfinden.
Mit der IP Adresse im eigenen WLAN verbinden wir uns nun und schließen die Konfiguration ab.
Hierzu wählt man im Bereich „Configure“ den Punkt „Configure Module“ und wählt BlitzWolf SHP (45), da Teckin SP21 noch nicht in der Liste auftaucht. Ab sofort läßt sich die Teckin Steckdose über das Webfrontend von Tasmota schalten.
Außerdem kann unter „Config Other“ auch gleich noch die Emulation für „Hue Bridge“ angehakt werden. Diese wird für die Integration in Alexa benötigt.
Ist das geschehen kann in der Alexa App nach neuen Phillips Geräten gesucht werden. Der Teckin Stecker taucht dann mit dem ebenfalls auf „Config Other“ eingestellten „Friendly Name“ als Lampe auf und kann dort geschaltet werden.
Alternativ zur HUE Emluation kann eine Belkon WeMo Emulation verwendet werden, die ich bisher jedoch noch nicht ausprobiert habe.
In der Alexa-App kann das Gerät wie üblich auch umbenannt werden, so dass man dort einen eigenen „Friendly Name“ konfigurieren kann.
Es musste mal wieder irgendwas elektrisches mit Kabel her. Die Wahl fiel diesmal auf eine IP Kamera. Neu auf dem Gebiet der Heimüberwachung sollte es erstmal ein günstiges Modell sein. Ich entschied mich für die DB Power VA033K+ für unter 40 Euro. Wie gewohnt traf die Lieferung kurz nach Bestellung auch schon daheim ein. Also frisch ans Werk…
Schnell war die App P2Pipc auf das iPhone heruntergeladen und die Kamera, angeschlossen an das heimische Netzwerk über ein Ethernet Kabel, mittels Scan Funktion anhand des QR Codes auf der Unterseite der Kamera erkannt. Na, das ging doch einfach … Schnell noch das Passwort für den Admin in der App geändert und das heimische WLAN ebenfalls über die App konfiguriert. Und nun kann es richtig losgehen.
Doch dann begannen die Schwierigkeiten, die mich bei der Recherche nach einer Lösung in abseitige Ecken des Internets, auf chinesische, niederländische und französische Homepages und auf privat betriebene FTP Server führte. Hoffentlich habe ich mir hier nichts eingefangen 🙂
Grund für die ausgedehnte Recherche war, dass der Zugriff zwar über iPhone App prima funktionierte, aber nicht über das Webfrontend des in die Kamera eingebauten Webservers. Die IP Adresse, die die Kamera per DHCP bezogen hatte, konnte ich noch leicht über die Adminoberfläche der Fritz.box herausfinden. Der Aufruf der Webseite jedoch gestaltete sich hingegen schwieriger. Nach dem Tausch von Netzwerkkabeln, mehreren Resets der Kamera und etlichen verzweifelten Logikversuchen später viel es mir auf: Der Zugriff auf das Webfrontend war nicht möglich, solange das LAN-Kabel noch in der Kamera steckte…. hä? OK, WLAN ist ja konfiguriert, da mache ich mir lieber keine weiteren Gedanken drüber.
Der Login auf die Weboberfläche klappte nun schließlich. Auch ein Live-Bild wurde angezeigt. Na, das scheint doch alles ganz gut zu funktionieren. Doch leider folgt die Ernüchterung auf dem Fuß: Kein Schwenken der Kamera ist möglich. Keine Einstellungen konnten über das Menü geändert werden. Hier bekomme ich immer nur die Fehlermeldung „var result=“Auth Failed“. Komisch. Ich habe mich doch grade erst mit dem Account auf der Kamera angemeldet?
Der Versuch über Wireshark herauszufinden, was genau den hier grade schief läuft hat leider nicht zum Erfolg geführt. Muss vielleicht an der Firmware der Kamera liegen. Nix war zu finden. Die Homepage von DB Power ist leider nicht erreichbar. Argh…
Und schließlich die Lösung
… und die kann manchmal so einfach sein.
Entnervt habe ich mich dazu entschlossen, schließlich doch noch die Software auf der mitgelieferten CD auszuprobieren. Klar, es handelt sich nur um eine dieser kleinen Mini CDs, die ich in mein nicht vorhandenes CD Laufwerk beim Macbook Air nicht hineinschieben kann. Also einen alten Windows Rechner angeschmissen, der noch ein CD Laufwerk besitzt, die CD geöffnet und ein wenig vertrauenserweckendes Programm chinesischer Herkunft installiert. Mehrere Dialoge bei der Installation konnte ich nur auf Verdacht bestätigen, da die Software offenbar komplett auf Chinesisch erstellt wurde.
Doch schließlich konnte ich das Tool zum Suchen der Kamera starten und dort in den Einstellungen feststellen, dass die Länge des Passwortes für den Admin Benutzer offenbar auf 15 Zeichen beschränkt ist. Da ich ein Freund langer Passworte bin hatte ich mir ein schönes langes Passwort ausgesucht, dass grundsätzlich auch von der Kamera akzeptiert wurde. Offenbar ist nur die Web-GUI nicht in der Lage längere Passworte zu verarbeiten.
Über die P2Pipc App konnte ich dann das Kennwort auf ein kürzeres ändern (man sollte offenbar auch Sonderzeichen vermeiden … habe ich zumindest irgendwo gelesen) und siehe da:
Nun klappt auch die Schwenk-Funktion über das Webfrontend (bei mir war sie standardmäßig übrigens auf Port 81 eingestellt) der Kamera, Einstellungen lassen sich speichern … Nun scheint alles Prima.
Zum Schluss dann noch in die Synology Surveillance Station einbinden…
Die DB Power VA033K+ ließ sich dann auch noch relativ einfach in die Synology Surveillance Station einbinden. Bei meinen Recherchen in den dunklen Ecken des Internets bin ich auf verschiedene Hinweise zu baugleichen oder ähnlichen IP Kameras gestoßen. Die DB Power ist offenbar ähnlich zu Kameras von FOSCAM, HEDEN und WANSCAM.
in der Surveillance Station funktioniert bei mir die Einstellung Marke HEDEN, Kameramodell CAMHEDP5IPWB ganz prima. Inklusive Presets für das Schwenken.
Ich bin nun zumindest zufrieden.
Hat ja lange genug gedauert die Kamera zum Laufen zu bekommen. Aber irgendwie macht es ja auch immer Spaß…
Vor einiger Zeit habe ich einen günstigen USB WLAN Adapter bei ebay gekauft, den ich am Raspberry Pi betreiben wollte. Nun war es soweit und ich wollte den Wifi Adapter in Betrieb nehmen.
Am Raspberry Model B Revision 2 angeschlossen wurde der Adapter zwar erkannt, die Eingabe von lsusb führte zu folgendem Ergebnis:
pi@raspbmc:~$ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 148f:7601 Ralink Technology, Corp.
Aha, es scheint sich um einen Adapter von Ralink zu handeln.
ifconfig hingegen hat keinen W-Lan Adapter angezeigt.
pi@raspbmc:~$ ifconfig
Nun ging die Suche los und hat mich über einige Webseiten und Foren geführt.
Die Suche nach der Ralink ID „148f:7601“ brachte es schnell ans Licht. Der WLAN Adapter verwendet einen MT7601 Chip von Ralink, der offenbar nicht vom Kernel direkt unterstützt wird.
Nun denn, also erstmal nach dem Rechten sehen. Um welches Linux geht es denn genau?
pi@raspbmc:~$ uname -a
Linux raspbmc 3.12.31 #2 PREEMPT Wed Oct 29 09:24:56 UTC 2014 armv6l GNU/Linux
Als erstes habe ich die Treibersourcen bei Mediatek auf meinen lokalen Rechner heruntergeladen und anschließend per scp (Secure Copy) auf den Pi übertragen. Dieser Schritt war notwendig, da Mediatek für den Download eine E-Mail Adresse wissen wollte. Die Datei DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2 landete in meinem Downloadverzeichnis.
Auf dem Mac wird dann ein Terminal geöffnet. Unter Windows geht sowas prima mit Putty.
#ins Verzeichnis Downloads wechseln
cd Downloads/
#Treiber auf den Raspberry Pi in das Verzeichnis /tmp kopieren
scp DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2 pi@192.168.178.38:/tmp
Anschließend per ssh mit dem PI verbinden und dort geht’s weiter.
ssh pi@192.168.178.25
Die IP Adresse müsst ihr natürlich durch die IP Adresse eures PI ersetzen.
Und weiter gehts auf dem Pi
Die nachfolgenden Zeilen habe ich dann einzeln auf dem Raspberry Pi ausgeführt. Die Kommentare (Zeilen die mit # beginnen) natürlich nicht.
#Werde root
sudo bash
#Die grafische Oberfläche stoppen
#(verringert die CPU Last und spart RAM)
initctl stop xbmc
#Installiere Notwendige Pakete um die Treiber zu bauen
apt-get -y install build-essential bc gcc make wireless-tools
#Module.symvers aus den Kernel headers herunterladen
cd /tmp
wget http://www.mirrorservice.org/sites/raspbmc.com/downloads/bin/kernel/linux-headers-latest.deb.gz
mkdir x
dpkg-deb -x linux-headers-latest.deb.gz x
mv -v x/usr/src/linux-headers-$(uname -r)/Module.symvers /usr/src
#Kernel source laden und vorbereiten
cd /usr/src
gKernel=$(uname -r | sed 's/[0-9]*$/y/')
#der folgende Schritt dauert eine Weile, da nun die Kernel Quellen geladen werden
wget --no-check-certificate https://github.com/raspberrypi/linux/archive/rpi-$gKernel.tar.gz
#auspacken des Quellarchives
tar xzf rpi-*.tar.gz
mv linux-rpi-*y rpi-linux
Als nächstes habe ich den Treiber aus dem Verzeichnis /tmp nach /usr/src kopiert, dann haben wir alles beieinander. Hier weicht die Anleitung von der Anleitung bei Dodger Tools ab, da wir einen anderen Treiber kompilieren wollen.
cp /tmp/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2 /usr/src/
#Treiber entpacken
tar xvjf DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2
Und weiter geht’s wieder mit der Anleitung von Dodger Tools:
#Kernel konfigurieren
cd /usr/src/rpi-linux
make mrproper
zcat /proc/config.gz > .config
sed -i 's/CONFIG_CROSS_COMPILE.*/CONFIG_CROSS_COMPILE=""/' .config
make modules_prepare
cp /usr/src/Module.symvers .
#Symlinks erstellen, damit die Modul Source die Kernel Source finden
rm -r /lib/modules/$(uname -r)/build
rm -r /lib/modules/$(uname -r)/source
rm -r /usr/src/linux
ln -s /usr/src/rpi-linux /lib/modules/$(uname -r)/build
ln -s /usr/src/rpi-linux /lib/modules/$(uname -r)/source
ln -s /usr/src/rpi-linux /usr/src/linux
Hier wieder eine leichte Abweichung wegen des anderen Treibers
#Modul kompilieren und installieren
cd /usr/src/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913
make
make install
#Alte Kernel Module entfernen
rm -r /lib/modules/$(uname -r)/kernel/drivers/net/wireless/rt2x00
#Raspberry pi Rebooten
reboot
#Wieder einloggen, Root werden und dann Prüfen, ob ein WLAN Adapter angezeigt wird
iwconfig
Yippieh, das hat funktioniert
Die Ausgabe zeigt:
root@raspbmc:/usr/src/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913# iwconfig
ra0 Ralink STA ESSID:"MeineSSID" Nickname:"MT7601STA"
Mode:Managed Frequency=2.437 GHz Access Point: 10:9A:DD:81:CE:6D
Bit Rate=58.5 Mb/s
RTS thr:off Fragment thr:off
Encryption key:1234-ABCD-2345-BCDE-3456-CDEF-4567-DEFG Security mode:open
Link Quality=79/100 Signal level:-62 dBm Noise level:-81 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
lo no wireless extensions.
eth0 no wireless extensions.
Jetzt nur noch das Network interface konfigurieren
nano /etc/network/interfaces
Dort dann folgendes einfügen (SSID und PASSWORD müssen durch eure Werte ersetzt werden):
auto ra0
allow-hotplug ra0
iface ra0 inet dhcp
wpa-ssid "ENTER YOUR NETWORK SSID"
wpa-psk "ENTER YOUR NETWORK PASSWORD"
Nach einem Reboot des Pi war dieser über WLAN erreichbar und hat eine schöne eigene IP Adresse erhalten:
Gedacht war das ganze erst als Fingerübung. Hauptzweck war es herauszufinden, was man machen muss, um eine App im Market zu veröffentlichen. Aber dann hat es wirklich viel Spass gemacht, die App zu entwicklen.
Eigentlich war alles ganz einfach. Hier die wichtigsten Schritte:
Als erstes musste natürlich die Idee geboren werden. Nach der Installation des Google Android SDKs habe ich mir den Beispielcode angeschaut und einige interessante Dinge gefunden. TTS hatte es mir gleich angetan. Mit Text To Speach ist es sehr einfach möglich die Sprachsynthese von Google zu nutzen. OK, also irgendwas mit TTS. Warum nicht noch Tiere dazu, das passt doch immer gut 🙂
Eclipse, Android SDK, ADB, … damit kommt dann halt jeder in Kontakt, wenn er eine App für Android bastelt
Wenn man die App fertiggestellt hat und veröffentlichen möchte muss man sie für ein Release kompilieren. Mit Eclipse Projekt/Export ging es ganz einfach. Inklusive der Erstellung des notwendigen Keys
Als nächstes noch schnell beim Publishing für den Android Market angemeldet. Unter market.android.com/publish ging das ganz flott. Inklusive der Anmeldung für den Google Developer Account. Die 25$ müssen über Google Checkout bezahlt werden. Dafür ist eine Kreditkarte notwendig.
Beim ersten Versuch die App zu publishen gab es ein paar Probleme. Zur App müssen mindestens zwei Screenshots hochgeladen werden. Obwohl ich das gemacht habe, zeigte Google eine Fehlermeldung an, ich müsse mindestens zwei Bilder hochladen. Also flugs den Browser geschlossen, und das ganze nochmal gestartet. Dann funktionierte das Einstellen in den Market reibungslos. Schön wäre es gewesen, ich hätte alle Texte, die zur Beschreibung der App notwendig sind gespeichert. So musste ich sie mir nochmal ausdenken. Nun denn, jetzt bin ich klüger. 🙂
Und siehe da, schon wenige Minuten später konnte ich die App Over The Air aus dem Market installieren. Das ging wirklich einfach!
Das Einbinden eines 1und1 Smartdrive unter Ubuntu 10.10 gestaltet sich ganz einfach. Allerdings sind einige Schritte zu beachten. Eine ausführliche Anleitung findet man hier:
It has taken me some time to get the 1und1 Smartdrive to work correctly under Ubuntu 10.10 Maverick through webdav. Capturing the steps here, to remind myself and share with the community.
Most of this info is created by testing, trial and error, using pieces of information found on the internet and the man pages.
1) Install davfs2 (via synaptic or command line: sudo apt-get install davfs2)
2) Allow users to mount by setting this option through this program
"sudo dpkg-reconfigure davfs2"
3) Create folder /media/1und1 (sudo mkdir /media/1und1)
4) Edit /etc/fstab by adding this line
https://sd2dav.1und1.de /media/1und1 davfs user,noauto,rw 0 0
5) Edit /etc/davfs2/davfs2.conf, changing the following line:
a) from: # ignore_home # system wide config file only
to: ignore_home kernoops # system wide config file only
b) from: # if_match_bug 0
to: if_match_bug 1
6) Edit /etc/davfs2/secrets, adding the line with credentials
https://sd2dav.1und1.de kaxxxx-xxx@online.de your-password
7) Add yourself to the user-group davfs2
(System -> Administration -> Users and Groups)
You can now mount /media/1und1 to your 1und1 Smartdrive as user
Einen anderen Weg als Google Apps geht Amazon Elastic Computing Cloud.
Auch Amazon stellt dem User seine Infrastruktur zur Verfügung. Hierbei allerdings erstellen Benutzer ein Amazon Machine Image (AMI), das entweder ein Linux oder Windows Image ist. Das ganze ist vergleichbar mit einem VMWare Image. Das Image erstellt man derart, dass die benötigten Applikationen vorkonfektioniert sind und das Image nur noch gestartet werden muss, um in die Infrastruktur eingebunden zu werden.
Genial, wenn dynamisch Rechenleistung hinzugeschaltet werden können muss.
Bezahlt wird nach Leistung, Dauer der Nutzung und übertragenem Datenvolumen und kann auf den Webseiten des Dienstes nachgelesen werden.
Wem es nur um Speicherplatz für seine Daten geht (z.B. das Backup von Daten oder aber auch für den performanten Zugriff auf Daten aus dem Internet), der sollte sich mal den Amazon Simple Strorage Service anschauen. Auch hier bezahlt der User nur die tatsächlich angefallenen Volumina.
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.
