Closed XL-Reaper closed 8 months ago
Hi @lumapu
Wenn gewünscht kümmere ich mich darum und erstelle ein PR.
@fsck-block sehr gerne, ich glaube du kannst das auch testen wenn ich mich nicht irre.
du könntest dir auch überlegen die for-Schleifen asynchron abzuarbeiten wie MQTT, das bringt auch beim esp32 was, lt. @beegee3 Messungen verbessert sich die Rate der erfolgreichen Messages vom Wechselrichter. Ich kann dabei auch gerne etwas helfen, am einfachsten wäre eine Kopie der erst kürzlich erzeugten MqTT async-loop-state-mschine
Anpassung in PR #958.
@lumapu
Jedoch ohne die MqTT async-loop-statemachine, hab's leider nicht verstanden.
War ja vorher auch schon asyncron via AsyncWebServerResponse.
Vielleicht bringen die kleineren chunks auch etwas auf dem esp32.
@XL-Reaper Which kind of metrics parser do you use? Im using Prometheus which seems to be not so picky :wink:
I'm using the official prometheus telegraf plugin
@fsck-block danke für deinen PR. Bzgl. async-loop kann ich evtl. in Zukunft mal drüber schauen. Bitte berichtet hierfür eure heap-fragmentation
hat sich inzwischen herausgestellt, das die hohe heap-fragmentation an der MqTT Lib liegt, da diese eine dynamische verkette Liste nutzt. Ich werde versuchen, dass die Lib hier entsprechend angepasst wird - so ist es für Mikrocontroller eher untauglich oder sogar ein Show-Stopper.
@XL-Reaper der PR ist geschlossen und der code bereits in AhoyDTU. Hattest Du Zeit die Änderung zu testen und können wir das Issue schließen ?
@fsck-block @lumapu oder muß das wegen der MQTT Library und ihrer etwas gewöhnungsbedürftigen Speicherverwaltung/-nutzung noch offen bleiben ? Wenn ja, gibt es ein Issue / PR upstream in der Bibliothek ? Sind die heap-fragmentation Werte dafür noch relevant ?
Der Code läuft bei mir seit Mai ohne Probleme, heap-fragmentierung findet bei mir nicht statt. Ich nutze aber auch nicht MQTT. Wobei die MQTT Library und Prometheus code aus meiner Sicht keinen Zusammenhang haben.
Von mir aus kann man den Issue zu machen.
Platform
ESP8266
Assembly
I did the assebly by myself
nRF24L01+ Module
nRF24L01+ plus
Antenna
circuit board
Power Stabilization
Elko (~100uF)
Connection picture
Version
0.6.9
Github Hash
15ec6a0
Build & Flash Method
ESP Tools (flash)
Setup
Debug Serial Log output
No response
Error description
I am using the version with prometheus exporter, so the /metrics endpoint exists. The output metrics have a wrong format though: I have 2 solar panels installed and named and the type for both panels is re-declared in the metrics endpoint. This causes error in parses like this one: [inputs.prometheus] Error in plugin: error reading metrics for "http://xxxx/metrics": reading text format failed: text format parsing error in line 39: second TYPE line for metric name "ahoy_solar_U_DC_volt", or TYPE reported after samples
In the attaches output of the metrics page, you can see that
TYPE ahoy_solar_U_DC_volt gauge
in line 39 was already declared in line 27
Same for
TYPE ahoy_solar_I_DC_ampere gauge
in line 41 was already declared in line 29
The values are fine, but the double declaration breaks the prometheus data specs metric.txt