Domotica because mosquitoes


To combat mosquitoes I once had a mosquito net. Those nets are usually awful; they hang from one point in the middle and then extend over your bed. Meaning that your bed turns into a cramped igloo tent. One exceptional hot week in The Netherlands resulted in some mosquitoes bites. The refreshed mosquito annoyance resulted in the discovery of rectangular mosquito nets, see e.g. this example product (I bought a different one btw). It basically adds straight walls and a ceiling around your bed. The net can be removed pretty easily once summer is over. It’s a pretty cool solution with two drawbacks: a) difficult to combine with a ceiling fan b) difficult to combine with a hanging lamp.

A fun solution to the lamp problem is to replace the light with remote controllable LED panel, mostly because why not. And so the lamp was replaced with an Ikea LED panel after which the rectangular  mosquito net was installed. The LED light is remote controllable. You get a pretty cool remote control with it, one you can install against a wall but is magnetic so you can still take the remote control with you. The Ikea LED light uses a communication protocol called Zigbee. This protocol is one of the various home automation protocols out there. The decision for buying the Ikea LED panel was mostly made because of interest into Zigbee.

Communication methods/protocols

For personal use the most common home automation methods/protocols seem to be:

  • Zigbee
    As mentioned. It works around 2.4Ghz (has multiple channels). Battery efficient. Mesh network. It should support a huge amount of devices, though range is less than Z-Wave Plus. Range could also be restricted due to interference with 2.4GHz Wi-Fi .
  • Z-Wave Plus
    Similar to Zigbee. It works around 900MHz, exact frequency differs per region. Battery efficient. Also uses a mesh network. There’s a huge amount of devices using Z-Wave Plus, though they tend to be more expensive than any other method. Due to using 900MHz it goes through walls easier than e.g. Zigbee or Wi-Fi.
  • Wi-Fi devices
    They mostly use 2.4GHz and support slow Wi-Fi b/g/n. Most of these devices use a chip called ESP8266. These devices are often not as power efficient as Zigbee/Z-Wave Plus so seems this is not a good choice for anything battery operated.
  • 433MHz
    Various devices work on the frequency 433MHz. They’re usually battery efficient, though (it seems?) there’s no real standardized protocol so aside from the frequency it depends on the service. A lot of the cheap ‘turn all these lights on/off’ use this frequency.
  • MQTT
    This is purely a protocol like e.g. HTTP or SSH. Its origin is from 1999. It doesn’t define how the data is transported (e.g. wired or wireless xx G/MHz), purely focusses on the protocol.


Although a few methods use encryption it doesn’t mean that they’re secure. E.g. Zigbee apparently is NOT secure against replay attacks, though the newer Zigbee v3 should be. The Wi-Fi devices by default are often “cloud connected”. The 433Mhz devices lack any encryption and it’s quite easy to influence things. MQTT has authentication and it could use encryption but appears it’s often not available on devices. Without encryption probably anyone on the same network can just use a network sniffer to capture the MQTT login details. The list of security issues is pretty extensive. It’s best to always assume someone could takeover anything connected to any Domotica which has wireless functionality. Same for a wire but at least it requires slightly more effort.

Free software

