Hallo zusammen,
bei mir läuft Fhem seit Jahren stabil auf einen Raspberry Pi.
Die Verbindung zur Fritzbox geht bei mir nur über WLAN.
U.a steuere ich damit meine Heizung (Max-Thermostate / Gartenbewässerung usw.)
Auch frage ich über das Internet Wetterdaten ab.
Nun zu meiner Frage:
Ich möchte über Nacht (00:00 - 06:00 Uhr) das WLAN auf meiner Fritzbox abschalten.
Ich denke, da hängt dann Fhem irgendwie in der Luft, kurz nach 06:00
Uhr startet dann Fhem meistens zwei mal hintereinander neu.
Gibt es hier führ eine saubere Lösung um über Nacht Fhem anzuhalten oder ähnliches?
Besten Dank im Voraus für evt. Tipps
Hallo,
über cron stop und start zu den Zeiten ausführen.
Gruß
Eisix
Falsche Fragestellungen. Richtig: warum hängt fhem "in der Luft?" Fhem, besser die Kernmodule, benötigen kein Internet. was also ist bei dir der Grund?
Vermute der wetterabruf.
Weitere Vermutung, das DNS Server Attribut ist im global nicht gesetzt.
Gesendet von meinem S68Pro mit Tapatalk
Mit dem in der Luft hängen, meine ich..
Fhem kommuniziert ja permanent mit dem Max-Thermostaten, bei fehlendem WLAN denke ich, kann es zum Aufhängen von Fhem kommen. (nur so ein Gedanke)
Hier ein Auszug aus dem Logfile von heute...
Das Attribut ist in global nicht gesetzt.
Wie lautet das attr? attr global - - - - -?
2020.04.26 01:19:07 0: Featurelevel: 5.7
2020.04.26 01:19:07 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:519)
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.
2020.04.26 01:19:31 0: Server shutdown
2020.04.26 01:19:02 0: Featurelevel: 5.7
2020.04.26 01:19:02 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:554)
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.
2020.04.26 01:18:52 0: Featurelevel: 5.7
2020.04.26 01:18:52 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:504)
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.
2020.04.26 01:18:52 0: Featurelevel: 5.7
2020.04.26 01:18:52 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:520)
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.
2020.04.26 01:18:51 0: Featurelevel: 5.7
2020.04.26 01:18:51 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:495)
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.
2020.04.26 01:18:59 0: Featurelevel: 5.7
2020.04.26 01:18:59 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:558)
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.
2020.04.26 01:19:06 0: Featurelevel: 5.7
2020.04.26 01:19:06 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:521)
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.
2020.04.26 01:19:19 0: Featurelevel: 5.7
2020.04.26 01:19:19 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:557)
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.
2020.04.26 01:19:10 0: Featurelevel: 5.7
2020.04.26 01:19:10 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:509)
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.
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.
2020.04.26 06:04:56 0: Featurelevel: 5.7
2020.04.26 06:04:56 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:523)
2020.04.26 06:04:57 0: Server shutdown
2020.04.26 06:06:18 0: Featurelevel: 5.7
2020.04.26 06:06:18 0: Server started with 160 defined entities (fhem.pl:21573/2020-04-01 perl:5.024001 os:linux user:fhem pid:656)
Im global Device dnsServer
Und Code/Logauszüge bitte in Code Tags packen.
(# Taste über dem Eingabefeld.)
Gesendet von meinem S68Pro mit Tapatalk
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.
Wenn es nur um den Wetterabruf geht, der FHEM blockiert, könnte man auch einfach direkt im device den Wetterabruf über das Attribut "disabledForIntervals" in dieser Zeit pausieren.
Kommt uwz mit fehlendem Internet nicht klar? (Te Log "malformed JSON...")
Zitat von: Himi am 26 April 2020, 09:59:31
Fhem kommuniziert ja permanent mit dem Max-Thermostaten, bei fehlendem WLAN denke ich, kann es zum Aufhängen von Fhem kommen. (nur so ein Gedanke)
genau anders herum wird ein Schuh draus. Die MAX Geräte verschicken regelmäßig Telegramme, alles was direkt an die Zentrale FHEM soll kommt dann halt nicht an und führt zum rferror Symbol (blinkende Antenne) am Device. FHEM ist das wurscht, auch wenn in die andere Richtung keine Antwort vom Gerät kommt.
Genau deswegen halte ich es für sinnvoll die Ursache von "hängt in der Luft" zu beseitigen.
Zitat von: betateilchen am 26 April 2020, 10:46:09
Wenn es nur um den Wetterabruf geht, der FHEM blockiert, könnte man auch einfach direkt im device den Wetterabruf über das Attribut "disabledForIntervals" in dieser Zeit pausieren.
Das Attribut gibt es leider bei dem UWZ Modul nicht.
Man müsste evtl. einen "Umweg" über ein zeitgesteuertes disable machen.
Oder über presence die Box anpingen und abhängig davon die Module steuern.
Gruß
Danny
Zitat von: moskito am 26 April 2020, 11:31:11
Das Attribut gibt es leider bei dem UWZ Modul nicht.
Man müsste evtl. einen "Umweg" über ein zeitgesteuertes disable machen.
Oder über presence die Box anpingen und abhängig davon die Module steuern.
Oder den Modulautor bitten, das Attribut zu unterstützen. Da im Modul bereits das Attribut "disable" unterstützt und die FHEM-interne Funktion IsDisabled() benutzt wird, wäre die notwendige Änderung im Code sehr überschaubar. (wenn ich es richtig sehe, geht es nur um die Erweiterung der Attributliste selbst)
der logauszug ist schon sehr seltsam.
warum sind die timestamps völlig durcheinander, zum teil identisch?
kommt denn deine system uhr ohne internet klar?
warum hast du nur featurelevel 5.7?
passen deine module überhaupt zusammen, oder updatest du immer nur "ausgewähle" module?
Plus 1. Und den Modulautor bitten Fehlerbehandlung (en) einzubauen für den Fall dass das Internet nicht verfügbar ist.
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 ;D
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
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
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
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
Naja, im geposteten log steht 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: 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.
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
$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)
Cooltux wird das klären soblad er den Freiraum dazu hat
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 ;D
Ich biete die aktuelle Version im UWZ Thread zum testen an.
https://forum.fhem.de/index.php/topic,51233.msg1047942.html#msg1047942