Hehe, ja DAS ist bei mir definitiv der Fall! das BMS ist im Keller in einer Metallbox, der ESP im EG darüber..
BLE RSSI -91 dBm
Ok, dann geh ich dem mal nicht weiter nach. Habe trotzdem ein paar Änderungen gemacht die wir (du 
) eventuell übernehmen könnten:
Muss noch a bissl testen und mach dann einen PR.
lg,
Jürgen
Na dann ist der NTP Sync ja genau richtig. Für die uptime kannst Du ja dann time_t und difftime() nutzen. Musst dir nur die time.h reinziehen
Ich habe mir noch einen Unifi Mesh AP in den Keller gehängt. Jetzt haben die Mäuse und die ESP einwandfreies WLAN und können direkt auf den Speichern rumliegen.
Wenn Du am /Status werkelst- vielleicht mal den RSSI Wert öfters publizieren. Momentan kommt der nur 1x beim Start. Vielleicht jede MIN_PUBLISH_TIME sekunde.
Ja das ist mir auch schon negativ aufgefallen
Ich denke die saubere lösung wäre, das Publizieren der /status messages aus der reconnect funktion rauszulösen in eine dedizierte Funktion, die dann (entsprechend mit MIN_PUBLISH_TIME) in der mqtt_loop aufgerufen wird?
Jo, hört sich nach nem Plan an. IP Adresse kannst Du aber rauslassen, die braucht es ja nur beim starten 
Jein, könnte sich bei einem WiFi reconnect ändern
phuuuuu, gar nicht so einfach, da du die publish der stati über den gesamten code verteilt hast..
Naja, sind quasi so statische Ausgaben, die auch im originalcode so waren. Du kannst aber auch eine get/setState Funktion mit nem enum, welcher Wert das ist, einbauen. Oder alle möglichen states in eine globale struct packen. Oder beides zusammen. Die setState() sollte den jeweiligen Wert auch gleich als einzelwert publizieren während im Loop die getState() alle Werte durchklingelt und published
Du überschätzt meine Programmierfähigkeiten immer noch massiv! 
Im Zeitalter von ChatGPT keine Ausrede. Bei mir läuft auch Github Copilot direkt im VS-Code, sonst würde ich nie so schnell sein mit cpp. Den halben parser hat die AI gemacht, nach dem 3. Block brauchte ich nur noch die TAB Taste und kurzen Kontrollblick
Ja is recht, ich commite den schmarrn den ich da jetzt probiert hätt trotzdem nicht, das hat's nur verschlimmbessert 
Alles gut, ich gucks mir später mal selbst an. Ich habe den Lösungsansatz schon im Kopf, nur grad ein Problem auf Arbeit, was höhere Prio hat. Wird wohl ne Nachtschicht. 
Ich hab meinen Branch jetzt entfernt und einen neuen erstellt mit einem commit, wo ich nur ein paar kleine Fehler (falsche Datentypen, unbenutzte var/defines) korrigiert habe, plus die Publizierung des "reset reason" reingenommen hab.
Ich hab auch die NTP config in die config.h migriert und alternativ die Zeitzonen-config auf configTzTime geändert. Das hätte den Vorteil, dass er die Umstellung Sommer-/Winterzeit automatisch macht.
Version ist auf 0.1.7 hochgezogen.
Die Änderungen sind so weit gestestet, läuft bei mir, PR habe ich erstellt!
lg,
Jürgen
Habe es jetzt mal so umgesetzt, wie angedroht und die 0.1.8 committed. Dein PR wurde integriert
Mahlzeit,
Hab mal gepulled und mir die Änderungen angschaut, folgendes fällt mir auf:
mqtt_handler.cpp Z. 18: die ominöse mqttpublishtime_offset, die ich mit 0.1.7 gelöscht habe hat sich wieder reingeschummelt
mqtt_handler.cpp Z.44 > hier wird noch retained gepublished, Absicht?
Ja, hatte in der Hektik hier ein kleines foo nach dem PR, weil ich die Datei offen und ein paar kleine Änderungen drin hatte. Beim reparieren einmal zu viel auf "mine" geklickt und die Variable war wieder drin. Das Retain Flag habe ich an der Stelle vergessen zu entfernen. Hab alles in Ordnung gebracht und committed
Hmm, irgendwas is de 0.1.9 a bissale komisch.. einige Werte (z.b. die uptime) werden nur alle min_publish_time gesendet, und beim BT RSSI scheint es, dass der einmal pro Minute (unabhängig vom publish_delay) gesendet wird, jedes 5. mal scheint er aber dann nach ein paar Sekunden gleich nochmal zu senden:
Ich fand den RSSI alle 5 Minuten ein bisschen wenig (wenn man auf der Suche nach guter Funkposition ist) und habe ihm kurzentschlossen im setState ein true mitgegeben (Map + sofort publish). Gemessen wird er alle 60 Sekunden. Da er mit in der state Map ist, wird er beim „Rundumschlag“ auch mit published. Falls dir das zu oft ist, setz das Flag im setState Aufruf (ble_Loop ganz unten) auf false. Dann wird er alle 60 Sekunden nur in die Map geschrieben und geht nur beim Rundumschlag mit raus.
Morgen,
Vorschlag: du postest ja im /data Teil einen A voll Daten, da machen ja in Wahrheit die paar Status Werte das Kraut auch nicht mehr fett. Ich denke man könnte daher alle publishs mit publish_delay bzw. min_publish_time gleich behandeln?
Würde z.b. auch bei der Funkpositions-suche helfen, weil dann setzt kurzzeitig den publish_delay auf 0 und speicherst dir halt den BT RSSI intern jede Sekunde weg?
lg,
Jürgen
Verstehe ich jetzt nicht. momentan werden alle Messwerte publiziert, wenn sie sich verändern (bei delay = 0). Bei delay > 0 setzt einfach der Parser für die Zeit aus, es sei denn, min_publish steht gerade an. Die Statuswerte werden ebenfalls publiziert, wenn sie sich ändern, oder min_publish ansteht. Der RSSI wird jede Minute aktualisiert und ausgegeben, die Minute wird in ble_client.h als 60000UL festgelegt. Die könnte man auch in der config.h definieren und meinetwegen auf eine Sekunde 1000UL setzen. Ich hatte dem jetzt nicht so viel Bedeutung zugemessen.
So wie ich das verstehe, möchtest Du jetzt die stati updaten wenn ein BLE Telegramm kommt. Kann man machen, aber macht nicht viel Sinn, weil die meisten Werte statisch sind und die uptime ja nun wirklich nicht im Sekundentakt publiziert werden muss. Zudem muss der Code perspektivisch auch lauffähig sein komplett ohne ble_client, wenn man sich für rs485 entscheidet. Entsprechend sollte man dort keine Aufgaben erledigen, auf die der Rumpfcode angewiesen ist. Die parser Funktionen im ble_Client sind nicht ohne Grund so generisch gehalten. Diese werden später im rs485 modul genauso aussehen. In meiner alten Heimat C# oder meiner aktuellen Heimat Typescript hätte ich ein Interface verwendet, um die Übergabe an den Parser abzusichern.
Ah, alles klar, na dann passts! Ich war jetzt irgendwie der Meinung dass die status Werte anders behandelt werden, aber dann passt das schon so 
Können wir den WiFi RSSI eventuell noch mit aufnehmen?
