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

[HCS]

Ich hatte mal USB Kabel mit anscheinend zu geringem Cu-Querschnitt. Da gabs beim WiFi Connect immer kurze Spannungseinbrüche. Mit dem Multimeter natürlich nicht feststellbar.  Beim WiF-Connect werden hohe Ströme benötigt. Nach Tausch auf ,gute' USB Kabel hat sich das Problem erledigt und mein LGW verbindet sich seitdem sicher und  auch ,immer'.

Ja,. genau solche Dinge meinte ich oben. Weil:
- USB-Kabel sind oft "nur" für Datenübertragung ausgelegt, wo natürlich keine hohen Ströme fleißen müssen
- Telefon-Ladegeräte müssen laden und sind ncht unbeding eine Konstantspannungsquelle, dem Telefon und seinem Akku ist ein kurzer Spannungseinbruch egal, einem Prozessor nicht
- Manche Ladegeräte legen irgend eine "Intelligenz" an den Tag, was für einen Prozessor, der ein konstante Spannung will, auch nicht sinnvoll ist.

Aber alles nur denkbare Probleme, die sich allerdings auch erst in Kombination (schlechtes Netzteil + schlechtes Kabel + schlechte Empfangssituation) dann manchmal auswirken.

Uptimes von 38 Tagen wären bei mir Traumwerte. Ich glaube mein Rekord lag mal bei 12 Tagen.

Ja, und "nur" 38 Tage, weil ich vor 38 Tagen den Strom abstellen musste.

Wobei 38 Tage nicht das erforderliche Ziel sind. Der ESP8266 muss sich bei jeden boot sich mit dem AP verbinden.

[sash.sc]

Habe mal die usb Kabel ausgetauscht, gegen etwas bessere Qualität, wie die bei den Handys dabei sind.
Seit dem gibt es keine Probleme mehr.

Und seit dem ist auch der Ladestrom für das Handy bis zu 30% höher.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[HCS]

Habe mal die usb Kabel ausgetauscht, gegen etwas bessere Qualität, wie die bei den Handys dabei sind.
Seit dem gibt es keine Probleme mehr.

Jetzt müssen wir herausfinden, woran man ein gutes USB-Kabel erkennt (also ohne Versuch und Irrtum)
Oder wie man die Qualität ermittelt.

OK, 2A drüber ziehen und den Spannungsabfall messen, ist aber vermutlich nicht für jeden durchführbar.

[sash.sc]

Ich habe z. B. Diese hier. Bin damit zufrieden.
Diese gibt es auch noch in anderen Längen.


OTISA 3Pack 1.8m Nylon Micro USB auf USB Kabel High Speed USB 2.0 Datenkabel für Android Smartphones Samsung /HTC / Nokia/ LG https://www.amazon.de/dp/B01MCYWK05/ref=cm_sw_r_cp_apap_7bAymczR1NriW


Gesendet von meinem E6653 mit Tapatalk

[marco-f]

Ich hab heute Nachmittag einen kleinen Reboot-Marathon hingelegt mit diversen Netzteilen und Kabeln. Ins Rennen geschickt wurden 5V 1A Handynetzteile von Asus, Samsung, HTC, ein Meanwell T-60B Schaltnetzteil mit 5V 5A und die USB 3.0 Ports meines PC's. Kombiniert wurde alles mit Micro-USB Kabeln von Samsung, Nokia, HTC und einem kurzen 10cm Kabel meiner Power-Bank.

Ergebnis: Eigentlich Nix! Sämtliche Netzteile in Kombination mit sämtlichen Kabeln brachten das gleiche Ergebnis, dass es immer wieder den Zustand gab, dass das LGW auf dem Display das Connected Symbol anzeigte, gleichzeitig ein RSSI von 30dBm ausgab und das LGW nicht im WLAN registriert war (siehe mein Bild von heute Mittag).

Das Einzige was heute wirklich auffiel - jeder zweite Connectversuch schlug fehl. In der Vergangenheit hatte ich dieses Gefühl auch schon das ein oder andere Mal, aber sporadisch gab es auch Ausnahmen, heute war es aber die Regel. D.h., LGW ist ordentlich verbunden, dann mach ich Strom ab & wieder dran, sende über FHEM einen Reboot oder drücke den Reset Button am NodeMCU und ich hab das oben beschriebene Fehlverhalten. Erneut Strom ab & wieder dran oder Reset Button - voila, erfolgreicher Connect. 


