[vz-users] Fehlermeldungen in vzlogger.log

[Tilman Glötzner]

Hallo

Noch eine Frage zu Middleware: Ich habe für den State of Charge den 
Kanaltype Füllstand gewählt. Leider wird dieser nicht einheitenfrei, 
sondern in Liter angezeigt. Kann man das änderen? Oder gibt es einen 
geeigneteren Kanaltype?

Danke und Gruß

Tilman

On 20.02.22 15:22, Tilman Glötzner wrote:
> 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