Fenstergriff betätigt Zeitstempel

[peter-pan]

...kein Problem. Ich lauf nicht weg. Spass beiseite. Danke dass du immer gerne weiterhilfst. Das Problem ist ja auch nicht überlebenswichtig, aber trotzdem interessant.

[udo1toni]

Also, ich kann bestätigen, dass weder in der Itemliste (die berücksichtigt ohnehin kein Pattern) noch in der Detailansicht bei DateTime die Pattern Formatierung berücksichtigt wird.
In der Main UI jedoch passt alles.
Sieht für mich nach einem Fehler aus, den man im englischen Forum/in github erwähnen könnte (ich denke, das ist Core)

[pauliv_de]

Den von @peter-pan erwähnten Aufsatz habe ich gelesen, verstehe ihn so, dass der Zeitstempel nicht erzeugt wird.
In meinem Fall wird der Zeitstempel zwar bei jeder Betätigung des Fenstergriffs erzeugt, aber mittels State description nicht formatiert.

[peter-pan]

@pauliv_de
Das habe ich im Wesentlichen auch daraus gelesen. Aber es ging wohl um einen MQTT-Channel und das auch irgenwie um ein "Number-Format".

Aber da wird geschrieben:

Code: Alles auswählen

As described above, the state description "pattern" is no longer observed after the "Is Command" switch has been activated once.

und @J-N-K antwortet:

Code: Alles auswählen

As far as I can see it all works perfectly fine. I setup MQTT similar to your setup with the same state descriptions and with both timestamp profiles.
The only thing I noticed is that the timestamp does not update at all when "isCommand" is enabled.

Da hört's dann bei mir auf. Ich verstehe nicht was mit dem" isCommand" gemeint ist.

Ich bin wie Udo der Meinung, dass da irgendwas im Kern nicht ganz passt. Wenn ich aus dem Item wieder ein "Ungebundenes" mache, dann wird der Pattern/Formatierer auch wieder berücksichtigt.

[pauliv_de]

Zwischenzeitlich habe ich ein Issue eröffnet
https://github.com/openhab/openhab-core/issues/4050

[peter-pan]

...Super

[udo1toni]

isCommand ist ein Flag, welches man bei verschiedenen Bindings im Channel setzen kann, woraufhin ein ankommendes Signal als Befehl interpretiert wird.
Leider gibt es da bisher auch keine einheitliche Regelung. Der Punkt ist: normalerweise ist openHAB der Teil, der Befehle gibt. Geräte können ihren Status melden und ansonsten die Klappe halten
Nun gibt es aber (gar nicht so selten) den Fall, dass man ein "Gerät" hat, welches nur einen Zweck hat, nämlich Befehle zu senden (z.B. ein Bewegungsmelder oder ein Taster). Will man so ein Gerät mit openHAB verbinden, um wiederum ein anderes Gerät (eines anderen Systems) zu steuern, so musste man früher eine Rule schreiben, welche den Status des Tasters oder Bewegungsmelders auswertete und stellvertretend den eigentlichen Schaltbefehl sendete - ganz schön umständlich. Dafür wurden dann verschiedene Lösungen erfunden, unter anderem das Profile follow, ein Channel, der mit diesem Profile an ein Item gekoppelt ist, wertet jeden Status als passenden Befehl und sendet entsprechend den Status an das verbundene Gerät weiter. Bei knx gab es ein Fehlverhalten (ursprüngliche Implementation in openHAB1), es gab schlicht keinen erkennbaren Unterschied im Verhalten bei ankommenden Meldungen, was dann zu Loops führte. Deshalb wurden die *-control Channel eingeführt, bei denen ankommende Meldungen als Befehl gewertet werden, wohingegen die postUpdates umgehend auf den knx Bus gesendet werden - und damit kann man dann einfach z.B. eine HUE Lampe mit einer knx Taste steuern, ganz ohne Rule, ganz ohne follow Profile.
In mqtt und http wurde stattdessen das isCommand Flag eingeführt, um (ankommend) ein gleichartiges Verhalten zu erreichen. Kommt aus einem solchen Channel eine Meldung rein, so wird sie als Befehl weitergeleitet, also z.B. wird received command getriggert, statt received update oder changed.
Ein Channel mit isCommand sollte eigentlich nie ein changed Ereignis triggern, womit dann auch klar sein dürfte, warum keine Zeitstempel mehr erzeugt werden (die werden im Übrigen ja auch über das Profile ermöglicht, und man kann immer nur ein Profile nutzen, also follow + Zeitstempel geht nicht).

