Wie schon öfter im Forum berichtet, verhält sich der Sketch zum Auswerten der EC3000 Power Meter per JeeLink bisweilen recht instabil und bleibt hängen.
Bei mir sind einige EC3000 im Einsatz und meine Beobachtung ist, dass in häufig in unregelmässigen Abständen ein "RFM12 hang" gemeldet wird, weitere Funknachrichten bleiben danach aus. Gelegentlich wird 'drecvintr exit' gemeldet, das dann abgesetzte 'ec' führt aber nicht wieder zu einem stabilen Bertrieb. Einzig ein Reset des JeeLink hilft in beiden Fällen weiter. Ein Workaround war bisher in meinem Testsystem, fhem per watchdog neu zu starten - für ein Produktivsystem ein absolutes no-go.
Der beigefügte Patch ändert das Modul 36_JeeLink in folgender Weise:
- neues sub JeeLink_ResetDevice(), um den JeeLink per DTR Puls neu zu starten. Die Länge in sec. ist über das Attribut resetPulseWidth eingestellt (default 0.5)
- "set DEVICE reset" erzwingt einen Reset
- bei "drecvintr exit" wird wie gewohnt 'ec' gesendet,. ausser es ist Attribut 'preferSketchReset' gesetzt, dann erfolgt der Reset
- bei "RFM12 hang" erfolgt ebenfalls ein Reset, wenn das Attribut gesetzt ist.
Ob der Patch Nebenwirkungen auf die anderen Clients hat, kann ich nicht testen, er hilft aber zumindest den Betrieb der EC3000 halbwegs zu stabilisieren.
Beste Grüße,
Andy.
hast du mal geschaut ob es reicht wenn das jeelink modul das usb device schließt und wieder öffnet? normalerweise sollte das auch zu einem reset führen.
das hätte den vorteil das keine usb spezifische behandlung gemacht werden muss und es auch bei einem remote device das mit ser2net angesprochen wird transparent gehen sollte (wenn ich das endlich eingebaut habe).
um das zu testen sollte ein einfaches modify ohne etwas zu ändern oder ein click auf DEF und modify ohne änderung reichen.
gruss
andre
Guter Punkt, habe das mit DEF und modify getestet und offenbar reicht Schliessen und wieder Öffnen, um den Reset durchzuführen - bin mir nur nicht sicher wie es zu implementieren ist ohne dabei Unfug zu treiben ;-). Wäre natürlich eleganter als über den DTR Puls. Noch besser wäre sicherlich ein stabiler Sketch, aber da habe ich mich nicht so schnell reinfuchsen können...
Was hat es mit dem ser2net auf sich, könnte man damit USB Sticks wie den JeeLink an einem remote Host ansprechen ohne dort eine fhem Installation aufsetzen zu müssen?
Grüße,
Andy.
ich schau mal das ich das resetten über schliessen und wieder öffnen einbaue. ich kann nur noch nicht versprechen wann.
ja. genau dazu ist das ser2net da. ich muss ins modul dazu noch einbauen das man statt dem device auch eine ip und einen port angeben kann. die infrastruktur in fhem ist dazu eigentlich schon da.
ich hatte schon angefangen das für das panstamp modul einzubauen habe aber bis jetzt nur die sende richtung zum laufen bekommen. sobald es funktioniert wollte ich es für den jeelink auch einbauen weil bei mir der kühlschrank im eg steht und die fhem installation unterm dach ist. ich würde dann im eg ein system mit einem zusätzlichen jeelink und einem cul installieren. mit dem hmlan hab ich nur probeme.
gruss
andre
das klingt nach genau dem was ich brauche - im Moment experimentiere ich mit 2 Raspberry Pis und FHEM2FHEM, bin aber nicht wirklich glücklich damit. Wenn Du etwas zu testen hast, würde mich das sehr interessieren.
Grüße,
Andy.
Hi,
nur mal ein kurzer Statusbericht, um den Thread am Leben zu erhalten :-)
Mit Patch laufen nun beide fhem Intanzen mit JeeLink ohne die Notwendigkeit eines "shutdown restart" - in der Zeit kam es täglich zwischen keinem und 5 Resets des Sketches direkt aus dem JeeLink Modul heraus, in jedem Fall mit gewünschtem Resultat.
Du hattest Bedenken geäußert zum Thema '$hash->{USBDev}->pulse_dtr_on()', dehalb habe ich nochmal ein wenig recherchiert: So wie ich das verstehe, ist pulse_dtr_on() Teil der perl Device::SerialPort API (sieh z.B. http://www.manpagez.com/man/3/Device::SerialPort/), sollte also unabhängig von USB funktionieren. Ansonsten scheint der Puls auf DTR im Normalfall immer beim Öffnen des Ports erzeugt zu werden, wie ich dem hier zu entnehmen glaube: http://stackoverflow.com/questions/10364136/stop-perls-tie-from-resetting-my-arduino-pulsing-dtr-on-my-serial-interface
Wie sieht denn das bei ser2net aus, gibt es sowas wie einen Protokollstandard, wie UART über Netzwerk getunnelt wird?
Grüße,
Andy.
ich hab den thread nicht vergessen :)
schön das es funktioniert. auch wenn sich scheinbar niemand sonst gemeldet hat würde ich dann die version einchecken die ohne direkten zugriff auf den port aus kommt.
das pulse_dtr_on ist zwar unabhängig von usb aber nicht unabhängig von der seriellen schnittstelle. usb/seriell ist für das fhem modul völlig transparent. lokal angeschlossen oder netzwerk ist ebenfalls (fast) völlig transparent. bis auf das parsen des device parameters. der zugriff selber ist es aber. und da funktioniert der zugriff über USBDev dann nicht mehr weil es das einfach nicht gibt.
es gibt bei ser2net noch die möglichkeit einer kontroll verbindung über einen zweiten port mit der man scheinbar ein paar dinge tun kann. die datenverbindung selber ist aber 1:1 transparent. der weg ist also nicht nutzbar wenn man die fhem io routinen transparent für serial/usb und netz nutzen möchte.
ser2net öffnet und schliesst das device auf der gegenseite aber ganz normal wenn die tcp verbindung auf und ab gebaut wird. d.h. wenn es mit dem einfachen öffnen geht sollte es auch mit ser2net keine probleme geben.
gruss
andre
ausgezeichnet :-) Wenn Du das eingecheckt hast, kannst Du das bitte nochmal kurz hier erwähnen, ich hab momentan das JeeLink Modul von updates ausgeschlossen.
War mir bislang nicht bewusst, dass ser2net eine existierende Lösung und Bestandteil der gängigeren Distributionen ist, aber Lesen bildet :-) Um an der DTR Leitung zu wackeln, müsste fhem-seitig RFC2217 (http://tools.ietf.org/html/rfc2217) implementiert werden, aber wenns ein einfaches schließen und wieder öffnen tut, wäre das schon ein wenig overkill...
Grüße,
Andy.
Hallo liebe Entwickler!
Erst einmal vielen Dank für die grandiose Arbeit zur Unterstützung des EC3000 - ich bin seit heute Abend stolzer Benutzer des FHEM mit JeeLink auf einer FritzBox, es funktioniert bislang auch alles zu meiner größten Zufriedenheit!
Aber was ist denn jetzt die für einen stabilen Betrieb der EC3000 geeignete Version der 36_JeeLink.pm?
Mir gelang es weder die 36_JeeLink.pm aus dem FHEM5.5 FritzBox 7390-Image noch die Version aus dem nightly tarball zu patchen (some hunks failed)...
Vielen Dank!
anbei mal der vorschlag für eine version die den reset per close/open macht. der reset wird bei 'drecvintr exit' und 'RFM12 hang' auf jeden fall gemacht. ohne option das weg zu konfigurieren.
probiert bitte mal ob das so geht.
gruss
andre
Hallo!
Vielen Dank, ich habe die neue 36_JeeLink.pm gerade aufgespielt und werde fhem mit meinen 9 EC3000-Sensoren nun ein paar Tage im Dauerbetrieb testen. Ich gebe Rückmeldung, sobald ich sagen kann, ob alles stabil läuft.
Viele Grüße und noch einmal vielen Dank für die ganze Mühe.
Hallo,
ich hatte ja eine kurze Rückmeldung versprochen - die 36_JeeLink.pm arbeitet seit nun sechs Tagen bei mir fehlerfrei, alle Resets wurden korrekt behandelt (siehe beiliegenden Ausschnitt aus meinem Log).
Vielen Dank für die tolle Arbeit und viele Grüße!
--- cut ---
...
2014.05.23 17:00:50 3: myJeeLink device opened
2014.05.23 17:00:51 3: EC3000_FC46: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_4ACB: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_F047: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_FC38: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_FB23: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_FC92: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_05F1: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_0EE8: I/O device is myJeeLink
2014.05.23 17:00:51 3: EC3000_0600: I/O device is myJeeLink
2014.05.23 17:00:51 1: Including ./log/fhem.save
2014.05.24 02:39:20 3: EC3000 Unknown device FBC7, please define it
2014.05.24 02:39:20 2: autocreate: define EC3000_FBC7 EC3000 FBC7
2014.05.24 02:39:20 3: EC3000_FBC7: I/O device is myJeeLink
2014.05.24 02:39:20 2: autocreate: define FileLog_EC3000_FBC7 FileLog ./log/EC3000_FBC7-%Y.log EC3000_FBC7
2014.05.24 22:14:59 0: myJeeLink: RFM12 hang detected
2014.05.24 22:14:59 3: Opening myJeeLink device /dev/ttyUSB0
2014.05.24 22:14:59 3: Setting myJeeLink baudrate to 57600
2014.05.24 22:14:59 3: myJeeLink device opened
2014.05.24 22:15:01 3: myJeeLink: Unknown code RFM12 restart , help me!
2014.05.25 15:07:45 0: myJeeLink: RFM12 hang detected
2014.05.25 15:07:45 3: Opening myJeeLink device /dev/ttyUSB0
2014.05.25 15:07:45 3: Setting myJeeLink baudrate to 57600
2014.05.25 15:07:45 3: myJeeLink device opened
2014.05.25 15:07:47 3: myJeeLink: Unknown code RFM12 restart , help me!
2014.05.28 11:42:46 0: myJeeLink: RFM12 hang detected
2014.05.28 11:42:46 3: Opening myJeeLink device /dev/ttyUSB0
2014.05.28 11:42:46 3: Setting myJeeLink baudrate to 57600
2014.05.28 11:42:46 3: myJeeLink device opened
2014.05.28 11:42:48 3: myJeeLink: Unknown code RFM12 restart swreset , help me!
--- cut ---
ich hab die version jetzt so eingecheckt.
gruss
andre
Hallo,
ich muss diesen Thread nun doch noch einmal kurz reaktivieren:
In der vergangenen Nacht hatte mein JeeLink einen Hänger, der nicht durch Schließen und Öffnen des USB-Ports behoben werden konnte:
--- cut ---
2014.06.04 05:13:42 0: myJeeLink: RFM12 hang detected
2014.06.04 05:13:42 3: Opening myJeeLink device /dev/ttyUSB0
2014.06.04 05:13:42 3: Can't open /dev/ttyUSB0: Input/output error
--- cut ---
Danach wurden keine Messwerte mehr aufgezeichnet, woraufhin ich die Fritzbox neu gestartet habe.
Hat jemand eine Idee, ob man da noch etwas tun kann? Selbst ein vollständiger Neustart des FHEM wäre für meine Zwecke akzeptabel, ich bin mir nur nicht sicher, ob sich dies aus der 36_Jeelink.pm heraus bewerkstelligen ließe.
Vielen Dank für eine kurze Rückmeldung.
Viele Grüße!
Wie flashe ich den JeeLink auf EC3000 mit FHEM?
Leider gibt es kaum Infos im Netz. Hatte mir extra nen JeeLink und Technoline Stromsensoren angeschafft und muss leider Feststellen, das es doch nicht so einfach ist wie gedacht.
Danke schonmal für die Antworten ;-)
Gesendet von meinem GT-N7100 mit Tapatalk
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
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*
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:
Zitat
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?
Niemand eine Idee?
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ß
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... :)
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...
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?
Zitat von: connormcl am 28 Oktober 2019, 01:47:03
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.
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.
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.