KNX seems to forget block object state. Is this the expected behavior?

Add-ons Bindings
1

Dear Community,

I’m experiencing some strange behavior with one of my KNX block objects. Here is the setup. I’ve configured a contact item that is used to represent my rain alert.

The item is linked to two thing channels. The first channel is an MQTT channel that receives rain alert messages as values 0 if no rain is falling and 1 if rain is falling. The values are mapped to the corresponding values CLOSED and OPEN on the channel configuration.

The other thing channel is a KNX channel configured as a contact-control channel with the matching group address. On the KNX side the GA is connected to the block object of an actor (in this case a MDT Jalousie actor) that drives my roof top windows.

The use case intended is to close the roof top window if it starts raining and go to the previous position if the rain stops.

So far this setup is working. At least for a while. When the alarm flag is received by the MQTT channel, it is forwarded to the KNX side and blocks the actor. When the alarm flag reset is received, it is also forwarded to the actor and unblocks it.

Now, if there is no alarm received for about 30 minutes, the roof top window is suddenly blocked. No message was received on MQTT and no message was forwarded to KNX. It seems like the actor forgot about the last state of the block object and thinks he is blocked now.

The actor stays in this state until it receives another write to the block object of 1 followed by a 0 which in fact toggles the alarm. The same can be achieved if I write to the alarm GA with ETS. Reading the GA is resulting in a refresh event on openHAB, upon openHAB writes back the old value. But this does not unblock the actor.

Has anyone seen a similar behavior or can give advice, what is wrong here? I’ve added the configuration of the item and the connected thing channels below.

image
image883×1106 32.3 KB

Configuration of the rain alarm item

UID: mqtt:topic:4b925e7086:5a969c13f1
label: Regensensor Dach
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:4b925e7086
location: Dach
channels:
  - id: regenalarm
    channelTypeUID: mqtt:contact
    label: Regenalarm
    description: ""
    configuration:
      stateTopic: regensensor/regenalarm/state
      closed: "0"
      open: "1"

Configuration of the MQTT channel

UID: knx:device:bridge:6570664e
label: Extern
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:bridge
location: Technikraum
channels:
  - id: C
    channelTypeUID: knx:contact-control
    label: Regenalarm
    description: null
    configuration:
      ga: 0/2/1

Configuration of the KNX channel

image
image1780×77 13.9 KB

Configuration of the GA for the rain alarm

2

Hhm, either this is a such common case and I’m simply do not know it or it is such uncommon, that there is simply no answer. Either way. I still do not know what is going on here.

3

Hello,

I have no idea, but try to disconnect the mqtt channel and send the channel state with the ets diagnose tool. If you problem is away you have a problem with the mqtt channel…… I have a lot of mqtt channels mixed with knx control-channels but without any problem.

Br

Johannes

4

This seems to place your problem firmly outside of openHAB and with your actor configuration?

5

I already tried with the ETS and found out that writing to the alarm object, resets the alarm block but 30 Minutes later, it is blocked again.

But now I found my error and @rossko57 already was on the right track.

6

You were right @rossko57, and your hint brought me on the right track. I use an MDT jalousie actor that can be enabled to listen for alarms. There are four alarms named wind alarm, rain alarm, frost alarm and a general block/disable object.

For each object you can configure if it is active. And then there is a setting for the priority of the alarms to give, e.g. the wind alarm a higher priority than the rain alarm.

And now for the problem I created. Each alarm object comes with a monitoring in minutes with 30 minutes as default. This setting will check if it received the alarm state periodically and if there was no state sent within the monitoring time, it goes into alarm mode regardless of the state it received long before.

The meaning behind is that the alarm should be send periodically and if the sensor fails to resend in that interval, the actor goes into alarm mode on itself.

Fortunately you can disable the monitoring by setting the monitoring value to zero. I’ve done this in the ETS and reprogrammed the jalousie actor. Now it is working as expected.

Thanks to you both, to bring me on the right track.