I’ve been very successfully using OH1 for a couple of months. From the start I tried out OH2 every once in a while, the latest one just this week with OH2b4. I still can not get auto discovery for KNX going.
What is the status there? What do I have to do to make it work?
@alphaZ What do you want to be autodiscovered? In the KNX 2.0 binding there is discovery of Group Addresses just by listening a certain time on the bus and record everything that is flying by. I also jumped in the KNX protocol itself and built (part of ) a mechanism to scan the KNX bus for devices, and try to download object association tables as well as group address tables. It does work but pretty badly as the KNX bus is waaaaaaaay to slow to handle this kind of traffic.
What would really help is getting the ETS project file imported with all the Group Address Names. As it’s not recommended importing the ETS Project file directly, now KNX.org has released an ETS App. “KNX Web service exporter”, that can export all relevant data. Yes, it’s in beta release and format might change but I think it’s still a great tool to use as source for import into Openhab2.
Any chance you can try implement a import function for the exported xml file?
That is good news. I have studies the ETS4 output a long time ago, and decided NOT to write support to import that file into OH as it was simply way too complex to do that. I will have a look at their new tool
Hi,
I took some time to install the export app in ETS5 and did a test export.
Due to the somehow private nature of the information contained (group addresses uses for certain function like e.g. garage door openers) I do not want to share that file.
What I see is that you get a flat XML with listed entities that get linked together by various ID-Attributes.
One gap I see is that you do not get the bus addresses for the devices, but only the device itself, it´s descriptive title and more (objects available, group address linked etc). So there is no real fix Device ID to use
I did some XPath tests and you can get some useful information from the file. Examples:
Get all writable group adresses: //entity [@writable=‘true’]/@groupAddress
List all devices: //entity [@device=‘true’]
Each device has a link to the related data points (e.g. inputA, InputB …) by technical IDs.
These data points then show up as separate entities which then link to other entities that contain e.g. the group address connected.
I do not know how stable the IDs used are in case the ETS project get modified (add/remove devices, assign group addresses to objects…)
Mhhh… this does not provide more information than the discovery stuff I have implemented. The advantage of this file that it will be quicker than reading out all devices on the bus itself, and it won’t flood the bus. I am not sure we should implement a reader for this…
In question of Gira homeserver, the esf-file format is used (does work since ETS1…). It’s called "Datenaustausch (z.B. OPC)… in german version. This will generate a simple text file (extension is .esf). Unfortunately there is no exact information about the DPT, but at least you will get a complete GA list with plaintext description, .
In a real-life environment this becomes much more complex (E.g. I have multiple 20-channel actors from MDT and their new, (really cool), Smart Switches running) - if you fully active all features for single actor you already get around 100 data points.
What I find interesting is that you get the descriptive texts from ETS and the building structure including the device assignment - Things you do not get from a bus scan. Afaik the OPC export does not provide building structure information, but you get the descriptive texts.
Here the corresponding ESF file content
OHTest
Schalten.Licht.0/0/1 Licht1 EIS 1 'Switching' (1 Bit) Low
Schalten.Licht.0/0/2 Licht2 EIS 1 'Switching' (1 Bit) Low
Schalten Status.Licht.1/0/1 Licht1Status EIS 1 'Switching' (1 Bit) Low
Schalten Status.Licht.1/0/2 Licht2Status EIS 1 'Switching' (1 Bit) Low
XML content seems to be a bit richer, but I´m missing the actual device address and the datapoint types (those are in the file, but somehow abstact).
The xml file has obviously more information, the downside is, it’s available since ETS5(?), where esf is available since ETS1(!).
I don’t like to upgrade to ETS5 without a really good cause, please don’t forget, it’s about 1000EUR in charge, I’m no professional electrician, so I won’t have any benefit from ETS5 (so far, all my equipment can be programmed through ETS3…)
I have now in more detail studied ETS 5.5, ETS Web Services and ETS Inside (beta from Aug) - Konnex has related to their IoT strategy implemented a new feature in latest version of ETS called “Functions”. It’s viewed in the Building topology. Creating a new function automatically creates the GAs that Konnex has defined as standard for the particular type of function. See example in screen dump below.
So far I understand, Functions are similar to “Items” in OH2. For example, the standard function “Dimmer” includes the four group addresses for switching, dimming, value and status. Going forward with a future KNX Bindning v2.x I think this feature will be important to focus on.
From ETS 5.5 help file:
"This is an element for structuring (= collecting) group addresses in the building view. In the structure (= functions), existing or new GAs can be stored in a function (i.e. linked to it) in a room structure.
The advantage is that GAs are shown directly in the building structure at the place
where they operate and can be used for creating a link with channels."
Copy of xml exported from ETS 5.5 with ETS Web Services exporter. Project is created using the Wizard in ETS 5: Test ETS Web Services exporter 2.pdf (51.5 KB)
Out of curiosity - what is the exact problem now - generating things and items file form XML? Creating Thing instances from XML file in openhab?
I did generator of these two formats for BACnet binding and it might be done as a standalone app. I also did a frame injection tool for wmbus as non-framework servlet.
Bindings are just fine without XML and surrounding tooling - as far I can see the KNX file is description of the building structure and/or commands supported by devices.
Currently, I’m evaluating ioBroker and their KNX Adapter so I’m not up to date with the OH2 KNX Binding. What I really like with the KNX Adapter in ioBroker is that you can directly import the ETS5 project file and there is no need to first export it from ETS using XML or the old GA export feature. It also maps the status GAs and imports the building structure from ETS at the same time. Unfortunately, it doesn’t support the ETS5 Functions yet. If you are interested in more details: https://github.com/ioBroker/ioBroker.knx
So far I know, not much development has been invested in the OH2 KNX Adapter last years and it surprises me as I thought KNX was an important technology for many OH users. But I suppose this is not the case. I plan to look back into the KNX features of OH2 some time in the future as I like the broader international user base of OH.
Well, in fact, knx is a european technology. So, when becoming international, openHAB tends to drop attention to knx (shame on the developers )
On the other hand, I doubt that ioBroker will succeed in every case when importing the project file from ETS5, as ioBroker has the same problems as openHAB: the structure is not the same as in knx, so you have to map some functionality.
Of course it would be a nice feature to get almost everything from knx to openHAB, but as there are other more annoying problems with knx and openHAB (disconnect, missing packets, )…