There’s various free software available for Domotica. A list of a few nice ones:

  • Home Assistant
    Tries to ensure it’s NOT “cloud connected”. You need a Raspberry Pi or some 24/7 on machine to run this on. This software supports loads of devices, including loads of Zigbee hubs, MQTT, Z-Wave Plus controllers, etc. There’s for easy installation on a Raspberry Pi.
    Aside from Home Assistant there are loads of alternative free software options.
  • Tasmota firmware
    Alternative firmware for ESP8266 devices. It seems pretty much all Wi-Fi b/g/n-only devices have an ESP8266 chip in them. The Tasmota firmware is NOT “cloud connected”, though it does rely somewhat on the internet, e.g. NTP for time synchronization. It adds support for MQTT, KNX, rules, timers, etc. The rules and timers would allow you to have the ESP8266 device itself know when to do something instead of having Home Assistant telling the device to do something.
    The big drawback is that it’s not easy to flash this firmware on most of the ESP8266 devices. It usually means taking something apart, soldering, etc. Fortunately the firmware is able to auto update itself making it a one-off hassle.
    Aside from Tasmote I noticed a few other similar ESP8266 firmware options, each with their benefits and drawbacks. Tasmota seems the most used/popular.
  • Zigbee2mqtt
    This software consists of two parts: One part is the real Zigbee2mqtt software, the other part  is firmware.
    The combination of both bits allow you to directly control Zigbee devices instead of needing to rely on the various Zigbee hubs. Often a Zigbee hub can only control a limited amount of devices, usually only within the same brand. Zigbee2mqtt supports way more devices than most of the Zigbee hubs. It then transforms this into MQTT.
    The drawback is that you need various components plus some tinkering, though the website explains what to do quite well. The site suggests to use a CC2531 chip, though I prefer the CC2530 chip. This as the CC2530 allows you to use an antenna. The CC2531 is easier to use and has an integrated antenna (worse range, 30m line of sight). I highly prefer a better range (60m for CC2530). Hopefully within 6 months better chip solution will become available.
    Another drawback is the limited amount of devices directly supported by the CC2530 or CC2531 chips. After 20-25 directly connected devices you might run into issues. To use more devices you’ll to have some Zigbee routers. It’s best to plan this ahead and plan for some non-battery operated Zigbee devices (Zigbee routers).
    For using Zigbee2mqtt, one possibility would be to have a chip with Zigbee2mqtt connected to a Raspberry Pi (or any other device with Home Assistant), another option is to combine it with a Wi-Fi chip and operate it independently.
    Aside from translating Zigbee to MQTT the firmware also allows you to create a Zigbee router. This to extend the range of your Zigbee network. The cost of such a router is only a few EUR at most. Easier solutions are either any Zigbee device connected to electricity (most are then a router), or a signal enhancer from Ikea for 9.99 EUR,.


I noticed a few nice devices. There might be many more nice ones out there. One way of figuring out which options are out there is to browse the supported devices list by zigbee2mqtt.

  • Zigbee Ikea TRÅDFRI
    I like their remote, their LED panel and their LED lamps. They also have various sensors, but they seem quite big compared to other solutions.
  • Zigbee Xiaomi/Aqara sensors
    They used to be dirt cheap until AliExpress raised all of the prices. The ones I like are their window/door sensors, shock sensors, motion sensor plus their magic cube.
  • Wi-Fi BlitzWolf BW-SHP6
    I like their plugs because they’re low cost, small footprint plus they still have a button on it making it easy to keep a physical way to turn the device on. The BW-SHP6 is a small EU plug which doesn’t take up too much space and allows up to 2300 Watt. There’s also the BW-SHP2 but I’d use the Osram smart+ plug over the BW-SHP2. You’re able to flash the Tasmota firmware on both the BW-SHP2 as the BW-SHP6, though it’s quite difficult for the BW-SHP6.
  • Osram smart+ plug
    This is a Zigbee plug with a button (Ikea one lacks a button).
    Drawbacks: bigger than the BW-SHP6
    Benefits: it speaks Zigbee, it’s a Zigbee router (extends your Zigbee range), it supports 16 Ampere/3600 Watt, I hope/guess the standby usage is lower
    You can buy it pretty cheaply on, use to check if you have a good price. New it’s often 15 EUR. Osram also sells used ones on Amazon; it seems they’re basically new but without a box. The price for those are around 11.50 EUR.
  • Sonoff (Wi-Fi)
    Loads and loads of different low cost options.  They’re supported by the Tasmota firmware. Their Wi-Fi switches are about 5.50 EUR if you buy 3; a possible use case  is to make these part of an extension cord.
  • Shelly (Wi-Fi)
    These devices are small enough to hide them within your wall outlet. They’re supported by the Tasmota firmware. Do look at the Tasmota Wiki as the Shelly hardware has some issues. For wall sockets I’d prefer an obvious device over something hidden within the outlet.
  • QuinLED (Wi-Fi)
    These aren’t devices, more like complete design for a device. The website extensively explains not only the device designs but also tools and equipment, LED strip advices, recommendations, guideline on what tools and equipment to buy to create these devices, etc.
  • Z-Wave Plus devices
    They’re so many nice devices which do not seem to have a Wi-Fi or Zigbee equivalent. E.g. 300Watt dimmers (Zigbee seems limited to 30Watt). The devices are way more expensive though; easily pay 70+ EUR per device/sensor.


