I am still continuing my efforts to understand and expand our BTicino MyHome automation system. So far I’ve been able to move the system to software-based configuration and replaced our broken F420 scenario module with the more advanced MH202 scenario programmer, now I am looking at expanding the system and adding new functionality.

As first step I planned to add wireless components to integrate a few lamps and add light switches in places without connection to our bus. Those new components should seamlessly integrate with the existing system: wireless components should be switchable by our wired controls and from within the MH202 scenarios; vice versa wireless switches should be able to control both wireless and wired devices.

In this post I’ll describe the components I choose for this expansion and the steps needed to tie them into our existing BTicino system.

While it has its advantages to stay within the ecosystem of one vendor, sometimes a best-of-breed combination of different products will lead to a better solution. In this particular case I was looking at the ZigBee wireless solutions from BTicino/Legrand, and also their MyHOMEServer1 with the Home + Control app and support for voice assistants, but in both cases found them too limiting. There is a gateway available to integrate the ZigBee solution with the wired MyHome components, but it seems to work only one way, with wireless remotes controlling wired devices. And the new mobile apps from BTicino/Legrand unfortunately do not support many of their older actuators and controls that we still have in use in our system. Therefore I started to look at products from other vendors and for a vendor-independent home automation platform to be able to integrate those into our system.

In this post we’ll cover:

• The choice of openHAB as integration platform and Shelly for wireless components.
• Installing and setting up openHAB.
• Modelling the BTicino and Shelly systems in openHAB, including a workaround for implementing BTicino group commands not supported by openHAB.
  
• Building the bridges between BTicino and Shelly in openHAB.

So, without further ado, let’s dive right into it …

OpenHAB as Integration Platform

Two of the most widely-used home automation platforms are Home Assistant and openHAB, both freely available  as Open Source and able to integrate with the BTicino MyHome products we use. Although a few years old, I found the bachelor thesis of Pirmin Gersbacher an interesting read, comparing those two platforms and also ioBroker and NodeRED.  His personal recommendation is openHAB as in his view it offers the best compromise of features, complexity and community support. Still, I was looking at Home Assistant as well but one of my requirements was voice assistant integration and Home Assistant relies on a paid cloud service for that, while with openHAB it could be achieved without additional costs. The final decisive factor for me was also not technical but the active BTicino discussion thread I found in the openHAB community. During my previous work with our BTicino system the folks there have been very helpful and that kind of support means a lot when starting as a beginner in a completely new field.

So I decided to go for openHAB and try it out as integration platform for expanding our BTicino system.

Shelly for Wireless Components

One of the guys in the openHAB community recommended the wireless components from Shelly, and I also found their wide range of products quite appealing. Particularly I was interested in the 1PM Plus and Plug S for connecting power outlets and lamps to our system, and the Button 1 as wireless light switch. They use standard WLAN connections and therefore do not require any additional base station or gateways to connect to our local network. Since those components are relatively inexpensive, I just went ahead and ordered two of each for testing.

The 1PM Plus can be used in existing in-wall installations, e.g. behind traditional light switches or power outlets, or built into devices. It can connect an existing physical switch and integrates it quite neatly. You can switch the device on and off from the Shelly system regardless of the position of the physical switch and when you switch the device with the physical switch it will update the Shelly system accordingly. In the photo below you can see the 1PM built into one of our lamps and connected to its switch.

Where there is no space for the 1PM, or if you don’t want to touch your electrical wiring, the Plug S is an inconspicuous device that goes between your power outlet and your device.

The Button 1 is a neat little device for controlling other home automation components. It only has a single button, but can still trigger six different actions, depending on how that button is pressed (single, double or triple press, long press and other combinations). What it lacks is a wall-mount, but you’ll find some 3D-printed options for that on Ebay.

The 1PM Plus built into a lamp …

… and the Plug S used to connect another lamp.

The Shelly Button 1 in its 3d-printed wall mount.

