Fhem über Nacht abschalten?

CoolTux · 27 April 2020, 07:52:17

disableForInterval habe ich in meine ToDo aufgenommen und ich schaue ob UWZ tatsächlich blockiert. Im Normalen Abrufbetrieb dürfte das nicht sein. Wo bei ich mir bei den Karten unsicher bin. Aber wird etwas dauern, irgendwie haben alle zu viel Zeit und melden Wünsche

Himi · 28 April 2020, 09:14:56

Ich habe das Problem vorübergehend über Crontab im Raspberry Pi gelöst.

der Eintrag in Crontab lautet:

55 23 * * * sudo systemctl stop fhem
10 6 * * * sudo systemctl start fhem

Fhem wird in der zweiten Nachthälfte angehalten, da benötige ich keine aktuellen Daten.
Gerne warte ich auf die Integration disableForInterval im Modul UVZ von CoolTux.

Danke für Eure Tipps

MadMax-FHEM · 28 April 2020, 09:47:39

Hast du Funksensoren im Einsatz!?

Wenn ja, dann beachten, dass die gegebenenfalls "beleidigt" sind, wenn sie die Zentrale nicht erreichen können und gegebenenfalls mehrfach senden/wiederholen...

Warum nicht nur per telnet, HTTP-Request oder IN fhem (Stichwort at) einfach das Modul disablen: attr Modul disable 1

Ja unschön wegen "Konfig-Änderung" aber evtl. "schöner" als fhem komplett zu beenden...

Aber: dein System, deine (Funk)Umgebung, ...

Gruß, Joachim

KölnSolar · 28 April 2020, 12:39:39

Zitataber evtl. "schöner" als fhem komplett zu beenden...

und nicht nur schöner. Vielleicht stellt sich heraus, dass es gar nicht am UWZ liegt.

Nur weil in dem seeeeehr kurzen Logauszug (verbose=0

?) das UWZ als letztes steht ?

Grüße Markus

MadMax-FHEM · 28 April 2020, 12:44:34

Zitat von: KölnSolar am 28 April 2020, 12:39:39
und nicht nur schöner. Vielleicht stellt sich heraus, dass es gar nicht am UWZ liegt. Nur weil in dem seeeeehr kurzen Logauszug (verbose=0 ?) das UWZ als letztes steht ?

Grüße Markus

Auch steht die Antwort darauf noch aus (oder)!?

Zitat von: Frank_Huber am 26 April 2020, 09:53:53
Vermute der wetterabruf.
Weitere Vermutung, das DNS Server Attribut ist im global nicht gesetzt.

Gesendet von meinem S68Pro mit Tapatalk

Damit dürfte es zumindest nicht so lange hängen...
...außer die "Abfragen" (HTTP-Requests!?) wurden "blocking" implementiert...

Gruß, Joachim

herrmannj · 28 April 2020, 13:08:16

Naja, im geposteten log steht

Code Auswählen

malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Error|Error http://f...") at ./FHEM/77_UWZ.pm line 1102.

Ein String mit dem Inhalt "Error|Error http://f..." wird in #1102 verfüttert an:

Code Auswählen

my $uwz_warnings = JSON->new->ascii->decode($response);

Pflichtschuldig verabschiedet sich JSON (vmtl je nach Version) damit. Systemd (vmtl) startet fhem nach einiger Zeit neu. Das Verhalten passt logisch auch wenn die Diagnose sicher nicht final ist.

KölnSolar · 28 April 2020, 13:31:45

Zitat2020.04.16 11:51:09 1: Nina NinaTest: JSONAcquire.607 Error: Can't get https://warnung.bund.de/bbk.dwd/unwetter.json -- https://warnung.bund.de/bbk.dwd/unwetter.json: Can't connect(2) to https://warnung.bund.de:443: SSL wants a read first
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<html>\r\n<head><tit...") at ./FHEM/77_Nina.pm line 337.

in #337

Code Auswählen

$Nina_warnings = JSON->new->ascii->decode($response);
Ist meines Erachtens dieselbe Situation, aber kein Absturz bzw. restart von FHEM.
Evtl.

ZitatJSON (vmtl je nach Version)

herrmannj · 28 April 2020, 13:56:46

Cooltux wird das klären soblad er den Freiraum dazu hat

CoolTux · 28 April 2020, 14:40:27

Hatte er. Ich habe UWZ komplett auf PBP umgestellt und habe mich dann auch gleich an die Fehlerbearbeitung gemacht. Davon gab es nämlich bisher genau Null. Oder besser es gab eine aber die war Halbherzig, siehe Fehler weiter oben

Ich biete die aktuelle Version im UWZ Thread zum testen an.

https://forum.fhem.de/index.php/topic,51233.msg1047942.html#msg1047942