OWX kann FHEM abschiessen ?!?

Begonnen von cwagner, 06 Dezember 2013, 23:30:41

Vorheriges Thema - Nächstes Thema

Petrosilius Zwackelmann

ZitatZum Testen reicht den FHEM zu beenden. Solle nach ca. 1 Minute wieder anlaufen und bald darauf wieder ansprechbar sein.

Landet man da nicht in diesem Programmteil, in welchem kein Neustart erfolgt, oder habe ich da was falsch verstanden...?

else
    # Server abgestürzt, Prozess nicht (mehr) vorhanden.
    log "MSG: no FHEM Server process found";
    #log "S: dead";
    return 1;



Gruß Manuel
FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

hexenmeister

Ja, aber das ist ein 'Unterprogram' (checkAlive), dieses wird weiter unten aufgerufen und ggf. (bei return 1) wird dort auch der Server restartet.

if ( checkAlive )
then
print "Server alive";
else
# TODO: Pruefen, ob FHEM gerade Update durchführt (dauert ca. 15 min. auf einer FB)
print "Server dead";
# FHEM PID suchen
pid=$(ps -ef | grep -v grep | grep fhem.pl | cut -c10-14);
if test $pid
then
print "killing FHEM. PID: $pid";
   log "MSG: killing FHEM PID: $pid";
   # Prozess beenden
   kill $pid;
   # Etwas warten
   sleep 3;
   # Wenn nicht beendet - hart terminieren
   kill -9 $pid;
fi
# FHEM neu starten
print "restarting FHEM";
./startfhem &
# Etwas Zeit zum Starten lassen.
sleep 120;
fi
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

@Moderator:
Das Thema hier 'driftet' immer weiter weg und hat gar nichts mehr mit 1wire zu tun.
Da es jedoch nicht ganz uninteressant zu sein scheint, würde ich vorschlagen, den Thread umzubenennen und (nach 'Sonstiges'?) zu verschieben.

Grüße,

Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Spezialtrick


ZitatPlots erlauben zwar den Überblick über die Ausfälle, sind jedoch eher 'Zierde' ;)

Sieht aber gut aus. :P

ZitatWichtig wäre zu prüfen, ob Watchdog den FHEM-Server bei Bedarf auch starten kann. Zum Testen reicht den FHEM zu beenden. Solle nach ca. 1 Minute wieder anlaufen und bald darauf wieder ansprechbar sein.

Ich habe FHEM beendet und es wird leider nicht neugestartet. :( Hier ist die Ausgabe von watchdog-2014-01.log:

2014-01-10_09:40:05 fhem_server V: 4 S: alive MSG: FHEM Server alive
2014-01-10_09:41:05 fhem_server MSG: no FHEM Server process found
2014-01-10_09:44:05 fhem_server MSG: no FHEM Server process found
2014-01-10_09:47:05 fhem_server MSG: no FHEM Server process found
2014-01-10_09:50:06 fhem_server MSG: no FHEM Server process found
2014-01-10_09:53:06 fhem_server MSG: no FHEM Server process found
2014-01-10_09:56:06 fhem_server MSG: no FHEM Server process found
2014-01-10_09:59:06 fhem_server MSG: no FHEM Server process found
2014-01-10_10:02:07 fhem_server MSG: no FHEM Server process found
2014-01-10_10:05:07 fhem_server MSG: no FHEM Server process found
2014-01-10_10:08:07 fhem_server MSG: no FHEM Server process found
2014-01-10_10:11:08 fhem_server MSG: no FHEM Server process found
2014-01-10_10:14:08 fhem_server V: 1988 S: dead MSG: no response from FHEM Server for 1988 sekonds
2014-01-10_10:14:09 fhem_server MSG: killing FHEM PID: 21201
2014-01-10_10:17:25 fhem_server MSG: starting watchdog
2014-01-10_10:17:26 fhem_server MSG: FHEM not runing. starting FHEM...


ZitatWie sehen die Definitionen für Plots in fhem.cfg? Da Du die Logs umbenannt hat, müssen auch diese Einstellungen entsprechend angepasst werden.

Habe Sie von dir kopiert und nur die Log Namen geändert. So sehen sie aus:

# Definition eines Dummy-Objektes fuer 'Alive'-Meldungen
define Server_Heartbeat dummy
attr Server_Heartbeat group Watchdog
attr Server_Heartbeat room Fhem
attr Server_Heartbeat userReadings lastChange { CurrentTime() }
# Protokoliert Zeitpunkt der letzten Änderung (in Objekt-Eigenshaften)
# Definition der Log-Datei
define FileLog_Server_Heartbeat FileLog ./log/Server_Heartbeat-%Y-%m.log Server_Heartbeat
attr FileLog_Server_Heartbeat group Watchdog
attr FileLog_Server_Heartbeat logtype myServerHeartbeat:Plot,text
attr FileLog_Server_Heartbeat room Fhem
# Visualisierung mittels eines Diagramms
define 0.wlHeartbeat SVG FileLog_Server_Heartbeat:myServerHeartbeat:CURRENT
attr 0.wlHeartbeat group Watchdog
attr 0.wlHeartbeat room Fhem

# Routine zur regelmaessigen Änderungen des Wertes des Dummy-Objektes
define tickHeartbeat at +*00:01:00 {tickHeartbeat('Server_Heartbeat');;}
attr tickHeartbeat alignTime 00:00
attr tickHeartbeat group Watchdog
attr tickHeartbeat room Fhem
# Log-Datei des Watchdogscriptes verfügbar machen
define FileLog_wathdog FileLog ./log/watchdog.log fakelog
attr FileLog_wathdog group Watchdog
attr FileLog_wathdog room Fhem

# Visualisierung für Watchdog-Log
define 0.wlWatchdog SVG FileLog_wathdog:myWatchdog:CURRENT
attr 0.wlWatchdog group Watchdog
attr 0.wlWatchdog room Fhem


Danke schonmal für deine Hilfe! :)


Zitat@Moderator:
Das Thema hier 'driftet' immer weiter weg und hat gar nichts mehr mit 1wire zu tun.
Da es jedoch nicht ganz uninteressant zu sein scheint, würde ich vorschlagen, den Thread umzubenennen und (nach 'Sonstiges'?) zu verschieben.

Grüße,

Alexander

Das Thema ist super interessant und sollte meines Erachtens "serienmäßig" in FHEM implementiert sein! :)
FHEM - Debmatic - Zigbee2MQTT - Homekit

Petrosilius Zwackelmann

Zitat von: hexenmeister am 07 Dezember 2013, 23:32:11
Hallo Manuel,

wirf die Return-Anweisung ganz raus, ist hier nicht wesentlich (und funktioniert je so nicht).
Script scheint auch die 'Lebenszeichen' des FHEM-Servers zu erkennen.
Bei der letzten Meldung, hast Du den FHEM selbst beendet, oder wieso wurde dieser als 'dead' eingestufft?
Es scheint mit dem Beenden auch nicht funktioniert zu haben. Ein Rechteproblem? Kann der Benutzer, unter dessen Rechten die Scripte laufen, den FHEM stoppen? Ist er in die sudo-Gruppe aufgenommen und sudoers entsprechend ergänzt?

Alternativ kann man versuchen aus den startfhem und stopfhem Schripten die sudos zu entfernen. Wenn die Benutzer richtige Rechte haben, wird es auch so reichen, ohne sudo-Gruppe etc.

LG

Alexander

Ich hatte die Return Anweisungen wegen Fehlermeldungen rausgeworfen...
Hast du einen Ansatz wie man das Skript für andere Systeme kompatibel machen kann?

Ein Restart dann aber nicht wenn der Prozess komplett beendet ist. Ein restart sollte aber theoretisch finktonieren wenn FEHEM dauerhaft einfriert... Bisher war mir aber nicht klar wie ich das hervorrufen kann. Vielleicht ein sleep 600 irgendwo einbauen.

Gruß Manuel
FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

Petrosilius Zwackelmann


Ein billiges {sleep xxx} in der Kommandozeile reicht...
manchmal sieht man den Wald vor lauter Hexenhäuschen nicht  :D

Gruß Manuel
FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

hexenmeister

ZitatIch habe FHEM beendet und es wird leider nicht neugestartet.
Das sieht mit nach Rechteproblem aus. Denn im Log sieht man, dass es versucht wird, FHEM neu zu starten.
2014-01-10_10:17:26 fhem_server MSG: FHEM not runing. starting FHEM...
Unter welchem User laufen Watchdog und FHEM? Hat dieser benötigte Rechte? Wird denn FHEM gestartet, wenn man  ./startfhem & eingibt (mit Rechten diesen Users)?

ZitatHabe Sie von dir kopiert und nur die Log Namen geändert. So sehen sie aus:
Schon komisch, sieht aus den ersten Blick richtig aus. Die Daten waren doch auch ok im Log, oder? Dumme Frage: die Methode CurrentTime() hast Du in Deinem 99_myUtils (oder so) schon drin?

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

ZitatIch hatte die Return Anweisungen wegen Fehlermeldungen rausgeworfen...
Hast du einen Ansatz wie man das Skript für andere Systeme kompatibel machen kann?

Ja, der Script ist etwas 'dirty', bin leider kein großer Bash-Kenner. Vor allem die Erkennung von PID ist nicht allgemeingültig. Um das zu machen, bräuchte ich Hilfe (oder viel Zeit zum einlesen, die ich leider nicht habe).

Manuel, wir haben ja an Deiner Version viel rungeschraubt, kanns Du mir sie bitte geben, ich könnte zumindest versuchen, eine gemeinsame Version für Rasp/QNAP/FritzBox zu erstellen.


Zitatmanchmal sieht man den Wald vor lauter Hexenhäuschen nicht  :D
;D*lol*
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Petrosilius Zwackelmann

FHEM 6 auf RaspPi V3:
HM_LAN / CUNX / HUEBridge /OneWire / Homebridge / SONOS / Harmony

Spezialtrick

Zitat
Das sieht mit nach Rechteproblem aus. Denn im Log sieht man, dass es versucht wird, FHEM neu zu starten.
2014-01-10_10:17:26 fhem_server MSG: FHEM not runing. starting FHEM...

Wie kann ich die Rechte denn genau festlegen?


ZitatUnter welchem User laufen Watchdog und FHEM? Hat dieser benötigte Rechte? Wird denn FHEM gestartet, wenn man  ./startfhem & eingibt (mit Rechten diesen Users)?

Es sieht so aus als würde FHEM auch unter dem Benutzer FHEM laufen, oder?

