OH2.3 with KNX2 - syntax of items not clear

Add-ons Bindings
5

Hi all,

thanks for your help !! I made some progess.
Please allow me to bother- as I am not still able to connect fully to the knx.

My knx.things

Bridge knx:ip:bridge [ 
    ipAddress="192.168.1.85", 
    portNumber=3671, 
    localIp="192.168.1.129", 
    type="TUNNEL",  
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    Thing device generic [
        address="1.1.10",
        fetch=true,
        pingInterval=300,
        readInterval=3600
    ] {
        Type switch        : kg_buero_licht_ea        "KG Büro Schreibtisch"       [ ga="9/0/0+<9/0/1" ]
/*        
        Type rollershutter : demoRollershutter "Shade"       [ upDown="4/3/50+4/3/51", stopMove="4/3/52+4/3/53", position="4/3/54+<4/3/55" ]
        Type contact       : demoContact       "Door"        [ ga="1.019:<5/1/2" ]
        Type number        : demoTemperature   "Temperature" [ ga="9.001:<5/0/0" ]
        Type dimmer        : demoDimmer        "Dimmer"      [ switch="5/0/0+<5/0/1", position="5/0/2+<5/0/3", increaseDecrease="5/0/4" ]
        Type string        : demoString        "Message"     [ ga="5/3/1" ]
        Type datetime      : demoDatetime      "Alarm"       [ ga="5/5/42" ]
*/        
    }
}

My knx.items:

Switch kg_buero_licht_ea	"KG Büro Schreibtisch [%s]" 	<light>	(gLicht,gKG) { channel="knx:device:bridge:generic:kg_buero_licht_ea" }

The log shows:

    >     > 2018-03-10 11:50:19.610 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from ONLINE to OFFLINE
    >     > 2018-03-10 11:50:19.614 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
    >     > 2018-03-10 11:50:19.618 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from ONLINE to UNKNOWN
    >     > 2018-03-10 11:50:19.624 [me.event.ThingUpdatedEvent] - Thing 'knx:ip:bridge' has been updated.
    >     > 2018-03-10 11:50:19.629 [me.event.ThingUpdatedEvent] - Thing 'knx:device:bridge:generic' has been updated.
    >     > 2018-03-10 11:50:19.653 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from UNKNOWN to ONLINE
    >     > 2018-03-10 11:50:19.655 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
    >     > 2018-03-10 11:50:22.896 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from UNKNOWN to ONLINE

… In the PaperUI I can see the KNX Device and the KNX/IP Gateway - both are running. I can see the Switch item …

But still no connection to the bus. I think the localSourceAddr and the address (Address @ knx) of the Thing are not correct - but only this combination was showing that Device and Gateway were online.

Any suggestion, what I am doing wrong?
Thanks
Michael

6

Hi all,

any thoughts how to debug the situation?

ANY help would be appreciated
Michael

7

I can’t really help you as I am trying to figure it out myself at the moment but there was something about the sourceaddress and so on recently on the github-thread here. Maybe you can get some helpful information there.

8

To debug KNX2, return this at openhub console:

log:set TRACE org.openhab.binding.knx

To debug calimero, return this at openhub console:

log:set TRACE calimero

If you get too much logs, instead of TRACE use INFO, WARN, DEBUG, TRACE.

9

Hi all,

thanks for the great support !!

I see in the log that the knx bus is monitored.
When I switch the device in paper ui the trace shows:

 Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 12/0/3 'knx:ip:bridge', DPT id 1.001, low priority': no confirmation reply received for 1.1.99->12/0/3 L_Data.req, low priority hop count 6 repeat, tpdu 00 81. Giving up now.

I followed lewie´s advice (on github!) how to configure the address for the hardware
The knx device remains offline.

… any hint ?
Thanks MICHAEL

10

Update: It seams my gateway refused the connection as all connections were in use … i am investigating!

11

Hi all,

here my learnings - thanks to the team supporting me:

The syntax description within the thing must show per device a new block and an individual device name. Each device points directly to the device on the bus with the KNX address. --> This leads to a high number of devices in the configuration->Things.
Syntax within the Bridge:
Thing device my1stDevice [] {} Thing device my2ndDevice [] {} …

Sidenote: My Devices are still “offline” in paperUI - but functional

Michael

12

Looking at the syntax provided, I am really scratching my head where the progess and advantages are with this new binding. Configuration looks to me way more complicated than the syntax of the 1.x binding, so what would be the users benefit here?

13

First of all: It’s the OH2 way of configuration. :slight_smile:
There is an explicit hardware abstraction. This is done through the things.
Items do only refer to a thing channel (or sometimes more than one).
If all is set up in a proper way, and assumed that the hardware provides the functions, you can get more information about the hardware devices.

