A few months after the challenge: what happened since?

It’s already been a few months since I wrote my last blog post about Thuis. Although the project isn’t moving as fast as it was during the challenge, it did not come to a standstill. Since then the Ambilight has been re-instated, a start was made on the kitchen UI, support for secondary buttons was added to Zway-MQTT and with some help of the community it was made more robust. And last but not least: we bought our first house: exciting times are coming up! In this blog I’ll give you a summary; I intent to write more detailed followups soon.

Ambilight

At first this seemed like an easy project as the basis was already created years ago by using an Arduino controlling the LEDs and a screen grabber installed on the connected Mac Mini. Since then I’ve switched to using an Apple TV instead and that means the grabber has to take place somewhere in between the AV receiver and TV. It was implemented using a Raspberry Pi running Hyperion and some hardware for grabbing the image (HDMI splitter, HDMI-to-RCA converter and a USB grabber). This all works pretty much out of the box, but often there was an annoying pink blink… Also every now and then the SD card got corrupt and had to be repaired. So far I’ve solved both issues and I’ll write a full blog post about it a bit later.

Kitchen UI

The Kitchen UI is still in a very early development stage. The goal is to have a specialized interface to be used while cooking. It will feature kitchen timers, controls for the kitchen lights and a recipe search. For the latter I reverse engineered the recipe API used by the Albert Heijn (supermarket in The Netherlands) app, so I can easily search for a nice recipe. By using some simple text recognition timers can be created automatically for the times mentioned in the recipe.

Zway-MQTT

My plugin for Zway aims to let it work over MQTT – Zway-MQTT – was released on their app store and is downloaded a few hundred times since. Some users even contributed to the code through its GitHub bringing improved stability, security, better support for thermostats and rolling shutters. I also worked on improving the stability and added support for using secondary buttons (aka scene activation). This will be released soon as part of version 1.3.

A new home for Thuis

One of the reasons it was so silent on this blog was that we were searching for a new home for ourselves. Now that we’ve bought a nice house, we’re busy with preparations for the move in April. This also means we have to plan how we want to move Thuis. Some functionality is quite specific for our current apartment and should work differently for our new home. For example our new house has multiple floors, so there’s a lot to think about. It’s also a good opportunity to expand Thuis even further. I’ll keep you updated!

Final demonstration Thuis

The challenge deadline is almost there, so it’s time for a final demonstration! In this last post I’ll show you the results of my work in a video and then describe what I did and what I’m planning to improve in the future.

Let’s start with the fun part: I present you a relaxed evening at Thuis!

I’ll continue this blog in the same style as my previous Status update and will give you the latest status of all the projects and use cases.

Open Source Projects

These are the projects I made available as open source on my GitHub account during this challenge (or will make available later). They are all set up, so that they can be reused by others in their own home automation projects.

Zway-MQTT

85%

Z-WavePlusProduct_150As described in Publishing activity from Z-Way to MQTT messages are published for each status change. It also subscribes to the responding topics, so you’re able to turn on and off devices through MQTT as well. The topics and devices used are completely configurable. With this all major functionality is done. The last couple of weeks I did several improvements to the reliability. Scene activation is something that still needs some work, so the to-do list remains the same.

To-do:

  • Publish a message on scene activation (e.g. used for each secondary push button on the wall)
  • Get it published on the Z-Way App store, already uploaded June, but still no response
  • Publish energy usage

Zway-MQTT on GitHub

Chef-Zway

100%

ChefMaking sure I can use Chef to fully install the Raspberry Pi 3 I needed to update a few recipes and also to create a completely new one for Z-Way. This was a major hurdle and took more time than expected, but I learned a lot from it. I hope in Cooking up the nodes: Thuis Cookbook you can also find something new for yourself. In Home Theater part 1: CEC I made some small updates as I installed the node connected to the home theatre system by HDMI.

Chef-Zway on GitHub

Plex-client

90%

plexPlex doesn’t allow me to add a plugin directly in the server, but there is an API and WebSockets for status messages. The API and WebSockets are implemented, as is described in Home Theater part 3: Plex playback controls. It is mostly implemented as Java library with a similar set up as I’m using for integrating Java and MQTT. As I have to clean up the project, it will be published at a later stage.

To-do:

  • Publish the code on GitHub

CEC-CDI

99%

The library for using CEC (Consumer Electronics Control) in Java was developed about 10 months ago and performs the most common functionality: monitoring stands-status, turning on/off devices, changing volume and changing outputs. Now it’s also integrated with Thuis and is available through MQTT. For more information please visit Home Theater part 1: CEC.

CEC-CDI on GitHub

MQTT UIKit

90%

interfacebuilderIn MQTT User Interface components for iOS the MQTT UIKit was developed. It now provides a Tile based interface with elements being updated automatically based on MQTT messages. Also several default UIKit elements were extended with MQTT functionality in Home Theater part 3: Plex playback controls.

To-do:

  • Publish the code on GitHub

Use Cases

Light when and where you need it

80%

Multi-Sensor

