KNX 2.0 configuration not working

Add-ons Bindings
1

Having debugged and read documentation now for hours during day and night, I don’t seem to get it and need help.

I do not get the binding to make a single switch work (Switch in BasicUI/Sitemap has no effect). My Synology-SPK-based KNX 1.9 configuration worked fine with nearly 100 items. But I bought an RPi3B+ with openHabian to go KNX 2.0, since I am planning major works, and the openHAB SPK was updated last in January - So I would be updating a configuration with limited perspective, and I am not fit enough to setup a full Synology-CHRoot-environment by hand.

So here’s my simple configuration based on the KNX binding documentation full example, written in VS Code with openHAB extension:
(Commented entries are variants or extensions I have tried so far, I use “#” to anonymize specific addresses here in public)

I understand that no service configuration (knx.cfg) is required.

knx.things

Bridge knx:ip:bridge // "KNX IP Gateway" @ "KNX"
[ 
    type="TUNNEL", 
    ipAddress= "192.168.178.#", // "224.0.23.12",
    portNumber=3671, 
    localIp="192.168.178.#", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="15.15.255" //"13.7.255" // "#.#.#"
]
{

    Thing device generic // "Generisches Gerät" @ "KNX"
    [
//        address="#.#.#",
//        fetch=true,
//        pingInterval=300,
//        readInterval=3600
    ]
    {
        Type switch : L_ArZ_D "Licht Arbeitszimmer Decke" [ ga="<#/#/#" ]
    }
}

knx.items:

ItemType L_ArZ_D "Arbeitszimmer Decke" <light> { channel="knx:device:bridge:generic:L_ArZ_D" }

haus.sitemap:

sitemap haus label="KNX Hauselektrik"
{
    Frame label="Test"
    {
        Switch item=L_ArZ_D
    }
}

This is the respective part of the log viewer (tail -F /var/log/openhab2/openhab.log /var/log/openhab2/events.log)

2018-05-20 21:37:41.154 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'knx.items'
2018-05-20 21:37:57.819 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'knx.things'
2018-05-20 21:37:57.828 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'knx.things' is either empty or cannot be parsed correctly!
2018-05-20 21:37:57.886 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'knx.things'
2018-05-20 21:38:06.047 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'haus.sitemap'
2018-05-20 21:38:06.131 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'haus.sitemap'
2018-05-20 21:38:06.329 [WARN ] [basic.internal.render.SwitchRenderer] - Cannot determine item type of 'L_ArZ_D'
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'L_ArZ_D' could not be found in the item registry
	at org.eclipse.smarthome.core.internal.items.ItemRegistryImpl.getItem(ItemRegistryImpl.java:70) [109:org.eclipse.smarthome.core:0.10.0.b1]
	at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getItem(ItemUIRegistryImpl.java:724) [155:org.eclipse.smarthome.ui:0.10.0.b1]
	at org.eclipse.smarthome.ui.basic.internal.render.SwitchRenderer.renderWidget(SwitchRenderer.java:55) [217:org.eclipse.smarthome.ui.basic:0.10.0.b1]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:172) [217:org.eclipse.smarthome.ui.basic:0.10.0.b1]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:137) [217:org.eclipse.smarthome.ui.basic:0.10.0.b1]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:158) [217:org.eclipse.smarthome.ui.basic:0.10.0.b1]
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:100) [217:org.eclipse.smarthome.ui.basic:0.10.0.b1]
	at org.eclipse.smarthome.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:159) [217:org.eclipse.smarthome.ui.basic:0.10.0.b1]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848) [88:org.eclipse.jetty.servlet:9.3.22.v20171030]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [88:org.eclipse.jetty.servlet:9.3.22.v20171030]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [85:org.eclipse.jetty.security:9.3.22.v20171030]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [88:org.eclipse.jetty.servlet:9.3.22.v20171030]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.server.Server.handle(Server.java:534) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [87:org.eclipse.jetty.server:9.3.22.v20171030]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [79:org.eclipse.jetty.io:9.3.22.v20171030]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [79:org.eclipse.jetty.io:9.3.22.v20171030]
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [79:org.eclipse.jetty.io:9.3.22.v20171030]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [90:org.eclipse.jetty.util:9.3.22.v20171030]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [90:org.eclipse.jetty.util:9.3.22.v20171030]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [90:org.eclipse.jetty.util:9.3.22.v20171030]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [90:org.eclipse.jetty.util:9.3.22.v20171030]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [90:org.eclipse.jetty.util:9.3.22.v20171030]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2018-05-20 21:38:06.334 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'L_ArZ_D' for widget org.eclipse.smarthome.model.sitemap.Switch
2018-05-20 21:38:06.336 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Switch
2018-05-20 21:38:06.338 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'L_ArZ_D' for widget org.eclipse.smarthome.model.sitemap.Switch
2018-05-20 21:38:06.341 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'L_ArZ_D' for widget org.eclipse.smarthome.model.sitemap.Switch
2018-05-20 21:38:06.343 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'L_ArZ_D' for widget org.eclipse.smarthome.model.sitemap.Switch
2

Because these settings are found in the knx.things.
I guess the # in ipAddress and localIp are only in the forum for masking your configuration?

Please don’t set autoReconnectPeriod to a value less than responseTimeout. For a first test I would recommend at least autoReconnectPeriod=60.

in knx.items, please set a correct Item type:

Switch L_ArZ_D "Arbeitszimmer Decke" <light> { channel="knx:device:bridge:generic:L_ArZ_D" }
1 Like
3

First off: Thanks a lot!

Yes, exactly. In my config, there is a valid number at this place.

Great - That changed something:

2018-05-21 00:28:40.208 [.ItemChannelLinkAddedEvent] - Link 'L_ArZ_D-knx:device:bridge:generic:L_ArZ_D' has been added.

I suggest this then to be changed in the full example from https://docs.openhab.org/addons/bindings/knx/readme.html

I can see now the item in the sidebar menu under “openhab items”. However, under “openhab things”, there is still only the RPi and the KNX IP Gateway, both with the channels “Online”, “Latency(ms)”, and “Last seen”. No thing or channel “L_ArZ_D” (e.g. to auto-generate an item from).

Of course - I had it this way but tried to restart with a code snippet, but appearently forgot to substitute the type. Unfortunately, it did not work and does not, now. I still get:

2018-05-21 00:28:44.642 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'knx.things' is either empty or cannot be parsed correctly!

But now, I do receive a reaction to the switch:

2018-05-21 00:29:48.864 [ome.event.ItemCommandEvent] - Item 'L_ArZ_D' received command ON
2018-05-21 00:29:48.952 [vent.ItemStateChangedEvent] - L_ArZ_D changed from NULL to ON
2018-05-21 00:29:49.368 [ome.event.ItemCommandEvent] - Item 'L_ArZ_D' received command OFF
2018-05-21 00:29:49.385 [vent.ItemStateChangedEvent] - L_ArZ_D changed from ON to OFF

The actual light does not react, though. I will try restarting the RPi, but I’m not too confident, yet.

Another side question: VS Code marked “L_AZ_D” uncolored, but “L_ArZ_D” colored - Is there a minimum length for IDs?

4

So, the restart did not help. But I found a few more errors in the log that might be an indication:

2018-05-21 00:55:25.016 [hingStatusInfoChangedEvent] - 'network:pingdevice:192_168_178_#' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
{Both for the IP of my RPi, and for the IP of the KNX IP Gateway...}
{...}
2018-05-21 00:57:21.506 [INFO ] [nx.internal.connection.KNXConnection] - KNXBinding configuration is not present. Please check your configuration file or if not needed remove the KNX addon.

This seems strange as I also thought that the knx.things now includes the binding configuration…?

5

Next question: is the knx.things from above a snippet or the whole file?

I’m not sure about the title (or label?) of the bridge. Is this optional or mandatory? Same for the Thing…

6

Since the documentation is not really self-explanatory, I copied the “full example” from the link above, and modified for my addresses and items. With “snippets” I mean suggestions from the VS Code OH extension that come up when typing. When things did not work out, I tried this as a basis, alternatively. It mostly looked the same, and there are no problems displayed (although I missed that one placeholder “itemtype”).

From the error messages, I’m starting to doubt that the KNX 2 binding is active.

  • I used the current openhabian image,
  • updated everything using openhabian-config, it seems I’m on openhab version is 2.2.0-1 stable
  • I did not activate legacy bindings, so there shouldn’t be any 1.0 bindings where 2.0 are available.
  • But it seems the binding says it’s KNX 1 - 1.11? And it’s not shown in Bindings configuration, although I installed it. (Iinstalled network binding, and that works. I added the RPi and the Interface as things in the network binding).

Is there any way to find out whether the latest openhabian image is actually distributed and auto-configured for the KNX 2 binding?

As for the address - I found that in other forum entries and tried as an alternative, since the code from the full example did not work. So I tried both. No idea if it is mandatory - I use it, it does not work. I leave it out, it does not work. No way of telling…

7

