KNX Properties

[TobyLorenz]

Der KNX Standard ist nix fuer schwache Nerven. Die Informationen sind gut versteckt und kreuz und quer verteilt.

Ja, in der Tat. Einige Informationen sind an verschiedenen Stellen enthalten oder ergänzen sich gegenseitig.

Das ist der Grund, warum ich bei mir in jeder Klasse und jedem Datentyp eine Doxygen Referenz auf die Spezifikation hinterlassen habe. Dann kann ich später noch mal nachschlagen, wo ich das her habe. Bei mir steht dann z.B. "@ingroup KNX_03_08_02_07_06_01", was so viel heißt, wie KNX Part 3/8/2 Kapitel 7.6.1 Search Request Frame. :-)

Ich nutze gerne pdfgrep wenn ich was suche.

Cool, hab gleich mal ein "apt install pdfgrep" laufen lassen. Danke für den Tipp. Kannte ich noch nicht :-)
Da sind in der Tat noch ein paar Teile, die ich mir noch nicht im Detail angesehen habe: 3/5/2 Management Procedures und 3/5/3 Configuration Procedures.

Wirst du den Stack veroeffentlichen?

Ja, ich denke schon. Hab schon einige Libraries veröffentlicht. Meistens unter Dual License: GPLv3 und Commercial. So bringt mir das Hobby immer einen kleinen Nebenverdienst ein ;-)

Nur habe ich bisher keine Applikationen veröffentlicht. Da fehlt mir noch eine geeignete Lizenz für OpenETS, die eine kommerzielle Nutzung kostenpflichtig macht, und ansonsten kostenfreie Nutzung erlaubt. Sowas wie Creative Common CC BY-NC-ND nur eben für Software.

[S. De Bruyne]

There are Properties. If you write data, and you read it back, you get the same data. REST-isch avant le mot.
And then there are Properties that you write, cause a command, and when you read them back, you get something totally different. They are the exact same things, just of type PDT_FUNCTION.
Then, sometimes, you want to query the network for information. So, you have to type this information. For this, the same identifiers are used. But querying requires parameters, different from the data of the actual Property. So, it is not required that any Property shall support querying; only a handful. The Properties that support these may be called Network Properties. That is not a different type, rather a different classification. Exactly what the spec says. And the rest is in the specification of the individual Properties, in the Management Procedures and in the Profiles.

The KNX Specifications are organised according hardware, software, specification and testing. Now, everything you need to implement Layer x is comfortably together in one document, and the tester also has all things nicely together. Meanwhile, and one of the reasons why there is no index, there are powerful search functions that you can use, as suggested.

And indeed, please do not reduce the protocol just to a collection of Frame formats. Check how the services are used and consult the Management Procedures.

[Zepp]

Da sind in der Tat noch ein paar Teile, die ich mir noch nicht im Detail angesehen habe: 3/5/2 Management Procedures und 3/5/3 Configuration Procedures.

wenn du einen Stack fuer einen management client (=ETS) bauen willst, sind das mit die wichtigsten Teile.

[TobyLorenz]

Thanks S. for the explanation. This made it already much clearer for me.

And indeed, please do not reduce the protocol just to a collection of Frame formats. Check how the services are used and consult the Management Procedures.

Yes, indeed it was already interesting to implement layer per layer. The interesting stuff happens there. Frames are just the events to trigger something ;-)

It's like playing a game and the first 7 levels up to including the Application Layer is solved already. Now I'm in the 8th level, the AIL. And then by implementing the Management Procedures and Configuration Procedures the game is over :-)