Watchdog mit Tasmota

[micky0867]

Nachdem sich mein FHEM-Server letzte Nacht aufgehangen hat und nur durch ein-/ausschalten wieder beleben ließ, habe ich mir Gedanken um eine entsprechende Überwachung gemacht.
Da ich keinen Raspi o.ä. mit bereits vorbereitetem Watchdog habe, musste eine andere Lösung her.
Zunächst war da der Gedanke, noch einen Rechner zu installieren, der per Funk/Wifi eine Steckdose schaltet, wenn der FHEM-Server nicht funktioniert.
Ich hätte da sogar noch eine Tasmota-Steckdose rumliegen.....

Aber wozu noch einen Rechner laufen lassen, wenn ich Tasmota auf meine Bedürfnisse anpassen könnte?
Also habe ich mir meine Gedanken für einen entsprechenden Patch gemacht.
Zum Glück habe ich aber vorher nochmal einen Blick in die Doku geworfen und erfreut festgestellt, dass eigentlich alles da ist, was ich brauche!

Im ersten Schritt habe ich eine Regel erstellt, die bei einem Event vom Typ Rules#Timer den Strom abschaltet, 10 Sekunden wartet und wieder einschaltet.
Der Rules#Timer-Event wiederum wird in einem zweiten Schritt initialisiert.
Bei diesem zweiten Schritt wird z.B. festgelegt, dass der Event nach einem Countdown von 10 Minuten feuern soll.
Damit wird nach 10 Minuten der Strom ab- und wieder eingeschaltet.
Wenn man jetzt den Countdown immer wieder neu festlegt, z.B. alle 2 Minuten, überschreibt man die vorhergehende Definition immer wieder, wodurch der Timer nie abläuft....außer....
der Rechner hängt oder das Wifi funktioniert nicht.
Da der Timer nur genau einmal ablaufen kann, hat der Server im Anschluß genug Zeit neu zu starten, bevor die Automatisierung den Timer neu aktiviert

Zum Einbinden gibt es zwei Möglichkeiten: Betriebssystem und FHEM

Ich bevorzuge das Betriebssystem, da ich die Funktionalität von FHEM sowieso schon überwache und ggf. neu starte.
FHEM bietet sich an, falls man es sonst nicht überwachen kann.

Hier ist das Script für's Betriebssytem (curl wird vorausgesetzt):

Code Auswählen Erweitern


#! /bin/bash

USERNAME=admin
PASSWORD=
SONOFFIP=192.168.178.100
RULE=1
RELAY=1
OFFSEC=10
INTERVAL=600


PATH=/bin:/usr/bin:/usr/local/bin:$PATH

if [ ! -z "$PASSWORD" ]; then
  CREDENTIALS="user=${USERNAME}&password=${PASSWORD}&"
fi


# Initialisierung
if [ "$1" == "-i" ]; then
  curl "http://${SONOFFIP}/cm?${CREDENTIALS}cmnd=Rule${RULE}%20on%20Rules%23Timer%3D${RULE}%20do%20backlog%20Power%20OFF%3B%20Delay%20${OFFSEC}%3B%20Power%20ON%20endon"
fi

# Watchdog fuettern
if [ "$1" == "-f" ]; then
  curl -k "http://${SONOFFIP}/cm?${CREDENTIALS}cmnd=RuleTimer${RULE}%20${INTERVAL}"
fi

# Watchdog aktivieren
if [ "$1" == "-a" ]; then
  curl -k "http://${SONOFFIP}/cm?${CREDENTIALS}cmnd=Rule${RULE}%201"
fi

# Watchdog deaktivieren
if [ "$1" == "-d" ]; then
  curl -k "http://${SONOFFIP}/cm?${CREDENTIALS}cmnd=Rule${RULE}%200"
fi

Das Script muss einmal mit dem Parameter -i aufgerufen werden, um die Regel im Sonoff zu konfigurieren.
Danach muss man per crontab alle x Minuten das Script mit dem Parameter -f aufrufen, damit der Watchdog nicht abläuft.
Mit den Parametern -a bzw. -d kann man den Watchdog aktivieren und deaktivieren.


In FHEM kann man den Aufruf per HTTPMOD steuern.

Code Auswählen Erweitern


