WIFI+MQTT Smoke-Detector with 5yrs battery and ESP8266

Read about Flocx’s current project, a battery-saving WIFI+MQTT-enabling cheap smoke-detector here: https://blog.flo.cx/2018/08/ikea-diy-smart-smoke-detector/

I wanted to do the same thing for my flat, but instead of using the IKEA one, I ordered two cheap 7€ SmartWares detectors from Amazon with 9V batteries that are advertised to give 5yrs battery life and otherwise identical hardware. Also instead of µPython I used Sming and C++. Just for the fun of it, I also added a voltage divider that measures the battery voltage at the time of alarm.

You can find my firmware on GitHub.


Todo for the future: motivate someone to do this for realraum. ;->

Since all 9V smoke-detectors ICs basically use the same pinout with an I/O-function on pin 7 that pulls LOW when no smoke is detected and HIGH on alarm, they are all equally easy to mod. The SmartWares are smaller than the IKEA ones though, so I did not even attempt to fit everything inside the case. More accessibility traded for lower WAF :)

Note that there are 3V Lithium 10yrs battery life smoke detectors out there, which work a bit differently. For once, the ESP8266 does not run with 3.0V but needs true 3.3V, so at the very least you will need a cheap and tiny boost converter from AliExpress. Furthermore, they do not use a CS2105G0 based chip but a PIC which might not have an pin as CS2105G0-I/O-pin configured.

A word of warning: In order to conserve the battery, the circuit disconnects the whole GND when no smoke is detected. Thus GND and 3V3 of the ESP8266 may be short-circuited through the unpowered buck-converter, depending on your component. So just to be safe, remove the Wemos from the circuit before connecting it via USB.

containers, e.g. with systemd

The more complex a program or application, the more likely it contains exploitable or otherwise dangerous faults. Containers are a way of limiting the damage by limiting an application access to the bare minimum. Ideally we would have a separate and instantly replaceable computer for every little daemon and service we run. Sadly, even with virtual machines, this would hardly be an efficient use of resources, so containers try to find a middle ground by allowing us to separate applications almost as if they were running on different machines, while actually sharing the same hardware and operating system kernel.

Several features come together to make this possible:
  • chroot
  • namespaces
  • cgroups

And it is a good idea to augment them with others:

  • seccomp-bpf syscall filter
  • packet filtering (ebtables)
  • virtual network devices
  • apparmor

Armed with these keywords, your week should now be filled with interesting and productive reading. :-)

If all you want are some opinionated basics however, read on:

Lesen Sie weitere containers, e.g. with systemd

Saving power of powerful printers


At home, my Samsung laser-printer uses 15W during standby. So, a few years back, in order to save power, I put it on a USB-controlled power-plug. Pretty soon I added a tiny script that would query cups if a print-job was queued and would switch the printer on and afterwards off again. It turned out to be a pretty effective power saving measure.


Our two very big and reliable printers at realraum were even more power hungry, so I wanted to to something similar for the space.

Using the hardware I had on hand, I cobbled together the following:

* A BeagleBone Green to act as cups print-server and to run the python scripts.
* An empty 230V power-plug case, housing a 5V power-supply (for the BB) and a small opto-coupler isolated relay to switch the plug.
* A second power-plug case with a second small opto-coupler isolated relay.

While there is a lot of room for optimization, like a leaner BeagleBone image and better housing for the power-plugs, printing- and power-saving-wise it works very well.

As always you can find our code on Github. Stay tuned for updates.