Watchdog für DoorPi

Hast du es bei dir schon eingebunden?
Die Idee ist echt gut.

Hab ich mir auch schon gedanken zu gemacht.
Ich muss mich noch drum Kümmern, dass ich per Pushover die Meldungen bekomme.

Hm in der Anleitung steht aber nur wie der Watchdog eingeschaltet wird oder? Ich habe das bei mir schon so gemacht und micht seitdem nicht mehr damit beschäftigt.
Jetzt müsste man aber noch etwas machen, dass man auch informiert wird, wenn etwas passiert.

Was ich bei mir gemacht habe, ich schicke mir eine Pushover Message wenn DoorPi gestoppt und gestartet wird (dafür gibt es Events im DoorPi). Der Watchdog zieht aber vermutlich einfach an der Reset Leitung, d.h. er fährt das System nicht sauber runter, oder doch? Ich würde aber zumindest sicherlich die Meldung bekommen, dass DoorPi gestartet wurde.

Ich denke, daß man hier als fhem-Nuter ganz gut fhem zusätzlich nutzen könnte (zumindest für eine Warnung).

Per fhem periodisch eine Aktion auf doorpi ausführen, die ihrerseits wieder in fhem etwas macht (zb einen dummy verändert).
Bei Ausbleiben der Aktion könnte man dann in fhem entsprechend reagieren (aber das ist natürlich hier ein wenig OT)....

Zitat

Nene, der Watchdog muss nicht zu einem Neustart führen. Auf der zweiten Seite ist beschrieben, wie mit einem kleinen Skript beliebige Aktionen ausgelöst werden können, die zum Reparieren einer unerwünschten Situation führen.

Ok, aber auf Seite 1 verstehe ich es so dass ein Reboot konfiguriert wird, wenn hohe Systemlast auftritt.
Und auf Seite 2 stehen Alternativen dazu, richtig?

Ich frage mich nur ob in dem Reboot-Fall mit der max-load ein geordneter Shutdown durchgeführt wird, oder einfach die Resetleitung gezogen wird. Ich würde mal von ersterem ausgehen

Siehe:
http://www.doorpi.org/forum/th…dog/?postID=1871#post1871

Hmm, klingt nicht schlecht den watchdog so für die Überwachung des DoorPi zu vergewaltigen.

Aber ich setze lieber auf Icinga. Ich habe einen zweiten Raspberry in meinem Heimnetz, welcher diverse Aufgaben hat.
Auf diesem ist unter anderem auch Icinga installiert, womit ich alle meine Geräte zuhause überwache.
z.B. Router, Fritzbox, DoorPi, Access-Points, NAS, etc.
Vor allem auch den Plattenplatz auf den Systemen und diverse Dienste, welche dort laufen. Ich werde per E-Mail benachrichtigt wenn etwas ausfällt (man kann aber auch ein GSM-Modem anbinden).
Dazu ein Dashboard mit allen Zuständen und Statistiken. Das passiert alles mit aktiven und passiven Checkern.

Icinga lässt sich sogar auf dem Raspberry Pi dazu installieren auf dem DoorPi selbst läuft. Ich würde den dann aber nicht mit WLAN anbbinden.

Trotzdem finde ich die Idee mit dem watchdog gut und wenn man nur DoorPi selbst überwachen möchte, ist das sicherlich eine gute und einfache Alternative.
Nur wenn der Pi komplett ausfällt, dann ist Ende! Aber das wäre natürlich auch der Fall wenn Icinga darauf läuft.

Ich habe mich erst seit kurzem mit dem Thema Watchdog und was da hintendran hängt befasst. Eigentlich erst wirklich seit @pahenning diesen Auschnitt aus seinem Buch gepostet hat dafür nochmal danke.

Dieses Programm Icinga werde ich mir auch mal anschauen, danke.

Das Ganze sollte doch relativ einfach möglich sein, indem der Watchdog auf dem Raspi die aktuelle log-Datei des DoorPi überprüft. Diese wird ja regelmäßig aktualisiert. Dann müsste man beim Ausbleiben einer Reaktion noch gezielt den DoorPi per "sudo service doorpi restart" neu starten.

Wie Joker, so lasse auch ich mir beim Beenden und Starten des DoorPi eine Push-Nachricht senden. Die entsprechenden Einträge in der doorpi.ini sehen bei mir folgendermaßen aus:

[EVENT_AfterShutdown]
10 = os_execute:/usr/local/etc/DoorPi/scripts/StopDoorPi.sh


[EVENT_OnStartup]
10 = sleep:1


[EVENT_AfterStartup]
10 = os_execute:/usr/local/etc/DoorPi/scripts/StartDoorPi.sh

Sie rufen jeweils ein kleines Shellskript auf, mit dem ich mir die Push-Nachrichten per Telegram senden lasse. Gleichzeitig frage ich auch noch den Anwesenheitszustand meiner HomeMatic ab, um mir die Push-Nachrichten je nach Anwesenheit oder Abwesenheit mit unterschiedlicher Prio zuzusenden.

#!/bin/bash
HMinfo1=xxxxxxxxx:xxxxxxxxxxxxxxxxxxxxx # Telegram Bot Token "HomeMatic Info" 
ChatId1=xxxxxxxxxxx # Telegram Chat-ID


curl -s -k "https://api.telegram.org/bot${HMinfo1}/sendMessage" -d text="DoorPi gestartet." -d chat_id=$ChatId1


exit 0

#!/bin/bash
CCU_IP=192.168.0.20 # IP-Adresse der CCU
LBoxPi_IP=192.168.0.21 # IP-Adresse des LBoxPi


HMinfo1=xxxxxxxxx:xxxxxxxxxxxxxxxxxxxxx # Telegram Bot Token "HomeMatic Warnung"
HMwarnung1=xxxxxxxxx:xxxxxxxxxxxxxxxxxxxxx # Telegram Bot Token "HomeMatic Warnung"
ChatId1=xxxxxxxxx # Telegram Chat-ID


# CCU-Systemvariable "Haus SV Anwesendheit" (ise_id: 34197) auslesen
present=$(curl -s -k "http://${CCU_IP}:8181/rega.exe?x=dom.GetObject(34197).Value()")
present=${present##*<x>}
present=${present%%</x>*}
# echo $present


if [ "$present" == "true" ] # Anwesenheit
  then
    curl -s -k "https://api.telegram.org/bot${HMinfo1}/sendMessage" -d text="<b>Achtung, DoorPi gestoppt!</b>" -d chat_id=$ChatId1 -d parse_mode=html
elif [ "$present" == "false" ] # Abwesenheit
  then
    curl -s -k "https://api.telegram.org/bot${HMwarnung1}/sendMessage" -d text="<b>Achtung, DoorPi gestoppt!</b>" -d chat_id=$ChatId1 -d parse_mode=html
fi


exit 0

Sowas müsste sich ja eigentlich auch ganz gut mit dem Watchdog realisieren lassen.

Gruß,

Thorsten

Ah, okay. Meine DoorPi-Log-Datei wird regelmäßig mit der IP-Adresse des Raspis und dem Port befüllt. Daher ging ich davon aus, dass man diese entsprechend auslesen kann. Aber das mit dem Event statuswatchdog ist ja dann eindeutig die bessere Alternative.

Gruß,

Thorsten