[vz-dev] Zeitstampfer - was: Re: Fwd: watchcat.c und Hardwareansteuerung

[Peer Janssen]

Justin Otherguy schrieb:
>> Für die fehlende Millisekundenauflösung hatte ich zwei Möglichkeiten 
>> ausprobiert:
>> - ein zweites Feld für die Millisekunden
> oh nein, bitte nicht.

finde ich auch bäh

>> - pro Event die Anzahl der Pulse speichern:
>> 	bei Impulsabständen kleiner 1s ist der Wert 1
>> 	kommen 3 Impulse innerhalb einer Sekunde eben 3
>> 	deshalb auch die Sprünge (Vielfache von 3600W)
> das ist spannend; die Idee, nicht pro Impuls einen Request abzusetzen, kam uns schon an verschiedenen Stellen.
> Das Problem ist, dass man so unschöne Ergebnisse erhält, wenn die Impulsabstände in der Nähe von 1 Sekunde (bzw. dem Übertragungsabstand) ist: dann gibt's diese komischen Sprünge. Der Stromzähler selbst bietet nun mal keine Möglichkeit, in festen Zeitintervallen den Verbrauch abzulesen. Das ist m.E. der Kern.

ACK

> Aber lass uns da ruhig noch drüber meditieren - vielleicht kommen wir ja noch auf eine brilliantere Lösung :-)
> 
>> Wobei vom Controller ja sowieso nur Sekunden-Timestamps kommen, von daher ist 
>> die Millisekundenauflösung ja nur künstlich am Server erzeugt.
>>
>> Schön wäre es natürlich, am Controller höher aufzulösen und evtl. auch pro 
>> Upload mehrere Timestamps zu übermitteln.

Soweit ich weiß, verkraftet die Parameterübergabe bei GET/POST auch 
mehrfaches Vorkommen von keys der key=value Paare.
Wenn der Controller also einen Puffer hat, könnte er die 
zwischenzeitlich während eines Requests aufgelaufenen Impulse im 
nächsten Request in einem Rutsch senden.
Und dann muss das PHP-Script das auch auswerten können.

Cave: Pufferüberlauf beim Zusammenstellen oder Senden des Requests, oder 
beim Zwischenspeichern der Daten.

> genau das hatten wir auch schon angedacht; der Controller bietet erst mal keine Auflösung feiner als 1 Sekunde - aber das ist lösbar.
> 
> Es gäbe noch ne andere Möglichkeit (das ist eine Idee von H. Häberle): man könnte die Zeitstempel als Unix-Timestamps aber in ms-Auflösung speichern. Für flot werden die Zeitstempel eh vor der Anzeige in genau dieses Format gewandelt. Da bliebe dann die Frage, an welcher Stelle man das überhaupt umwandeln müsste. Ich finde es sehr praktisch, die Uhrzeit für das darzustellende Intervall in "yyyy-mm-dd, hh:mm" anzugeben; aber dann müsste man das halt umrechnen - das tut nicht weh.

So mache ich das schon lange mit meinem GMZ. Der AVR hat einen 
freilaufenden ms-Zähler, und die mit den Impulssummen gesendete 
Timestamp ist dann einfach drei Ziffern länger.

Dies könnte allerdings zu Wertesprüngen beim Uhrupdate durch NTP führen.

Auf meinem Desktop beispielsweise sieht das so aus:

29 Apr 07:17:02 ntpdate[1493]: adjust time server 88.84.153.170 offset 
-0.243647 sec
29 Apr 08:17:03 ntpdate[2025]: adjust time server 83.170.1.225 offset 
-0.241005 sec
29 Apr 09:17:03 ntpdate[2383]: adjust time server 188.40.77.71 offset 
-0.242519 sec
29 Apr 10:17:02 ntpdate[2721]: adjust time server 78.47.136.228 offset 
-0.245004 sec
29 Apr 11:17:02 ntpdate[3670]: adjust time server 78.46.194.186 offset 
-0.233799 sec

Das sind immerhin jede Stunde 1/4 bis 1/5 Sekunde, die die Kiste falsch 
läuft. Warum sollte das auf einem unkalibrierten AVR mit eventueller 
Temperaturdrift (die dann je nach Installationsort einen Tagesgang oder 
einen Jahresgang haben könnte) anders sein? Das gäbe dann jede Stunde 
einen kleinen Hüpfer in der Watt-Kurve.

Wegen solcher Gründe lasse ich den Zähler des GMZ ohne NTP einfach frei 
laufen und speichere zusätzlich zur Controller-Timestamp auch eine 
Server-Timestamp des Requests. So kann man dann überhaupt mal 
herausfinden (und dann auch herausrechnen), wie die Controller-Uhr 
gelaufen ist.

Alternativ könnte man natürlich auch einen Request mit der 
NTP-Zeitkorrektur absetzen (letztlich wohl durch Abfrage eines ms-Timers 
im Controller), in der Datenbank speichern und im passenden Intervall 
berücksichtigen.

Peer