InfluxDB 3.0.0 Änderung - Keine Daten mehr im HistoryGraph widget

[MarkSau]

Hi. Bei der neuen Version vom InfluxDB Adapter 3.0.0( Alpha) hat sich einiges verändert. Nach Installation der Version werden keine Daten mehr in dem HistoryGraph angezeigt. Hat wohl mit folgender Änderung zu tun:

"GetHistory-Anfragen müssen nun bei start/end Angaben in ms erfolgen! Zeitangaben in Sekunden werden nicht mehr umgerechnet! Bitte sicherstellen das alle UIs und Charting-Adapter aktuell **sind!"

Siehe https://forum.iobroker.net/topic/54756/test-adapter-influxdb-3-0-0/2

[Apollon77]

Seems to be Bug in the alpha and can be retested - in general.

BUT while checking the issue I found several parameter values that do not really make sense and should be revised:

• requesting 9.999.999 datapoints (limit and count are set to this value) is a bit too much, or? ;-) I will not imagine if adapter crashes first OOM or the browser of the user or if noone will wait until some GB of data are transferred to the browser ... ok most likely the socket will never transport that withoput a timeout :-)
• The step value only makes sense if you want to get aggregated data - and even then is 3,6s (3600) a strange value ... maybe it is on purpose. Ideally ommit it and set meaningful count parameter because then the step is automatiocally calculated by time differnce/count ...

[Zefau]

@Apollon77 Mit 9.999.999 will ich sicherstellen, dass die Zeitspanne von Start bis Ende komplett abgedeckt ist. Wenn ich zu wenig Daten anfrage kann es passieren, dass die Zeitspanne nicht komplett abgedeckt wird. Der Socket ist so programmiert, dass Datenpakete in Chunks aufgesplittet werden, damit auch große Datenmengen übertragen werden. Dennoch hast du recht, wenn es Gigabyte werden ist es problematisch.

Der step value hat keine Auswirkungen, da ich keine Aggregation drin habe (aggregate ist none). Hatte hier viel rumgespielt. Auch hier war das Problem, dass die Zeiträume bei bestimmten Parametern nicht vollständig abgedeckt sind, daher musste ich die Aggregation rausnehmen.

[Apollon77]

Ok I get what you mean. The reason is the default of 2000 ... I took this discussion as reason to change the way how the default is calculated in sql, history and influxdb: In next version we change it by checking the timeframe and calculating limit (if not set) to be "one value every 10s", but minimum 2000. I think this should fix it for maaany cases and prevents us from giving out too many. In fact I understand the reasoning of your limit value - when you are aware of the risk and have it documented for the users, maybe all fine :-)

[mcuiobroker]

@zefau Was soll ich in die Doku mit aufnehmen? Risiken? Wann ziehen die eingestellten 500 Datapoints? Welche Prioritäten sind gesetzt? Zeitrahmen oder Anzahl der Datensätze?

[Apollon77]

Ok, es gibt zwei Parameter count und limit. Ich bin gerade dabei die 3 history Adapter an der Stelle zu vereinheitlichen weil da bissl was auseinandergelaufen ist.

Parameter "count" ist die Anzahl der Zurückgegebenen Datensätze. Bei Aggregationen (also alles ausser aggregate non/onchange) basiert darauf die Anzahl der zeitblöcke für die Aggregation durch die der Gesamtzeitraum geteilt wird.

Parameter "limit"ist ..... das schau ich mir gerade an :-) Genau da ist der Mischmasch passiert und verschiedene Adapter legen den unterschiedlich aus. Ich denke "Limit" wird die maximale anzahl der Datensätze sein die gesammelt wird wenn keine Aggregation stattfindet. Aber eigentlich ist das dann das gleiche wie count ...

Ich räume auf und melde mich wieder

[Zefau]

@Apollon77 hast du hier schon etwas umgesetzt? bleibt die Lösung, die ich aktuell implementiert habe in zukünftigen History-Adapter-Versionen noch funktionsfähig? Ich würde es gerne erst mal so lassen, um rückwärtskompatibel zu bleiben (also sprich, wenn ich es in v3.1 implementieren würde; die Endanwender aber noch einen alten History Adapter haben).

[Apollon77]

Steht noch aus ... wird aber wenn backward compatible sein vorauss. bzw melde mich wenn nicht