Sensors are placed in both the kitchen and the entrance room. The Core knows about them and as described in Core v2: A Java EE application rules are defined to turn the lights in those rooms on and off depending on movement and time. This works pretty well already!

To-do:

  • Further optimize the rules
  • See if improvements can be made by using iBeacons

Welcome home

100%

The iBeacons are placed at several locations in the house, providing a good coverage to detect if you’re arriving home. When you arrive home a notification is sent, which allows you to directly start up the home theatre system.

You can read about this in Presence monitoring using iBeacons.

Home Cinema

90%

Home Cinema

The Z-Wave hardware for the home cinema is in place (using a 6-socket PowerNode), so it can be turned on and off. Using the above mentioned Plex and CEC integration we can fully manage the home theatre system. An extra Raspberry Pi 1B was placed next to the TV to control devices through HDMI CEC. This is described in Home Theater part 2: controls. The Ambilight will be finished at a later stage.

To-do:

  • Add and integrate a DIY ambilight

Mobile & On-The-Wall-UI

100%

iPad on the wall

The app is running and fully functional, as you can see in Final implementation UI design, you can manage devices in the house and see the latest status. A wish is still to add a speech control to the iPad app. In the kitchen we have an iPad mounted on a cabinet as well, for which I would like to create a separate app with additional features like a cooking timer and a recipe browser (my girlfriend supports this idea a lot :). Another option is to use a Raspberry Pi plus display, which will be integrated in a cabinet door.

Todo:

  • Add speech commands
  • Create a custom app for the kitchen (either iPad or web)

Wake-up light

10%

Work hasn’t started yet on the Wake-up light as one of the key components (the MOVE) is not delivered. And as this is an Indiegogo project it’s still not certain when it will be delivered. I did experiment with emulating a Hue bridge to make sure Sleep Cycle can communicate with Thuis and unfortunately I could not get this working properly yet. Nevertheless, one to-do is fully fixed: the main light in the bedroom is now dimmable through Z-Wave.

To-do:

  • Sleep Cycle doesn’t have a web hook available yet, so it’s still needed to set up a Philips Hue bridge
  • Install and integrate the MOVE

Manual override

80%

Wall Switches

Most lights can already be switched manually using the buttons on the walls. Some of them should however be switched using the secondary button, which does a scene activation. I still have to add support for this to the Zway-MQTT.

To-do:

  • Add support for secondary buttons in Zway-MQTT

Energy monitoring & saving

10%

For energy monitoring I only did some research. InfluxDB seems to be a good candidate for storing the data. Unfortunately I wasn’t able to work on this use case during the challenge, but I’ll come back to this in a later stage.

Todo:

  • Let Zway-MQTT publish energy usage
  • Integrate YouLess to record total energy usage of the house
  • Create reports based on the usage

Future

I already mentioned some future plans, a few of those I want to highlight.

Wake up light

It would be great to wake up with light that feels like a sun rise. In the summer managed by actually letting the sun in by raising the curtains, in the winter by using an electronic light. For this use case I’m currently very depended on external parties, which is the reason this part of Thuis is postponed to the later stage.

Kitchen control

Tools which are used a lot in the kitchen are a timer and a recipe browser. The plan is to integrate these both in an easy to use app which is always available on one of the kitchen cabinets doors. It can be used to override the automatic schedule as well, for example when we get home later than usual and still want the full light for cooking.

Ambilight

A few years back I’ve built an Ambilight for my TV. However this is based on an a Arduino connected to Mac Mini. It’s therefore only usable when the Mac Mini is the source of the video. As we’re mainly using a Apple TV nowadays, the Ambilight can’t be used. I will use a HDMI splitter and grabber connected to a Raspberry Pi 2B to replace the Mac Mini and make it possible to enable Ambilight for videos from all sources.

Various

  • Using presence information for improved automation
  • Saving usage data and energy usage to a database for data mining
  • Integrate a robotic vacuum cleaner
  • Add voice control

Summary

It feels so weird, but with this paragraph my last blog of this challenge comes to an end. Over the last couple of months I’ve been able to set up a very nice home automation system at my house. It was a hard job to get everything done on time and especially describe all of it in writing, but I’ve managed well and I’ve enjoyed the process a lot! Thanks again to element14 for selecting me as a sponsored challenge and for giving me the inspiration and motivation to work on Thuis!

Home Theater part 3: Plex playback controls

plexPlex is software which makes it possible to enjoy all of your media on all your devices. When on the server you create a library based on video (and music, photos, etc) files, Plex finds the corresponding metadata and gives you an easy to use interface to browse and play your movies. You can interact with Plex through its API and you can keep up-to-date with what’s happening on each client by subscribing to the WebSockets channel. In this last part of the Home Theater series we’ll integrate Plex in Thuis.

Plex API

Official documentation for the API is not publicly available, but luckily some other developers are maintaining  the up-to-date wiki about it. For now we’ll use the API just for basic playing controls. As time is limited and the calls are simple, we’ll execute them directly from iOS:

As you can see there are four control  @IBActions available: to play, to pause, to stop, and to scrub forward and backwards.