The installation and configuration of the Shelly components went pretty smoothly. For the Plug S just install the app and follow the instructions it gives you, for the 1PM Plus you might want to have a look at the user guide for correct wiring first. If you are looking for anything else, the Shelly Knowledge Base is a good place to start.

Assign Static IP Addresses

For the next steps it is important to assign static IP addresses to your Shelly components. OpenHAB stores those addresses, and looses the connection to the components if they change dynamically. Ideally you’ll assign static IP addresses to the MAC addresses of the components in your router configuration. Alternatively you can also set the static IP address in the configuration of the Shelly device, just make sure that it is out of the range of addresses your DHCP server uses.

Once the Shelly system has been set up, it was time for the next step, the installation of openHAB.

OpenHAB Installation on Synology

To use openHAB for home automation, you need to run it on a local server that is available around the clock and connected to your other home automation components, typically via a local TCP/IP network. And especially for essential components and connections, I’d always prefer the simplicity and reliability of a wired Ethernet connection over a wireless link. The openHAB installation overview gives some general recommendation on choosing the right platform. In our case the obvious choice for running openHAB is our Synology NAS, a DS420+ that provides storage, backup, file synchronization and many other capabilities in our network.

OpenHAB runs as Docker container on the Synology, a step-by-step instruction for the deployment can be found here. Following those instructions was straight forward and it took me less than half an hour to have an up-and-running openHAB installation.

There was only one thing I had to set additionally, which was the time zone. While openHAB has a time zone setting in its configuration, this setting does not seem to work, at least not in the Docker setup on the Synology. Instead it was necessary to set the time zone in the Java parameters of the Docker container, otherwise openHAB would operate on UTC time. To do that, set the environment variable EXTRA_JAVA_OPTS to “-Duser.timezone=<your time zone>”, in my case to time zone “Europe/Vienna”. You can find a list of available time zones for example here or here. The screenshot below shows the setting in the Docker container’s configuration:

Setup Bindings and Create Things

Once you have openHAB running, next you will need to install and setup bindings to connect openHAB to the other components of your home automation system. So, in this case we will install the OpenWebNet binding for the BTicino system and the Shelly binding.

For OpenWebNet you will need a gateway that connects the proprietary bus to the TCP/IP network. We have talked about gateway options already in my article on software configuration, and the OpenWebNet binding page also lists devices that have been tested as gateway. In my case the obvious choice was the MyHOMEServer1, but the MH202 would have been an option as well, albeit some stability issues have been reported with that device as gateway. To setup your gateway in OpenHAB you can either use the gateway discovery feature or add it manually, the OpenWebNet binding page again has more information on this.

Since the Shelly components are connected directly to the TCP/IP network via WLAN, no gateway is required.

The following figure shows the communication between the bindings and the BTicino and Shelly components:

Once your bindings are set up, the next step is to create so-called things in openHAB, which represent your physical devices with sensors and actuators. You can use the automatic discovery of Things or add them manually via the user interface or configuration files. The pages for the OpenWebNet binding and the Shelly binding will again provide you with more information. You can start with only a few Things for testing purposes, and after you have created them your Things page in openHAB should look like this:

After creating your Things, the next step is to organize them in a semantic model.

The Semantic Model

The semantic model provides an abstraction layer that allows you to organize all your home automation components into a structure that represents the physical layout of your home and is independent of the underlying technologies used. You can find a detailed description and tutorial for creating a semantic model in the openHAB documentation’s Semantic Model page.

In the semantic model, your devices, such as lamps, are represented by Equipments and Points. A Thing representing a lamp integrated with BTicino will have different properties than a Thing representing a lamp integrated with Shelly. However, the Equipments and Points representing both lamps will provide the same properties and functionality and in your rules and automation you can address them both in the same manner. Things expose their status and data through Channels, which are used to link them to the Points, which are grouped into Equipments. For example, a Thing representing a lamp can have a Channel of type Switch, which is linked to an Point of type Switch.

