OpenHab 3 Grundstruktur, Things für KNX

[nickknx]

Guten Morgen zusammen,

ich habe schon etwas länger gesucht aber so richtig, wie man es am besten macht habe ich noch nicht gefunden.

Wie habt ihr denn euer KNX System als "Things" und "Channels" hinzugefügt,
mich interessiert besonders die Grundstruktur und wie ich die Channels realisiert z.B. für ein Thermostat mit Sollwertverschiebung und Co.

Ich selbst habe es jetzt nach KNX Pro Raum aufgeteilt und dann alles was sich in dem Raum befindet als Channel angelegt.

Entgegen zu den Prinzip z.B. des Bindings Sonos wo jedes Gerät ein sep. "Thing" ist, frage ich mich nun was ist der richtige und geschickteste Weg für KNX.

Vllt. könntet ihr von eurer "Things" und "Channel" Ansicht ebenso mal ein paar Bilder posten und auch erklären wie man am besten ein Thermostet komplett abbildet.

p.s. Es funktioniert auch alles in der kommunikation ich kann die angelegt steuern und bedienen nur habe ich die Verbindung zu den Gateways/Bridges unterbrochen, ich immmer am basteln bin und nur Zeitweise aktiviere.

Ich hoffe ihr steinigt mich nicht gleich .

Anbei ein Bild von mir:

[zeebee]

Ist doch relativ egal wie du die Things und Channels anlegst. Letztendlich ordnest du ja über die Items. Ich habe einfach Things in für mich logische Gruppen angelegt: Alle Schalter, Alle Rollläden, Alle Temperaturen usw. Danach per semantischen Modell meinen Räumen zugewiesen.

Was du mit Thermostat abbilden meinst, weiss ich jetzt nicht. Du meinst das Zusammenspiel zwischen Mess-, Solltemperatur und Sollwertverschiebung? Das mache ich nicht per openHab, sondern an meiner Glasbedienzentrale 2 Smart.

[udo1toni]

Natürlich kannst Du knx Things so organisieren, wie Du willst. Korrekt ist es allerdings, pro Device ein Thing anzulegen. Ich habe das bei mir so aufgebaut, ich habe auch z.B. Lichtschalter als Things angelegt. Die GA gehören logisch aber normalerweise zu einem Aktor, weshalb die Lichtschalter dann keine Channel aufweisen. Dennoch ist die gesamte Hardware abgebildet. Wenn ich nun auf die Idee komme einen Wandtaster zu nutzen, um etwas zu steuern, was nicht über knx geschaltet wird, so trage ich in ETS die neue GA im Taster ein, wechsle nach openHAB, hinterlege dort die neue GA im passenden Thing als *-control Channel und bin mit der Konfiguration durch.

[Tokamak]

Die Things pro KNX-Device anzulegen, ist nicht "korrekt", sondern nur was, was der Autor des KNX-Bindings vermeintlich gemeint hat, weil er vorsah, dass man eine physikalische Adresse angeben kann - was man aber auf der anderen Seite nicht konfigurieren sollte.

Die Abbildung von Gruppenadressen auf KNX-Devices geschieht bereits in der ETS. Und da sollte sie meiner Meinung nach bleiben. Nach außen hin sichtbar ist der KNX-Bus lediglich mit seinen Gruppenadressen. Nur die werden in openHAB benötigt.

Daher ist der Ansatz von zeebee, "pro Typ" ein Things anzulegen, genauso stichhaltig und korrekt wie etwa mein Ansatz, Things pro Gewerk anzulegen, was in etwa meinen Hauptgruppen entspricht.

Ob ich den control-Channel der neuen Licht-GA dann einem "Schalter-Thing" a la zeebee, meinem "Licht-Thing" oder einem "Device-Thing" zuordne, ist im jeweiligen Thing-Modell schlüssig, der gleiche Aufwand und dem Item, was darauf aufbaut, vollkommen wurscht.

[udo1toni]

Selbstverständlich kannst Du das so halten, wie Du willst, aber die Definition eines Things ist sehr eindeutig in der openHAB Dokumentation beschrieben, es ist die Abbildung physischer Geräte.
Genauso kann man natürlich mqtt Things anlegen, wie man das will, schließlich ist der Broker das Device, mit dem sich openHAB unterhält. Kann man machen, ist aber nicht so gedacht. Und in diesem Sinne (ist nicht so gedacht) ist es auch nicht korrekt.

[Tokamak]

Der Autor des KNX-Bindings hat sich zu sehr am openHAB-Begriff "Thing" als "Device" orientiert. Softwaremodelltechnisch ist auch eine Haupt- oder Mittelgruppe ein Thing.

Softwaretechnisch ergibt es keinen Sinn, das Mapping zwischen GAs und Devices sowohl in ETS als auch in openHAB zu pflegen. Das ist doppelter Aufwand ohne zusätzlichen Nutzen. Das merkt man alleine daran, da eine Fehlkonfiguration in diesem Sinne in openHAB überhaupt keine Folgen hat, solange das Item auf den richtigen Channels aufsetzt.

ETS kapselt das Mapping-Know-How. Außerhalb ETS sind die Devices schlichtweg nicht sichtbar.

Natürlich kann das jeder machen wie er möchte. Nur die eine Variante als "korrekt" zu bezeichnen, hilft Usern nicht, die versuchen, einen Zugang zu openHAB und dem KNX-Binding zu finden und lieber nach GAs als nach Devices gruppieren möchten.

[udo1toni]

