[vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept gesucht

Thu May 3 23:15:19 CEST 2018

Moin Rupert,

vielen Dank auch für deinen Input.

Aktuell bin ich noch in der „wie-könnte-man-sowas-anstellen“-Phase.

Da ich ja vorhin festgestellt habe, das bei mir keine Aggregation läuft…..is das wohl die erste Baustelle. Vielleicht (oder wahrscheinlich) sieht die Welt danach völlig anders aus, mal abwarten und sehen.

Ich sehe zwei Szenarien:

1.       Entweder dumme S0 Impulse, so wie bei meiner Wasseruhr

2.       Oder eben Zählerstände.

Irgendwie gefallen mir die Zählerstände bis jetzt besser, auch wenn diese aufwendiger zu realisieren sind.

Bei den Zählerständen sehe ich wieder zwei Varianten:

2.a) Die Zählerstände werden nur in der Datenbank gespeichert. Dann muss ich den letzten Wert aus der Datenbank lesen, den aktuellen Wert dazu addieren und den neuen Wert wieder in die Datenbank schreiben.

2.b) Oder die Zählerstände selber zwischenspeichern und diese dann nur an die Middleware/Datenbank senden.

Hätte ich jetzt Zeit, hätte ich ne Menge auszuprobieren, aber leider hab ich da keine Zeit für. Deswegen erstmal als Trockenschwimmkurs alles durchdenken.

Beim Betriebsstundenzähler denke ich funktioniert das.

Bei Schaltspielzähler weiß ich noch nicht wie ich das anstelle, bzw. hab ich da noch keine Idee wie man das im Frontend darstellt

2. Der aufgeweckte ESP sendet jede Sekunde (oder wie genau Du es halt willst) ein "Piep" an den Server, der fragt dann aus der DB den letzten Stand des Betriebsstundenzählers ab, den Du ebenfalls mit Typ AccumulatorInterpreter angelegt hast, und addiert eins (oder was immer die Zeit zwischen zwei Pieps ist) drauf. Diesen neuen Zählerstand schickst Du an die MW. Schläft der ESP ein, bleibt der Zähler mangels "Piep" stehen.

Das würde doch aber bedeuten, das pro Schaltspiel und „Piep“ im Sekundentakt eben auch im Sekundentakt Datensätze in die Datenbank geschrieben werden, oder nicht?

Ich merke schon, das ist gar nicht mal so einfach wie ich mir das vorgestellt habe.

Was will ich eigentlich, bzw. was ist sinnvoll?!

Ein Licht geht an und nach ein paar Minuten wieder aus.

Was interessiert mich daran, und was soll dargestellt werden:

1.       Wann ging das Licht an

2.       Wann ging das Licht wieder aus

3.       Das wievielte Schaltspiel ist dies

4.       Wie viele Betriebsstunden (Betriebssekunden) hat die Lampe bereits gelaufen

Zu 1. und 2. stell ich mir die Darstellung wie ein Rechtecksignal vor.

Bei 1. steigt die Flanke bei einem timestamp von 0 auf 1.

Bei 2. fällt die Flanke bei einem timestamp von 1 auf 0.

Bei 3. wird bei der steigenden Flanke von 1. ein Schaltspiel hinzuaddiert.

Bei 4. …….öhm…….wie könnte das aussehen? Wenn man hier bei 1. die Betriebsstundenuhr weiterlaufen lässt und erst wieder bei 2. anhält, dann würden ja im Sekundentakt Datensätze in die Datenbank geschrieben werden. Das halte ich ja für falsch, weil es unnötige Datensätze erzeugt. Ich denke eine bessere Idee wäre bei 1. die Zählerstand der Uhr zu senden, und bei 2. noch einmal. Dazwischen nimmt der Betriebsstundenzähler ja einfach nur linear zu.

Somit muss man nur 1x bei Schaltspielbeginn und 1x bei Schaltspielende Daten an die Middleware schicken.

Das hört sich für mich nach dem richtigen Plan an.

Oder kann man sich 1., 2. und 3. sogar sparen und diese Information aus 4. ableiten?

Liebe Grüße,

Chris

Von: Rupert Schöttler [mailto:rupert.schoettler at gmx.de] 
Gesendet: Donnerstag, 3. Mai 2018 20:17
An: volkszaehler-users at demo.volkszaehler.org
Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept gesucht

Hallo Christian,

