SmartHome/J TCP/UDP Binding

Hello,

I’ve been using openHAB 1.8 with the UDP-Binding successfully. Now I’ve been trying to migrate to the current version of openHAB and get the UDP-Binding to work, to no avail.

This is my setup:

  • Windows 10
  • Zulu Java 11
  • openHAB 3.3.0
  • SmartHome/J TCP/UDP Binding 3.2.14
    Documentation: TCP/UDP Binding

The installation of the binding worked well, no errors.

The configuration was done completely textual:

The thing is configured to receive UDP data on port 4000 which is sent from my heating system.
The channel uses an address filter with the IP of the heating system.

Thing tcpudp:receiver:string "my UDP Thing" [ localAddress="0.0.0.0", port="4000", protocol="UDP" ] {
    Channels:
        Type receiver-string : udpChannel "my UDP Channel" [ addressFilter="192.168.178.201:*" ]
}

An item is created and linked to the UDP channel of the UDP thing. The channel-ID was copied from the openHAB configuration web site.

String udpItem "my UDP Item" {channel="tcpudp:receiver:string:udpChannel"}

Also I’ve created a sitemap to see the results:

sitemap udp label="UDP" {
    Frame label="UDP" {
        Text item=udpItem label="UDP-String [%s]"
    }

To check the result I use the openHAB → settings → things → channels → item web page (http://localhost:8080/settings/things/tcpudp:receiver:string/links/udpItem/udpChannel), the said sitemap and the log file.

All of them don’t show any update of the item. The log output doesn’t show any events. According to the openHAB web page its state is NULL.

The Windows firewall does not block incoming messages from the local network for Zulu Java 11.

I’m using Wireshark to check for messages from my heating system. And apparently the PC receives these messages:

  • Source: 192.168.178.201
  • Destination: 192.168.178.24
  • Protocol: UDP
  • Length: 401
  • Scr Port: 4002
  • Dst Port: 4000

Further I’ve installed another binding LuftDatenInfo to see if openHAB is receiving anything at all. This works well and the data from a randomly selected sensor is displayed and updated. This indicates that network traffic can be received by openHAB.

Now my question is why the UDP binding does not show any events or data.

I’d be very happy to get some insight about what’s wrong with my setup.

Thank you very much!

Cheers
Markus

Did you try setting the binding to TRACE logging and see if something is received?

Yes, I’ve increased the logging level of openhab.event and openhab.event.AddonEvents to TRACE. This does not show anything received.
I didn’t find a special log for the TCP/UDP-binding.

log:set TRACE org.smarthomej.binding.tcpudp

Thanks for this advice. I did that right now, restarted the whole thing and got a lot of output. I hope that this can be presented clearly here.

Each line starts with this:

[.tcpudp.internal.TcpUdpHandlerFactory] - bundle org.smarthomej.binding.tcpudp:3.2.14 (240)[org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory(311)] :

Then comes the actual message. Here is the list of messages:

  1. Activating component from state unsatisfiedReference

  2. Querying state unsatisfiedReference

  3. Querying state unsatisfiedReference

  4. Dependency not satisfied: $000

  5. Dependency not satisfied: $001

  6. Not all dependencies satisfied, cannot activate

  7. dm $001 tracking 1 SingleStatic added {org.openhab.core.thing.type.DynamicStateDescriptionProvider, org.smarthomej.commons.SimpleDynamicStateDescriptionProvider}={service.id=479, service.bundleid=241, service.scope=bundle, component.name=org.smarthomej.commons.impl.SimpleDynamicStateDescriptionProviderImpl, component.id=313} (enter)

  8. ActivateInternal

  9. Querying state unsatisfiedReference

  10. Querying state unsatisfiedReference

  11. Activating component from state unsatisfiedReference

  12. Querying state unsatisfiedReference

  13. Querying state unsatisfiedReference

  14. Dependency not satisfied: $000

  15. Not all dependencies satisfied, cannot activate

  16. dm $001 tracking 1 SingleStatic added {org.openhab.core.thing.type.DynamicStateDescriptionProvider, org.smarthomej.commons.SimpleDynamicStateDescriptionProvider}={service.id=479, service.bundleid=241, service.scope=bundle, component.name=org.smarthomej.commons.impl.SimpleDynamicStateDescriptionProviderImpl, component.id=313} (exit)

  17. dm $000 tracking 2 SingleStatic added {org.smarthomej.commons.transform.ValueTransformationProvider}={service.id=480, service.bundleid=241, service.scope=bundle, component.name=org.smarthomej.commons.transform.internal.ValueTransformationProviderImpl, component.id=314} (enter)

  18. ActivateInternal

  19. Querying state unsatisfiedReference

  20. Querying state unsatisfiedReference

  21. Activating component from state unsatisfiedReference

  22. Querying state unsatisfiedReference

  23. Querying state unsatisfiedReference

  24. Changed state from unsatisfiedReference to satisfied

  25. registration change queue [registered]

  26. Checking constructor public org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory(org.smarthomej.commons.transform.ValueTransformationProvider,org.smarthomej.commons.SimpleDynamicStateDescriptionProvider)

  27. getReferenceClass: Looking for interface class org.smarthomej.commons.transform.ValueTransformationProvider through loader of org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory

  28. getParameterClass: Found class org.smarthomej.commons.transform.ValueTransformationProvider

  29. getReferenceClass: Looking for interface class org.smarthomej.commons.SimpleDynamicStateDescriptionProvider through loader of org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory

  30. getParameterClass: Found class org.smarthomej.commons.SimpleDynamicStateDescriptionProvider

  31. Found constructor with 2 arguments : public org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory(org.smarthomej.commons.transform.ValueTransformationProvider,org.smarthomej.commons.SimpleDynamicStateDescriptionProvider)

  32. This thread collected dependencies

  33. getService (single component manager) dependencies collected.

  34. Querying state satisfied

  35. Querying state satisfied

  36. For dependency $000, optional: false; to bind: [[RefPair: ref: [{org.smarthomej.commons.transform.ValueTransformationProvider}={service.id=480, service.bundleid=241, service.scope=bundle, component.name=org.smarthomej.commons.transform.internal.ValueTransformationProviderImpl, component.id=314}] service: [null]]]

  37. For dependency $001, optional: false; to bind: [[RefPair: ref: [{org.openhab.core.thing.type.DynamicStateDescriptionProvider, org.smarthomej.commons.SimpleDynamicStateDescriptionProvider}={service.id=479, service.bundleid=241, service.scope=bundle, component.name=org.smarthomej.commons.impl.SimpleDynamicStateDescriptionProviderImpl, component.id=313}] service: [null]]]

  38. getting activate: activate

  39. Locating method activate in class org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory

  40. Declared Method org.smarthomej.binding.tcpudp.internal.TcpUdpHandlerFactory.activate([interface org.osgi.service.component.ComponentContext]) not found

  41. Locating method activate in class org.openhab.core.thing.binding.BaseThingHandlerFactory

  42. Found activate method: protected void org.openhab.core.thing.binding.BaseThingHandlerFactory.activate(org.osgi.service.component.ComponentContext)

  43. invoking activate: activate: parameters [org.apache.felix.scr.impl.manager.ComponentContextImpl]

  44. invoked activate: activate

  45. Set implementation object for component

  46. Changed state from satisfied to active

  47. dm $000 tracking 2 SingleStatic added {org.smarthomej.commons.transform.ValueTransformationProvider}={service.id=480, service.bundleid=241, service.scope=bundle, component.name=org.smarthomej.commons.transform.internal.ValueTransformationProviderImpl, component.id=314} (exit)

I have numbered them, which is not the case in the original output.

There are a few lines that don’t seem quite right to me, e.g. No. 6 and 15. From No. 35 on it looks better in my opinion, No. 46 gives me hope that everything is OK.

Although I can see incoming UDP messages with Wireshark, no events are output in logging.

So is there a problem with the setup of the UDP binding or my thing / channel / item?

How did you install it? It seems that some dependencies are not satisfied, probably a bundle is missing. The recommended way is using the JSON 3rd party marketplace which will make sure everything necessary is installed.

That’s how I did it (I wrote it down so in case it works I can easily transfer it to the Raspberry Pi):

Settings → System Services → JSON 3rd party addons → enter URL

URL: https://download.smarthomej.org/addons.json

Settings → Bindings → Other Add-Ons → install Smarthome/J TCP/UDP Binding

Might output No 40 be the problem?

My fault, I was looking with a mobile device and did only see the first messages. At the end every dependency is satisfied.

You do not see any log messages when data is received? Can you please configure the thing in UI so we can be sure that it’s not a configuration issue?

No, there are not any log messages.
I’m not sure how to do the configuration in the UI. I’ll try again later. For now I’ve found this in the UI code section for the UDP thing:

UID: tcpudp:receiver:string
label: my UDP Thing
thingTypeUID: tcpudp:receiver
configuration:
  protocol: UDP
  port: "4000"
  localAddress: 0.0.0.0
  bufferSize: 2048
channels:
  - id: udpChannel
    channelTypeUID: tcpudp:receiver-string
    label: my UDP Channel
    description: null
    configuration:
      addressFilter: "*:4000"

The status of the UDP thing in the UI says “online”.

Reloading the configuration files gives this log output:

  • Rule engine started.
  • Loading model ‘udp.things’
  • Loading model ‘udp.items’
  • Item ‘udpItem’ changed from NULL to UNDEF
  • Loading model ‘udp.sitemap’

The state of the item in the UI is changed accordingly to UNDEF (deviating from the screenshot).

I’ll try to add screenshots of the thing, channel, item.



Why do you configure the address filter? If you do so, the SENDING UDP port is matched. Since that seems to be 4002 (according to the information in the first post), nothing will be received.

To be hones I’ve done the configuration by copying and modifying the example from the documentation (very bottom of the page): TCP/UDP Binding

From the given explanation I understood that the address filter ist used to distinguish multiple devices that are sending out UDP messages to the same receiver (PC with openHAB) and to the same port.
The port of the sender is ignored due to the *.

So now I’ve tried these for the channel configuration of the UDP thing:

Thing tcpudp:receiver:string "my UDP Thing" [ localAddress="0.0.0.0", port="4000", protocol="UDP" ] {
Channels:
Type receiver-string : udpChannel "my UDP Channel" [ addressFilter="*:*" ]
}

and

Thing tcpudp:receiver:string "my UDP Thing" [ localAddress="0.0.0.0", port="4000", protocol="UDP" ] {
Channels:
Type receiver-string : udpChannel "my UDP Channel" [ ]
}

The thing file is loaded without warnings, no UDP messages are received.

Or did I get you wrong and I need to make other changes?

Do you see a message in the log that something is received? I have another report that this only starts working after restarting the system (it could be that there is a bug in re-starting the receiver with a new configuration).