openhabforum.de

Hallo zusammen.
Mal eine Frage an die strukturierten Menschen unter euch (Ich bin das leider nicht, aber das Genie beherrscht schließlich das Chaos ):
Ich habe bei mir im Wohn- Esszimmer (Ist nicht mit Wänden oder so abgetrennt) einen HM-IP 6-Fach-Wandsender, den ich allerdings auf dem Couchtisch als Handsender nutze.
Im Esszimmerbereich habe ich eine Stehlampe mit einem HMIP-PSM Zwischenstecker, eine Deckenlampe, mit einem Schalter HmIP-BSL.
Im Wohnzimmerbereich habe ich eine Schrankbeleuchtung mit einem Zwischenstecker HMIP-PSM und eine Stehlampe mit einer schaltbaren Steckdose, die mit einem Schalter HmIP-BSL geschaltet wird.
In der Homematic-UI habe ich die 4 Geräte mit 4 der 6 Kanäle des "Handsenders" direkt verknüpft und zusätzlich noch eine Küchenlampe mit einem 5. Kanal (Falls ich mal wieder vergessen habe, das Küchenlicht auszuschalten und schon auf dem Sofa liege ).
So weit, so schick.
Jetzt habe ich aber einige Probleme mit meinem OH und möchte, da momentan Urlaub, das System von Grund auf neu aufsetzen und Frage mich, wie man die einzelnen Geräte bezeichnen sollte.
Klar, die Schaltaktoren und Zwischenstecker benenne ich nach der Funktion, also z. B. Die Deckenlampe im Esszimmer: EZ_Licht, gefolgt mit dem jeweiligen Channel, also EZ_Licht:1. EZ_Licht:2 , oder den Zwischenstecker der Wohnzimmerstehlampe: WZ_Stehlampe-
Aber bei dem Handsender bin ich mir nicht im klaren, wie ich die einzelnen Schaltkanäle benennen sollte.
Channel 1 ist die EZ_Stehlampe. Sollte ich den "EZ_Stehlampe_Schalter" benennen, oder so, wie der Wandsender heißt, gefolgt mit dem Channel, also "WZ_6_Fach:1"?

Meine Frage ist also, ob ihr eine Struktur in euren Bezeichnungen habt, die ihr mir mal zeigen könntet?

Die Frage hört sich für jemanden mit einem guten Strukturverständnis komisch an, aber vielleicht hilft mir ja jemand, etwas Struktur in den Dschungel zu bringen.

Wenn dann noch jemand seine Modell-Struktur darstellen könnte, dann wäre ich noch glücklicher.

Ja, ein allgemeines Problem

Meine zwei Eurocent dazu:
In openHAB gibt es mehrere Abstraktionsebenen. Außerdem ist noch zu bemerken, dass Items sozusagen Teile des openHAB Busses sind. Ein Item steht immer für einen einzelnen Wert auf dem Bus bzw. für die Möglichkeit, einen Befehl zu schicken.
Items sind nicht hardwareabhängig - in dem Sinne, dass es völlig egal ist, ob ich z.B. ein Homematic Relais, ein Sonoff Relais oder auch ein knx Relais schalte, es handelt sich immer um ein Switch Item.
Items sind aber gewöhnlich ortsbezogen - natürlich gibt es den Fall, dass z.B. ein Zwischenstecker mal hier mal dort zum Einsatz kommt, aber das Gros sollten ja fixe Installationen sein.
Im Unterschied dazu sind Channel und die Things immer hardwarebezogen - schließlich bilden sie die Schnittstelle zur Hardware.

Weiter: openHAB ist normalerweise die Zentrale, welche Steuerbefehle erteilt. Man wird also vorzugsweise Aktoren verbinden, nicht Schalter. Nur wenn man von einem Bussystem aus Aktoren eines anderen Systems steuern möchte, muss ein Schalter verknüpft werden.
Wenn Du also Deine 6-Kanal Fernbedienung nutzt, sollte das komplett an openHAB vorbei gehen und nur in homematic stattfinden, es sei denn, Du möchtest z.B. über eine der Tasten, sagen wir mal, den Fernseher stumm schalten, dann müsste diese eine Taste in openHAB als Channel angelegt sein.

