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
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.
Klappt auch nicht mit http://www.fhemwiki.de/wiki/HttpUtils#HttpUtils_NonblockingGet ?
Das ist eine Lösung ohne forken.
Gruß
Markus
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.
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
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.
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).
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.
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.
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.
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!
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.
???
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.
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. ;)
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.
Eine zentrale Auswertung finde ich auch schwierig. Im jeweiligen Modul finde ich das ganz gut aufgehoben. Immerhin kann man ja den Status für ein device schon sehr komfortabel über die zentrale Funktion IsDisabled($name) abfragen, das erleichtert die Reaktion innerhalb des Moduls selbst erheblich.
stimmt schon, da wir kein echtes Multitasking haben, können fehlerhafte Module unbeschtraft alles lahmlegen.
Ich würde wohl zur Fehlersuche trotzdem eher die Definitionen aus dem Config auskommentieren (*duck*) ;)
Guten Morgen :D
Zitat von: hexenmeister am 15 Oktober 2014, 19:19:56
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.
Zitat von: hexenmeister am 15 Oktober 2014, 20:02:10
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. ;)
Ich würde mal davon ausgehen, dass die wenigsten Modulautoren das jeweilige Modul aus Nächstenliebe schreiben, sondern weil sie selbst so etwas brauchen. Ich schreibe ja (vermutlich) kein Sprinkle Modul, wenn ich keinen Garten habe, oder z.B. die serielle Anbindung an einen Wasserzähler, wenn ich das Gerät dazu nicht selbst im Haus habe. Damit will ich sagen, dass man natürlich ein Eigeninteresse an der korrekten Funktionsweise seines Moduls haben sollte. Sprich ein Modul sollte FHEM nicht beeinträchtigen, wenn die Grundvoraussetzungen nicht gegeben sind, d.h. wenn das Internet oder Netzwerk nicht verfügbar ist, der serielle Bus abgezogen ist, das jeweilige Gerät nicht antwortet usw. Design- oder Programmierfehler passieren nun mal, das ist völlig normal. Auch kann man nicht verhindern, dass jemand zum 1. April mutwillig eine Endlosschleife eincheckt.
Es wird aber auch mindestens eine englische commandref verlangt, es gibt Designvorgaben wie das Modul mit dem FHEM Kern kommuniziert etc. Von daher könnte man den Modulautoren auch "vorschreiben", dass die Hauptfunktionalität außer Funktion gesetzt wird, wenn das Attribut "disable" aktiviert ist.
Beruflich schlage ich mich mit solchen Themen herum und bei uns kann man externe Systeme per Softwareschalter lahm legen, falls die mal rumzicken. Und das Hauptsystem sollte funktionieren - besser ist das.
Und, hexenmeister, du musst dich gar nicht wegducken - vielleicht bin ich wirklich nur zu faul eine intelligentere Fehlersuche zu machen ;) Ist ja auch irgendwie genauso wie Dokumentation ein natürlicher Feind des Programmierers.
Ich wollte hier auch kein Fass aufmachen, jedoch finde ich die spontane Reaktion von betateilchen toll.
Einen habe ich noch: Unlängst habe ich an meinem Wohnzimmerschrank rumgebaut und alle Geräte abgeklemmt. Dazu konnte ich die beiden Yamaha Module per disable lahm legen, damit mir das Log nicht überläuft. Danach habe ich alles wieder aktiviert und fettisch. Das ist doch eine feine Sache.
Viele Grüße
Jürgen
Moin!
Zitat von: Deudi am 16 Oktober 2014, 09:34:43
Ich würde mal davon ausgehen, dass die wenigsten Modulautoren das jeweilige Modul aus Nächstenliebe schreiben, sondern weil sie selbst so etwas brauchen.
Im Prinzip ja, aber... ich habe mittlerweile eine oder andere Funktionalität in mein Modul eingebaut, die ich weder brauche, noch (mangels betroffene Hardware) testen kann. Eigeninteresse hin oder her...
ZitatVon daher könnte man den Modulautoren auch "vorschreiben"...
Klar, kann man was verlangen. Oder zumindest versuchen... Ich habe nur sagen wollen, dass dies zum Thema Fehlersuche IMHO nicht unbedingt sicher genug ist.
ZitatUnd, hexenmeister, du musst dich gar nicht wegducken
;) Damit sollte mein "Kopfeinziehen" zum Ausdruck gebracht werden, bevor mir jemand wegen direkten Editieren im Config drauf haut (ist hier (nicht unbegründet) verpönnt). ;)
ZitatIch wollte hier auch kein Fass aufmachen
Zu spät :P
ZitatDazu konnte ich die beiden Yamaha Module per disable lahm legen, damit mir das Log nicht überläuft. Danach habe ich alles wieder aktiviert und fettisch. Das ist doch eine feine Sache.
Für so was habe ich ja auch eingebaut, auch wenn ich das nicht brauche. Ironie des Schicksals: vor kurzen hat mir jemand genau so ein Fehler gemeldet: mit einem disable im SYSMON startet FHEM nicht mehr. War eine Endlosschleife im Init. Habe ich natürlich korrigiert. Es war aber viele Monate so drin. Das zeigt schon recht deutlich, wie viele Leute diese Funktionalität "wirklich gebraucht" haben. ;)
So, jetzt mache ich den Faß wieder zu ;)
Zitat von: hexenmeister am 16 Oktober 2014, 11:35:07
Ironie des Schicksals: vor kurzen hat mir jemand genau so ein Fehler gemeldet: mit einem disable im SYSMON startet FHEM nicht mehr.
Da hat "disable" doch gemacht was draufsteht und es hat sogar global gewirkt ;D
Gut, dann beschäftige ich mich daheim weiter mit dem geöffneten Fass und ich schaue mal, ob ich es heute noch leer bekomme :P
Ich appelliere trotzdem an alle Entwickler darauf rumzudenken, ob in ihrem Modul ein disable Sinn machen würde. :o
Jedenfalls ist mein Problem aus dem Betreff gelöst worden und ich mache heute Abend mal ein Update und baue mir ein Notify. Weiterhin ist der zweite Cubietruck auf dem Postweg und somit kann ich am Wochenende das Projekt Gewaltenteilung in FHEM angehen. 8)
Viele Grüße
Jürgen
Zitat von: Deudi am 16 Oktober 2014, 14:17:07
somit kann ich am Wochenende das Projekt Gewaltenteilung in FHEM angehen. 8)
die ich übrigens für völlig überflüssig halte.
Zitat von: betateilchen am 16 Oktober 2014, 14:34:22
die ich übrigens für völlig überflüssig halte.
Nachdem mein FHEM zwei Tage lang bis zum Entfernen des GDS Moduls das Log mit HMLAN Disconnects vollgeschrieben hat, sehe ich das nicht so. Glücklicherweise kann es ja jeder so machen, wie er es für richtig hält.
Entferne mal bei deinem FHEM den CUL, schließe ein HMLAN an und zieh das Kabel aus dem Router.
Zwei CubieTrucks halte ich auch für übertrieben. Schon einer hat ja genug Leistung. Man könnte, wenn man das schon möchte, FHEM auch zwei mal auf dem selben Rechner installieren.
Anstatt zwei Cubietrucks zu installieren, könnte man ja auch einfach die Fehlerursache auf dem EINEN suchen und beheben ;)
Zitat von: hexenmeister am 16 Oktober 2014, 15:29:49
Zwei CubieTrucks halte ich auch für übertrieben. Schon einer hat ja genug Leistung. Man könnte, wenn man das schon möchte, FHEM auch zwei mal auf dem selben Rechner installieren.
Nun ja, es gibt einen Unterschied zwischen überflüssig und übertrieben. Wenn es sonst nicht läuft, ist es nicht überflüssig. Übertrieben aber vielleicht schon. Dafür dass im Büro nur noch eine LED Lampe statt 3x 40W Halogen an der Decke leuchtet, kann man ne Menge Cubietrucks betreiben :P
Über eine zweite FHEM Installation auf dem selben Truck hatte ich auch schon nachgedacht. Ich denke man muss nur die Portnummern (WEBxxx und Telnet) unterschiedlich gestalten, oder gibt es sonst noch was zu beachten (Pfade sind ja relativ)?
Zitat von: betateilchen am 16 Oktober 2014, 16:21:15
Anstatt zwei Cubietrucks zu installieren, könnte man ja auch einfach die Fehlerursache auf dem EINEN suchen und beheben ;)
Habe ich ja schon, ich habe gefunden, du hast gefixt ;)
Vielleicht nehme ich den zweiten auch nur als Hardwareredundanz (Testsystem), mal sehen...
Jetzt nehmt mir doch nicht meinen Spieltrieb ;D
ZitatÜber eine zweite FHEM Installation auf dem selben Truck hatte ich auch schon nachgedacht. Ich denke man muss nur die Portnummern (WEBxxx und Telnet) unterschiedlich gestalten, oder gibt es sonst noch was zu beachten (Pfade sind ja relativ)?
Ressourcen aller Art (Ports, Hardware wie CUL etc.) müssen natürlich exclusiv gehandelt werden. Ansonsten... probiere es aus ;)
So läuft :D
Zweite fhem Installation auf dem gleichen Cubietruck per FHEM2FHEM mit der ersten Installation verbunden.
Bei der zweiten Installation haben die Portnummern alle ein +10 bekommen. Bisher alles ok. Werde es mal beobachten.
Grüße
Jürgen
Hallo betateilchen,
da ist noch eine Logausgabe zuviel in GDS_GetUpdate Zeile 377. Ich bekommen alle 20 Minuten
GDS DWD is disabled, data update cancelled.
ins Log, obwohl das Modul nicht disabled ist.
Grüße
Jürgen
Zitat von: Deudi am 18 Oktober 2014, 15:09:42
da ist noch eine Logausgabe zuviel in GDS_GetUpdate Zeile 377.
Ein typischer copy&paste Fehler, danke für den Hinweis. Ab morgen erledigt.