Strange Homematic sensor behavior

Hi all,

I am trying to install a doorbell at an electric gate 300 meters away. First I installed the knob with an HM-PBI-4-FM interface connected to a CCU2. I then opened the Homematic web GUI to see whether it sees the changes when I press the knob. Whenever I press the knob briefly it modifies the “last change” entry. So I concluded that the knob is working and the CCU2 gets the information. Then I went back to the house and programmed the openhab2 stuff rules. I tested these rules using the CCU2 web GUI and clicking in the control field of the HM-PBI-4-FM interface. Now everything seemed to work nicely. If I click in the control field the ring goes and a camera picture is taken. If I go to the knob and press it, the change is registered in the GUI but no rule is executed.

image

Now I am puzzled. How can the interface record a change, but nothing happens further on. If I control by interface everything works.

Please share any thoughts.

Thanks - Martin

How is your Thing defined, what are the available channels, and which do you link to your item(s), which then triggers the rule(s) how? Would be helpful to find where your issue might lie.

Also, what log entries do you get when pressing the web ui, compared to pressing the actual button?

Hi Hans,

as I said - if I trigger the event manually in homematic’s GUI everything works. Items are like this:

Switch Klingel_Tor1K "Klingel Tor1 kurz" <switch> (gKlingel_Tor) 
{channel="homematic:HM-PBI-4-FM:4a49da24:xyz123456:1#PRESS_SHORT"}
Switch Klingel_Tor1L "Klingel Tor1 lang" <switch> (gKlingel_Tor) 
{channel="homematic:HM-PBI-4-FM:4a49da24:xyz123456:1#PRESS_LONG"}
Number Klingel_Tor_SS "Klingeltaster Signal [%d]" <qualityofservice> (gKlingel_Tor, gSignalstaerke) 
{channel="homematic:HM-PBI-4-FM:4a49da24:xyz123456:0#SIGNAL_STRENGTH"}
Switch Klingel_Tor_BV "Klingeltaster Batterie [%s]" <battery> (gBatterie, gKlingel_Tor) 
{channel="homematic:HM-PBI-4-FM:4a49da24:xyz123456:0#LOWBAT"}

Rule:

rule "Klingeltaster Tor"

when Item Klingel_Tor1K changed to ON or Item Klingel_Tor1L changed to ON

then
if (szTorklingel.state != 0)
    FunkgongGF_CMD.sendCommand("1,1,8,2,0")     // Signalisierung, außer szTorklingel == 0
if ((szTorklingel.state == 2) && (TorStatus_C3.state == CLOSED))
{
    Torantrieb_SW.sendCommand(ON)               // Öffne das Tor, wenn szTorklingel == 2
}
if (szTorklingel.state == 3)
    szTorAuf.sendCommand(ON)                    // Öffne das Tor und lasse es offen, wenn szTorklingel == 3

executeCommandLine("/var/www/html/info/ohcam_tor")  // in jedem Falle ein Foto machen
logInfo('rules','Torklingel')                   // und loggen ...
end

When everything works we have the following log entries:

2020-08-27 14:00:28.540 [vent.ChannelTriggeredEvent] - homematic:HM-PBI-4-FM:4a49da24:xyz123456:1#BUTTON triggered SHORT_PRESSED
2020-08-27 14:00:28.541 [vent.ItemStateChangedEvent] - Klingel_Tor1K changed from OFF to ON
2020-08-27 14:00:28.547 [ome.event.ItemCommandEvent] - Item 'FunkgongGF_CMD' received command 1,1,8,2,0
2020-08-27 14:00:28.555 [nt.ItemStatePredictedEvent] - FunkgongGF_CMD predicted to become 1,1,8,2,0

I need to walk to the gate in order to find out what happens when I actually press the button. Will add that later today.

szTorklingel is the programmable function of the button:

  • 0 - log/foto only,
  • 1 - ring the chime,
  • 2 - open the gate (and close again after the programmed time),
  • 3 - open the gate and leave it open

Thanks for reading - Martin

Yes, would be good to see what might be different when you actually press the button, to see how to make it work the same - possibily by triggering the rule by the channel trigger itself.

Well, I found something. I turned the log mode to debug and found this, when I press button 1:

homematic:HM-PBI-4-FM:4a49da24:xyz123456:1#INSTALL_TEST

where I expected:

homematic:HM-PBI-4-FM:4a49da24:xyz123456:1#PRESS_SHORT

This explains that the GUI recognizes any button change. I now googled it and found out that this is a security thing between the CCU2 and the HM-PBI-4-FM. I tested the whole thing in our house earlier where a CCU3 is working. I did not run into anything like that there.

Well, I try to set the button now to #INSTALL_TEST and check whether it’s working now.

Thanks for being with me - Martin

Not sure if you speak German, but this might be helpful

Especially the part about