Things sind als virtuelles Abbild der Hardware gedacht. Hast Du also drei Zwischenstecker, so sind das drei Things. Jeder der Zwischenstecker bietet dann nur einen Schaltkanal, aber es sind drei Geräte.

Ein Thing hat eine UID, da nutze ich gerne eine möglichst kurze Bezeichnung der Hardware selbst, falls ich mehrere baugleiche Geräte habe gefolgt von einem Unterstrich und einer fortlaufenden Zahl, z.B. habe ich hier diverse WLAN Zwischenstecker, die alle mit Tasmota geflasht sind, und zwar solche mit dem Branding von Nous und solche mit dem Branding von Gosund. Entsprechend heißen die Teile bei mir also nous_1, nous_2, nous_3 ... gosund_3, gosund_4. Die Things haben auch ein Label, da schreibe ich gerne eine konkrete Funktion rein, z.B. "Fernseher Kind 1".
Die Channel solcher Geräte sind alle identisch zu den jeweils baugleichen Geräten, also z.B. schalten, power, und das Label der jeweiligen Channel kann auch jeweils gleich sein, beim Listen der Channel weiß man ja immer, zu welchem Gerät der Channel gehört.
Der Bezug zum Item sieht dann z.B. so aus: mqtt:topic:broker:nous_1:schalten und damit ist alles Notwendige geklärt. Mir ist vor allem wichtig, die UIDs klar und kurz zu halten, es mag bedeuten, dass sich nicht an jeder beliebigen Stelle die vollständige Information über Ort und Verwendungszweck habe, aber das brauche ich auch nicht, ich kann es ja jederzeit an anderer Stelle nachschauen.

Die passenden Items dazu sind dann wie oben erwähnt ortsbezogen, da ich hier verschiedene Gebäude abdecke sieht das bei mir so aus: NEG_Wohn_Stehleuchte -> Das ist ein Switch Item, um die Stehleuchte im Wohnzimmer im Erdgeschoss des Neubaus zu schalten. Das ist genauso gut wie Neubau_Erdgeschoss_Wohn_und_Esszimmer_Wohnzimmerbereich_hinter_der_Couch_Stehleuchte_Schalter, aber sehr viel kürzer Man denke immer daran, dass man Itemnamen vielleicht auch in Rules verwenden und dort hinschreiben will.

Schalter oder Status oder so was hat im Itemnamen nichts zu suchen, das ist Müll. Die Ausnahme davon wäre lediglich, wenn man Items hat, die Bezug zueinander haben und eine gerichtete Kommunikation erzwingen, also z.B. ein Item um einen Schaltvorgang zu befehlen, ein anderes um die Rückmeldung zu erhalten. Gewöhnlich sollte das aber immer über ein Item abgebildet werden, nicht über zwei.
Ich habe hier Raumthermostate, deren Betriebsart ich steuern kann. Die Steuerung erfolgt über einen Wert 1-4, die Rückmeldung erfolgt aber mit 2^(1 - 4) (also als Bitmuster). Das hängt damit zusammen, dass noch weitere Zustände über das selbe Register rückgemeldet werden, z.B. ob geheizt oder gekühlt wird). Hier bleibt mir nichts anderes übrig, als die Rückmeldung in einem separaten Item abzubilden. Allerdings habe ich eine passende Rule, welche mir das jeweilige Steueritem automatisch passend setzt...

Die Items sind dann auch im Semantic Model passend gruppiert und getaggt, so dass die Wohnzimmer Stehleuchte im Wohnzimmer als Licht angezeigt wird.

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 Ja, ein allgemeines Problem

Meine zwei Eurocent dazu:

