Keybow as a remote? Is KeybowOS mandatory?

Just seen the new Keybow, and I was wondering if it is mandatory to use of the KeybowOS, or if it can be used with a more general Raspbian (or similar) set-up?

Was just thinking that if it can be read via GPIO into python or such like, it could be a nice little set-up for a remote control style keypad to operate other stuff over wifi via JSON-RPC api’s or suchlike. For example being able to run a remote Volumio or Kodi set-up via their web APIs.

By the way - you’ve got a broken link in the 2nd tutorial (setting up) to the last one (macros & snippets) in the advanced section at the bottom. Looks like you’re missing a close bracket in the link set-up.

That likely depends on whether it uses i2c or an actual GPIO pin per button for button presses etc. You really need the Pinout to see what’s what and thats not up yet. New product so I’d say be patient and see what somebody from Pimoroni has to say. Or wait for somebody else to buy one. Won’t be me, I already spent all my Christmas budget on Arduino stuff. ;) Just posting to see what info comes here as I may eventually buy one.

The tutorials mention each button is linked to a specific individual GPIO pin, which is what got me wondering somewhat.

The question was mainly aimed at @sandyjmacdonald as the author of those tutorials and the knowledgable one about such matters ;)

Ok, sounds doable then. I just took a quick look see.

It’s all one-pin-per-button and a Python library will come eventually.

It’ll also have a dtoverlay, something like:


/ {
    compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

    fragment@0 {
        target = <&gpio>;
        __overlay__ {
            keybow_pins: keybow_pins {
                brcm,pins = <5 6 12 13 16 17 20 22 23 24 26 27>;
                brcm,function = <0>;
                brcm,pull = <2>;
    fragment@1 {
        target-path = "/";
        __overlay__ {
            gpio_keys: gpio_keys {
                compatible = "gpio-keys";
                pinctrl-names = "default";
                pinctrl-0 = <&keybow_pins>;
                status = "okay";

                key0: key0 {
                    label = "Key 0";
                    linux,code = <11>;
                    gpios = <&gpio 17 1>; 

                dot: dot {
                    label = "Dot";
                    linux,code = <52>;
                    gpios = <&gpio 27 1>;

                enter: enter {
                    label = "Enter";
                    linux,code = <28>;
                    gpios = <&gpio 23 1>;

                key1: key1 {
                    label = "Key 1";
                    linux,code = <2>;
                    gpios = <&gpio 22 1>;

                key2: key2 {
                    label = "Key 2";
                    linux,code = <3>;
                    gpios = <&gpio 24 1>;

                key3: key3 {
                    label = "Key 3";
                    linux,code = <4>;
                    gpios = <&gpio 5 1>;

                key4: key4 {
                    label = "Key 4";
                    linux,code = <5>;
                    gpios = <&gpio 6 1>;

                key5: key5 {
                    label = "Key 5";
                    linux,code = <6>;
                    gpios = <&gpio 12 1>;

                key6: key6 {
                    label = "Key 6";
                    linux,code = <7>;
                    gpios = <&gpio 13 1>;

                key7: key7 {
                    label = "Key 7";
                    linux,code = <8>;
                    gpios = <&gpio 20 1>;

                key8: key8 {
                    label = "Key 8";
                    linux,code = <9>;
                    gpios = <&gpio 16 1>;

                key9: key9 {
                    label = "Key 9";
                    linux,code = <10>;
                    gpios = <&gpio 26 1>;


    fragment@3 {
        target = <&i2s_pins>;
        __overlay__ {
            We cannot share BCM 20 between gpio keys (Left) and i2s (PCM_DIN)
            Assign PCM_DIN to the HAT EEPROM (ID_SD) pin which should be generally unused.
            brcm,pins = <18 19 0 21>;
            brcm,function = <4 4 0 4>;

Thanks Phil.

Will hang on and see what comes out then. Could be a fun little project, although arguably a touch on the expensive side perhaps (to get past she who holds the purse strings anyway).

Eek. Just seen this, Darren. The separate parts will be available to buy in the New Year. It’ll likely be the PCBs, switches, and key caps, and then you can add your own Pi.

I’ve fixed that link too. Thanks for the heads-up!

Just for perspective, here’s a little breakdown of the costs to get the parts separately:

Pi Zero WH: £13.02
Kailh Gold switches: £8.28 for 12 (from Mechbox UK)
Clear DSA key caps: £4.68 (from Mechbox UK)
USB cable: £2.50
Reusable box: £2.50

So (if my maths is correct) you’re getting the rest for £20.98: the two PCBs, mounting plate, and fixings. Decent value!

Thanks Sandy. It wasn’t the price vs cost of materials that was the concern, just the cost overall for a “tinker project”. Especially one that just replaces several existing control options with something all-in-one, but where the existing ones do work. Always a difficult sell to the management… ;-)

You’ll have to think of some indispensable uses for it that “the management” will approve of! :-D

1 Like

I’m reviving this thread, as i have the exact same idea.
I’d like to use my keybow as a remote keyboard / controller: press a key, and have it execute say a curl command to switch a source on my home cinema amplifier or pause a film in Kodi.

When i looked at the product page, the fact it came with a Raspberry Pi Zero W made me think the keybow would cleverly start its own wifi hotspot, let me connect to that, give it details of my home wifi and have it connect to that. And from then on, be able to assign macros to keys.

But in fact, as we know, KeybowOS is designed to make the rpi0w show up as a HID and, far from stupidly, a keyboard. I find that cool and clever too, and in a way kind of wish i wanted to use it that way. (It also shows i bought it without really reading the description well enough, but oh well).

But anyway, what is coming to mind right now in order to use the Keybow as a remote device, which only uses USB for power, is to slap a normal rpi0 OS on an SD card, pre-configure wifi (using wpa_supplicant.conf etc.), and then try to find and reuse as much of the code in KeybowOS that controls the GPIO communication with the keys, the LED control and the macros, as possible.

Any hints on doing that would be much appreciated.

Last question: if using the Keybow as originally intended (a USB-connected keypad), could one just swap out the Pi Zero W for a Pi Zero (the original, no wifi version)?

This was my goal right when I saw the KeyBow the first time. If someone is still looking for a solution, my python code is on github (GitHub - DFranzen/WiKeyBow: 12-Button fully programmable wireless Keyboard Firmware) with examples on how to configure it for TP-Link kasa, Tasmota, Philips Hue, squeezebox and even SSH/XDoTools.

Setup is as expected above: Install a Raspberry Pi OS on the SD-Card and then download and configure the python script as a service.

In case you’re still interested in this, check out Kiwi. It’s an Elixir/Nerves based firmware for the Pimoroni Keybow that allows you to run arbitrary HTTP requests, as well as control OBS (streaming studio) from it. :)