The third important element of the semantic model are Locations, which represent your home, its floors and rooms.

Here is a small example of how my semantic model looked after I added a few Locations, Equipments and Points:

Now, let’s have a closer look at a few of the specifics of modelling the BTicino and Shelly components in the semantic model.

Channels for BTicino and Shelly

The Things representing actuator components controlled by BTicino only have one Channel of type Switch, which represents and controls their ON/OFF status and is used to link them to their respective Equipment and Point. The Shelly components expose more Channels, such as their power consumption or WLAN signal strength. In their case the Channel called Power represents their ON/OFF status and is used to link them to their Equipment and Point. The screenshot above already shows this for a BTicino light, the one below a Shelly light and its Equipment and Points.

Non-Semantic Modelling

The Semantic Model gives you a good overview of the physical layout of your house and rooms, and can be used by UI components of openHAB for visualisation. However, it is not very well suited for automation and distribution of commands, since it mixes different type of devices and their properties.

I first did try to use the Semantic Model for distributing commands, but encountered two major limitations. First for groups like Locations to pass on commands to their members, you have to set the Member Base Type, for example to Switch.  The group will then pass on ON/OFF commands for lights, but not others, like UP/DOWN commands for shutters. Second, if, like in the case of the Shelly components, an Equipment has multiple Points of Type Switch, they will be all switched. So not only would the light go on and off, but also the setting for disabling and enabling of status LEDs of the Shelly Plug S will change.

The solution for this is to create separate, non-semantic group structures that organize your points into groups that you want to be able to run certain commands and actions on. In my case I created structures reflecting again the physical layout of the house with floors and rooms, but only containing those Points that I want to group and address as one. Due to the limitation of groups only forwarding commands for one device type, I needed separate structures for each device type, in my case lights, shutters and music players.

The following screenshot shows this kind of structure:

Setting the Member Base Type and an aggregation function allows the groups to pass on commands and show an aggregated status of the devices under them:

You can use the same Points you already created in the Semantic Model and link them to the non-semantic groups:

Before we move on to the integration between BTicino and Shelly, I have to talk about the implementation of BTicino general, area and group commands.

General/Area/Group Commands

A neat feature of the BTicino system are general, area and group commands (for simplicity, I’ll continue with calling them just group commands), which can be used to switch multiple actuators with one command. If you do not use those commands you can skip over to the next session, otherwise read on.

The group commands are part of the OpenWebNet Lighting commands (WHO=1), same as the commands for switching single lights. When such commands are used in the BTicino system, two things need to happen in openHAB: first, openHAB needs to actively switch Shelly components and second it needs to update the status of BTicino components.

The Issues

When trying to implement this in openHAB, I encountered two issues. First, unfortunately the OpenWebNet binding does not automatically process group commands to update the Things status. And second, also manually creating a Thing that listens to group commands does not work entirely. While you can manually create a Thing that listens for OpenWebNet commands with for example WHERE=7 for area 7, the Thing only gets updated when the status changes from ON to OFF or vice versa. In the BTicino system, an OFF command could be issued followed by another OFF command and there is no way to detect the second OFF command in openHAB, again leading to the systems getting out of sync. I have filed an enhancement request for the first issue and a bug report for the second, and in the meantime implemented the workaround I’ll describe in this section.

A note on window shutters: the issue described is about lights and their status. I have also added our BTicino-controlled shutters into openHAB and for those group commands work fine. It seems that even when controlled by group commands, the individual shutters send status updates on the bus that are processed by the openHAB binding. So for shutters, no workaround is required.

A Workaround Based on Scenarios

The OpenWebNet binding also supports CEN and CEN+ commands (OpenWebNet WHO=15) and they can be used to circumvent the issues described above. For that, first the controls need to be reconfigured to issue CEN/CEN+ commands instead of the group commands, second you will need to implement scenarios in the BTicino system and/or openHAB that process those commands. Those scenarios can then still rely on group commands within the BTicino system so that you do not have to include each actuator that shall be switched.

In my case I wanted to keep the BTicino system as self-sufficient as possible and implemented the BTicino side of the scenarios in our new MH202 scenario programmer. While openHAB may be more powerful in some regards, that adds complexity both on a functional level and regarding its deployment as IT-system in a Docker container on our NAS. Compared to that the simplicity of the embedded BTicino components in my eyes makes them more reliable for the core tasks of our home automation.

Regarding using CEN or CEN+ for this workaround, I decided on CEN since the MH202 can issue CEN commands but not CEN+. See my post on the MH202 for more information on the differences between CEN and CEN+.

The following figure shows the flow of messages for this workaround, with the physical controls sending CEN commands (1), which are caught by the MH202 and openHAB via the gateway (3). The MH202 uses group commands to switch the BTicino actuators (2), openHAB switches the Shelly actuators (4).

For the implementation, the following steps are required:

• Assign a CEN address consisting of an A value, PL value and a virtual button number to each of the group commands you are using.
• Reconfigure the physical controls to send CEN commands instead of group commands.
  
• Implement a scenario in the MH202 for each of the CEN commands, to switch the desired BTicino actuators.
  
• Create a Thing in openHAB that listens to the CEN commands.
• Implement a rule in openHAB for each of the CEN commands, to switch the desired Shelly actuators and update the openHAB status of the BTicino actuators.
  

In my case I implemented three scenarios to reflect our group commands: one for switching all lights in the house off, and one each for switching the lights off on ground floor and first floor. I assigned the unused address of A=9, PL=1 to those scenarios, with virtual button numbers 1, 2 and 4:

Next comes the reconfiguration of the physical controls, which is now much easier thanks to having implemented software configuration via the My Home Suite. My post on the MH202 has a bit more information on how to configure controls for CEN/CEN+. The screenshot below shows the configuration for one of our newer 4652/2 controls that supports the My Home Suite’s advanced configuration:

The last step on the BTicino side is to implement the scenarios. The screenshot below shows the scenario for switching off all lights on the ground floor. This scenario is triggered both by the scenario address for ground floor and for the house’s general off, and it uses the BTicino group commands to then switch off the lights.

In openHAB we’ll start with creating a Thing for receiving the CEN messages. For that, you manually create a new Thing of type CEN Scenario Control and then configure it with the scenario addresses you will be using, as shown in the next screenshot:

And finally, we’ll set up a rule for each of the scenarios. The Thing you have created in the previous step will have one Channel of type Trigger for each of the virtual buttons, and this Channel is used to trigger the rule.

As described in the Non-Semantic Modelling section above, I have set up non-semantic Groups for controlling devices, which includes the BTicino and Shelly actuators. So, in this case we’ll send an off command to the Group representing the ground floor, as can be seen in the following screenshot:

This introduces some redundancy, with openHAB sending off commands to actuators that have already been switched off within BTicino, but seems the only sensible way to keep the two systems synchronized. Be aware that this workaround might lead to racing conditions between the two systems. If for example we trigger a scenario in BTicino that uses a group command to switch off devices, and then switch one of those devices back on in BTicino before openHAB has processed the scenario, then openHAB will turn off the device again. Most likely such racing conditions will occur when calling up different scenarios in a row, for example from the MH202, and in that case it may make sense to introduce some delay to avoid such racing conditions. The following screenshot shows an example of this:

Having completed the implementation of group commands, we now have a full and accurate representation of the BTicino system in openHAB and can continue with building the bridges between BTicino and Shelly.

Connect BTicino Controls and Scenarios to Shelly Actuators

To be able to switch the Shelly Actuators (the 1PM Plus and the Plug S) from the BTicino physical controls and the MH202 scenario programmer, they need some kind of representation in the BTicino system. For that, I tested two approaches:

