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

[Rupert Schöttler]

Hallo Christian,


Am 03.05.2018 um 23:15 schrieb Christian Wulff:
> 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.
>
>  
>
Ja, diesen Plan halte ich auch für den besten -- und er entspricht genau
dem, was ich in meiner ersten Antwort am 1.5. auf Deine Anfrage
geschrieben habe. Allerdings auch mit den Nachteilen, die dort skizziert
sind: Es gibt keinen Zählerstand, den Du direkt aus der DB auslesen
könntest, und die Darstellung des Schaltspielzählers im Frontend ist
nicht perfekt -- die wird es aber nie sein, egal welche Daten
(Zählerstand oder Impuls) Du erzeugst und einspeicherst, denn so ein
Kanaltyp müsste erst implementiert werden. Ich würde aber erst mal
anfangen, Daten zu sammeln, und mir um die optimale Darstellung später
Gedanken machen: Erstens "schaut sich manches weg", wenn man sich daran
gewöhnt hat, z.B. eine unpassende Einheit, und Daten, die Du heute nicht
sammelst, sind für immer verloren.

Ich würd's so versuchen (immer noch "Trockenschwimmkurs" ;-):

1. Daten auf dem ständig laufenden Server erzeugen
Ein Skript überwacht in Endlos-Schleife, ob der ESP "da" ist, z.B. per
Ping im 10-Sekundenraster, und schreibt das in eine Datei: 1 = ESP an =
Licht an, 0 = Aus.
(Da gibt's vielleicht auch besseres, denn das Skript darf nicht
abstürzen, sonst ist der "Sensor" kaputt. Andererseits könntest Du die
Einschaltverzögerung des ESP "hinten" dran addieren, indem Du die 0
nicht sofort, sondern erst ein paar Sekunden später in die Datei schreibst.)
Die Datei enthält entweder 1 oder 0, also nicht hinten anhängen, sondern
überschreiben. Ich meine zumindest, so funktioniert das "file-meter".

2. Datei mit vzlogger überwachen
Dazu ein neues "meter" in die Aufzählung packen mit "protocol": "file".
vzlogger darf das ruhig in kurzem Intervall z.B. 1 sec überwachen, denn
Doubletten schickt er nicht an die Middleware, außer man würde es ihm
explizit befehlen.
Dieses Meter befeuert 2 channels:
- Den Schaltspielzähler vom Typ "Impulse" -- Gas, Wasser oder Strom: Den
idealen gibt es m.E. nicht, es müsste ein generischer Impulszähler sein.
- Den Betriebsstundensensor (siehe Franks Antwort vom 3.5 1:45h)

Die Kanäle hast Du vorher im Frontend angelegt.

Übrigens: Wenn Dir die Kanaldarstellung nicht gefällt, Du ihn vom
"falschen" Typ angelegt hast, kannst Du das problemlos auf der DB
ändern, ohne die Daten zu verlieren: Einfach in der Tabelle entities den
type ändern, id und uuid bleiben gleich --> Daten bleiben erhalten, das
Frontend stellt sie aber anders dar. Welche englischen Einträge erlaubt
sind und den deutschen Bezeichnungen entsprechen, findest Du unter
https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Definition/EntityDefinition.json

Viel Erfolg!
Rupert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20180505/ffd1eda0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5643 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20180505/ffd1eda0/attachment-0001.bin>