LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino

[ext23]

Nein das ist es ja gerade, das lief tagelang mit der 1.25 und dann sind die Probleme aufgetreten (mit der 1.25). Den Upgrade auf die 1.28 habe ich ja gestern erst gemacht. Also das muss was anderes sein.

/Daniel

[pc1246]

Und wenn jemand keinen Priority-Wartungsvertrag hat, verlasse ich das Bett auch nicht noch mal 

Und Deine Frau hat sowohl 24/7 als auc den Priority-Wartungsvertrag!
Na dann sieh mal zu! 
Gruss Christoph

[Omega]

Hättest Du Dir die 24/7 Lizenz der LGW Software gegönnt, wäre Dir das nicht passiert 

Ich bin zwar kein Schwabe, aber einen Wartungsvertrag für eine Software, die ansonsten unglaublich stabil und fehlerfrei läuft....meine Hochachtung dafür an HCS.

,,set connect" und ,,LGW reboot" hatte ich gestern mehrfach probiert – ohne Ergebnis. Aber der FHEM restart hat dann eben das gewünschte Ergebnis gebracht.

Dabei ist mir aufgefallen, das das Reading pressure seit dem 26.01.17 nicht mehr aktualisiert wird (auf dem OLED wird es aber immer angezeigt und nach einem Reboot steht auch der aktuelle Wert im device – aber nie im dazugehörigen Filelog).
Erst nachdem ich das Attribut ,,dew_state absFeuchte 1" (was ja zunächst einmal nicht direkt mit dem LGW zu tun hat) gelöscht hatte, wurde das Reading wieder aktualisiert.

Erst mal ist alles wieder gut
LG
Holger

[HCS]

Und wenn jemand keinen Priority-Wartungsvertrag hat, verlasse ich das Bett auch nicht noch mal 

Und Deine Frau hat sowohl 24/7 als auc den Priority-Wartungsvertrag!

Ja, aber nur solange ich das Bett nicht verlassen habe 

... Aber der FHEM restart hat dann eben das gewünschte Ergebnis gebracht.

Das hatte ich auch schon mal. Es kann wohl passieren, dass in FHEM DevIO ein wenig in Schieflage gerät, was dann zu dem Effekt führt.

[ext23]

Gibt es schon was Neues wegen der EC3000? Ich habe festgestellt, das Signal kommt wieder. Dauert aber eben durchaus mehr als 1 Tag.

Dann eine andere Frage, ich bekomme im FHEM log jetzt ständig aller paar Sekunden: "LaCrosse: Unknown device 11, please define it" Aber im Log vom LGW sehe ich nichts, da ist alles ruhig außer meine Steckdosen.

/Daniel

[HCS]

Gibt es schon was Neues wegen der EC3000? Ich habe festgestellt, das Signal kommt wieder. Dauert aber eben durchaus mehr als 1 Tag.

Leider nicht. Das ist ein ganz übles Problem. Es ist nun wohl definitiv so, dass der RFM69 irgend wann aufhört zu empfangen. Wenn man ihn neu initialisiert (das war der "17241#3r 20000#3r" Test), dann läuft er wieder eine Weile.
Warum das passiert und warum es nur auf auf manchen LGW passiert und warum es nur mit EC3000 passiert habe ich aber noch nicht herausgefunden.
Und ich habe zwei LGW, mit exakt gleicher Ausstattung (3xRFM69) und Konfiguration und auf dem einen geht es und auf dem anderen nicht.
Das Problem ist aber auch, dass es auf dem LGW, auf dem ich es nachvollziehen kann, manchmal auch mehr als ein paar Minuten funktioniert.
Das macht die Testerei extrem unhandlich 

Genug gejammert  Ich arbeite an dem Problem, kann aber aktuell aufgrund völliger Ratlosigkeit keine Prognose abgeben.

Dann eine andere Frage, ich bekomme im FHEM log jetzt ständig aller paar Sekunden: "LaCrosse: Unknown device 11, please define it" Aber im Log vom LGW sehe ich nichts, da ist alles ruhig außer meine Steckdosen.

Dann wäre ja zu vermuten, dass es nicht vom LGW kommt, sondern von einem anderen Device, das LaCrosse als Client hat.
Hast Du sonst noch was am Laufen (JeeLink, Signalduino, ...)?

[ext23]

Aber es lief bei mir wie gesagt einige Tage sehr gut. Ich habe aber einen EC3000 an eine andere Stelle verfrachtet und das könnte sich decken mit dem Zeitpunkt wo ich die Aussetzer habe. Könnte es sein, dass sich der RFM irgendwie aufhängt wenn er unsaubere Signale empfängt?

Ich hab eben nochmal geschaut, das ist wirklich so. Am 28.02. habe ich einen meiner drei EC3000 an eine Stelle gehangen, die ich würde mal sagen funktechnisch am weitesten entfernt ist von den 3 Geräten. Und exakt ab diesem Tag habe ich auch die Aussetzer.

Btw. ein reinitialize falls zu lange keine Daten komme wäre doch ein Workaround oder?

Wegen dem anderen LaCrosse Gerät muss ich mal schauen, vielleicht der panstamp sonst habe ich ja nur noch CUL und TRX433 dran.