• Lighting commands with A/PL addresses (OpenWebNet WHO=1): similar to the BTicino actuators, each Shelly actuator is represented by an A/PL address. The controls use that A/PL address to issue switching commands, and instead of a BTicino actuator, openHAB would process the command and switch the Shelly actuator. However, this approach did not work very well. The physical BTicino controls rely on feedback from the actuator and if none is given react with their light blinking and by issuing the switching command multiple times. Also the OpenWebNet binding seems to rely on the presence of a physical actuator and did not properly process the switching commands in some situations. The only way I could get this to work properly was to assign an unused BTicino actuator to the address, an approach that may be feasible in some situations where you don’t have too many Shelly (or any other vendor) actuators and have BTicino actuators available, or don’t mind spending the money for adding some to your system. The only advantage of that approach I can see is that you will get correct status lights in your physical BTicino controls, something the second approach with CEN/CEN+ commands cannot provide.

• CEN/CEN+ commands (OpenWebNet WHO=15): similar to the group commands discussed further above, CEN/CEN+ commands can also be used from the BTicino system to switch the Shelly actuators via openHAB. Again, at least in my case, CEN is the better choice, because some of our older physical controls and the MH202 cannot issue CEN+ commands. The CEN/CEN+ commands are stateless and do not rely on a physical actuator, therefore avoiding the issues with A/PL addresses. The only downside of this approach is that the physical control’s status lights will not be able to show the status of the actual device, something I can live with.
  

Based on these tests I settled on using CEN commands. The following figure shows the flow of messages: the physical controls and the MH202 send CEN commands (1), which are forwarded to openHAB via the gateway (2) and openHAB switches the Shelly actuators (3).

The first step for their implementation was to assign two CEN addresses (A/PL and virtual button) to each Shelly actuator, one each for the ON and OFF commands. In the example shown below A=9, PL=2, button=1 is for the ON command, and button=2 for the OFF command for one specific lamp:

As next step we’ll setup another Thing in openHAB to listen to the commands. If you use the same A/PL address, one Thing is sufficient and you can use up to 32 virtual buttons for the different Shelly actuators:

Finally we need to setup two rules for each Shelly actuator, one each for the ON and OFF commands. The screenshot below shows one rule for an ON command. It is triggered by the previously created Thing’s channel representing the virtual button used and then issues an ON command to the Point representing the power on/off state of the Shelly actuator.

Finally we can configure the controls, for example here the setup of an 4652/2 control in the My Home Suite, controlling the Shelly actuator to which the virtual buttons 3 and 4 have been assigned:

With that last step we have completed the integration of the Shelly actuators in the BTicino world and can move on to the Shelly controls.

Connect Shelly Controls to BTicino Actuators

The following figure shows the flow of messages for triggering BTicino actuators from Shelly buttons: pressing the button triggers a rule in openHAB (1), which sends a command to BTicino via the gateway (2, 3).

When creating the Equipment representing the Shelly Button 1 in your semantic model, you should at least create Points for Event Count and Last Event, which will be used to trigger rules and determine what type of action was performed on the button.

The rule for processing a button press looks as shown in the screenshots below. It is triggered by a change of the Event Count, conditioned on the type of action we want to use (single short push) and executes a Blockly script that toggles the state of the Point representing the BTicino component we want to switch:

With the rule in place, the Shelly Button 1 will now switch the light controlled by BTicino. Of course, you can also switch multiple lights or trigger scenarios in BTicino by sending CEN/CEN+ messages via the OpenWebNet binding. For details on sending CEN/CEN+ messages to activate scenarios, check out my post on the Alexa integration with BTicino-controlled devices and scenarios.

Final words

This concludes the basic steps needed to integrate our BTicino MyHome automation system with the wireless components from Shelly. To a large extend the described solutions can also be applied to other vendor’s home automation components and I feel quite confident that with openHAB as core integration platform we’ll be able to build on our existing BTicino system and continue expanding it with additional functionality and components from various vendors.

I hope you found this post useful and will be able to apply some of the presented concepts to your own home automation projects. If you have any questions or comments, feel free to contact me.