OK, solved it after becoming sceptical of what “installing the newest openhabian and updating everything to most current” resulted it (OH 2.2/KNX 1.11 were the indicators I stumbled about):

  • openhabian brings you the current release.
  • but “current” means obviously stable releases only.
  • That is obviously why openhabian comes only with openhab 2.2.
  • openhab 2.1 had KNX 1.9 - openhab 2.2 seems to have KNX 1.11?
  • Although 2.2 and 2.3 appear to be similar main numbered versions, 2.3 is only a snapshot.
  • KNX2 was introduced only with 2.3, so you have the choice to install an unstable system / “snapshot” with the “current” binding, or install according to the current documentation including a “legacy” KNX binding (?!).
  • For “non-legacy” KNX 2, openhabian has to be reconfigured against the warning that you really do want to open the system for unstable releases, and to be updated.
  • All previous configuration is lost, so you will have to install all bindings (including the KNX 2.0 binding) etc. again.

One view is: I surely could have researched, gathered, and combined this information about the versions and what which term means for OH insiders - rather than debugging a code for many hours (that is actually not buggy at all, but simply not relevant to that release).

Another view is: If openhab had any end-user compatible documentation about the key binding openhab was initially developed for, It would have saved me around two business days of work and frustration (without any chance to succeed).

Is there any chance of having the tutorials extended to explain that, in openhab speak, “legacy” is to be read as “current stable release” and “2.3” is still a snapshot after a stable 2.2? Just to save other end users from the same frustration…

8

The problem is the meaning of the word stable. In software area this is often understood as “This software does work reliable.” But there is another meaning, too: “This software won’t change.”

The openHAB philosophy is more near the latter than the former meaning, so to say the nightly version isn’t less reliable than the last release, but there is a good chance there are breaking changes now and then, so you have to be careful when updating.
The nightly version gets new functionality, which will appear in the next release, but this implies sometimes some bugs, e.g. OH2.3.0 got recently the ability to autoconvert units (e.g. °C to °F). The downside is, you have to change some definitions and rules to use this functionality, and you have to use a <space> after [ and before ] in specific cases (and that’s a bug…).

Legacy bindings are those which are from OH1 but have also candidates from OH2, for example exec binding. There is an exec1 binding (legacy) and an exec2 binding.
For http there is no special OH2 version yet, so http is not legacy.

It’s adverse that the documentation hides legacy bindings, I think the team is working at that problem.
That’s the downside of splitting up such a large project - please take a look at openHAB · GitHub, afaik all 43 repos (plus esh repos as well!) are used to build openHAB, most parts are fully automated, so e.g. the documentation is built automatically whenever openHAB is rebuilt (which is, when something was changed, so nearly every day).

9

Thank you for taking the time to explain the background if the documentation. It is indeed a big and great project I am thankful for. Yet it sometimes seems it is all logically structured as long as you are a developer or a longtime follower or the source code, and maybe it can be explained afterwards to the end user - But it just does not feel intuitive. You can just flash your SD card and be up and running with your RPi - except, in this or that case, all you have to do is SSH into it and perform the feared “sudo this, vi that” sequence, oh, and not like it says, but in your case, with the current release, you need to exchange this for that - But if you work with Linux, you should have known that, right?

Sorry for the rant. Actually, openhabian and openhabian-config are as good as it can get in a headless Linux setup! Yet, literally everyone I know except one person (a Linux admin) would have given up on it after 20 % of the effort I put in - due to limited time/priority/self-exploitation and knowledge (I used to do some Basic/ Pascal programming as a kid). To be honest, I was not expecting this kind of learning curve when I learned about openHAB, the Synology SPK, and openhabian - The impression I had first was a more of a plug & play one. For KNX, this seems to be quite a bit of way to go… Although it all might be logical once you are knee-deep inside the system…

10

:grin: I can’t deny…

But to be fair, I tried out some other software, FHEM, MisterHouse, LeibNIX (well, hardware), even professional software (Gira Homeserver 2) and edomi, and guess what? openHAB1 (!) was by far the simplest bit of software, and I had a working system in 5 Minutes at the very first test (!)
This was openHAB1.0 of course, there was no config UI at all, and I did the installation on my Windows Desktop.
As I already had a xen server up and running, the step from test installation on Desktop to a working GNU/Linux setup was not that hard, and to be honest, it’s sort of fun project after all :slight_smile:

I read many, many howtos and man pages from GNU/Linux software, and the documentation of OH2 is often more precise and more helpful (in question of the subject which should be covered by the article).

One big issue is, it’s enough new stuff only to learn openHAB just as only to learn GNU/Linux, I had mastered some part of the way for the latter :wink: before beginning the journey to a smart home with openHAB.

11

Granted… I haven’t tried anything else yet, part of the difficulty is the complexity the system allows for (which is good), and the intransparency that comes with an automated up-to-date setup (which is good, too). And a RPi is usually Linux-based, after all.

So thanks for not giving up to help (another “good” for openHAB) and being patient with my frustration :slight_smile: All the best
novamax

12

You’re welcome :slight_smile: