GDS blockt FHEM wenn Internet offline?

Begonnen von Deudi, 13 Oktober 2014, 11:52:25

Vorheriges Thema - Nächstes Thema

Deudi

Hallo Betateilchen,

ich benutze seit einigen Wochen dein GDS Modul - super Sache und lief bisher ohne Probleme.

Gestern ist bei uns das DSL ausgefallen (anbieterseitig). Dabei konnte ich feststellen, dass immer wenn ein Update der Wetterdaten anstand, FHEM längere Zeit hängen blieb und alle HMLAN disconnecten etc. Das Verhalten konnte ich durch Entfernen des Moduls beheben.

Hoffentlich lehne ich mich nicht zu weit aus dem Fenster, wenn ich GDS dafür verantwortlich mache. Kannst du das ausschließen (ist GDS non-blocking), dann muss ich weiter forschen oder ist das GDS Modul auf einen Internetausfall nicht wirklich vorbereitet?
Ich habe jetzt mal keine Logs etc. drangehängt, da ich nicht genau weiß welche Informationen hier weiterhelfen.

Grüße
Jürgen
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

betateilchen

GDS und nonblocking hatte ich schonmal irgendwann gebaut, das hat aber jede Menge anderer Probleme bei den Anwendern geschaffen, deshalb habe ich diese Option wieder gestrichen. Daher kommt das Blockieren, wenn keine Internetverbindung besteht. Mir ist dazu noch keine wirklich alle Fälle abdeckende Lösung eingefallen.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Markus Bloch

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

betateilchen

Das hatte ich auch schon getestet - sogar gegen meine innere Überzeugung. Hat auch nicht zuverlässig funktioniert.

Ausserdem bin ich ein natürlicher Feind der HttpUtils - aber das ist ein anderes Thema.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Deudi

So, seit gestern ist das Internet wieder da  ::)

Um den Status des Internetzugangs (halbwegs) sicher zu ermitteln, pinge ich mit PRESENCE einen Webserver. Bevor ich versuche eine Aktion "im Internet" auszuführen (Mail, Pushover etc.) prüfe ich den Status der PRESENCE Instanz. Das tut es so grob, genau genommen müsste ich den Mailserver und den Pushover-Server pingen. Dadurch verhindere ich Probleme mit längeren Timeout Zeiten, falls das Internet mich mal nicht mag.

Wäre das nicht auch ein gangbarer Weg für die Module, die auf das Internet angewiesen sind? Könnte nicht das Modul GDS intern den Status des DWD Servers monitoren, das Weather den Server von Yahoo etc.? Oder es gibt ein Attribut mit dem man eine selbst erstellte PRESENCE Instanz angeben kann, dessen Status vom Modul geprüft wird.

Ich habe in der letzten Zeit mein FHEM stark aufgebohrt mit allen "Bells and Whistles" (PRESENCE, GDS, Weather, SYSMON, RSS etc.). Seitdem häufen sich die Abstürze und Latenzen. Nix gegen euch Entwickler - ich finde das alles sehr nützlich und kann es hier gewinnbringend einsetzen. Allerdings mag ich das nicht damit bezahlen, dass mein FHEM instabil wird und während meines Urlaubs die Rollos nicht fahren usw.
Daher habe ich für mich jetzt die Konsequenz gezogen und die FHEM-Konfiguration auf das absolut notwendige reduziert (die Kommunikation mit den Homematic Geräten und sonst nix!). Alles andere kommt auf einen zweiten Cubietruck. Auf letzterem ist es mir dann Wurscht, wenn es hier und da mal zwickt.

Grüße
Jürgen
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

betateilchen

Ich könnte dem gds Modul bei Gelegenheit das Attribut "disable" verpassen, dann könntest Du einfach Dein gds-Device per notify (auf Dein presence) abschalten, wenn das Internet nicht zur Verfügung steht. Und natürlich auch wieder einschalten, wenn alles wieder passt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

SYSMON hat ein disable Attribut ;)
Sollte aber nicht der Grund deiner Probleme sein. Läuft bei mir immer mit und reißt den Server nicht runter. Ich hatte vor kurzen Probleme mit Geodata (Abstürze und http-bezogene Meldungen im Log, weiß nicht mehr wie genau). Habe rausgenommen - wieder Ruhe.
Weiterhin würde ich die Watchdog empfehlen (Hardware-Watchdog oder Watchdog-Script).

Deudi

Zitat von: betateilchen am 15 Oktober 2014, 15:20:27
Ich könnte dem gds Modul bei Gelegenheit das Attribut "disable" verpassen, ...

Das wäre cool, würde ich begrüßen. Das sollte vielleicht sogar mal als "Must-Feature" für alle Module vorgeschrieben werden. Dann kann man bei Problemen ruckizucki den Übeltäter ermitteln.

Watchdog habe ich eingerichtet und getestet. Allerdings hatte ich Probleme, die zu ständigen Disconnects der HMLAN führen. Dann geht auch nix mehr, obwohl FHEM noch läuft.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

hexenmeister

Disconnects sind blöd, haben aber nichts mit Watchdog zu tun.

Mit "must" ist so eine Sache... Ich habe das zwar eingebaut, Sehe aber keine Notwendigkeit dafür. Zumindest nicht für die Fehlersuche.
Dafür gibt es logs, perfmon und apptime.

betateilchen

Zitat von: betateilchen am 15 Oktober 2014, 15:20:27
Ich könnte dem gds Modul bei Gelegenheit das Attribut "disable" verpassen

Zitat von: Deudi am 15 Oktober 2014, 16:11:31
Das wäre cool, würde ich begrüßen.

Ab morgen per update verfügbar.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Deudi

Zitat von: hexenmeister am 15 Oktober 2014, 16:30:16
Disconnects sind blöd, haben aber nichts mit Watchdog zu tun.
Weiß ich, habe ich auch nicht behauptet.

Zitat
Mit "must" ist so eine Sache... Ich habe das zwar eingebaut, Sehe aber keine Notwendigkeit dafür. Zumindest nicht für die Fehlersuche.
Dafür gibt es logs, perfmon und apptime.
perfmon und apptime hatte ich noch nicht benutzt. Da werde ich mal mit anfangen.
Wenn man allerdings testweise ein Modul deaktivieren möchte, muss man es komplett rauswerfen incl. aller Attribute und dann ggf. wieder einbauen. Da ist ein Attribut "disable" viel schneller mal kurz gesetzt. Ich finde das ist schon eine feine Sache.

@betateilchen
Vielen Dank!
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

hexenmeister

Das Problem mit dem disable ist, dass es nicht zentral, sondern in jedem Modul selbst implementiert sein muss. Du hast also keine Sicherheit, dass es nicht trotzdem für die Probleme sorgt. Also für diesen Zweck nutzlos.

betateilchen

#12
???

Natürlich muss ich in meinem Modul auf das disable reagieren, aber das ist doch genau der Hintergrund, warum Deudi geschrieben hatte:

ZitatDas sollte vielleicht sogar mal als "Must-Feature" für alle Module vorgeschrieben werden

Im GDS Modul sorgt das disable jedenfalls ab morgen dafür, dass keine Internet-Kommunikation mehr stattfindet, solange das Attribut gesetzt ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

Ist schon klar. Es wäre jedoch sauber, wenn so eine Feature zentral implementiert wäre. Sonst kann man ja nicht sicher sein, dass der Modul Autor eben dieser korrekt umgesetzt hat. ;)

rudolfkoenig

Zentral ist aber sowas nicht ganz trivial, da ein Modul beliebigen Unsinn treiben kann, z.Bsp. sh -c 'while true; do echo hallo; sleep 1; done' aufrufen.