UDP binding: Delaying/The binding should wait for a reply

Hello,

I have connected over 25 433 MHz switches over an Intertechno ITGW433 Gateway. On Openhab I am using the UDP binding to send commands to the ITGW433 Gateway which sends the commands over 433MHz intertechno protocol to the switch.

One example to give you an idea how my items are defined:

Switch Esstisch "Esstisch 3er" {udp=">[ON:10.2.11.229:49880:'0,0,6,0,256,67,0,1,10,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,1,1,5,1,5,1,1,1,1,1,5,1,5,1,1,1,1,1,5,1,5,1,1,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,5,1,1,1,1,1,5,1,1,1,5,1,1,1,5,1,5,1,1,1,1,1,5,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,1,1,5,1,39,0'], >[OFF:10.3.11.229:49880:'0,0,6,0,256,67,0,1,10,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,1,1,5,1,5,1,1,1,1,1,5,1,5,1,1,1,1,1,5,1,5,1,1,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,1,1,5,1,5,1,1,1,1,1,5,1,1,1,5,1,1,1,5,1,5,1,1,1,1,1,5,1,1,1,5,1,5,1,1,1,5,1,1,1,5,1,1,1,1,1,5,1,39,0']"}

Unfortunately, the answer of the Intertechno Gateway is always the same, which leads to warnings. Just an extract as information:

2019-05-01 21:09:05.812 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item Esstisch
2019-05-01 21:09:05.835 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item WZLampeHolzGr
2019-05-01 21:09:05.854 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item WZLampeHolzGr
2019-05-01 21:09:05.870 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item Terrassenlampe
2019-05-01 21:09:05.890 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item Terrassenlampe
2019-05-01 21:09:05.907 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item WZBunteStehlampe
2019-05-01 21:09:05.924 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item WZBunteStehlampe
2019-05-01 21:09:05.941 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item GallerieStehlampe
2019-05-01 21:09:05.957 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item GallerieStehlampe
2019-05-01 21:09:05.973 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item WZLampeHolzKl
2019-05-01 21:09:05.989 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item WZLampeHolzKl
2019-05-01 21:09:06.005 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item GallerieRLli
2019-05-01 21:09:06.021 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item GallerieRLli
2019-05-01 21:09:06.037 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item HuelstaLi
2019-05-01 21:09:06.053 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item HuelstaLi
2019-05-01 21:09:06.070 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command OFF on item Kuechelinks
2019-05-01 21:09:06.086 [WARN ] [ing.tcp.protocol.internal.UDPBinding] - Cannot parse input HCGW:VC:ITECHNO;MC:HCGW22;FW:11;IP:10.2.11.150;; to match command ON on item Kuechelinks
...
...

My problem: If I want to switch many switches at the same time (e.g. by a rule), openhab fires many UDP commands in very short period of time. Apparently to much for the ITGW433 Gateway, as this is dropping several of the commands.
I was trying to activate blocking in the UDP binding config (udp.cfg). The idea was, that openhab should wait for the answer of the ITGW433 before it starts sending the next UDP command. Here my current config:

# all parameters can be applied to both the TCP and UDP binding unless
# specified otherwise

# Port to listen for incoming connections
#port=25001

# Cron-like string to reconnect remote ends, e.g for unstable connection or remote ends
#reconnectcron=0 0 0 * * ?

# Interval between reconnection attempts when recovering from a communication error,
# in seconds
retryinterval=5

# Queue data whilst recovering from a connection problem (TCP only)
#queue=true

# Maximum buffer size whilst reading incoming data
#buffersize=1024

# Share connections within the Item binding configurations
itemsharedconnections=true

# Share connections between Item binding configurations
bindingsharedconnections=true

# Share connections between inbound and outbound connections
#directionssharedconnections=false

# Allow masks in ip:port addressing, e.g. 192.168.0.1:* etc
#addressmask=true

# Pre-amble that will be put in front of data being sent
#preamble=

# Post-amble that will be appended to data being sent
#postamble=\r\n

# Perform all write/read (send/receive) operations in a blocking mode, e.g. the binding
# will wait for a reply from the remote end after data has been sent
blocking=true

# timeout, in milliseconds, to wait for a reply when initiating a blocking write/read
#  operation
timeout=3000

# Update the status of Items using the response received from the remote end (if the
# remote end sends replies to commands)
updatewithresponse=true

# Timeout - or 'refresh interval', in milliseconds, of the worker thread
#refreshinterval=250

# Timeout, in milliseconds, to wait when "Selecting" IO channels ready for communication
#selecttimeout=1000

# Used character set
#charset=ASCII

In the packet capture you can see, that this is not the case:

Packets from 10.2.11.150 are the UDP commands from openhab (length 284). The answer (always the same, independent from which switch received the commands) is coming from IP 10.2.11.229. As you can see, the first two UPD commands are already send without answer.

Is there another possibility to let the Openhab wait for the ITGW433? Or what am I doing wrong in the UDP binding config?

Thanks a lot for your help

Ok, I tried some other debugging without success. So if any one has an idea what I could try else, I am happy to hear about it :slight_smile: