vzlogger
vzlogger copied to clipboard
volkszaehler
InfluxDB: Use single measurement for points
Hi,
I'm using vzlogger to read the SML measurements from my two ehz counters and write them to a influxdb. I am measuring the feed, delivery and solar production values. currently the values are written to individual points in one measurements identified by a tag. So I get something like
time, value, tag=zaehler
1582714567874000000 24119140 feed 1582714567874000000 66835655.7 delivery 1582714565507000000 80804793.1 solar
unfortunately, influxdb is not capable of doing calculations based on different measurement-points (or I didn't get how to do it).
So my proposal would be, if possible, to be able to combine my three points to one and insert something like this in influxdb:
time, feed, delivery, solar
1582714567874000000, 24119140, 66835655.7, 80804793.1
I hope that I have formulated this understandably ;)
Thanks Michael
@michis0806 I'm typically (and I'm by far no expert) doing only a single measurement and single field. Everything else should be tags. I.e.
SELECT value FROM "vzlogger" WHERE "channel" = "feed" or "channel" = "solar"
Not sure if more fields provide an advantage, but they should be- as suggested- part of a single measurement.
@andig my problem is, that I cannot calculate measurements like the current "Gesamtverbrauch" or "Eigenverbrauch" if it's stored in separate points. But I could use
select solar - delivery as solarusage
or
select feed + solar - delivery as totalusage
when it's posted in one measurement-point
Of course. You can only add if timestamps match. In influx 2 that is done using the ˋaggregateWindowˋ function.
with #426 we get pretty close already.
it should be possible to implement this in the InfluxDB api by just grouping entries with identical timestamps. ( https://github.com/volkszaehler/vzlogger/blob/master/src/api/InfluxDB.cpp#L279 )
but this becomes a pretty hard problem when the values are from different meters,
we would have to provide for an aggregateWindow as andi mentiond above.
and it's pretty much impossible for two S0-meters for example, because the s0 pulses will never be in sync.
just as comment, without deeper knowledge of the details: complex operations should not be done at the vzlogger. it will end up in a configuration jungle. A similar, and might be easier example: weather sensor with temperature and humidity.
@antonmeyer: i don't understand why you feel the need to discourage adding a feature, without having contributed anything. (while also actually requesting a subset of this feature in #487 ...)
when only grouping on identical timestamps, (and with the feature you requested being implemented), this should be a pretty simple thing to do.
@antonmeyer: i don't understand why you feel the need to discourage adding a feature, without having contributed anything. (while also actually requesting a subset of this feature in #487 ...)
Ich antworte mal auf Deutsch: wenn die Idee ist, vzlogger als Universal-Werkzeug zu nutzen, ok, dann sollte man kein feature stoppen. Ich hatte den Eindruck, dass vzlogger eine Art Brücke zwischen Sensor und Datenbank / middle ware sein soll. Also am Besten stateless. Komplexere Operationen wie Aggregation sollte in der Middleware stattfinden. Ist ja eher eine schwäche der influxdb, wenn sie die Zusammenfassung von mehreren Messreihen nicht erlaubt. Wobei ich denke, dass es geht. Wird nur etwas aufwändiger und kann man nicht mit dem Query Builder zusammen-klicken. Und ja, #487 ist nicht ganz konsequent, weil es noch mehr config Optionen hinzufügt. Und klar fände ich es auch gut, wenn man in einem Messpunkt mehrere fields mit senden kann. Aber mein Eindruck ist, dass die Grundidee von VZlogger ist, dass ein Kanal genau ein value (mir fällt gerade nicht der präzise Begriff ein) haben kann. Genauso würde ich gerne die Anzahl der UUIDs reduzieren, weil ich sie in der influxdb lieber durch "sprechende" tags ersetze. daher auch #487 was meinst Du "ohne etwas beigetragen zu haben"? Ein Kommentar ist ja mal ein Beitrag.