Wie immer ist dein Post mehr als die 2 Cent wert . Danke für die ausführliche, wenn auch nicht immer für mich verständliche Antwort .

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 In openHAB gibt es mehrere Abstraktionsebenen. Außerdem ist noch zu bemerken, dass Items sozusagen Teile des openHAB Busses sind. Ein Item steht immer für einen einzelnen Wert auf dem Bus bzw. für die Möglichkeit, einen Befehl zu schicken.
Items sind nicht hardwareabhängig - in dem Sinne, dass es völlig egal ist, ob ich z.B. ein Homematic Relais, ein Sonoff Relais oder auch ein knx Relais schalte, es handelt sich immer um ein Switch Item.
Items sind aber gewöhnlich ortsbezogen - natürlich gibt es den Fall, dass z.B. ein Zwischenstecker mal hier mal dort zum Einsatz kommt, aber das Gros sollten ja fixe Installationen sein.
Im Unterschied dazu sind Channel und die Things immer hardwarebezogen - schließlich bilden sie die Schnittstelle zur Hardware.

Okay, ich bin noch einen Schritt vor Openhab, aber das Problem ist erst einmal das selbe.
Ich bin im Moment dabei die Geräte von Homematic in der Zentrale ein wenig zu sortieren (Ich weiß, das du kein Homematic hast, aber es geht ja um eine grundsätzliche Namensvergabe).
In der WebUI der HM-Zentrale werden die einzelnen Geräte mit einem Namen benannt, also zum Beispiel der Schalter der Esszimmer-Deckenlampe, der sich an der Küchentür befindet mit der Bezeichnung "EZ_Lampe_K"(Ich habe 3 Schaltstellen für die Deckenlampe - früher hieß das wohl Kreuzschaltung , aber ich habe das mit 3 Schaltaktoren realisiert, die direkt miteinander verknüpft sind)
Jetzt wo ich das schreibe, frage ich mich, ob der Zusatz "_K" überhaupt notwendig ist, denn in OH will ich die Esszimmerlampe An- und Ausschalten, entweder über ein Tablet oder Progammgesteuert, aber muss ich alle 3 Schalter im OH darstellen? (Wie gesagt, in meinem Kopf ist häufig ein wenig "Kabelgewirr" )
Aber zurück: Jedes Gerät hat in der Zentrale dann die einzelnen Kanäle, die für das Geräte vorhanden sind Der Küchentürschalter hat noch 2 beleuchtete Bereiche, die man separat ansprechen kann, somit sind es insgesamt 14 Kanäle.
Bezeichne ich die nach der Funktion, ohne eine Beziehung zum Gerätenamen? Am Ende werden das doch meine Items in OH und dementsprechend sollte die Bezeichnung doch etwas mit der Funktion des Channels am Gerät zu tun haben, oder?

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 Weiter: openHAB ist normalerweise die Zentrale, welche Steuerbefehle erteilt. Man wird also vorzugsweise Aktoren verbinden, nicht Schalter. Nur wenn man von einem Bussystem aus Aktoren eines anderen Systems steuern möchte, muss ein Schalter verknüpft werden.

Das ist wohl eines meiner Probleme. Ich schaue im Esszimmer auf den Schalter in der Wand und wenn ich den Schalter oben drücke, dann geht mir die Lampe an , also das Licht leuchtet und unten gedrückt, geht das Licht aus.
Wenn ich den Schalter aber aus der Homematic Sicht betrachte, dann habe ich eigentlich 5 Geräte: 1 Aktor, der An und Aus kennt, 2 Schalter, die durch eine direkte Verknüpfung den Aktor steuern und 2 Lampen, die verschiedene Farben in unterschiedlicher Stärke annehmen können und per WEB-UI oder durch Programme gesteuert werden können.
Das heißt doch, das ich in OH den Aktor als Item anlege, je Lampe im Schalter einen Dimmer, einen Switch und eine Farbauswahl. Wie soll ich die dann aber benennen? - Weiter unten schreibst du, das die Bezeichnung Status, oder Schalter nichts im Namen zu suchen haben, aber was dann? - "EZ_Licht" für den Schaltaktor, "EZ_Licht_LED_Dim_oben" und "EZ_Licht_LED_Dim_unten" für die Dimmer und wie würde man dann den Schalter für die Lampe im Schalter benennen? - "EZ_Licht_LED_Schalter_oben"
Das Prinzip scheint mir einfach nicht klar.

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 Wenn Du also Deine 6-Kanal Fernbedienung nutzt, sollte das komplett an openHAB vorbei gehen und nur in homematic stattfinden, es sei denn, Du möchtest z.B. über eine der Tasten, sagen wir mal, den Fernseher stumm schalten, dann müsste diese eine Taste in openHAB als Channel angelegt sein.

