Seite 1 von 2

OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 14:41
von Anbeku
Ich habe ein paar Homatic Drehriffsensoren mit dem bekannten "Problem", dass diese die drei Zustände als String liefert, während Homatic als nativen Zustand mit semantic für Fenster nur den binären OpenClosedType und eigene Enums, kann ma offenbar auch nicht definieren. Jetzt würde ich als Lösung gerne die Strings des Drehriffsensores auf ein Contact Item mappen? Muss ich da wirklich für jeden Sensor einen eigenes Proxy-Item anlegen und dann für jeden Zustand eine Rule schreiben, oder geht das auch irgendwie einmal für alle gleichartigen Items? So etwas wie Templates oder Klassen gibt es bei OH nicht oder?

Abschließend möchte ich noch sagen, dass ich mir aus diesem Grund wohl keine Drehriffsensoren mehr kaufe. Die sind in der theorie attraktiv, aber machen in der Praxis nur unnötige Arbeit. Mit normalen optischen Kontakten fahre ich da bisher besser.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 16:14
von udo1toni
Das sollte eigentlich ganz einfach sein.

Ich habe das zwar unter OH3 noch nicht ausprobiert, sollte aber ähnlich wie in OH2 (und auch schon OH1) funktionieren.
Punkt 1: Es gibt ein Window Icon mit drei definierten Zuständen, nämlich open, closed und ajar. Damit man dieses Icon verwenden kann, muss ein String Item verwendet werden, denn Contact hat nur OPEN oder CLOSED (oder NULL) als Zustand, ja, leider...

Was kommt nun von homematic? Falls String mit OPEN, CLOSED und AJAR, brauchst Du gar nichts weiter zu tun, als lediglich das entsprechende Icon auszuwählen.

Kommen von homematic aber zwei binäre Informationen (z.B. 0/1 für closed/open und 0/1 für closed/ajar), dann bedarf es einer Rule. Du legst Die Kontakte und die zugehörigen String Items dann in Gruppen an, am besten drei Gruppen für die drei "Sorten" Items. Alle Items, die zueinander gehören (also je drei für ein Fenster) müssen einen identischen Namensteil haben, damit die Zuordnung klar ist. Dieser identische Namensteil muss für alle Item an der gleihcen Stelle sein, also z.B. der erste Teil des Itemnamens. Weiterhin muss sich dieser Namensteil für alle Fenster unterscheiden, so dass der Namensteil eindeutig für jedes Fenster ist. Ein weiterer Namensteil sollte dann pro Gruppe gleich sein. Also zum Beispiel:

