search

lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
947 stars 222 forks source link

[Bug] Wrong prometheus metrics format #953

Closed XL-Reaper closed 8 months ago

XL-Reaper commented 1 year ago

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

fsck-block commented 1 year ago

Hi @lumapu

Wenn gewünscht kümmere ich mich darum und erstelle ein PR.

lumapu commented 1 year ago

@fsck-block sehr gerne, ich glaube du kannst das auch testen wenn ich mich nicht irre.

lumapu commented 1 year ago

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

fsck-block commented 1 year ago

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:

XL-Reaper commented 1 year ago

I'm using the official prometheus telegraf plugin

lumapu commented 1 year ago

@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

lumapu commented 1 year ago

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.

stefan123t commented 8 months ago

@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 ?

fsck-block commented 8 months ago

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.