define WDog HTTPMOD http://192.168.178.100/cm?cmnd=RuleTimer1%20600 120
attr WDog get0Name Initialize
attr WDog get0URL http://192.168.178.100/cm?cmnd=Rule1%20on%20Rules#Timer=1%20do%20backlog%20Power%20OFF;;%20Delay%2010;;%20Power%20ON%20endon
attr WDog get1Name Enable
attr WDog get1URL http://192.168.178.100/cm?cmnd=Rule1%201
attr WDog get2Name Disable
attr WDog get2URL http://192.168.178.100/cm?cmnd=Rule1%200
attr WDog reading0JSON Rule1
attr WDog reading1JSON T1
attr WDog requestHeader1 Content-Type: application/json
attr WDog requestHeader2 Accept: */*
attr WDog stateFormat Rule1

Die komischen Zeichen "%20" sind eigentlich Leerzeichen, allerdings kann HTTMOD diese scheinbar nicht automatisch ersetzen.
Die Zeile mit dem define liest sich also als "define ... RuleTimer1 600 120"

Hier muss man einmal ein "get Initialize" machen, damit der Sonoff konfiguriert wird.

Micky

[bartman121]

Ich halte es für wahnsinnig einen Linux-Rechner wegen eines abgestürzten Programmes einfach hart vom Netz zunehmen.

Die richtige Vorgehensweise wäre es die Ursache des Problems zu finden und diese zu beseitigen. Danach das Programm geordnet wieder zu starten. Das geht auch meist ohne Neustart.

Einfach Strom abschalten zerballert Dir im schlimmsten Fall das Dateisystem. *Kopfschüttel*

[micky0867]

Ich halte es für wahnsinnig einen Linux-Rechner wegen eines abgestürzten Programmes einfach hart vom Netz zunehmen.

Mit FHEM-Server meinte ich nicht FHEM selbst, sondern das OS.
....und jetzt erklär mir bitte noch, warum es dann überhaupt eine Watchdog für den Raspi gibt und wie der denn das Dateisystem syncen soll.....

Grundsätzlich gebe ich dir in gewissem Maße Recht....aber ein journalisiertes Dateisystem verträgt schon eine ganze Menge, und manchmal gibt es halt keinen anderen Weg....insbesondere dann nicht, wenn ich im Urlaub bin, und meine Hausautomation nicht will.

[bartman121]

Ich habe meine feste Meinung dazu, das Abschalten des Stromes darf in keinem Fall automatisch erfolgen. Das kann man als finalen Versuch gern manuell machen(vpn->tasmota).

Ein watchdog dient dazu Programme/Dienste zu überwachen und beim Absturz des Programmes vernünftige Aktionen auszuführen (z. B. ALLE AKTOREN IN SAFE-POSITION ZU FAHREN).

Es ist völlig okay was du selbst für vernünftig hältst, aber hier unbedarfte User zu animieren einen raspi ohne sinnvollen Grund hart ab- und wieder anzuschalten halte ich für sehr schlecht.

[micky0867]

einen raspi ohne sinnvollen Grund hart ab- und wieder anzuschalten

mich deucht, du hast entweder den ersten Post nicht gelesen, oder nicht verstanden

Ich habe keinen Raspi (der tatsächlich einen Watchdog hat, der aber eben keine Dienste, sondern ein OS überwacht)
Aufgabe eines Watchdog: https://de.wikipedia.org/wiki/Watchdog
Im Allgemeinen ist das ein HW-Reset, da fährt nix mehr in SAFE-Position
Das Überwachen und der Restart eines nicht funktionierenden Dienstes wird Monitoring und nicht Watchdog genannt.

Ich kam nicht auf mein System - gar nicht (und glaub mir, ich mache seit mehr als 25 Jahren Unix)
Der sinnvolle Grund liegt im jeweiligen Ermessen, wenn du nicht darauf angewiesen bist, dass dein Fhem bzw. das OS läuft, ist das OK.
Das mit dem VPN ist toll....sofern man im Urlaub mitbekommt, dass was nicht stimmt...und Zugriff hat....schonmal ne Kreuzfahrt gemacht oder in der tiefsten Eifel gewesen?

Und es gab/gibt sogar eine Clustertechnik, die sowas nutzt....ich muss dabei allerdings eingestehen, dass ich das selbst für keine gute Idee halte, wenn sich die Systeme gegenseitig abschalten können, da bin ich dann doch der Verfechter des Computer-Suizids mittels Kernel-Panic.
https://de.wikipedia.org/wiki/STONITH

So, jetzt haben die unbedarften User wohl genug Pro- und Contra um selbst zu entscheiden.
Wobei ich jedem zum Raspi-Watchdog raten würde....allerdings würde ich auch jedem vom Raspi abraten, da die standardmäßige SD-Karte die beste Voraussetzung für ein defektes Dateisystem ist.
Wenn dann schon einen Banana-PI, der hat auch einen Watchdog und SATA.