Homematic Switch vs. Contact


I am trying to use a push button wired to a HM IO-Module. The channel of the module is also directly connected to an actuator switching some light.

My Item is

Switch IO_Bad_OG_ost_4 "I/O Bad OG Ost #1 shortpress" <homematic> (Aktoren_Technik) { channel="homematic:HG-HMW-IO-4-FM:e3224ce8:LEQ0773177:1#PRESS_SHORT"}

On pressing the button, I get following messages in the log:

13:32:38.984 [INFO ] [marthome.event.ItemStateChangedEvent] - IO_Bad_OG_ost_4 changed from OFF to ON
13:32:39.013 [INFO ] [marthome.event.ItemStateChangedEvent] - A6_Licht_Bad_OG_Decke changed from OFF to ON
13:32:40.998 [INFO ] [marthome.event.ItemStateChangedEvent] - IO_Bad_OG_ost_4 changed from ON to OFF

The button press generates an ON Message, and after 2 seconds, an OFF message (via the IO-Module) . The linked actuator just switches (toggles) the light ON or OFF. The additional OFF message seems to get ignored (which is part of the homematic direct link, I suppose).

When I change the Item defenition to a Contact Type Item, I don’t get any message, the binding seems to enforce the “Switch” type Item.

Anyway, I want to get rid of the direct connection between the button and the switch/lamp, and create some rule to switch a proxy Item on/off instead, but that turns out to be kind of complicated. If I push the button 2 times quickly (within the 2 seconds range between the ON and OFF message in the log), I get:

14:15:57.802 [INFO ] [marthome.event.ItemStateChangedEvent] - IO_Bad_OG_ost_4 changed from OFF to ON
14:15:57.829 [INFO ] [marthome.event.ItemStateChangedEvent] - A6_Licht_Bad_OG_Decke changed from OFF to ON
14:15:58.330 [INFO ] [marthome.event.ItemStateChangedEvent] - A6_Licht_Bad_OG_Decke changed from ON to OFF
14:16:00.318 [INFO ] [marthome.event.ItemStateChangedEvent] - IO_Bad_OG_ost_4 changed from ON to OFF

The second push does not even show up in the log, but the light is switched off correctly.
Does anybody have an idea what’s going on here? How can I correctly interpret this kind of device/behaviour?


(N.B. The thread Homematic: Repeated PRESS_SHORT events? seems to direct to the same issue, but with no solution…)

I think the main reason of this problem is that OH (respectively ESH) currently does not have a direct equivalent to a button (“Taster”). It is normally emulated by using a switch. The switch changes its value (from OFF to ON or vice versa) and then “automatically” back to its initial value similar to a button. Unfortunately´, this behavior causes two events.

I have a similar problem in a rule and did not find a real solution for it. Maybe you can wait until the automatic OFF event occurs and ignore any actions between.

@gerrieg, do you have an idea. It’s also a bit strange that the second push does not appear in the log but seems to work.

Hi Martin,

yes, I agree. At least, the Homematic Binding does not allow defining a “Contact” Item.
I think, this might have to do with the way homematic treats the buttons/actuators. The difference between Contact and Switch functionality in HM seems to be implemented in the link (“Direktverknüpfung”) of the IO-Module-actuator.

I will power on my CCU again as soon as I find the time, and see what shows up in the HM-Log for this case. For now, we only see what OH gets reported by the binding…



In Homematic, all PRESS_* (PRESS_SHORT, PRESS_LONG) datapoints are “Taster”. In OH, there is no “Taster” so i mapped them to a Switch. But the PRESS_* events are only triggered with ON from Homematic, so the binding itself sets the Switch back to OFF after a delay of 2 seconds.

In OH2, there are now TriggerChannels available that fits much better to a “Taster”. I will soon implement these TriggerChannels for all PRESS_* datapoints. Then everything should work as expected.


Just as @MHerbst stated, this is due to the underlying Eclipse Smarthome lib and I believe it’s unrelated to Homematic or the binding. I actually had to change many of my contact items into ‘switch’ items when I moved from OH1 to OH2, and it took me quite a while to find out that I needed to. This does not apply to all contacts, though. It was an annoying little task to find out device-by-device.

Thanks for the info @Gerhard. I fact, if we would use only “Taster” in HM, we wouldn’t need the OFF-message at all, but if we set HM to work with switches, that’s another story.

I can work around that situation. I also see trigger channels as a great improvement in many situations.
And many thanks for the great work to all OH developers and maintainers! “Great Stuff” (not meant as a quote here -:slight_smile:

1 Like