openhabforum.de

Hallo,

Ich hab ein kleines Problem mit der Erstellung von Equipment im semantischen Modell. Es tritt dann auf wenn ich versuche einen KNX Schaltaktor bzw. dessen Channels für Licht in den einzelnen Räumen hinzuzufügen. Im OH erscheint nach dem ich versuche das entsprechende Equipment zu erzeugen:

An error occurred while creating the items: Bad Request

auf der Log Seite kommt:
rest.core.internal.item.ItemResource] - Received HTTP PUT request with an invalid item name '1142A5Schaltaktor'

Ich nehme stark an dass es da ein Problem mit dem item name gibt, aber was ist an dem falsch bzw. wie kann ich das korrigieren?

Schönen Gruß

Es ist ganz einfach Erlaubte Zeichen für IDs sind die Buchstaben des englischen Alphabets (groß oder klein), ab dem zweiten Zeichen zusätzlich auch die arabischen Ziffern sowie der Unterstrich und das Minuszeichen. Das zugehörige Pattern sähe so aus: [a-zA-Z][a-zA-Z0-9_\-]* wobei der Backslash notwendig ist, weil das - ein Sonderzeichen innerhalb REGEX ist.
Das erste Zeichen muss immer und überall, wo IDs geschrieben werden, ein Buchstabe sein, ob nun Things, Channel, Rule-IDs oder Items.
Das Label hingegen ist frei, es darf beliebige Zeichen beliebiger Sprachen enthalten, letztlich so ziemlich alles, was UTF-8 hergibt. (Wobei es sicherlich Zeichen gibt, deren Darstellung dann Probleme bereitet...)

Grundsätzlich kannst Du Namen frei definieren, aber ich möchte dringend davon abraten, Itemnamen an einer Hardware auszurichten. Ich hatte das bei mir auch mal so und es ist Quatsch.
Stattdessen sollte man sich klar machen, dass es mehrere Abstraktionsebenen in openHAB gibt.
Die erste Ebene sind die Bindings, welche Zugriff auf die verschiedenen Systeme gewähren. Das Binding wird über Things konfiguriert.
Handelt es sich um ein Bussystem (wie z.B. knx) so gibt es eine Bridge (die ist aber auch ein Thing, nur halt übergeordnet für die am Bus angebundenen Geräte) .
Man kann in einem System beliebig viele Bridges für ein Binding haben, das ist natürlich nur sinnvoll, wenn Du z.B. von einer openHAB Instanz mehrere knx-Universen steuern möchtest.
Jedes Thing ist das Äquivalent zu einer Hardware (sofern es das in dem Binding gibt), also z.B. ein REG von knx, ein Busankoppler mit aufgesetztem Wandtaster usw.
Unterhalb des Things gibt es Channel für die verschiedenen Funktionen, also bei einem Schaltaktor z.B. den Channel, der das Relais ein- und ausschaltet.
Die ID eines knx Channels ergibt sich also daraus in dieser Form: knx:device:bridge:reg_123:ch1 Dabei ist knx das Binding, device ist das Schlüsselwort für die Art des Things, bridge ist der Name der Bridge (und da ich nur eine habe, gibt es keinen Grund, hier nicht die generische Bezeichnung zu verwenden) reg steht für ReihenEinbauGerät (ich habe auch schon den Herstellernamen verwendet oder den Typ dort angegeben, also z.B. gira_ts2plus_47 für für einen Gira Tastsensor 2 plus) und am Ende steht der letzte Teil der physikalischen Adresse (muss man nicht rein schreiben, ist aber manchmal praktisch bei der Zuordnung und halt ein eindeutiges Merkmal, in dem sich auch baugleiche Geräte immer voneinander unterscheiden). Da ich nur eine Linie betreibe, reicht mir der letzte Teil für Eindeutigkeit.
ch1 ist schließlich der Kanal, da es sich um einen Schaltaktor handelt (und dieser keine weiteren Extras wie Strommessung bietet) reicht das super zur eindeutigen Identifikation.
Der Channel hat auch noch ein Label, da steht z.B. "Wohnzimmer Stehleuchte" drin.
Zack, habe ich in der Things Liste ein Device, was meinetwegen "Schaltaktor 6fach 1" heißt und dort gibt es einen Channel "Wohnzimmer Stehleuchte", über den die Steckdose geschaltet wird, an der diese Stehleuchte angeschlossen ist..

Und nun folgt eine weitere Abstraktionsebene in openHAB, das sind die Items.
Items haben genau gar nichts mit der Hardware zu tun, bis sie mit einem Channel verlinkt werden. Aber dieser Link kann jederzeit aufgehoben werden.
Ich könnte also ein Switch Item anlegen, und dies mit dem beschriebenen Channel verlinken und nenne das Item EGWohnen_Stehleuchte.
Später komme ich auf die Idee die Stehleuchte lieber über einen WLAN Zwischenstecker zu schalten, meinetwegen, weil ich den knx Channel für andere Aufgaben brauche. Und da muss ich nun nur den Link entfernen und einen neuen Link definieren.

Erst mal scheint das belanglos, aber weil ich meine Stehleuchte in diversen Rules ansteuere, muss ich nun sonst gar nichts ändern, während jemand, der die Itemnamen an der Hardware ausrichtet, entweder damit leben muss, dass der Name nun nicht mehr passt, oder eben an allen Stellen entsprechende Änderungen vornehmen muss.

Das semantische Modell ist im Übrigen ausschließlich Item-bezogen und hat nichts mit den Channels zu tun. Es ist lediglich so, dass man das Modell über die Geräte anlegen kann, was bei bestimmten Geräten sinnvoll ist, in anderen Fällen aber nicht (z.B. bei dem 6-Kanal Schaltaktor von oben nicht sinnvoll, das als Gerät zu definieren, da auf dem Schaltaktor evtl. verschiedene Räume geschaltet werden.

Lieber udo1toni,

Herzlichen Dank für deine Superantwort.
Ich hatte da schon sowas im Verdacht, auch deine Ausführung darüber die Itemnamen an der (KNX) Hardware auszurichten kann ich mittlerweile zu mehr als 100% bestätigen - es ist wirklich Unsinn das so zu machen.
Das stammt bei mir zum Einen aus der KNX Schule und zum Anderen weil ich vor ca. 2 Jahren einfach mal im OH "drauflosgebastelt" habe.
Somit ist jetzt der Tag/Abend gekommen an dem ich wieder eine "Altlast" über Bord werfen kann. Einerseits wird die Geschichte dann verständlicher und der "Schaden" ist ziemlich gering, ich hab ein EFH und da ist die Anzahl der Aktoren/Channels usw. ziemlich überschaubar....

...ich melde mich wieder wenn mir die nächsten Fehler aus der Vergangenheit um die Ohren fliegen .

Bis dahin aber nochmals DANKE & schönen Abend

@udo1toni.

Ich verzweifle bei meinem Umstieg von OH2 zu OH3. Bei OH2 habe ich eine Sitemap und eine Items- Liste erstellt und damit konnte ich alles steuern. KNX, HUE, AVR, Kameras und so weiter. Nach einem Spannungsabfall seitens der Stadtwerke hat irgend was in meinem Pi den Geist aufgegeben. Da eine Neuinstallation nötig war, dachte ich: "...Mach gleich ein Update." Und jetzt habe ich den Salat.
Ich habe unter Anderem 4 16-fach Aktoren, einen 8-fach Aktor sowie Rollladenmotoren von Rademacher (X-Line), Gira Wetterstation.

Jetzt hänge ich an dem Punkt, dass das Gateway online ist, ich aber noch nicht genau verstanden habe, wie ich ein Thing erstelle um die jeweilige Funktion zu erzeugen. Kannst du hier helfen?

Vielen Dank im Voraus für deine Antwort.

Ja, sicher

Grundsätzlich kannst Du alle Dateien 1:1 aus dem openHAB2-System übernehmen.
Allerdings vermute ich, dass Du wahrscheinlich unter openHAB2 mit dem knx1 Binding gearbeitet hast. Das wäre daran erkennbar, dass die Links in der .items Datei so aussehen: Das knx2 (bzw. knx3) Binding arbeitet bekanntermaß0en komplett anders.
Um alles bequem umzustellen, brauchst Du drei Infomationsquellen:

1. Die Datei knx.cfg aus dem Ordner /etc/openhab2/services/ (alternativ könnte die nötige Information auch in openhab.cfg enthalten sein, dann als Block mit den Konfigurationsinformationen für knx).
2. Die .items Datei(en) welche die Itemkonfiguration der knx-Items enthält/enthalten.
3. Eine Liste aller knx Devices mit den physikalischen Adressen und der Zuordnung, welche GA zu welchen KO gehört.

Punkt 3 ist nicht überlebensnotwendig, aber sehr erstrebenswert.

Die Daten aus Punkt 1 brauchst Du, um die knx Bridge zu konfigurieren.
Die Daten aus Punkt 2 brauchst Du, um die Channel korrekt zu konfigurieren.
Die Daten aus Punkt 3 brauchst Du, um die Channel korrekt zu strukturieren.
Diese Struktur ist wie erwähnt nicht überlebensnotwendig, hilft aber ungemein, wenn Du in openHAB seltsame Fehler feststellst, die auf bestimmte GA begrenzt sind. Man kann den knx Bus als Ganzes als Thing darstellen, das bedeutet, Du hast eine Bridge für die Verbindung und darunter ein generic knx Thing, in dem sämtliche Channel zusammengefasst sind. Das ist beim Einrichten schön einfach, aber eben nicht strukturiert.
Wenn Du die Channel hingegen strukturiert anlegen willst, legst Du pro Device ein Thing an. Denke bei der Zuordnung der Channel immer daran, dass der "Besitzer" des Channels immer der Aktor oder der Sensor ist, nicht ein Wandtaster.
Die große Ausnahme dieser Regel sind Channel, zu denen es keine Sensoren oder Aktoren in knx gibt, also z.B. wenn ein Wandtaster einen Aktor eines anderen Bindings steuern soll (z.B. eine Hue Lampe). Nur dann legst Du den Channel im Taster Device an. Falls Du Binäreingänge verbaut hast, kannst Du diese bevorzugt als Taster betrachten es sei denn, es handelt sich um eine Sensor Funktion (z.B. Fensterkontakte).
Es gibt noch eine weitere Kategorie Channel, das sind solche, die nicht einem bestimmten Gerät zugeordnet werden können. Dazu gehören z.B. alle Szenensteuerungen, selbst wenn nur ein Gerät damit gesteuert wird, denn eine Szene hält keinen Status. Auch Uhrzeit und Datum, die von openHAB in Richtung des knx Busses gehen gehören in diese Kategorie, weil es mehrere Geräte in knx geben wird, die diese Daten empfangen.
In diesen Fällen ist am ehesten openHAB "Besitzer" des Status. openHAB hat keine physikalische Adresse, das heißt, Du legst dafür zusätzlich ein generic knx Thing an, welches nur diese Channel hält. Mutmaßlich werden diese Channel außerdem eine Besonderheit aufweisen, die Dir noch zu schaffen machen wird, wenn Du bisher mit knx1 unterwegs warst.

Es ist nämlich so, dass knx1 einen Designfehler aufwies, der mit knx2 behoben wurde. Dieser Designfehler (bzw. dessen Behebung) führt aber zu einem Breaking Change, dasheißt, knx2 verhält sich in bestimmten Details völlig anders als knx1, das betrifft die Trigger in den Rules.
knx1 hat immer sowohl ein update als auch ein received command getriggert, egal was auf dem knx Bus passierte.
knx2 sendet grundsätzlich immer ein update, wenn dadurch ein Status geändert wird gibt es auch ein changed Ereignis. Hingegen gibt es kein received command. Soll - z.B. um mit einem Wandtaster ein nicht-knx-Gerät zu steuern - dennoch eine GA als received command gewertet werden, so muss ein *-control Channel verwendet werden. Hier kehrt sich die Logik komplett um, d.h. es gibt nur ein received command, aber kein update.
Um das Ganze komplett zu machen reagiert ein normaler Channel nur auf commands (also wenn man mit sendCommand einen Befehl schickt), während ein *-control Channel ausschließlich auf postUpdate reagiert. Deshalb kann man solche Channel (passenden Channeltyp mal vorausgesetzt) direkt über ein Item mit einem anderen Channel verlinken. knx sendet dann das Kommando über das Item direkt an das zweite Binding, das Status Update des zweiten Bindings führt hingegen zu einem Status Update, welches von knx empfangen wird. Man kann also den knx Taster ohne Rule mit einer anderen Lampe verbinden.

Es gibt ansonsten für jeden Itemtyp einen passenden Channel (bzw. zwei, einmal normal, einmal control), also z.B. switch, dimmer, contact, rollershutter, number, string...

Die Konfiguration kannst Du über die Main UI vornehmen, aber genauso gut auch über eine Textdatei, in diesem Fall *.things im Ordner things/
Das sieht dann so aus: Was Du gut sehen kannst: Zuoberst wird die Bridge definiert (im Beispiel mit einem knx Tunnel Gateway) Die Parameter entsprechen den Standardeinstellungen und sollten nicht ohne triftigen Grund verändert werden. Insbesondere die localSourceAddr muss unbedingt eine freie physikalische Adresse sein, es darf kein Device geben, welches auf diese Adresse reagiert, auch nicht das Gateway, auch nicht als sekundäre Adresse.
Darunter werden dann die einzelnen Devices definiert, mit Angabe der echten physikalischen Adresse. Ist die physikalische Adresse gesetzt, kann man in openHAB jederzeit erkennen, ob es Probleme mit der Kommunikation gibt (indem das Thing als OFFLINE angezeigt wird; die zugeordneten Channel können dennoch weiterhin funktionieren).
Solltest Du ein Device nutzen, welches nicht von sich aus senden kann, sondern immer eine Sendeaufforderung braucht, so kannst Du für dieses Device mit readInterval dafür sorgen, dass der initiale Read Request (die GA mit < vorne dran) alle readInterval Sekunden erneut gesendet wird. Gewöhnlich sollte der Parameter aber auf 0 stehen. fetch ist eine nice-to-have Funktion und bringt keine Vorteile, kann aber zu Problemen führen wenn sie aktiviert ist, also besser auf false lassen.
Die Channel schließlich gehören zum jeweiligen Thing. Die zugehörigen Items zu den gezeigten Channels sehen dann so aus: autoupdate="false" bewirkt dabei, dass der Status aktiv nur vom knx Bus gesetzt wird.

Vielen Dank für deine sehr schnelle und sehr ausführliche Antwort udo1toni. Ich werde mir in der nächsten Woche dazu sehr viel Zeit nehmen und es ausprobieren. Selbstverständlich gibt es dazu dann noch ein Feedback. Vielen Dank.