Als vor ein paar Wochen die große Umzugswelle zu Mastodon begann, kam ich mal wieder auf die Idee, dass es sicher lustig wäre, wenn ich den Blog direkt anschließe. Bisher gab es kein Activity-Pub-Plugin für Kirby, was wahrscheinlich daran liegt, dass im Großen und Ganzen nur wenig Leute Kirby als Blog, oder sowas benutzen, wo es sinnvoll wäre, sowas zu haben.

Meine Finger juckten, ich hatte Lust das auszuprobieren, kann ja alles nicht so schlimm sein. Ich las also eben mal durch die ActivityPub-Spec und begann ganz vorsichtig ein paar Routen in meine Kirby-Installation reinzunehmen.

Nach dem ersten Herumprobieren fand ich auch schon den sehr hilfreichen Blogpost von Eugen, dem Erfinder von Mastodon. Im Blog schreibt er im Post “How to implement a basic ActivityPub server” genau das, was ich machen wollte. Mehr oder weniger.

Der Post behandelt erstmal, wie man eine Reply auf eine Nachricht schickt, ist aber etwas veraltet, denn mittlerweile enthält die Signatur auch noch einen Digest-Wert, aber insgesamt konnte ich damit schonmal gut arbeiten und das Grundkonzept verstehen. Zunächst widmete ich mich aber erstmal der Follow-Funktionalität, weil was bringt es mir, Content zu veröffentlichen, wenn ihn gar niemand sieht!

Im Nachhinein kann ich jetzt sagen, dass das ja alles gar nicht so schlimm ist. Natürlich habe ich beim Herumprobieren teilweise ewig gebraucht um die richtigen Bausteine so zu kombinieren, dass es funktioniert und in den nächsten Posts zu diesem Thema werde ich vielleicht noch ein bisschen tiefer darauf eingehen.

Gleichzeitig war das aber auch mal wieder so ein Projekt, bei dem ich es einfach beim Proof of Concept hätte lassen sollen, denn die letzten beiden Abende, wo ich versucht hab, es alles etwas “schön” zu machen, waren irgendwie mehr nervig, als unterhaltsam. Mehr dazu aber in den nächsten Tagen!

Bis dahin möchte ich aber erstmal ein bisschen ausprobieren, ob es denn nun wirklich funktioniert. Ihr könnt dem Blog unter dem Handle knuspermagier@knuspermagier.de in eurem Mastodon-, bzw. Fediverse-Client folgen. Probiert es doch mal aus!

Manchmal baut man doch etwas größeres als sonst in Kirby und man greift zu SQLite um Daten zu speichern. Ich bin ja relativ Dependency-Faul und denke mir oft, dass ich die paar Queries dann halt kurz selber schreibe, sobald ich aber dann zu einem Laravel-Projekt wechsel und dort Eloquent benutze, hasse ich mich dafür.

Zum Glück hat Fernando Gutiérrez ein kleines Composer-Projekt gemacht, mit dem man ganz einfach Eloquent installieren und nutzen kann. Danke Fernando, danke an das Laravel-Team, dass man Eloquent auch so nutzen kann.

Heute hatte ich mal wieder so ein typisches Problem, das am Ende tausend neue Probleme eröffnete, aber der Reihe nach:

Vor etwa einem Jahr kaufte ich einen Bausatz für einen Feinstaubsensor. Ich baute das auch alles erfolgreich zusammen, aber ich schaffte es nicht, das Ding ins WLAN zu kriegen.

Nun, fiel mir das Ding wieder in die Hände und ich entschied mich, es noch einmal an zu gehen, vor allem, da ich ja gerade Home Assistant aufgesetzt hatte und mich also über jeden weiteren Sensor freue. Mittlerweile hatte ich auch ein anders WLAN und vielleicht klappt es ja damit! Erfolg! Juchu!

Nun funktionierte der Sensor und es wirkte auch so, als würde er erfolgreich regelmäßig seine Daten an die Sensor.Community-Karte pushen. Für Home Assistant gibt es nun eine Integration, bei der man die SensorID eingibt und die dann die Daten entsprechend wieder zurück holt und speichert. Nachdem das erstmal gut lief, zeigte es nur noch “unknown” und “Sensor nicht verbunden” an, in dem Moment, als ich meinen Erfolg gerade vorzeigen wollte.

Probleme

Hier offenbarten sich mehrere Probleme:

