News from German OSM Carto style

Back in June 2017 the OpenStreetMap Carto style (which German style is based on) finaly made the change to a hstore based PostgreSQL backend (a key value store, well suited for OSM tags).

I have been using hstore in German style for many years now and went even further by eliminating all columns in the database tables which represent an individual key.

Unfortunately upstream still uses columns for the most common keys used in OSM tagging.

Especially the decision to keep name in a different column than localized names (name:* tags are kept in hstore) is not well suited for localization, one of the main features of German style.

For this reason German style still uses a slightly different database schema which can however be made fully compatible to upstream using the database views available in our Github repository.

At Karlsruhe Hack Weekend in October I also updated the l10n code to make it possible to use them with an unaltered upstream database schema as an alternative. See l10 repository on Github for details.

I still recommend using using the German style schema though.

The Github repository does also contain a l10n only branch of Openstreetmap Carto which is an exact copy of upstream with the notable exception of localized labels in any desired latin character based language.

Because of the new Lua based transformation functions that upstream uses since Carto 4.x (the hstore based branch) I had to do a database reimport on our German tileserver as well, despite the fact, that I have been using hstore ever since.

I took the chance to go for --hstore option instead of --hstore-match-only which will allow for rendering of any tag used in osm, as exotic it will be. One example of such a thing is the now active rendering of the golf tag taken from french carto style (see screenshot above).

A few other changes include the adaption of road colors to be more close to the ones used in upstream and a few minor improvements like rendering of the infamous Dönertier instead of Hamburgers on Döner fast-food restaurants very common in Germany (see screenshot below).

I still hope to get one or two people to support maintenance of this fork as keeping it current with upstream will always require a little bit of work! Please contact me if you like to help.

At the time of writing http://tile.openstreetmap.de/ is in sync to the current version of upstream Carto style which is v4.4.0.

A Matrix Keypad on a Raspberry Pi done right

There are quite a few articles to be found on the Internet on how to use a matrix keyboard on a Raspberry Pi.

Surprisingly none of them seems to use the method documented here.

Instead most of them seem to use some handcrafted Raspberry Pi and python-only solution with debounce logic implemented in userland.

As with my article on Setting up a GPIO-Button “keyboard” on a Raspberry Pi this uses a device tree based approach and will not require any driver code in userland.

As with the solution above an application will be able to use this keyboard just in the same way as any other keyboard (e.g. a standard USB keyboard) connected to a computer running Linux.

So here is how to do it:

Unfortunately, at the time of writing, the standard kernel of Raspbian does not include the required driver. I already filed a bug on GitHub, so this might change in future.

For now we need to build our own kernel.

To build the required driver module call make menuconfig after make XXXXXX_defconfig and enable CONFIG_KEYBOARD_MATRIX

matrix-keypad

After booting this kernel modinfo matrix-keypad should show you something like this:

pi@raspberrypi:~$ sudo modinfo matrix-keypad
alias:          platform:matrix-keypad
license:        GPL v2
description:    GPIO Driven Matrix Keypad Driver
author:         Marek Vasut 
srcversion:     54E6656500995BD553F6CA4
alias:          of:N*T*Cgpio-matrix-keypadC*
alias:          of:N*T*Cgpio-matrix-keypad
depends:        matrix-keymap
intree:         Y
vermagic:       4.9.35+ mod_unload modversions ARMv6 p2v8 

To enable the driver we need to create a device tree overlay file suitable for a given matrix keyboard.

As an example I use the following device available at your favorite china shop.

4x5matrix

