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

Thu May 3 22:20:14 CEST 2018

Hallo Frank,

>>>>>>>>Zählerstände sind sicherlich schicker, aber auch schwieriger in der Handhabung: soll der ESP den laufenden Absolutwert speichern? <<<<<<<<

So hab ich mir das bisher gedacht: Der ESP soll den Absolutwert in einem FRAM Baustein speichern. Vielleicht noch mehrfach redundant und mit etwas Logik die Fehler rausfiltern (z.B. 5x den gleichen Wert speichern. Bei den Schaltspielen darf der neue Wert nur 1 größer sein als der alte. Bei den Betriebsstunden darf der neue Wert nur größer sein als der alte, aber auch nicht sehr viel größer. Und so weiter.)

Ich hatte auch die Idee jedesmal die letzten Werte aus der Datenbank abfragen, aber wenn es dann zu Problemen kommt mit dem Zugriff, dann kriegt man das nicht mit oder kriegt ständig Fehler.

Bei so einem nicht flüchtigem FRAM soll jedes Byte mehrere Billionen mal beschrieben werden können. Ich denke das reicht erstmal ne Weile J

https://www.adafruit.com/product/1895

https://www.adafruit.com/product/1897

Zum Thema Aggregation habe ich folgendes im Wiki gefunden, ich denke das meinst du:

https://wiki.volkszaehler.org/howto/datenmengen?#performance_der_middleware_erhoehendatenaggregationcache

Wie ich sehe ist die Aggregation bei mir aus.

Der aktuellen Zustand meiner (nicht vorhandenen) Aggregation (aktiv, Anzahl der Datensätze, Ratio) habe ich mit folgender Middleware-Abfrage geprüft:

http://IP-ADRESSE/middleware.php/capabilities/database.json?

Ergebnis:

{"version":"0.3","capabilities":{"database":{"data_rows":30461209,"data_size":2664267776,"aggregation_enabled":0}}}

Wenn ich das richtig interpretiere sind es knapp 30,5 Mio. Datensätze mit 2,66GB Größe, Aggregation ist aus.

Die Aggregation hab ich noch nicht sicher verstanden.

Wenn ich es richtig verstehe, werden keine Daten gelöscht oder ausgedünnt, sondern nur zusätzliche Daten erzeugt, was nur Zeit und Speicherplatz kostet.

Was passiert wenn die Initialaggregation unterbrochen wird? Stromausfall oder plötzlich anspringendes Backup aus einem cronjob, das die Services vom Volkszähler stoppt?

Ist das ein Problem, oder kann man die Aggregation später einfach nochmal neu starten und die läuft dann dort weiter wo sie unterbrochen wurde?

Was ist das mit dem day / hour und minute?

Ich stelle mir das so vor: Die Rohdaten werden im Sekundentakt in der Datenbank gespeichert.

Schaut man sich jetzt die Daten im Frontend voll hineingezoomt an, sieht man die Werte mit dem Sekundenintervall.

Zoomt man jetzt heraus, so kommt irgendwann der Punkt an dem so viele Sekundenintervalle dargestellt werden sollen die man garnichtmehr auf einer Pixelbreite darstellen kann. Dann ist dies auch sinnlos und man kann auf die aggregierten Daten zugreifen. Die aggregierten Daten sind dann ein Mittelwert aus den Sekundenintervallen.

Für „Minute“ wurden 60 Sekundendatensätze zu einem Datensatz/Datenpunkt zusammengefasst.

Für „Hour“ wurden 60x60 = 3600 Sekundendatensätze zu einem Datensatz/Datenpunkt zusammengefasst.

Für „Day“ wurden 24x60x60 = 86400 Sekundendatensätze zu einem Datensatz/Datenpunkt zusammengefasst.

Stimmt das soweit?

Im Wiki habe ich gelesen, dass das Frontend dafür gerüstet ist.

Ist denn die Volkszähler App dafür auch gerüstet?`

Und wie sieht es mit http requests aus. Können die das auch nutzen?

Lieben Gruß,

Chris

Von: Frank Richter [mailto:frank.richter83 at gmail.com] 
Gesendet: Donnerstag, 3. Mai 2018 01:46
An: volkszaehler.org - users
Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept gesucht

Am 2. Mai 2018 um 21:49 schrieb Christian Wulff <christianwulff at gmx.de>:

(...) 

Nun nochmal zu meinen Fragestellungen:

1.            Hat schon mal jemand eine Betriebsstunden- und/oder Schaltspielerfassung mit einem Volkszähler realisiert? Wenn ja, wie?

Ich nicht.

2.            Wie stellt man die Betriebsstunden im Frontend dar? Wie sieht das aus? „Betriebsstundenzähler (Impulse)“ und „Betriebsstundenzähler (Zählerstand)“ gibt es ja, aber dann gibt es noch einen „Betriebsstundenzähler“. Was ist das?

Du meinst den "Betriebsstundensensor". Das ist halt ein Betriebsstundenzähler mit der Logik des SensorInterpreters. Wenn dort 1h lang der Wert 1 anliegt, kommt 1 Betriebsstunde raus. Es gibt also für alle 3 Interpreter-Logiken einen passenden Kanaltyp, genau wie bei elektrischer Energie (Impulse/Zählerstände/Leistung). Für das was du haben willst, brauchst du Zählerstände. Wenn du Sekunden in die DB schreibst, musst du Auflösung auf 3600 setzen,

3.            Wie stellt ich die Schaltspiele dar? Als Ventil? Welche Daten braucht das Ventil? „1“ für „high“ und „0“ für „low“? Ist das irgendwo dokumentiert?

Ventil nutzt SensorInterpreter, dass passt nicht für deine angedachten Absolutwerte. Im Zweifelsfall hilft immer ein Blick in lib/Definition/EntityDefinition.json. Dort kannst du dir auch einen eigenen Kanaltyp für Schaltspiele definieren. Du brauchst hierfür ebenfalls den AccumulatorInterpreter (für absolute Zählerstände). 

4.            Der Bewegungsmelder schaltet ja auch den ESP8266 mit ein und aus. Die Bootverzögerung kann ich ignorieren oder mal messen und dann als konstanten Wert zu jeder Messung dazu addieren.

Aber wie schaffe ich es, dass der ESP8266 das Abschalten registriert und dann noch den Wert an die Datenbank sendet?

ESP durchlaufen lassen (evt. mit Deepsleep und wecken beim Einschaltvorgang)? Oder jede Sekunde/alle 5 Sekunden einen Datensatz erzeugen und damit leben, dass der letzte verloren geht? Oder mit MQTT realisieren und Ausschaltung als last will realisieren? Pufferkondensator/akku würde ich eher nicht machen.

Grüße

Frank

Von: Frank Richter [mailto:frank.richter83 at gmail.com] 
Gesendet: Mittwoch, 2. Mai 2018 22:02
An: volkszaehler.org - users
Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept gesucht

Hi Christian,

bei deinen lahmen Antwortzeiten hast du sicher keine Aggregation aktiviert, oder? Bitte mal überprüfen (aggregation in der volkszaehler.conf.php und Cronjobs für regelmäßige Aktualisierung der Tabelle aggregate).

Zählerstände sind sicherlich schicker, aber auch schwieriger in der Handhabung: soll der ESP den laufenden Absolutwert speichern?

Gruß

Frank

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

Hallo Christian,

Am 30.04.2018 um 10:52 schrieb Christian Wulff:

ich bin auf der Suche nach einem Konzept für folgende Fragestellung: 

Ich möchte die Schaltspiele und Betriebsstunden einer Bewegungsmelder-gesteuerten Beleuchtung über WLAN mit dem Volkszähler erfassen.

Die Schaltspiele möchte ich dabei nicht als S0 Impulse, sondern als Zahl gespeichert haben. Das heißt folgendermaßen: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ........

Hintergrund ist, dass man so auf den ersten Blick in die Datenbank die Schaltspiele ablesen kann, und nicht bei einer Abfrage mühsam alle Impulse aufaddieren muss. (Hab ich nämlich schon bei anderen Kanälen in der Datenbank und dauert mir bei der späteren Abfrage leider zu lange).

Ich meine, dass das mit S0-Impulsen schon gut geht: Jedes Einschalten (Wechsel 0 -> 1) erzeugt einen Impuls, den Du mit vzlogger registrieren kannst. Die Auflösung ist 1. In der Grafik des VZ bzw. der Tabelle darunter bekommst Du dann als "Verbrauch" die Anzahl Schaltspiele im ausgewählten Zeitraum. Ok, 100% so wie Du Dir das vorstellst, ist es nicht. Aber das Aufaddieren ist m.E. nicht "mühsam", wie Du schreibst. 
Das wäre der 1. Kanal zum Mitzählen. 

Bei den "Betriebsstunden" sollen die "Betriebssekunden" aufaddiert werden. Diese können variieren, weil der Bewegungsmelder innerhalb seiner Timerlaufzeit mehrfach ausgelöst werden kann, oder das Licht auch manuell angeschaltet werden kann.

Das heißt folgendermaßen (Beispiel pro Schaltspiel 55 Sekunden, kann aber auch variieren): 55, 110 , 165, 220, 652, 707, 762, 817, 1254, 1309, .....

Auch hier der gleiche Grund: Bei ersten Blick in die Datenbank möchte ich die Betriebsstunden in Sekunden auslesen.

Hierzu würde ich einen 2. Kanal einrichten, der auf dasselbe 1 / 0-Signal reagiert. Ich habe eine Photodiode, die registriert, ob im Keller Licht an ist, und das an einen GPIO des Pi gibt. Der Kanal ist ein allgemeiner "Sensor" mit Einheit "Ein" und Stil "states". Hier sehe ich z.B. in der Tabelle, dass das Licht im Durchschnitt eines Tages "0,037 Ein" war. Gut, das müsste ich in Stunden umrechnen. Vermutlich geht es mit dem Kanaltyp "Betriebsstundensensor" viel einfacher, ich habe damit aber keine Erfahrung.

Ich gebe zu, meine Lösungsvorschläge ignorieren Deinen Wunsch, "beim ersten Blick in die DB" die Info zu bekommen. Ich kann den aber auch nicht wirklich nachvollziehen: Wie würdest Du "in die DB" hineinschauen? Per SQL? Auch dann muss, nach Tausenden Schaltspielen, die je 1 Datensatz erzeugt haben, der richtige =letzte herausgesucht werden. Geht das schneller als ein COUNT oder SUM? Ich habe eine analoge Wasseruhr als S0-Zähler eingerichtet, die hat nach 4 Monaten rd. 226.000 Datensätze in die DB gepumpt. Eine Grafik über diesen Zeitraum aufzubauen dauert ein paar Sekunden, liefert mir aber neben dem Gesamtverbrauch auch den zeitlichen Verlauf. Würde ich diese Daten verdichten gemäß https://wiki.volkszaehler.org/howto/datenmengen, würde es vermutlich noch deutlich schneller gehen.

Direkt auf der DB (phpMyAdmin) geht's auch nicht viel schneller:

Zeige Datensätze 0 -  0 (1 insgesamt, Die Abfrage dauerte 3.7392 Sekunden.)

SELECT count(*), Sum(value) FROM `data` WHERE channel_id=12
225887    736725    

(Da fällt mir auf: 736.725 Impulse bei 60 Imp/l sind 12.278,75 l. Die Tabelle sagt 12,2 m³ -- kann das Teil nicht richtig runden??)

Brauchst Du bessere Performance, für die es sich lohnt, die Standardkonzepte zu verbiegen?

Als Hardware dachte ich an einen ESP8266. Damit habe ich bereits einige Projekte erfolgreich gemacht. Diesen könnte ich auch mit einem FRAM Speichermodul kombinieren, um die Werte beim Sensor zwischenzuspeichern.

Was soll der ESP8266 machen? M.E. reicht es, wenn Du Licht an/aus als 1/0 an einen GPIO bekommst und das mit vzlogger an die Middleware übertragen lässt.

Warum will ich das haben? In erster Linie: Just for fun! 

Das ist die wichtigste Triebfeder! :-)

Viele Grüße
Rupert

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