Dein hartnäckiges Insistieren, ohne Impulse auszukommen, und Deine Zusatzinfos aus der 2. Nachricht haben mich noch mal überlegen lassen, wie es vielleicht doch gehen könnte, ohne das Standard-VZ-Konzept zu verbiegen: M.E. musst Du außerhalb des VZ Zählerstände selbst bilden.

Nach wie vor bin ich zwar der Überzeugung, Impulse wären richtig, und die Performance sollte akzeptabel sein -- mit den Hinweisen von Frank. Der Request
http://server/middleware.php/data/5f___c5.json?from=01-01-2010 <http://server/middleware.php/data/5f___c5.json?from=01-01-2010&to=now&tuples=1> &to=now&tuples=1 antwortet mir in 1,5 sec bei 9 Mio Datensätzen des Stromzählers -- mit Aggregation. Er liefert den Gesamtverbrauch und eine Durchschnittsleistung sowie die Anzahl der Zeilen. Gut, vielleicht rechnet die Middleware in Wahrheit nur die Differenz aus Anfangs- und Endzählerstand und ist deshalb so schnell. Aber dasselbe bei einer S0-Wasseruhr (siehe https://wiki.volkszaehler.org/hardware/channels/meters/water/wasserzaehler_ohne_s0 -- etwas Werbung in eigener Sache ;-) erledigt die MW in 6,6 sec bei 227.000 Datensätzen. Ich habe einen Pi3 mit einer SSD, keiner SD-Karte. Wie oft willst Du die aktuellsten Daten abfragen, dass die Performance so entscheidend ist?

Aber zurück zu meiner Idee für Deinen Ansatz:

Du musst Zählerstände selbst bilden, außerhalb des Volkszählers. Dir helfen dazu weder die Middleware noch der vzlogger -- zumindest wüsste ich nicht, wie: Denn ich weiß nicht, wie man den letzten Zählerstand aus der MW rausbekommt. Ich habe zwar einen eHZ, der im Sekundentakt seinen Zählerstand in die Datenbank pumpt (daher die 9 Mio Datensätze ;-), der Request middleware.php/data/uuid.json?from=now liefert den aber nicht, nur die aktuelle Momentanleistung. Ein passender SQL-Befehl wäre 

SELECT <http://ras3/phpmyadmin/url.php?url=https://dev.mysql.com/doc/refman/5.5/en/select.html>  * FROM `data` where channel_id=1 ORDER by timestamp <http://ras3/phpmyadmin/url.php?url=https://dev.mysql.com/doc/refman/5.5/en/date-and-time-types.html>  desc limit 1;

Der geht auf der DB in Millisekunden -- dem Index sei Dank. 

Also wenn Dich das nicht schreckt (oder Du eine bessere Lösung hast -- lass es uns wissen!), könnte es so gehen:

1. Bei jedem Aufwachen sendet der ESP ein "Hallo Welt" an Deinen Server, der fragt dann aus der DB den letzten Stand des Einschaltzählers ab, den Du vom Typ AccumulatorInterpreter angelegt hast (siehe Franks Antworten), und addiert eins drauf. Diesen neuen Zählerstand schickst Du an die MW (oder schreibst ihn direkt in die DB).

2. Der aufgeweckte ESP sendet jede Sekunde (oder wie genau Du es halt willst) ein "Piep" an den Server, der fragt dann aus der DB den letzten Stand des Betriebsstundenzählers ab, den Du ebenfalls mit Typ AccumulatorInterpreter angelegt hast, und addiert eins (oder was immer die Zeit zwischen zwei Pieps ist) drauf. Diesen neuen Zählerstand schickst Du an die MW. Schläft der ESP ein, bleibt der Zähler mangels "Piep" stehen.

Wenn Du's ganz genau brauchst oder das Boot-up des ESP signifikant ist, kannst Du zusätzlich bei 1. den Betriebsstundenzähler um die gemessene Verzögerung bis zum ersten "Piep" hochzählen.

Dies, wie gesagt, meine Idee -- weder ganz noch in Teilen getestet, ein reiner Trockenschwimmkurs. Mit dem Einspeichern der Zählerstände und dem richtigen Kanal-Typ dazu müsste auch das Frontend sinnvolles anzeigen.

Lass uns wissen, ob's funktioniert -- so oder anders!

Gruß, Rupert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20180503/e567d913/attachment-0001.html>