Nevertheless there are many more possibilities: something I am currently working on and would like to implement a bit later makes it possible for a user to select a TV series episode directly from the iOS app.

Plex Notifications

To get notifications when the play state changes one can subscribe to the WebSocket of the Plex server. The URL for the WebSockets channel is the following:  ws://localhost:32400/:/websockets/notifications. There are multiple types of messages posted, but we’re only interested in  PlaySessionStateNotifications. It has the following fields:

The other interesting fields are state (playing, paused, etc), viewOffset (how many seconds is the video already playing) and key (identifier used to get information from the API). The code that is directly communicating with Plex is placed in a separate library. Just like for MQTT and CEC it uses CDI events to present the notifications to Thuis. In Thuis we have the PlexObserverBean handling the notifications:

When the notification has at least one child – we take the first one. If the Plex client is playing and the lights in the kitchen are still on, we are turning the lights off. Then we publish the play state and offset to MQTT. When it’s the first notification we get for the key we query the LibraryService, which calls the API to retrieve more information on the video. With all this information available through MQTT we can use it in our iOS app.

iOS

In the iOS app we will add a new view for displaying what is currently playing. When we receive a PLAYING message on Thuis/homeTheater/state we’ll automatically open it. The button to open it manually will only be available when there is something playing. For this we update our TilesCollectionViewController:

The nowPlaying view itself is composed using some  StackViewsUILabels and UIImageViews. The interesting thing about them is that these default iOS UI elements themselves are MQTT subscribers and update their content based on messages on the corresponding MQTT topic. This is possible because of two features of Swift: extensions and protocols. For example the UILabel can be made aware of MQTT as follows:

Similar extensions are made for the other elements. The result looks like this:

iPad: now playing

Following these steps we set up the Home Theater flow to our iOS app and made sure everything works smoothly. In my opinion it still needs a bit of fine-tuning, but even now it works pretty well!

Home Theater part 2: controls

In Final implementation UI design you saw our Thuis iOS app, which has a few buttons for controlling the Home Theater. In this post we’ll make sure they work well. For brevity I will describe only the main scene: it makes sure we can watch anything on the Apple TV.

Defining devices

Before we can use any devices in Thuis we have to define them. You might remember from Core v2: A Java EE application that we have a class Devices containing static definitions. Here we will add the devices we need for the home theater system:

The bottom 2 are Z-Wave outlets, which you’ve seen before. All the others are new types of devices. Below we’ll describe each of them separately.

TV

Sony Bravia EX700Let’s start with the easiest device: the television. With the work we did yesterday in Home Theater part 1: CEC we can turn the TV on and off by sending a simple MQTT message. Because of that it’s defined as a MqttSwitch.

 

Apple TV

Apple TVThe Apple TV is a great device as the centre of the home theatre. It is able to control other devices through CEC, but unfortunately you can’t control it yourself through CEC. So I had to look for an alternative and I found it in AirPlay. Xyrion describes it well how you can wake up an Apple TV by connecting to it using Telnet and telling it to play some bogus video.

In Java we can do this by using a Socket. For this we’ll create a new Command, the SocketCommand:

We use this command in the definition of the AppleTV itself. By extending MqttSwitch we can leverage the logic for updating its status from MQTT. I’m not entirely sure how we can turn off the Apple TV programmatically, so this method is not implemented yet.

 

Receiver

Denon AVR-X2000My AV receiver is Denon AVR-X2000. CEC support on this device is limited, but luckily there is an API. Unfortunately, the API is not documented, but by using the web interface I could reverse engineer it. While it’s starting up there are some quirks though as it can take quite a while before the Denon is reachable through the API (while it already works by manually pressing the power button). Because of this we’ll use a combination of both CEC and the API.

Firstly lets create the Receiver class itself. It’s a implementation of MqttSwitch, so the CEC part is easily taken care of. We do override the on() method to make sure it’s only fired when needed as this command toggles the power status for the Denon. To get more detailed information on the status and to change volume and inputs we use the API. The API calls are performed by a DenonCommand.

Due to the time limitations I won’t go into the implementation of the API in this post. If you would like to find out more details about this topic, there is a valuable article by Open Remote describing the key possibilities.

NAS

ReadyNAS Ultra 4The NAS runs the Plex Media Server. When nobody is home, the NAS is not used and is turned off by default. The NAS supports Wake-on-LAN (WOL), so we can use this to awake it to make Plex available.

For WOL I use a nice little library and built a command around it:

As the Computer class used for the NAS is just a basic implementation of an  Actuator using the WakeOnLanCommand for the wake() method, I would not present the source code here.

Scenes

Now when we almost have all the devices set up we can combine them in scenes. Let’s start with some code:

Here the scenes are split in two. The homeTheaterBase is the basis for all different home theater scenes: e.g. the one for the Apple TV is displayed here, or the one for Blu-ray. It also allows me to switch from one to another without turning everything off.

As you can see lots of commands are dependent on each other, so devices have to wait for some other devices before starting up. The most obvious case is that you first have to turn on the power before you can turn on the device itself, or give the device more commands.