Du würdest den 6-Fach Schalter also garnicht in OH anlegen als Thing und Items? - Anlegen müsste ich den dann nur, wenn ich z. B. einen Z-Wave-Zwischenstecker mit einer Taste schalten wollte, damit ich das per Rule realisieren könnte?

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 Things sind als virtuelles Abbild der Hardware gedacht. Hast Du also drei Zwischenstecker, so sind das drei Things. Jeder der Zwischenstecker bietet dann nur einen Schaltkanal, aber es sind drei Geräte.

Wenn per Rule auf einen Schaltvorgang reagiert werden soll, dann wird der Zwischenstecker abgefragt und nicht der Status des Schalter?!?

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 Ein Thing hat eine UID, da nutze ich gerne eine möglichst kurze Bezeichnung der Hardware selbst, falls ich mehrere baugleiche Geräte habe gefolgt von einem Unterstrich und einer fortlaufenden Zahl, z.B. habe ich hier diverse WLAN Zwischenstecker, die alle mit Tasmota geflasht sind, und zwar solche mit dem Branding von Nous und solche mit dem Branding von Gosund. Entsprechend heißen die Teile bei mir also nous_1, nous_2, nous_3 ... gosund_3, gosund_4. Die Things haben auch ein Label, da schreibe ich gerne eine konkrete Funktion rein, z.B. "Fernseher Kind 1".
Die Channel solcher Geräte sind alle identisch zu den jeweils baugleichen Geräten, also z.B. schalten, power, und das Label der jeweiligen Channel kann auch jeweils gleich sein, beim Listen der Channel weiß man ja immer, zu welchem Gerät der Channel gehört.
Der Bezug zum Item sieht dann z.B. so aus: mqtt:topic:broker:nous_1:schalten und damit ist alles Notwendige geklärt. Mir ist vor allem wichtig, die UIDs klar und kurz zu halten, es mag bedeuten, dass sich nicht an jeder beliebigen Stelle die vollständige Information über Ort und Verwendungszweck habe, aber das brauche ich auch nicht, ich kann es ja jederzeit an anderer Stelle nachschauen.

Die letzten 2 Abschnitte verstehe ich leider nicht. Wenn ich die Labels der einzelnen Items nicht genauer bezeichne, also das Label "State" bei allen Things nicht mit einer genaueren Gerätebezeichnung ergänze, also z. B.: "EZ_Licht_State", dann stehen in der Items-Übersicht nachher 50, oder mehr Items mit der Bezeichnung "State". Ist das so gewollt?

udo1toni hat geschrieben: ↑21. Jul 2023 12:12 Die passenden Items dazu sind dann wie oben erwähnt ortsbezogen, da ich hier verschiedene Gebäude abdecke sieht das bei mir so aus: NEG_Wohn_Stehleuchte -> Das ist ein Switch Item, um die Stehleuchte im Wohnzimmer im Erdgeschoss des Neubaus zu schalten. Das ist genauso gut wie Neubau_Erdgeschoss_Wohn_und_Esszimmer_Wohnzimmerbereich_hinter_der_Couch_Stehleuchte_Schalter, aber sehr viel kürzer Man denke immer daran, dass man Itemnamen vielleicht auch in Rules verwenden und dort hinschreiben will.

Schalter oder Status oder so was hat im Itemnamen nichts zu suchen, das ist Müll. Die Ausnahme davon wäre lediglich, wenn man Items hat, die Bezug zueinander haben und eine gerichtete Kommunikation erzwingen, also z.B. ein Item um einen Schaltvorgang zu befehlen, ein anderes um die Rückmeldung zu erhalten. Gewöhnlich sollte das aber immer über ein Item abgebildet werden, nicht über zwei.
Ich habe hier Raumthermostate, deren Betriebsart ich steuern kann. Die Steuerung erfolgt über einen Wert 1-4, die Rückmeldung erfolgt aber mit 2^(1 - 4) (also als Bitmuster). Das hängt damit zusammen, dass noch weitere Zustände über das selbe Register rückgemeldet werden, z.B. ob geheizt oder gekühlt wird). Hier bleibt mir nichts anderes übrig, als die Rückmeldung in einem separaten Item abzubilden. Allerdings habe ich eine passende Rule, welche mir das jeweilige Steueritem automatisch passend setzt...