Here is what the corresponding device tree overlay file 4x5matrix.dts looks like:

    /dts-v1/;
    /plugin/;
    / {
           compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

           fragment@0 {
              target-path = "/";
              __overlay__ {
                 keypad: MATRIX4x5 {
                    compatible = "gpio-matrix-keypad";
                    debounce-delay-ms = <10>;
                    col-scan-delay-us = <10>;
                    /* 
		       try to use GPIO only lines
                       to keep SPI and I2C usable
                    */
                    row-gpios = <&gpio 27 0    // 1
                                 &gpio 22 0    // 2
                                 &gpio 10 0    // 3
                                 &gpio 9 0>;   // 4

                    col-gpios = <&gpio 13 0    // 5
                                 &gpio 26 0    // 6
                                 &gpio 16 0    // 7
                                 &gpio 20 0    // 8
                                 &gpio 21 0>;  // 9
                    /*
                      Keycodes from /usr/include/linux/input-event-codes.h
                      converted to hex using printf '%02x\n'
                    */

                    linux,keymap = <
                                    // col0 row0 KEY_LEFT
                                    0x00000069
                                    // col0 row1 KEY_KP0
                                    0x01000052
                                    // col0 row2 KEY_RIGHT
                                    0x0200006a
                                    // col0 row3 KEY_KPENTER
                                    0x03000060
				    // col1 row0 KEY_KP7
                                    0x00010047
                                    // col1 row1 KEY_KP8
                                    0x01010048
                                    // col1 row2 KEY_KP9
                                    0x02010049
                                    // col1 row3 KEY_ESC
                                    0x03010001
                                    // col2 row0 KEY_KP4
                                    0x0002004b
                                    // col2 row1 KEY_KP5
                                    0x0102004c
                                    // col2 row2 KEY_KP6
                                    0x0202004d
                                    // col2 row3 KEY_DOWN
                                    0x0302006c
                                    // col3 row0 KEY_KP1
                                    0x0003004f
                                    // col3 row1 KEY_KP2
                                    0x01030050
                                    // col3 row2 KEY_KP3
                                    0x02030051
                                    // col3 row3 KEY_UP
                                    0x03030067
                                    // col4 row0 KEY_F1
                                    0x0004003b
                                    // col4 row1 KEY_F2
                                    0x0104003c
                                    // col4 row2 KEY_KPSLASH there is no KP_#
                                    0x02040062
                                    // col4 row3 KEY_KPASTERISK
                                    0x03040037>;

                 };
              };
           };
      };

Further documentation can be found in the file Documentation/devicetree/bindings/input/matrix-keymap.txt inside the Linux kernel source tree. Feel free to ask if it does not work for you.

Now to enable our keyboard there are only four steps left:

  1. Connect the keyboard to the GPIO lines as defined in the dts file
  2. Compile the dts file to the binary dtbo format. This is done using the device tree compiler of your kernel tree:
    ./scripts/dtc/dtc -W no-unit_address_vs_reg -I dts -O dtb -o 4x5matrix.dtbo 4x5matrix.dts
    
  3. Copy the resulting dtbo file to /boot/overlays/4x5matrix.dtbo on the Raspberry Pi
  4. Add the following to /boot/config.txt:
    dtoverlay=4x5matrix
    

Now after rebooting the Pi the lsinput command should show us a new keyboard connected to the device. You may need to install a package called input-utils first if this command ist not available on your Pi.

Here is what this looks like after pressing the Enter Key on the matrix keyboard:

pi@raspberrypi:~$ sudo -s
root@raspberrypi:~# lsinput
/dev/input/event0
   bustype : BUS_HOST
   vendor  : 0x0
   product : 0x0
   version : 0
   name    : "MATRIX4x5"
   bits ev : EV_SYN EV_KEY EV_MSC EV_REP

root@raspberrypi:~# input-events 0
/dev/input/event0
   bustype : BUS_HOST
   vendor  : 0x0
   product : 0x0
   version : 0
   name    : "MATRIX4x5"
   bits ev : EV_SYN EV_KEY EV_MSC EV_REP

waiting for events
19:56:28.727096: EV_MSC MSC_SCAN 24
19:56:28.727096: EV_KEY KEY_KPENTER (0x60) pressed
19:56:28.727096: EV_SYN code=0 value=0
19:56:28.797104: EV_MSC MSC_SCAN 24
19:56:28.797104: EV_KEY KEY_KPENTER (0x60) released
19:56:28.797104: EV_SYN code=0 value=0

Happy hacking!

Craft-Bier Freunde als Lobbyisten für Einwegdosen?

Als eines der wenigen Länder in Europa hat Deutschland ein bis heute immer noch relativ gut funktionierendes Mehrwegsystem für Getränkeflaschen.

Dessen Totengräber waren bisher ja eher nicht die kleinen Brauereien, die üblicherweise in Standardflaschen abfüllen, sondern jene, die auf Spezialflaschen umgestellt haben um ihr Markenprofil zu schärfen.

Nun ist das traditionelle Feindbild bei Bier-Nerds ja eigentlich recht klar. Kleine Brauereien gelten als Cool, Ableger der Großkonzerne eher nicht 🙂

Daher finde ich es umso erstaunlicher, dass derzeit gerade in diesem Umfeld ein bemerkenswerter Lobbyismus zu Lasten der einheitlichen Mehrwegflasche entsteht.

Dieser Artikel entsteht, weil ich mir am Wochenende in einer örtlichen Craftbeer-Bar entsprechende “Argumente” anhören musste.

