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

Begonnen von gandy, 01 Mai 2014, 11:39:05

Vorheriges Thema - Nächstes Thema

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gandy

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.

fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

flydd

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!

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

flydd

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.

flydd

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

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

flydd

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!

bamm-bamm

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