Price wise, it might be good to buy a device (“hub”) with support for all the Zigbee devices, Z-Wave, Wi-Fi, 433MHz, etc. This as building everything yourself might not even be cheaper if you’re only building it once. This as you might need to buy loads of things: soldering equipment, wire stripper, up to possibly a 3D printer. That would be less fun though!

That said, it’s a bit unfortunate that to really integrate everything together requires too much knowledge. I’d like a more out-of-the box type of solution. Something I’d be comfortable with giving to family that’s easy to use, works well and is still free software.

Fanless NUC

My newly built fanless was nice, but I could still hear my NUC if listened closely. During my investigations I noticed the fanless cases from Akasa, including replacement cases for various NUC motherboards/kits. After wondering  if I maybe shouldn’t replace my NUC I eventually decided to just buy a new fanless case for my existing NUC. The reasoning was quite simple, the Akasa case was 51.96 EUR including shipping. Any other solution would probably be much more expensive.

I didn’t monitor the temperature change too closely. It seems the fanless case keeps my CPU at least 10 degrees Celsius cooler than the Intel case. As the Akasa case is entirely metal it’ll ruin the WiFi/Bluetooth reception. The case does have the option to install an external WiFi antenna, but it doesn’t include the proper wire to do that. I’ve bought that from AliExpress for 5.72 EUR.

The next thing I want to replace is my current mouse. The mouse wheel has been giving issues since forever and the mouse gives off a light. I tried investigating the best possible replacement but there’s too many options. Plus it’s difficult to easily filter out the irrelevant options. Eventually I noticed a fairly cheap somewhat silent Logitech mouse. A quieter mouse fits with my fanless cases so I bought that. The website said it does next-day arrival.. it didn’t arrive the next day.

New computer

Shortly after I assembled my current/old pc the older pc died. I intended to have two and ended up with only one; my NUC. With memory prices slowly dropping to more affordable levels I decided to assemble a new pc.  I tried to go for components with a good price/performance. I don’t want to spend 50% more for maybe 10% more performance. Next to price/performance I opted for an AMD CPU because Intel has so many more security issues. I went with a 1TB SSD (SATA because of price/performance), 65W TDP AMD Ryzen with integrated GPU, a mini-ITX size motherboard with good 5.1+ sound, plus a fanless case. PSU wise I found a laptop-like PSU/charger which needed a DC-DC converter. The result is an utterly quiet pc. I did a stress test and checked the temperatures. Everything seems ok, though wonder how things will be during summer. I quite like the lack of any noise.
My existing older pc is a NUC with a slowly spinning fan. I noticed a company making fanless cases for pretty much all NUC models. I’m wondering whether to make my existing NUC fanless, or maybe do something else.

32GB of memory, 1TB SSD, AMD Ryzen

Installing Mageia was annoying. Latest stable didn’t work, latest beta same. Eventually ended up installing it via internet (net install).

Before buying all the components I wasn’t aware something like fanless existed for such a CPU. It’s nice to do the research and make a pc which mostly follows the  tips  I found, my preferences and the trade-offs I had to make. Price wise I spent about 800 EUR on the various components (I didn’t list all of them). In case people want to know the exact components I’ll put it into the comments (update: had to put it under the “more” link). I’m trying to avoid making this appear as an advertisement.

Continue reading “New computer”

GUADEC 2017 on the cheap

