OH3 Equipment und Points statt Groups und Items?

[Hoggle]

Hier wird mir aus dem Herzen gesprochen.
Als ich vor gut, boah, vielleicht 2 Jahren mit Openhab anfing, kam ich von Fhem, was mir einiges abverlangte, denn in den Dokus wurde wild von 1.x zu 2.x Beschreibungen hin und her gesprungen.
Dank dieses Forums habe ich mir über die Zeit aber schon einiges anlegen können.
Was aufgefallen ist, es wurde fast ausschließlich mit VSC in Textdateien konfiguriert, was natürlich das Copy/Paste vereinfachte.
Ein schönes, da einfaches Beispiel war/ist mein Garagentor.
Ich habe einen Motor, der über einen Taster angesteuert wird: drücken:Garagentor läuft in eine Richtung; wieder drücken: Tor bleibt stehen; Nochmal drücken: Tor läuft in die andere Richtung, usw.
Ich habe mir also einen Zwischenstecker für die Steckdose, in die der Motor eingesteckt ist von Homematic geholt (HM-LC-Sw1-Pl-CT-R1) und 2 Neigungssensor, ebenfalls von Homematic (HM-Sec-TiS), von denen ich einen oben und einen unten ans Tor geschraubt habe.
Dank Homematic-Binding Things über die UI angelegt und per Text-Datei die Items dazu.
Zusätzlich noch ein Dummy-Item in dem ich den Status der beiden Neigungssensoren per Rule abbilde(Beide ON=Tor geschlossen; beide OFF= Tor geöffnet; unterschiedliche Position bedeutet teilweise geöffnet)
Wenn ich den Schalter in Openhab anschalte dann wird er nach 2 Sekunden wieder ausgeschaltet, damit er immer auf OFF Steht:

Code: Alles auswählen

rule "Garagentorknopf"  //Item Garagentormotor
when
    	Item G_M_1STATE changed to ON 
then
createTimer(now.plusSeconds(2)) 
        [|
         G_M_1STATE.sendCommand(OFF)
        ]
    
end 

Soweit die Vorrede - Aber wie bekomme ich diese Rule in der UI von OH3 "zusammengeklickt"?
Ich Scheiter schon an der Timersteuerung.
Natürlich ist es simple, die Rules-Datei einfach in das Verzeichnis von OH3 zu kopieren, was auch funktioniert, aber richtig fühlt sich das nicht an, oder? - Natürlich, die Funktion (Schalter wird nach 2 Sekunden wieder auf OFF gestellt, klappt)
Dann das Thema mit dem Status:
Hier die Rule aus OH2:

Code: Alles auswählen

rule "Status Garagentor" when
    Item G_N_O_1STATE changed or //einer der Kontakte hat seinen Status geändert
    Item G_N_U_1STATE changed 
then
    if (G_N_O_1STATE.state == ON && G_N_U_1STATE.state == ON) //Beide Kontakte ON
        G_Garagentorstatus.postUpdate(100) //zu
    else if (G_N_O_1STATE.state == OFF && G_N_U_1STATE.state == OFF) //Beide Kontakte OFF
        G_Garagentorstatus.postUpdate(0) //offen
    else //Zwischenposition
        G_Garagentorstatus.postUpdate(50) //dazwischen
end

Okay, die 1. Hürde war, das ich die Items in OH3 beim anlegen so definiert hatte, das es nicht ON/OFF, sondern CLOSED, OPEN heisst, habe ich sofort gefunden, aber ich habe bei mir im Garagentorstatus jetzt 0, wenn beide Sensoren Closed sind 50 wenn Sie unterschiedlich und 100 wenn beide Sensoren OPEN sind.
Wie bekomme ich jetzt das Mapping (geöffnet/teilweise geöffnet/geschlossen) und die passenden Icons im OH3 hin?

Sorry, das dieser Post doch so lang wurde, aber wie soll man es kürzer formulieren, so das Ihr das nachvollziehen könnt.

Der Umstiegt von OH2 zu OH3 ist dann wohl doch nicht so trivial, oder liegt es an meinen 50 Jahren

Und um die oben stehenden Post noch einmal aufzunehmen:
Wie ist die Logik hinter OH3?
1. Es gibt ein Binding, die das Tor zu den Geräten aufmacht (Z.B. Homematic)
2. Es gibt die Things, die das Gerät definiert und die Kanäle darstellt
3. Ja was kommt jetzt? Items, die die Funktion, die durch den Kanal bereitstellt, definiert, oder ein Equipment, oder ein Point? Spätestens hier weiss ich nicht mehr so Recht weiter.

Wie ist der richtige Ansatz für die Definition UND, was ich noch wichtiger finde: also doch weiterhin besser per Text-Datei definieren, oder sofort per UI?

[Bubbleman]