/Daniel

[HCS]

Könnte es sein, dass sich der RFM irgendwie aufhängt wenn er unsaubere Signale empfängt?

Das ist recht plausibel, weil das LGW, mit dem ich teste, genau an der Reichweitengrenze von fast allen EC3000 steht.
Guter Hinweis.
Das könnte ich aber testen, muss es nur heute Abend zu den EC3000 hin tragen (das geht remote noch nicht) und schauen, ob es dann nicht mehr auftritt.

Btw. ein reinitialize falls zu lange keine Daten komme wäre doch ein Workaround oder?

Ja, das ist die Notlösung. Aber eigentlich würde ich lieber das Problem verstehen und die Ursache beheben als die Symptome zu unterdrücken.

[RaspiLED]

Hi HCS,
Wird Zeit für Dein neues Projekt: fhem Roboter auf ESP32 Basis
Gruß Arnd

Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...

[HCS]

Wird Zeit für Dein neues Projekt: fhem Roboter auf ESP32 Basis

Nicht mehr nötig, muss nicht in den Keller, habe das Problem wohl gefunden 

Ich habe die AGC mit dem rauchenden Colt in der Hand erwischt 

Nachdem ich ein paar mal im Zustand "geht nicht mehr" die Register des RFM69 rausgedumpt habe, ist mir aufgefallen, dass er eigentlich noch arbeitet aber in RegLna (0x18) entweder 0x28 oder 0x30 drin steht, was bedeutet, dass die AGC den LNA auf  Max gain -36dB bzw.  Max gain -48dB gesetzt hat, was bedeutet, dass schon ein heftig starkes Signal kommen muss, dass es da durch geht. Wenn da aber nichts durch kommt, dann bekommt die packet engine nichts und setzt den LNA nicht zurück. Ein Teufelskreis.
Eigentlich sollte RegLna, nachdem ein Paket empfangen wurde, wieder auf 0x08 stehen, da AutoRxRestartOn gesetzt ist.
Scheinbar gibt es den Fall, dass ein Paket nur so halb empfangen wird, die packet engine kein "payload ready" signalisiert und der RFM69 dann in diesem Zustand verbleibt.
Das dürfte auch der Grund sein, warum es manchmal (selten) auch wieder von selbst funktioniert. Ein mal ein Signal, das stark genug ist, und die packet engine hat den LNA wieder auf gemacht und es funktioniert wieder so lange, bis sich der RFM69 die Tür zuhaut.

Ich habe jetzt testweise mal die AGC deaktiviert, damit lief es die ganze Nacht über konstant.

Die AGC zu deaktivieren ist zwar auch nicht genau das, was ich mir vorstelle, aber vieleicht bekomme ich ja noch raus, warum der RFM69 sich mit aktiver AGC das antut.

@ext23: probier mal bitte mit der angehängten Test-Version, ob das bei Dir auch funktioniert.

Ach ja: wenn jemand fundierte Erfahrungen mit der AGC auf dem RFM69 hat, dann her damit.

[PeMue]

Ich habe die AGC mit dem rauchenden Colt in der Hand erwischt 

AGC = Automatic Gain Control?

[HCS]

AGC = Automatic Gain Control?

Ja.

[PeMue]

Ach ja: wenn jemand fundierte Erfahrungen mit der AGC auf dem RFM69 hat, dann her damit.

Das Thema wurde hier https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/rfm69-reception-issues-due-to-broken-agc/ schon mal diskutiert, wie fundiert das ist, kann ich nicht beurteilen ...

[HCS]

wie fundiert das ist, kann ich nicht beurteilen ...

Ja, der spricht über "mein" Problem. Warum hast Du das gefunden und ich nicht. OK, wenn man erst mal das Problem kennt, kennt man auch die keywords, die man suchen muss. 

Und er hat dann auch die AGC abgedreht und "max gain" konfiguriert, so wie ich gestern Abend.
Und das LGW empfängt die fünf EC3000 immer noch, seit 19 Stunden 

Ich stimme da sehr mit ihm überein, dass ein schrottig empfangenes Paket (das muss noch nicht mal von einer EC3000 gekommen sein) die AGC runter zieht und da stehen lässt.
Eigentlich müsste die packet engine den LNA gain nicht nur dann zurücksetzen, wenn der payload abgeholt wurde, sondern auch, wenn sie ein Paket verworfen hat.
Ich bin recht sicher, dass es sie auch im zweiten Fall meistens macht, aber scheinbar gibt es Fälle, in der sie es vergisst.

Danke für den Link, hatte schon Angst, dass ich mir nur einbilde, dass der RFM69 ein Fehlverhalten an den Tag legt 

Ich muss nur noch testen, was jetzt passiert, wenn das LGW direkt neben einer EC3000 steht. Weit weg geht super ...

[ext23]

OK ich hab die FW mal aufgespielt. Schauen wir mal. Sag mal diese initialization, kann man die nicht auch speichern im LGW? Wenn ich den LGW neu starte schnallt das FHEM manchmal nicht und schickt somit die init strings nicht neu. Oder es dauert einfach nur lange.

/Daniel