Die Items sind dann auch im Semantic Model passend gruppiert und getaggt, so dass die Wohnzimmer Stehleuchte im Wohnzimmer als Licht angezeigt wird.

Ich muß mich wirklich mal hinsetzen und überlegen, was überhaupt alles in OH rein muß. Z. B. die 3 Schalter, die die Esszimmerlampe schalten und direkt in der HM-Zentrale verknüpft sind, sind doch eigentlich nicht wichtig, ausser ich möchte statistisch erfassen, welcher Schalter am meisten gedrückt wird (Was natürlich äusserst wichtig für mein Leben ist )

Also, früher... hat man entweder einen Schalter gehabt (Ich nenne es mal Normalschaltung), oder zwei (Wechselschaltung) oder mehr als zwei (Kreuzschaltung). Die Bezeichnung rührt von der Art der Verschaltung. Bei der Wechselschaltung wird der "mittlere" Schalter einer Kreuzschaltung durch zwei Drähte ersetzt
Ich verlinke hier mal in die Wikipedia: https://de.wikipedia.org/wiki/Kreuzschaltung und insbesondere auf das dort verwendete Schaubild mit allen möglichen Zuständen, das ist wirklich schön und anschaulich. Man kann bei der Kreuzschaltung "beliebig" viele Kreuzschalter zusätzlich einbauen, die Enden der Schalterkette sind aber immer Wechselschalter. "beliebig" stimmt natürlich nicht, da jeder Schalter einen Innenwiderstand hat, deshalb wird man ab einer bestimmten Anzahl eher zu einem Stromstoßrelais greifen.

Die Kreuzschaltung ist aber auch so eher ungewöhnlich, meist verbaut man stattdessen direkt ein Stromstoßrelais, welches also zwei stabile Schaltstellungen besitzt, zwischen denen jeweils per Stromstoß hin- und hergeschaltet wird.

Was Du über Homematic realisiert hast, ist also hoffentlich(!) keine Kreuzschaltung (an jeder Schaltstelle ein Aktor), sondern eben die indirekte Steuerung eines Stromkreises durch mehrere Taster (nicht Schalter). In dem Moment, wo Du eine der beteiligten Tasten drückst, wird das Relais umgeschaltet. Wobei Du mutmaßlich Tasterpaare hast, die übereinander angeordnet sind. Dabei sind die Taster so konfiguriert, dass der obere Taster immer ON sendet, während der untere Taster immer OFF sendet. Kann man so machen, ist halt Platzverschwendung.

Wie dem auch sei, es ist ja nun egal von welcher Stelle aus Du das Licht schaltest, also ist es auch uninteressant, welcher der Schalter betätigt wurde.
openHAB will keinem Schalter befehlen, sondern einem Aktor.
openHAB will nicht die Schaltstellung eines Wandtasters sehen, sondern den Schaltzustand des Aktors.

Hoggle hat geschrieben: ↑21. Jul 2023 14:50 Wenn per Rule auf einen Schaltvorgang reagiert werden soll, dann wird der Zwischenstecker abgefragt und nicht der Status des Schalter?!?

Genau!
Wobei "abgefragt" ja nicht mal stimmt. Du befiehlst über Homematic Licht ON -> Der Aktor schaltet das Licht ein -> der Aktor meldet den Zustand "Licht ON" -> openHAB empfängt die Statusmeldung und sendet sie an das passende Item.
Umgekehrt: openHAB sendet den Befehl OFF -> der Channel sendet den Befehl OFF an den Aktor -> der Aktor schaltet das Licht OFF -> der Aktor meldet "Licht OFF" -> openHAB empfängt die Statusmeldung und sendet sie an das Item.
So (und keinesfalls anders) wird das konfiguriert.
Schalter interessieren nicht. Es sei denn, man möchte mit dem Homematic Taster ZWave steuern, dann natürlich...
Vergiss also in openHAB die Schalter, so Du sie nicht für spezielle Funktionen brauchst.