When using VSCode, to generate an item from a thing channel is two clicks (!) and if you organized the channels in things, you can generate all items for a thing by two clicks, so it’s not so much harder.
But if you don’t want to use textual configuration, it’s now possible and easy to do in the OH2 way of configuration, whether to use Paper UI, HABmin, REST or even karaf.

14

Hm, interesting answer.

Still not sure why it needed to become more complicated AND needed to have a new syntax, f.e. why do DPT‘s now carry a name as a definition for a DPT? The sole purpose of DPT‘s is to clarify the exact function of the respective object…

Splitting the config into things and items, I understand that this „is the way it is in OH2“…but maybe this „thing concept“ is just a little bit over the top for Knx, as the system itself uses HA abstractions via GA‘s. So connections are now done by a GA, that connects to a thing that is part of an item…?

15

Sorry, I don’t understand?

But please be aware that openHAB is not a knx system. openHAB is to integrate most of “smart” systems in one.
The thing “thing” is to allow autoconfiguration and autodiscovery for some smart systems. In fact, knx2 will provide “sort of autoconfiguration” by reading knxproj (from ETS5) in a future “advanced” version. So there will be no need to configure any thing for knx, and even item configuration will benefit, I think.

16

I was refering to this:

“upDown”, “stopMove” or “position” are names for DPT, whereas these functions are already defined by DPT themselves in KNX.

Agreed, but this should not mean that a binding needs to make things overly complicated, just to be “fully correct” in terms of the underlying technical concepts. Especially when it worked quite well (and relatively simple) in former versions.

BTW: KNX is no auto-discovery system. Even importing the project file would be no really “auto-discovery”, so one would anyway have to manually set and correct some things when using KNX. Again, keep it simple would reduce the possibility of human errors.

(btw: I recently heard in a podcast that the roots of OH where indeed in KNX…back in the days when Kai was looking for a system for his own home that was equipped with KNX… ;-))

17

No!
stopMove is the parameter name which refers to the corresponding GA, as is upDown and position. There are channels which have no reference to a special type of DPT at all (only one parameter named ga - but of course there is always a default DPT which is used, as is for specifically named parameters). It’s possible to use different DPTs for the same parameter (for example position, DPT 5.x or 9.x).

Yes, there is no real auto discovery for knx, because knx does not provide the necessary information, but to import the ETS5 project, is a nice way to ease the openHAB configuration.

In fact, you do not need to switch to OH2, and you do not need to use knx2 either.
But if using knx2, well, you should accept that it’s (very) different to knx1.
Every openHAB2 binding uses things and channels as an abstraction layer, that’s the way eclipse smarthome works.

18

Maybe I am using the wrong terminology (it’s a parameter, got it), but you essetially confirmed what I just said. It is still a naming that refers to some kind of default DPT = added abstraction & added complexity.

Lol, when the 1.x binding becomes a legacy one, it will be no longer be under development I’d guess. So in the mid-term, the KNX2 is not really just optional. Or are you saying I do not need to use OH at all, so I’d rather should go away? Hm :thinking:

That is what my whole thinking is all about - If things are changed, they should change for the better / simpler, not for being more complicated.

But I get the underlying messsage here: Take it as it is, because it is like it is and it needs to be like it is because this is the new way. Full stop. :joy:

So i’ll refrain from making suggestions or giving feedback in the future, as this is obviously not wanted. :wink:

Thanks for your efforts Udo, appreciate the time you took to reply and have a great weekend !

19

But it’s very different! Let’s compare to openHAB1/knx1:

Rollershutter ItemOfChannel1 "My roller shutter [%d %%]" {knx1="GA1,GA2,GA3"}

knx1 wants GA1 to be MOVE, GA2 to be STEP and GA3 to be Position.
If you don’t want to set GA2 at all, you can’t just omit the parameter, but you have to set the DPT for each following parameter (in this case 5.001:GA3). I’m not sure, if it’s even possible to change the order of the GA even when setting the DPT explicitly (and it’s the same for GA1 and GA2 anyway, so openHAB could not decide which is MOVE and which ist STEP)
Now in knx2 there is an explicit assignment for each parameter, so it’s not possible to mix them up anymore.

Type rollershutter : channel1 "My roller shutter" [upDown="GA1",stopMove="GA2",position="GA3"]

Yes, you have to type more characters, but this is way more readable than in knx1.
Yes, you have to link this channel to the item as an additional step, but with VSCode this is done with two klicks, and you could do it even without any textual configuration (Paper UI/HABmin/karaf/REST/…more to come).

Well, there are current bug fixes for other legacy bindings, and even new functionality, but to be honest, knx1 with openHAB2 is not as stable as it should be, and it’s not possible to change this without breaking knx in OH1, so, at least for knx you’re right :wink: nonetheless, OH1 is not end of life yet.

Well said… did you ever encounter such updates in ANY software?
Well, sometimes… but most of the time updates make things more complex, even for configuration, just because there are new possibilities.

When speaking of knx2, I see a more strict definition of channels, and it’s more clear where to put all those GA for the channels.
In question of -control channels, yes, it’s a pity that I have to define two items/channels for the very same thing, just to receive commands from the bus, but if that is the price to have a stable knx addon, I’ll bite the bullet, and to be honest, there is a difference between getting a rocker activity and the corresponding actuator state, so yes, one has to change old rules, but it’s correct and there’s not more complexity but only different triggers.

I didn’t want to be rude :slight_smile: and I’m no developer but only end user, it’s my point of view. I’m an openHAB user since OH1.0.
I wasn’t pleased to see an additional layer (things), but in the end I did understand why this step was taken.
I’m pretty sure there will be no step back because openHAB2 is developed with eclipse smarthome, and eclipse smarthome is maintained not only by Kai, there are commercial products using (and developing) eclipse smarthome as well.
So yes, in the end it’s “Take it or leave it.” but please, don’t be offended. I don’t want to offend anyone!

20

Ok, again, I get your points and i am not offended at all :slight_smile: It just sounded like you wanted to make it clear that I am on the wrong track and if I didn’t liked it i could go to a very hot place :wink:

I guess you are correct that almost any new software is the opposite of being less complicated than the old version. Maybe that is just what drives me so nuts, that everyone seems to prioritze technical aspects over usability (look at iOS, which lost the majority of it’s simplicity and elegance over the years and became fat, cluttered and sometimes really confusing).

So I will take the time and check the documentations, set up a test system and start to migrate everything to the new KNX2 binding within the next couple of weeks. Maybe while doing this I will eventually experience that “better concept” and “professionalism of that Binding” (which is something annother post called it) :joy:

Again, thanks for your time and have a great weekend!

21

Well, this is not fully correct: yes, you can still use the old OH1.x binding but it’s not supported anymore AND one must expect that somewhen in the future there will be breaking changes which prevent usage of newer versions of OH.

To be honest: I was really keen on the KNX2 binding but now I’m disappointed. I don’t see the added value/benefit for a user in comparison to the old v1.x binding, even worse - the configuration became needlessly complicated and would require a huge effort for . Just to have it “streamlined” with Eclipse SmartHome I would have preferred that all the efforts would have been spent in enhancements, stabilization, documentation of the old binding.

What about having a survey asking the KNX users about their satisfaction with the new vs. the old binding and where further development efforts should be spent. IMO this is much more “product thinking” (creating value) instead streamlining things just to have it streamlined.

Regards
John

P.S: As other users already stated: this is neither making developers work bad nor not appreciating that people are spending their spare time into open source development.

22
  1. knx2 is capable to be controlled via Paper UI
  2. knx2 is capable to be configured via Paper UI
  3. There is a more strict definition for channels (as written in OH2.3 with KNX2 - syntax of items not clear - #19 by Udo_Hartmann)
  4. A more strict separation between commands and changes or updates.

No, it’s not. The binding configuration moved from knx.cfg and knx.items to knx.things (or do the configuration via Paper UI, karaf, REST, HABmin…) Of course, now you have to define links to the channels, but even this is possible via Paper UI.

23

No, it’s not. The binding configuration moved from knx.cfg and knx.items to knx.things (or do the configuration via Paper UI, karaf, REST, HABmin…) Of course, now you have to define links to the channels, but even this is possible via Paper UI.

When I migrated my KNX Items (several hundred) I had indeed the impression that it is much more complicated.

In KNX1 I had on line in a configuration file per item, these files could be grouped by whatever I liked. In KNX2 I habe one entry in the things file, grouped by the KNX actuator, another entry in an items file, which must match the things definition. I had several hard to spot bugs, just because these entries where not matching correctly.

To make things worse, for some items I need another things definition for a “control type” and additional items for this as well, when wanting to use “received command” triggers. Rule triggers must be adapted and again a lot of opportunities to make errors and a illogical configuration.

Creating the items out of the things in VSCode might work for new installations, but not when migrating an old installation where the existing item names are used in a lot of places. Beside that, the problem with the additional “control” things persists.

I see the benefit in using the Paper UI for some, but as I do not use it and don’t want to (e.g. because this configuration can not be placed under version control) that is no advantage for me.

To be honest: Without the bugs in the current KNX1 Binding I would not even think about migrating…

24

This is one of the most confusing changes for me…Can someone maybe explain, why especially THIS change has been introduced? I have started playing around with zwave these days and couldn’t find anything similar there. No need for separate control items in zwave, so why in KNX ? (unless I have overlooked something here)

I do as well fully agree here…