I’ve just booked flight and hotel for GUADEC 2017, which will be held in Manchester. André suggested that I should decide this time. We’ll be staying a wheelchair accessible (the room is slightly bigger :P) room with Easyhotel. It’s 184 GBP for 5 nights and NOT close to the venue (but not bad via public transport). Easyhotel works like a budget airline. You’ll have to pay more for WiFi, cleaning, breakfast, a remote, etc. I ignored all of these essential things which means André has to do without that as well. The paid WiFi might even be iffy, so rather use my mobile data, plus per half June that shouldn’t cost anything extra thanks to new EU regulations. Before GUADEC I might switch to another mobile phone company to get 4-5GB/month for 18 EUR/month. André will probably want to work remotely. Let’s see closer to the date what’s a good solution (share my data?).

Flight wise for me Easyjet is cheapest (70 EUR) and it’s the fastest method. Funny to combine Easyjet with Easyhotel. I usually use a combination of Google flights and Skyscanner to see the cheapest options. However, rome2rio works as well. The latter will also check alternative methods to get to Manchester, e.g. via Liverpool and so on. For Skyscanner, somehow the Dutch version often gives me cheaper options than Skyscanner in other languages. Google flights usually is much more expensive. I only use Google flights to determine the cheapest days, then switch to Skyscanner to get the lowest price.


Window Managers under Wayland: libweston

One of the criticisms towards Wayland is the lack of a Window Manager concept. This to have an option of a different window manager behaviour/experience without needing to write a whole compositor as well. On LWN, daniels confirmed that it’ll become easier with time thanks to libweston.

Quoting daniels (first line/paragraph he’s quoting me):

> Not exactly sure what this allows, but I assume that most of the compositor logic is in this libweston, thereby reducing the complexity creating a different Wayland compositor.

Correct. The idea is to let people write window managers and desktop environments without having to worry about the details of DRM/KMS/GBM, EGL, dmabuf, the Wayland protocol itself, and whatever other plumbing. It’s not there yet, but hopefully in the next year or so it’ll become a really solid viable alternative.

Secret santa: GNOME

With a group of colleagues we held a secret santa. One of the rules specified to only list hobbies and likes; specific gift requests weren’t allowed. I wrote down: GNOME, Salsa, purple and travel. I assumed this list would be entirely useless and I’d rather have santa use their imagination. The picture explains all:

A pink GNOMEThe secret santa even included a poem with the request to send pictures of me and the gnome during my travels. Anyone remember the traveling gnome that we used to see on Planet GNOME?

Apparently Googling ‘GNOME’ doesn’t really explain what is meant with ‘GNOME’ :-P Aside from above gnome I also got a ‘The best places to be today’ from Lonely Planet!! Also, look carefully at the picture.


I’m going to GUADEC 2016 Karlsruhe, Germany

I’ve arranged pretty much everything for Karlsruhe. Meaning: transportation (train) and the hotel. According to the feedback I received, the public transport will be pretty terrible during the conference. So make sure to get a hotel nearby. The one I chose (Leonardo Hotel) is about 20 minutes walking. Make sure to read the reviews of this hotel. The closest hotel will be Achat and the GUADEC website should soon have a discount code for that. Achat with discount is still more expensive than Leonardo; though Achat should be worth it.

Aside from the likely non-working (UPDATE/correction: mostly working except maybe 1 tram line) public transport, they’ll also have bikes for around 1 EUR/30 minutes. So that’s probably what I’ll use to get around. The bikes likely require a data connection to rent.

To get there I’ll go by train; seemed like the best option (100 EUR round trip for about 6 hours one way). Coach would take 8+ hours and cost at least 100 EUR. Anyone looking into doing the same I recommend booking asap, trains are getting more expensive. I gambled on not paying the additional 8 EUR to reserve a seat on the high speed train part. Let’s see if that was a wise choice :P Still remember the time I reserved and the train was pretty much empty, as well as the time I did not and I had to change seats multiple times!

User conference

In case you use GNOME, the GUADEC conference is also for users. In case you’re wondering if you’ll fit in: Everyone is usually super friendly. First year you go you go to see talks and maybe a few drinks (alcohol is optional). Second year you talk more with the people you met from last year. Third year onward the talks are an excuse to go and the only talks you see are the ones where the speakers asked you to please attend :P plans I’ll never get to

