[patch] Stabiler Betrieb der EC3000 Power Meter mit 36_JeeLink und 36_EC3000

[QuesT]

Hallo,

Hier findest du schon mal ganz unten die benötigten Files: http://forum.fhem.de/index.php/topic,11648.840.html
Hier das Wiki für den JeeLink: http://www.fhemwiki.de/wiki/JeeLink

[bamm-bamm]

Vielen Dank!!!
Ich hatte es lt. Wiki mit der Arduino Software versucht....mehr als Verzweifelung hatte das nichts gebracht
Hatte "EC3000.hex" schon in etlichen Suchmaschinen vergeblich gesucht. Umflaschen vom vorher geflashtem LaCrosse auf EC3000 erfolgreich und die Technoline Geräte wurden sofort erkannt. Kein Peeren nötig. Jetzt muss ich nur noch mit geeichtem Gerät testen, ob die empfangenen Werte denn annähernd zu gebrauche sind *gg*

[connormcl]

Ich habe mein FHEM seit ca. Anfang 2017 in Betrieb. Also deutlich nach der hier diskutierten Problematik.

Allerdings habe ich auch das Problem, dass mein JeeLink v1 mit EC3000 Sketch ab und zu nach 1-4 Wochen hängen bleibt.
Er hängt per USB direkt an einem Raspberry Pi 3B.

Der Hänger am JeeLink reisst dann Teile von FHEM mit in den Abgrund:
Es geht dann kein Webinterface mehr und auch at-Timer im Hintergrund werden nicht mehr ausgeführt. Von HMCCU kommen aber noch Meldungen im Log.

Im Log sieht es so aus:

2018.04.21 02:59:26 0: JeeLink1: RFM12 hang detected
2018.04.21 02:59:26 3: Opening JeeLink1 device 127.0.0.1:10003
2018.04.21 02:59:26 1: 127.0.0.1:10003 disconnected, waiting to reappear (JeeLink1)
2018.04.21 03:19:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 03:57:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 04:40:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 05:18:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 05:56:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 06:36:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 07:15:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 07:55:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 08:33:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 09:13:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 09:54:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 10:31:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 11:09:46 3: CCURPC: CB2001 Received 500 events from CCU since last check

Ein Neustart von FHEM reicht nicht aus; ebenso ein Reboot nicht....es muss zusätzlich der JeeLink durch einen Powercycle.

Dazu habe ich zwei Fragen:
1) Kann ich das Problem irgendwie beheben oder Softwaremässig ohne FHEM lösen? FHEM startet ja im Fehlerfall nicht und dann müsste jemand händisch an die Hardware...

und

2) Es scheinen sich ja nicht alle FHEM Komponenten aufzuhängen... aber soweit, dass es insgesamt nicht mehr läuft. Sollte FHEM an der Stelle nicht robust genug sein, um den Ausfall einer Hardware-Komponente zu tolerieren? Kann das an einer Einstellung liegen?

[connormcl]

Niemand eine Idee?

[Guzzi-Charlie]

Hallo,

schonmal das timeout Attribut versucht. Ich hatte lange auch das Problem das der Jeelink ab und zu einfach die Arbeit eingestellt hat und dabei das ganze System mit in den Abgrund gezogen hatte. Es half dann nur den Jeelink zu ziehen und neu zu stecken, oder den Raspberry neu zu starten.

Beispiel:
attr timeout 60,15 bedeutet, daß alle 15s geprüft wird ob der letzte Empfang innerhalb der letzten 60s lag. Wenn nicht wird der Jeelink resettet. Bei mir funktioniert der Jeelink seitdem ohne Probleme und das System bleibt nicht mehr stehen.

Gruß

[connormcl]

Danke für die Rückmeldung...werde ich mal eintragen und beobachten!

Kann aber ein halbes bis Jahr dauern, ehe ich weiss, ob es funktioniert hat...

[connormcl]

Gestern hatte ich einen Hänger mit nicht mehr erreichbarem FHEM bei einem JeeLink v1 mit LaCrosse-Sketch, von dem ich erwartet hätte, dass er durch den timeout erfasst wird.

Meine JeeLinks sind mit ser2net an den FHEM-Rechner angebunden.
Das Attribut timeout hatte ich schon gesetzt, aber FHEM nicht neu gestartet.

Ich konnte im Log keinen timeout/reopen-Versuch feststellen. Es war nur der JeeLink-Disconnect zu sehen.
Wie müsste der ReOpen-Versuch im Log aussehen? -> Ich habe jetzt mal FHEM neu gestartet und warte bis zum nächsten Hänger.

Das Ganze hat mich zum Nachdenken bezgl. der "RFM12 hangs"-Aussetzer gebracht: hier reagiert FHEM auch nicht mehr und kann nur per "kill -9" abgeschossen werden. Bei einem direkten FHEM-Neustart ohne vorher den hängenden JeeLink zu Powercyclen kommt FHEM ja nicht hoch.
Beim Hochfahren macht er doch aber nichts anderes wie einen Reopen des JeeLinks...also sollte das ReOpen bei timeout im laufenden Betrieb in diesem Fall auch nicht helfen können...

