After smartening up our entrance gates, the next thing on my to-do list was our doorbell. The conventional doorbell was barely audible on the first floor of the house, and not at all in the garden. So, my goal for this project was to integrate the doorbell with openHAB, and to play a sound on our Sonos speakers and send a notification to our phones when someone rings the bell. Also an important requirement was for the solution to be robust, ideally with the conventional button and doorbell still working in case the more fancy automation stuff in the background fails.

Our last successful projects with Shelly components for integrating additional lights and the aforementioned entrance gates lead me to look at Shelly again for integrating the doorbell, specifically the Shelly Uni. However, after a few failed experiments with it, I abandoned that idea and turned to the good old BTicino wired bus, for which I found just the right components needed to make this project work.

In this post I’ll cover:

• Why the Shelly Uni did not work out
• Integrating the doorbell with BTicino
• The openHAB setup for mobile and Sonos notifications

Let’s first have a look at the original wiring of the doorbell circuit, as basis for explaining the failed attempts with the Shelly Uni and the final setup with BTicino. At this point I have to state my background is software engineering and my understanding of electrics is very limited. Very helpful with that were once again the folks in the openHAB community, where I started a thread in the DYI section for this project and got many helpful suggestions for understanding the doorbell circuit and potentially solutions for integrating it into openHAB. As for the wiring: we have a breaker box in our cellar, which among other things houses the 12V AC power supply for the doorbell circuit. Both the wiring to the button at our garden entrance and to the doorbell in our entrance hall ends up in that breaker box:

Based on that wiring, I wanted to keep the original button and the doorbell in
place and only add the integration in the breaker box, avoiding any
battery-powered smart but potentially unreliable solutions for button and or the bell.

Failed Attempts with the Shelly Uni

When looking at the available Shelly devices, the Uni was the natural choice for this project, because it is the only Shelly device that can directly run off the 12V AC power supply. While there’d be other devices such as the Shelly Plus 1 that support 12V DC and conversion solutions are available, they’d increase complexity and “messiness” of the solution and introduce additional points of failure.

My first idea for adding in the Shelly Uni was to just use it to detect button presses and leave the doorbell itself in the conventional circuit, triggered by the button. In terms of robustness this would have been an ideal solution, with the drawback that the bell itself could not be triggered or silenced by our automation. For this setup, I wired the Shelly’s switch input between the button and the bell, as can be seen in the figure below. However, it turned out that even with the button released, there is enough current flowing from the other side through the bell to trigger the Shelly, and therefore it permanently reported the switch input as on/closed.

After disconnecting the blue wire between power supply terminal 3 and the bell, the input of the Shelly worked correctly. The next attempt was therefore to take out the bell of the conventional circuit and have it switched by the Shelly’s relay. This would then allow also to include the bell itself in automation but make it rely on the Shelly. Since the Shelly and thus the doorbell would continue to function even if the WLAN or openHAB fails, this was still an acceptable solution in terms of robustness. For this solution, the power supply and the bell would be connected to the Shelly’s out terminal, as can be seen in the figure below. However, when testing this setup it did not work, and after diving a bit more into the specs of the components it turned out that the bell needs more current than the Shelly can handle.

One potential solutions for that would have been to use a Shelly Plus 1, with a more powerful relay but as mentioned before needing a solution for converting the supplied power from AC to DC. Another would have been to decouple the bell circuit from the Uni using a contactor, again increasing the complexity of the solution. A third solution could be to use the BTicino actuators already in place in the breaker box to switch the bell and connect them to the Shelly via openHAB. This would have worked without additional components but would not have been very robust, since a failure of any of the then many involved systems (the Shelly, our WLAN, openHAB and BTicino) would all render the doorbell useless.

At this point I was very close to giving up on this project, when I remembered that BTicno has a module for integrating conventional switches and buttons, opening up a simple solution just based on BTicino.

Successful Integration with BTicino

The BTicino 3477 and F428 are control interfaces for integrating conventional buttons or switches, with the rail-mounted F428 being ideal for our breaker box. This setup is shown in the figure below, with the button taken out of the doorbell circuit and wired to the F428. The bell is wired to an F411U2 actuator, which already was in place in that breaker box and had a free channel. This would again give us the opportunity to control the bell itself from our automation. For it to work it would rely on the BTicino system, but that is for sure the most reliable part of our automation and so I felt quite comfortable with this solution.

And here a photo of the installation in our breaker box:

Both actuator and control interface are configured via the My Home Suite, about which you can read in my first post on home automation. For the actuator, we define the A/PL address (A=4, PL=9) and set the PUL option, which excludes it from the group commands intended for lights. Also important is to disable zero crossing, since we do not have the neutral input for the actuator and it is not needed for the bell anyway. The control interface we set up as light control for the same A/PL address and with a 2 second timer. When the button is pressed, the switch will be set to on for two seconds and then goes automatically off again, until the button is pressed again. The screenshot below shows the configuration:

The configuration of the F411U2 actuator …

… and of the F428 control interface.

With that configuration the physical bell is triggered and we can move on to the more advanced automation in openHAB.

The openHAB Setup

With our BTicino system already integrated into openHAB, it was easy to add the doorbell and setup rules for mobile and audio notifications. The figure below shows the overall setup: the F428 control interface detects button presses and sends commands to the bus (1). Our MyHOMEServer1 gateway forwards them to openHAB (2), which in turns has rules in place triggering audio notifications via the Sonos binding (3) and mobile notifications via the Cloud Connector and the myopenhab.org cloud service (4).

To get the bells signal into openHAB, we setup a Thing via the OpenWebNet binding and a corresponding Equipment and Point in the data model:

The Thing representing the bell signal …

… and the Equipment and Point linked to the Thing.

With the data model in place we can now create a simple rule triggered by a change of the Point’s status to ON. The rule then runs a script which sends out the notifications. In addition to what is shown in the overview above, I also have our Amazon Echo Dot devices announce that someone is at the door, via the Amazon Echo Control binding.

I will not get into details of setting up all the used bindings, since they are well-documented and I have also written about some of them before, check this post for the OpenWebNet binding, and this post for the Cloud Connector.

For the announcement via Sonos and the Echo Dots I created non-semantic groups in the data model, which have all the Points that should be addressed as members. This way the script can send the command to the group and I can add/remove devices there without having to touch the script. For Sonos, we use the Points linked to the Notification Sound channel of the Thing, for the Echos we use the Points linked to the Speak channel of the Things. Don’t forget to set the member base type of these groups to String, the same type as the Points in them. Only then commands will be properly forwarded.

The non-semantic groups for addressing the Sonos and Amazon devices.

The rule triggered by the bell button being pressed …

… and the simple script sending out the notifications.

With all that in place, we’ll never miss the ring of our doorbell again! ;-)

Before concluding this post, I’d like to mention on issue with the Sonos binding. The Notification Sound feature of the binding does resume the music from the queue after the sound is played, however that does not work if the music was started via the Spotify app and Spotify Connect. This issue is known to the developers but it seems there is no real solution for it, so it is a limitation that we have to live with.

Final Words

What I at first believed to be a very simple project turned out to be rather complicated with the failed attempts with the Shelly Uni and the resulting steep learning curve. Despite not using it in the end it was interesting to learn about the capabilities and limitations of this little and cheap smart device. And I am quite happy with the final BTicino solution, it was also inexpensive, easy to setup and I believe will be quiet robust.

Thanks again to the folks in the openHAB community who helped me along the way!

I hope you found this post useful, and as always don’t hesitate to contact me in case you have any suggestions or questions.