Core v2: A Java EE application

Since quite some time my home automation is build around a core app made in Java EE. As part of this challenge I’m improving the core and integrating it more tightly through MQTT. The core is responsible for coordinating all nodes and enforcing the business rules for our home.

Introduction

Thuis ArchitectureThe Thuis core runs on the Raspberry Pi 3 in a WildFly container. Like all nodes it’s connected to the MQTT broker for communication with the rest of the system. It also takes care of communication with some external applications, like Plex (media server) and Netatmo (weather station). In this blog I’ll focus on the integration of MQTT, Z-Way devices and the rules.

The building blocks of the application are as follows:

  • Model:
    • Devices
    • Rooms
    • Scenes
    • Rules
  • Commands
  • Controller
  • MQTT-CDI

Each of these will be described in this blog. Currently all models and rules are defined as static objects in Java code, the goal is to put this in the database at some point and make it editable through a UI, that will however be after the challenge ends.

Device Model

The two base models are Device and  Room. To be combined with  Device there are different types of Actuator and Sensor. The following image and table show the interfaces. There are several implementations, for example there is  MqttSwitch which implements Device and  Switch and defines a switch which can be controlled through MQTT.

Device, Actuator and Sensor class diagram

Interface Description
Device General definition of a (virtual) device: an identifier and it's status (type will be overridden by more specific interfaces)
Actuator A device with controls
Switch
extends Actuator
A switch with on/off and toggle features
Dimmer
extends Switch
A switch which also has can have values between 0 and 100, where 0 is off
Thermostat
extends Switch
A thermostat supporting a set point for the temperature. It can be turned on/off, which will put it on predefined on and off temperatures
Sensor A device that provides a (single) value of a sensor
BinarySensor
extends Sensor
A sensor with a value that can be true or false
MultilevelSensor
extends Sensor
A sensor with an arbitrary value and a configurable unit of measurement

All devices are virtual devices, each with a single function. For example a sensor that can measure both temperature and trigger on movement will be implemented as two sensors: a MultilevelSensor and a BinarySensor.

In this blog post we’ll describe two of our rooms: the living room and the kitchen. This gives us the following definitions:

Command Model

As you might have noticed in the interfaces above, several methods return Command. A command is a runnable class that can be executed to fulfill a task, for example turning on a Switch with Switch.on(). For each type of command there is an implementation. The one used most by the devices defined above is the MqttCommand which publishes a MQTT message, so for example Z-Way will receive it and take action. The implementation is quite straight forward:

Command class diagram

Commands can be encapsulated in other commands. By encapsulating you can either compose several commands into a single one, or add a condition to the command. The following commands of this type exist:

Command Description
ConditionalCommand  A command that executes the encapsulated command when a certain condition is met. The condition is defined using a Predicate lambda. Three default conditions are available:
illuminance – shortcut for predicates based on illuminance, for example execute when illuminance is below 100lux
whenOn/ whenOff – execute a command when a given device is turned on/off
ListCommand execute several commands in order
PrioritizedCommand execute a command with a different priority, for example USER_INITIATED: the highest priority which will let the command jump in front of the execution queue
WaitForCommand wait for a condition to be true before executing another command. Two default conditions are available: waitForOn and waitForOff which wait for the status of a device to turn on or off before executing another command

Another way of combining commands is using a Scene. This is an object that contains two ListCommand, one for activating the scene and one for deactivating it. A scene for turning on and off the mood lighting in the living room is defined like:

Observing MQTT messages

The Core observes MQTT messages arriving on basically any topic. It then checks if there are any devices (or better ObserveMqttStatus implementations) matching this topic. The status of these devices is then updated. When a sensor gets a new value an event is emitted. These events (and individual MQTT messages) can triggered rules. This all happens in the MqttObserverBean. This bean also takes care of updating the status of any scenes or rooms including this device.

The connection with the MQTT broker is handled by the MQTT-CDI extension made by Alexis Hassler, to which I contributed some improvements in the past. This CDI extension abstracts the actual connection away. When MQTT messages arrive on a subscribed topic they are fired as CDI events which can be observed using the @MqttTopic annotation. This way you can very easily observe any messages arriving:

