Hauptmenü

Fragen zu watchdog

Begonnen von Kharim, 26 November 2015, 22:24:33

Vorheriges Thema - Nächstes Thema

Kharim

Hallo zusammen,

ich habe hier einen Dummy FensterID, welches Werte zwischen 0 und 4 annehmen kann.
(0 kein Fenster offen, 1-4 das jeweilige Fenster offen - gesetzt über Notify)

Nun möchte ich einen Watchdog im Stile von: "set Fenstertest watchdog FensterID!=0 00:05:00 FensterID==0 Fensternachricht()"
"Fensternachricht()" ist dabei eine eigene Funktion in 99_myUtils.

Leider passiert rein gar nichts...ich habe auch nichts im Log entdecken können.

Was mache ich falsch?

Vielen Dank,
Kharim
Raspberry Pi 2 + Minibian + 2x MAX Cube CUN (868/433Mhz) + Thermostate + Fensterkontakte + Taster+RGB-LED Band über pigpiod + TFA Sensoren 30.3169/3125
Raspberry Pi 2 + Minibian +Z-Wave (USB) + Bewegungsmelder + Fensterkontakt + Sirene + SMS Steuer-/Benachrichtigung (ohne Internet)

Muschelpuster

Ich glaube, dass Zustände, die über Notifys gesetzt werden keine Events auslösen. Das könnte ja auch massive Kettenreaktionen auslösen. Aber der Watchdog braucht ein Event....
Wie wäre es mit dem Schweizer Taschenmesser des FHEM für solche Fälle - genannt DOIF:
define Fenstertest doif ([FensterID:state] ne "0") (Fensternachricht())
Dann noch das Atribut WAIT setzen und die ganze Sache geht erst verzögert los.
Aber evtl. braucht DOIF auch ein Event?...

2. Ansatz ist evtl. die Prüfung des Dummy auf einen numerischen Wert. Da ein Dummy auch einen String aufnehmen kann, verspricht folgendes vielleicht mehr Erfolg:
set Fenstertest watchdog FensterID ne "0" 00:05:00 FensterID==0 Fensternachricht()

Sicher bin ich mir hier nicht, aber vielleicht hilft das ja als Denkansatz etwas weiter.

überwachte Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Kharim

Von der DOIF war ich eigentlich abgekommen, da diese nicht unterbrechbar ist?

Ich benötige quasi eine Wartezeit die abgebrochen werden kann.....daher die Idee über den Watchdog.
Raspberry Pi 2 + Minibian + 2x MAX Cube CUN (868/433Mhz) + Thermostate + Fensterkontakte + Taster+RGB-LED Band über pigpiod + TFA Sensoren 30.3169/3125
Raspberry Pi 2 + Minibian +Z-Wave (USB) + Bewegungsmelder + Fensterkontakt + Sirene + SMS Steuer-/Benachrichtigung (ohne Internet)

Damian

Zitat von: Kharim am 27 November 2015, 09:52:06
Von der DOIF war ich eigentlich abgekommen, da diese nicht unterbrechbar ist?

Ich benötige quasi eine Wartezeit die abgebrochen werden kann.....daher die Idee über den Watchdog.

Aber selbstverständlich wird die Wartezeit abgebrochen, wenn sich die Bedingung ändert.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

ahilger1306

#4
Ich bin Newbie und komme i-wie überhaupt nicht mit dem Watchdog klar. vlt. kann mir jmd. helfen


define wd_NAS_lebt watchdog NAS_lebt==warten 00:00:03 NAS_lebt==alive set NAS_lebt stoerung;; trigger wd_NAS_lebt


Hintergrund:

NAS_lebt ist ein Dummy Device nur mit einem state als Reading.
Es bekommt alle 60 Sekunden von außen (per Telnet) den Wert "alive" gesetzt.
Das wiederum aktiviert ein Notify welches den Wert nach 50 Sekunden auf "warten" setzt.

Wenn jetzt von außen kein "alive" mehr kommt, möchte ich das über den Watchdog erkennen und mir eine Nachricht per Push senden.

Was mache ich falsch? Ist der Ansatz generell suboptimal?

Gruß und Danke
André


RAW vom Dummy

defmod NAS_lebt dummy
attr NAS_lebt group Systemüberwachung

Beta-User

Zitat von: ahilger1306 am 24 Mai 2018, 16:17:18
Was mache ich falsch? Ist der Ansatz generell suboptimal?
Zum einen: uralt-Beiträge aufwärmen, die irgendwie auch keine abschließende Lösung anbieten. Da liegt doch der Schluß nahe, dass die verwendete Syntax nicht paßt ;) .

Zum zweiten: Erstelle Event-Handler am besten mit dem Event-Monitor (siehe Wiki). (Mind.) die Syntax für die Events müßte anders aussehen, und der Punkt am Ende fehlt; das ist in der commandref auch leicht zu übersehen...:
define wd_NAS_lebt watchdog NAS_lebt:warten 00:00:03 NAS_lebt:alive set NAS_lebt stoerung;; trigger wd_NAS_lebt .
Was mir dann noch nicht klar ist: Warum setzt du den Dummy (?) dann (nur) auf stoerung und versendest nicht gleich (noch zusätzlich) die Nachricht?

Für weitere Hilfestellung bitte ggf. noch die entsprechenden Events aus dem Event-Monitor nachliefern.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ahilger1306

Hi Beta-User,

danke für die Hilfe...der Trick mit dem Event Handler hat mir geholfen.

Zitat
Zum einen: uralt-Beiträge aufwärmen, die irgendwie auch keine abschließende Lösung anbieten. Da liegt doch der Schluß nahe, dass die verwendete Syntax nicht paßt  .

Du hast schon recht...ich wollte den einfach recyceln und deswegen nicht extra einen neuen aufmachen. Ich weiß für die Zukunft bescheid.


Zitat
Was mir dann noch nicht klar ist: Warum setzt du den Dummy (?) dann (nur) auf stoerung und versendest nicht gleich (noch zusätzlich) die Nachricht?

Das war nur zwecks Test. Da es jetzt läuft kommt da der Versand einer Nachricht über Pushover rein.


Mit dem Code hat es jetzt funktioniert.
Danke

defmod NAS_lebt_watchdog_2 watchdog NAS_lebt:warten 00:00:20 NAS_lebt:alive {fhem("SET NAS_lebt dasistmist")}
attr NAS_lebt_watchdog_2 autoRestart 1
attr NAS_lebt_watchdog_2 room System

setstate NAS_lebt_watchdog_2 defined
setstate NAS_lebt_watchdog_2 2018-05-25 10:07:50 Activated activated
setstate NAS_lebt_watchdog_2 2018-05-25 10:05:17 Triggered triggered