Hallo
@Hoggle
an der Stelle stockt es bei mir gedanklich auch gerade.
Things, Bindings und Chanels habe ich verstanden, wenn ich auch lange noch nicht routiniert oder sicher im Umgng damit bin.
Wie dann aber Items, Points und Equipment damit und zueinander in Verbindung stehen...?
Items sind die virtuellen Entsprechungen von "Dingen" (ich schreibe bewusst nicht Things). Ein Item symbolisiert zB einen Schlater in OH.
Unter einem Point verstehe ich auf eine abstrakte Art eine Art "Ansatzpunkt" an einem Item. Eine Schnittstelle oder einen Datenpunkt. Besser kann ich es derzeit nicht verstehen oder erklären.
Das Equipment habe ich noch gar nicht wirklich verstanden. Bedeuten tut es ja "Ausstattung".
Ich habe unter "Modell" die Räume meines Hauses angelegt. Einem Raum kann man nun noch ein Equipment unterordnen. Das scheint dann zB eine "Funktsteckdose" zu representieren. Nur welche Rolle spielen jetzt Items und Point im Verhältnis zum Equipment...?
Die Doku erklärt da für mich nichts. Gemäß der Doku habe ich gedacht das "Endgerät" in Openhab, welches man dann über das GUI bedienen kann, wäre das Item.

Bin verwirrt.

Gruß
Thomas

[Hoggle]

Things, Bindings und Chanels habe ich verstanden, wenn ich auch lange noch nicht routiniert oder sicher im Umgng damit bin.
Wie dann aber Items, Points und Equipment damit und zueinander in Verbindung stehen...?
Items sind die virtuellen Entsprechungen von "Dingen" (ich schreibe bewusst nicht Things). Ein Item symbolisiert zB einen Schlater in OH.

Aus meinem Verständnis heraus sehe ich das auch so, wobei für mich ein Item und ein Equipment noch zusammen passen können. Also ein Switch, der den State einer Lampe von ON auf OFF und umgekehrt schaltet, kann als Equipment als Licht oder Schalter genannt werden, aber eigentlich kann das doch über Gruppen auch schon seit OH2 super zugeordnet werden. Mir erschließt sich einfach der Grund nicht, besonders, da es die Gruppen ja noch immer gibt.

Unter einem Point verstehe ich auf eine abstrakte Art eine Art "Ansatzpunkt" an einem Item. Eine Schnittstelle oder einen Datenpunkt. Besser kann ich es derzeit nicht verstehen oder erklären.

Hier setzt es dann bei mir komplett aus. Ist ein Point noch unterhalb des Items angeordnet?
Was beschreibt ein Point und was kann man damit machen?

Die Doku erklärt da für mich nichts. Gemäß der Doku habe ich gedacht das "Endgerät" in Openhab, welches man dann über das GUI bedienen kann, wäre das Item.

Wie gesagt, ich dachte auch, wenn man in einer Baumstruktur denken würde, dann würde ich nach oben das jeweilige Binding stellen, darunter alle Things des Bindings und unterhalb der Things die Items, die zusätzlich dann noch durch vergabe von unterschiedlichen Gruppen zusammengefasst werden können. Wo liegt nun der Vorteil von Equipments und wo finde ich die Points, geschweige denn, was ich damit machen kann.

In dem Zusammenhang noch eine weiterführende Frage zum symantischen Modell: Kann man die Auswahl der symantischen Classes irgendwo editieren? Ich würd nämlich gerne ergänzen oder umbenennen, denn z.B. weiß ich nicht, wo ich meine CCU2 einordnen soll, denn den Punkt "Bridge" gibt es ja nicht.

[Anbeku]

Ich glaube da werden verschiedene Ebenen durcheinandergeworfen. Equipment und Points sind Begriffe aus der semantischen Ebene. Equipments sind auf der technischen Ebene groups mit der class "Equipment" damit sind sie auch "Items" nach der klassischen Sichtweise. Points sind Items mit nur einem verlinkten Channel und der class "Point". eine Funktsteckdose wäre dann z.B. ein Equipment das Funktsteckdose heißt und mehrere Ponts hat z.B. einen Schalter und einen Messwert "Power"

[Hoggle]

Ich glaube da werden verschiedene Ebenen durcheinandergeworfen. Equipment und Points sind Begriffe aus der semantischen Ebene. Equipments sind auf der technischen Ebene groups mit der class "Equipment" damit sind sie auch "Things" nach der klassischen Sichtweise. Points sind Items mit nur einem verlinkten Channel und der class "Point". eine Funktsteckdose wäre dann z.B. ein Equipment das Funktsteckdose heißt und mehrere Points hat z.B. einen Schalter und einen Messwert "Power"

Aber dann muß meine Fragestellung anders sein: Meint ein Thing und ein Equipment und eine Item und ein Point das selbe?
Wo liegen die Vorteile? Wieso wird das seperat betrachtet? Ist das nicht "doppelt gemoppelt"?
Und hat ein Item nicht auch nur 1 Channel?