For publishing messages a service method is available.

Rules

To enable sensors (or other events) to trigger commands there are rules. A rule is an Observer of either an MQTT topic or a  SensorChanged event. As result one or more commands are executed. An example of a rule is the following:

This example covers most of the basic options. It observes the movement sensor in the kitchen. When it’s status becomes  true and it’s not very light it will check 3 timeframes. Depending in which timeframe the current time fits a combination of lights is turned on. This way you always have the most useful lights for the task ahead. The timing might need some optimization, but this is a good start.

Controller

Taking care of the actual execution of commands and scenes are the Controller and the CommandExecutor. Take the example rule above: it triggers several lights to be turned on or off. These commands are passed on to the controller. The controller takes the command, determines it’s priority and then puts it on a JMS queue:

(for the purpose of this blogpost the code is simplified a bit)

A JMS MessageListener, the CommandExecutor, is used to listen to the commands which are added to the queue and execute them. Because of the way the JMS queue works, commands are executed in chronological order while respecting the priorities. This means that all commands with the same priority are executed exactly in order they were added (FIFO), but when a command of a higher priority is added to the queue it’s moved in front. This is used for situations where for example the home theater is starting up (which takes a few minutes in total) and someone triggers a motion sensor. This command gets the USER_INITIATED priority and is therefore executed at the first possible moment, in front of all other steps of starting up the home theater. Something that’s not time sensitive (for example automatically turning off the heating at night) gets a LOW priority and will therefore never block any more important commands.

Some commands can take a long time and you don’t want them to block the queue. For example a WaitForCommand takes until the condition becomes true. In this case the condition is tested once and when the result isn’t true yet the command is added to the queue again with a small timeout.

Concluding

The most important part of the Core is now done, but most rules still have to be implemented. In a later stage some more external systems will be added to the core, for example for controlling the Home Theatre. I’m also aware that, to keep this blog post from growing too much, I have simplified some code samples and didn’t cover every detail. If you’re interested in a certain detail, please let me know and I’ll explain it more!

Publishing activity from Z-Way to MQTT

Now we have a working Raspberry Pi 3 with Z-Way it’s time to connect it to the backbone of Thuis: MQTT. For this I developed a custom userModule/app. In this post I’ll explain what it does, how to use it and how it works.

Goal

The app enables Z-Way to send and receive MQTT messages. Whenever the status of one of the selected devices changes it will be published to a topic. Based on these topics some other topics are available to change the status of the devices or request a status update.

How to use

Install

Z-Way MQTTZ-Way allows developers to create userModules and publish them to their App Store. Unfortunately they still didn’t reply to my submit, so it’s available straight away. Luckily they do have a beta-token mechanism, so it’s still possible to install it. I’ve used BaseModule by @maros as basis, so you’ll need to install this as well.

To install it follow these steps:

  1. Go to the Management page of your Z-Way
  2. Open the App Store Access tab
  3. Add mqtt_beta as token
  4. Now go to Apps, and then Online Apps
  5. Search for Base Module and install it
  6. Search for MQTT and install it

Configure

MQTT PublicationWhen you go to the settings of the app you’ll find quite some options. The first section are the basic settings needed for MQTT: the client ID and hostname/port/username/password of the MQTT broker. Next are the common topic prefix (we’ll use Thuis/device for now) and postfixes for requesting a status update and for setting the status of a device.

More interesting is the second section, which are the publications. When you add a publication you first select a type: a single device or tagged devices. We’ll use the latter for now. Now you will add some tags to select which devices will be part of this publication.

Next is deciding on the topic for the publication. You can use two placeholders: %deviceName% and %roomName%. They will be replaced by the actual values for the corresponding device. In this example we’ll use the topic %roomName%/%deviceName%.

The last option is wether or not to publish status updates as retained messages, we’ll turn it on.

Receive status updates

Now you’ve configured the Z-Way MQTT app so we can use it to receive updates on our devices. We’ll use mosquitto_sub to demonstrate this:

As you can see a devices called ‘Counter Switch’ in the room ‘Kitchen’ was turned on and off, the dimmer in the office was turned down, and the luminescence sensor in the kitchen gave an updated status.

