Sending Wunderground temperature to KNX-Bus

Setup, Configuration and Use Items & Sitemaps
1

Hello,

i have a problem to send temperature to the KNX-Bus.

my item is as follow:

Number Hannover_Temperatur “Temperatur [%.1f °C]” (Temperature_Aussen, HWR) {weather=“locationId=hannover, type=temperature, property=current”, knx=“0/0/3”}

my Config:

  • Synology NAS mit Openhab 1.71
  • Raspberry with Siemens BCU and eibd as Tunnel (0.0.0)

OH.cfg

################################ KNX Binding ##########################################
knx:ip=192.168.1.28
knx:ignorelocalevents=true
knx:type=TUNNEL
knxport=3671
knx:localIp=192.168.1.210

Weather

################################### Weather Binding ###################################
weather:apikey.OpenWeatherMap=geheimerschlüssel
weather:apikey.Wunderground=geheimerschlüssel

weather:location.hannover.name=Hannover
weather:location.hannover.latitude=52.3456
weather:location.hannover.longitude=9.7908
weather:location.hannover.provider=Wunderground
weather:location.hannover.language=de
weather:location.hannover.updateInterval=30

weather:location.leon.name=Leon
weather:location.leon.latitude=52.3456
weather:location.leon.longitude=9.7908
weather:location.leon.provider=OpenWeatherMap
weather:location.leon.language=de
weather:location.leon.updateInterval=30

but when i activate the items i get every second writes to KNX-Bus as follow:

20:14:59.648 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
20:14:59.648 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: indication from 0.0.1
20:14:59.649 [WARN ] [.w.internal.bus.WeatherBinding:113 ] - Received command for readonly item Hannover_Temperatur, republishing state
20:14:59.650 [INFO ] [runtime.busevents :22 ] - Hannover_Temperatur received command 14.0
20:14:59.652 [DEBUG] [.b.knx.internal.bus.KNXBinding:113 ] - Received update (item=‘Hannover_Temperatur’, state=‘14.00’)
20:14:59.652 [INFO ] [tuwien.auto.calimero :51 ] - [EventAdmin Async Event Dispatcher Thread] link 192.168.1.28:3671: send message to 0/0/3, wait for confirmation
20:14:59.655 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: confirmation of 0/0/3
20:14:59.655 [DEBUG] [.b.knx.internal.bus.KNXBinding:138 ] - Wrote value ‘14.00’ to datapoint ‘command DP 0/0/3 Hannover_Temperatur, DPT main 0 id 9.001, low priority’
20:14:59.656 [INFO ] [runtime.busevents :26 ] - Hannover_Temperatur state updated to 14.00
20:14:59.687 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: indication from 0.0.1
20:14:59.687 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
20:14:59.688 [WARN ] [.w.internal.bus.WeatherBinding:113 ] - Received command for readonly item Hannover_Temperatur, republishing state
20:14:59.689 [INFO ] [runtime.busevents :22 ] - Hannover_Temperatur received command 14.0
20:14:59.691 [DEBUG] [.b.knx.internal.bus.KNXBinding:113 ] - Received update (item=‘Hannover_Temperatur’, state=‘14.00’)
20:14:59.691 [INFO ] [tuwien.auto.calimero :51 ] - [EventAdmin Async Event Dispatcher Thread] link 192.168.1.28:3671: send message to 0/0/3, wait for confirmation
20:14:59.694 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: confirmation of 0/0/3
20:14:59.694 [DEBUG] [.b.knx.internal.bus.KNXBinding:138 ] - Wrote value ‘14.00’ to datapoint ‘command DP 0/0/3 Hannover_Temperatur, DPT main 0 id 9.001, low priority’
20:14:59.695 [INFO ] [runtime.busevents :26 ] - Hannover_Temperatur state updated to 14.00
20:14:59.726 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
20:14:59.726 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: indication from 0.0.1
20:14:59.727 [WARN ] [.w.internal.bus.WeatherBinding:113 ] - Received command for readonly item Hannover_Temperatur, republishing state
20:14:59.728 [INFO ] [runtime.busevents :22 ] - Hannover_Temperatur received command 14.0
20:14:59.730 [DEBUG] [.b.knx.internal.bus.KNXBinding:113 ] - Received update (item=‘Hannover_Temperatur’, state=‘14.00’)
20:14:59.730 [INFO ] [tuwien.auto.calimero :51 ] - [EventAdmin Async Event Dispatcher Thread] link 192.168.1.28:3671: send message to 0/0/3, wait for confirmation
20:14:59.733 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: confirmation of 0/0/3
20:14:59.733 [DEBUG] [.b.knx.internal.bus.KNXBinding:138 ] - Wrote value ‘14.00’ to datapoint ‘command DP 0/0/3 Hannover_Temperatur, DPT main 0 id 9.001, low priority’
20:14:59.734 [INFO ] [runtime.busevents :26 ] - Hannover_Temperatur state updated to 14.00
20:14:59.765 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
20:14:59.765 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: indication from 0.0.1
20:14:59.766 [WARN ] [.w.internal.bus.WeatherBinding:113 ] - Received command for readonly item Hannover_Temperatur, republishing state
20:14:59.767 [INFO ] [runtime.busevents :22 ] - Hannover_Temperatur received command 14.0
20:14:59.769 [DEBUG] [.b.knx.internal.bus.KNXBinding:113 ] - Received update (item=‘Hannover_Temperatur’, state=‘14.00’)
20:14:59.769 [INFO ] [tuwien.auto.calimero :51 ] - [EventAdmin Async Event Dispatcher Thread] link 192.168.1.28:3671: send message to 0/0/3, wait for confirmation
20:14:59.772 [INFO ] [tuwien.auto.calimero :51 ] - [KNXnet/IP receiver] link 192.168.1.28:3671: confirmation of 0/0/3
20:14:59.772 [DEBUG] [.b.knx.internal.bus.KNXBinding:138 ] - Wrote value ‘14.00’ to datapoint ‘command DP 0/0/3 Hannover_Temperatur, DPT main 0 id 9.001, low priority’
20:14:59.773 [INFO ] [runtime.busevents :26 ] - Hannover_Temperatur state updated to 14.00