Attending conferences is a good way to get some excitement into helping out. Lots of people trying to improve and make things better. I attended FOSDEM (6000 people) and (1600 people). As usual, I’ve had various ideas:

  1. Create an imperfect way to automatically create tarballs:
    Over the various years people often asked “why do we still use tarballs”? But moving away from tarballs is not easy so I don’t want to handle that. Instead, I want to take a small part of the idea and get that working. This to save time for maintainers as well as shortening the time needed to make a GNOME release.

    • Make use of
      Actually have no idea how works
    • Perform various sanity checks and bail out if something is wrong or not as expected (“make distcheck”)
    • Do NOT try to handle everything
      Not everything is on; not every branch might be on there. Too bad!
    • Do try to encourage rewarding a proper module (e.g. be a bit strict in the requirements so that those modules get benefits such as automated releases)
    • Find a way to handle NEWS
      We’ll probably want to generate those from commit messages. E.g. NEWS: bla bla bla
    • Probably need to define an expected workflow
  2. Create an extension for having points on Bugzilla
    We used to have this ages ago. Each time I work on Bugzilla I find various gaps. Either bugs, lack of API, etc. I think this might require an major version upgrade of GNOME Bugzilla else I’d need to apply too many workarounds. Still, points have often been requested and it would really help not only GNOME but also Mageia.
  3. Do minimal amount of work to speed up downstream development
    Example: help out Tails and maybe promote them a bit. They requested a keyword on Bugzilla. Super easy to add. Asked them if anything else might be nice but apparently there’s not much.
    Related: for many years I was planning to see how GNOME would be easier to work with. Find the things which might be easy to change and really help someone else.

Very likely I’ll not get to actually doing any of above. It would be nice though!

Perfect storm: GTK+3.x behaviour under KDE and Firefox’s move to GTK+3.x


At Mageia, various people suddenly started complaining about the scrollbar behaviour of GTK+3.x. Not always in the most constructive manner. One example:

“GTK+3 is the way of the future and all you luddites had better fall in line sooner if not later”

The reason was two fold. For one, Mageia could not use oxygen-gtk anymore. Oxygen-gtk played an important part in ensuring GTK+ not only looked but also behaved like Qt. The second big reason was the Firefox package being compiled with GTK+3.x support instead of GTK+2.x.

Loads of people use Firefox. These people don’t like their Firefox behaving different from what they’re used to and expect.

Already lots of moons ago people complained about the different behaviour of toolkits. One of the solutions is xsettings; a way to inform a toolkit at runtime regarding about settings such as (quoting): “double click timeout, drag-and-drop threshold, and default foreground and background colors for all applications running within a desktop”. Checking the xsettings spec git log this standard was created around 2001!

The solution seems obvious: Ensure the right xsetting is set. In practice there were some difficulties:

  1. The KDE xsettings manager was unmaintained for ~3 years
  2. There wasn’t any xsetting for this in gtk+
  3. GNOME bug 688524: Expose gtk-primary-button-warps-slider as an X setting was marked as WONTFIX

Road towards fixing the behaviour

First up was getting commit access to xsettings-kde. This was initially written by various Mageia people using the example code included in the xsettings spec. Unfortunately it seems the maintenance more or less died as soon as it was moved to KDE. One of the listed maintainers is Colin Guthrie; the same Mageia person whom I always pester for getting fixes for things I don’t understand. Furthermore, I recently helped out Ben Cooksley (KDE sysadmin) by fixing a GNOME mailserver misconfiguration which caused problems for KDE. Surely us finally (configuration was there for years) not causing problems for KDE anymore was worth KDE commit access right?
A few days after requesting access it was the same Ben Cooksley who setup the account! Though probably not a good idea to follow the same path if you want KDE commit access. :-P