Ich könnte jetzt mal noch versuchen mir ein spezielles Kabel zu bauen mit ordentlich Querschnitt zwischen MicroUSB Stecker und USB Buchse, oder mal mit nem Speicheroszi schauen was die 5V Schiene macht wenn ich das Teil starte, aber nach den Beobachtungen von heute Nachmittag glaube ich kaum dass ich damit noch irgendwas erreiche.

[HCS]

Ich könnte jetzt mal noch versuchen mir ein spezielles Kabel zu bauen mit ordentlich Querschnitt zwischen MicroUSB Stecker und USB Buchse, oder mal mit nem Speicheroszi schauen was die 5V Schiene macht wenn ich das Teil starte, aber nach den Beobachtungen von heute Nachmittag glaube ich kaum dass ich damit noch irgendwas erreiche.

Glaube ich auch nicht.

Neuer Anlauf: steck es an einen Rechner und führe ein flash erase durch.

Code Auswählen Erweitern

esptool.py --port COM3 erase_flash
bzw.

Code Auswählen Erweitern

esptool.py --port /dev/ttyWasAuchImmmer erase_flash

Den Port entsprechend anpassen.
Das bringt es in den Zustand, wie es ab Werk war.

Danach firmware neu aufspielen und neu konfigurieren.

Der ESP8266 merkt sich einige "WiFi-Dinge" im flash, vielleicht ist da irgendwo der Wurm drin.

Hast Du einen Range-Extender in Betrieb?
Das soll angeblich auch mit dem ESP8266 manchmal ein Problem sein.

[PeMue]

Neuer Anlauf: steck es an einen Rechner und führe ein flash erase durch.

Für Windows Nutzer geht das auch mit dem NodeMCU Flasher.

Gruß PeMue

[heka]

Vielleicht hilft es, hier mein fhem listing vom LGW:

Code Auswählen Erweitern


Internals:
Alive 2017-10-16 21:56:24
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.10.38:81
DeviceName 192.168.10.38:81
FD 4
NAME myLaCrosseGateway
NR 48
PARTIAL
RAWMSG OK 9 3 1 4 214 106
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.30
myLaCrosseGateway_MSGCNT 749781
myLaCrosseGateway_TIME 2017-10-16 21:58:50
settings (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868980 r:6631) + BME280 + OLED {IP=192.168.10.38}]
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
4:EMT7110  ^OK\sEMT7110\s
5:Level ^OK\sLS\s
6:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2017-10-16 21:58:50 analog 965
2017-10-16 21:58:50 state initialized
helper:
Attributes:
initCommands 2,868980,120i v
room CUL
timeout 180
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
watchdog 300


[marco-f]

Hast Du einen Range-Extender in Betrieb?
Das soll angeblich auch mit dem ESP8266 manchmal ein Problem sein.

Nein. Eine Fritz!Box 7490 im Keller und ein Linksys Access Point mit DD-WRT im OG, beides als getrennte Netzte mit verschiedenen SSIDs.

Platt machen und neu aufspielen werde ich wahrscheinlich heute Abend mal in Angriff nehmen, aber erstmal verfolge ich noch eine andere Spur.

Ich habe gestern Abend nach meinem letzten Posting noch ein paar interessante Beobachtungen gemacht. Ich hab, eher aus Verzweiflung, geschaut ob ich das Ganze nicht zur Fehlereingrenzung noch weiter minimieren kann. Zu Testzwecken hab ich dann mal den RFM69 entfernt, also nur noch NodeMCU und Display gestartet. Und siehe da ... plötzlich buchte sich der NodeMCU nach jedem Reboot sicher ins WiFi ein. Als ich dann den RFM69 wieder anschloss und alles gestartet habe lief mal zufällig keine Musik im Hintergrund und ich vernahm plötzlich kurzzeitig ein leises Summen. Und beim nächsten Reboot wieder. Ich entdeckte, dass das Summen immer dann auftritt wenn auf dem Display erscheint "Connect WiFi". Ich hab dann das LCD abgeklemmt, also nur NodeMCU mit RFM69 gestartet und auch hier waren plötzlich alle Startversuche erfolgreich.
Nach diesen Beobachtungen war für mich der 3,3V Festspannungsregler auf dem NodeMCU der Verursacher, denn mir nur einem weiteren Verbraucher klappte es immer. Später in der Nacht hatte ich dann den NodeMCU mal 15-20 Minuten stromlos und wollte ihn siegessicher nur mit dem RFM69 wieder starten, da leuchtete auf einmal am ESP ne fette blaue LED und er buchte sich wieder nicht ein. Nach einem Reboot klappte es dann, aber dieses Verhalten dass nach längerem Stromlos sein der ersten Bootvorgang fehlschlägt lies sich wiederherstellen. Und das immer in Verbindung mit der blauen LED am ESP, ich konnte also noch im Bootvorgang anhand der LED sehen ob es erfolgreich ist oder nicht.

