GDS blockt FHEM wenn Internet offline?

[betateilchen]

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.

[hexenmeister]

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*)

[Deudi]

Guten Morgen 

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.

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

[hexenmeister]

Moin!

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...

Von 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.

Und, 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).

Ich wollte hier auch kein Fass aufmachen

Zu spät 

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.

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

[Deudi]

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
Gut, dann beschäftige ich mich daheim weiter mit dem geöffneten Fass und ich schaue mal, ob ich es heute noch leer bekomme

Ich appelliere trotzdem an alle Entwickler darauf rumzudenken, ob in ihrem Modul ein disable Sinn machen würde. 
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. 

Viele Grüße
Jürgen

[betateilchen]

somit kann ich am Wochenende das Projekt Gewaltenteilung in FHEM angehen. 

die ich übrigens für völlig überflüssig halte.

[Deudi]

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.

[hexenmeister]

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.

[betateilchen]

Anstatt zwei Cubietrucks zu installieren, könnte man ja auch einfach die Fehlerursache auf dem EINEN suchen und beheben

[Deudi]

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 

Ü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)?

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 

[hexenmeister]

Ü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

[Deudi]

So läuft 

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

[Deudi]

Hallo betateilchen,

da ist noch eine Logausgabe zuviel in GDS_GetUpdate Zeile 377. Ich bekommen alle 20 Minuten

Code Auswählen Erweitern

GDS DWD is disabled, data update cancelled.
ins Log, obwohl das Modul nicht disabled ist.

Grüße
Jürgen

[betateilchen]

da ist noch eine Logausgabe zuviel in GDS_GetUpdate Zeile 377.

Ein typischer copy&paste Fehler, danke für den Hinweis. Ab morgen erledigt.