OpenHAB Export aus der ETS5

[alanz]

Hallo zusammen,
ich bin Anfang des Jahres vor dem selben Problem gestanden. Nachdem ich die files zuerst manuell erstellt hatte, hat's mich irgendwann so genervert das ich mich hingesetzt habe und einen Converter für das knxproj-File in Java gebaut habe. Das ganze funktioniert so, dass KNX Funktionen anhand eines Prefix im Number Feld in verschiedene Typen von Things konvertiert werden. Dabei werden aus den GAs der Funktion anhand von Suffixen quasi die unterschiedlichen Channels. Ich verwende dann Apache Velocity Templates, um daraus das thing, items und sitemap File zu generieren. Über speziell formatierte Kommentare im KNX können dabei sogar die Groups, Icons etc. gesteuert werden. Ich verfolge dabei einen Single-Source Ansatz (in diesem Fall das KNX-File).

Aktuell generiere ich damit bei mir das komplette .things File mit rund 160 Things / ~850 Zeilen, das Items File mit ~700 Zeilen und meine Haupt-Sitemap.

Genug gelabert

Das Ganze ist nicht ganz einfach zu verwenden. Man muss sich mit Velocity Templates auseinandersetzen und sich auf KNX Seite an einige Regeln halten. Außerdem ist es auf meine aktuellen Bedürfnisse zugeschnitten.
Aber: Wenn Interesse besteht würde ich es demnächst mal etwas aufräumen und etwas dokumentieren und auf GitHub zur Verfügung stellen.
Einzige Einschränkung: Das Ganze benötigt die XML Schema Definition aus der ETS. Da ich kein ETS Entwickler bin kann ich diese nicht zur Verfügung stellen. Man kann sich die Datei aber relativ einfach aus einer ETS Installation extrahieren... Damit kann ich auch keine fertigen Builds bereitstellen. D.h. man muss sich das ganze selber bauen.

Gruß

[udo1toni]

Das klingt sehr spannend. Allerdings... Wenn Du eh schon konvertierst, wäre es evtl. sinnvoller, gleich nach JSON zu konvertieren (was dann auch unter OH3 funktioniert). statt das alte Textformat, welches unter OH3 nicht mehr untertützt wird.

[alanz]

Hallo,
aktuell basiert bei mir noch alles auf things, items und sitemap Files. Ist ein wenig historisch bedingt. KNX ist erst kürzlich nach dem Umzug in unser neues Haus dazu gekommen. Mit der JSON-Variante habe ich mich bisher noch nicht beschäftigt...