Ich will mal sehen dass ich heute an meiner Spannungsversorgung n bissel was umbaue. Einerseits mal schauen ob es was ändert wenn ich nicht über die USB Buchse sondern über VIN versorge, andererseits mal die 3,3V für den RFM und das LCD über einen Zusätzlichen Spannungsregler erzeugen so dass der Regler auf dem NodeMCU wirklich nur den ESP versorgen muss.


P.S.: In der Zwischenzeit hab ich ausversehen das LGW aus der Ferne rebootet und es hat sich wieder nicht connected. 

[HCS]

Ich habe begonnen, den BME680 in das LGW zu implementieren.
Der BME680 misst Temperatur, relative Luftfeuchte, Luftdruck und VOC (Volatile Organic Compounds)

Diskussion, Probleme und Fortschritte dazu siehe hier: https://forum.fhem.de/index.php/topic,78128.msg700815.html#msg700815

[marco-f]

Ich habe einen Durchbruch erzielt. Ich kann den Fehler jetzt Ein- und Ausschalten und sogar austricksen.

Die Vermutung mit dem Problem auf der 3,3V Schiene war ne Sackgasse. Die Tatsache dass der NodeMCU allein mit dem RFM69 vorgestern eine Weile problemlos startete hatte andere Ursachen, die ich in dem Zeitpunkt aber noch nicht im entferntesten in Zusammenhang bringen konnte. Dazu später mehr ...

Für Windows Nutzer geht das auch mit dem NodeMCU Flasher.

Das klappte nicht wirklich. Ich hab wie in der Anleitung genannt die ganzen Einträge gemacht, überall das x gesetzt und geflasht. Der NodeMCU schien auch leer zu sein, zumindest tat sich beim Start nichts mehr. Nachdem ich das LGW wieder geflasht hatte, waren aber sofort alle Setup-Einstellungen wieder drin. Also kann nicht alles gelöscht gewesen sein.

Neuer Anlauf: steck es an einen Rechner und führe ein flash erase durch.

Code Auswählen Erweitern

esptool.py --port COM3 erase_flash
bzw.

Code Auswählen Erweitern

esptool.py --port /dev/ttyWasAuchImmmer erase_flash

Das klingt immer so schon einfach. Ich als Linux-DAU hab erstmal gefühlt zwei Stunden gebraucht um Python, pip und esptool auf den Raspberry zu bekommen. Aber dann konnte ich es damit löschen und nach dem LGW flashen war es diesmal wirklich jungfräulich.

WiFi Einstellungen vorgenommen, reboot und getestet. Zig Reboots, immer wieder Strom weggenommen, und immer startete es. Ein erstes Erfolgsgefühl stellte sich ein. Also alle Setup-Einstellungen wieder eingertragen und reboot ... ... Fehler war wieder da! Nun war ich mir schon ziemlich sicher dass es an irgendwelchen Einstellungen liegen musste und ich habe durchprobiert wann der Fehler wieder eintritt.

Das Ergebnis war das Startup Delay! Steht das bei 0, klappt der Reboot immer. Stelle ich das auf 30, dann schlägt jeder 2. Reboot fehl. Das dort was nicht hinhaut war mir schon vorgestern aufgefallen, da hab ich aber noch keinen Zusammenhang gesehen. Wiki sagt zum Delay "Mit diesen Konfigurationsprameter kann eine Verzögerung (in Sekunden) definiert werden, bis das LGW nach einen Neustart einen ersten Verbindungsversuch zum WiFi Access Point (Router: Fritzbox etc.) startet." - das macht es bei mir nicht! Trotz in meinem Fall eingetragenen 30 Sekunden reagiert das LGW sofort nach der Versorgung mit Spannung innerhalb des Delays auf Pings, es muss also sofort wieder eine Verbindung herstellen. Nach Ablauf der Delay-Zeit, wenn auf dem Display "Connect Wifi" erscheint, bricht dann die Verbindung zusammen und es ist der von mir beschriebene Fehler da.
Einzige Ausnahme ist, wenn man einen Dauer-Ping auf das LGW laufen hat, dann tritt dieser Fehler nicht auf. Das war auch der Grund warum ich vorgestern dachte dass NodeMCU + RFM69 alleine problemlos starten - da ich kein Display mit Anzeigen mehr hatte lief auf dem Rechner ein Dauerping weil ich daran sehen konnte in welchem "Zustand" an LGW gerade ist.

