openhabforum.de

Hallo zusammen,
nach ein paar arbeitsreichen Wochen habe ich nun endlich Urlaub und wieder etwas Zeit, mich meinem OH3 zu widmen... immer noch nebenbei laufend (OH2.5 ist produktiv).
Es gibt ja schon eine ganze Reihe Beiträge zum Semantic Modell, aber speziell zu den Fenstersensoren von homematic habe ich nichts finden können.
Warum speziell? Im Gegensatz zu meinem alten Innogy-System werden die Fenstersensoren nicht mit einem Contact-Item angelegt, sondern als String. Und dafür bekomme ich dann die kleine Anzeige auf den Cards nicht hin...

Ich meine diese kleinen Icons, die auf der Card zu sehen sind... oder hier eben nicht:

Bad1.JPG

Beim Innogy System, wo die Sensoren als Contact angelegt wurden, waren die Icons automatisch da..

Jemand ne Idee? Merke, dass es auch echt ein Problem sein kann, wenn man sich mal ein paar Wochen so gar nicht damit beschäftigt....

Danke!
Oliver

Hallo Oliver,
was für Fenstersensoren hast du denn ? Ich habe IP-SWDO-Sensoren und die kennen sowohl String als auch Contact. Dann habe ich auch noch einen "IP-SRH"-Kipp-Sensor, der hat nur String mit "OPEN, CLOSED und TILTED". OH3 kennt aber nur OPEN und CLOSED bzw. ON und OFF.

Vielleicht interessieren dich in diesem Zusammenhang die Infos auf dieser Webseite.

Um die Anzeige für den Kipp-Sensor auch angezeigt zu bekommen, habe ich mir ein "Dummy-Item" gebastelt:

Code: Alles auswählen

Contact  HmIP_SRH_0515_1STATECONTACT "Terrassentür Essen Status Kontakt[MAP(de.map):%s]" <door> (gSen_0515,gHaustur)  ["OpenState"]  // Dummy-Contact Item

und noch eine kleine DSL-Rule, die die Status umsetzt:

Code: Alles auswählen

rule "HM Status Terrassentuer Esszimmer Umwandlung"
    when
      Item HmIP_SRH_0515_1STATE changed 
    then
      if ( HmIP_SRH_0515_1STATE.state == "OPEN" ) {
          HmIP_SRH_0515_1STATECONTACT.postUpdate(OPEN)
          logInfo("homematic","Terrassentür offen {} ", HmIP_SRH_0515_1STATECONTACT.state )
          return ;
      }
      else if (HmIP_SRH_0515_1STATE.state == "CLOSED") {
          HmIP_SRH_0515_1STATECONTACT.postUpdate(CLOSED)
          logInfo("homematic","Terrassentür geschlossen {} ", HmIP_SRH_0515_1STATECONTACT.state)
      }
      else if (HmIP_SRH_0515_1STATE.state == "TILTED") {
          HmIP_SRH_0515_1STATECONTACT.postUpdate(OPEN)
          logInfo("homematic","Terrassentür gekippt {} ", HmIP_SRH_0515_1STATECONTACT.state )
      }
      else {
          logInfo("homematic","Terrassentür nix passiert {} ", HmIP_SRH_0515_1STATE )
      }
end

Vielleicht hilft dir das !!??

Gruss - Peter

Hallo Peter,

ich nutze lediglich die SWDM, keine Drehgriffkontakte. Wenn ich da durch VSC die item automatisch aus dem Thing anlegen lasse, dann bekomme ich eben für Kanal "_Kanal1_STATE" ein String-item angelegt.

Hatte in der Vergangenheit schon mal probiert, das manuell durch Contact zu ersetzen, da ging aber gar nix mehr.
Jetzt gerade noch mal probiert, bisher zeigt er mir den korrekten Status an... keine Ahnung, entweder damals was falsch gemacht oder da hat sich zwischen 2.5 und 3.1 doch etwas geändert, dass er mit beidem zurecht kommt.

Aber auch als Contact bekomme ich es nicht direkt auf der Kachel angezeigt, sondern ich muss halt immer "rein" gehen. Ich hätte aber gerne schon diese kleinen Icons die direkt auf der Kachel angezeigt werden... Weißt was ich mein???

Vielleicht hat das aber auch gar nichts damit zu tun, mit welchem Item-Typ die Channels verknüpft sind und das Problem liegt ganz woanders (oder sitzt vor dem Rechner

)

Danke und Gruß
Oliver

Hallo Oliver,
Ich glaube nicht, dass es mit einer Umänderung des Item-Types getan ist. Du musst schon ein neues Item vom Typ "Contact" anlegen.

Dieses Item wird mit der Regel geändert, wenn sich der Status deines Original-Items ändert. Es tritt sozusagen an die Stelle des Original-Items.

Hier noch mal die zwei Items:

Code: Alles auswählen