Interact

There are two interactions available: requesting a status update and setting a value. Both can be demonstrated using mosquitto_pub. To request the status of the dimmer in the office publish a message to Thuis/device/office/dimmer/status with an empty message:

When you subscribe to the dimmer’s topic in the meanwhile you receive the new status:

Then to set the dimmer to 60% you send the message 60 to Thuis/device/office/dimmer/set:

The light will turn on and you’ll see the status changed:

Currently values between 0 and 100 are supported for dimmers (devices supporting the SwitchMultiLevel command class) and on/ off for switches (devices supporting the SwitchBinary command class).

How does it work

Z-Way apps are made in JavaScript. Their basic structure is defined in the developer manual. As said before I’m using the BaseModule as basis as it provides some useful functions for interacting with devices, for example filtering status updates to includes only updates with actual changes. The full project can be found on my GitHub as Zway-MQTT. Here I’ll explain some interesting parts of the code.

MQTT client

From a userModule you can call out to external utilities, but only when you give explicit permission. I would like to avoid this, so I searched for a pure JavaScript solution. Most JavaScript-based MQTT libraries use WebSockets, which is unfortunately not available in Z-Way. Luckily I found a module by @goodfield. He found and modified a MQTT client for use within Z-Way. I cleaned it up and started using it:

Publishing status updates

To receive updates we have to subscribe to updates sent by the Z-Way core. I’m using the modify:metrics:level event, which is the filtered version from BaseModule.

In updateDevice I retrieve the new value from the device and transform it if needed. Then I’ll look up all publications matching this device (for example because they are tagged with the configured tag) and execute a MQTT publish for them.

You’ll notice the createTopic call, this call takes care of merging the prefix and configured topics plus it replaces the placeholders. Device and room names are camel cased to have nice and valid topics.

Reacting on interaction

To react on status requests and new values the app will subscribe to all topics starting with the prefix. It will then filter out the actions. If it receives an action message it will try to find the corresponding publication and device bases on the topic. It will then take the requested action.

We can now easily talk to Z-Wave devices through MQTT messages. Later I’ll add support for more command classes, like thermostat and power usage. Someone already requested battery level updates through GitHub, which is an interesting addition as well.

Installing the Raspberry Pi 3 in practice

Last week I explained how I’m using Chef to provision my Raspberry Pi’s and the recipes in my Thuis cookbook. Back then I didn’t have a Raspberry Pi 3 yet, so I tested it on an older model. This week the kit arrived, so I’ll bring the bootstrapping in practice on the Raspberry Pi 3! Not everything went as expected, so this is a good subject for this blogpost.

The Kit

Pi IoT Kit

Installing the Raspberry Pi 3

As mentioned before I’m using raspbian-ua-netinst as a basis for my install, as this gives me a very lean install of Raspbian. The maintainers of the projects didn’t update the installer yet for the Raspberry Pi 3, so there are some manual steps to go through for now. This is discussed in issue #375. It boils down to the following steps:

  1. Format the SD card
  2. Copy all files from the latest version to the SD card
  3. Fix the files for the Raspberry Pi 3:
    1. Copy (replace all) the files from the firmware repo using the handy tarball made by @eLvErDe
    2. Edit /boot/config.txt by adding the following at the end:
  4. Insert the SD card in the Raspberry Pi and power it on
  5. Now wait until the installation finishes (it will take quite some time, when you don’t have a screen attached wait until the ethernet connection becomes silent)
  6. SSH into the Raspberry using the default username root and password raspbian
  7. Now fix the kernel by installing and running rpi-update:
  8. Edit /boot/config.txt again by changing [pi2] into [pi3]

The Raspberry Pi is now ready to be bootstrapped.

Bootstrapping Chef

Bootstrapping Chef is a matter of running one simple command from my workstation:

However I ran into a few complications. During my testing I didn’t run into these because of the iterative process and some differences between the hardware of the two Raspberries.

Complication 1: systemd needs services to be reloaded