Außerdem hat die Fachzeitschrift “Meiningers CRAFT” kürzlich einen ähnlich einseitigen Artikel (leider nicht online) veröffentlicht, den man ebenfalls nicht unwidersprochen stehen lassen sollte.

Auch die Karlsruher Bierblogger von Hoptimizer blasen ins selbe Horn.

Einer der Gründe für dieses “Dosenfreundliche” Umfeld ist vermutlich die Tatsache, dass die USA beim Thema als Vorbild gelten. Was dort richtig ist kann ja bei uns nicht falsch sein!

Die obejktive Antwort fällt aber trotzdem ziemlich eindeutig aus. Die Getränkedose ergibt aus umweltpolitischer Sicht keinen Sinn für den (räumlich relativ kleinen) deutschen Markt.

Im Export sieht das sicher anders aus, denn dort gibt es kein Mehrwegsystem und man kann schon froh sein, wenn das jeweilige Verpackungsmaterial der stofflichen Wiederverwendung zugeführt wird.

Nun noch ein paar Widerworte zu den vermeintlich guten Argumenten, die die Befürworter von Dosen für sich verbuchen.

Ich werde im folgenden die 0,33l Longneck Flasche als Vergleichsobjekt verwenden, da sich diese im deutschen “Craft-Bier” Umfeld als Defakto-Standard durchgesetzt hat.

Nehmen wir an ich würde Bier in solchen Flaschen bei einer Brauerei in Hamburg bestellen und mir diese nach Südwestdeutschland liefern lassen. Die Flaschen müssen also rund 600km zurücklegen, bis sie hier in Karlsruhe ankommen. Das stellt innerhalb Deutschlands in etwa den worst-case dar. Im Vergleich zu den USA, wo diese Entfernung schon mal das achtfache betragen kann, nicht ganz unerheblich. Mal ganz abgesehen davon, dass es in den USA kein herstellerunabhängiges Mehrwegsystem gibt.

Fakt ist zudem, dass die Flasche aus meinem Beispiel zur erneuten Befüllung normalerweise eben gerade nicht zurück nach Hamburg muss! Viel wahrscheinlicher ist stattdessen, dass die Flasche hier in Karlsruhe z.B. mit Hoepfner Pilsener, welches die selben Flaschen verwendet, neu befüllt wird.

Mission accomplished! So sieht ein funktionierendes Mehrwegsystem aus.

Bei Bier, das hier aus dem Südwesten stammt, wie z.B. das vom Hopfenstopfer aus Bad Rappenau, ist die Ökobilanz selbstredend noch erheblich besser.

Der vermeintliche Vorteil der Getränkedose greift also nur im Vergleich zu Einwegflaschen, die schwerer sind als Dosen und dadurch bei weiten Transportwegen im Nachteil.

Für Mehrwegflaschen ist die Ökobilanz durch die Widerbefüllung selbst bei diesen Entfernungen günstiger. Details hierzu kann der geneigte Leser bei der deutschen Umwelthilfe nachlesen.

Auch das zweite Argument für die Dose, dass diese die Qualität vermeintlich länger hält kann man so nur bedingt stehen lassen.

Klar ist UV-Strahlung den Geschmack abträglich, aber davor schützt die braue Farbe der Mehrwegflaschen ebenfalls hinreichend.

Falls das so ein wichtiges Argument wäre müssten die Brauereien, die in Dosen füllen noch viel dringender über eine geschlossene Kühlkette bis zum Verbraucher nachdenken.

Ein Konzept im übrigen, welches Braufaktum AFAIK als einizger Hersteller konsequent durchzieht.

Positiv erwähnen möchte ich an dieser Stelle noch die Brooklyn Brewery, die ihr Bier in Deutschland über ihren Vertriebspartner in 0,33l Longneck Mehrwegflaschen abfüllen lässt.

Setting up a GPIO-Button “keyboard” on a Raspberry Pi

Back in late 2013, when I wrote the first Version of a raspberry-pi based software controlling a HD44780 based 4×20 characters LCD and 4 input buttons I started querying the buttons using the generic GPIO driver included in Raspbian and its sysfs interface.

However, this has a couple of drawbacks. First of all it is hardly portable to other Linux based hardware and one has to do a lot of stuff like debouncing on the application level.

Fast forward to early 2017. Raspbian now uses a device-tree based approach for system setup and a driver called gpio-keys is readily available in its standard kernel.

However, as it is often the case in the Free Software world, the documentation of this driver is limited to some README files included in the Linux kernel and some discussions scattered all around the web.

