openhabforum.de

Moin zusammen,
ich versuche gerade die Dauer des Lüftens mit Fensterkontakten zu überwachen und im Bedarf eine Nachricht per Telegram zu verschicken.

Der Ansatz ist:
Fenster Offen triggert einen Timer von 15 Min

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: DuscheFenster_OffenGeschlossen
      state: OPEN
      previousState: CLOSED
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      command: ON
      itemName: DuscheTimer15Min
    type: core.ItemCommandAction

Wenn der Timer seinen Status von ON wechselt, schicke Nachricht an Telegram Gruppe

Code: Alles auswählen

configuration: {}
triggers:
  - id: "2"
    configuration:
      itemName: DuscheTimer15Min
      previousState: ON
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "3"
    configuration:
      type: application/javascript
      script: >
        var logger  =
        Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' +
        ctx.ruleUID);

        var things = Java.type('org.openhab.core.model.script.actions.Things');



        if (items.getItem('DuscheFenster_OffenGeschlossen').state == 'OPEN') {
          things.getActions('telegram', 'telegram:telegramBot:076f70b110').sendTelegram('Achtung! Fenster in der Dusche ist offen');
          logger.info("Alarm Dusche Fenster ist offen. Nachricht an Telegram geschickt")
        }
    type: script.ScriptAction

Das funktioniert schon, hat aber ein kosmetisches Problem. Die Timer werden getriggert und sind danach im State: UNDEF. Es gab dazu verschiedene Posts das mit autoupdate auf off zu setzten z.B. hier viewtopic.php?p=33103#p33103 das scheint aber in OH 4 nicht mehr zu funktionieren oder ich finde die Konfiguration nicht

. In der Doku hatte ich zu Autoupdate von Items auch leider nichts gefunden. Habt ihr da eine Idee, wie man den Status auf OFF setzen kann, wenn er sich von ON ändert? Hab es mit einer Rule versucht und bin gescheitert.

Ich gehe mal davon aus, dass das Item DuscheTimer15Min mit einem Expiration Timer versehen ist. Mein Tipp: ändere die Funktionsweise.
Definiere, dass der Expiration Timer nach 15 Minuten ein Command OFF senden soll.
In der Rule zum aktivieren des Timers nutzt Du ein postUpdate(ON), falls das Fenster geschlossen wird, soll ein postUpdate(OFF) gesendet werden (kein Command)

Nun kannst Du die zweite Rule (zum Versenden der Nachricht) auf received command OFF triggern lassen.

Grundsätzlich kannst Du das autoupdate über die Metadaten beeinflussen, der Weg über postUpdate() ist aber besser, Du willst ja nicht Immer eine Nachricht bekommen, sondern nur, wenn das Fenster zu lange offen steht.

udo1toni hat geschrieben: ↑2. Feb 2024 20:58 Ich gehe mal davon aus, dass das Item DuscheTimer15Min mit einem Expiration Timer versehen ist.

yepp

udo1toni hat geschrieben: ↑2. Feb 2024 20:58 Mein Tipp: ändere die Funktionsweise.
Definiere, dass der Expiration Timer nach 15 Minuten ein Command OFF senden soll.
In der Rule zum aktivieren des Timers nutzt Du ein postUpdate(ON), falls das Fenster geschlossen wird, soll ein postUpdate(OFF) gesendet werden (kein Command)

Das hatte ich vorher vergeblich gesucht. Wenn das Item schon existiert, wird das nicht angezeigt... erst wenn man einen neuen expiration timer setzt . Klassischer Fall von Fehler 40

udo1toni hat geschrieben: ↑2. Feb 2024 20:58
Nun kannst Du die zweite Rule (zum Versenden der Nachricht) auf received command OFF triggern lassen.

Grundsätzlich kannst Du das autoupdate über die Metadaten beeinflussen, der Weg über postUpdate() ist aber besser, Du willst ja nicht Immer eine Nachricht bekommen, sondern nur, wenn das Fenster zu lange offen steht.

Kurzfassung: alle Timer sind umgebaut und funktionieren. Der Timer ist entweder ON oder OFF. Vielen Dank

