[vz-dev] Fwd: Re: Offene Enden

[Florian Ziegler]

Hallo,

Am Montag, 17. Mai 2010 07:29:23 schrieb Justin Otherguy:
> Moin Jens,
> 
> Am 12.05.2010 um 00:56 schrieb Jens Wilmer:
> > Hallo zusammen,
> > 
> > Am 06.05.2010 23:45, schrieb Justin Otherguy:
> >> das kann ich aufklären: die UUID wird nicht pro Eintrag in der DB
> >> gespeichert; die UUID wird vorher (über eine separate Tabelle) in eine
> >> fortlaufende ID aufgelöst und dann mit abgespeichert. Das ist also kein
> >> Problem.
> > 
> > Wenn das dann mehr als 256 Leute Nutzen, ist die ID vielleicht schon ein
> > signifikanter Teil der Datenmenge. Aber es geht ja nicht nur darum,
> > sondern auch um die Datenhaltung. Macht man eine Tabelle pro UUID und
> > Eingang, kann man den Zeitstempel als Clustered Index benutzen, damit
> > wird immer hinten an die Tabelle angehängt und man bekommt alle
> > benötigten Daten direkt am Stück aus der Tabelle geliefert. Die
> > Zusammenfassung in aller Daten in eine Tabelle bringt nur dann Vorteile,
> > wenn Daten aus mehreren Quellen zusammen abgefragt werden und dass auch
> > nur, wenn es gemeinsame Indizes gibt, die nicht mehr so viel Sinn
> > machen, da der Pflegeaufwand deutlich über dem Nutzen liegen dürfte.
> > Aber mit 5 Zählern und den Daten von 6 Monaten macht das keinen großen
> > Unterschied.
> 
> ...das klingt interessant. Giess das doch mal in PHP - dann können wir's ja
> mal ausprobieren.
> 
> Ich glaube, wir sollten mehr coden und weniger diskutieren - am praktischen
> Beispiel klären sich manche Fragen sicher leichter. Ich wäre auf die Idee
> mit 1 Tabelle/UUID nicht gekommen - das ist originell. Bei der Auswertung
> ist das sicher schneller, insbesondere bei einer grossen Anzahl UUIDs.
> Spannend ist natürlich die Frage, wie schnell das beim Loggen ist. Hinzu
> kommt, dass ist das Projekt momentan eher auf viele kleine dezentrale
> Implementierungen zusteuern sehe (mein.volkszaehler, "embedded
> volkszaehler"). Aber wie gesagt: wenn Du das in PHP-Form schickst, können
> wir's ja mal ausprobieren.

mein Ansatz geht im Moment auch in Richtung vieler verschiedener 
Implementierungen.
Hier nochmal der Link:
http://volkszaehler.f10-home.de/smartmeter.html
Die Auswertung erfolgt komplett in JavaScript, der Server liefert lediglich 
die Pulse im JSON Format:

{	"source":"volkszaehler.org",
	"version":"0.1",
	"storage":"mysql",
	"channels":[
		{"id":4,
			"resolution":2000,
			"function":"MCHN-C0",
			"pulses":[[1273677599,1],[1273677602,1],[1273677664,1]]},
		{"id":5,
			"resolution":1000,
			"function":"MCHN-C1",
			"pulses":[[1273675886,1],[1273675998,1],[1273676110,1]]}
		],
	"type":"pulses",
	"windowStart":1273675886,
	"windowEnd":1273679446}

wie und wo die Daten gespeichert werden ist dann egal. Für MySQL hab ich die 
Implementierung fertig, am Code für CSV-Dateien arbeite ich noch. Da würde ich 
einfach für jede uuid ein File anlegen.
Ich denke, es wäre auch relativ einfach möglich auf dem Controller den http-
server zu aktivieren und das JSON im Controller zu erzeugen, wenn man zum 
Loggen einen größeren Speicher dranhängt.

Damit kann man dann halt wie gesagt, die Speicherart beliebig austauschen, 
aber auch die Auswertung per JavaScript. Man kann also in einer beliebigen 
Webseite z.B. per AJAX den aktuellen Stromverbrauch laden und anzeigen.

Drehpunkt ist damit nur noch das Format des JSON. Man müsste sich dann z.B. 
drauf einigen, was das hier bedeutet:
1273675886,1
1273675895,4

sind das 4 Pulse in Sekunde *95 oder 4 Pulse seit *86.

Möglich wäre auch noch sowas:
1273675886,1
1273675895,2
1273675910,3
1273675912,5
1273675914,6
1273675920,7

also zu jedem abgespeicherten Timestamp die absolute Anzahl der Pulse. Das 
hilft zumindest, wenn ein Timestamp nicht übertragen wird.

> 
> > Die Detektion von 70ms langen Impulsen ist eine Echtzeitfähigkeit, die
> > zum einen durch die Nutzung von Interrupts, zum anderen durch einen
> > Echtzeitkernel gelöst werden kann. Linux ist in dem Bereich nicht gerade
> > die effizienteste Wahl aber 50ms Reaktionszeit sind mit
> > Echtzeiterweiterungen kein Problem. Ich weiß nur nicht, ob das noch
> > unbedingt die geforderte Einfachheit bietet.
> 
> ACK. Das weiss ich auch nicht. Wenn wir das ausprobieren, erfahren wir's
> vielleicht ;-)
> 
> >> - eine Kombination aus ATmega+Emb. Linux halte ich nicht für sinnvoll;
> >> da stellt sich für mich die Frage nach der Zielgruppe; das wäre zwar
> >> sicher technisch eine spannende Lösung, macht den Aufbau aber nicht
> >> gerade einfacher
> > 
> > Aber auch nicht schwerer. Man benötigt keine zusätzlichen Fähigkeiten zu
> > denen, die man auch braucht, um einen Edimax-Router entsprechende
> > Anzuzapfen oder ein Mini Embedded Linux Platinchen in Betrieb zu nehmen.
> 
> Einverstanden, schwerer wird's nicht, aber aufwändiger. Mit einer Lösung
> auf Basis von Flukso würde der Volkszähler für eine ganz andere Zielgruppe
> interessant.
> 
> >> - eine solche Kombination würde dem Flukso schon sehr ähneln
> > 
> > Gute Designs setzen sich halt durch :o)
> :
> :-)
> 
> Gruss, J.
> 
> _______________________________________________
> volkszaehler-dev mailing list
> volkszaehler-dev at lists.volkszaehler.org
> https://volkszaehler.org/mailman/listinfo/volkszaehler-dev


Gruß flo