Linux already has drivers for almost all of the common low level peripheral interfaces like I2C, SPI, OneWire, hardware PWM and generic GPIO. It is usually the better approach to use them instead of constantly re-inventing the wheel.

So here is my quick guide for setting up a “keyboard” made up from a couple of buttons connected via GPIO ports as shown in the image.

gpio-keys

While this has currently only been tested on Raspberry Pi, it will likely also work on other Linux based boards with device tree enabled (e.g Beaglebone and others).

Keyboards in modern Linux Kernels are presented to userland as a so called input event device. To inspect them I would recommend the installation of the evtest and input-utils packages on Debian/Ubuntu based distributions. The lsinput command (run as root) shows which ones are available on a system.

So, what do we need to do to make a keyboard from our GPIO connected push-buttons?

The missing link between the gpio-keys driver and the setup of the actual GPIO ports, where the buttons are connected to, is a so called device-tree (DT) overlay.

While DT itself is a data structure for describing hardware, a DT overlay is something a user can put in place to change such a hardware description in a way which matches the actual application scenario (like buttons, buses etc. connected to the device).

So let’s build such an overlay for the four buttons shown in our schematic above.
The Documentation available at raspberrypi.org provides some clues about device tree overlays as well.

Here is the final result which works, so let’s go into the details:

    /dts-v1/;
    /plugin/;
    / {
       compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
       
       fragment@0 {
          target-path = "/";
          __overlay__ {
             keypad: breadboard_keys {
                compatible = "gpio-keys";
                #address-cells = <1>;
                #size-cells = <0>;
		autorepeat;
                button@22 {
                   label = "breadboard Menu";
                   linux,code = <28>;
                   gpios = <&gpio 22 1>;
                };
                button@10 {
                   label = "breadboard down";
                   linux,code = <108>;
                   gpios = <&gpio 10 1>;
                };
                button@9 {
                   label = "breadboard up";
                   linux,code = <103>;
                   gpios = <&gpio 9 1>;
                };
                button@11 {
                   label = "breadboard enter";
                   linux,code = <14>;
                   gpios = <&gpio 11 1>;
                };
             };
          };
       };
    };

Our overlay fragment contains a keypad called breadboard_keys. This is actually the string which lsinput will show as the actual name of our input device. 11, 10, 9 and 11 are the GPIO port numbers corresponding to the green wires in our schematic.

The file gpio-keys.txt from the Linux Kernel source-tree will show us what our four button definitions need to look like. We need a label, which is arbitrary text, a linux,code which is actually a keycode as defined in /usr/include/linux/input-event-codes.h and we need a gpio definition with two options, the number of the GPIO to use and a boolean value indicating if the button is active low (1, as in our case) or active high (0).

Another thing I would like to point at is the autorepeat keyword. If given this will activate a key-press repeat behavior known from ordinary keyboards. The production of key-press-events will be repeated as long as the button is pressed.

Now how to enable this overlay on Raspberry Pi?
Very simple, once you know how 🙂

First put the above code in a file e.g. breadboard.dts.

Then compile a binary version and put it into the right place:
dtc -I dts -O dtb -o /boot/overlays/breadboard.dtbo breadboard.dts

Finally the following line must be added to /boot/config.txt:
dtoverlay=breadboard

Now we are done.

Here is how this looks like on the software side without any other input devices like keyboards connected:

root@raspberrypi:~# lsinput
/dev/input/event0
   bustype : BUS_HOST
   vendor  : 0x1
   product : 0x1
   version : 256
   name    : "breadboard_keys"
   phys    : "gpio-keys/input0"
   bits ev : EV_SYN EV_KEY EV_REP

root@raspberrypi:~# input-events 0
/dev/input/event0
   bustype : BUS_HOST
   vendor  : 0x1
   product : 0x1
   version : 256
   name    : "breadboard_keys"
   phys    : "gpio-keys/input0"
   bits ev : EV_SYN EV_KEY EV_REP

