Open Sineos opened 7 years ago
Parameter "resolution" only affects identifier "Power". Change it to get the correct results on InnoDB, it wont affect the values in VZ.
That the Parameter "resolution" only affects identifier "Power" makes sense. For the Impulses the Channel settings in Volkszaehler front-end gives the resolution.
Nevertheless I have problems in understanding the logic:
Is the resolution in Volkszaehler different to the resolution in vzlogger?
Is the resolution in Volkszaehler different to the resolution in vzlogger?
Kind of. Maybe you didn't notice the standard-value for impulses is Imp/kWh, not Wh. But the value for power vzlogger is distributung are W. So, in innodb you get liter instead of m³.
Now it makes sense. Many thanks for this clarification. Really appreciated.
On a side note: With vzlogger developing more and more to a multipurpose tool (Influxdb or #308 ) it might be useful to make this more transparent to the user. Maybe a unit element in vzlogger would do the trick, i.e. resolution is for the meter (e.g. 100 Imp/unit) and unit is the actual dimension (e.g. m3)
On a second thought, basically the setting is already there with "identifier": "Power"
. It would be great if further identifier
could be created analogue to the commonly used measurements.
It would be great if further identifier could be created analogue to the commonly used measurements.
I think we shouldn't tinker with different dimensions in vzlogger.
Maybe it could be helpful to have another identifier without the 1000-Problem. But how to name it?
In the Volkszaehler front-end different measurements for a channel can be selected:
If my understanding is correct, the same issue would be applicable for every measurement including impulses and absolute readings, e.g. a flow-rate sensor could return liters/h, while another one returns m3/h.
Basically the identifier Power already is a dimension because it means Watts. Depending on the use case following identifiers may be useful:
Behind every identifier, a certain factor would be set, making sure that the result complies to the given dimension.
In the unit.h include the dimensions are already listed, maybe this could be used as a staring point. Another approach would be a numeric identifier like in unit.h and a list of applicable values in the documentation or the config editor.
We should imho not double the functionaly we already have in the middleware. Vzlogger does too much already.
@andig I fully understand this position. Just with the recent developments like the Influxdb API or an (hopefully) upcoming MQTT API this is a relevant point imo. With only Volkszaehler.org / middleware in place, vzlogger basically was an integrated aspect of this bundle. With these additions I can use vzlogger independently to feed InfluxDB or use MQTT to feed basically any other system (Node-Red, iobroker, openHAB, FHEM etc). I think this is an excellent development because none of the before mentioned products have such a powerful and well-designed way to acquire sensor data (especially S0 and OBIS) like vzlogger.
On the other hand a totally valid design decision for vzlogger would also be: Gather the values 1:1 from the meter and leave the dimension / unit to the processing instance. Here it might make sense to add this information to the documentation, whereas the identifier “Power” is quite misleading. It should somehow be clear to the user that vzlogger just passes on the “raw readings” from the meter and that any unit or conversion of units needs to be done in the processing or visualization.
On one of my RPis I have updated vzlogger to
vzlogger v0.6.1 based on heads/master-0-g99f8edbcb4
to test the new Influxdb interface (btw. many thanks for it!)This RPi is monitoring:
This is the config for it:
In the volkszaehler frontend the readings are fine:
In Influxdb / Grafana the values for the Gas-Meter are off by a factor of 1000, whereas the values for power do match: