Grafana geeft groupby niet goed weer

[TCroezing]

Ik heb Homeassitant die data doorstuurt naar influxdb, die ik ontsluit met grafana.

Nu heb ik toevallig eens wat data van de grafieken gecontroleerd, en zie een raar verschijnsel, misschien dat jullie mij wat kunnen helpen?

Ik heb de volgende (voorbeeld) query:
SELECT max("value") FROM "W" WHERE "entity_id" = 'afgenomen_vermogen_real' GROUP BY time(1d)

De crux is de goup by op 1 dag. Kijkende naar de inhoud van een voorbeelddag, zie ik dat de UTC dag genomen wordt. M.a.w. de data die genomen worden om de goup by (1dag) te berekenen gaat van 01:00 tot 01:00. Het verschil tussen CET en UTC...
De max van de voorbeeldquery is dus de data van de 01:00 uur. Zoals je ook ziet:


De TimeZone van de influxDB, Grafana en browser en Dashboard is CET. Dan moet de group by toch ook over de CET tijd gaan?

[chaoscontrol]

Grafana en InfluxDB met zijn net-niet-sql was ik uiteindelijk zo zat dat ik Grafana nu op mssql draai. Daar heb je nu niets aan, maar mss zie jij ook nog het licht.

[TCroezing]

Op zich een idee, maar die data die ik via HA naar If/Gf doorstuur zijn meestal vluchtige data. Juist mooi weer te geven met Gf.
Wat ik wel wil behouden zit in een SQLite.

[Thralas]

Volgens mij doe je ten onrechte de aanname dat GROUP BY time() met kaldenderdagen rekening houdt.

Terwijl het volgens mij gewoon een interval is van 24 uur, niet meer en niet minder. Het feit dat je interval begint op 01:00 is dan toeval.

Misschien kun je het nog wel een beetje sturen door een expliciete startboundary op te geven, maar zoals ik InfuxDB (niet Grafana!) goed begrijp is het gebrek aan calendar grouping al tijden een issue (maar er lijkt schot in de zaak te zitten).

[ Voor 3% gewijzigd door Thralas op 20-12-2018 21:02 ]

[TCroezing]

Of ik nou GROUP BY time(24h) of (1d) opgeef de resultaten zijn dezelfde.

Jeej, calendar groupings een issue? Het is een timeseries database, daar draait toch alles om tijd?...

Maar dan vertekent het weergegeven beeld toch helemaal als je in de zomertijd zit, dan lopen wij hier 2 uur uit de pas...

[Thralas]

TCroezing schreef op donderdag 20 december 2018 @ 21:29:
Of ik nou GROUP BY time(24h) of (1d) opgeef de resultaten zijn dezelfde.

Natuurlijk, dat is dezelfde interval met een andere representatie.

Jeej, calendar groupings een issue? Het is een timeseries database, daar draait toch alles om tijd?...

Maar dan vertekent het weergegeven beeld toch helemaal als je in de zomertijd zit, dan lopen wij hier 2 uur uit de pas...

Dat laatste is nu juist wat kalendertijd veel complexer maakt dan een simpele tijdsinterval. Niet iedere maand is even lang. Al helemaal niet als we van tijdzone wisselen. Of het februari is. Of een schrikkelseconde introduceren.

[TCroezing]

Thralas schreef op donderdag 20 december 2018 @ 22:56:
Natuurlijk, dat is dezelfde interval met een andere representatie

Naja, je zou het wel anders kunnen interpreteren als je na het beginpunt kijkt. 24 kan van 08:00 uur tot 08:00 uur
Een dag begint om 00:00 uur (laat het daar nou net om gaan )

Dat is nu juist wat kalendertijd veel complexer maakt dan een simpele tijdsinterval. Niet iedere maand is even lang. Al helemaal niet als we van tijdzone wisselen. Of het februari is. Of een schrikkelseconde introduceren.

Dat zijn toch allemaal basis zaken die goed geregeld moeten zijn, helemaal voor een timeseries database waar de core, de tijd is?

Bv. als je in de US woont en je bekijkt geaggregeerde tellergegevens, dan zie je dan toch gegevens van de dag weergegeven bij de nacht en andersom?
Daarom vat ik het niet

[Hero of Time]

Alles wordt in UTC opgeslagen en wordt in de software blijkbaar omgezet naar de juiste tijdzone bij weergave. Als je in de VS zou zitten, aan de oostkust, zou je alles met -5 uur zien. Dus ipv de 1:00 - 1:00 bij jou zien ze 19:00 - 19:00.

Als je niet wat uitgebreider de periode op kan geven om weer te geven, zou je naar de ontwikkelaars kunnen gaan en vragen hoe ze dit hadden bedacht en/of een feature request indienen hiervoor.

[JaQ]

Vanaf InfluxDB 1.3.4 lijk je een tz mee te kunnen geven: https://github.com/influx...ter/README.md#examples-16

[3ddie]

Ik ben toevallig afgelopen weken met hetzelfde aan het knoeien, de tz meegeven zoals hierboven werkt wel, maar grafana lijkt dat mij mij niet op te slaan bij een query.

Ik kwam online tegen dat "GROUP BY time(24h,-1h)" een oplossing/workaround is, die bij mij ook werkt, ik vermoed alleen dat wanneer het zomertijd wordt de query veranderd moet worden, dus een echt oplossing is het ook niet.

Volgende wat ik nog wil zijn grafieken met maandelijks verbruik, lijkt ook lastig te zijn ivm niet kunnen groupen op kalendermaanden.

[TCroezing]

@JaQ en @3ddie Bedankt!
Hmm, als het een echte TimeZone is, dan zou de DST ook wel goed moeten gaan.
Ik zal het ook eens proberen.

[MrMonkE]

3ddie schreef op donderdag 27 december 2018 @ 09:31:
Ik kwam online tegen dat "GROUP BY time(24h,-1h)" een oplossing/workaround is, die bij mij ook werkt, ik vermoed alleen dat wanneer het zomertijd wordt de query veranderd moet worden, dus een echt oplossing is het ook niet.

De EU is er mee bezig.
Dit wordt nog lachen want alle legacy code die met winter/zomertijd rekening houdt moet worden aangepast.
Weet jij in welke queries en code het in je organisatie gebruikt wordt?

Y2k-Part-Deux

[TCroezing]

JaQ schreef op donderdag 27 december 2018 @ 09:13:
Vanaf InfluxDB 1.3.4 lijk je een tz mee te kunnen geven: https://github.com/influx...ter/README.md#examples-16

Dat was het inderdaad!
Query is nu:

code:

SELECT -(last("value") - first("value")) FROM "W" WHERE "entity_id" = 'afgenomen_vermogen_real' AND $timeFilter GROUP BY time(1d) tz('Europe/Amsterdam')

En die toevoeging van de tz werkt!
Super, Thx!