Loop when using a knx2 switch-control channel

knx2
Tags: #<Tag:0x00007fe057ea36b8>
(Peter Weiß) #1

I am currenlty migrating from openHAB 1.8 to the openHAB 2.4.0 image from dockerhub.

I am facing an issue with the channel definition

Type switch-control : Windalarm [ ga="3/1/4" ]

and the rule

rule "Rule"
when
	Time cron "0 * * * * ?"
then
	Windalarm.sendCommand(OFF)
end

In events.log I see

2019-02-10 20:32:03.803 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:03.873 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:03.875 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:03.945 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:03.947 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.016 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.018 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.095 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.098 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.165 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.168 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.240 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.244 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.323 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.325 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.393 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.395 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.461 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.463 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.532 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.534 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.602 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.604 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.674 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.676 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF
2019-02-10 20:32:04.777 [ome.event.ItemCommandEvent] - Item 'Windalarm' received command OFF
2019-02-10 20:32:04.779 [nt.ItemStatePredictedEvent] - Windalarm predicted to become OFF

I do not see the command once per second but all the time. The same on the group monitor of the ETS. What is wrong? Is it a bug?

(Udo Hartmann) #2

Why using switch-control? This would be “the wind sensor is not knx, but knx devices shall receive a command depending on the wind sensor.”

(Peter Weiß) #3

The wind sensor is on KNX but the decision that there is too much wind is on openHAB. That is, openHAB is the owner of the wind alarm status.

I have the described issue for all my *-control channels. The wind alarm is just an ecample.

(Rossko57) #4

Perhaps that’s the part we need to see?
A guess

when
  Item xx recieved command
then
   do so some workings out
   xxx.sendC0mmand(zz)
(Peter Weiß) #5

What I have posted is not the full rule. I simplified my rule file to the minimum to demonstrate the issue I currently have. One Windalarm.sendCommand(OFF) is sufficient to produce the loop on the KNX bus.

(Udo Hartmann) #6

What’s your bridge configuration like?
What’s the complete thing (at least the Thing head and config) of the *-control channel?

(Peter Weiß) #7

These are some snippets from my KNX thing file:

Bridge knx:ip:bridge [ 
	ipAddress="192.168.25.12", 
	type="TUNNEL", 
	autoReconnectPeriod=30,
	useNAT=true,
	localSourceAddr="1.1.253"  
] {
	Thing device generic [
		readInterval=3600
	] {
...
		Type switch-control	: Windalarm	[ ga="3/1/4" ]
...
}
(Udo Hartmann) #8

Please try to set localSourceAddr to 0.0.0

(Peter Weiß) #9

Setting localSoureAddr to 0.0.0 does not change the behaviour. The loop still occurs.

(Miro Selent) #10

I can see the same behavior in my installation (also TUNNEL bridge) with a simple switch-control thing and a switch item. When I turn the switch in any PaperUI on, it freaks out completely like in your log.

If I configure the item with the property autoupdate=“false” it doesn’t loop but it’s not sending manually changed values to the KNX any more.

(Rossko57) #11

With autoupdate enabled (the default), all it does is listen for commands sent to an OH Item, and automatically issue an appropriate postUpdate to the Item.

The implication of the “fix” allowing KNX to fall silent, is that it is Item state updates that are being set out.

That seems to me to be consistent; I thought switch-control was intended for use with e.g. a wall button, where you’d want incoming KNX being “translated” to openHAB commands. Returning a status to the wall switch to e.g. light an indicator makes sense.
(This is the opposite of an ordinary actuator, where you’d send commands and receive status)

So … I suppose my puzzle is why would you have openHAB send commands to a switch-control?

(Miro Selent) #12

For me switch-control should be used if the actual device is not on the KNX. The state of that virtual kind of device is then in OH. Writing and reading from KNX works exactly for that reason. Otherwise the KNX Switch itself would answer its state value.

The broken thing is that the *-control things send a value to the KNX bus and react on the same message from KNX with a state-update again. Thats the loop. I can not imagine any use case that would require endless looping and bus killing KNX message sending, except a DOS attack.