Klar, muss nur irgendwo per setState() einmalig oder wiederholt gesetzt werden, der Rest passiert automatisch. Habe erst heute Abend Zeit. Habe meinem Sohn eine ausgiebige Motorradtour zugesagt, bei dem Wetter. Die Pferde werden gerade gesattelt. 
1 „Gefällt mir“
Ich hätte den setState für den RSSI dort rein wo du auch die uptime setzt, ich denk das würd reichen. Wenn das OK ist für dich mach ich wieder einen PR.
lg,
Jürgen
Guck doch mal ob das wifi Modul schon ein Loop hat. Da wäre es eigentlich, von der Logik her besser aufgehoben.
Ich habe zwar jetzt eine wifi_loop inkludiert, hab aber auch das ganze state-zeugs in eine eigene h/cpp ausgelagert - ich fand das irgendwie nicht ganz passend im mqtt_handler.
Vielleicht kannst du bei Gelegenheit mal drüberschaun, ich habe einen PR erstellt.
lg,
Jürgen
Das verstehe ich nicht. Die states sind Bestandteil des MQTT stacks und werden nirgends anders verwendet außer für die Sendung über MQTT, quasi ein Cache für MQTT. Da ein separates Modul zu machen, macht es nur unübersichtlicher.
Naja, die map beschreiben wir im ble_client und wifi_handler (und eben im mqtt_handler), deswegen.
Aber wie gesagt, nur ein Vorschlag, kannst es natürlich auch verwerfen, dann mach ma nur die wifi_loop wie von dir vorgeschlagen und gut is 
Done, neuer PR ist raus! 
Es gibt da noch ein anderes Problem. Nach 5-6 Stunden scheint sich die MQTT Verbindung aufzuhängen und sich nicht neu zu verbinden. Ein paar mal habe ich in diesem offline Status eine vermurkste IP Adresse im Status im MQTT Explorer gesehen. Ich kann nur sehr schwer seriell debuggen, weil es erst nach Stunden auftritt und der Speicher im Keller steht.
Ich versuche das Problem erstmal einzukreisen, indem ich den ESP Neustarte nach 10 vergeblichen MQTT Verbindungsversuchen. Wenn das wirkt, weiß ich zumindest schon mal, dass er in der reconnect Schleife festhängt und nicht verbinden kann.
Tritt bei mir nicht auf, ich habe allerdings am derzeitigen Standort guten WiFi Empfang, dafür schlechte BT Verbindung 
EDIT: Denkfehler, tritt bei mir ja vermutlich deswegen nicht auf, weil die schlechte BT Verbindung den ESP sowieso im <1h Zeitraum resettet.. Ich werde mal meinen ESP an einer für BT günstigeren Stelle platzieren und teste dann ob das bei mir auftritt..
Aber grundsätzlich ist mir das auch schon aufgefallen dass der MQTT reconnect faktisch eine "fire and forget" Aktion ist.
Hatte da in meinem Projekt schon viele Probleme, die allesamt nur auftraten, wenn die WiFi Verbindung schlecht war.
Eventuell mal den WiFi RSSI checken? Ich habe derzeit -47 dBm oder so.
lg,
Jürgen
Meine ESP sind 1m vom Unifi Mesh Accesspoint entfernt. Okay, dieser hat „nach oben“ nicht die beste Verbindung, Aber wifi kann ich glaube ausschließen. Wenn der Restart Abhilfe bringt, werde ich als nächsten Schritt den reconnect jeweils mit einer neuen pubSubClient Instanz probieren. wenn das dann die Lage wieder verschlechtert kann es eigentlich nur noch an dem wifi.Client liegen, der dem MQTT Client im constructor übergeben wird. Ohne seriell zu loggen ist das halt Mist.
hmm, ja das ist blöd, damit sagt der RSSI am ESP natürlich auch nichts mehr aus..
eventuell dass wir vorsichtshalber bei MQTT reconnect auch das WiFi vorher frisch verbinden?
So, nach langem probieren habe ich es nun auch zum Laufen gebracht.
Letztendlich hat das zusätzliche Einbinden der macros.h in der influxdb_handler.cpp den oben gezeigten Fehler beseitigt.
Wenn ich jetzt so drüber nach denke, dürfte der eigentliche Fehler in der influxdb_handler.h liegen und das #include "config.h" in Zeile 8 müsste #include "macros.h" heißen.
@juepi79 kannst Du Dir das mal anschauen und ggf. noch in deinen PR einbauen? Ich komm gerade zu nix, die ganze Familie liegt flach und ich bin der einzige, der die Grippe schon überstanden hat. Ich kämpfe auch immernoch mit dem toten PubSub Client, der sich nicht wieder connected. Habe jetzt gelesen, das man vor dem reconnect den wifi Client stoppen soll, weil es sein kann, dass noch ein offener Socket den Mosquitto blockiert. Ich habe dazu in der mqtt Loop, dort wo der disconnect festgestellt wird ein wifi_client.stop(); eingebaut, vor dem reconnect. Das soll den offenen socket killen. Test läuft gerade
Völlig richtig, die Einbindung der macros.h hat auch im rs485-teil noch gefehlt, sorry! 
Habe beide header files korrigiert und in den PR übernommen!
lg,
Jürgen
1 „Gefällt mir“
Ach so, ja das klingt nicht unplausibel, da ja der broker nur eine Verbindung pro client (bzw. client name) zulässt, und wenn die TCP session nicht sauber geschlossen wurde muss die möglicherweise erst in ein Timeout laufen bevor man reconnecten kann.
Da das aber ausschließlich den Host betrifft auf dem der broker läuft würde es mich wundern wenn ein reconnect vom WiFi am ESP da was ändert.
Ich habe jetzt etwas recherchiert und bin jetzt über das cleanSession flag bei der connectFunktion des PubSubClients gestoßen. Ist leider in der API etwas schlecht (gar nicht) dokumentiert was das genau macht, ich habe in einem Forum aber diese Erklärung gefunden:
cleanSession: A boolean indicating whether the broker should start a new session for the client (clean session) or resume an existing session.
Ich vermute dass genau das dein Problem beheben könnte und habe das geänderte connect jetzt auch in den PR aufgenommen.
Update 11.4.25: Für alle welche die aktuell von mir verwendete Version (PR steht bei @waldmaus noch aus) testen wollen, ihr findet den Code hier:
Läuft bei mir seit mehreren Wochen problemlos. Der ESP resettet bei mir ab und an wegen einer (vermute ich) eher schlechten BT Verbindung (man hört auch ab und zu das BMS piepsen wenn der ESP die Verbindung neu aufbaut), aber kommt immer wieder sauber hoch und leitet die Daten zuverlässig an den Broker weiter.
lg,
Jürgen
Hallo Jürgen,
kurze Frage, ist noch geplant über die RS485 Schnittstelle auslesen zu können oder funktioniert das mittlerweile gar schon?
LG
Wolfgang
Servus Wolfgang,
Kann ich dir leider nicht genau sagen, verwende die Firmware nur mit BT. So wie ich das verstanden hätte sollte es funktionieren - RS-485 adapter vorausgesetzt.
lg,
Jürgen
Super, danke für die Antwort.
Ich werde es morgen mal austesten und berichten (wenn ich es hin bekomme.-)).
Habe jetzt 3 JK-BMS im Einsatz und die Bluetooth Verbindung geht des Öfteren verloren, daher wäre für mich RS485 perfekt.
Hallo,
zur Info, ein ESP32 kann max 3 BLE Schnittstellen handhaben.
Die Erkenntnis zu erlangen hat mich letztes Jahr einige Zeit gekostet.
Ich habe (zwar in einer anderen Anwendung) 4 JK-BMS und deshalb 2 ESP32 welche die 4 JK-BMS auslesen.
Kurze Meldung von mir. Ich kann zur Zeit aus beruflichen und familiären Gründen nicht am Projekt arbeiten. RS485 ist vorgesehen, aber nicht implementiert. Momentan wird über BLE pro BMS ein ESP32 benötigt. Der BMS Name wird über das Build Target oder die config.h beim flashen festgelegt. Ich habe hier 2 BMS mit 2 ESP32 laufen. Leider sind wir den reboots noch nicht wirklich auf die Spur gekommen. Manchmal ist nach 5h-20h die MQTT Verbindung weg. Es ist nicht wirklich reproduzierbar. Meine BMS sind 2 Etagen tiefer im Keller. Somit fällt permanentes loggen an der seriellen Konsole aus. Die Neustarts sind aber auch nichts problematisches, der ESP ist ja nach 10 Sekunden wieder mit Daten am Start.
Es steht noch ein Pullrequest aus. Wenn ihr Probleme mit dem aktuellen GIT habt könnt ihr auch mal den Fork testen, dem der PR zugrunde liegt.