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
smime.p7s
Description: S/MIME Cryptographic Signature