1. Home Assistant ist nicht gut darin, einfach z.B. den letzten Erfolgreich abgefragten Wert anzuzeigen, wenn ein Sensor kurzzeitig mal weg ist
2. Der Sensor hatte zwischendurch ein paar Probleme, die Daten an den WebService zu übertragen, weshalb er dort aus der Auflistung entfernt wurde, was dazu führte, dass die Integration keine Daten abrufen konnte.

Das erste Problem kann man Lösen, in dem man wilde Sachen in YAML-Dateien schreibt, die irgendwie einen temporären Sensor erzeugen, der die alten Daten zwischenspeichert, oder so, aber ich wollte erstmal das andere lösen, damit das erste vielleicht gar nicht erst auftritt!

InfluxDB to the rescue?

Die Firmware vom Feinstaubsensor kann die Daten jedenfalls auch in eine InfluxDB speichern. Hach, InfluxDB, was haben wir schon alles gemeinsam erlebt. Wie viele Daten, die ich danach nie anschaute, habe ich schon in dir gespeichert, weil es so einfach ging. Ich installierte also kurz die aktuelle Version auf dem Home Assistant-Server und musste leider feststellen, dass Version 2 überhaupt nicht mehr so einfach und schnell funktioniert wie die alte Version.

Das mag natürlich daran liegen, dass ich mich nicht großartig damit beschäftigt habe, aber ich bekam es in fünf Minuten jedenfalls nicht hin, dass der Sensor seine Daten erfolgreich speichern konnte. Keine Ahnung, ob sich der write-Endpunkt irgendwie geändert hat und nun einen anderen Syntax erwartet, oder woran es lag. Auf jeden Fall gibt es nun Organizations und Buckets und das klingt schon schlimm genug.

Zum Glück gibt es noch InfluxDB 1.8 zum Download. Puh, Tag gerettet. Installiert, mit dem Sensor verbunden, Daten werden gespeichert. Durchatmen.

Nun bin ich also wieder zurück in Home Assistant und will gerade herausfinden, wie ich die Daten aus der InfluxDB nun in einem Dashboard anzeigen kann, als mir auffällt, dass… es mittlerweile wieder Daten aus der Sensor.Community anzeigt. Na toll.

InfluxDB als Sensor in Home Assistant

Auch wenn es jetzt erstmal wieder funktionierte, wollte ich natürlich auf Nummer sicher gehen und die Daten doch aus der InfluxDB ziehen. Das ist leider wieder etwas umständlich, aber was solls. Also zunächst muss man eine sensor.yaml erstellen. Ich benutze die Docker-Variante von Home Assistant, also lege ich sie dorthin, wo auch die configuation.yaml liegt.

Anscheinend kann man in dieser Datei diverse Sensoren definieren, die man nicht über eingebaute Integrationen im Klicki-Bunti-Interface erstellt hat.

Die Datei sieht bei mir so aus:

- platform: influxdb
  host: IP-Adresse
  api_version: 1
  queries:
    - name: feinstaub_pm10
      where: 'time > now() - 7d'
      measurement: '"feinstaub"'
      field: "SDS_P1"
      group_function: last
      database: feinstaub
    - name: feinstaub_pm25
      where: 'time > now() - 7d'
      measurement: '"feinstaub"'
      field: "SDS_P2"
      group_function: last
      database: feinstaub

Das erstellt zwei Sensoren. In die configuration.yml kommt noch folgendes:

sensor: !include sensor.yaml

influxdb:
  exclude:
    entity_globs: "*"

Keine Ahnung, wozu man den letzten Teil braucht, aber es steht so in allen Tutorials! Insgesamt aber nett, dass Home Assistant überhaupt InfluxDB-Support hat und man nichts extra installieren muss.

Wie auch immer, es funktioniert nun. Mal sehen, wie lange.

Vor ein paar Monaten habe ich ja mal BetterJournal vorgestellt. Ich entwickelte das, weil ich keine Lust mehr auf Day One hatte, da ich das nicht mehr so richtig hübsch und leichtgewichtig fand.

Tatsächlich benutze ich meine Webapp nun auch täglich, mein Streak, der natürlich noch aus DayOne-Zeiten übertragen wurde, sind mittlerweile 414 Tage. Fast anderthalb Jahre lang jeden Tag irgendwas notiert, mal wichtiger, mal weniger wichtig. Außerdem nutze ich es gerade als Essenstagebuch, um meinen Snack-Konsum etwas zu kontrollieren, als Dankbarkeitsjournal, etc., was man halt alles so macht.