Allerdings ist das ganze generisch aufgebaut, so dass man damit auch JSON erzeugen könnte. Man müsste einfach nur die Velocity Templates (https://velocity.apache.org/) entsprechen anpassen. Ich erzeuge bspw. auch eine html-Seite mit allen Items über diesen Mechanismus.

Hab die letzten Tage mal noch eine Readme dazu geschrieben und etwas aufgeräumt. Die Readme ist sicher noch verbesserungswürdig und es fehlt noch einiges. Für den Anfang sollte es aber reichen.

Das ganze steht hier auf GitHub zur Verfügung: https://github.com/Blizzard26/knxTools

Gruß

[TLA]

Ich schaue mir das mal an. Irgendwie muss ich da aber auch noch mal etwas "abstrakter" drauf schauen.
Zumindest sagt mir mein Bauch: Das ist noch keine dauerhafte Lösung.
Ich muss ggf. auch erst mal besser verstehen wie man Things to KNX Devices und dem abstrakteren Konzept von Kanälen mapped.

[alanz]

Nunja, es gibt leider kein wirkliches 1:1 Mapping zwischen KNX und OpenHAB, da die beiden doch recht unterschiedlich aufgebaut sind. Das Mapping Funktion -> Things schien mir das logischste / flexibelste zu sein. Ein Thing entspricht einem "physischen" Device. Für mich kam das den Funktionen am nächsten - die entsprechen ja quasi auch einem Ding in der Wirklichkeit (z.B. einer Lampe). Man hätte es auch an den tatsächlichen Geräten in OpenHAB aufbauen können. Aber da gibt's keinen guten Schnitt; nimmt man jetzt den 16x Schaltaktor im Schaltschrank oder den Taster im Raum? So entspricht die Funktion / das Thing der Lampe im Raum. Schien mir am logischsten zu sein. Abgesehen davon kann man die Funktionen aufbauen wie man möchte und hat damit maximale Flexibiltät... Mir ist aber auch klar, dass das ganz schön Aufwand bedeutet, wenn man in der ETS bisher keine Funktionen verwendet hat.

Gruß

[udo1toni]

Eigentlich ist sehr genau definiert, dass ein physisches Gerät in knx einem Thing in openHAB entspricht - das kann man schon daran fest machen, dass man pro Thing eine physikalische Adresse setzen kann.
Allgemein steuert man von openHAB aus Lichter, Motoren usw., Schalter werden eher selten "gesteuert"; allerdings kommt es durchaus vor, dass man einen Schalter oder Taster an der Wand verwenden möchte, um etwas außerhalb knx zu steuern. Nur diese Taster werden in openHAB benötigt.
Etwas anders sieht das natürlich aus, wenn die Taster z.B. auch Messwerte liefern.
Aber auch dann ist die Zuordnung vorhandener GA logisch eindeutig: GA gehören dem Device, welches den Zustand hält, also für Messwerte der Sensor, für Schaltstellungen der Aktor. Ein Schaltbefehl kann von verschiedenen Tastern kommen, aber eine betimmte GA steuert immer genau einen Aktorkanal (es sei denn, es handelt sich um Zentralfunktionen, natürlich) und gehört damit logisch zur Rückmeldung, die genau zu einem Aktorkanal gehört.

Übrig bleiben damit dann nur ein paar wenige GA, welche übergreifend verwendet werden und somit überhaupt keinem Gerät "gehören". Diese kann man prima in einem "virtuellen" Gerät zusammenfassen.

[alanz]

Prinzipiell gebe ich dir recht, was die OpenHAB Seite anbelangt. Auf der KNX Seite ist es leider nicht ganz so einfach. Ich habe bspw. diverse Schalter bei denen ich die LEDs zur Statusanzeige verwende und diese über Regeln aus OpenHAB heraus schalte....

Auf der KNX Seite zu identifizieren, welches Gerät den Zustand hält ist leider in vielen Fällen unmöglich bzw. nicht eindeutig. Bei einer Lampe ist der Zustand eigentlich im Schaltaktor hinterlegt. Andererseits halten die meisten Schalter ebenfalls den Zustand um umschalten zu können. Sprich beide Seiten haben L und S Flag (sei es auf einem ComObjekt oder mehreren). Man kann also nicht automatisch entscheiden was jetzt das "physische" Gerät repräsentiert. Auch hat man häufig Fälle bei denen GAs mehrere Geräte steuern (z.B. einen zentralen Licht aus Schalter). In OpenHAB möchten man das ggf. ebenfalls als Schalter haben (wobei es da mit dem Zustand nicht ganz einfach ist). Das in KNX zu erkennen erscheint mir fast unmöglich.
Daneben ist die Struktur der Geräte häufig von Hersteller zu Hersteller unterschiedlich. D.h. man müsste für jedes Gerät ein Mapping nach OpenHAB umsetzen. Bei Schaltern von Jung habe ich beispielsweise ein Com-Objekt für Schalten und Status; Bei Schaltern von MDT sind es zwei Com-Objekte.
Schlussendlich interessiert mich das eigentliche physische Gerät in diversen Fällen eigentlich nicht direkt. Zum Beispiel interessiert mich die Zimmertemperatur eigentlich "nur" im Kontext der Heizung. Ein separates Thing in OpenHAB brauche ich dafür nicht.

Aus all den Gründen hatte ich mich dazu entschlossen die Funktionen in der ETS zu verwenden. Damit lassen sich meiner Ansicht nach "physische" (und auch virtuelle) Gerät am besten abbilden. Für ein direktes Mapping hatte ich bei meinen ersten Versuchen leider keinen wirklich sinnvollen Weg gefunden.

[udo1toni]

Prinzipiell gebe ich dir recht, was die OpenHAB Seite anbelangt. Auf der KNX Seite ist es leider nicht ganz so einfach. Ich habe bspw. diverse Schalter bei denen ich die LEDs zur Statusanzeige verwende und diese über Regeln aus OpenHAB heraus schalte....

Das ist bei mir genauso. Allerdings brauche ich dazu keine Regeln in openHAB, die Statusanzeige funktioniert rein in knx.

Auf der KNX Seite zu identifizieren, welches Gerät den Zustand hält ist leider in vielen Fällen unmöglich bzw. nicht eindeutig.

Da muss ich entschieden widersprechen. Es gibt exakt eine Quelle für den Zustand eines Schaltaktors, und das ist immer und ausschließlich der Aktor selbst.

Bei einer Lampe ist der Zustand eigentlich im Schaltaktor hinterlegt.

Nicht nur eigentlich

Andererseits halten die meisten Schalter ebenfalls den Zustand um umschalten zu können. Sprich beide Seiten haben L und S Flag (sei es auf einem ComObjekt oder mehreren).

NEIN! Innerhalb einer GA darf nur maximal ein KO ein gesetztes L-Flag haben, sonst kommt es zu einer Kollision bei Leseanfragen. Ein Schalter darf niemals auf Leseanfragen antworten, es sei denn, es geht um GA, die keinem Aktor zugeordnet sind (und es ist sichergestellt, dass dieser Schalter der einzige ist, der auf Leseanfragen antwortet)

Man kann also nicht automatisch entscheiden was jetzt das "physische" Gerät repräsentiert.

Wie gesagt, das ist ganz eindeutig ausschließlich der Aktor, der die Lampe schaltet. Alles andere ist schlicht falsch.

Auch hat man häufig Fälle bei denen GAs mehrere Geräte steuern (z.B. einen zentralen Licht aus Schalter).

Ja, vollkommen normal. Es gibt aber immer exakt eine GA, auf der ein Gerät sendet (wenn es denn auf dem KO senden darf) und das ist die 1. angegebene GA (oder auch Haupt-GA)

Der korrekte Aufbau eines Schaltkanals:
Aktor KO1 (Ein/Aus setzen): GA1,GA2,...
Aktor KO2 (Ein/Aus Rückmeldung):GA3
Aktor KO3 (Szene): GA4
Aktor KO4 (Zwangssteuerung): GA5
Schalter KO1:GA1,GA3(!)
weitere Schalter identisch
Zentral aus KO: GA2
Szenensteuerung KO: GA4
Zwangssteuerung KO: GA5

Wenn der Aktor auf Ein wechselt, sendet er über GA3 seinen Zustand, der in allen Schaltern ankommt. Somit "weiß" jeder Schalter, dass der nächste Befehl der Aus Befehl ist. Kontrolllämpchen gehen an, die hängen parallel zum KO1.
Wenn man nun Zentral aus drückt, wird immer Aus gesendet, der Aktor wechselt auf Aus, sendet Aus auf GA3 und alle Schalter wissen, dass der nächste Schaltbefehl Ein ist.
Somit spielt es auch keine Rolle, ob der Aktor eventuell in einer knx Szene mit spielt (im Beispiel GA4) oder z.B. Zwangsstellungen hat (GA5), Treppenlichtautomatik beinhaltet, whatever...
Der Schalter an der Wand kann niemals den Status des Aktors halten, er hat schlicht nur unzureichende Kenntnis über die verknüpften GA und deren Funktion. Er kann aber immer dem Zustand des Aktors folgen.

openHAB tritt, wie bereits erwähnt, im Allgemeinen als Schalter auf, das heißt, es erteilt Befehle und bekommt als Antwort ein Status Update. Es kann somit identisch zum Wandtaster konfiguriert werden, soweit es sich um gewöhnliche Schalter handelt.
Nur, falls das zu schaltende Objekt kein knx Schaltaktor ist, tritt openHAB stellvertretend als virtueller Aktor auf. Und in diesem Moment ist openHAB als Aktor auch für den Status zuständig. Wenn ein switch-control Channel einen Befehl empfängt, so führt das darauf folgende postUpdate zum Senden des Status auf der 1. angegebenen GA.

Die Entwickler von knx haben sich schon Gedanken um die möglichen Szenarien gemacht. Normalerweise gibt es keine separaten Status KO in Schaltern, so dass man gewöhnlich die Status-LED nicht frei nach Belieben ein- und ausschalten kann. Das kann bei komplexen Schaltern wie dem MDT Glastaster anders sein, grundsätzlich ist der Status aber an das KO gebunden, welches zum Senden des Schaltbefehls verwendet wird.

[alanz]

Das ist bei mir genauso. Allerdings brauche ich dazu keine Regeln in openHAB, die Statusanzeige funktioniert rein in knx.

Kommt auf die Logik dahinter an. Wobei ich sonst keine Visu oder ähnliches im Einsatz habe; nur ein Logikmodul und das reicht an der ein oder anderen Stelle nicht aus.... Daher habe ich komplexere Logik in OpenHAB. Dazu gehören Teilweise auch komplexere Status.

NEIN! Innerhalb einer GA darf nur maximal ein KO ein gesetztes L-Flag haben, sonst kommt es zu einer Kollision bei Leseanfragen. Ein Schalter darf niemals auf Leseanfragen antworten, es sei denn, es geht um GA, die keinem Aktor zugeordnet sind (und es ist sichergestellt, dass dieser Schalter der einzige ist, der auf Leseanfragen antwortet)

Wenn ich einen Jung Schalter mit BA (4071.01) hinzufüge sind beim "Schalten" KO standardmäßig alle Flags gesetzt. Das mag nicht im Sinne des Erfinders sein, funktioniert bei mir aber von Anfang tadellos. Ich habe diverse GAs bei denen das L-Flag bei mehreren KOs gesetzt ist. Das ist zwar nicht sauber, solange aber nur ein KO den Wert tatsächlich ändert und alle anderen diesen nur spiegeln sehe ich da wenig Probleme - auch wenn es nicht korrekt sein mag.

Unabhängig davon, ob das so richtig ist oder nicht, ist das zentrale Problem eigentlich die Aktoren. Bei den meisten Aktoren, habe ich keine Möglichkeit gefunden die Kanäle sinnvoll zu identifizieren. Meist sind diese nur über den Namen der KOs definiert. Kanäle (im Sinne des separaten Tabs in der ETS) sind häufig nicht hinterlegt bzw. können auch nicht angelegt werden. D.h. man müsste sich zur Erkennung der Kanäle auf Sprachtexte verlassen (die auch noch zwischen den Herstellern unterschiedlich sind). Bei manchen Aktoren können die Namen der Kanäle auch in der ETS geändert werden. Eine wirklich sinnvolle Möglichkeit zu identifizieren, welche KOs einen Kanal bilden habe ich nicht gefunden. Bin aber für Vorschläge offen.

Wobei ich die Variante über Funktionen für mich bevorzuge, da ich darüber auch öfter mehrere physische Dinge zu einem Verknüpfe (z.B. Heizungsaktor + Isttemperatur aus dem Zimmer)

[udo1toni]

Wenn ich einen Jung Schalter mit BA (4071.01) hinzufüge sind beim "Schalten" KO standardmäßig alle Flags gesetzt. Das mag nicht im Sinne des Erfinders sein, funktioniert bei mir aber von Anfang tadellos. Ich habe diverse GAs bei denen das L-Flag bei mehreren KOs gesetzt ist. Das ist zwar nicht sauber, solange aber nur ein KO den Wert tatsächlich ändert und alle anderen diesen nur spiegeln sehe ich da wenig Probleme - auch wenn es nicht korrekt sein mag.

Es gibt Kollisionen auf dem Bus (das wird nirgendwo angezeigt, auch nicht im ETS Busmonitor, der Busankoppler erkennt die Kollision) Jung ist offensichtlich an dieser Stelle etwas übers Ziel hinausgeschossen.

Unabhängig davon, ob das so richtig ist oder nicht, ist das zentrale Problem eigentlich die Aktoren. Bei den meisten Aktoren, habe ich keine Möglichkeit gefunden die Kanäle sinnvoll zu identifizieren. Meist sind diese nur über den Namen der KOs definiert. Kanäle (im Sinne des separaten Tabs in der ETS) sind häufig nicht hinterlegt bzw. können auch nicht angelegt werden. D.h. man müsste sich zur Erkennung der Kanäle auf Sprachtexte verlassen (die auch noch zwischen den Herstellern unterschiedlich sind). Bei manchen Aktoren können die Namen der Kanäle auch in der ETS geändert werden. Eine wirklich sinnvolle Möglichkeit zu identifizieren, welche KOs einen Kanal bilden habe ich nicht gefunden. Bin aber für Vorschläge offen.

Das ist halt ein zentrales Problem bei knx, es gibt keine zwingenden Zusammenhänge, die man allgemein aus der Datenbank auslesen könnte. Allerdings kann man im Aktor davon ausgehen, dass alle KO eines Kanals numerisch aufeinander folgen. Es gibt also x mal n + m KO, wobei x die Anzahl KO pro Kanal, n die Anzahl Kanäle und m die kanalübergreifenden KO sind. Natürlich kann man oftmals einzelne KO einzelner Kanäle "ausschalten" oder umschalten. das macht es nicht einfacher
Letztlich muss der Anwender wissen, welche KO zueinander gehören und welche Bedeutung sie haben (denn die Namen differieren ja auch von Hersteller zu Hersteller).
Diese Aussagen gelten aber genauso auch für Taster

Wobei ich die Variante über Funktionen für mich bevorzuge, da ich darüber auch öfter mehrere physische Dinge zu einem Verknüpfe (z.B. Heizungsaktor + Isttemperatur aus dem Zimmer)

Nun ja, es steht Dir frei, die Things anders zu verwenden als gedacht

[alanz]

Das ist halt ein zentrales Problem bei knx, es gibt keine zwingenden Zusammenhänge, die man allgemein aus der Datenbank auslesen könnte.

Dem kann ich nur zustimmen.

Allerdings kann man im Aktor davon ausgehen, dass alle KO eines Kanals numerisch aufeinander folgen. Es gibt also x mal n + m KO, wobei x die Anzahl KO pro Kanal, n die Anzahl Kanäle und m die kanalübergreifenden KO sind. Natürlich kann man oftmals einzelne KO einzelner Kanäle "ausschalten" oder umschalten. das macht es nicht einfacher
Letztlich muss der Anwender wissen, welche KO zueinander gehören und welche Bedeutung sie haben (denn die Namen differieren ja auch von Hersteller zu Hersteller).
Diese Aussagen gelten aber genauso auch für Taster

Die Variante mit Anzahl KOs pro Kanal hatte ich auch mal überlegt. Fand ich aber nicht besonders prickeln, da ich dass dann immernoch pro Aktor-Typ hätte definieren müssen. Außerdem hätte man quasi pro KO im Kanal nochmals die Bedeutung hinterlegen müssen. Es lässt sich bei einem Jalousienaktor leider nicht wirklich unterscheiden, ob es sich beim Prozentwert jetzt um die Position der Jalousie oder die Lamellenposition handelt.

Am Ende fand ich die Variante mit den Funktionen ganz charmant, da Sie in gewisser Weise den Things entsprechend und ich Sie vor allem auch den Räumen zuordnen kann - das wäre bei den Aktoren schwierig. Damit kann ich mir die komplette Sitemap inklusive Stockwerks/Raumaufteilung aus der Struktur in der ETS Ableiten. Bei mir wird gerade quasi alles (Things, Items, Sitemaps) aus dem ETS Projekt generiert. Alles was dort keinen Platz hat wird über statische includes hinzugefügt.

Sieht dann bei mir so aus:
ETS.png

KNXOverview.png
Wohnzimmer.png