waiting for events
20:00:23.629190: EV_KEY KEY_BACKSPACE (0xe) pressed
20:00:23.629190: EV_SYN code=0 value=0
20:00:23.749163: EV_KEY KEY_BACKSPACE (0xe) released
20:00:23.749163: EV_SYN code=0 value=0
20:00:23.969176: EV_KEY KEY_DOWN (0x6c) pressed
20:00:23.969176: EV_SYN code=0 value=0
20:00:24.099151: EV_KEY KEY_DOWN (0x6c) released
20:00:24.099151: EV_SYN code=0 value=0
20:00:24.329158: EV_KEY KEY_UP (0x67) pressed
20:00:24.329158: EV_SYN code=0 value=0
20:00:24.439154: EV_KEY KEY_UP (0x67) released
20:00:24.439154: EV_SYN code=0 value=0
20:00:24.669157: EV_KEY KEY_ENTER (0x1c) pressed
20:00:24.669157: EV_SYN code=0 value=0
20:00:24.759176: EV_KEY KEY_ENTER (0x1c) released
20:00:24.759176: EV_SYN code=0 value=0
root@raspberrypi:~# grep breadboard /sys/kernel/debug/gpio
 gpio-9   (                    |breadboard up       ) in  hi    
 gpio-10  (                    |breadboard down     ) in  hi    
 gpio-11  (                    |breadboard enter    ) in  hi    
 gpio-22  (                    |breadboard Menu     ) in  hi    

Finally something which is not strictly on-topic concerning this post. There is something one should know about keyboard like input event devices like this. Pressing a button will send events to all applications normally consuming them (e.g. applications running on Linux console or X-Window system).

This might be an unwanted behavior. If so, your application software needs to issue a EVIOCGRAB ioctl after opening the input device.

Die “Outdoor-Bier” Verkostung

Dank dem Basislager, unserem umtriebigen Karlsruher Outdoor-Laden, habe ich nun, nachdem es das Zeug in den USA schon zwei Jahre lang gibt, endlich auch in Deutschland so ein Outdoor-Bier von Pat’s Backcountry Beverages in die Finger gekriegt.

Weil ich zusammen mit meinem Hobbybrauer-Kollegen ohnehin am Verkosten unserer letzten selbstgebrauten Sude war haben wir deren PALE RALE mal dazu genommen:

Mit einem halben Liter Sprudelwasser gemischt und im Teku-Glas verkostet 🙂

Nachdem ich bisher meist eher positive Kritiken gelesen hatte kommt nun aber eine negative 🙁 Zumindest das PALE RALE geht gar nicht! Das schmeckt nach allem möglichen aber nicht nach Bier und ich behaupte, dass ich ungefähr weiß, wie ein Pale-Ale schmecken sollte. Ein Haltbarkeitsdatum habe ich leider keines gefunden. Die Prägung 1013 auf der Packung ist hoffentlich eine Losnummer und kein Datum.

Nun lässt sich Geschmack schwer beschreiben, aber ich versuche es trotzdem mal.

Sowohl der Geschmack des Mineralwassers (Kohlensäure) als auch des Ethanols treten IMO zu deutlich hervor. Der malzige Geschmacksanteil erinnert (wohl auch deshalb) eher an einen Malzlikör als an ein Bier.

Durchaus ähnlich vom Geschmack her findet sich in meiner Erinnerung eigentlich nur der Irish-Mist Likör, von dem wir zum direkten Vergleich natürlich keinen da hatten.

Das Black IPA werde ich aus reiner Neugier vielleicht auch noch irgendwann einmal probieren. Insbesondere weil ich die Hoffnung habe, dass die Röstmalzaromen eventuell den Ethanolgeschmack etwas dämpfen.

Fazit: Zu diesem obskuren bierähnlichen Getränk gibt es aus meiner Sicht bessere (auch alkoholische) Alternativen für den Abend am Lagerfeuer. Spontan würde mir ganz Old School ein Tee mit Rum einfallen. Oder man besorgt sich die Karbonisierungsflasche von Backcountry Beverages und mixt sich einen Wodka Lemon oder Jackie Cola.

Categories:

icinga2 CheckCommand definition for calling a plugin with non-option arguments

Sometimes in my work as a Linux system adminstrator I come up with a solution which can not be found using Google, the all-knowing Trash Heap.

In this case I usually end up digging for the solution myself and sometimes I like to share them rather than documenting them only in house.

This way at least in future others will be able to google them 🙂

So here we go:

The most significant difference in icinga2 is the, arguably more clearly arranged, config file syntax.
Fortunately the actual tests from nagios/icinga1 can be used unmodified. However an appropriate CheckCommand definition is needed.

To create it for his custom tests or those tests which are not yet part of the official distribution an administrator need to create it from scratch or by means of copying and modifying another one.

In my case this has been proven to be quite easy with just one exeption. I have somne tests which require something that Unix slang usually calls non-options arguments.

What does this mean? Well a popular example of this kind of command would be git. Given the command git commit -a the term commit would be the non option argument.

So here is what a CheckCommand definition for this command would look like. Of course this does not make sense as an icinga test and can not be actually used.

object CheckCommand "git" {
	import "plugin-check-command"
	import "ipv4-or-ipv6"

