Issue of the topic: I have a knx and a onewire binding. In the past i used openHab to publish changes on oneWire bus to a KNX object. It was very easy to do, i created one Item and add both connections (knx and oneWire) to this item and it worked out of the box.
With the “new” version 2 of the bindings the configuration changed completly. I have to create an entry in the thing file and use this reference in the item file.
So with this configuration i have to create two entries in both thing files and then use this references in the item file. Is this correct?
I do not understand why the configuration changed this way. In my mind this change make a lot more work without having new functionality. I am sure there is a document which describe why they changed it this way, but from my side i do not see the benefit of doing it this way.
Current config (with binding version 1):
Number TempRoom1 “Room1 O [%.1f °C]” (gEG, gOneWire, gSensoren) { onewire=“deviceId=28.FD05BE070000;propertyName=temperature”, knx=“9.001:0/4/51” }
config with binding v2:
knx thing:
Type number : Room1 [ ga=“9.004:0/4/51” ]
oneWire thing:
Thing basic Room1 [
id=“28.FD05BE070000”,
refresh=60
] {
Channels:
Type temperature-por-res : temperature [
ignorepor=true,
resolution=“11”
]
}
item:
Number TempRoom1 “Room1 O [%.1f °C]” (gEG, gOneWire, gSensoren) { onewire=“deviceId=28.FD05BE070000;propertyName=temperature”, channel=“knx:device:bridge:KNXITEM:Room1, onewire:basic:mybridge:Room1:temperature” }
So with this configuration i have to create two entries in both thing files and then use this references in the item file. Is this correct?
Note that is old version 1 configuration syntax and will not connect to the channel that you defined for onewire.
Docs confirm that you may link more than one channel and/or v1 binding to an Item
Hint {channel="this", channel="that"} is I think preferred over {channel="this,that"} although I think either works.
BUT
Note that in general, device data from bindings cause OH Item state updates.
Commands to Items cause bindings to send to devices.
So dual linking an Item does not usually cause data coming in one binding to go out the other. That’s by design.
This was an established principle in openHAB v1 as well. How it worked for you before is not at all clear. But read on …
It seems that you’d need the onewire binding to forward incoming data as an Item command.
A few bindings do have options for this unusual configuration, but not I think onewire v2
An alternative approach is to configure the KNX binding to send out Item state updates instead of commands.
Here we are in luck!
KNX binding v2 provides channels of xxx-control type, and these reverse the usual command/state relationship.
Intended for things like KNX wall control panels to issue commands to openHAB, they also have the effect of sending openHAB state updates onto the KNX bus. Just what you want.
So in summary -
Fix your onewire config to get your Item state updates.
Configure your KNX channel as number-control type to publish Item state updates to KNX
By separating the connection to the devices from the Items that represent various aspects of the devices we can:
automatically discover devices instead of needing to hard code their configuration parameters
apply Profiles which simplify and eliminate some simple Rules
have a means to package Actions along with a Binding instead of needing to install Actions separately
As an example for how this is an improvement consider zwave. In OH 1.x you had to keep a mental mapping between node numbers and device types. Then you had to look up your device to see what command classes it supports and which corresponding Item that command class is used with. If you have to remove and re-add a device to the controller, you have to watch the logs to verify what node it was added as. It was a giant book keeping nightmare. And Zwave was not alone in this. There were many bindings that required watching log files or researching all sorts of information from other sources in order to figure out how to write the Item’s binding configuration.
With this separation from Items and Things, now all you do is install the binding, create the Serial Controller Thing (replaces the stuff you used to put into zwave.cfg) and scan for the devices. It not only discovers all the nodes and creates all the Things for you, it determines all the command classes and provides Channels for all of them. All at the click of an icon.
Hi, maybe i am to old to use it in the correct way. I do not want to have the items in a database where i not able to see all the connection to each other. I like the config files. With this setup i am able to use vi or nano to get a complete overview of all items.
Maybe in future i will see the benefit of having this setup.
Hi, first of all thank you very much for your detailed answer. But i am not able to find a solution from your answer.
Your summary was:
Fix your onewire config:
I used the latest version of the plugin with the configuration described on the binding page to get the value. I do not understand what i have to change in the config.
I have read the knx binding doku about number-control and think i get an understanding howto use it.
So it would be great if you would spend some time to give me a full picture what to do.
Sorry i am not so familiar with the usage of this page. I want to reply to the post of @rlkoshak. His post sounds like. Configure zwave cfg. Scan for devices and use gui to configure. And i think with this setup there is a database where the binding and items are stored.
Thank you very much for sharing all your knowledge about openHab.
There is no requirement to have anything in the database, unless you want to take advantage of automatic discovery. And even then, only those automatically discovered Things are required to be in the database. And the database is just JSON formatted plain text file so it’s not all that opaque or hard to figure out.
If you don’t want to take advantage of the fairly large labor savings that comes with automatic discovery, that is fine. You don’t have to take advantage of that. But I would push back on a desire not to change anything being equated with no benefit at all with the new way 2.x bindings work.
Profiles are documented here. One of the profiles, the follow profile, causes any event that comes in on the first Channel linked to the Item to be forwarded to the second Channel lined to the Item.
So if you have
Number TempRoom1 "Room1 O [%.1f °C]” (gEG, gOneWire, gSensoren) { channel="onewire:basic:mybridge:mysensor:temperature", channel=""knx:device:bridge:generic:demoTemperature" [profile="follow] }
than any change on the onewire channel will be sent on to the knx device.
NOTE: I copied and pasted the channel IDs from the docs for each binding, you need to determine the proper IDs from your specific Things.
The Zwave binding as always had a database of all of the hundreds of devices that the binding can support. You used to have to manually look through that database in order to figure out what command channels a given make and model of a device (e.g. a light switch) supported so you could come up with the correct binding configuration for each Item. That does not have anything to do with putting Items in a database. This was a database you used to have to manually consult in order to figure out how to create your Items in the first place.
With Things, all that is done automatically for you now. Discover the Things, accept them from the Inbox and it’s all right there in front of you. All you have to do is copy the Channel ID and paste it into your .items file and you are done. No research required. No manually pouring through log files or searching through databases. It just happens.
This part onewire=“deviceId=28.FD05BE070000;propertyName=temperature”,
is for linking to version 1 onewire binding.
You want to use version 2, so remove it.
