Jan-Philipp Litza

Garagentormotor in Home Assistant einbinden

Mon, 28 Jul 2025 00:00:00 +0200

Unser Garagentor wurde bereits als wir die Garage übernahmen von einem Motor angetrieben. Um genau zu sein von einem „novoferm VivoPort“. Der hat zwar immerhin eine Fernbedienung, aber leider auch nur genau eine. Man könnte welche nachkaufen und anlernen, aber die hätte ich dann im entscheidenden Moment doch nicht dabei.¹

Außer mit der Fernbedienung kann man den Motor mit einem kleinen blauen Knopf unten am Gehäuse starten. Und da dachte ich mir: Den Knopfdruck kann man doch auch simulieren! Also habe ich mir einen Shelly 1 Gen3 besorgt und ein wenig gelötet: Auf der Platine des Motors selbst habe ich mir direkt am Eingang die 24V und Erde mit einem Kabel abgegriffen; außerdem beide Seiten des Schalters.

Nach entsprechender Verkabelung klappt das auch wunderbar. Der Shelly hat einen Auto-OFF Timer von 0,2s eingestellt, damit er einen kurzen Knopfdruck simuliert anstatt den Knopf gedrückt zu halten. Damit konnte ich also über Home Assistant das Garagentor vom Handy aus auf- und zumachen – außer bei Regen, dann ist das WLAN aktuell zu schwach in der Garage.

Aber schon am nächsten Tag habe ich versehentlich auf dem Heimweg das Garagentor geschlossen anstatt es zu öffnen, weil jemand anders es schon kurz vorher geöffnet hatte. Blöd. Also muss ich auch den aktuellen Zustand erkennen können.

Jetzt gäbe es viele Möglichkeiten, zu erkennen ob das Garagentor offen ist. Da der Shelly aber so schön im Gehäuse des Motors verbaut war wollte ich auch die Zustandserkennung irgendwie dort ansiedeln. Da erschien mir eine Art Neigungssensor das einfachste zu sein, da der Motor am Tor montiert ist und sich daher mit ihm zusammen neigt. Mit genauer Winkelangabe könnte man dem Tor sogar digital beim Öffnen und Schließen zusehen, bräuchte aber zusätzliche Hardware. Mir reicht vorerst eine digitale Auf/Zu-Angabe, die ich zudem über den Schalter-Eingang des Shelly selbst realisieren könnte.

Jetzt sind solche digitalen Neigungsschalter zwar Centartikel, aber nur im Fachhandel erhältlich, sodass die Versandkosten den Warenwert um ein Vielfaches übersteigen. Außerdem: Wo wäre da der Spaß?

Also habe ich so einen Neigungsschalter selbst gebaut! Dazu habe ich einen alten Kugelschreiber seiner Miene beraubt und stattdessen eine Metallkugel eingesetzt. Diese rollt darin je nach Lage hin und her und verbindet am einen Ende zwei Kabelenden, die ich im Schraubverschluss eingeklemmt und vorne durch die Öffnung herausgeführt habe.

Und schon habe ich einen Neigungsschalter zum Anschluss am Schalter-Eingang des Shelly. Im Foto ist zu sehen wie er rechts am Rand auch noch Platz im Gehäuse des Motors fand. In den Einstellungen des Shelly musste ich natürlich noch Eingang und Ausgang entkoppeln (auf „Detached“ stellen). Außerdem sollte man in den Einstellungen des Eingangs die Option „Enable factory reset from input“ deaktivieren².

Das geöffnete Gehäuse des Garagentormotors mit Shelly (blau) und Neigungsschalter (Kugelschreiber am Rechten Rand)

Schließlich musste ich in Home Assistant noch Eingang und Schalter des Shelly zu einer Garagentor-Entität machen, um sie hübsch darstellen zu können:

template:
  - cover:
      - name: Garagentor
        state: '{{ {"on": "closed", "off": "open"}[states("binary_sensor.shelly1g3_0123456789ab_input_0_input")] | default(None) }}'
        device_class: garage
        optimistic: true
        open_cover: &garagedoor_action
          action: switch.turn_on
          target:
            entity_id: switch.shelly1g3_0123456789ab_switch_0
        close_cover: *garagedoor_action

Diese ganze Lösung ist nicht nur komplett im ursprünglichen Gehäuse versteckt, sondern auch kompatibel zur klassischen Steuerung: Sowohl die Fernbedienung als auch der Knopf funktionieren noch wie zuvor, und der Zustand in Home Assistant wird trotzdem passend aktualisiert. Dafür war sie preislich vermutlich sogar günstiger als eine Fernbedienung nachzukaufen.

Jetzt bleibt (neben dem grenzwertigen WLAN-Empfang) nur noch ein Problem, das ich noch nicht gelöst habe. Während der Motor läuft fällt die Spannung so stark ab, dass der Shelly neustartet. In den bis zu 60 Sekunden nach dem Senden des Signals zum Öffnen oder Schließen (egal ob der Home Assistant oder Fernbedienung oder Knopf) ist also keine Kommunikation möglich und der Zustand wird nicht aktualisiert. Da der Neigungsschalter aber eh erst auslöst wenn das Tor fast ganz offen ist macht das beim Öffnen nur wenig Unterschied. Eventuell könnte ich mit einem passend dimensionierten³ Kondensator am Eingang des Shelly sowie einer Diode vom 24V-Eingang der Motor-Platine lösen, aber dazu stört es mich aktuell zu wenig.

Wir nutzen die Garage eher mit Fahrrädern, sodass es keine Lösung ist, die Fernbedienung einfach im Auto oder beim Autoschlüssel zu lagern. ↩
Ask me how I know… Der Eigenbau scheint etwas zu federn und daher gerne mal ungewollt den Shelly auf Werkseinstellungen zurücksetzen. ↩
Ich habe mir noch nicht angelesen, wie man das eigentlich berechnet. Ob ich da auch bei 1 Farad landen würde? ↩

Document management, part 3: Scanning documents

Tue, 22 Jul 2025 00:00:00 +0200

I previously always used gscan2pdf for scanning. A great piece of software for technically minded folks, providing tweaks for every option and kind of integrating OCR. But for batch scanning, that workflow was simply too cumbersome. And OCR was automatically done in a later stage anyway, as discussed in the first part of this post series. So I had a look at the alternatives.

When scanning documents, most business devices have a function to send an email somewhere, with the document attached. My decades-old Epson BX635FWD, which I nowadays only use for its duplex scanning capabilities (not printing), doesn't have such a feature. Tt does have network connectivity! (Although its WiFi only supports WPA-Personal, not WPA2, making it incompatible with any WiFi network in 2025 - but it does have RJ45 as well.) But in its webinterface, you can configure almost nothing (except for "AirPrint" and "Google Cloud Print").

But it does support hosting a file share itself! Of course you need to provide it with something to share, so I plugged in a USB thumbdrive. Now, what exactly is a "file share"? Probably SMB/CIFS. But opening the share via either Nautilus/GVfs/Gio/whatever-it's-called-nowadays or smbclient failed with strange error messages. The latter at least was a bit descriptive:

$ smbclient -L //EPSON63556D.fritz.box/
Protocol negotiation to server EPSON63556D.fritz.box (for a protocol between SMB2_02 and SMB3) failed:  NT_STATUS_INVALID_NETWORK_RESPONSE

So there is something there, it just doesn't do what's expected. The important bit is in parenthesis: The printer doesn't speak at least SMB2_02! man smb.conf provides us with the option client min protocol and its possible values, of which I'll just choose the lowest:

$ smbclient -L //EPSON63556D.fritz.box/MEMORYCARD --option='client min protocol=CORE'
Server does not support EXTENDED_SECURITY  but 'client use spnego = yes' and 'client ntlmv2 auth = yes' is set
Anonymous login successful
Password for [WORKGROUP\jplitza]:

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       IPC Service
	MEMORYCARD      Disk      EPSON
Reconnecting with SMB1 for workgroup listing.
Server does not support EXTENDED_SECURITY  but 'client use spnego = yes' and 'client ntlmv2 auth = yes' is set
Anonymous login successful

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------

Hm, so what should I use for login? I didn't configure any user! Also, I should probably change that option it complains about…