The receiver has a special qualifier waitForFullOn: this is because it has two stages of powering on. Firstly CEC reports it’s turned on (this is the normal on-state) and later the API reports the powered-on status as well (the full-on-state). We’re interested in both of them as it’s not possible to send any commands through the API before it reaches the fully-on-state.

Time for a quick demo:

Note: as this is the demo, the launch takes a bit of more time then usually. Please be patient 🙂

There is one thing left to integrate: Plex! This will be the subject of part 3.

Home Theater part 1: CEC

An important part of Thuis is integration of our Home Theater system. As the integration is quite extensive and consists of several components, this will be a 3-part blog series. In the first part we start with communicating to CEC-enabled devices from a Raspberry Pi. In the second part we will integrate CEC with the rest of Thuis, and make sure everything works properly together. In the third – and last – part of the Home Theater series we will add the support for Plex.

Home Cinema

CEC

HDMILet’s start with a short introduction of CEC itself. CEC stands for Consumer Electronics Control and is a feature of HDMI. CEC enables HDMI-devices to communicate with each other. In the ideal situation this means a user only needs one remote control to control all his devices: TV, AV receiver, Blu-ray player, etc. Unfortunately many manufacturers use their own variation of CEC and therefore in a lot of cases one still needs multiple remotes. To get an idea about the protocol have a look a CEC-O-MATIC, this is a great reference for all available commands!

The good news is that the GPU of the Raspberry Pi supports CEC out of the box!

libCEC

To be able to handle the different dialects of CEC, Pulse Eight developed libcec. It enables you to interact with other HDMI devices without having to worry about the communication overhead, handshaking and all the differences between manufacturers. In contrast to what I mentioned in Cooking up the nodes: Thuis Cookbook Raspbian Jessie nowadays provides version 3.0.1 in the Apt repository, so there is no need to use the version from Stretch anymore. I’ve updated the cookbook accordingly. Other than that provisioning the Raspberry Pi using Chef was straightforward.

libCEC comes with the tool cec-client. This basically gives you a terminal for CEC commands. When we execute cec-client you see it connecting to HDMI and collecting some information about other devices, then we can give it commands. For example we ask it for all devices currently connected with the scan command:

// indicates a comment added by me, // ... indicates output that was hidden as it’s not needed for understanding