Wer jetzt seine Taster-Aktionen unbedingt auf ‘INSTALL_TEST’ triggern möchte, kann hier aufhören zu lesen.
Alle die wissen wollen warum den die ‘PRESS’ Datenpunkte einiger Geräte nie in IPS gesetzt werden lesen weiter.

I.e. if you have the HM-PBI-4-FM already directly linked with your MP3 Gong, and the link is set to AES encrypted you will only be able to get the INSTALL_TEST trigger in openHAB. To be able to get the key presses as well you’ll need to set the encryption to OFF/STANDARD

Or it is still stuck in the CCU3 with some encrypted link when you tested it there.

Not sure if you speak German, but this might be helpful

Sure. Well, that’s interesting. However, I checked the thing first w/ our CCU3 and I swear, it worked. Then I “un-learned” the thing from the CCU3 and “learned” it at the CCU2 at the gate. And it did not work.

Well - I will try to un-encrypt the channel and retry. Actually I always forget how to access this setting - I’m getting old (sigh).

Just “Unlearned” or “Unlearn with factory reset” from the CCU3?

How does your Thing look like? Is created via PaperUI or manually in a Text-File ?
I have to say that my Bridge and my Things are created with PaperUI, but the Items are manually generated with VSC into a Text-File.
I had a weird behaviour with a SWDO-I Sensor, which suddenly produces a Warning-Message for a Channel which was not present.
I opened an issue in github, but found a solution by myself.
I think there was a change in the Channel-Definition for the linked items. If you look in a Channel-Definition of a new created Thing (PaperUI) . The Bridge-Device is no longer part of the linked Channel.

example:

// old Version 
Switch  HmIP_SWDO_I_E754_0CONFIGPENDING "Haustür Config Pending [%s]"   (gHomeMatic) {channel="homematic:HmIP-SWDO-I:my bridge-name:abcdef123xxx:0#CONFIG_PENDING"}
// new version
Switch  HmIP_SWDO_I_E754_0CONFIGPENDING "Haustür Config Pending [%s]"   (gHomeMatic) {channel="homematic:HmIP-SWDO-I:abcdef123xxx:0#CONFIG_PENDING"}

Homematic really can be confusing at times.:slight_smile: I have my Bridge and Things created in text files, and still have the Bridge-Device in the Channel definitions with 2.5.8-1 . Wouldn’t be an HmIP issue vs. just Hm thing?!? Have seen a similar issue with text file thing channels with the Mi Binding vs. PaperUI discoverd things.

That’s how I did it.

Unlearned on both sensor and CCU3 side, otherwise I would not be able to reconnect to the CCU2.

I finally managed to change the communication to “unencrypted”. Now the CCU2 complains about “pending configuration”. Duh! Does that really mean that I need to travel back to the gate, open the sensor housing and press that config button ?!

Was just wondering, as I’ve had issues with just “Unlearn” when some direct links might still be stuck. So always make sure now to “Unlearn with factory reset” before relearning a sensor/actor again.

Or just wait a while, it should send the configuration eventually. A config button press might speed it up though :wink:

I don’t remember I created any direct links as I nearly always use openhab for any rules/actions. And that was a fresh device out of the box.

I checked the CCU3 again and found an empty program which might have been a dummy for the button interface. This might have been the reason why it worked on the CCU3. Argh, I’m doing too many things at the same time AND I’m am getting old …

So, I assume that a dummy program addresses the same problem. Correct ?

I would assume so, and since you said everything worked fine on the CCU3, but not the CCU2 now I think you might have just “Unlearned” it from the CCU3, but without a factory reset. So now it won’t work with the CCU2 unless you turn off the encryption, as stated in the article I posted above.

One other suggestion would be to now fully “Unlearn with factory reset” from the CCU2, to give the HM-PBI-4-FM a full factory reset and clear any possibly remaining links in it, then relearn it to the CCU2 and see if it makes a change, hopefully without having to turn off the encryption.

The options “Unlearn” and “Unlearn with factory reset” are in the popup menu of the dialog window which appears when selecting the Delete button of a sensor/actor.

Just changed all channels to “unencrypted”. I will leave it like that but keep your suggestion in mind to always unlearn devices w/ factory reset.

Thanks for sharing your thoughts with me - Martin

Did the configuration go through, and do you now see the expected SHORT_PRESS and LONG_PRESS events?

The config is still pending but the events are now as expected.

1 Like

Just to formalise what I have only deducted by trial and error so far, and reading up a bit more about this …

  • “Unlearn” on CCU - CCU forgets the sensor/actor; sensor/actor forgets the CCU, but remembers all direct links, which were either defined on the CCU, or by directly linking with another sensor/actor

  • “Unlearn and Factory Reset” on CCU - CCU forgets the sensor/actor; sensor/actor forgets the CCU and all direct links

  • “Factory Reset” on sensor/actor itself - sensor/actor forgets the CCU and all direct links, but CCU remembers sensor/actor and all direct links defined on the CCU