smbclient //EPSON63556D.fritz.box/MEMORYCARD --option='client min protocol=CORE' --option='client use spnego=no' -U WORKGROUP/user%pass -c ls
lpcfg_do_global_parameter: WARNING: The "client use spnego" option is deprecated
lpcfg_do_global_parameter: WARNING: The "client use spnego" option is deprecated
  EPSCAN                              D        0  Thu Mar  6 21:22:56 2025

Yay! So it just accepts all credentials. Also, my ability to downgrade the connection smbclient establishes to such a low security level that my scanner supports it might come to an end sooner or later, given that option is deprecated. But for now, it works!

The rest is just a little Bash scripting to fetch all documents from the scanner into the current working directory and delete them on the printer (so they don't lie around unencrypted, and also do save space on the thumbdrive).

#!/usr/bin/env bash

set -o pipefail

SHARE="//EPSON63556D.fritz.box/MEMORYCARD"
TMPFILE="$(mktemp)"

cleanup() {
    rm -f "$TMPFILE"
}
trap cleanup EXIT

smbclient() {
    command smbclient -d0 -U WORKGROUP/user%password "$SHARE" --option="client use spnego=no" --option="client min protocol=CORE" "$@"
}

smbclient -Tcag - | tar -vx --strip-components 3 --backup=numbered > "$TMPFILE"

while read FILENAME; do
    smbclient -c "del $FILENAME"
done < "$TMPFILE"

Why no cifs mount

I specifically wanted a userspace solution for this problem, because the device isn't always powered on. I was able to mount it using the cifs module of the Linux kernel using mount -t cifs //EPSON63556D.fritz.box/MEMORYCARD /mnt/scanner -o vers=1.0,sec=none, but that mount would make the whole system hang when the device was turned off.

Also, I was positively surprised to find out how much smbclient was actually able to do! That --tar option really made the whole task quite easy.

And in Nextcloud?

The above script successfully worked for several months, copying the documents into the "consume" folder of Paperless-ngx. But since I'm thinking about migrating that functionality back into Nextcloud, I wanted to see if I could simply set up anexternal SMB/CIFS storage.

My first attempt played out like this:

Me: *trying to add an external SMB storage
Nextcloud: "This action needs authentication"
Me: "OK, sure thing." *lets password manager fill in password
Nextcloud: "Wrong password"
Me: "Err, what? No, it's definitely correct!" *tries again
Nextcloud: *just hangs there
Me: *opens browser devtools* "Oh look, the response says 'Invalid storage backend "smb"'"

Yeah well… turns out I hit three bugs at once:

The error message was wrong. My password wasn't wrong at all, but the password dialog interprets every non-OK response that way. After some digging, that seems to be a global problem with that dialog in the Nextcloud frontend.
The second password entry didn't even trigger a request.
The smb backend actually should be available, since the server has smbclient installed, which the aforementioned docs say is sufficient.

That last one actually was introduced only recently. You can find the details in the issue I filed.

So after the detour of fixing that bug, I was able to successfully attempt the setup - with the expected problems, since there is no interface to specify custom options for smbclient. So I had to insert those pesky options into the system-wide /etc/samba/smb.conf:

[global]
# lower client security standards for Epson printer to work
client use spnego=no
client min protocol=CORE

Now my idea was to set up a Nextcloud flow to move the files to permanent storage and start OCR. Alas… how would Nextcloud know there were new files on the share?

The answer seems to be to regularly execute occ files_external:scan 2 in a cronjob or systemd timer. Not pretty, but doable.

But another problem arose: How to even move a file in a flow? The number of apps that provide flow actions seems to be quite small, and they are either highly specific integrations or as broad as "call a script" or "send a webhook".

Furthermore, even matching on files in a directory is next to impossible in Nextcloud flows. It involves tagging the directory, letting Nextcloud add another tag to all files inside it and then matching on that tag.

So just like I felt that Paperless-ngx doesn't quite fit my thought model, I'm now under the impression that Nextcloud flows are either completely useless or just not useful for me.

Document management, part 2: Nextcloud full text search

Tue, 22 Jul 2025 00:00:00 +0200

Nextcloud is my favorite piece of self-hosted software. It is so universal that it replaced almost everything else I used before. And I remember my surprise about the simplicity of setting up calendar and contact syncing via CalDAV a decade ago using Nextcloud, compared to earlier self-hosted solutions.

After my experiments with Paperless-ngx, I wanted to give one particular feature a go that I didn't use previously: Full text search.

The reason why I didn't use that feature earlier is simple: Its official implementation requires you to set up an Elasticsearch server. I'm sure that's a great fit for enterprise usage of Nextcloud, and in my dayjob I operated several Elasticsearch clusters of various sizes. But in the family IT, that software seems very much overkill - both in terms of resource requirements as well as skill and time required to operate.

What always amused me was that the Nextcloud engineers were considerate enough to make the whole framework very modular - provider apps provide the content to be indexed, platform apps implement the indexing and searching - and yet nobody every implemented another platform app than the official Elasticsearch one! There certainly is other software specialized on searching (Solr comes to my mind), and usually someone somewhere then implements an integration into a software so popular as Nextcloud. But not in this case.

My idea, however, was much simpler. Nextcloud already has a database backend, why not use it for searching? I knew MySQL had full text search capabilities, so I assumed PostgreSQL did as well, usually being the more advanced competitor in my impression. I didn't even know what other backends were supported, but surely supporting those most widely used would be most important!

So I dove into a jungle of code, split up between the Nextcloud server core (where - surprisingly - all of the interface definitions lived), the fulltextsearch app and the fulltextsearch_elasticsearch app. Along the way I found more and more documentation for Nextcloud developers, especially about how database access worked. But nothing really explained the whole thought model around the full text search framework with its services, runners and interfaces. So I was left with only one option: Hack away and see where it leads!

Well, it lead to the first ever Nextcloud app by yours truly: fulltextsearch_sql. It does exactly what I imagined, and it does so quite well actually!

Of course this is a mere proof of concept. The code is a spaghetti mess and the number of TODOs riddled throughout the code and issues on Github speak for themselves. I still haven't wrapped my head around the concepts of tags, substags, metatags, parts and multiple excerpts. And yet… it works! And I probably will even keep using it on my personal instance.

I'm currently in the process of submitting it to the official app catalog. We'll see if and when that works out…

Update: After more than a week, my certificate request pull request was finally merged, enabling me to submit the app. So you can now find it in the Search category of installable apps on your Nextcloud instance! I also spent some time automating E2E tests and app release with Github Actions and actually implementing PostgreSQL support (based on those tests, since my Nextcloud uses MySQL).

Frontend

Now that I had a working full text search backend, I was able to try and actually use it - after what felt like an eternity of indexing. But it turns out the front end for full text search in Nextcloud is suprisingly… rough? Every result is prefixed with "(files)" to indicate the content provider it belongs to. In a fully localized application, that feels out of place.

When the excerpt the (my) platform app provides is too long for the available screen space, it's truncated in the middle, where the searched term is most likely to show up. So maybe my understanding what an excerpt should be differs from what Elasticsearch provides…

And that's only in the webinterface. I opened a bug report to the Android app because depending on a server setting, it opens search results in the browser instead of the app itself. Ironically, the setting in question is called "Open files directly from search results". Luckily, I can just turn it off, and everything works as it should.

Conclusion

All in all, the full text search experience with Nextcloud isn't great, but it seems to work without requiring additional software. Now I just need to export everything I put exclusively into Paperless-ngx in the last few months to my old folder structure in order to really compare the two solutions.

Document management, part 1: Paperless-ngx

Tue, 22 Jul 2025 00:00:00 +0200

Nobody likes paper folders. And although I don't expect having to move ever again, if I do, I don't want to carry boxes of them around. So I set out to finally digitize all of them.

When looking for self-hosted document management software, everybody seems to be using Paperless-ngx nowadays. It's the successor to the discontinued Paperless-ng, which was the successor to the discontinued Paperless. (Wonder what the next reincarnation will be called…)

So naturally I checked out why everybody loved this piece of software. And it does have its advantages:

Simple automatic OCR of scanned PDFs
Automatic creation date recognition
Automatic assignment of correspondents, tags and other metadata based on heuristics
Full text search
Arbitrarily complex metadata for every document
Automatic import of files from a “consume” directory, to which a script puts everything my scanner scans
An inbox of documents that yet have to be categorized
Side-by-side view of editable metadata and document for easy entry of metadata

But after using it for a while, I don't consider it the right fit for my needs.

Finding documents

I often find myself wondering “What was the name of that insurance company again?” just to find their latest invoice.

In my previous setup, I just had a folder structure like Insurances/Company Name/YYYY-MM-DD Invoice.pdf. Having a list of ~10 insurance companies to pick from is much easier than remembering it from scratch (or looking through ~100 correspondents in total).

Now you could associate so called “storage paths” with documents in Paperless-ngx that would cause the PDFs to have this exact same layout on disk. Or you could associate tags with the documents. And you can also automate all that. But it doesn't beat the simplicity and accessibility of nested folders…

Metadata creep

When I said “arbitrarily complex metadata”, I referred to the ability to create custom metadata fields. But I don't need any of those! In fact, I don't even need those metadata fields that Paperless-ngx has built-in. Why would I care about the “document type“ of a document? Its title probably says it all! And those storage paths seem inferior to simply folders of files, as mentioned above.

Now of course I could simply ignore those fields. But then I feel like I'm holding it wrong! So I always try to come up with reasonable values at least for the document type, although I never use that field at all.

Access control

Last but definitely not least is access control.

I'm sure there are situations where fine grained access control is useful. For example in a business setting, with departments and everything.

But my instance is to be used by exactly two people: Me wife and me. And we're coming from a digital folder we both have access to and paper folders we both have access to. So I would simply want everything to be available to her as well.

But apparently, that's surprisingly hard. Every document has its own permissions. So does every correspondent. And while I could grant her “Superuser“ rights, that would eliminate the possibility of every having different views of the system - which might come in handy at some point.

Another curiosity: Documents imported from the “consume” directory don't have an owner and can be accessed by everyone!

Conclusion

Paperless-ngx is a great piece of software! But somehow, it doesn't fit my thought model, which seems to be very centered around classical folders.

Also, I'm in the process of simplifying my private IT infrastructure in order for it to be easier to maintain. And introducing another application doesn't quite seem justified.

What I definitely don't want to miss are full text search and automatic import and OCR of scanned documents. But I'll try to implement that in Nextcloud, which I have anyway and will very likely keep. We'll see how that works out, stay tuned…

AirCO₂ntrol in Home Assistant

Wed, 08 Dec 2021 00:00:00 +0100

Auf Empfehlung von @nblr hin habe ich mir über meinen Arbeitgeber (vielen Dank an dieser Stelle) den CO₂-Sensor „AirCO₂ntrol Mini“ der Firma TFA Dostmann besorgt. Neben drei farbigen LEDs, deren Übergänge bei 800ppm und 1200ppm liegen, hat er die Besonderheit, dass er über seine Messwerte (Temperatur und eben die CO₂-Konzentration) auch per USB Auskunft erstattet!

Der ursprünglich von @nblr verlinkte hackaday-Artikel erwies sich als wenig hilfreich, da er am Ende nicht funktionierte. Aber nach genug etwas Suchen fand ich noch diverse andere Lösungen. Eine davon schien mir für meinen Anwendungszweck tauglich: Der Sensor sollte nämlich am OpenWrt-Router im Arbeitszimmer hängen, und darauf erst mal 1000 Abhängigkeiten zu installieren ist bekanntlich schwierig. Dieses Python-Script hatte derer aber recht wenige und war simpel genug, es mal eben so umzubauen, dass es die Messwerte via ~~MQTT~~ HTTP statt via stdout mitteilt.

Und so sendet jetzt mein Fork alle paar Sekunden die aktuelle CO₂-Konzentration und Temperatur im Arbeitszimmer an meinen Home Assistant. Das erzeugt schöne Graphen, für mehr nutze ich das aber tatsächlich noch nicht, denn die LED-Ampel reicht mir aus um ans Lüften erinnert zu werden. Und das ist bei einem etwa 12m³ großen Raum schneller nötig als mir lieb ist, besonders wenn die Tür zu ist…

Graph der CO₂-Konzentration im Laufe eines Arbeitstages

Update 10.10.2022: Da mir das Python auf dem OpenWrt-Router zu viel Platz weggenommen hat bin ich auf Micropython umgestiegen und nutze jetzt die HTTP API von Home Assistant statt MQTT.

My DNS setup with PowerDNS

Sun, 30 Dec 2018 00:00:00 +0100

I recently overhauled my DNS setup (recursive for my home network and authoritative for my domains), so why not blog about it?

Let’s start with the requirements, which are kind of special. I host all my stuff at home behind a DSL line, and while I have a VPN with a static IP address as well, I don’t want to tunnel everything through it. Thus, I need dynamically updatable DNS records for almost everything.

Furthermore, I want my home network to be able to resolve my domains even when the internet connection is broken (or stated differently: I don’t want the requests to hit the internet).

Hence, I’m need a combined recursive and authoritative server. The recursive part, however, has some quirks of its own: I want to be able to resolve non-standard community-TLDs like .dn42 in the VPN-based overlay networks I’m part of. But at the same time, I want the “usual” DNS to be DNSSEC-validated. Together, this requires the ability to have so called “negative trust anchors”, or NTAs for short. They state that some part of the DNS must not be DNSSEC-validate, come whatever may. Otherwise, I could advise the DNS recursor to look for .dn42 at 172.23.0.53, but it would refuse to answer any requests for it because the DNSSEC-signed root zone says there no .dn42.

Previously, I was using bind for the authoritative part. But because bind is incapable of having configurable NTAs¹, it used unbound as recursor. This was kind of cumbersome and involved every request passing through two daemons with two caches. I chose bind because it was (and AFAIK still is) the only software that is able to DNSSEC-sign zones if it only has the ZSK, not the KSK, which I only had on my laptop. However, as my laptop is now backed up on my home server anyway, I got rid of this level of paranoia and looked at other software again.

In other contexts I very successfully used PowerDNS, and hence I set forth to replace the legacy combination with a nice pdns and pdns_recursor. And indeed: It works like a charm!

What’s more, there’s hardly anything interesting about the config that I could mention here: It just works!™ Okay, it’s a bit more than that. Especially that much of what I considered configuration takes place in the database. But nothing I had to do was out of the ordinary, and I found everything I needed in the extremely good documentation. Compare that to bind, where every documentation is incomprehensible or incomplete.

And on the way, I got some nice tools like pdnsutil edit-zone. Hooray!

In newer versions you can inject them during runtime, but they aren’t preserved across restarts. ↩

Bonding Wifi interfaces with Network Manager

Mon, 24 Sep 2018 00:00:00 +0200

For a long time, it bothered me that transitioning from network cable to Wifi caused a loss of all persistent connections. SSH being the most painful, others were noticable too (streams, chat, …).

After upgrading to Ubuntu 18.04, I noticed that Network Manager has the ability to control bonding devices. Maybe it gained this ability even earlier, but I just noticed it now. What Linux calls bonding, others teaming, port channel or link aggregation group, is usually used with multiple cables to increase throughput, reliability or both of mostly servers. The different modes decide which packets are sent out which “slave” interface, sometimes in cooperation with the switches they are connected to, sometimes without. So why not use bonding to bond the ethernet and Wifi cards in active-backup mode?

Problem was, the GUI of Network Manager apparently doesn’t want you to bond wifi interfaces. Manually, using ip link, I was able to configure the desired bond. But ditching Network Manager altogether makes managing Wifi networks really cumbersome. So after digging around a bit, I found the holy grail:

nmcli conn modify "Wifi connection" connection.master bond0 connecion.slave-type bond

This simply adds the already configured wifi connection as a slave to the already configured active-backup bond connection. You can even use the GUI afterwards to mange both, it’s just this link that cannot be created with the GUI.

Now, I can dock and undock my laptop without losing all SSH connections. ☺

Was mit Holz

Wed, 06 Jun 2018 00:00:00 +0200

Ich habe die letzten beiden Wochenenden auch mal #WasMitHolz gemacht: Einen Wickelkommoden-Aufsatz! Den Plan hatte ich gefasst, sobald klar wurde, dass wir eine Wickelkommode brauchen und keine Kommode passender Höhe haben. „Der Plan“ sah dabei so aus:

Hochprofessionelle Skizze der Konstruktion

Ich habe mich davor gedrückt, irgendetwas selbst sägen zu müssen, da ich weder Werkbank noch vernünftige Säge besitze. Die Platten wurden also alle bereits im Baumarkt passend zugesägt. Also… alle bis auf eine, da ich leider das „2×“ in der Liste geflissentlich ignoriert habe. Also sah das Projekt nach dem ersten Anlauf erst mal nur so aus:

Work in Progress…

Eine Woche später hatte ich auch die fehlende Platte (und etwas Zubehör vom Schweden) und konnte das Ganze fertigstellen:

Fertiger Aufsatz

My Multi-Room Music Setup

Sat, 07 Apr 2018 00:00:00 +0200

For much too long, I wanted to write about how I completely overhauled our multi-room audio setup at home about a year ago.

Previously, the setup was as follows: We had four sets of speakers, distributed in the different rooms of our apartment, and they were all connected to the HP Microserver that played the music using MPD and Pulseaudio via a copper cable and a USB DAC. The obvious downside to this approach is its lack of scalability: Each room required a dedicated cable to the server, and the 7.1 USB DAC that I tricked into playing the same stereo stream on every of its four mini jack plugs. The less obvious downside is the lack of surge protection on copper audio cables.

So when I decided to move the server to another place in the apartment and equip it with a UPS (and thus surge protection, on the power line as well as on the Ethernet side), I was looking for a new solution. The main requirement was synchronicity: While standing in the hallway, I want to have exactly synchronous audio from all rooms. That’s what Pulseaudio was for in the old setup, as I couldn’t get ALSA to do the job well enough.

Secondly, to achieve surge protection on all wires towards the server, it seemed like a good idea to use something Ethernet-based (obviously requiring some playing device in every room).

Enter Snapcast. In a traditional server-client architecture, this little piece of software offers exactly that: Streaming time-synchronized audio from a FIFO on the server to multiple clients’ speakers. The performance is topped off by an Android app that can be used as both, a client and a remote control for the various volume levels. And with the buffers all tuned to low, the delay when starting and stopping music is only minimal.

Dusting off some old Raspberry Pis model B, the (far from hi-fi) playback hardware was settled. But because I don’t want to update a couple of Raspbians every day for no apparent reason (remember, they run a single daemon in a sealed off network and only every connect to my own server), I went ahead and toyed around with Buildroot and its Snapcast-addon SnapOS. And for a software guy like myself, that’s where the real fun began: How fast can I get the Pis to play music after powering them up? Or, as next best optimization goal: How small can I get the image?

Well, I won’t say that I’ve attained the optimum, but I’m satisfied by the current solution: My snapcast satellite configuration (currently) produces a 1.1 MiB kernel (XZ compressed) and a 3.9 MiB initramfs (uncompressed) that takes around 15 seconds to boot and play music, fetching all its configuration (network details, hostname, NTP and Snapcast servers) via DHCP. Only my SSH key is “hardcoded”.

So two of the rooms now have Rasberry Pis for playback, the workroom uses my laptop and – what I like most – the living room the Amazon FireTV (the Android app also is a client, remember?).

I was a bit disappointed that I actually needed wired Ethernet for decent synchronicity, but for some reason I couldn’t get a satisfactory result using Wifi links. Oh well.

GPG attacks

Sun, 27 Aug 2017 00:00:00 +0200

While communicating with the CCC office, I was informed that they couldn’t send me GPG encrypted mails because of the error “GPGME: Ambiguous name”. Of course there is more than one key if you search for my mail address (I had other keys in the past), but they also quoted my correct key ID.

Well, turns out the GPG key ID collisions that were in the news last year also caught my key. While the key with id 0xB17F2106D8CCEC27 really is mine (as I also state on my keys page), the fake one with long ID 0x5AAD3FC3D8CCEC27 (notice the identical last eigth characters) has many of the correct parameters that are mentioned in the article:

It has the correct primary user ID.
It is signed by some other fake keys that correspond to real keys that signed my real key (like CACert).

However, it also lacks some details:

It doesn’t have any secondary user IDs.
It has the wrong creation time.
Its signatures never expire. CACert only ever signs for one year.
And of course, it’s revoked, as it was created by researchers.

All in all, I guess I should be proud that apparently, I’m part of the GPG strong set (as suggested by the article) and surprised that the CCC office considers revoked keys.