[vz-users] Fehlermeldungen in vzlogger.log

[Tilman Glötzner]

Hallo

mit Eurer Hilfe, habe ich es gefunden: Daniel hatte recht, die 
exec-Schnittstelle möchte den Zeitstempel offensichtlich in Sekunden.

Bei Auflösung des Zeitstempels mit 1 ms funktioniert es nicht:

[Feb 20 15:12:45][exec] MeterExec::read: Reading line: '1645366365823: 
Battery1_Temperature = 16.
5'
[Feb 20 15:12:45][exec] MeterExec::read: string: Battery1_Temperature, 
value: 16.500000, timestam
p: 1645366365823.000000
[Feb 20 15:12:45][exec] MeterExec::read: Reading line: '1645366365823: 
Battery1_SOE = 17.0'
[Feb 20 15:12:45][exec] MeterExec::read: string: Battery1_SOE, value: 
17.000000, timestamp: 16453
66365823.000000
[Feb 20 15:12:45][S0]   MeterS0:HWIF_GPIO:first poll returned 0
[Feb 20 15:12:45][S0]   MeterS0:HWIF_GPIO:first poll returned 0
[Feb 20 15:12:46][S0]   MeterS0:HWIF_GPIO:first poll returned 0
[Feb 20 15:12:46][exec] MeterExec::read: Closing process 'solaredge.py'
[Feb 20 15:12:46][mtr6] Got 2 new readings from meter:
[Feb 20 15:12:46][mtr6] Reading: 
id=Battery1_Temperature/StringIdentifier: value=16.50 ts=2147483
647000
[Feb 20 15:12:46][mtr6] Reading: id=Battery1_SOE/StringIdentifier: 
value=17.00 ts=2147483647000
[Feb 20 15:12:46][chn8] Adding reading to queue (value=17.00 
ts=2147483647000)
[Feb 20 15:12:46][chn9] Adding reading to queue (value=16.50 
ts=2147483647000)

Hallo Daniel

>Allerdings glaube ich nicht das ein Akku da wirklich die richtige Quelle für ist. Insbesondere wenn die Temperatur ohne Rundung erfasst wird. Die ändert >sich ganz sicher mit jeder Anfrage.
Die Temperatur und Füllstand ändert sich eher langsam -- es sei denn, es wird mit hohen Leistungen geladen oder entladen. Und das sind ja auch die Momente, die interessieren.
Beim Temperatursensor erfolgt die Ausgabe zwar nicht gerundet, aber quantisiert, d.h. auch hier gibt es beim Ideling wenig Änderungen (das Rauschen des Sensors ist offensichtlicher kleiner als Quantisierungsrauschen :-)) ...

Die Duplicates habe ich mal auf 30 Sekunden heruntergesetzt:
+---------------+------------+----------------+
| timestamp     | channel_id | value          |
+---------------+------------+----------------+
| 1645365053000 |         20 | 16.39999961853 |
| 1645365261000 |         20 | 16.39999961853 |
| 1645365297000 |         20 | 16.39999961853 |
| 1645365332000 |         20 | 16.39999961853 |
| 1645365370000 |         20 | 16.39999961853 |
| 1645365405000 |         20 | 16.39999961853 |
| 1645365441000 |         20 | 16.39999961853 |
| 1645365476000 |         20 | 16.39999961853 |
| 1645365512000 |         20 | 16.39999961853 |
| 1645365548000 |         20 | 16.39999961853 |


Viele Grüße und Danke,

Tilman

On 20.02.22 15:00, Daniel Lauckner wrote:
> Hallo,
>
>
> am Sonntag, 20. Februar 2022 um 14:37 hat Thomas Höpfner geschrieben:
>> Nur in diesen Fall (exec Script) sehe ich den Sinn nicht. Es gibt nur Werte, wenn das Script läuft. Die Datenmenge wird also durch die Anzahl der Aufrufe bestimmt.
> Duplicates ist vor allem für Werte interessant die sich über länger Zeiträume nicht verändern. Als Beispiel taugt da am ehesten ein PV-Einspeieszähler. Der ändert sich über die ganze Nacht nicht. Tagsüber möchte man aber vielleicht trotzdem minütlich Daten haben.
>
> Von daher sehe ich keinen Widerspruch in den Anforderungen.
>
> Allerdings glaube ich nicht das ein Akku da wirklich die richtige Quelle für ist. Insbesondere wenn die Temperatur ohne Rundung erfasst wird. Die ändert sich ganz sicher mit jeder Anfrage.
>
>
> mfg Daniel