Ich hab mir eine BUSY Bar gekauft, damit Leute im Büro sehen, wann ich telefoniere. Drei Stunden später zeigt das Ding meine Stromproduktion, die Termine meiner drei Kalender, den Regenalarm für Salzburg und wie viel von meinem Claude-Wochenlimit noch übrig ist. Die ursprüngliche Funktion, Anwesenheitsstatus, hab ich als erstes wieder rausgeworfen.
Das ist keine Anleitung „So nutzt du die BUSY Bar richtig“. Das ist die Geschichte, wie aus einem netten, aber ziemlich limitierten Gadget mit Vibe Coding ein System wurde, das läuft, egal wo das Gerät gerade steht. Zuhause, im Büro, im Hotel, solange WLAN da ist. Du bekommst am Ende dieses Artikels die komplette Architektur, die Fallen der undokumentierten API und eine ehrliche Einschätzung, für wen sich der Aufwand überhaupt lohnt.
Fangen wir bei dem an, was in der Box liegt.
Was kann die BUSY Bar eigentlich von Haus aus?
Die BUSY Bar ist eine 72×16-Pixel-RGB-LED-Matrix im Alu-Gehäuse, gebaut von busy.app, mit Drehregler, Start-Pause-Taste und WLAN. Aus der Box heraus macht sie genau das, wofür sie beworben wird: Fokuszeiten anzeigen, Pomodoro-Timer, ein „Busy“-Status fürs Büro, eine vorinstallierte Mini-App für Uhrzeit und Datum. Solide Hardware, sauber verarbeitet, das Display ist auch bei Tageslicht gut lesbar.
Aber das war’s dann auch. Die Bar zeigt an, was ein anderes Programm ihr schickt, mehr nicht. Kein eigenes Betriebssystem mit App-Ökosystem, keine Automatisierung, keine Anbindung an irgendetwas, das schon in meinem Zuhause läuft. Es gibt zwar eine offene HTTP-API, aber die musst du selbst ansprechen. Für die meisten Käufer bleibt das Gerät eine sehr schön gebaute Anwesenheitsanzeige.
Warum mir das nicht reicht
Ich hab seit 2024 ein Zuhause, das mittlerweile ziemlich viel selbst weiß. Ein Raspberry Pi mit Home Assistant kennt meinen Stromverbrauch, die Temperatur in vier Räumen, den Wetterbericht meines Gartensensors, drei Google-Kalender und meine Claude-Nutzung. All dieses Wissen sitzt normalerweise in einem Dashboard, das ich aktiv aufrufen muss. Am Schreibtisch, am Handy, wo auch immer.
Eine BUSY Bar, die nur „Busy“ oder „Pomodoro“ anzeigt, während direkt daneben ein Home-Assistant-Server mit Dutzenden Sensoren läuft, ist für mich vertane Chance. Die Frage war nicht, ob ich die Bar so nutze, wie sie gedacht ist. Die Frage war, wie viel von meinem Zuhause ich auf eine 72×16-Pixel-Fläche quetschen kann, ohne dass sie unleserlich wird.
Kurz zur Begriffsklärung
Bevor es technisch wird, drei Begriffe, die im Rest des Artikels öfter vorkommen:
Vibe Coding bedeutet, dass du einer KI in normaler Sprache beschreibst, was du bauen willst, und mit ihr iterierst, bis das Ergebnis passt. Ich hab dazu selbst schon ausführlich geschrieben, unter anderem in meinem Artikel über Apps bauen ohne Programmierer, einfach mit Klartext.
REST-API ist die Schnittstelle, über die zwei Programme per HTTP miteinander reden, ohne dass jemand manuell in einer Oberfläche klickt. Die BUSY Bar hat eine, Home Assistant auch.
RRULE ist die Regel in einem Kalenderformat (iCal), mit der sich wiederkehrende Termine beschreiben lassen, etwa „jeden Donnerstag“. Das klingt banal, hat mich echt Zeit gekostet, dazu gleich mehr.
Wie ich das Ding vibe-gecoded hab
Drei Teile, die zusammenspielen. Kein Zufall, sondern bewusst so aufgeteilt, weil jeder Teil ein anderes Problem löst.
Teil eins ist das Desktop-Gadget, ein reines Python-Programm ohne externe Bibliotheken, pure stdlib. Es läuft als Fenster auf meinem Windows-PC, spiegelt sich aber gleichzeitig auf die echte Bar. Hier stecken alle Module, das Layout, die Icons.
Teil zwei ist eine kleine Bibliothek, die das Gadget als Modul importierbar macht, ohne dass Layout, Icons oder Datenquellen zweimal gepflegt werden müssen.
Teil drei ist eine Home-Assistant-App, die genau dieselbe Bibliothek verwendet, aber direkt auf dem Home-Assistant-Server läuft. Sie spricht Home Assistant intern über http://supervisor/core an, mit dem Supervisor-Token, das die App automatisch bekommt. Kein eigenes Long-Life-Token nötig, keine Zugangsdaten, die irgendwo im Klartext rumliegen. Und genau das ist der Punkt, an dem die Bar unabhängig vom PC wird: Solange der Home-Assistant-Server läuft, und der läuft bei mir rund um die Uhr, bekommt die Bar ihre Daten. Mein Windows-Rechner kann aus sein, im Standby, komplett wo anders stehen. Die Anzeige läuft trotzdem weiter.
Wichtig dabei: Alle Sachdaten kommen mittlerweile ausschließlich aus Home Assistant. Das Gadget selbst hat außer der Uhr, den Timern und dem Lauftext keine eigenen Datenquellen mehr. Das war eine bewusste Entscheidung, weil Home Assistant ohnehin schon die zentrale Wahrheit für mein Zuhause ist. Warum sollte ich in einem zweiten System nochmal dieselben Sensoren abfragen?
Wer selbst mit Home Assistant und KI arbeitet: Ich hab in KI und Home Assistant: Das Haus, das mitdenkt beschrieben, wie ich YAML-Fehler und Automationen generell mit Claude löse. Dieselbe Arbeitsweise steckt auch hier drin, nur eben für ein einzelnes Anzeigegerät statt für die ganze Haussteuerung.
Was die Bar jetzt eigentlich anzeigt
Sechzehn Module, alle mit klarer Aufgabe. Zeit und Alltag: Uhr, Datum mit einem Kalenderblatt, das die echte Tageszahl zeigt, Pomodoro-Timer, Countdown. Arbeit: Lauftext für spontane Nachrichten, Homeserver-Auslastung, und mein aktuelles Claude-Kontingent, 5-Stunden- und Wochenlimit, direkt aus einem Home-Assistant-Sensor. Zuhause: Energie, also Photovoltaik-Leistung und Hausverbrauch, Temperaturen aus vier Räumen, Wetter vom eigenen Gartensensor, eine Vier-Tage-Vorhersage, ein Regenalarm. Und dann noch Uptime, drei Kalenderquellen zusammengeführt in ein „Termin“-Modul, der Batterie- und WLAN-Status der Bar selbst, und ein Modul namens Plasma, das ich einfach mag, weil es keinen praktischen Zweck hat.
Zwei Module hab ich wieder entfernt, und das war ich mir eigentlich noch selbst schuldig zu erklären: Ein Modul zeigte, welches Programm gerade im Fokus war, das war aber sinnlos, sobald die Bar am Arbeitsplatz hing statt am PC. Und ein Pollen-Modul, weil mein Home Assistant dafür schlicht keine Sensoren hat (noch nicht). Kein Sensor, keine Daten, kein Modul. Klingt logisch, aber genau solche Entscheidungen fallen einem erst auf, wenn man das System wirklich benutzt statt es nur zu bauen.
Das Layout selbst ist zentral definiert, damit sich jedes neue Modul automatisch einfügt: ein Pixel schwarzer Rand, ein quadratisches Icon links, vier Spalten mit abnehmender Deckkraft als weicher Übergang, Text ab Position 19 immer linksbündig. Stehender Text wird nie abgedunkelt, nur scrollender Text läuft in diese Fade-Zone hinein, mit einem führenden Leerzeichen, damit der sichtbare Anfang trotzdem an derselben Stelle beginnt. Die Icons stammen übrigens nicht aus meiner eigenen Zeichenkunst, sondern aus echten Vorlagen: Twemoji unter CC-BY-4.0-Lizenz, das offizielle Home-Assistant-Logo, und für das Claude-Modul mein eigener kleiner Roboter Clawd aus einem Idle-GIF. Nur zwei Icons hab ich wirklich selbst gepixelt, weil die Vorlage bei 14 Pixel Kantenlänge schlicht unleserlich wurde.
Welche Fallen mir die undokumentierte API gestellt hat
Jetzt kommt der Teil, der mich zwischendurch fast wahnsinnig gemacht hat. Die BUSY-Bar-API ist offen, aber praktisch nicht dokumentiert. Fast jeder Fehler kommt als dasselbe nichtssagende „400 Bad Request“ zurück, egal was tatsächlich falsch war.
Ein paar Beispiele, damit du dir das Kopfzerbrechen sparst, falls du selbst mit dem Gerät bastelst: display: "front" ist in jedem Element Pflicht, sonst verweigert die Firmware die Annahme. Farben brauchen zwingend einen Alpha-Kanal, #RRGGBBAA, sonst ebenfalls ein Fehler ohne erkennbaren Grund. Aufräumen des Displays geht ausschließlich per DELETE-Request auf /api/display/draw, ein /clear-Endpunkt existiert nicht, ein POST darauf liefert 405. Setzt du bei einem Text width, schaltest du damit die automatische Zentrierung ab, was sinnvoll ist für scrollenden Text, aber bei stehendem Text zu schiefen Anzeigen führt.
Am meisten Zeit hat mich scroll_rate gekostet: Der Wert zählt Pixel pro Minute, nicht pro Sekunde. 1000 entspricht etwa 17 Pixel in der Sekunde. Ich hab zuerst Werte eingesetzt, die für „Sekunde“ Sinn ergeben hätten, und mich gewundert, warum der Text entweder stillsteht oder wie im Zeitraffer durchrast. Und bei Rechtecken ist fill ein Schlüsselwort, none, solid, gradient_h oder gradient_v, die eigentliche Farbe gehört in ein separates Feld namens fill_colors. Setzt du stattdessen direkt eine Farbe in fill, bleibt die Firmware einfach hängen. Ohne Fehlermeldung, ohne Log, das Gerät reagiert dann schlicht nicht mehr auf weitere Befehle.
Am kuriosesten fand ich, dass GET /api/screen die aktuelle Anzeige als BGR zurückliefert, nicht als RGB. Wer testet, ob die Farbe stimmt, sieht plötzlich Rot und Blau vertauscht und sucht den Fehler an der völlig falschen Stelle. Und Cloudflare, das vor der Busy-Cloud hängt, blockt den Standard-User-Agent von Pythons urllib mit einem stumpfen „error code: 1010″. Sobald ich einen Browser-User-Agent mitgeschickt hab, ging plötzlich alles. Diese Falle kannte ich eigentlich schon von einem anderen Projekt, ist mir hier aber trotzdem nochmal ins Netz gegangen.
Die Font-Breiten waren auch so eine Sache. Ich hab die Zeichenbreite auf der Hardware geschätzt, 30 Prozent zu hoch, wie sich rausstellte. Texte galten dadurch als zu breit für die verfügbare Fläche, bekamen automatisch ein width-Attribut und standen dann trotzdem still, weil die Bar bei geringem Überhang gar nicht erst zu scrollen beginnt. Erst als ich die tatsächlichen Pixelwerte an der Hardware nachgemessen hab, 4,6 Pixel pro Zeichen bei der schmalen Schrift, 6,7 bei der fetten, hat das Scrollverhalten gepasst.
Und dann war da noch die Sache mit dem Kalender. Meine drei ICS-Feeds liefern auch wiederkehrende Termine, technisch als RRULE nach RFC 5545 definiert. Mein erster Parser hat nur einmalige Termine erkannt, ein wöchentlicher Fixtermin fehlte komplett in der Anzeige. Die Lösung war eine eigene kleine RRULE-Expansion mit Unterstützung für tägliche, wöchentliche, monatliche und jährliche Wiederholung, inklusive Ausnahmen und einem Zeithorizont von 120 Tagen nach vorn. Kein Hexenwerk, aber auch nicht die fünf Minuten, die ich mir dafür eingeplant hatte.
Warum das jetzt auch ohne meinen PC läuft
Der eigentliche Clou an dem Ganzen ist nicht die Bar selbst, sondern dass sie komplett vom Home-Assistant-Server aus bespielt wird. Ich muss den Windows-Rechner nicht anlassen, muss kein Programm im Hintergrund laufen lassen, muss mir keine Gedanken machen, ob ich beim nächsten Neustart die Anzeige verliere. Die BUSY Bar verbindet sich entweder direkt im lokalen WLAN mit 192.168.1.111 oder, falls sie unterwegs ist, über die Cloud-API von busy.app. Ein „Auto“-Modus probiert zuerst das lokale Netz und fällt automatisch auf die Cloud zurück, gemessen liegt das bei etwa 0,1 Sekunden für die LAN-Verbindung gegenüber 0,3 Sekunden für die Cloud. Nicht dramatisch, aber spürbar, wenn du Wert auf flüssiges Scrollen legst.
Das heißt konkret: Ich könnte die Bar theoretisch mit ins Büro nehmen, an eine andere Steckdose stecken, und solange sie WLAN oder eine mobile Freigabe findet, zeigt sie weiterhin meine echten Zuhause-Daten an. Strom, Temperaturen, Kalender, alles. Das war für mich der Moment, an dem aus einem Gadget ein System wurde. Nicht weil die Hardware das kann, sondern weil ich die Datenlogik komplett aus der Hardware rausgezogen und in Home Assistant zentralisiert hab.
Übrigens auch spannend für alle, die selbst mit API-Keys und Sensordaten experimentieren: In Ich hab einen API-Key gefunden, was jetzt? beschreibe ich, wie aus einem einzigen freigeschalteten Zugang mein Strom-Dashboard entstanden ist. Ähnliches Prinzip wie bei der BUSY Bar: eine offene Schnittstelle nehmen und mit Vibe Coding etwas draus bauen, das tatsächlich täglich genutzt wird, nicht nur einmal demonstriert.
Für alle, die selbst nach 30 Jahren Pause wieder anfangen wollen, Software zu bauen: Meine eigene Geschichte dazu, vom C64 über Assembler bis zu Claude Code, steht in Vom BASIC-Zeiler zum Vibe Coder.
Was ich aus dem Projekt mitnehme
Die BUSY Bar allein ist ein hübsches Anzeigegerät mit begrenztem Funktionsumfang. Verbunden mit einem System, das schon weiß, was in deinem Zuhause passiert, wird sie zu etwas anderem: einer ambient anzeigenden Fläche, die keine Interaktion verlangt. Ich muss kein Dashboard öffnen, kein Handy zücken. Ich schau kurz hin und weiß, ob es heute regnet, wie viel Strom die Sonne gerade liefert und wann mein nächster Termin ist.
Der Aufwand dahinter war nicht klein, die undokumentierte API allein hat mich Zeit gekostet. Aber genau das ist der Unterschied zwischen einem Gadget, das tut, wofür es beworben wurde, und einem System, das für dich gebaut ist. Für EPU und KMU, die ich in meiner Beratungsarbeit begleite, ist das oft die entscheidende Frage: Reicht mir das Standardprodukt, oder lohnt sich der Aufwand, es an meine echten Abläufe anzupassen? Bei der BUSY Bar war die Antwort für mich eindeutig ja.