Es geht nicht um softwaretechnische Abstraktion, es geht um Hardware. Es gibt in knx keinerlei Regeln, die vorschreiben, wie GA organisiert sein müssen. Es gibt noch nicht mal eine Vorschrift, wie die GA aufgebaut ist, der Standard 5Bit/3Bit/8Bit ist lediglich default, man kann genauso auch zwei Ebenen 6Bit/10Bit oder gar eine vollkommen eigene Aufteilung der GA-Struktur vornehmen, schließlich handelt es sich nur um 16 Bit im Datenpaket.
Es ist auch für andere Systeme nicht zu umgehen, die Konfiguration der Systeme - zumindest teilweise - doppelt anzulegen, das liegt in der Natur von openHAB, dessen Aufgabe es ist, unterschiedlichste Technologien miteinander zu verbinden, und zwar ohne Herstellerwissen.

Was die Sichtbarkeit von Devices angeht: selbstverständlich steht in jedem Datenpaket drin, welches Device (!) das Datenpaket abgesendet hat. Diese Information ist jederzeit von jedem Empfänger einsehbar, nicht nur im ETS Busmonitor oder ETS Gruppenmonitor. Es ist nicht üblich und nicht vorgesehen, diese Information auszuwerten, dennoch ist es möglich; z.B. in MrHouse war das implementiert - man konnte z.B. in zwei Wandtastern die selbe GA hinterlegen und mit der selben GA unterschiedliche Reaktionen (außerhalb knx) auslösen.

[Tokamak]

Wenn es einen Unterschied macht, ob Device A oder Device B ein Ereignis ausgelöst hat, sind es zwei verschiedene Ereignisse (oder, in KNX-Sprech: Zwei Gruppenadressen). Das heißt, die Information gehört in das Ereignis.
Wenn ich in einem irgendeinem Code sähe, dass ein*e Entwickler*in neben dem Ereignis auswertet, wer es abgesendet hat, und das würde nicht Debugging oder Test dienen, würde ich ihm oder ihr den Puls fühlen und es als Bug einstellen.

Dass die Devices auf dem KNX-Bus sichtbar sind, ist für das Debugging notwendig und hat mir das eine oder andere Mal gute Dienste geleistet.

Wenn die Entwickler von EIB/KNX gewollt hätten, dass die Absender-Devices auswertbar wären, hätten sie auf die GAs verzichtet. Dann würde man in einem Device alle Kanäle durchnummerieren, und auf der Aktor-Seite würde man das Paar (Device, Channel) auswerten.
Es ist aber viel mehr so, dass kein mir bekanntes KNX-Gerät die Auswertung der Absenders in irgendeiner Logik zulässt.

Ich störe mich letztlich nur an dem Begriff "korrekt" und dem damit verbundenen Hinweis, es anders machen zu sollen. Dem ist nicht so.

Und damit ist das Thema, was mich betrifft, hier abgeschlossen.

[nickknx]

Guten Morgen zusammen,

vielen Dank an alle für euer Feedback,
also sehe ich es nun richtig so das es hier kein "korrekt" gibt sondern, eher vorlieben des einzelnen.

Ich hätte noch eine Bitte hat schon jemand von euch mal die Thermostat Funktion mit umgesetzt, also einstellbare Raumtemperatur?

Vg

[udo1toni]

Ich habe das bereits erläutert, und ich bleibe bei meiner Wortwahl. Korrekt im Sinne des openHAB Ansatzes ist es, pro physischem Gerät ein Thing anzulegen. Möglich ist es auch anders, niemand wird gezwungen, etwas so wie vorgesehen zu machen. Aber nicht alles, was funktioniert, ist automatisch auch richtig.

Ich habe in meinem Posting oben sehr genau erklärt, dass die Unterscheidung, von welchem Device ein Befehl kam, sehr wohl jederzeit möglich ist. Hätten die Entwickler das nicht gewollt, so hätten sie keine Quelladresse mit in die Datenpakete gebaut.
Es geht ausdrücklich nicht um knx Geräte, sondern Geräte außerhalb des knx Systems, welche die Kommunikation mitverfolgen, wie z.B. openHAB oder MrHouse.

Für die Raumtemperatur kommt es auf die vorhandenen Geräte an. Ich nutze z.B. Gira TS2+ als RTR, Soll- und Isttemperatur sind jeweils auf separate GA verbunden, in openHAB werden sie als Number Channel eingerichtet. Genauso sind die Betriebsmodi auf eigene GA geführt, so dass ich für jeden Raum getrennt zwischen Komfort, Nacht, Standby und Frostschutz wählen kann.

[heinemma]

Hallo zusammen,

ich würde mich zwar noch als Anfänger bezeichnen, was KNX und OpenHAB angeht, melde mich aber einfach mal zu Wort, da ich vor kurzem die Heizungsregelung erfolgreich in OpenHAB 3 abgebildet habe. Auch dank der vielen nützlichen Hinweise von udo1toni, die man im Netz so findet. Danke dafür an dieser Stelle 😉 Komischerweise hat bei mir die 1-Bit Temperaturverschiebung erst funktioniert, als ich den Switch-Channel unter dem tatsächlichen MDT GT2 Thing angelegt hatte.

Meine Konfiguration ist somit wie folgt: MDT GT2:
Ist-Temp // Number
Temp.verschiebung // Switch

MDT Heizungsaktor
Aktuelle Soll-Temp // Number
HVAC-Status // Number (5.010:2/3/15+<2/3/16)