	command = [ PluginContribDir + "/check_git" ]

	arguments = {
		# nonopt is the non option argument
		"nonopt" = {
			value = "$git_command$"
			skip_key = true
			order = 1
			required = true
		}
		"-a" = {
			value = "$git_all$"
			description = "commit all"
		}
	}
}

Die Wahrheit über das “Reinheitsgebot” zum Tag des deutschen Bieres

Als wir vor vielen Jahren angefangen haben selbst Bier zu brauen war mein Glaube an das Reinheitsgebot kindlich naiv und ungebrochen.

Heute bin ich mir da nicht mehr so sicher, denn das was heute Reinheitsgebot genannt wird hat mit der Vorschrift von 1516 eigentlich kaum noch etwas gemein. Die Vorschrift von 1516 selbst ist im historischen Kontext interessant und war damals relativ sinnvoll, heute ist sie das ganz bestimmt nicht mehr.

Im folgenden poste ich hier mal eine Tabelle, was heute so alles als Zutat in Bier, das angeblich nach dem Reinheitsgebot von 1516 gebraut wurde, erlaubt ist. Verarbeitete Versionen einer Zutat gelten aus meiner Sicht als erlaubt. Nach dem Sinn darf man da bei so mancher Vorschrift nicht fragen.

Wer die aktuell gültige Vorschrift selbst lesen möchte kann das bei Gesetze im Internet tun.

Zutat

Originalvorschrift von 1516

Heutige Vorschrift (2015)

Wasser

OK

OK

Hopfen

OK

OK

Hopfenextrakt

unbekannt

OK, lassen wir mal als verarbeiteten Hopfen gelten.

Malz

Nur aus Gerste

Aus jedem Getreide im obergärigen Bier,
im untergärigen Bier ist nur Gerstenmalz erlaubt!

Hefe

unbekannt, aber als “Zeug” verwendet

OK

Getreide (unvermälzt)

Nur Gerste.
Die Bezeichnung “Malz” kommt im Originaltext nicht vor.

Nicht erlaubt

Zucker

Nein

Im obergärigen Bier erlaubt

Polyvinylpolypyrrolidon (PVPP)

unbekannt 🙂

Im Prozess erlaubt, weil nicht im fertigen Bier enthalten.

Färbebier

unbekannt 🙂

Färbebier ist ein nahezu vollständig aus Röstmalzen gebrautes Pseudo-Bier, dem die Bitterstoffe die bei der Röstung enstehen entzogen wurden. Die Firma Weyermann vertreibt ein solches “Bier” unter der Bezeichnung Sinamar. Die Zugabe ist erlaubt.

Gewürze

nein, aber schon 35 Jahre später wurde Kori­an­der und Lor­beer wieder erlaubt.

nein

Zum Schluss noch ein paar Worte zum Wasser. Da steht oben in beiden Spalten lapidar OK. Heute wird aber kaum noch von einer industriellen Brauerei einfach Wasser aus der Leitung, der eigenen Quelle oder Brunnen verwendet. Stattdessen wird aufbereitet was das Zeug hält. Ist ja noch kein Bier, kann man also alles machen, was lebensmittelrechtlich zulässig ist.

Mein Fazit:

Die Zugabe von Sinamar finde ich grenzwertig. PVPP geht gar nicht. Zucker ist mir zumindest unsympatisch, dafür gibt es Malz.

Andererseits finde ich die Zugabe natürlicher Gewürze, die Verwendung unvermälzter Getreide und Früchte in Ordnung.

Das ist dann so ungefähr das, was in unser selbstgebrautes Bier rein darf 🙂

Categories:

India Pale Ale (IPA) und Co. in Karlsruhe reloaded

Seit ich vor fast 3 Jahren meinen Artikel über IPA’s in Karlsruhe geschrieben habe ist in der deutschen Bierlandschaft und natürlich auch im Raum Karlsruhe einiges passiert. Es wird also Zeit für eine Fortsetzung.

Vorweg noch eine Begriffserklärung für diejenigen Leser, die mit den Begriffen Kalthopfung bzw. Hopfenstopfen nichts anfangen können. Die Wikipedia hat einen (nicht wirklich guten) Artikel dazu. Ich selbst mag den Begriff Kalthopfung lieber als Hopfenstopfen. Im englischen Sprachraum wird die Methode meist als “dry hopping” bezeichnet.