Blöd ist also, dass es zwei unterschiedliche Lösungen für das selbe Problem gibt, gut hingegen, dass man eine schon bestehende Möglichkeit nicht wieder weg erfunden hat, nur weil es inzwischen eine "allgemeinere" Lösung gibt.

[peter-pan]

... die Botschaft hör ich wohl, allein mir fehlt der Grips (frei nach Goethes Faust). Hast du evtl. ein praktische Beispiel aus deinem Fundus ?

So wie ich das verstehe, gibt es ja nur ein Profil ( [profile="system:timestamp-update"] ), oder ?

[pauliv_de]

Ob die Erklärung von Udo zur Lösung meines Problems beitragen kann weiß ich nicht...

Aber zwischenzeitlich habe ich heraus gefunden, dass das fehlerhafte Verhalten bei items auftritt die "options" und "commandDescription" Parameter wie auch z.B. "STABLE" und "NOT STABLE" oder "CLOSED", "TILTED" und "OPEN" enthalten...

Bei Items die als Status nur "ON" oder "OFF" melden tritt der Fehler nicht auf !

Dem entsprechend habe ich https://github.com/openhab/openhab-core/issues/4050 ergänzt.
Gruß Paul

[peter-pan]

Aber zwischenzeitlich habe ich heraus gefunden, dass das fehlerhafte Verhalten bei items auftritt die "options" und "commandDescription" Parameter wie auch z.B. "STABLE" und "NOT STABLE" oder "CLOSED", "TILTED" und "OPEN" enthalten...

...das hab ich jetzt leider auch nicht verstanden
Mein REST-Api-Json für das Zeitstempek-Item sieht in diesem Fall so aus:

Code: Alles auswählen

{
  "link": "http://192.168.178.38:8080/rest/items/HmIP_SRH_0515_1STATE_Time",
  "state": "2024-01-20T16:31:58.547492921+0100",
  "stateDescription": {
    "pattern": "%1$td.%1$tm.%1$ty - %1$tH:%1$tM Uhr",
    "readOnly": true,
    "options": [
      {
        "value": "CLOSED",
        "label": "Fensterzustand: verriegelt"
      },
      {
        "value": "TILTED",
        "label": "Fensterzustand: gekippt"
      },
      {
        "value": "OPEN",
        "label": "Fensterzustand: offen"
      }
    ]
  },
  "commandDescription": {
    "commandOptions": [
      {
        "command": "CLOSED",
        "label": "Fensterzustand: verriegelt"
      },
      {
        "command": "TILTED",
        "label": "Fensterzustand: gekippt"
      },
      {
        "command": "OPEN",
        "label": "Fensterzustand: offen"
      }
    ]
  },
  "metadata": {
    "semantics": {
      "value": "Point",
      "config": {
        "isPointOf": "gSen_0515"
      }
    },
    "stateDescription": {
      "value": "pattern",
      "config": {
        "pattern": "%1$td.%1$tm.%1$ty - %1$tH:%1$tM Uhr"
      }
    }
  },
  "editable": false,
  "type": "DateTime",
  "name": "HmIP_SRH_0515_1STATE_Time",
  "label": "Terrassentuer Datum ",
  "category": "window",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "gSen_0515"
  ]
}

Du hast da aber was mit ON/OFF erwähnt. Das bringt mich auf den Gedanken, dass das evtl. mit dem Item-Typ des Ursprungs-Items zusammenhängt. Vielleicht verhält es sich bei einem (gebunden) Switch-Item anders als bei einem String-Item. Ich werd's einfach mal ausprobieren. Aber eigentlich sollte es ja nicht so sein.