[connormcl]

Leider habe ich immernoch die Probleme mit den JeeLinks...die hängen sich im EC3000 Betrieb auf und FHEM gleich mit.

Da bin ich leider mit LaCrosse Thermometern und EC3000 inkl. JeeLink voll auf die Nase gefallen. Das hat man in allen FHEM-Tutorials zu lesen bekommen und wurde gepriesen als günstig und gut für den Einstieg... nun sind aber sowohl der EC3000 Sketch, als auch das FHEM-Modul zum JeeLink instabil.

Der JeeLink ist über ser2net angebunden. Der Reset bei RFM12 hang wird nicht korrekt ausgeführt, sondern bringt FHEM zum Absturz.
Ich habe mir jetzt zwar ein ShellScript geschrieben, was den FHEM in einen Not-Betrieb ohne JeeLink versetzt, aber das kanns ja nicht sein.

Kennt jemand andere und stabile Hardware zum Anbinden der EC3000 an FHEM?

Oder gibt es irgendwo ein JeeLink-Perl-Modul, das den FHEM nicht zum Absturz bringt?

[kpwg]

Leider habe ich immernoch die Probleme mit den JeeLinks...die hängen sich im EC3000 Betrieb auf und FHEM gleich mit.
...
Kennt jemand andere und stabile Hardware zum Anbinden der EC3000 an FHEM?

Ja. Der EC3000 Sketch für den Jeelink funktioniert schlicht nicht, wie er sollte. Ich habe damit auch viel Zeit und Mühe vergeudet- vergeblich. Ich würde da keine weitere Minute investieren.

Als langfristig sehr zuverlässig und stabil hat sich hier der LaCrosse-Gateway auf Basis ESP8266 mit zwei RFM69 bewährt. Ich habe den seriell (USB) am RasPi angebunden und bei den noch verbliebenen LaCrosse-Sensoren (DTH29IT) und drei EC3000-Steckdosen keine Ausfälle zu verzeichnen. Zu erwähnen ist noch, das die RFM69 Module HF-technisch besser als die alten RFM12B sind, was sich spürbar auf Empfang und Reichweite auswirkt.

[Guzzi-Charlie]

Hallo zusammen,

ich kann zwar nicht mit neuen Erkenntnissen dienen, aber ich kann hier nochmal bestätigen daß meine JeeLink-EC3000 Kombi seit dem Setzen des timeout Attributes absolut stabil läuft (siehe auch meine Antwort #19 hier im Thema). Seit mindestens dem letzten halben Jahr gab es keinerlei Hänger vom JeeLink oder des RasPi wegen des JeeLinks. Bei mir hängt der JeeLink über mehrere USB-Verlängerungen und 2 USB-Hubs an einem RasPi 3+.

Über den JeeLink sind bei mir 13 EC3000-Meßsteckdosen angebunden. Der JeeLink hängt im Kellergeschoß in der abgehängten Zwischendecke und koppelt dort sowohl alle EC3000 im Keller (Kühl-/Gefrierschrank, Waschmaschine, Heizungspumpen, 3D-Drucker) als auch die EC3000 im Erdgeschoß (Kühlschrank, Gefrierschrank, Spülmaschine) an. Auch empfangstechnisch gibt es keine Probleme, obwohl zwischen dem JeeLink und dem Erdgeschoß eine 20cm dicke Stahlbetondecke liegt.

Aktuell ist der JeeLink das Einzigste was per USB am RasPi hängt.

Gehört zwar nicht direkt hier her, aber ich hatte massive Probleme mit USB One-Wire Busmastern (3 Stück mit ca. 70 Temp.-Sensoren). FHEM hat sich immer wieder aufgehängt, bzw. ließ sich kaum noch bedienen. Da hab ich auch lange gesucht bis ich die als Verursacher identifiziert hatte. Nachdem ich die alle rausgeschmissen hatte (die 70 Temp.-Sensoren sind jetzt über 10 D1-Mini mit Tasmota-FW per WLAN und MQTT2 angebunden) funktioniert FHEM wieder flott wie am ersten Tag.

[connormcl]

Danke für die Rückmeldung.

Bei mir hängt sich der JeeLink beim "RFM12 hang detected" leider so auf, dass FHEM trotz des Attributes "timeout 60,15" diesen nicht neu startet, sondern sich selbst blockiert.
Auch ein manueller Neustart von FHEM ändert daran nicht. FHEM kann in diesem Zustand den JeeLink nicht wieder initialisieren, sondern bleibt gleich wieder stehen.

Evtl. liegt das alles daran, dass er per ser2net angehängt ist. Falls jemand einen Linux-Befehl für die Konsole kennt, der einen Reset erfolgreich hinbekommt, immer her damit. Den Reset habe ich bisher nur durch manuelles abstecken hinbekommen.