Meine erste Abhilfe jetzt lautet Startup-delay auf 0 setzen, aber das hat ja jetzt wieder was von Auswirkung statt Ursache bekämpfen. Beim nächsten Netzwischer hängt dann das LGW wieder in der Luft, weil der AP nicht so schnell startbereit ist.

Und jetzt hoffe ich dass dieses Phänomen reproduzierbar und behebbar ist.

MfG
Marco

[PeMue]

Das klappte nicht wirklich. Ich hab wie in der Anleitung genannt die ganzen Einträge gemacht, überall das x gesetzt und geflasht. Der NodeMCU schien auch leer zu sein, zumindest tat sich beim Start nichts mehr. Nachdem ich das LGW wieder geflasht hatte, waren aber sofort alle Setup-Einstellungen wieder drin. Also kann nicht alles gelöscht gewesen sein.

Sonderbar, ich hatte mal auf einem WeMos D1 mini mit ESPEasy geflasht und dann mit dieser Methode "leer" gemacht. Das hat funktioniert. Werde das mal mit dem LGW probieren ...

Gruß PeMue

[HCS]

Meine erste Abhilfe jetzt lautet Startup-delay auf 0 setzen, aber das hat ja jetzt wieder was von Auswirkung statt Ursache bekämpfen. Beim nächsten Netzwischer hängt dann das LGW wieder in der Luft, weil der AP nicht so schnell startbereit ist.

Das funktioniert mit Startup-delay 0 trotzdem, aber Du musst eventuell den Timeout auf der Setup-page für die erste SSID hochsetzen, auf einen Wert, der länger als die Zeit von Deinem AP ist, bis er hochgefahren ist.
Genau dieses Thema habe ich in V1.23 erledigt. Siehe hier:
https://forum.fhem.de/index.php/topic,43672.msg512376/topicseen.html#msg512376
Zitat daraus:

V1.23
Connectverhalten auf einen AP
Das ganze kommt aus dem Stromausfall-Thema, bei dem das LGW viel schneller als der AP bereit ist und bereits aufgibt, bevor der AP nach ein bis zwei Minuten bereit ist, einen Connect anzunehmen.
   
Man kann nun auf der Setup-Page für beide SSIDs einen Timeout konfigurieren.
120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen.
Diese Zeit war bisher hart in der Frimware auf 15 Sekunden festgelegt.
Dafür kann man dann das Startup-delay wieder auf 0 stellen.

Ich habe "Stromausfall" wie folgt simuliert und getestet:
- AP aus/ein, LGW bleibt an
- LGW aus/ein, AP bleibt an
- LGW + AP aus/ein

In allen drei Fällen kam die Verbindung wieder zustande und nach ein bis zwei Minuten sind wieder Daten in FHEM eingelaufen.

Und jetzt hoffe ich dass dieses Phänomen reproduzierbar und behebbar ist.

OK, das kann ich mal versuchen zu reproduzieren (und ggf. zu korrigieren).
Ich überlege gerade, wozu man das Startup-Delay überhaupt noch braucht.

Der Hammer, wie Du das rausexperimentiert hast, auf die Idee wäre ich nie gekommen 
Suchst Du gerade eine neue Stelle als Tester?

[marco-f]

Ok, stelle ich mal den Timeout hoch. Für mich klang der Startup-Delay nur damals nach genau dem was ich gesucht habe, als eben nach einem Netzwischer das LGW nicht wieder hoch kam.

An teilweise haarsträubende Fehlersuchen gewöhnt man sich in 15 Jahren Nachrichtentechniker irgendwann. Das Problem ist nur immer nicht irgendwann den Enthusiasmus zu verlieren.

[HCS]

Und jetzt hoffe ich dass dieses Phänomen reproduzierbar und behebbar ist.

Zumindest reproduzierbar. Mit 30 Sekunden delay geht es tatsächlich nur jedes zweite mal 
Ich werde der Sache mal auf den Grund gehen.