[SOLVED] Cannot get UDP binding to send data

Add-ons Bindings
, ,
1

Hello all,

I already read a lot in the documentation about openHAB 2 in general and about my specific issue in the forum, via Google, … but I cannot get the UDP binding to send data. I have to admit I am quite new to openHAB and so maybe my issue has also to do with my way of thinking, so I try to explain, what I want to do.

In general I have my home automation running with Loxone. Unfortunately some protocols/systems/… cannot be connected natively to Loxone and therefore my idea was to sync all of these first to openHAB and then have ONE interface between openHAB and Loxone.

The Loxone binding is installed and working well but it can only send commands to specific channels (e.g. light controllers). For this I have created an item and connected it to a Loxone channel. I can then use this item (e.g. via Alexa and Hue Emulation) to switch a light on and off:

Dimmer KU_B1 "Esstisch" [ "Lighting" ] { channel="loxone:miniserver:<serial>:<UID light controller>-AI1" }

In my use case I want however to make temperatures from Xiaomi Aqara sensors available in Loxone to use is for my heating control. Unfortunately the Loxone binding does not allow to update any analog input channel (only reading is possible). Therefore my idea was to sync the status with the TCP/UDP binding.

I installed it and configured it in addition to an existing temperature sensor binding:

Number KU_UW1_TE1 "Temperatur Küche" { channel="mihome:sensor_weather_v1:<serial>:temperature", udp=">[loxone.dev.null:9898:'REGEX((.*))']" }

I thought, this item will get its status via the Xiaomi binding and will send updates via UDP as soon as it is triggered with an update.

I can see the updates frequently in the event.log:

2018-12-15 21:55:16.455 [vent.ItemStateChangedEvent] - KU_UW1_TE1 changed from 23.1299991607666 to 23.139999389648438

I can also see in the openhab.log, when starting openHAB that the communication channel seems to be established:

2018-12-15 21:12:54.939 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - 'Connecting' the channel Channel [item=KU_UW1_TE1, command=0, direction=OUT, remote=loxone.dev.null/192.168.253.8:9898, buffer=, isBlocking=false, isReconnecting=false, channel=, host=loxone.dev.null, port=9898]

I can however not see any communication. Neither an error or whatever in the openHAB logs nor any actual communication via Wireshark.

A udp.cfg with an uncommented “charset=ASCII” has been created by me (since in the documentation the bug was listed that without any configuration the binding won’t send anything).

So, to be honest, I am lost.
It might be, that I need to create rules and actively send the information to some UDP send target item (as I have seen in some configuration) but then we come back to my openHAB newbie status and my maybe wrong way of thinking.

I hope, somebody is able to help/explain this issue to me.

Sincerely,
Siebo

2

A binding sends a command to the device on a sendCommand event
I recommend that you split your item in 2 an use a rule:

Number KU_UW1_TE1_mihome "Temperatur Küche" { channel="mihome:sensor_weather_v1:<serial>:temperature" }
Number KU_UW1_TE1_loxone "Temperatur Küche" { udp=">[loxone.dev.null:9898:'REGEX((.*))']" }

And the rule:

rule "mihome to loxone"
when
    Item KU_UW1_TE1_mihome changed
then
    KU_UW1_TE1_loxone.sendCommand(triggeringItem.state as Number)
end
3

Thank you for that hint with the rule triggered on change of the items.

I now did the following and everything works as expected:

I added one item to send UDP communications to Loxone

String Loxone_UDP { udp=">[loxone.dev.null:9898:default]" }

I added all my Aqara sensors to the group xiaomisensors

Number KU_UW1_TE1 "Temperatur Küche" (xiaomisensors) { channel="mihome:sensor_weather_v1:<serial>:temperature" }

I added a rule to send UDP communication when one of the group members changes

rule "Loxone_UDP"
when
        Member of xiaomisensors changed
then
        Loxone_UDP.sendCommand(triggeringItem.name + "@" + triggeringItem.state.toString)
end

Don’t know if this is “best practice” now, but it works as expected.
Thank you again :-).