After installing WildFly the recipe tries to start the services; this however fails with a cryptic No such file or directory. The reason for this happens to be that systemd needs to be reloaded after adding new init-scripts. The WildFly recipe doesn’t take care of this and therefor runs into the issue. To resolve the issue I forked the cookbook and added a systemctl daemon-reload command to it (see PR #38). This ensures it can start WildFly as expected.

Complication 2: For Z-Way bluetooth needs to be turned off

RazberryThe RazBerry uses the serial IO pins on the Raspberry Pi, the same are used by the built-in Bluetooth connection as well. To be able to use the RazBerry and run Z-Way, Bluetooth has to be disabled. The original install script takes care of this, but after I converted it to be used in a Chef cookbook this didn’t work anymore. That’s why I converted these commands to Ruby blocks in my Chef recipe now. This looks as follows:

Basically this deletes the serial connections from /etc/inittab and /boot/cmdline.txt and adds an option to /boot/config.txt to disable Bluetooth.

Complication 3: sudo commands not found

When trying to do a command using sudo, e.g. sudo shutdown now I got a Command not found error. This happens because /sbin and other secure directories are not on the PATH for a non-root user. When you use sudo it should be and for this a small piece of configuration is added for the sudo cookbook:

Configuring Z-Way

As I already have a working Z-Way setup at home the configuration is pretty easy. It boils down to:

  1. Browse to http://10.0.0.201:8083 (where 10.0.0.201 is the IP of your Raspberry)
  2. Choose a password of your own choice
  3. Restore the backups:
    1. For the controller (*.zbk):  http://10.0.0.201:8083/expert/#/network/control
    2. And for the module automation (*.zab): http://10.0.0.201:8083/smarthome/#/admin
    3. If you used userModules then copy or install these again (their settings are part of the backup, but not the actual files)

Deploying an application to WildFly

This is easy as dropping an .ear of .war file to /opt/wildfly/standalone/deployments. Alternatively you can deploy the app as part of a Chef recipe like:

In the upcoming blogs I’ll work on the Java app and integrating Z-Way with MQTT, then we’ll do the actual deployment.

With the complications out of the way, the Raspberry Pi 3 is now fully ready to receive some app deployments, which is what I’ll work on now!

 

Cooking up the nodes: Thuis Cookbook

In my last post I explained the basics of Chef, and in the last week I worked on defining the configuration of each node. I selected several cookbooks from the Supermarket and wrote some myself. Using a series of recipes I defined the software and configuration of two of the nodes of Thuis in the Thuis Cookbook. In this post I’ll show you my choices and give some code samples to let you set up your own Chef config.

Let’s start with some of the cookbooks I’m using from the Supermarket:

Cookbook Description
apt Takes care of keeping the apt-get cache up to date
firewall Install and configure UFW
hostnames Automatically configures the hostname of each node based on a pattern
mosquitto Install and configure Mosquitto (MQTT broker)
tar Download and extract a tar file
sshd Install and configure the SSH deamon
sudo Configure which users can sudo
timezone_lwrp Configure the time zone
users Add default users with SSH keys
wildfly Install and configure WildFly and Java

Basics: default recipe

Execute on each the device the default recipe provides the basic setup of a node. All it does is installing a few packages and including other recipes:

Of course the recipes have some configuration, this is provided through the attributes file:

The firewall, sshd and users recipes are part of the thuis cookbook, the first two are fairly straight forward:

The users recipe is based on this nice blogpost: it’s creating my default user (robin), adding my SSH key and allows it to sudo without using a password.

Specifics per node

For both nodes (more will follow later) I’ve created a specific recipe. These recipes include the default recipe plus take care of the specific needs of that node.

thuis-server-core

As mentioned in my post about the architecture of Thuis the core node will use WildFly, a MQTT broker and Z-Way:

Mosquitto for now uses the default configure of the cookbook, I’ll finetune this later. I did have to update the cookbook a bit as it didn’t have support for Debian/Raspbian Jessie yet, for that I did a PR, which is accepted.

WildFly required a bit more effort as the standalone.xml configuration file wasn’t update with the latest version and the underlying java cookbook doesn’t have support for the ARM packages needed for the Raspberry Pi. The latter was solvable using some custom configuration which selects a different download based on the architecture:

Next is overriding the WildFly standalone.xml configuration:

The template file is a copy of the original, but updated using a diff between the original and the version from WildFly 10.0.0.Final. The needed configuration in attributes.rb is:

It changes the version to use, disables a few modules and important on the Raspberry Pi it uses -client instead of -server in Java options.

Chef Z-Way cookbook directory structureThe most difficult to get working was Z-Way. There is no cookbook available yet, so I had to build this one from scratch. I could have taken a relative easy way out by just letting the cookbook execute Z-Way’s install script, but as I want to learn Chef I went for the hard road. On the right you can see the structure of the cookbook. The full cookbook is available on Github at Edubits/chef-z-way.

The cookbook uses a few recipes to install Z-Way to the device, and more importantly to safely upgrade it while retaining the configuration of all devices. It also installs the required services and enables them to automatically start like:

A few things are kept as in the original script in the template file install.sh.erb and executed during as part of the install recipe. As I’m currently testing on an old Raspberry Pi with the Razberry hardware, I could not verify the full installation yet.

thuis-server-tv

The TV node will mostly take care of connecting to the home cinema system using CEC. For this a Java EE application is used, so WildFly is needed here as well. Next to WildFly we need libcec.

libcec in Jessie is only version 2 and we need 3, so we’ll grab this package from the Stretch repository:

Testing

Raspberry Pi 1BChef has a very nice way of testing cookbooks using Kitchen and Vagrant: it spins up a virtual machine from an image and runs the recipes on that. I used this for the general testing, however quite some of my changes and configuration are specifically made for the Raspberry Pi. This means to test those I had to use an actual device. For this I used my good old Raspberry Pi 1B. This required some patience, as one chef-client run without any changes takes about 5 minutes on this device. As there are some differences in architecture between the 1B and the 3B I expect there will be some small changes needed when deploying the cookbooks to the new device.

Bootstrap the nodes

As soon as the kit arrives (somewhere in the coming week) I will install them using raspbian-ua-netinst, assign a static IP in my router and then I can bootstrap the Raspberry Pi’s with just one command each:

Now the Pi’s are fully installed and ready to be used and it’s time to actually build & deploy automation software and connect some hardware! Let the fun begin 🙂

Using Chef to provision Raspberry Pi’s

ChefInspired by one of the other challengers I started to experiment with Chef. Frederick is using Puppet to provision his Raspberry Pi’s. To get more knowledge on the several tools out there we decided to both try one. So that’s why I started using Chef.

Chef vs Puppet

Both tools are open source projects built for automatically provisioning nodes with software and configuration. They both have a fairly similar setup using a server and clients on all nodes. The biggest difference is in how you manage your configuration. Puppet uses a Ruby-based DSL which is similar to JSON, Chef uses pure Ruby. This makes Chef a bit more powerful out-of-the-box. As Rich Morrow said in his report:

Whereas Chef tries to provide more power to the user, Puppet puts safety rails around them.

Some noteworthy differences:

Chef Puppet
Language Ruby  DSL
Execution Order enforced Model driven
Approach Programmer's approach Sysadmin friendly
Used by a.o. Facebook & Adobe Twitter & Intel

To learn more about Puppet I refer you to Frederick’s posts, here more about Chef!

The basics

A typical setup consists of three elements: your workstation, a server, and nodes.

Chef setup

The server is the central repository for all code and it also keeps knowledge about every node it manages. From your workstation you write and verify the configuration policy and then upload it to the server. When you run chef-client on a node the latest code is downloaded from the server and the node’s configuration is brought up-to-date.

Preparation

To start you need a set up workstation and server. You can install a server locally or use a hosted version. Hosted Chef is free up to 5 nodes, so that’s how we’ll start.

  1. Install the Chef Development Kit
  2. Sign up for the trial of Hosted Chef
  3. Create an Organization at https://manage.chef.io/
  4. Go to the Administration tab, selection your new organization and click Generate Knife Config
  5. Save knife.rb to ~/.chef
  6. Copy your private key (created during signup) to ~/.chef as well
  7. Test the connection between your workstation and the server with knife ssl check

Your first cookbook & recipe

A cookbook is a set of configuration describing a service or node. It consists of recipes, template files and attributes. A recipe describes everything that is required to configure part of a system, for example which software packages to install, how to configure them or execute other recipes.

For this example we’ll create a simple cookbook which creates a file, just like in Fredericks example. Start with generating the cookbook:

You now have the following directory structure:

As you can see there is already a default recipe created. Let’s edit that to contain the following:

Now upload it to your server:

And bootstrap a node:

You’ll see that Chef is installed on the node and in the end the file is created according to the recipe. When you run chef-client from the node it will check if there is a new version and if the file is still there. If something is not according to the recipe – it will fix it.

Supermarket

Of course there are already lots of cookbooks created by others, they are shared in the Supermarket. You can easily add a dependency to one of these cookbooks. There are several ways to override attributes used in the cookbook, or even override complete files to make sure it does exactly what you want.

You should have a basic understanding of Chef now, there is however much more. To let you get more familiar with Chef they have some excellent tutorials. In upcoming blogposts I’ll show my cookbooks as well.

The ugly: Chef on a Raspberry Pi

Now the bad news: Chef doesn’t support the Raspberry Pi out-of-the-box, so you can’t bootstrap it as easily as on other platforms. It also needs a fairly recent version of Ruby, which is not available in the Jessie repository. Luckily you can overcome this by using a custom bootstrap script and using the Stretch (the upcoming version of Debian/Raspbian) repository.

A good starting point is the Raspbian-Bootstrap by Dayne. It’s made for Wheezy, so we’ll have to update it a bit. It took some experimenting, but at some point I found a working solution. We can skip the custom Ruby build (which takes a long time) by using the ruby2.3 package from the Stretch repository and I’ve updated the syntax of the configuration part to the one from the default Chef bootstrap.

This brings us to the following steps:

  • Take a Raspberry Pi with a clean Raspbian install (I use raspbian-ua-netinst, as it gives a minimal install)
  • Download my version of Raspbian-Bootstrap
  • Use knife to bootstrap with a custom template:

    This will do the following:

    • Add the Raspbian Stretch repository to Apt and update the Apt index
    • Remove any existing versions of Ruby
    • Install Ruby 2.3 plus build tools from the Stretch repository
    • Install gems needed for Chef + Chef itself
    • Add basic configuration for Chef
    • Start chef-client for the first time running in this case my base cookbook thuis-base
  • Start using Chef on your Raspberry!

 

Software Architecture

To make the Thuis app as flexible and efficient as possible a solid architecture is needed for the system. Different systems have different properties, which are most important, for Thuis it’s important to provide the wanted functionality, be reliable, usable and adaptable.

Functionality and usability are the most obvious: without the wanted functionality the system doesn’t do anything. And when it’s not easier in use as the non-automated (old-fashioned) situation, it won’t be used at all. Thuis should be reliable because it’s influencing lots of functionality in the house: if for example the lights don’t work, this can be problematic when it’s dark. This includes recoverability as well: whenever something goes wrong it should not put the system in a non-working state, but should be able to at least do it’s basic functionality. The last property is adaptability, which is important since all products on the market evolve rapidly. It should be possible to keep up with the latest products and easily add new hard- and software to the system.

Architecture overview

Thuis Architecture

This blog provides a general overview of the architecture. In the upcoming blogs I will go in-depth into each module.

Core

Raspberry PiAt the heart of Thuis there is a Java EE application running in a WildFly container on a Raspberry Pi 3. On the same node Z-Way (a Z-Wave controller), Mosquitto (a MQTT broker) and a database (which one is to be decided later) are running. They are sharing the same node to save budget, but because of the modular set up they can be split on to multiple nodes.

Initially the core application will be built around a MQTT observer: it subscribes to all available topics and knows what to do when certain messages arrive. All the rules live here, has knowledge of all devices, and keeps their status up-to-date. Different types of commands can be linked to each device and executed for them. Execution happens in prioritized JMS queue. This makes it possible to execute some commands in a predefined order and prioritize user initiated actions above background tasks.

Communication

MosquittoCommunication between the core modules takes place through MQTT. This is connectivity protocol designed for machine-to-machine communication, especially in IoT environments. It’s extremely light weight and provides a publish/subscribe way of communication.

MQTT in this case is used to provide a bus-structure, in a way comparable to the CAN bus used in cars. Each node can publish messages to any topic. These messages will be delivered to any nodes that are subscribed to that topic. For example when Z-Way detects a movement in the kitchen it publishes this to the topic  Thuis/kitchen/movement. Another node is subscribed to this and can take action by turning on a light. This way the coupling between the different nodes is very loose and it’s possible to exchange devices easily.

While MQTT is available for a lot of platforms, it’s not possible to hook up anything directly to it. That’s why some modules use a bridge. The most important examples are the Z-Wave devices. A Z-Wave node can only communicate through Z-Wave with each other and the controller. In this case the controller acts as a bridge to connect it to the other parts of the system. The same is the case for services that have an API, but no extensions, like Plex. For these the Core will act as a bridge.

User interaction

As mentioned in the proposal user interaction takes place in several ways. From the start these are physical buttons (Z-Wave), some iPhones and an iPad. A web and voice interface will be added later. Just like any other modules they communicate through MQTT. To make the interfaces easily adjustable and maintainable several UI components will be developed which will be connected to one or more MQTT topics. They automatically update based on a subscription and can publish messages to a topic when a user interacts with them.

This should give you some more insight in the building blocks of the Thuis system. Next up will be the setup of the MQTT broker and the first integration: Z-Way.

Collecting materials

To make my proposal a reality I need quite some electronics in the house. Luckily we already have several Z-Wave devices and Raspberries in the house, and a sponsored Kit on the way. But what other hardware do we still need?

More Z-Wave devices

DimmersThe entrance, living room, kitchen and office already have most lights controllable through Z-Wave. We do however plan to make this happen in the bedroom (and bathroom) as well to create a wake-up light. For this I’ll order the Fibaro Dimmer 2 or Qubino Dimmer modules, plus some dimmable LED bulbs and switches. Before ordering I’ll try to find out which combination is working best nowadays, because in the office I’m using the first generation Fibaro Dimmer and that one unfortunately buzzes while it’s dimmed. In a later blogpost I’ll let you know which one I choose.

iBeacons

Estimote BeaconsNext to PIRs I’ll be using iBeacons to detect where in the house we are. I’ve chosen the latest generation of Estimote beacons for this. I’ve used the first generation before and they are nice little beacons with a very powerful SDK. Using at least 6 beacons it should be possible to give a quite accurate approximation of your location in the house. I’ll be giving it a try when they arrive.

This generation is brand new, so I had to pre-order them.

MOVE

MOVEAnother pre-order is the MOVE, which is currently available on Indiegogo. The MOVE is a bluetooth controlled motor to motorize existing blinds and shades. There is a micro USB connector as well which can be used to control it, so when it arrives I’ll experiment with both Bluetooth and USB control.

It will be used in the bedroom as part of the wake-up light. The estimated shipping date is currently in June.

HDMI capturing

For the ambilight in the home cinema I intend to use Hyperion. A HDMI splitter will be used so I can intercept the signal to the TV and feed into HDMI-to-RCA converter and a capturing device, which in turn will feed the images into a Raspberry Pi. The software interprets the image and controls the LEDs through an Arduino. Most materials are ordered from AliExpress, so it will probably arrive in about a month.

Patience

Now it’s time to be patience and wait for the arrival of all materials. In the meanwhile I’ll be working on some other parts, more about that in the next post!

 

Sponsored Challenger

Pi IoT Design ChallengeGood news! I’ve been selected as a sponsored challenger in the Pi-IoT design challenge organized by element14. This gives me an extra boost to automate my home and also blog about it. One of the perks is that I’ll receive a very nice kit of materials:

The Raspberry Pi 3 will become the core of the system. Together with the LCD, the other Raspberry Pi will be one of the controllers. Depending on the exact EnOcean sensors they will probably be used next to the current Z-Wave sensors. I didn’t decide yet what the other components will be used for, but I bet something interesting will come up along the way!

To read all about my plans please have a look at the About page. I’m very glad I’ve been chosen as challenger and hope you’ll enjoy my home automation journey!