As you can see currently 4 devices are connected to the bus, including the Raspberry Pi itself (device #1). The Apple TV is the currently active source. You can tell cec-client which output it should give with the -d parameter. We’ll use this for our integration by choosing -d 8, which just displays the traffic on the bus.

CEC-CDI

To integrate libCEC (or more specifically cec-client) with Java we have to write a wrapper around it. We’ll do that in a similar way as MQTT-CDI, so the Java code can observe events happening on the CEC-bus via a CDI observer. I wrote the initial version about a year ago and the full source code is available on my GitHub as Edubits/cec-cdi. It does not support the full CEC protocol yet, but most of the usual commands are available. For example you’re able to turn on and off your devices, and send UI commands like play, pause, volume up, etc. You can of course also monitor these same functions, so the app will for example know when you turn off the TV manually.

You can add CEC-CDI to your own project by adding the following dependency to your pom.xml:

Monitoring what happens in the home theatre system can be done using CDI observers. Currently you can just add a qualifier for the source device, later I might also add some more sophisticated qualifiers such as the type of a command. When you’re interesting in all messages send from the TV you can observe them like this:

To turn the TV on you can send it the IMAGE_VIEW_ON message without any arguments, for putting it in standby you use the STANDBY command. In Java this looks as follows:

ThuisServer-TV

Just like the Core application described in Core v2: A Java EE application, this will be a Java EE application running on WildFly. It includes CEC-CDI. The application itself is quite simple as it’s only function is bridging between CEC and MQTT. So we have two @ApplicationScoped beans observing events.

The CecObserverBean forwards specific messages from the CEC bus to MQTT. In the example it monitors the power state of the television. Note that my Sony television has its own dialect as well, depending on how the TV is turned off it reports the official  STANDBY command or gives a vendor specific command. When turning on it’s supposed to report a certain command as well, but the Sony decides to skip it. That’s why – as workaround – I listen to REPORT_PHYSICAL_ADDRESS, which is a command it always gives during power on.

The opposite happens in the MqttObserverBean, which listens to MQTT messages and executes the corresponding CEC commands. Here we’ll turn the TV on and off and then ask the TV to report its power status back:

This concludes our implementation of the TV node. It’s now able to listen to other CEC-enabled devices, communicate with them and bridge this through MQTT messages. In part 2 we’ll take these MQTT messages, wrap them and create some scenes to turn everything on with a single button!

Presence monitoring using iBeacons

One of the goals of Thuis is optimizing it’s own rule engine based on actual activity in the house. Although time is to short to actually start the optimization, with this blog we’ll start collecting presence data using iBeacons. As a bonus we solve the Welcome Home use case!

iBeacons monitoring, ranging and indoor location

Estimote BeaconsiBeacons (in my case by Estimote) are little Bluetooth LE devices which on regular intervals broadcast their identifiers. Mobile apps can use this as a way of determining their location. They can be used in several ways. The three most common ways are:

  • Monitoring – the app gets a signal whenever it enters the region defined by one or multiple beacons (aka when it receives a packet sent by the them). The app gets a small amount of time to do some work, for example notify the user. This works even when the app is terminated.
  • Ranging – When the app is active it can listen to all beacons around and based on the signal strengths make an approximation of the distance between the beacon and the phone.
  • Indoor location – Estimote developed another layer on top of ranging. Based on several beacons (at least one per wall) and the sensors in the phone it can determine its location within a space. This works quite precise, but it uses more energy than the other methods. Also it can only be used when the app is in use.

I experimented with all three to see which way is most usable for Thuis. Indoor location was a bit of a hassle to set up (it involves walking lots of circles close to the walls through the house, which is not easy when there is furniture!), but the result is impressive. Not being able to use it in the background made me choose monitoring as the main technique.

ps: for the Android users out here: although I’m talking about iBeacons (by Apple) there are very similar technologies available for other platforms. For Android that’s Eddystone, which is the Estimote beacons can broadcast as well.

Presence monitoring

To optimize the Thuis rule engine it needs to have knowledge of what happens around. One of the useful things to now is who is where and when. We’ll use presence monitoring to determine who is currently where in the house.

Hardware set up

Estimote iBeacon settingsWe want to know who is where on a room-level, so who is in which room. To identify different rooms we’ll deploy a iBeacon is every room we’re interested in. We’re using 3 Estimote Location Beacons and 3 older Estimote Proximity Beacons. In the entrance, living room, bedroom, kitchen and office 1 beacon is installed at the center of the outer wall (as far as possible from other beacons). The signal strength of each of them is tweaked ranging from -30dBm (±1.5 meter) in the smallest rooms to -20dBm (±3.5m) in the bigger rooms. Each beacon is configured to broadcast its ID approximately 3 times per second. These values will likely be optimized further over the coming period.

Initial version

I started by using just region monitoring as this is very easy to implement. To make my life easier I started with some structs describing the deployed beacons together with some helper functions. The interface of the struct looks like:

And the beacons are defined as:

All code related to beacons takes place in the class BeaconManager. It sets up monitoring in the init method and implements the delegate methods for the ESTBeaconManagerDelegate. It keeps some information about which is the current region for this phone and for each beacon when was the last time this phone entered or left the region. The initial version just logs information to the console based on activity.

This already works quite well, but as we’re working with wireless signals there can be mistakes. For example a packet from another room reaches your phone and therefor your presence is adjusted. Or some packets get lost and cause your phone to think it left the region.

The latter is the reason that for resetting the currentPresence to outside we use the home region. This region consists all beacons, so the change of a false positive is smaller. It does however still happen every now and then.

Improving accuracy with ranging

To make presence monitoring more accurate we can combine monitoring with ranging. When the app is in the background and enters a region it’s woken up and gets a small amount of time to do some work. We can use this time to start ranging beacons, and with the more detailed data about the beacons around us make a better approximation.

To start ranging we have to adjust the didEnter method, instead of updating currentPresence and lastLeftOrEntered we start ranging:  beaconManager.startRangingBeacons(in: BeaconIDs.home.asBeaconRegion) . To receive the results we’ll implement the corresponding delegate method in which we’ll update the values:

Notice we’ll take the first beacon (with a known proximity) from the given list. The SDK returns them ordered from close to far away, so we’ll always use the closest beacon. Our value of currentPresence got a lot more accurate now!

Based on how it performs I’ll do some further optimizations. One thing I still have to do is make the values of  currentPresence and  lastLeftOrEntered persistent, so they will survive a termination of the app.

Publishing presence

As always we want to publish our data through MQTT, so the other Thuis nodes can use it as well. In MQTT User Interface components for iOS we added MQTT to the app, so we can build on this. Whenever the currentPresence value changes we’ll have to publish a message. This means we have to update both the didRangeBeacons method and the didExitRegion method.

didRangeBeacons is updated like this:

And to detect someone leaving the house we change didExitRegion, here we only publish when the specific region is home:

Note that the name in the topic is still static, I’ll make it configurable in the app later.

Walking around slowly through the house gives the following MQTT messages:

Welcome home

Based on the same events we can welcome a user home as well and directly give him a useful action. I could directly turn on some lights for example, but I rather give the user the choice. So we’ll send the user a notification with an action. We’ll start with a single action, but later multiple actions can be added depending on for example the time or person.

When we get home we often watch an episode of a TV series (currently we’re watching The Mentalist, very nice show!), so the action of choice will be turning on the home theatre system.

Sending a notification is easy. In the BeaconManager we create a function for it:

We’ll call it from the didEnterRegion method when we enter the home region. To avoid getting too many notifications in case of exiting and entering the region by accident we’ll add a cool down period of 5 minutes. This looks as follows:

The result is you receive this notification when you arrive home:

Notification: welcome home!

To make it work there is one more thing to do and that’s implementing another delegate method, this time in the AppDelegate:

So when the notification action is used it will publish a MQTT message which enables the Home Theater scene and you can directly start watching your favorite series. How the home theater scene works will be the subject of the next blog!

 

Installing a Z-Wave dimmer

One thing I forgot to show you earlier is how to install Z-Wave devices into your house. In this post I’ll install a dimmer module in the bedroom, which will be part of the wake up light.

Materials used

The materials I’m going to use are the following:

Used materials

  • Fibaro Dimmer 2 – the actual Z-Wave dimmer
  • Fibaro Bypass 2 – needed when using LED lights
  • Philips Dimmable LED – 6W/470lm (comparable to 40W), warm white
  • Jung 535 EU – 2 push buttons
  • Some electrical wire

Installing the dimmer step-by-step

Now we have all materials, let’s start the installation. There are two possibilities to connect the dimmer, depending if you have 2 or 3 wires available. In our case we just have 2 wires available behind the outlets, so we’ll have to consider the following wiring diagram:

Wiring Diagram

We’ll go through the installation step-by-step.

0. Cut the power

For your own safety always cut the power when working on your lights. Find out in which group your light is placed and disable the power for this group.

1. Prepare the dimmer

Prepare the dimmer and push buttons by connecting them together. It’s best to do this now, as while you’re not working on the wall yet you have plenty of room.

Prepare the dimmer

2. Install the dimmer

Now install the dimmer and buttons in place and connect the live and switch wires. Push everything inside to check if it fits, but don’t close it with screws yet.

Install the dimmer

3. Install the bypass

As we’re using a LED light bulb we need to use a bypass. This makes it possible for the dimmer to function on low loads. It’s best to install the bypass close to the light itself, so we’ll install it above the light. (in my case this is also the only place where it fits, as space behind the buttons is very tight) 

Installation is easy as you just have to connect both ends to either side of the bulb (direction doesn’t matter). Here I’m using a screw terminal. The black and blue wires will go to the light itself.

Install the bypass

4. Connect the light

Now connect the light itself and screw in a light bulb.

Plug in light bulb

5. Include the light in Z-Way

The wiring is ready. You can now enable the power again. To use the light we have to add it to the Z-Wave controller: Z-Way. For this you go to http://server-ip:8083 and then move to Settings > Devices. Here you click the Add new button. Click the Start inclusion button. You’re controller is now in inclusion mode. To include the new dimmer you have to activate it; for this dimmer you can triple click the button connected to S1.

Z-Way inclusion

After a while inclusion should be finished and you can test the light!

In my case the interview part of the inclusion could not finish successfully. This is a known problem with this dimmer and Z-Way and hopefully will be fixed soon. The basic features of the device are luckily working as they are supposed to.

6. Test!

And there was light:

And there was light!

By clicking the S1 button you can turn on and off the light. By holding it you can dim it. A nice surprise was that this is the first combination of dimmer/LED which doesn’t make any noise while dimming!

7. Finish up the buttons

Now that we verified the light works, the only thing left is finishing up the buttons. Screw it on its place and click the buttons in their socket.

Install buttons

Add the new light to Thuis

The physical part is done, but we of course want to use the light within Thuis. For this we have to do a few steps as well. As described in Publishing activity from Z-Way to MQTT we name the device and add it to a room. We also add the tag mqtt as that’s how I configured the MQTT app for Z-Way. The light is now controllable through MQTT.

Next is to add it on the Java side in the Core. This is described in Core v2: A Java EE application. We add the device by adding a line to the Devices class:

The bedroom light is now ready to be used in any rules, or to be controlled from other devices as the iOS app.

 

Final implementation UI design

From my holiday location at the coast of Bulgaria I finished up the implementation of the UI of Thuis. It works nicely on both the iPhones and the iPad on the wall. This blog will give you a demo and bring you up-to-date with some of the changes I made since the last post.

iPad on the wall

Adding the Slider Tile

I already implemented the UICollectionViewController and several tiles in the last blog post, however it was lacking the SliderTile implementation. For this several changes were needed, for example a tile should be able to span multiple columns to create enough space for the slider. For this a new property is added to Tile called columns. It now looks like this:

UICollectionViewController can handle cells of different sizes,  so making sure they display correctly is luckily easy:

Now we can actually implement the SliderTile itself. First we add the slider to the UI:

TileCollectionViewCell.xib with Slider

The TileCollectionViewCell class got some more functionality now. To make things easier I moved some of the logic from the TilesCollectionViewController to here. It now takes care of deciding what to show and what to hide. For example the value will be hidden when there is no value (for buttons) or when a slider is used (the slider already visualizes the value).

To handle changes of the value when someone uses the slider a delegate method had to be added. The slider is linked to the delegate method in the TileCollectionViewCell, but this delegates the actual work to the SliderTile. This class also has some properties defining the slider, such as the minimum and maximum allowed values, and takes care of updating the slider when a MQTT message arrives.

Adding a optional postfix to values

Some of the InfoTiles show the weather, and for the temperature it’s a lot clearer when we include a degree sign next to the value. So I’ve added an optional postfix to the value of a Tile. This is a simple String property which is added at the end of the value before display:

Changes to support iPad

The iPhone and iPad have a very different screen size and of course we don’t want to duplicate any code, or add checks everywhere. Luckily for us Apple solved most of this by providing adaptive layouts and layout constraints. We’ll use the latter to slightly change the layout of the TileCollectionViewCell to adapt to the bigger screen. Apple differentiates between devices by using so-called size classes, which are very well described in The Adaptive Model. There are two changes we have to make: change the icon size and the width of the slider. The icon will be 45 points on compact-width devices and 70 on regular-width devices. The slider will get a width of 200 points on compact-width devices and 400 on regular-width devices.

Determining the size of the cell was already working well on all devices as it’s using a size based on the size of the superview. You can see the implementation of the slider above.

Demo

The implementation of the design Marina made for the Thuis app is now implemented, and how better to show it then with a demo:

In the demo you can see the different screens on both an iPad and an iPhone. At the bottom you can see the MQTT messages being send and received. Notice that when clicking a button a message is send to the set-topic (for example Thuis/device/living/moodTop/set) by the iOS app. Then a message is received on the status topic for that device ( Thuis/device/living/moodTop), which is sent by Zway.

When a scene is triggered (in this case Mood, which are the mood lights in the living room) you see the Core sends a message for each device in that scene. The status is also reflected on the iPhone. The slider for the main light in the dining sends out messages every time when you pause for a tenth of a second.

This should give you a good overview of the app and its design. Off to the next use case!

MQTT User Interface components for iOS

How useful would a home automation system be where you could only interact through MQTT messages? Not very, so that’s why we’ll start working on the User Interface today. The goal is to create some generic UI elements, which can be linked to the MQTT topic. The element will display the current status clearly and will let the user interact with it.

For now there will be three types of UI elements, which can be placed in a grid of tiles. These elements are:

  • Button – a simple push button. The background visualizes the state and tapping it will toggle the state.
  • Slider – a slider to be used for e.g. a dimmer module. The position on the slider shows the current state. Minimum and maximum values can be defined.
  • Info – a tile without any interaction. Just displays the current state of for example the temperature.

Each tile can have some properties defining how it looks. Options include a title, an icon, a value and the selected state.

ps: if you’re familiar with Swift and UIKit, you might notice that – for the purpose of learning – I’m using Swift 3 and iOS 10. They are still in beta and will be available in fall. 

MQTT Client

Before we can define the UI elements, we need a connection to MQTT. For this we’ll use Moscapsule, a MQTT library written in Swift. Making a connection is quite simple. We do this by creating a configuration, adding some callback blocks and opening the connection:

As you can see we don’t do anything yet in the callbacks, except for logging. We’ll arrange that later; let’s firstly create the UI elements themselves.

Tiles: data model

All types of tiles share some attributes. One of these is an array of MQTT topics to which this tile will be subscribed. The common attributes are defined in the base class Tile, including an enum for annotating topics and a protocol for making a tile selectable:

For each type of Tile a subclass exists. They describe any additional properties needed, plus they define what happens when a MQTT message is received. Let’s take the button as an example:

User Interface

The model doesn’t say anything about how the tile will look on screen, it just focusses on managing the status. So what about the UI? For that we use the TileCollectionViewCell, which is a subclass of UICollectionViewCell. It is defined using a nib-file and structured by using Stackviews:

TileCollectionViewCell.xib

The corresponding class is a simple subclass of UICollectionViewCell which takes care of the border radius and hides the value label if there is no text defined (due to the Stackview that results in the icon being centered above the title). The heavy lifting happens in the TilesViewController, which is a UICollectionViewController. It has a property to hold a list of Tile objects. To high light a few parts: in viewDidLoad all tiles are subscribed to their respective MQTT topics:

It also subscribes itself to the same topic, so it can reload the UI when new messages are coming in:

The only part missing is the interaction. When you select one of the cells it will publish a message to the defined ‘set’-topic and update the internal state of the tile:

Putting it together

To put it together we create multiple instances of the TilesCollectionViewController and add them to a UITabBarController. Each instances overrides a single method defining the tiles. For the icons we use a library which enables us to use IonIcons instead of images. The home screen displays the most-used tiles:

This brings us the result of this blog post: a working iPhone app which communicates with Thuis through MQTT.

Screenshot

When messages arrive on the status-topics, the selected-status of the button-tiles and the value of the info-tiles are updated. When one of the button-tiles is tapped a message is send to the set-topic with the new status. As described in Publishing activity from Z-Way to MQTT this is already picked up and executed.

You probably do notice that it looks very plain yet: we’ll fix this in a next blog post. We’ll also add some more controls, like slider, which can be used for dimmers and a volume control.

Status update

I’ve been busy with a few other things, so that’s why it has been silent on the IoT front. As I also just past half of the blog posts, I thought this would be good time to reflect on the plan and report the latest status. In this blog I’ll go through all projects/libraries and use cases presented in the plan and show the status. Some to-do’s are marked italic: these might happen after the challenge deadline.

Open Source Projects

These are the projects that I’m making available as open source on my GitHub account during this challenge. They are all set up so that they can be reused by others in their own home automation projects.

Zway-MQTT

80%

Z-WavePlusProduct_150As described in Publishing activity from Z-Way to MQTT messages are published for each status change. It also subscribes to the responding topics, so you’re able to turn on and off devices through MQTT as well. The topics and devices used are completely configurable. With this all major functionality is done.

To-do:

  • Publish a message on scene activation (e.g. used for each secondary push button on the wall)
  • Get it published on the Z-Way App store, already uploaded June, but still no response
  • Publish energy usage

Zway-MQTT on GitHub

Chef-Zway

100%

ChefMaking sure I can use Chef to fully install the Raspberry Pi 3 I needed to update a few recipes, but also create a completely new one for Z-Way. This was a major hurdle and took more time than expected, but I learned a lot from it. In Cooking up the nodes: Thuis Cookbook you can learn more about it.

Chef-Zway on GitHub

Plex-client

30%

plexPlex doesn’t allow me to add a plugin directly in the server, but there is an API and WebSockets for status messages. For now only some research has been done and some models set up. It will be implemented as Java library, likely with a similar set up as I’m using for integrating Java and MQTT.

To-do:

  • Set up projects
  • Implement models and client code for API
  • Implement models and client code for WebSockets
  • Forward events through CDI and MQTT

CEC-CDI

50%

The library for using CEC (Consumer Electronics Control) in Java was developed about 10 months ago and already performs the most common functionality (monitoring stands-status, turning on/off devices, changing volume and changing outputs). However it should still be integrated with the remainder of the system.

To-do:

  • Integrate library with Core
  • Forward messages through MQTT

CEC-CDI on GitHub

MQTT UIKit

20%

interfacebuilderThe work on the MQTT UIKit for iOS is just started and will be the subject of the next blogpost. The goal is to provide reusable UI elements which update their status by subscribing to a MQTT topic and are able to send messages as well.

To-do:

  • Implement several UI elements (button, slider, info)
  • Integrate them with MQTT
  • Build an app around them

Use Cases

Light when and where you need it

80%

Multi-Sensor

Sensors are placed in both the kitchen and the entrance room. The Core knows about them and as described in Core v2: A Java EE application rules are defined to turn the lights in those rooms on and off depending on movement and time. This works pretty well already!

To-do:

  • Further optimize the rules
  • See if improvements can be made by using iBeacons

Welcome home

The implementation of this use case is mostly dependent on iBeacons being in place. As they are finally delivered, I can start setting them up.

To-do:

  • Set up iBeacons
  • Integrate them with the iOS app (which will publish MQTT messages about their current location in the house)

Home Cinema

30%

Home Cinema

The Z-Wave hardware for the home cinema is in place (using a 6-socket PowerNode), so they can be turned on and off. As mentioned above the Plex and CEC libraries are work in progress. When these are there we can make a full integration.

To-do:

  • Finish Plex and CEC libraries
  • Set up a Raspberry Pi for the CEC communication
  • Integrate them with the Core
  • Add and integrate a DIY ambilight

Mobile & On-The-Wall-UI

15%

iPad on the wall

Work on the iOS UI elements is just started. Further development of the iPhone and iPad apps depends on this. The iPad is already mounted on the wall though!

Todo:

  • Finish MQTT UIKit
  • Create an app for the dashboard (both mobile and On-The-Wall)
    • Provide basic actions (turning on/off device, triggering scenes and providing information)
    • Show the current movie playing in Plex and pause/start
    • Add speech commands
  • Create a custom app for the kitchen (either iPad or web)

Wake-up light

Work has not started on the Wake-up light, mainly because one of the required components (the MOVE) is not delivered yet. As it’s an Indiegogo project, it’s not certain when it will be delivered. I’m not counting on it for the duration of the challenge. I will start on the wake-up light with only bedroom light gradually turning on.

To-do:

  • Sleep Cycle doesn’t have a web hook available yet, so it’s still needed to set up a Philips Hue bridge
  • Install Z-Wave dimmer in the bedroom
  • Install and integrate the MOVE

Manual override

80%

Wall Switches

Most lights can already be switched manually using the buttons on the walls. Some of them should however be switched using the secondary button, which does a scene activation. I have to add support for this to the Zway-MQTT.

To-do:

  • Add support for secondary buttons in Zway-MQTT

Energy monitoring & saving

10%

For energy monitoring I only did some research yet. InfluxDB seems to be a good candidate for storing the data. As time is running out, I’m not sure if I’ll be able to fulfill this use case.

Todo:

  • Let Zway-MQTT publish energy usage
  • Integrate YouLess to record total energy usage of the house
  • Create reports based on the usage

Summary

Up to now I mostly set up infrastructure and backend code. It’s now time to really start implementing the selected use cases. This is what I will focus on for the upcoming weeks. Although there is only 1 month left until the deadline, I’m confident I can implement most of them on time!