Closed sstidl closed 1 year ago
Ach ja: Ich verfolge das Projekt seit ca 3 Wochen und gratuliere euch zu dem tollen Projekt. Es gibt keinen schöneren Beweis, wie schön open source und gemeinsamer Forschergeist funktioniert!! Danke!
könntest du ein anderes USB Netzteil ausprobieren? Die WiFi Verbindung ist im allgemeinen sehr stabil und führt von selbst keinen reboot aus. Warum es zur Exception kommt kann ich versuchen aus dem Stack zu lesen, danke für's teilen
Ich hab das Problem sowohl am USB Anschluss vom Laptop gehabt als auch an einem Akku Pack als auch an USB Netzteil mit 1A. Mehr als 1A sollte der ESP hoffentlich nicht ziehen.
@lumapu ich glaube ich habe das auch ab und an gehabt.
Der WiFi Connect bricht manchmal weg, davon bekommt der Ahoy Code aber nicht zwingend etwas mit, da wir hierfür m.W. bisher kein ausreichendes Event Handling haben. Eventuell wird er durch einen Interrupt Handler sogar in die RX Methode und danach in die MQTT Publish Methoden verzweigt. Dann vergißt er eventuell dass er gar keinen TCP/IP Stack auf dem WiFi mehr hat ?
Das Problem ist dass dann der MQTT Stack hier jedesmal versucht die IP / den Namen des MQTT Brokers aufzulösen. Da er das teilweise für jedes einzelne Topic aus einer Nachricht macht, dauert es relativ lange bevor er zu etwas anderem kommt und somit schlägt vermutlich der Watch Dog zu.
Vielleicht kann @beegee3 sogar mal drüber schauen der hat ja einen analytischen Spürblick für solche Probleme :grinning:
@stefan123t danke für dein Vertrauen. Die payload.h und hmRadio.h sind allerdings sehr schwierig nachzuvollziehen. @lumapu hat zwar schon etwas mehr Struktur reingebracht, aber das meiste ist wohl noch aus der Anfangszeit. Insbesondere wäre es schön, wenn nicht von allen möglichen Programmteilen darauf zugegriffen würde, sondern das mehr zentralisiert wäre. Und ein paar Sachen scheinen noch vom Typ 'trial and error' zu sein (z.B. das setzen des RX Loop Counters). Aber das ist ja bekannt, s. #536 (ich glaube übrigens nicht, dass der Takt halbiert wird 😄). Andererseits habe ich das Problem mit Wifi Abbrüchen nicht. Ich habe einen stabil laufenden ESP32, keinen ESP8266. Vielleicht kann jemand, der beide ESP Typen hat, mal dahingehend prüfen?! Außerdem teste ich gerade eine Version, wo MQTT durch FTP ersetzt ist, d.h. anstelle des MQTT publish werden die Daten in eine CSV Tabelle auf einem FTP Server (fritz.box 😄) geschrieben. Ist natürlich nicht als MQTT Ersatz gedacht, ist nur für den Test praktisch, das MQTT Setting zu nutzen. Die Routinen für die Datenaufbereitung sind von MQTT übernommen. Das läuft seit einem Tag ohne Abbruch, was dafür spricht, dass Payload und Radio kein grundsätzliches Problem haben.
@beegee3 ja das mit dem Pakethandling würde ich auch gerne zentral in der hmRadio Klasse oder so sehen. Bisher steckt mir da auch noch zuviel Logik in app:loop() wo es mE nicht hingehört.
Ob die Trennung in hmRadio und payload notwendig ist, weiß ich aktuell nicht, evtl wenn payload (besser hmPayload ?) wirklich nur die Dekodierung der (zu sendenden und) empfangenen Pakete macht und in die in hmDefines definierten und von hmInverter genutzten Klassen schreibt ?
@cbscpe ist aktuell auch daran sich die hmRadio Methoden genauer anzusehen da er hierzu eine 5in1 NRF24 Scanner gebaut hat und dem Channel Hopping auf die Schliche kommen möchte...
@lumapu das hmSystem ist eigentlich ein ahoyDTUSystem und müsste dann um die Klassen miInverter etc erweitert werden oder sehe ich das falsch ?
Offtopic: @beegee3 Das mit FTP ist ein interessantes Feature. Ich nutze die Serial Logfiles mit einem entsprechenden Logfile Viewer dazu. Am liebsten wäre mir da auch eine CSV ähnliche Ausgabe die u.A. der Serial Plotter der Arduino IDE auch prima als Graph darstellen kann. Vielleicht kann man das per ESP Web Tools / WebHook auch direkt auf einer (unserer) Webseite tun ?
Hups ich glaube der ganze letzte Kommentar war OffTopic!
Also das Problem mit dem MQTT Connection Loss erscheint mir mit dem WiFi Connection Handling von Ahoy zusammenzuhängen.
@lumapu hier sollten wir mE auch eine klarere Trennung zwischen App und MQTT Ausgabe / Client bekommen oder einführen. Die App müsste dann dafür Sorge tragen dass die WiFi Verbindung vorhanden ist und ggf die ganzen MQTT Ausgabe(n) verhindern, bevor wir Daten hier zu versenden versuchen...
Liebe Leute, ich hab nun den 100uF Elko direkt am NF angelötet und obwohl es 3 resets danach gegeben hat, hat er die erste Nacht überstanden.
Offtopic:
Ich hab beim Versuch, eine 12V Versorgung anzubringen den usb2serial geschossen. Stromversorgung vom ESP hatte funktioniert, aber der ch341 ist heiß und stinkig geworden.
Ist das nicht erlaubt?
In der Spezifikation steht bis 19V Input (Vin) möglich.
Edit: heute noch Mal geschaut, 10V max, selbst schuld. :-(
@stefan123t
Also das Problem mit dem MQTT Connection Loss erscheint mir mit dem WiFi Connection Handling von Ahoy zusammenzuhängen.
Glaube ich eher nicht, sobald die Wifi Verbindung steht, macht ahoywifi
aktiv nichts mehr. Erst mit Verbindungsverlust wird versucht diese wieder herzustellen. MQTT versucht allerdings gleichzeitig auch die Verbindung zum Server herzustellen. Das ist natürlich viel zu früh, macht erst Sinn, wenn die IP vom Router vorliegt (GotIP
event). Das gilt auch schon für den Boot/Reboot.
Eigentlich sollte die app::loop bei nicht vorhandener Wifi Verbindung nur (!) den wifi Ticker laufen haben. Auch Payload und Radio loops müssen nicht sein. Das sollte sich erst mit GotIP
ändern. Wegen der UTC timestamp Bezüge im Code würde ich die MQTT Verbindung erst nach erfolgreichem NTP Update aufbauen. Mit den Wifi events in ahoywifi
, Schnittstelle zu app
und einer deleteAllTicker
Funktion im Scheduler
könnte man sinnvoll auf die verschiedenen Wifi Zustände reagieren. Werde morgen mal einen Code Vorschlag dazu machen (hab' heute leider keine Zeit mehr).
Offtopic FTP
Das mit FTP ist ein interessantes Feature...
Wegen der ganzen Debug Infos am seriellen Port wird eine CSV ähnliche Ausgabe dort schwierig, ansonsten nette Idee!
@sstidl offenbar bringt auch bei Dir der 100uF Elko am NRF24 etwas. Vielleicht packst Du auch noch einen zweiten 220uF an die 5V Schiene des ESPs damit der auch stabil läuft.
Nachdem Dein CH341 abgeraucht ist müssen wir annehmen, dass es wohl noch ein bißchen dauert, bis Du wieder dazu kommst das Problem mit einem neuen ESP weiter zu analysieren.
@sstidl offenbar bringt auch bei Dir der 100uF Elko am NRF24 etwas. Vielleicht packst Du auch noch einen zweiten 220uF an die 5V Schiene des ESPs damit der auch stabil läuft.
Nachdem Dein CH341 abgeraucht ist müssen wir annehmen, dass es wohl noch ein bißchen dauert, bis Du wieder dazu kommst das Problem mit einem neuen ESP weiter zu analysieren.
Du wirst lachen, seit der ch341 kaputt ist, funktioniert alles einwandfrei. Vielleicht hat der viel Strom gefressen und jetzt ist er ruhig. Solange ich per OTA Update brauche ich noch keinen neuen ESP. 😉
Wie der Teufel so will: Das Ding ist jetzt 5 Tage ohne reboot gelaufen. Dann hab ich heute den Power Level von HIGH auf MIN gestellt, weil der Inverter quasi durchs Fenster draußen am Balkon nur 3m Distanz überwinden muß. Kommunikation hat sauber geklappt. Dh Power Level ok. Nach 25 Minuten wieder reboot wg exception.
Das war vor 10min. Ich beobachte und berichte weiter.
Ok. Wieder auf HIGH Power Level gestellt und es läuft stabil. @stefan123t woran könnte das liegen? Ist doch unlogisch, dass es mit mehr Power stabiler ist?
@sstidl gibt es Neuigkeiten oder kann man von "resolved" ausgehen?
@sstidl gibt es Neuigkeiten oder kann man von "resolved" ausgehen?
Ich würde sagen, resolved. Auch wenn ich nicht verstehe wieso HIGH Power Level stabiler ist als normaler Level.
Platform
ESP8266
Model name
NodeMCU V3.4 ESP8266 ESP-12 E Lua CH340 https://www.makershop.de/plattformen/esp8266/nodemcu-esp8266-dev-kit/
nRF24L01+ Module
nRF24L01+ plus
Antenna
circuit board
Power Stabilization
~100uF Elko
Connection diagram
genau wie hier https://github.com/lumapu/ahoy/blob/main/Getting_Started.md#esp8266-wiring-example
Connection picture
Version
0.5.66
Github Hash
f8fe044
Build & Flash Method
ESP Tools (flash)
Desktop
Linux
Setup
Debug Serial Log output
Error description
Alles scheint zu laufen, doch zufällig kommt es dann zu einem Verbindungsverlust: Meldung
I: MQTT disconnected, reason: TCP disconnect
nach dem dritten Mal (warum auch immer das Disconnect stattfindet, das Gerät liegt in Sichtweite vom WLAN Router und auf dem MQTT Server gibt es keine Ausfälle)danach braucht es eine Minute oder so, dann versucht er reconnect des WLANs. Offenbar mehrfach:
danach Exception und Reboot
Ich hab auch probiert, das zu erzwingen, in dem ich mqtt server restartet hab, da kommt auch die disconnect Meldung, aber alles geht normal weiter. Ich vermute, dass der WIFI Stack im ESP sich vertut.