[ESP8266] mqtt connection loss, exception #548
Comments
|
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. |
|
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. Das Problem ist dass dann der MQTT Stack hier jedesmal versucht die IP / den Namen des MQTT Brokers aufzulösen. Vielleicht kann @beegee3 sogar mal drüber schauen der hat ja einen analytischen Spürblick für solche Probleme 😀 |
|
@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 😄). |
|
@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 |
|
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, Offtopic: |
Glaube ich eher nicht, sobald die Wifi Verbindung steht, macht Offtopic FTP
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, |
Du wirst lachen, seit der ch341 kaputt ist, funktioniert alles einwandfrei. Vielleicht hat der viel Strom gefressen und jetzt ist er ruhig. |
|
Wie der Teufel so will: Das war vor 10min. Ich beobachte und berichte weiter. |
|
Ok. Wieder auf HIGH Power Level gestellt und es läuft stabil. |
|
@sstidl gibt es Neuigkeiten oder kann man von "resolved" ausgehen? |
Ich würde sagen, resolved. |
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
{ "generic": { "version": "0.5.66", "build": "f8fe044", "wifi_rssi": -61, "ts_uptime": 691, "esp_type": "ESP8266" }, "system": { "ssid": "xx", "device_name": "AHOY-DTU", "mac": "xx", "hostname": "AHOY-DTU", "pwd_set": false, "prot_mask": 61, "sdk": "2.2.2-dev(38a443e)", "cpu_freq": 80, "heap_free": 18048, "sketch_total": 2646016, "sketch_used": 486, "version": "0.5.66", "build": "f8fe044", "wifi_rssi": -61, "ts_uptime": 691, "esp_type": "ESP8266", "radio": { "power_level": 2, "isconnected": true, "DataRate": 2, "isPVariant": true }, "statistics": { "rx_success": 23, "rx_fail": 0, "rx_fail_answer": 1, "frame_cnt": 110, "tx_cnt": 29 }, "core_version": "3.0.2", "flash_size": 4096, "heap_frag": 5, "max_free_blk": 7504, "reboot_reason": "Exception", "schMax": 9 }, "inverter": { "inverter": [ { "enabled": true, "id": 0, "name": "HM-800", "serial": "xx", "channels": 2, "version": "10010", "ch_max_power": [ 490, 490 ], "ch_name": [ "Panel1", "Panel2" ] } ], "interval": "30", "retries": "5", "max_num_inverters": 10 }, "mqtt": { "broker": "192.168.0.2", "port": "1883", "user": "", "pwd": "", "topic": "inverter" }, "ntp": { "addr": "pool.ntp.org", "port": "123" }, "sun": { "lat": "48.20820", "lon": "16.37380", "disnightcom": true, "offs": 0 }, "pinout": { "cs": 15, "ce": 2, "irq": 0, "led0": 255, "led1": 255 }, "radio": { "power_level": 2, "isconnected": true, "DataRate": 2, "isPVariant": true }, "serial": { "interval": 10, "show_live_data": false, "debug": true }, "static_ip": { "ip": "192.168.0.55", "mask": "255.255.255.0", "dns1": "192.168.0.2", "dns2": "8.8.8.8", "gateway": "192.168.0.1" } }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 disconnectnach 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.
The text was updated successfully, but these errors were encountered: