[vz-dev] MAX 1800Watt

[Schramm, Marcus]

Hi,

am 23.12.2010 15:38, schrieb Jakob Hirsch: 
> ITechPro, 2010-12-23 12:34:
>> Hintergrund: Ich habe bei mir S0-Zähler mit 2000 Imp/kWh im Einsatz.
> Welche eigentlich und wo her? Kostenpunkt?
Ich habe mir über Ama*on 3x MD-Watt 5(50)A für ~20,-EUR/Stück bestellt,
und einbauen lassen. Am 2.12 hatte ich u.a. Foto davon an Liste geschickt.

> Ist ja auch klar, das verhindert der unique key (timestamp, channel_id).
> Ich kenne den controller-code auch nicht so genau, aber mit "Summarize
> Events" sollte er doch alle events innerhalb der "Resolution in seconds"
> aggregiert an das backend schicken, denke ich.
> Die Aggregation könnte auch das backend machen, aber da gehört und
> sollte es IMO nicht hin.
Habe jetzt mal mit "Summarize Events" getestet (hatte es wegen internem
Backendserver bisher nicht aktiviert): Funktioniert aber bei mir nicht,
weil die genullten msec dann an den &value= Wert anstatt den timestamp
angehängt werden (1->1000):
<IP> - - [23/Dec/2010:18:21:55 +0100] "POST /backend/index.php/data/
	<UUID>.json?ts=1293124915&value=1000 HTTP/1.1" 200 66

> Hatten wir ja kurzem auf der Liste: e6 kann aktuell nur timestamps mit
> voller Sekunde.
Sorry, hatte ich bis jetzt nicht mitgekriegt.

> Möglicherweise oder tatsächlich? Die Tests von Justin diesbezüglich
> haben sich eigentlich sehr gut angehört (IIRC). Wenn die Last auf dem
> Backend nicht zu hoch ist, sollte dessen timestamp deutlich genauer sein
> als der vom controller. Die Latenz ist selbst außerhalb des LAN
> vernachlässigbar. (Für bessere Verfügbarkeit, also wenn das backend
> nicht erreichbar ist, brauchen wir die timestamps des controllers dann
> aber doch.)
> 
> Im Optimalfall würde das aber direkt der controller machen. Hat der
> ATmega nicht eine 32768Hz-RTC eingebaut? Wenn man direkt an Zähler dran
> käme...
Im Moment kann ich das "tatsächlich" nicht bestätigen, hatte nur vor der
Aktivierung der timestamps den Eindruck z.T. unrealistische Werte angezeigt
zu bekommen, dessen Ursache ich damals in einer durch Last verzögerten
Generierung der timestamps durch die DB vermutete.

Gruß
Marcus

_______________________________________________
volkszaehler-dev mailing list
volkszaehler-dev at lists.volkszaehler.org
https://volkszaehler.org/mailman/listinfo/volkszaehler-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3942 bytes
Desc: not available
URL: <http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20101223/efa4d265/attachment.bin>