Im folgenden also eine Liste von Ereignissen und Fakten aus diesem Umfeld mit besonderem Fokus auf die Region Karlsruhe. Wer weitere Infos hat möge diese bitte in die Kommentare schreiben.

  • Deutsche Brauereien beginnen den Trend aus den USA zum “craft beer” langsam aufzunehmen. Darüber, dass dieser Begriff zu deutschem Bier aber nicht so recht passt habe ich einen ausführlichen Blogpost geschrieben.
  • Der Vogelbräu hat im Jahre 2013 ein schönes kaltgehopftes IPA als Saisonbier gebraut, das leider ziemlich teuer war. Die lange Lagerung wäre aus meiner Sicht nicht wirklich notwendig gewesen, dann wäre es vielleicht auch etwas preiswerter geworden.
  • Nicht in Karlsruhe, aber gar nicht so weit weg in Bad Rappenau braut der Hopfenstopfer schöne innovative Biere.
  • Auch wir selbst haben inzwischen schon mehrere gestopfte Biere gebraut, die im Bekanntenkreis sehr gut angekommen sind.
  • Zur Fußball WM 2014 und erneut im Juni 2015 hat Der Vogelbräu das kaltgehopfte untergärige “Samba Bier” gebraut, das mir recht gut geschmeckt hat. Für meinen Geschmack hätte die Kalthopfung ruhig deutlich ausgeprägter sein dürfen.
  • Der Oxford Pub hat die vermutlich beste Bierkarte der Stadt.
  • Der zugehörige Oxford Shop verkauft viele dieser Biere auch für daheim, ist aber leider relativ teuer.
  • Die Brauerei Ketterer aus Pforzheim braut mehre kaltgehopfte Ales als Saisonbiere, die man oft im kleinen Ketterer am Lidelplatz trinken kann
  • Die meisten Karlsruher Getränkemärkte haben keine solchen Biere im Programm. Bisher gibt es nicht eimal die Biere aus der Region (Ketterer, Hopfenstopfer)
  • Die Brauerei Schneider aus Kehlheim braut zwei interessante kaltgehopfte Weizenbiere, das TAP4 und das TAP5. Beide Biere sind bei Getränke Melter in Eggenstein erhältlich.
  • Die Biomarktkette Alnatura verkauft den Riedenburger Doldensud in Ihren Filialen.
  • Vom 25.-26. April findet in Heilbronn die Messe Artbrau statt, auf der innovativen Brauereien aus der weiteren Region vertreten sind.
  • Deutschlandweit gibt es nun mehrere Verbrauchermessen, die sich dem Thema Bier widmen. Die bekannteste ist wohl die Braukunst Live in München.

Update 8.6.:

  • Vergessen habe ich die Braufaktum Kühschränke bei Real und Scheck-In. Da die Firma zu Radeberger gehört sind die natürlich zu Recht umstritten.
  • Die neuen Sorten von Beck’s gibts zwar auch fast überall. IMO können die aber nix.
  • Getränke Schorpp in Bulach verkauft das Distelhäuser Blond zum normalen Kistenpreis. Die drei “Craft” Sorten aber leider nocht nicht.
Categories:

Warum der Begriff “Craft-Beer” keine gute Bezeichnung für deutsches Bier ist

Eines gleich vorneweg, ich bin ein großer Freund der neuen Vielfalt in der Bierlandschaft und begeisterter Konsument kaltgehopfter Biere.

Mehr noch, ich braue solche Biere zusammen mit meinen Freunden sogar sebst.

Was mir jedoch nicht so recht gefällt ist die Bezeichnung “Craft-Beer”.

Einerseits, handelt es sich mal wieder um einen unnötigen Anglizismus und andererseits, passt seine ursprüngliche Bedeutung nicht so recht in die deutsche Brauereilandschaft.

Gemeint sind damit nämlich Brauereien, die sich in der Abgrenzung zum industriell hergestellten Bier als Brau-Handwerker verstehen. Eine solche Abgrenzung ist in den USA, wo es bis vor rund 20 Jahren ja fast ausschließlich ersteres gab, auch sinnvoll. Man muss schmunzelnd an den Spruch von Oscar Wilde denken: “I find American beer a bit like having sex in a canoe. It’s fucking close to water.”

In Deutschland ist das aber auch heute trotz Radeberger und Co. immer noch deutlich anders, auch wenn unsere Fernsehbiere auf dem besten Weg in Richtung Budweiser und Co. sind.

Zurück zur Bezeichnung “Craft-Beer”. Bei vermutlich 90% der deutschen Brauereien und mit Sicherheit bei 99% der Oberfränkischen handelt es sich nach der amerikanischen Definition um lupenreine Craft-Breweries.