So i don´t know how to solve the problem

gpowa

2

In looking at the code for the weather binding, it reacts to incoming commands and updates by pushing another event on the bus, which seems like it is the source of the problem. I’m not familiar with the weather binding, but I think it would be good if this weren’t being done:

	@Override
	protected void internalReceiveCommand(String itemName, Command command) {
		logger.warn("Received command for readonly item {}, republishing state", itemName);
		WeatherPublisher.getInstance().republishItem(itemName);
	}

	@Override
	protected void internalReceiveUpdate(String itemName, State newState) {
		logger.warn("Received new state for readonly item {}, republishing state", itemName);
		WeatherPublisher.getInstance().republishItem(itemName);
	}
3

Ok, So what can i do? Maybe i contact to the developers of the
weather Binding and where i can find them ?

gpowa

4

It looks like the binding’s author, @gerrieg, has an account here. The problem, as I see it, is that the weather binding does not ignore state changes and commands that are directed to items it is bound to, but instead puts a new update on the event bus, leading to the situation shown in your log. In my opinion, the weather binding should not override those methods, but instead ignore them, so no conflicts like this occur.

The point is that, contrary to the logger.warn messages above, there is no such thing as a “readonly item”. A specific binding may only be interested in publishing states for items and not receive them or commands, but the binding does not “own” the item – other bindings or rules may be perfectly interested in using the item’s state or sending the item commands that have nothing to do with what other bindings may be bound to it. If some other piece of code updates an item’s state and sends it a command, if the weather binding were to just ignore that, that would be perfectly legitimate (plus, it should allow your example to work perfectly).

5

I made a new weather binding JAR with the above methods removed. Please try it to see if it fixes the issue (by replacing the one in your addons folder). If so, I will submit a pull request and hopefully @gerrieg will comment.

6

Ok Ive tested your Binding and it worked without Problems. In the Mean Time Im look in the KNX-Binding and found an interesting Option.

Local KNX Binding bus address.
Use it, when two or more openHAB Instances are connected to the same KNX bus.
(optional, defaults to 0.0.0)

knx:busaddr=1.1.128

After i mark this as active, i have with the old Binding the same Result.
So i Think that OpenHAB with Raspi (eibd) needs this Entry to stop Echos.
What is now better, the Entry or to workaround the Binding ?

Thanks for Support

gpowa

7

The idea was, that the weather items are readonly. If a item get’s updated, i am republish the ‘correct’ state. Previously the weather binding had a cache and republishing was necessary. This cache has been removed in a PR, so now it’s better to remove the two methods too.

So please create PR with your changes, thanks!

8

Ok, thanks for the Info. Because I´m new here and i don`t Know how to
make a pull request.

@watou

Can you make the pr for me, thanks!

gpowa

9

Thanks, @gerrieg, I’ve created PR #3397 that removes those two method overrides.

@gpowa, I’m not sure about the KNX option, but I know that the change to the weather binding is a good idea to stop the looping you saw.

10

The PR is merged so this change should appear in openHAB 1.8. Please report if you see any possibly related issues. Thanks!