root@raspberrypi:~# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 19:19 ?        00:00:01 init [2] 
root         2     0  0 19:19 ?        00:00:00 [kthreadd]
root         3     2  0 19:19 ?        00:00:00 [ksoftirqd/0]
root         5     2  0 19:19 ?        00:00:00 [kworker/0:0H]
root         6     2  0 19:19 ?        00:00:00 [kworker/u2:0]
root         7     2  0 19:19 ?        00:00:00 [rcu_preempt]
root         8     2  0 19:19 ?        00:00:00 [rcu_bh]
root         9     2  0 19:19 ?        00:00:00 [rcu_sched]
root        10     2  0 19:19 ?        00:00:00 [khelper]
root        11     2  0 19:19 ?        00:00:00 [kdevtmpfs]
root        12     2  0 19:19 ?        00:00:00 [netns]
root        13     2  0 19:19 ?        00:00:00 [kworker/0:1]
root        14     2  0 19:19 ?        00:00:00 [writeback]
root        15     2  0 19:19 ?        00:00:00 [bioset]
root        16     2  0 19:19 ?        00:00:00 [kblockd]
root        17     2  0 19:19 ?        00:00:00 [khubd]
root        18     2  0 19:19 ?        00:00:00 [rpciod]
root        19     2  0 19:19 ?        00:00:00 [khungtaskd]
root        20     2  0 19:19 ?        00:00:00 [kswapd0]
root        21     2  0 19:19 ?        00:00:00 [fsnotify_mark]
root        22     2  0 19:19 ?        00:00:00 [nfsiod]
root        23     2  0 19:19 ?        00:00:00 [crypto]
root        29     2  0 19:19 ?        00:00:00 [kthrotld]
root        30     2  0 19:19 ?        00:00:00 [VCHIQ-0]
root        31     2  0 19:19 ?        00:00:00 [VCHIQr-0]
root        32     2  0 19:19 ?        00:00:00 [VCHIQs-0]
root        33     2  0 19:19 ?        00:00:00 [iscsi_eh]
root        34     2  0 19:19 ?        00:00:00 [dwc_otg]
root        35     2  0 19:19 ?        00:00:00 [DWC Notificatio]
root        37     2  0 19:19 ?        00:00:00 [deferwq]
root        38     2  0 19:19 ?        00:00:00 [kworker/u2:2]
root        39     2  0 19:19 ?        00:00:02 [mmcqd/0]
root        40     2  0 19:19 ?        00:00:00 [jbd2/mmcblk0p2-]
root        41     2  0 19:19 ?        00:00:00 [ext4-dio-unwrit]
root       156     1  0 19:19 ?        00:00:00 udevd --daemon
root       663   156  0 19:20 ?        00:00:00 udevd --daemon
root       664   156  0 19:20 ?        00:00:00 udevd --daemon
root      1586     1  0 19:20 ?        00:00:00 /usr/sbin/ifplugd -i eth0 -q -f
root      1624     1  0 19:20 ?        00:00:00 /usr/sbin/ifplugd -i lo -q -f -u
root      1726     2  0 19:20 ?        00:00:00 [kworker/0:2]
fhem      1832     1  0 19:20 ?        00:00:00 /bin/sh ./watchdogloop.sh
root      1934     1  0 19:20 ?        00:00:00 dhclient -v -pf /run/dhclient.et
fhem      1958     1  1 19:20 ?        00:00:11 perl fhem.pl fhem.cfg
root      1962     1  0 19:20 ?        00:00:00 startpar -f -- fhem
root      1982     1  0 19:20 ?        00:00:00 /usr/sbin/rsyslogd -c5
root      2041     1  0 19:20 ?        00:00:00 /usr/sbin/cron
104       2071     1  0 19:20 ?        00:00:00 /usr/bin/dbus-daemon --system
avahi     2098     1  0 19:20 ?        00:00:00 avahi-daemon: running [raspberry
avahi     2099  2098  0 19:20 ?        00:00:00 avahi-daemon: chroot helper
ntp       2147     1  0 19:20 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.
root      2179     1  0 19:20 ?        00:00:08 /usr/local/sbin/pilight-daemon
root      2215     1  0 19:20 ?        00:00:00 startpar -f -- pilight
root      2224     1  0 19:20 ?        00:00:03 perl /usr/local/bin/shairport.pl
root      2255     1  0 19:20 ?        00:00:00 /usr/sbin/sshd
nobody    2284     1  0 19:20 ?        00:00:00 /usr/sbin/thd --daemon --trigger
root      2291  2255  0 19:20 ?        00:00:00 sshd: root@notty
root      2298     1  0 19:20 tty1     00:00:00 /sbin/getty --noclear 38400 tty1
root      2299     1  0 19:20 tty2     00:00:00 /sbin/getty 38400 tty2
root      2300     1  0 19:20 tty3     00:00:00 /sbin/getty 38400 tty3
root      2301     1  0 19:20 tty4     00:00:00 /sbin/getty 38400 tty4
root      2302     1  0 19:20 tty5     00:00:00 /sbin/getty 38400 tty5
root      2303     1  0 19:20 tty6     00:00:00 /sbin/getty 38400 tty6
root      2304     1  0 19:20 ttyAMA0  00:00:00 /sbin/getty -L ttyAMA0 115200 vt
root      2307     1  0 19:20 ?        00:00:00 /usr/sbin/console-kit-daemon --n
root      2374     1  0 19:20 ?        00:00:00 /usr/lib/policykit-1/polkitd --n
root      2380  2291  0 19:20 ?        00:00:00 /usr/lib/openssh/sftp-server
root      2383  2224  0 19:20 ?        00:00:00 avahi-publish-service C279C1EF3F
fhem      2741  1832  0 19:35 ?        00:00:00 sleep 60
root      2742  2255  8 19:35 ?        00:00:00 sshd: root@pts/2
root      2749  2742 19 19:35 pts/2    00:00:00 -bash
root      2757  2749  0 19:35 pts/2    00:00:00 ps -ef


Mit "./startfhem" kann ich FHEM starten. Allerdings nur, wenn mit dem ROOT eingeloggt bin. Zuerst wird mir ausgegeben, dass der Watchdog schon läuft und dann, dass FHEM gestartet wird, soweit es nicht sowieso schon läuft. Das Passwort des Nutzer FHEM kenne ich nicht und habe ich auch nie vergeben.

ZitatSchon komisch, sieht aus den ersten Blick richtig aus. Die Daten waren doch auch ok im Log, oder? Dumme Frage: die Methode CurrentTime() hast Du in Deinem 99_myUtils (oder so) schon drin?

Ja das habe ich. Habe es ebenfalls von Dir an das Ende der 99_myUtils kopiert. Schaut so aus:

# Liefert aktueller Zeitstempel
sub
CurrentTime()
{
  return strftime("%H:%M:%S", localtime());
}

# --- server heartbeat / watchdog ---
sub tickHeartbeat($)
{
    my ($device) = @_;
    my $v = int(Value($device));
    $v = $v+1;
    if($v>=60) {$v=0;}
    fhem("set $device $v");
}


Eigentlich scheint ja alles richtig zu sein bis auf die Rechte Vergabe. :(
FHEM - Debmatic - Zigbee2MQTT - Homekit

hexenmeister

ZitatEs sieht so aus als würde FHEM auch unter dem Benutzer FHEM laufen, oder?
jep. ist auch gut so. Ich denke, das Problem werden sudo-Befehle in den start-Scripten sein. Diese habe ich reingeschrieben, um mit Sicherheit FHEM beenden zu können. Dafür müssen aber die Rechte für den FHEM-User vergeben werden (in /etc/sudoers). Entweder Du nimmst die sudos raus (in startfhem und stopfhem) oder Du machst das, was ich auf meiner Seite beschrieben habe:
ZitatIch habe den Benutzer fhem in die Gruppe sudo aufgenommen. Damit will ich sicherstellen, dass der Script in der Lage ist, volle Kontrolle über den FHEM-Server auszuüben, auch dann, wenn dieser unter einem anderen Benutzeraccount gestartet sein sollte.

sudo usermod -aG sudo fhem

Um keine Sicherheitslücke aufzumachen, bekommt dieser Benutzer Rechte zur Ausführung mit sudo nur für ganz bestimmte Scripte. Dies geschieht durch Einfügen einer Zeile in die Datei sudoers (sudo nano /etc/sudoers).

fhem ALL=(ALL) NOPASSWD: /opt/fhem/runwatchdog.sh, /opt/fhem/killwatchdog.sh, /opt/fhem/watchdogloop.sh, /opt/fhem/runfhem.sh, /opt/fhem/killfhem.sh

Möglicherweise kommen die Diagramme nicht, weil die Logdateien dem falschen Benutzer gehören (mit ls -l log/*.log anzigen).
Rechte vergeben (aus dem fhem-root verzeichnis):
sudo chown fhem:fhem log/*.log
sudo chmod a+rw log/*.log

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Spezialtrick

ZitatZitat
Es sieht so aus als würde FHEM auch unter dem Benutzer FHEM laufen, oder?
jep. ist auch gut so. Ich denke, das Problem werden sudo-Befehle in den start-Scripten sein. Diese habe ich reingeschrieben, um mit Sicherheit FHEM beenden zu können. Dafür müssen aber die Rechte für den FHEM-User vergeben werden (in /etc/sudoers). Entweder Du nimmst die sudos raus (in startfhem und stopfhem) oder Du machst das, was ich auf meiner Seite beschrieben habe:
Zitat
Ich habe den Benutzer fhem in die Gruppe sudo aufgenommen. Damit will ich sicherstellen, dass der Script in der Lage ist, volle Kontrolle über den FHEM-Server auszuüben, auch dann, wenn dieser unter einem anderen Benutzeraccount gestartet sein sollte.

sudo usermod -aG sudo fhem

Um keine Sicherheitslücke aufzumachen, bekommt dieser Benutzer Rechte zur Ausführung mit sudo nur für ganz bestimmte Scripte. Dies geschieht durch Einfügen einer Zeile in die Datei sudoers (sudo nano /etc/sudoers).

fhem ALL=(ALL) NOPASSWD: /opt/fhem/runwatchdog.sh, /opt/fhem/killwatchdog.sh, /opt/fhem/watchdogloop.sh, /opt/fhem/runfhem.sh, /opt/fhem/killfhem.sh

Das hatte ich auch direkt am Anfang genauso ausgeführt. Hat auch ohne Fehlermeldung funktioniert. Das ist die Ausgabe von "ls -l log/*.log":

root@raspberrypi:/opt/fhem# ls -l log/*.log
-rw-rw-rw- 1 fhem dialout  276839 Dec 31 20:32 log/fhem-2013-12.log
-rw-rw-rw- 1 fhem dialout  325224 Jan 10 20:28 log/fhem-2014-01.log
-rw-r--r-- 1 fhem dialout  259065 Jan 10 20:41 log/Server_Heartbeat-2014-01.log
-rw-rw-rw- 1 fhem dialout 3087271 Jan 10 20:40 log/sysmon-2014-01.log
-rw-rw-rw- 1 fhem dialout    7154 Dec 31 18:35 log/Tageslicht-2013.log
-rw-rw-rw- 1 fhem dialout    4655 Jan 10 08:43 log/Tageslicht-2014.log
-rw-rw-rw- 1 fhem dialout  129817 Jan 10 20:40 log/watchdog-2014-01.log
-rw-r--r-- 1 root root     130055 Jan 10 20:27 log/watchdog_err.log
-rw-r--r-- 1 fhem dialout       0 Jan  9 19:28 log/watchdog.log


Dieser Befehl "sudo chown fhem:fhem log/*.log" erzeugt eine Fehlermeldungen:

root@raspberrypi:/opt/fhem# sudo chown fhem:fhem log/*.log
chown: invalid group: `fhem:fhem'
root@raspberrypi:/opt/fhem# sudo chmod a+rw log/*.log
FHEM - Debmatic - Zigbee2MQTT - Homekit

Spezialtrick

#42
Ich eben zusätzlich per Cyberduck die Rechte der Log Dateien an die anderen vorhanden Log Dateien angeglichen, sodass alle Logs diese Rechte haben: -rw-rw-rw-  und siehe da FHEM startet plötzlich nach circa einer Minute, wenn man es beendet. :)

Nun fehlt nur noch der untere Plot. :)

Ich habe nun auch hinbekommen, dass zumindest der schwarze Graph angezeigt wird, in dem ich die DEF des Plot von "./log/watchdog.log fakelog" zu "./log/watchdog-%Y-%m.log fakelog" geändert habe. Der Orangene Status Balken fehlt aber leider immer noch.  :-\
FHEM - Debmatic - Zigbee2MQTT - Homekit

hexenmeister

#43
Die Pfade in der Zeile (fhem ALL=(ALL) NOPASSWD: /opt/fhem/runwatchdog.sh, /opt/fhem/killwatchdog.sh, /opt/fhem/watchdogloop.sh, /opt/fhem/runfhem.sh, /opt/fhem/killfhem.sh) sind alle korrekt?
Hm.. aber gut, es scheint ja jetzt zu funktionieren.

Der chown-Befehl, mein Fehler, es soll fhem:root (statt fhem:fhem) heißen, in Deinem Fall noch besser fhem:dialout

Die Rechte in dem Listing waren falsch, die Zuordnung zu root:root auch nicht gut. Hast Du aber ja behoben. Jetzt müsste aber gehen...

Edit: Ich glaube, ich weiß es! Ich habe mir die orangene Farbe in CSS _zusätzlich_ definiert. Ändere bitte in der Daten myWatchdog.gplot l8fill auf l1fill

#
# Anzeige der Watchdog-Log-Informationen
#

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set title 'Watchdog'
set yrange [-10:300]
set y2label "Zeit (s)"

set ytics ("alive" 0, "dead" 1)
set yrange [-0.1:1.1]
set ylabel "Status"

#FileLog 4:\x20V\x3a:0:
#FileLog 6:\x20S\x3a:0:$fld[5]=~"dead"?1:0


plot "<IN>" x1y2 notitle ls l5 lw 0.5 with steps, \
            x1y1 notitle ls l1fill lw 0 with steps
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

@Manuel:
Danke, habe meine Version etwas optimiert und die Teile, wo Anpasung notwendig ist, nach vorne als Variablen verlagert.
Leider ist das keine grundsätzliche Lösung. K.A. wie ich das in Bash-Script machen kann. Man könnte natürlich auch Perl dazu bemühen...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy