Hörmann garage door with Homematic HmIP-MOD-HO

Tutorials & Examples Solutions
1

For quite a while I have been looking for a way to integrate my Hörmann garage door into openHAB. My goal very simple: control the door through openHAB just like with the original remote. The available solutions didn’t really work out for me.

  • HM-KNX, directly connects to the Hörmann bus, but KNX is no option for me (wiring) and price is well above 100 €
  • Bisecur Gateway, also requires wiring, also above 100 €
  • UPA1, requires additional interface (e.g. ESP32) to connect to openHAB
  • Another remote and connect it to some interface

None of them were within the justifiable budget (money / time) for this functionality so I focused on other projects until a few days ago I came across the Homematic HmIP-MOD-HO .
Priced slightly above the Hörmann UAP 1 but well below the Bisecur Gateway it seemed worth a try as I’m already running other Homematic devices. As I didn’t find enough valuable information available I wanted to share my experience.

0. Preparation
Make sure your motor is supported by the HmIP-MOD-HO and that the CCU firmware is updated. Make sure the BUS port of your motor is not used. The HmIP-MOD-HO uses the same address as the UAP1, so they can’t be operated in parallel.

1. Inclusion in Homematic WebUI
As for other Homematic devices, installation starts at the Homematic WebUI. Type in KEY and SGTIN and start the search process. Within the next 60 seconds, connect the HmIP-MOD-HO to the BUS port of your motor.
The status LED of the HmIP-MOD-HO will start blinking orange and ultimately turn red. That’s no problem. Press and hold the button (which is the LED) for 4 seconds until it start blinking orange again. Now it’s in inclusion mode. It turned red again, but the WebUI inbox showed the newly identified device. After confirmation I could play with the buttons (see picture, sorry for German setting) and it controlled the garage door as intended.

image
image858×451 12.2 KB

2. Integration in openHAB
My PaperUI inbox already showed the new thing which provides surprisingly many channels.
After playing around I am now using the following:

  • 1#DOOR_COMMAND: This string channel can be set to NOP, OPEN, CLOSE, STOP or PARTIAL_OPEN in order to make the door execute it.
  • 1#DOOR_STATE: This string channel provides the door status VENTILATION_POSITION, OPEN, CLOSE or POSITION_UNKNOWN. The latter is used when the door moves or if the door has been stopped at any non-preset (open, closed, ventilation) position. You don’t get precise position information like percentage, though.
  • 1#ERROR_CODE: Number channel with an error code in case there is some problem, otherwise 0.

I’d like to point out some other channels some might be interested in, but which I decided not to use. There are even more available though.

  • 1#PROCESS: This string channel with NOT_STABLE while motor is running and STABLE in standstill.
  • 2#STATE: This switch channel allows controlling the light of the motor. As I’m happy with the logic my SupraMatic has built-in I’m currently not planning to integrate this little bulb. I have the general garage lighting independent of the motor anyway.
  • 0#SIGNAL_STRENGTH: I checked this number item only once at setup just to know. It’s stationary equipment and shouldn’t change that often or drastically.

3. Items
The first, virtual item is the one I use for my sitemaps.

Rollershutter UG_Garage_Tor "Garagentor" <garagedoor>  
String UG_Garage_Tor_1DOOR_COMMAND "DOOR_COMMAND" {channel="homematic:HmIP-MOD-HO:OE00000000:00000000000000:1#DOOR_COMMAND"}
Number UG_Garage_Tor_1ERROR_CODE "ERROR_CODE" {channel="homematic:HmIP-MOD-HO:OE00000000:00000000000000:1#ERROR_CODE"}
String UG_Garage_Tor_1DOOR_STATE "DOOR_STATE" {channel="homematic:HmIP-MOD-HO:OE00000000:00000000000000:1#DOOR_STATE"}

4. Rules
The goal is to have the virtual rollershutter item as the sole interaction point. I have never used ventilation position or independent light control and never had the need to. Therefor the following rules purely forward the commands for open/close/stop to the garage door and feed the status back open/closed/other. At the moment that’s all I want.

rule "Garage door: close"
when
    Item UG_Garage_Tor received command DOWN 
then
     UG_Garage_Tor_1DOOR_COMMAND.sendCommand("CLOSE")
end

rule "Garage door: open"
when
    Item UG_Garage_Tor received command UP 
then
     UG_Garage_Tor_1DOOR_COMMAND.sendCommand("OPEN")
end

rule "Garage door: stop"
when
    Item UG_Garage_Tor received command STOP 
then
     UG_Garage_Tor_1DOOR_COMMAND.sendCommand("STOP")
end


rule "Garage door: update position"
when
    Item UG_Garage_Tor_1DOOR_STATE changed
then
    var pTorStatus = UG_Garage_Tor_1DOOR_STATE.state
    
    if (pTorStatus == "OPEN") {
        UG_Garage_Tor.postUpdate(UP)
    }
    else if (pTorStatus == "CLOSED") {
        UG_Garage_Tor.postUpdate(DOWN)
    }
    else { // position unknown, ventilation position or moving
        UG_Garage_Tor.postUpdate(20)
    }
end

5. Result
image
The icon shows the garage door status, no matter if it has been operated by the wall switch, the original remote or the HmIP-MOD-HO. The buttons allow to open, stop and close the door.

Of course for many others this is only a fraction of the desired functionality. I still hope it helps to understand what to expect from HmIP-MOD-HO and how to get started with it.

2

I have just connected shelly device as a trigger device parallel to the button on my wall, as for whether the door is open or not - it is handled by my alarm system. The only problem that there is no state of whether the door is moving or whether it is semi-open/open (just closed/not-closed). But this costs just 10 euros (for the price of one shelly 1).

1 Like
3

Thank you for the hint. Unfortunately that wouldn’t have worked so easy in my setup. I don’t have a switch for UP and another for DOWN.
My wall switch provides only a trigger to the motor and the action depends on the current state.
If the door is moving, it stops.
If it stands still, it will start moving in the opposite direction than it moved last time.
It wouldn’t be enough to track the button status to predict what will happen next because it wouldn’t notice other operations such as remote control.
Therefore I preferred to link to the Hörmann bus in some way.

Edit:
Same issue with the 40 € original remote controls. They only send a trigger, therefore not suitable for intentional operations.
And I’m hesitating to add sensors (end position switches) to control a system that has them already built in. I’d rather try to find a way to use them directly.

4

How does it do that?

5

I have used the trigger and agree this is not the most convienient way. However, knowing how long does it take to open/close the door and having a close sensor, it is easy to emulate the “open” and “close” with a rule.

Regarding the alarm system, this is a simple wired magnetic sensor for DSC alarm system.

6

Thanks for sharing your setup here! I’m using it in a similar fashion. :+1:

Lately, we noticed that the humidity in the garage increased rapidly to levels often above 90%. We even started seeing some mold in some areas of the ceiling. Therefore I‘d like to automate the ventilation position, but I wasn’t able to find out which command to send to trigger it.

Does anyone know which command to achieve this?

Thanks!

7

Just sending PARTIAL_OPEN to the 1#DOOR_COMMAND channel should make the door go to the ventilation position.

8

Ahh, thank you very much! I‘ll give it a try.

I thought it had to be something like VENTILATION_something…

9

Unfortunately the door command string is not matching the door state string for the same thing. I.d.k. why they made it that way…

10

@Mhgglmmr Thank you for sharing.
When sending a command e.g. by a hand remote or a wall pin remote, will I see the new status in OpenHab?
Does Homematic depends on a cloud connection? Or will all request done locally?

11

Dear all, has anybody succeeded in controlling the HmIP-MOD-HO also with Alexa?