Das Bier das man dort findet ist aber halt (von wenigen Ausnahmen abgesehen) kein (I)PA und auch nicht hopfengestopft.

Was machen wir jetzt?

Den oberfränkischen Brauereien ihr Handwerk abzusprechen wäre schlichtweg eine Frechheit! Im Gegenteil, die untergärigen Kellerbiere fränkischer Brauart sind meistens hervorragend.

Mein Vorschlag:
Wir begraben den Begriff “Craft-Beer” im deutschsprachigen Raum, denn das deutsche handwerklich gebraute Bier braucht sich nicht zu verstecken, auch wenn es sich meist nicht um kaltgehopftes Obergäriges handelt.

Lasst uns lieber von innovativen Brauereien sprechen, denn davon gibt es zum Glück wieder mehr 🙂

Categories:

Das wartungsarme Fahrrad

Von Fahrrädern, die zwar technisch möglich sind, die man sich aber nicht kaufen kann

Vor nun fast mehr als 9 Jahren habe ich mein damaliges Fahrrad mit Shimano 21 Gang Kettenschaltung (einer Bauart, die es heute gar nicht mehr gibt) aufgrund schlechter Ganzjahrestauglichkeit ersetzt.

Der Nachfolger war ein Fahrrad mit einer vergleichsweise teuren Rohloff 14-Gang Nabenschaltung in der Hoffnung nun endlich mal ein wartungsarmes Fahrrad zu erwerben.

Letzteres war und ist für mich überaus wichtig, weil ich kein Auto besitze und das Fahrrad daher 24 Stunden am Tag, 7 Tage die Woche und 365 Tage im Jahr einfach funktionieren muss.

Die Entwicklung bei Kettenschaltungen hin zu immer mehr Gängen und noch weniger robusten Ritzeln mit mehr als 7 Kettenblättern hat meine Entscheidung für die Nabenschaltung ja eigentlich bestätigt, wären da nicht ein paar völlig blödsinnige Tatsachen, die die Rohloff Schaltung in letzter Konsequenz dann doch für wartungsarme Fahrräder untauglich erscheinen lassen.

Worum geht es?

Verbleibender Schwachpunkt bei meinem Rad ist die Kette und da gäbe es aus meiner Sicht zwei Lösungen:

  • Ersatz der Schaltungskette durch einen ungekapselten Riemenantrieb
  • Ersatz der Schaltungskette durch eine breite Kette und eine brauchbare Kapselung

Beides wären gangbare Wege aber beide scheitern an unterschiedlichen Gründen. Technische Gründe sind das nicht und das beweist in meinen Augen, dass das Fahrrad selbst von den Fahrradherstellern immer noch nicht als alltagstaugliches Verkehrsmittel angesehen wird.

Die erste Lösung scheitert am Preis. Fahrräder mit Riemenantrieb aka Gates Carbon Drive erfordern leider Spezialrahmen und sind in Verbindung mit der ebenfalls sehr teuren Rohloff Nabenschaltung dann preislich aus meiner Sicht oberhalb der Schmerzgrenze.

Eine Nachrüstung an meinem Rad würde die Anschaffung eines neuen Rahmens bedeuten.

Die zweite Lösung ist das ärgerlichere Problem! Das wäre nämlich technisch preisgünstig ohne Spezialrahmen machbar, wird aber von den Teileherstellern nicht unterstützt. Vollverkleidungen für die Kette wie den Hebie Chainglider gibt es nämlich nur für Schaltungsketten und schlimmer noch, weder die Firma Rohloff noch die Hersteller der Kurbeln liefern breitere Ritzel, wie sie bei Verwendung einer breiteren Kette notwendig bzw. zumindest wünschenswert wären.

So habe ich mich also gerade eben wieder einmal darüber geärgert, dass ich am hinteren Ende der Spannmöglichkeit meiner Kette angelangt bin und nun eine neue wenig haltbare Schaltungskette kaufen muss, die ich eigentlich gar nicht mehr haben möchte.

Ich hoffe ich werde die Verfügbarkeit wartungsarmer Alltagsräder mit aktzeptablem Preis- Leistungsverhältnis noch erleben. An der Technik liegt das nämlich nicht. Vielleicht findet sich ja in den Weiten des Internets jemand mit einem ähnlichen Problem und einer genialen Lösung.

Am Schluß auch noch etwas positives! Mein Fahrrad verfügt über hydraulische Bremsen der Firma Magura. Diese haben meine Erwartungen bzgl. Wartungsarmut vollumfänglich erfüllt und sind aus meiner Sicht ihren vergleichsweise teuren Preis wert.