Home Automation

Welcome to my Home Automation page.

Most of my efforts for Home Automation are about creating sensors that can detect harmful situations like smoke, water leakages, gas leakages, open windows, … If one of those „harmful“ situations is discovered, I want to be immediately noticed, no matter where I am on this big world.

Have a look of what is here today

Home Automation Setup

You may say that there are too many similar technologies doing more or less the same, and you are right. But it grew over the time and I enjoy to discover new technologies, their strength and their weaknesses. Let me explain:

  • I began with simple FS20 radio switches and at that time there was a set with 3 smoke detectors and a simple modem to dial out and replay a pre-recorded text message in case any of the smoke detectors were triggered.
    Problem though was, that I could not find any water or gas detectors. Only weather sensors were available, but no bidirectional communication was possible to detect low batteries or request status information or set parameters.
  • Than HomeMatic came out and it was possible to connect the devices to the computer. At that time FHEM was able to use the HomeMatic LAN device. In addition FHEM was able to use a device called CUL to talk to FS20 devices too. That was the birth of the first real Home Automation in my home.
    Now I could see in the WUI of FHEM the status of all my FS20 devices, the status of the HomeMatic smoke detectors, water detectors, window sensors, … In case of smoke or water FHEM could trigger a SMS message to my mobile. I love FHEM for its great hardware support.
    Problem though was that I did not like FHEM’s standard WUI too much and that programming triggers and procedures in FHEM is difficult and debugging close to impossible. All FHEM configuration is in one single more or less unstructured file only, looking terrible.
    Another problem is that HomeMatic devices have quite a price. Spreading 10 or 20 water sensors around your house is costly.
  • OpenHAB has a WUI that suites me more and OpenHAB spreads its configuration over several well formed files. Rules and commands are easily done and tested. I was not willing to rearrange all my hardware around OpenHAB. After all FHEM was doing a great job there.
    During my experiments with Arduino I discovered the ESP8266 chip, which is much more powerful than the Arduino’s Atmega328 and has WLAN and a full TCP/IP stack also. You can get such a module for around 10 €.  But how to connect the ESP8266 with OpenHAB? That can be done via the MQTT bus, which is originally designed for sensor grids. And in fact the MQTT bus is now the glue between all components. FHEM, OpenHAB, my ESP8266 based TOAST nodes and the MySensors nodes all send and receive messages via the MQTT bus.
  • First the ESP8266 based TOAST nodes seamed to be perfect. Plenty of IO ports, plenty of memory, full and secure WLAN connectivity, TCP/IP, MQTT client, web server, affordable, small, perfect sleep mode, capable of running on 2 AA batteries. I love it and I am building more than only sensors with it.
    Problem though is that the WLAN overhead is so tremendous that the nodes are not really good on batteries. Sending a simple temperature every 5 minutes, with deep sleep in the meantime, will give you less than 2 months of lifetime on 2 AA batteries.
  • So this is the point where I came back to the Arduino’s Atmega328. A bare Atmega328 with a RFM69 (868MHz transceiver) can run for more than 1 or 2 years on 2 AA batteries. The MySensors framework is giving you a lot of help, e.g. the gateway to MQTT or message handling or functions to send battery level, deep sleep modes, OTA, …

This is what I am currently working on.

Come again and check from time to time what’s new.