In Homematic wirst Du aber jedem Schalter einen eigenen Namen geben wollen, damit Du im Falle eines Falles immer eine eindeutige Zuordnung hast - kann ja sein, dass Du mal einen Schalter austauschen musst, oder eine andere Funktion programmieren willst (das ist der Witz an Bussystemen, dass man recht einfach weitreichende Änderungen vornehmen kann). Wie Du die Schalter benennst, ist aber egal, das sind Homematic-interne Namen, in openHAB interessieren Dich nur die Aktoren (es sei denn ZWave...) und dort auch nur die Funktionen, die Du wirklich abbilden willst. Ich meine mich an HEX-Werte zu erinnern (also [0-9A-F], nicht Klartext Namen aus der Homematic Oberfläche, aber vielleicht liege ich da auch falsch

Denke daran, in openHAB gibt es ein Item pro Kanal. Schaltaktor -> Switch Item. Das heißt so, weil da etwas geschaltet wird, nicht, weil es ein Schalter wäre. Dimmer -> Dimmer Item. Eines, nicht mehrere. Ein Dimmer Item kann mit den Befehlen ON/OFF ein- und ausgeschaltet werden, mit INCREASE/DECREASE kann man das Licht heller/dunkler stellen (relatives Dimmen) und mit den Zahlen 0 - 100 kann direkt eine exakte Helligkeit ausgewählt werden. Je nach Konfiguration des Dimmers wird diese Helligkeit dann unmittelbar angesteuert oder über eine Ramp-Zeit weich angesteuert. Der Dimm-Aktor meldet im Gegenzug die aktuelle Helligkeit an openHAB, welche openHAB dann auch darstellt.

Hoggle hat geschrieben: ↑21. Jul 2023 14:50 Die letzten 2 Abschnitte verstehe ich leider nicht. Wenn ich die Labels der einzelnen Items nicht genauer bezeichne, also das Label "State" bei allen Things nicht mit einer genaueren Gerätebezeichnung ergänze, also z. B.: "EZ_Licht_State", dann stehen in der Items-Übersicht nachher 50, oder mehr Items mit der Bezeichnung "State". Ist das so gewollt?

Mööp, Achtung! Bitte nicht Channel und Item miteinander vermischen! Die Label der Channel sind jeweils gleich (natürlich kannst Du da auch einen Bezug zur echten Senke herstellen, also z.B. "Küchenlicht Schalten", aber wenn es sich um ein 1-Kanal-Thing handelt, ist das unnötig, denn "Küchenlicht" steht schon im Thing Label, es ist also hinreichend im Channel "Schalten" zu schreiben, um eindeutig zuordnen zu können, was da passiert.
Das Itemlabel hat nicht zwingend etwas mit dem Channel Label zu tun, es ist nur so, dass openHAB beim automatischen Generieren von Items automatisch die Label von Thing und Channel verwendet, um daraus Itemnamen zu bilden und deren Label zu befüllen. Was im Itemlabel steht, ist aber komplett egal, da kannst Du alles rein schreiben, auch "Konstantinopel" oder "Hugendubel", Du musst nur wissen, dass Konstantinopel in Wirklichkeit das Item ist, welches die Saturnrakete startet, während "Hugendubel" das Internet der gesamten amerikanischen Westküste abstürzen lässt.

Hoggle hat geschrieben: ↑21. Jul 2023 14:50 Ich muß mich wirklich mal hinsetzen und überlegen, was überhaupt alles in OH rein muß. Z. B. die 3 Schalter, die die Esszimmerlampe schalten und direkt in der HM-Zentrale verknüpft sind, sind doch eigentlich nicht wichtig, ausser ich möchte statistisch erfassen, welcher Schalter am meisten gedrückt wird (Was natürlich äusserst wichtig für mein Leben ist )

Eben. Es sollte gewöhnlich keine Rolle spielen, welcher Taster gedrückt wurde - in knx z.B. steht diese Information gewöhnlich gar nicht zur Verfügung, es sei denn, man parametriert das entsprechend. Aber wozu?