Fenster01_String, Fenster01_Open, Fenster01_Ajar. (Die weiteren Items heißen dann z.B. Fenster02_... oder auch Wohnzimmerfenster5_... oder KiziF_... oder wie auch immer, der Punkt ist der Unterstrich mit einem weiteren Namensteil und dass der 1. Teil des Namens eindeutig ist.

Die Items kommen nun jeweils in eine Gruppe, z.B. heißen die Gruppen gWinOpen, gWinAjar und gWinString. Für jedes Fenster liegt also in jeder der Gruppen exakt ein Item (entsprechend der Funktion der Gruppe).

Nun legst Du eine Rule an:

Code: Alles auswählen

Rule "Fensterzustand von Contact nach String"
when
    Member of gWinOpen changed or
    Member of gWinAjar changed
then
    val strName = triggeringItem.name.split("_").get(0) // welches Fenster betrifft die Änderung
    var strState = "CLOSED"
    if(gWinOpen.members.filter[i|i.name.startsWith(strName)].head.state == OPEN)
        strState = "OPEN"
    else if(gWinAjar.members.filter[i|i.name.startsWith(strName)].head.state == OPEN)
        strState = "AJAR"
    if(gWinString.members.filter[i|i.name.startsWith(strName)].head.state.toString != strState)
        gWinString.members.filter[i|i.name.startsWith(strName)].head.postUpdate(strState)
end
Diese Rule reicht für alle Fenster, egal wie viele das sind. Sollten Fenster nur einen Kontakt haben, kann man die Rule leicht abwandeln, so dass vor der Wertabfrage zunächst geprüft wird, ob der Kontakt überhaupt vorhanden ist.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 16:49
von violine21
Was kommt nun von homematic? Falls String mit OPEN, CLOSED und AJAR, brauchst Du gar nichts weiter zu tun, als lediglich das entsprechende Icon auszuwählen.
So kommt die Info von Homematic:
Drehgriffsensor.gif

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 17:12
von Anbeku
Im Prinzip ist es so, dass ich drei String-Zustände habe: "Window status: locked", "Window status: open" und "Window status: tilted", Das was violine21 geschrieben hat gilt nur für die Homatic-Seite, Homatic kennt nämlich Enums mit diversen Werten, Openhab aber nur wenige vordefinierte. Ich kann also irgendwo, für diese drei Zustände Icons auswählen. Ich weiß aber nicht wo. Ind er hilfe steht es auch nicht Die Textdefinition gibt es da ja nicht. Eventuell irgendwo in der Statedescription, aber muss ich mal ausprobieren.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 17:16
von Anbeku
Ich habe allerdings das Problem, wenn ich mal Regeln schreiben möchte, die z.B. vor offenen Fenstern warnen, dann muss ich trotzdem wieder irgendwie Fenster mit Text status und mit Contact zusammenbringen.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 17:29
von Anbeku
Ne, ich bekomme das nicht hin mit den Icons. Über die Metadaten kann ich zwar das jeweilige Default-Widged aus und diese haben auch eine Einstallellung für das zugehörige Item, aber da kann man nur den namen auswählen und kein mapping auf zustände.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 17:57
von violine21
Anbeku hat geschrieben: 14. Feb 2021 17:12 Im Prinzip ist es so, dass ich drei String-Zustände habe: "Window status: locked", "Window status: open" und "Window status: tilted", Das was violine21 geschrieben hat gilt nur für die Homatic-Seite, Homatic kennt nämlich Enums mit diversen Werten, Openhab aber nur wenige vordefinierte. Ich kann also irgendwo, für diese drei Zustände Icons auswählen. Ich weiß aber nicht wo. Ind er hilfe steht es auch nicht Die Textdefinition gibt es da ja nicht. Eventuell irgendwo in der Statedescription, aber muss ich mal ausprobieren.
Leider habe ich Homematic noch nicht in OH3 integriert, darum kenne ich die Zuordnung mit den Fenstericons noch nicht.
Aber kannst Du nicht eine map-Datei schreiben, die die empfangenen Zustände umsetzt?
"Window status: locked"=zu
"Window status: open"=offen
"Window status: tilted"=gekippt
Und dann State-Description die Map-Datei hinterlegen? "MAP(test.map):%s"
Was zeigt denn dann das Item an?
Zu dem 3-fach-Icon ist es dann auch nicht mehr weit...

Wie gesagt, habe das in OH3 mit Homematic-Fenstersensoren noch nicht gemacht, steht mir aber noch bevor.
Habe davon 5 Stück verbaut :shock:

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 14. Feb 2021 20:25
von Anbeku
violine21 hat geschrieben: 14. Feb 2021 17:57
Aber kannst Du nicht eine map-Datei schreiben, die die empfangenen Zustände umsetzt?
"Window status: locked"=zu
"Window status: open"=offen
"Window status: tilted"=gekippt
Und dann State-Description die Map-Datei hinterlegen? "MAP(test.map):%s"
Wäre mal ein Versuch Wert. Irgendwie habe ich das mit den map Dateien erst spät verstanden. Ich konnte mir nicht vorstellen, dass es da in OH3 keinen weg gibt, die über die Gui zu erzeugen, aber so sieht es wohl aus, und ein Addon muss man dafür auch installieren.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 15. Feb 2021 00:58
von udo1toni
Anbeku hat geschrieben: 14. Feb 2021 20:25
violine21 hat geschrieben: 14. Feb 2021 17:57
Aber kannst Du nicht eine map-Datei schreiben, die die empfangenen Zustände umsetzt?
"Window status: locked"=zu
"Window status: open"=offen
"Window status: tilted"=gekippt
Und dann State-Description die Map-Datei hinterlegen? "MAP(test.map):%s"
Wäre mal ein Versuch Wert. Irgendwie habe ich das mit den map Dateien erst spät verstanden. Ich konnte mir nicht vorstellen, dass es da in OH3 keinen weg gibt, die über die Gui zu erzeugen, aber so sieht es wohl aus, und ein Addon muss man dafür auch installieren.
Das Mapping kann (noch) nicht über die UI angelegt werden, wie viele andere Dinge auch...

Das window Icon bietet die drei Zustände open, closed und ajar. Wenn der String anders gefüllt wird, musst Du entweder mittels Rule und Proxy Item arbeiten oder alternativ ein eigenes Iconset (z.B. window2) anlegen, mit den entsprechenden Strings, damit es korrekt angezeigt wird.

Mit Proxy item ist das aber genauso möglich und die oben gezeigte Rule funktioniert genauso, nur noch einfacher, da ja nur ein Quellitem gebraucht wird:

Code: Alles auswählen

Rule "Fensterzustand von String IN nach String OUT"
when
    Member of gWinStringIN changed
then
    val strName = triggeringItem.name.split("_").get(0) // welches Fenster betrifft die Änderung
    var strState = "CLOSED"
    if(triggeringItem.state.toString == "Window status: open")
        strState = "OPEN"
    else if(triggeringItem.state.toString == "Window status: tilted")
        strState = "AJAR"
    if(gWinStringOUT.members.filter[i|i.name.startsWith(strName)].head.state.toString != strState)
        gWinStringOUT.members.filter[i|i.name.startsWith(strName)].head.postUpdate(strState)
end
Das Prinzip bleibt das gleiche, im Proxy Item wird der String in Abhängigkeit der Status gesetzt.

Eine Rule um vor geöffneten oder gekippten Fenstern zu warnen ist ebenso einfach realisierbar, ohne weiteres auch auf Basis des "Originalitems":

Code: Alles auswählen

Rule "Fensterzustand melden"
when
    Member of gWinStringIN changed
then
    val lTilted = gWinStringIN.members.filter[i|i.state.toString == "Window status: tilted" ]
    val lOpen = gWinStringIN.members.filter[i|i.state.toString == "Window status: open" ]
    val lClosed = gWinStringIN.members.filter[i|i.state.toString == "Window status: locked" ]
    var strMessage1 = "Anzahl geschlossene Fenster: " + lClosed.size
    var strMessage2 = "Anzahl offene Fenster: " + lOpen.size
    var strMessage3 = "Anzahl gekippte Fenster: " + lTilted.size
    var strMessage4 = "geschlossene Fenster: "
    lClosed.forEach[i|strMessage = strMessage + i.name + " "]
    var strMessage5 = "offene Fenster: " 
    lOpen.forEach[i|strMessage = strMessage + i.name + " "]
    var strMessage6 = "gekippte Fenster: 
    lTilted.forEach[i|strMessage = strMessage + i.name + " "]
    // die 6 Texte ausgeben...
end
Das natürlich nur als Beispiel, wie man die entsprechenden Meldungen generieren kann.

Re: OH3: "Mapping" für Drehriffsensoren mit drei Zuständen

Verfasst: 15. Feb 2021 09:30
von Anbeku
Ich baue da mal was zusammen. Ich frage mich allerdings, warum der Contact in Openhab3 nicht einfach drei Zustände hat. Wenn es Icons mit drei Zuständen gibt, hat man das Problem ja offenbar schon erkannt. Es dürfte ja auch eigentlich nichts kaputt gehen, wenn man dem ENUM einfach einen dritten Wert hinzufügt, der sonst einfach nicht benutzt wird. Aber das müsste ich wohl die Entwickler fragen.