oliverbaush hat geschrieben: ↑3. Feb 2024 09:04 Das hatte ich vorher vergeblich gesucht. Wenn das Item schon existiert, wird das nicht angezeigt... erst wenn man einen neuen expiration timer setzt . Klassischer Fall von Fehler 40

Du meinst, Du wolltest den existierenden Timer umbauen? Ja, kann gut sein, dass man dort nicht mehr nachträglich etwas ändern kann, sondern den Timer entfernen und erneut anlegen muss...

Das sind Stellen in openHAB, bei denen ich froh bin, bei der Textkonfiguration geblieben zu sein.
Wenn man in der Textkonfiguration etwas ändert (egal was), dann wird es geändert.
Wenn diese Änderung daraus besteht, ein existierendes "etwas" zu löschen und neu anzulegen, dann geschieht das automatisch, denn man hat ja die bestehende Konfiguration (durch die Änderung) entfernt (z.B. wenn man die UID eines Things ändert oder den Namen eines Items).

udo1toni hat geschrieben: ↑3. Feb 2024 11:03 Das sind Stellen in openHAB, bei denen ich froh bin, bei der Textkonfiguration geblieben zu sein.

Ich hatte bisher nur über die UI alles angelegt und mich aus Unwissenheit nie mit der textbasierten Config auseinander gesetzt

. Denke das das auch der bequemere Einstieg ist

Blöd gefragt: gibt es aktuell gute Gründe auf textbasiert umzusteigen?

Nein, Du kannst inzwischen praktisch alles, was über Textkonfiguration geht, genauso auch über die UI konfigurieren.

Die UI hat den Charme, dass man jederzeit alle möglichen Parameter sehen kann, an den meisten Stellen mit sinnvollen Hilfstexten. Es gibt natürlich diverse Dinge, die man trotzdem wissen muss, z.B. wie man eine Transformation erstellt, letztlich alles "händischer" Code ohne großartige Hilfstexte.

Auf der anderen Seite hat die Textkonfiguration den Charme, dass man sie sehr einfach selbst schreiben kann, das Format ist gut dokumentiert und man kann viele gleichartige Things durch Copy&Paste sowie Änderung von Details sehr viel schneller erstellen als über die UI, wo man immer wieder zig Dinge immer wieder identisch zusammenklicken muss. Während json händisch zu bearbeiten kein Vergnügen ist, kann man yaml ganz gut von Hand bearbeiten, allerdings besteht yaml auf sehr strikten Formatierungen mittels Einrückungen, was halt schon lästig sein kann. Die Textkonfiguration hat ebenfalls ihre Pros und Kontras, aber zumindest die Formatierung kann nach Belieben auf möglichst gute Lesbarkeit angepasst werden.
Alles was über Textdateien konfiguriert wurde, kann über die UI nicht editiert, aber sehr wohl eingesehen werden. Man könnte also auch von einer erhöhten Sicherheit gegenüber versehentlichen Änderungen sprechen (wenn man unbedingt positive Aspekte sucht...).

Für mich ist es einfach die gewohnte Art, Dinge zu konfigurieren

und zumindest hier im Forum ist es eine wesentlich effektivere Art, Konfigurationsdetails zu zeigen als über Screenshots (komplett sinnlos, weil man anschließend alles abtippen muss...) und wie erwähnt verzeiht das ursprüngliche Textformat zumindest ungewöhnliche Formatierungen eher als das yaml Format. Zudem sind Items bisher über yaml nur unvollständig abgebildet, wenn man also Screenshots vermeiden will, ist die Textkonfiguration momentan tatsächlich die einzige Möglichkeit, Items "fertig zur Verwendung" im Forum zu teilen.

openhabforum.de

[Solved] Auto Update von Switch Item

[Solved] Auto Update von Switch Item

Re: Auto Update von Switch Item

Re: Auto Update von Switch Item

Re: [Solved] Auto Update von Switch Item

Re: [Solved] Auto Update von Switch Item

Re: [Solved] Auto Update von Switch Item