Next up: the gtk+ xsetting. At the time of requesting xsettings-kde access, I didn’t know that gtk+ lacked the xsetting to control the scrollbar behaviour. Reading the related bug it was pretty clear the WONTFIX was not so much about the xsetting itself: The bug wanted an xsetting which was controlled by gsettings. Having an xsetting in gsettings is pretty much over the top. We already have an ini file (applies to everything), xsetting manager/client, xsetting overrides key in gnome-settings-daemon, etc. A gsetting changing an xsetting? This resulted in the WONTFIX. Matthias Clasen was worried if KDE would actually use the xsetting. Quite nice to explain that I got KDE commit access specifically to improve xsettings-kde (+ok from Colin Guthrie). This resulted in an “ok to reopen”. The xsettings patch was outdated plus I didn’t like the chosen xsettings name, so I spend 5 minutes writing a new one. Most of those 5 minutes I spent on aligning my commit message with previous ones as well as figuring out the nicest place to put the one liner change.

Lastly: Patching it back into the existing Mageia packages. I then discovered I made a typo in the xsettings-kde patch. Ugh.

Response from users

<R> is the firefox misbehaviour under gtk3 on cauldron fixed now?
<M> yes, the scrollbar works fine, now

Also seems quite telling people are trying this out within 1 hour of me updating the packages!

The patches

For any distribution wanting these fixes as well. The easily backportable patches:

I’m going to send above information to the GNOME distributor mailing list with the request to forward it. Any GNOME packager should subscribe themselves to this mailing list!

Other desktops

Other desktop environments should determine for themselves if they want to change GTK+ behaviour. Any Qt using distribution should make use of xsettings-kde. If a desktop environment (e.g. MATE) is maintaining a gnome-settings-daemon fork, one way would be to change the ‘fixed_entries’ variable in plugins/xsettings/gsd-xsettings-manager.c. If the desktop uses a custom GTK+ theme, another solution would be to store a settings.ini in the theme directory next to the gtk.css file. I’ve suggested to the Mageia MATE packager to reach out to MATE.


Various other xsettings which might make sense to set under KDE. There’s some backlog in the xsettings-kde maintenance which needs to be done. For the backlog I probably need to find some assistance (I’m not a C developer). I need to check if there are outstanding bugs and where they are.

My intention is that GTK+ under other desktop environments at most is considered different. GTK+ should not be out of place (or worse).

Hardware accelerated video playing with Totem


Various months ago I had hardware problems. To debug this and because I wanted a small server I bought an Intel NUC5PPYH. It’s a really small low power PC. Using this I discovered that my hardware troubles weren’t related to my SSD. Since that time I’ve been using the NUC as my main machine. My previous machine had upgraded parts, but GPU/motherboard and memory all were from around 2007. A slow low power 2015 NUC is somewhat in the same performance range as that 2007 machine (50% slower in some things, faster in others) while using way less power. My previous machine had 2 cores, the new one has 4.

My previous machine already had difficulty with some of the super high quality videos. Depending on the settings, some videos can use a very high amount of CPU. The CPU of the NUC is slightly slower to play videos.

Initially the various GNOME video playing bits crashed when trying to play video. Those crasher bugs got fixed, but Totem never properly played anything. I quickly discovered that mpv didn’t have any problem with hardware accelerated video playing, so used that and stopped filing bugs.

It helped me to improve the Mageia mpv package. Ensuring it had an OSD, was compiled with vaapi support, etc. Then recently gstreamer-vaapi 0.7.0 was released and gave me the idea to try Totem again. I’m guessing that change made things work, though not exactly sure.

Hardware accelerated video playing

Two frames from Tears of Steel showing Koen Martens, GUADEC 2010 organizer (together with Vincent and Reinout). First screenshot shows Totem with 6-7% CPU usage. The second shows MPV with 3-4% CPU usage. System Monitor itself uses around 20% CPU. Now that it works nicely, I’m working on having Mageia 6 automatically install VAAPI for you if your system has a similar GPU as mine.

Playing 1080p movie using Totem with 6-7% CPU usage
Tears of Steel using Totem – 6-7% CPU
Playing 1080p movie using mpv with 3-4% CPU
Tears of Steel using MPV – 3-4% CPU

Secret bonus: Polari

If you look at the CPU usage, you’ll not spot something. I’m also running Polari on a different workspace. It previously used 10-20% even when idle. I filed a bug but the developer couldn’t reproduce. Now I cannot reproduce as well — 0% CPU!! :-D