Rules trigger - received update vs changed

Setup, Configuration and Use Scripts & Rules
1

Hi guys,

I am actually one of the early users from OH and finaly did my change to OH2. I am struggling with something where I need your help.

Most is working fine. I was able to migrate my items with only a few changes. No um struggling with the rules. No single rule which is based on “changed” trigger is firing. When I change it to “received update” it fires. I nailed it down to an issue with my KNX IP Interface (Siemens N146, which worked perfectly fine in OH1).

Here is my knx.config

autoReconnectPeriod="30"
busaddr="1.1.168"
ignorelocalevents="true"
ip="192.168.20.250"
localIp="192.168.30.48"
maxRefreshQueueEntries="1000"
numberOfThreads="3"
port="3671"
service.pid="org.openhab.knx"
type="TUNNEL"

Sending to KNX and receiving updates from KNX works fine. I can turn on an item

openhab> send Light_GF_Arbeiten ON
Command has been sent successfully.

Light goes on.

I can turn it off with my physical switch in the room and its received in the OH2 logs

18:13:03.939 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Light_GF_Arbeiten' received command OFF

So communication just works fine. Only one thing. When I turned it on via the shell in the logs I find this

18:14:09.096 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Light_GF_Arbeiten' received command ON
18:14:09.099 [INFO ] [tuwien.auto.calimero                ] - calimero.link.192.168.20.250:3671: send message to 1/1/5, wait for confirmation

Wait for confirmation sounds like there is a missing feedback that OH2 really changes the item. Its receives the update, but in OH2 its not “changed”. Physically it is, but logically its not.

Evidence is this. The light is physically OFF. I do this:

openhab> send Light_GF_Arbeiten ON
Command has been sent successfully.
openhab> items list Light_GF_Arbeiten
Light_GF_Arbeiten (Type=SwitchItem, State=OFF, Label=Arbeiten, Category=blight, Groups=[GF_Arbeiten, Lights])

OH thinks its still OFF.

When looking in OH APP and physically switching a light the status in the app either gets not updated.

Whats missing?

Item Definition

Switch Light_GF_Arbeiten			"Arbeiten"		<blight> (GF_Arbeiten, Lights) { knx="1/1/5+0/1/0+0/1/2" }

Not sure if this has something to do with it. The OH2 Server has only one IP interface

openhab.log:2017-09-10 17:52:21.963 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.30.48

I dont know where to look for. Any help appreciated. You can imagine whats a house like to live in which was uttermost smart with OH1 and after changing to OH2 nearly no rule is working anymore. HELP ,-).

Regards
Ralf

PS. Needless to say that in OH1 it worked with this config for KNX

knx:ip=192.168.20.250
knx:type=TUNNEL
knx:localIp=192.168.30.48
2

When you dont get feedback here it can have the following reasons
A) you asked a silly question which was asked 100x before
B) you were unfriendly
C) its really hard and no-one has a Clue
D) you asked in the wrong sub forum

Any hint for me?

3

As a pacifier :wink:
I can definitely rule out a, b, and d. :slight_smile:

So, … well, I have no clue, as I did not see this problem before.

The only idea that occurs to me, is: is the GA, which is sent to the actuator, the first one set to the communication object?

4

Hello Udo,

thanks for your efforts to try to help me.

I have been able to isolate the problem. It seems to be related to listening GAs. This is what I found.

This way it works:

Item definition

Switch Light_GF_GWC "GWC" (Lights) { knx="1/1/3" }

Console Log

openhab> send Light_GF_GWC ON
Command has been sent successfully.
openhab> items list Light_GF_GWC
Light_GF_GWC (Type=SwitchItem, State=ON, Label=GWC, Category=null, Groups=[Lights])

This way it doesnt work

Item definition

Switch Light_GF_GWC "GWC" (Lights) { knx="1/1/3+0/1/0" }

Console Log

openhab> send Light_GF_GWC ON
Command has been sent successfully.
openhab> items list Light_GF_GWC
Light_GF_GWC (Type=SwitchItem, State=NULL, Label=GWC, Category=null, Groups=[Lights])

Whats wrong with the definition of the listening GAs?

Can anyone give me a working example for an item with listening GAs?

Regards
Ralf

5

Is the GA 0/1/0 linked to a status feedback object with at least a transmit flag of the same switch actuator channel as GA 1/1/3?

6

No. 1/1/3 is the GA of the actor. The read flag for this GA is active.

The GA 0/1/0 is the “Zentral Off” GA for all Lights in the first floor.

7

So, the answer to your problem is in your own statements:

You should set the channel of the actuator with a status feedback object linked to a GA!
Thus said, I agree with Udo!

8

Now I get it. Solved now. I created for all Objects an additional GA as Status Adress. Alle Actors now have a status Object. The respective Status GA is connected to. The actor is listening also to the central off GA. If a message comes via the CentralOff GA it changes its status, the status GA gets updated and thus OH gets informed.

I assume this is necessary bc of a “bug” in 1.8 and below, bc this worked exactly as implemented before in older versions.

# Ignore local KNX Events, prevents internal events coming from
# 'openHAB event bus' a second time to be sent back to the 'openHAB event bus'.
# Note: To send back events second time is a Bug, but for backward compatibility, the behavior is not changed.
# For new installations, its recommend to set "ignorelocalevents=true"
# (optional, defaults to false)
ignorelocalevents=true

It might be this option which I set. Anyhow. Solved now. Thanks a lot for your patience

9

In fact, you don’t need to add a central off GA to any Item, as long as the stats GA is set up correct:

knx actuator:

object | Name                    | GA          | Flags C R T W U I
     1 | Switch ON/OFF channel 1 | 1/1/3,0/1/0 |       X - - X - - 
     2 | State of channel 1      | 1/1/4       |       X X X - - -

This would be represented in openHAB as

Switch MyknxSwitch "knx Switch is [%s]" {knx="1/1/3+<1/1/4",autoupdate="false"}
  • If GA 0/1/0 is sending an OFF (or ON…) the actuator will change it’s state and will send it’s new state through GA 1/1/4.
  • If openHAB is started, openHAB will request the state through GA 1/1/4 (and the actuator will answer)
  • If openHAB sends a command, this will be sent through GA 1/1/3, the actuator will answer with new state through GA 1/1/4, same if GA 1/1/3 is sent through knx bus
  • If there is no answer from knx bus, the state of the item will stay the same as prior to the sendCommand(), as openHAB does not update the state without request through binding (or postUpdate())
10

Hi Udo,

I got it. Thanks. Makes perfect sense.