[violine21]

Der Umstiegt von OH2 zu OH3 ist dann wohl doch nicht so trivial, oder liegt es an meinen 50 Jahren

Hallo,
also am Alter liegt es sicher nicht
Es ist tatsächlich vieles erst mal neu und ich bin gerade auch dabei, die einzelnen Dinge zu verstehen.

Was ich wohl bis jetzt verstanden habe, der Weg geht mehr und mehr in Richtung UI's.
Habe mir im englischen Forum einige Beiträge mühsam übersetzt und verstanden, das es für viele Neueinsteiger einfacher ist,
sich die Dinge zusammen zu klicken. Textbasierte Programmierung wird wohl von den langjährigen Nutzern bevorzugt und von
den erfahrenen Programmierern. Immer wieder fallen die Argumente wie Copy & Paste und Massenbearbeitung.
Beteuert wird immer wieder, das die textorientierte Programmierung weiterhin Bestandteil ist.

Ich habe mich dann mal dran gemacht und ein System aufgesetzt. Habe das Shelly-Binding installiert und ein Thing und die entsprechenden
Items über die UI angelegt bzw. anlegen lassen. Der Weg ist einfach kinderleicht, alles geht fast von selbst, die Fehlerquote sinkt rapide.
Das ist wohl ein Hauptargument der UI-Befürworter.
Beim Anlegen einer Rule bin ich dann ganz schnell an die Grenzen gestossen. Da hat man kaum Spielraum.

Aus meiner Sicht wird es das "zweigeteilte" System aus Text und UI noch weiterhin geben. Auf der einen Seite hat man die vielen
"altgedienten" User, die die Textprogrammierung verinnerlicht haben, andererseits gilt es auch neue User zu begeistern. Heute
läuft fast alles nur noch über Zusammenklicken.

Kurzum, ich habe für mich die Entscheidung getroffen, so weiter zu machen wie bisher. Things lege ich so weit es geht über die UI an
und ab Item-Ebene mache ich dann textbasiert weiter (VSC). In wie weit ich damit die neuen Features wie Model, Equipment und Points
nutzen kann, werde ich sehen. Auf alle Fälle wird mein Produktivsystem vorerst auf Version 2.9.10 weiter betrieben.
Es braucht sicher noch etwas Zeit, bis die ersten ToDo-Videos auf Youtube zu OH3 (in deutsch) erscheinen.

Soweit meine Erkenntnisse mit 56 Jahren

[Anbeku]

Aber dann muß meine Fragestellung anders sein: Meint ein Thing und ein Equipment und eine Item und ein Point das selbe?
Wo liegen die Vorteile? Wieso wird das seperat betrachtet? Ist das nicht "doppelt gemoppelt"?
Und hat ein Item nicht auch nur 1 Channel?

Ich habe mich verschrieben und meine immer Items und nicht Things. Also ein Equipment ist ein Item, aber umgekehrt gilt das nicht immer. Genau so ist es mit Points.

[Anbeku]

Ich habe mich dann mal dran gemacht und ein System aufgesetzt. Habe das Shelly-Binding installiert und ein Thing und die entsprechenden
Items über die UI angelegt bzw. anlegen lassen. Der Weg ist einfach kinderleicht, alles geht fast von selbst, die Fehlerquote sinkt rapide.
Das ist wohl ein Hauptargument der UI-Befürworter.
Beim Anlegen einer Rule bin ich dann ganz schnell an die Grenzen gestossen. Da hat man kaum Spielraum.

wäre ja auch ok, wenn man das mischen könnte, also z.B. nur die Rules als text schreiben könnte. Leider ist es offensichtlich nicht so, dass die UI nur ein Frontend für die Textdateien ist, sondern das ist alles parallel.

[violine21]

Leider ist es offensichtlich nicht so, dass die UI nur ein Frontend für die Textdateien ist, sondern das ist alles parallel.

Ja. Es ist wohl alles parallel.
Du kannst die in VSC geschriebene Rule in der UI anschauen aber nicht bearbeiten. Sie ist mit einem Schloss-Symbol gekennzeichnet.
Bei den Items auch.

Hier ist ein Video, was für den Anfang schon mal einiges erklärt:
https://www.youtube.com/watch?v=VEagSEx7e4o&t=0s

[violine21]

Ein wenig erinnert mich der Aufbau an Homematic. Da hat man auch Geräte, Kanäle, Gewerke und Räume.
Dadurch kommt Struktur in das System. In der Darstellung kann man dann unter den zugeordneten Kategorien wählen
und hat so eine gute Übersicht.
Wenn man dann das System in VSC betrachtet, findet sich diese Struktur genau so wieder.
Leider geht es wohl umgekehrt, also von der textbasierten Programmierung nicht.