Heute baute ich kurz noch ein paar Kleinigkeiten ein, die mir den Umgang mit der App erleichtern, manchmal will man ja z. B. noch etwas zu einem vorherigen Tag hinzufügen, das war bisher nur etwas aufwändiger, das heißt mit drei Klicks, möglich, jetzt gehts mit Einem. Es macht mir Spaß, mir die Arbeit zu erleichtern. Umso leichter, es zu benutzen ist, umso motivierter bin ich, auch immer schön etwas rein zu schreiben, über das ich mich dann in fünf Jahren freuen kann.

Wie dem auch sei, eine Sache stört mich daran: Es ist halt eine Webseite. Klar, der (etwas unaktuelle) Code ist auf Github und jemand, der Lust darauf hat, sich eine PHP-App zu installieren, könnte es ausprobieren, aber wenn wir ehrlich sind, macht das doch keiner.

Mein Wunsch ist es irgendwie immer, den Kram, den ich baue, mit anderen zu Teilen, und zwar nicht nur in dem ich hier darüber schreibe, sondern ich würde mir wünschen, dass andere die Sachen benutzen können und sich vielleicht daran erfreuen. Leider wählte ich bisher irgendwie immer den unpassendsten Weg dafür. Bequem für mich, denn ich kann PHP und diverse Frontend-Technologien, aber halt unbequem für andere, weil nur Nerds sich eine eigene BetterJournal-Instanz aufsetzen würden.

Long story short: Ich freue mich sehr, dass ich den Sprung von Day One zu meiner eigenen Software machte, denn ich bin damit viel zufriedener, aber gleichzeitig schau ich es mir immer an und denke nur, was ich da wieder für eine unsexy Webapp gemacht habe. Es fühlt sich auch einfach falsch an, seine Tagebucheinträge in einem Webbrowser einzutippen.

In letzter Zeit spiele ich mit SwiftUI rum und Apps machen ist gar nicht mehr sooo anstrengend wie früher. Aktuell bastel ich an etwas ganz anderem, aber wenn ich das mal fertig habe, vielleicht baue ich BetterJournal vielleicht doch als richtige App? Bisschen nervig wäre es schon, alles nochmal zu bauen, aber ich fürchte, anders kann ich meinen Wunsch nach einer Software, die auch jemand benutzt, nicht befriedigen.

Vielleicht sollte ich mir auch einfach mal eingestehen, dass es auch okay ist, etwas nur für sich selber zu bauen? Es ist immer so schwierig, herauszufinden, was man eigentlich will!

Letztens schaute ich mal auf der Seite vom Freilichtheater in Tecklenburg nach, ob man schon weiß, was nächstes Jahr gespielt wird, und tatsächlich ist es Mozart! Darauf freue ich mich! Anscheinend lief es 2008 schon einmal dort, wusste gar nicht, dass das schon so alt ist.

(Laut Wikipedia ist es von 1999, also schon wesentlich älter.)

Wer wird wohl die Titelrolle singen? Oedo Kuipers wäre natürlich super, aber vielleicht ist er mittlerweile auch zu alt.

Schade, dass es keine Dauerkarte gibt, wenn es gut wird, würde ich es mir sicher mehr als einmal anschauen wollen.

Nur ein kurzer Check-In zu diesem Projekt: Ich habe es gestoppt.

Die Tatsache, dass ich nicht an die Tags komme, und noch ein paar andere Kleinigkeiten haben meine Motivation leider ziemlich getrübt. Ich hab wirklich keine Lust in meiner App einen weiteren Datenlayer mit neuen Tags zu pflegen, die in der OG Reminders.app nicht angezeigt werden, nervt mich. Auch so Sachen wie die Sortierung der Listen und Todos wäre blöd geworden. So viel Zeit-Invest ist es mir doch nicht wert, dass ich am Ende eckige Checkboxen habe.

Ich erkläre dieses Projekt damit erstmal für beendet. Spaß hatte ich trotzdem und gelernt habe ich eine Menge! SwiftUI gefällt mir richtig gut.

Außerdem habe ich mir überlegt, die Kategorie “Projekte” im Wiki irgendwie aufzusplitten und noch “Experimente” einzufügen. Habe einen faden Beigeschmack dabei, so eine unendlich lange Liste von angefangenen “Projekten“ zu haben, von denen keins fertig wurde. Experiment trifft es einfach besser.

(Hab es aber noch nicht gemacht)