Some very basic information on how things work:
The bus address can be seen as the physical unique address of device (e.g. an Actor, a Sensor etc) on the knx bus.
Each knx device owns some communication objects.
The number, purpose and data types vary depending on the device type and its configuration.
Those objects are linked to group addresses.
Now how does this magic work ?
You have an actor with 4 channels that switches mains power - might be for your light or for a wall outlet or whatever. (In case you want to dim your lights special dim actors are required.)
Let´s assume you have a simple switching actor.
In ETS you can see in the device list that your actor has been assigned a physical address (bus address). Opening that actor various parameters can be set - you may e.g. disable unused channels.
For the channels you have enabled certain communication objects are shown.
For a dim actor channel typical objects are a state channel, the actual switching channel, an absolute dim value etc.
By assigning a group address to a communication object (I break this down to the very basic stuff) the device starts listening for that address value to be contained in telegrams sent on the knx bus. (You actually need to program your settings into a device after setting it up in ETS, do not forget).
Lets assume you habe set group address 1/1/1 as the address of the switching object of your Channel A (the one connected to your kitchen light bulb).
Now you add this group address to e.g. a communication object on one of your sensors (the wall switches). As this is the first address (you may assign multiple one to an object, whenever you push the corresponding segment of the wall switch, the address is written as a telegram on the bus, containing e.g. “1” for on or “0” for off. Just a simple example, there is much more.
As your actor channel object from above is listening on the bus, it receives the telegram, figures out it is addressed to himself and takes the payload to either switch on or off the light.
That is the most simple case to illustrate how things work.
What you’ve learned so far:
Devices have unique physical addresses, that identify them on the bus.
Communication objects reflecting aspects of the device functionality are linked to group addresses
Group address is uses for communication between devices over the bus and link them together.
What does it mean for openHAB ?
A binding is “just” a piece of code that interfaces actual hard- or software to the OH system following OHs architectural design / interfaces.
Bindings support various types of Things - you may think of a thing as a representation for something that the binding supports (e.g. a knx actor).
Some bindings support auto-discovery of things, some do not. The knx binding does not.
In OH for knx you have to define the representation (thing) of an interface/gateway (you did that above) to the bus, allowing you to read and write telegrams from/to it. So you go to the configuration, goto Things and press the big fat “Plus” sign - guess you already configured your gateway thing that way.
Select the knx binding, and you see what is supported. So besides the IP Gateway and the serial interface something called “KNX device” is available - this is a generic representation of a device on the bus. Use this as your actor.
Enter a meaningful label (I usually start with the bus address, followed by e.g. “MDT Dim Actor Model” so have a structure) - feel free to use whatever you want.
Now select the gateway you already have up and running as your bridge.
Add the bus address of your actor. do not touch anything else.
Press create to save it.
Tada! The things shows up as being online.
But up to now it is just a hull, being empty without functionality.
So we go to the tab “Channel” and add a channel. There are various types of channels supported. Simply use the “Switch” type.
Enter a Channel Identifier, e.g. “Channel_A” and a label like “Kitchen Ceiling Light”.
Add your switching group address in the field that appears at the bottom. Check the binding documentation for adding e.g. a state later - lets just keep it simple here.
Create the channnel.
Screen switches. Now expand the channel you created.
Press plus to add an “Item”. Items a the object coding and UI are linking to in OH, it is another layer of abstraction. Items may be linked to multiple channels, but we just create a single new one here.
Keep everything as it has been defaulted and press the blue “Link” button at the bottom.
You see your channel has been linked to the new item.
You now established the complete chain Physical actor - IP Gateway - OH KNX Gateway thing (Bridge) - OH knx device Thing.
The actual functionality lies within the linking of:
knx Actor Communication Object <-> OH Thing channel <-> OH Item.
Now if you change the OH item this get propagated down to the communication object of the actor using the group address chosen and triggers the linked functionality (here: Switch the channel / light)
The easiest way: Go to the configuration, Choose “Model”, “Create Points from Model”, Choose your “knx Device” as thing, mark the channel you´ve created and say “Add to Model” (Keep all the defaults).
Now within the Model tree select the point you created.
You will see it on the right panel, a switch on top of it. Switch it, now, do it, have faith!
If everything went fine, your light bulb should now switch on and off.
For more details (this post is far too long) please take the time and read the documentations first - the RTFM approach works pretty well here. Not reading the docs will lead you nowhere.
Hope I was able to clarify things a bit for you. I know the learning curve is everything else than flat for OH. But it pays out.