String   HmIP_SRH_0515_1STATE  "Terrassentuer Status[MAP(de.map):%s]" <door> (gSen_0515)  ["Point"]   {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:1#STATE"}
Contact  HmIP_SRH_0515_1STATECONTACT  "Terrassentür Essen Status Kontakt[MAP(de.map):%s]"  <door>  (gSen_0515,gHaustur) ["OpenState"] // Dummy-Contact Item

Das erste Item ist das Original und das zweite, dass für den Ausweis in der Location verwendet wird (["OpenState"]) und abhänig davon durch die Rule verändert wird.

Wenn es aber auch als Contact-Item funktionieren sollte, musst du natürlich auch eine "Location und Equipment"-Zuordnung haben.

Mein gesamter Item-Block für den Sensor sieht so aus:

Code: Alles auswählen

// Terrassentür - Esszimmer 0007D7099D0515                                                                                                                                                 
Group                  gSen_0515                                      "Terrassentür Essen"                                           <door>           (gEG_Essen,gTuer)                    ["Door"]  
Switch                 HmIP_SRH_0515_0DELETEDEVICE                    "Terrassentuer Delete device [%s]"                                              (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#DELETE_DEVICE"}
Switch                 HmIP_SRH_0515_0CONFIGPENDING                   "Terrassentuer Config pending [%s]"                                             (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#CONFIG_PENDING"}
String                 HmIP_SRH_0515_0DELETEDEVICEMODE                "Terrassentuer Delete device mode [%s]"                                         (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#DELETE_DEVICE_MODE"}
Switch                 HmIP_SRH_0515_0DUTYCYCLE                       "Terrassentuer Duty cycle [%s]"                                                 (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#DUTY_CYCLE"}
Number                 HmIP_SRH_0515_0ERRORCODE                       "Terrassentuer Error code [%s]"                                                 (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#ERROR_CODE"}
String                 HmIP_SRH_0515_0FIRMWARE                        "Terrassentuer Firmware [%s]"                               <firmware>          (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#FIRMWARE"}
Switch                 HmIP_SRH_0515_0INSTALLTEST                     "Terrassentuer Install test [%s]"                                               (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#INSTALL_TEST"}
Switch                 HmIP_SRH_0515_0LOWBAT                          "Terrassentuer Batteriestatus [MAP(battery.map):%s]"        <lowbattery1>       (gSen_0515,gBatt)                    ["LowBattery"]               {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#LOW_BAT"}
Number                 HmIP_SRH_0515_0OPERATINGVOLTAGE                "Terrassentuer Operating voltage [%.1f V]"                                      (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#OPERATING_VOLTAGE"}
String                 HmIP_SRH_0515_0OPERATINGVOLTAGESTATUS          "Terrassentuer Operating voltage status [%s]"                                   (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#OPERATING_VOLTAGE_STATUS"}
Number                 HmIP_SRH_0515_0RSSI                            "Terrassentuer Rssi [%s]"                                                       (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#RSSI"}
Number                 HmIP_SRH_0515_0RSSIDEVICE                      "Terrassentuer Rssi device [%s]"                                                (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#RSSI_DEVICE"}
Number                 HmIP_SRH_0515_0RSSIPEER                        "Terrassentuer Rssi peer [%s]"                                                  (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#RSSI_PEER"}
Switch                 HmIP_SRH_0515_0SABOTAGE                        "Terrassentuer Sabotage [%s]"                                                   (gSen_0515)                          ["Alarm","Presence"]         {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#SABOTAGE"}
Number                 HmIP_SRH_0515_0SIGNALSTRENGTH                  "Terrassentuer Signalstärke [%s]"                           <signal>            (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#SIGNAL_STRENGTH"}
Switch                 HmIP_SRH_0515_0UNREACH                         "Terrassentuer Unreach [%s]"                                                    (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#UNREACH"}
Switch                 HmIP_SRH_0515_0UPDATEPENDING                   "Terrassentuer Update ausstehend [%s]"                                          (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#UPDATE_PENDING"}
String                 HmIP_SRH_0515_1STATE                           "Terrassentuer Status[MAP(de.map):%s]"                      <door>              (gSen_0515)                          ["Point"]                    {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:1#STATE"}
String                 HmIP_SRH_0515_0BATTERYTYPE                     "Terrassentuer Batterie Typ [%s]"                                               (gSen_0515)                          ["Control"]                  {channel="homematic:HmIP-SRH:3014F711A0001F98A9AABCAF:0007D7099D0515:0#BATTERY_TYPE"}
Contact                HmIP_SRH_0515_1STATECONTACT                    "Terrassentür Essen Status Kontakt[MAP(de.map):%s]"         <door>              (gSen_0515,gHaustur)                 ["OpenState"]              // Dummy-Contact Item

Das erste Item (Gruppen-Item) ist das Equipment (["Door"]) welches über Gruppenzuordnung (gEG_Essen) die semantische Verbindung zur Location hat und das natürlich an die Gruppenmitglieder "vererbt". (Soweit ich das verstehe

).

Das Icon ist aber natürlich in der Location nur sichtbar, wenn der Status "OPEN" ist.

Noch eine Bemerkung am Rande, wenn ich in OH3 das Homematic-Binding aktiviere, wird die Verbindung zu meinem OH2.5-System unterbrochen.

Es wird also jeweils das zuletzt hochgefahrene System berücksichtigt. Ich weiss aber nicht, ob das so bei allen Usern ist oder nur bei mir

open.jpg

Hallo Peter,

vielen Dank noch mal! Aber widersprichst Du dir da nicht selbst? Du hattest zuerst geschrieben, Deine SWDO keinen auf dem Kanal sowohl String als auch Contact. Im letzten Beitrag aber, dass Du ein ungebundenes Contact-Item nimmst und das über ein Rule schaltest... Das ist nicht das Gleiche!

Bei uns im Haus würde das bedeuten, dass ich für 24 Fenster und 4 Türen jeweils zwei Items anlegen müsste und die Rules dazu... das ist es mir dann doch nicht wert, Zumal die Ansicht ja im Grunde tatsächlich nur die alte PaperUI ablöst (wenn auch auf eine sehr schöne Art). Meist nutze ich das Smartphone und darauf eine Sitemap, die super funktioniert.

Von daher verzichte ich da jetzt einfach mal auf die Anzeige... aber wie gesagt: Danke!

VG, Oliver

...nein,nein, nein. Das war wohl etwas missverständlich. Ich habe die SWDO-Sensoren für die Fenster. Die bringen von Haus aus sowohl ein String- und ein Contact-Item mit(Thing). Wobei, soweit mir bekannt ist, das Contact-Item aus/im Binding (Thing) erzeugt wird. Du findest dazu bestimmt Näheres im internationalen Forum bzw. bei Martin Herbst.

Der Fenster/Tür-Sensor "SRH" hat aber nur ein String-Item, der die Werte OPEN/CLOSED/TILTED darstellt. Deshalb ist er für die Anzeige in der "Location"-Card nicht geeignet, da er nicht vom Typ Contact/Switch ist. Deshalb habe ich hier diesen Umweg mit der Regel gewählt. etwas ähnliches habe ich auch für meine Sonos-Boxen gemacht. Dies gilt natürlich nur für die Anzeige in den Standard/Default-Cards(Location).

Es ist natürlich jederzeit möglich eine eigene Seite (Page) ähnlich wie in OH2 innerhalb einer Sitemap zu kreieren, so wie du das wahrscheinlich jetzt schon tust und dir damit die Werte anzuzeigen, allerdings wird das wahrscheinlich bei der Anzeige des Status bei Group-Items nicht so funktionieren.

Nun wieder zu deinen Sensoren; wenn die "Things" deiner Sensoren einen "Channel" für ein "Contact"-Item aufweisen ist alles ok und die Darstellung sollte ohne Probleme möglich sein, wenn nicht, gibt es nur den Umweg oder Verzicht.

Die Regel sollte aber eigentlich nicht so das grosse Problem sein, da du hier mit dem Member-Trigger arbeiten kannst und 24 (28) weitere Items per Copy/Paste anzulegen, sollte auch keine grosse Hürde darstellen. Ich könnte mir auch vorstellen, dass Udo hierzu ein paar tolle Infos zur Verfügung hätte.

Man kann auch die PaperUI und die Location-Card nicht miteinander vergleichen. Eigentlich war die PaperUI als Admin-Tool gedacht, so wie es nun unter OH3 die MainUI ist und nicht GUI.

Wie gesagt die Visualisierung ist die eine Seite der Medaille, aber die andere Seite (die viel wichtigere) ist die Kommunikation der Sensoren mit meinen Heizkörperthermostaten und die funktioniert wunderbar.

Grüssle aus dem Schawbenland - Peter

Ah, okay.. dann habe ich das tatsächlich falsch verstanden. Wie gesagt, ich nutze nur die "normalen" Sensoren mit Magnet. Wie gesagt, sooo wichtig ist mir das nicht, wäre lediglich nett gewesen.
Auf meiner Sitemap läuft ja alles exakt so, wie unter oh2.5 und das ist auch das, was ich täglich nutze...

openhabforum.de

OH3: Semantic Modell bei homematic Fenstersensoren

OH3: Semantic Modell bei homematic Fenstersensoren

Re: OH3: Semantic Modell bei homematic Fenstersensoren

Re: OH3: Semantic Modell bei homematic Fenstersensoren

Re: OH3: Semantic Modell bei homematic Fenstersensoren

Re: OH3: Semantic Modell bei homematic Fenstersensoren

Re: OH3: Semantic Modell bei homematic Fenstersensoren

Re: OH3: Semantic Modell bei homematic Fenstersensoren