Das legt aus dem Hauptspeicher eine 30MB „Partition“ an, und diese wird als /tmp eingebunden. Da dort temporäre Daten gespeichert werden erfolgen hier öfters Schreibzugriffe. Würde also ne SD-Karte belasten, bei ner SSD mit 128GB sollte es unkritisch sein. Kannste also eigentlich auskommentiert lassen.
Stefan Von meinem iPad gesendet > Am 05.05.2018 um 23:15 schrieb Christian Wulff <christianwu...@gmx.de>: > > Bis jetzt läuft es. > Was ist denn das und was tut es? (tmpfs /tmp tmpfs > nodev,nosuid,mode=1777,size=30M 0 0) > Muss ich das danach wieder zurückstellen? > LG > Chris > > > Von: Frank Richter [mailto:frank.richte...@gmail.com] > Gesendet: Samstag, 5. Mai 2018 23:13 > An: volkszaehler.org - users > Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept > gesucht > > Und was sagt aggregate.php jetzt? > > Christian Wulff <christianwu...@gmx.de> schrieb am Sa., 5. Mai 2018 22:51: > Dann sieht es so aus: > > df -h > Filesystem Size Used Avail Use% Mounted on > /dev/root 118G 53G 59G 48% / > devtmpfs 459M 0 459M 0% /dev > tmpfs 463M 0 463M 0% /dev/shm > tmpfs 463M 6.3M 457M 2% /run > tmpfs 5.0M 4.0K 5.0M 1% /run/lock > tmpfs 463M 0 463M 0% /sys/fs/cgroup > /dev/mmcblk0p1 63M 21M 43M 33% /boot > tmpfs 93M 0 93M 0% /run/user/1000 > > > Lieben Gruß, > Chris > > Von: Frank Richter [mailto:frank.richte...@gmail.com] > Gesendet: Samstag, 5. Mai 2018 20:38 > An: volkszaehler.org - users > Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept > gesucht > > Vermutlich ist das diese Zeile in der /etc/fstab: > > tmpfs /tmp tmpfs nodev,nosuid,mode=1777,size=30M 0 0 > > Kommentier' die mal aus (mit #), starte neu und schau nochmal was df -h dann > sagt. > > > > > Am 5. Mai 2018 um 20:33 schrieb Frank Richter <frank.richte...@gmail.com>: > Dann hast du die Version vom Image, wo /tmp als Ramdisk eingerichtet ist. > Vermutlich reicht dort der Platz nicht für so umfangreiche DB-Akrobatik. > Vielleicht kann Udo kurz erklären, wie du /tmp zurück auf die Platte bekommst. > > Grüße > Frank > > Am 5. Mai 2018 um 20:28 schrieb Christian Wulff <christianwu...@gmx.de>: > Moin Frank, > > Das Systemlaufwerk ist eine 128GB SSD > > /tmp $ df -h > Filesystem Size Used Avail Use% Mounted on > /dev/root 118G 53G 59G 48% / > devtmpfs 459M 0 459M 0% /dev > tmpfs 463M 0 463M 0% /dev/shm > tmpfs 463M 6.3M 457M 2% /run > tmpfs 5.0M 4.0K 5.0M 1% /run/lock > tmpfs 463M 0 463M 0% /sys/fs/cgroup > tmpfs 30M 0 30M 0% /tmp > /dev/mmcblk0p1 63M 21M 43M 33% /boot > tmpfs 93M 0 93M 0% /run/user/1000 > > Lieben Gruß, > Chris > > > > Von: Frank Richter [mailto:frank.richte...@gmail.com] > Gesendet: Samstag, 5. Mai 2018 20:23 > > An: volkszaehler.org - users > Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept > gesucht > > Wie voll ist dein /tmp (df - h)? > > Am 5. Mai 2018 um 20:16 schrieb Frank Richter <frank.richte...@gmail.com>: > Kein Plan, hatte ich noch nie. Speicherkarte oder was besseres als > Systemlaufwerk? > > Am 5. Mai 2018 um 20:13 schrieb Christian Wulff <christianwu...@gmx.de>: > …..lief leider nicht soooo lange. Fehlermeldung: > > Performing 'full' aggregation on 'day' level. > > > [Doctrine\DBAL\Exception\DriverException] > An exception occurred while executing 'REPLACE INTO aggregate (channel_id, > type, timestamp, value, count) SELECT channel_id, ? AS type, > MAX(agg.timestamp) > AS timestamp, COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - > MIN(agg.prev_timestamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count > FROM ( S > ELECT channel_id, timestamp, value, value * (timestamp - @prev_timestamp) > AS val_by_time, GREATEST(0, IF(@prev_timestamp = NULL, NULL, > @prev_timestamp)) AS > prev_timestamp, @prev_timestamp := timestamp FROM data CROSS JOIN (SELECT > @prev_timestamp := NULL) AS vars WHERE channel_id = ? AND timestamp < > UNIX_TIMES > TAMP(DATE_FORMAT(NOW(), "%Y-%m-%d")) * 1000 ORDER BY timestamp ) AS agg > GROUP BY channel_id, YEAR(FROM_UNIXTIME(timestamp/1000)), > DAYOFYEAR(FROM_UNIXTIME(t > imestamp/1000))' with params [3, "15"]: > SQLSTATE[HY000]: General error: 126 Incorrect key file for table > '/tmp/#sql_49e_1.MYI'; try to repair it > > > > [Doctrine\DBAL\Driver\PDOException] > SQLSTATE[HY000]: General error: 126 Incorrect key file for table > '/tmp/#sql_49e_1.MYI'; try to repair it > > > > [PDOException] > SQLSTATE[HY000]: General error: 126 Incorrect key file for table > '/tmp/#sql_49e_1.MYI'; try to repair it > > > run [-l|--level LEVEL] [-m|--mode MODE] [-p|--period PERIOD] [--] [<uuid>]... > > > Was muss ich nun tun? > > Lieben Gruß, > Chris > > > > Von: Christian Wulff [mailto:christianwu...@gmx.de] > Gesendet: Samstag, 5. Mai 2018 20:04 > > An: 'volkszaehler.org - users' > Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept > gesucht > > Moin, > > alles klaro, läuft jetzt mit: > > php /var/www/volkszaehler.org/misc/tools/aggregate.php run -m full -l day -l > hour > > Vielen Dank! > > ….mal sehen wie lange es dauert…. > > Lieben Gruß, > Chris > > Von: Frank Richter [mailto:frank.richte...@gmail.com] > Gesendet: Samstag, 5. Mai 2018 19:53 > An: volkszaehler.org - users > Betreff: Re: [vz-users] Schaltspiel- und Betriebsstundenzähler - Konzept > gesucht > Frank Richter <frank.richte...@gmail.com> > Und lass -l minute erstmal weg, das bringt nicht viel und dauert ewig. > > Am 5. Mai 2018 um 19:48 schrieb Christian Wulff <christianwu...@gmx.de>: > Moin, > > ich muss nochmal an dieser Stelle einhaken. > > Vor der Aktivierung der Aggregation sah die Antwort der Abfrage > http://IP-ADRESSE/middleware.php/capabilities/database.json? so aus: > {"version":"0.3","capabilities":{"database":{"data_rows":30461209,"data_size":2664267776,"aggregation_enabled":0}}} > > Ich habe jetzt die Aggregation aktiviert. > > Nach der Aktivierung der Aggregation sah die Antwort der Abfrage > http://IP-ADRESSE/middleware.php/capabilities/database.json? so aus: > {"version":"0.3","capabilities":{"database":{"data_rows":30087708,"data_size":2674753536,"aggregation_enabled":1,"aggregation_rows":0,"aggregation_size":49152,"aggregation_ratio":0}}} > > Soweit so gut. > > Allerdings kann ich die Aggregation nicht starten. > Ich habe folgenden Befehl aus dem Wiki probiert: > php /var/www/volkszaehler.org/bin/aggregate run -m full -l day -l hour -l > minute > > Antwort: > Could not open input file: /var/www/volkszaehler.org/bin/aggregate > > Das Problem ist, dass es in dem Ordner /var/www/volkszaehler.org/ keinen > Ordner „bin“ gibt. > > Nun weiß ich nicht mehr weiter. > Wer weiß da Rat? > > Danke und lieben Gruß, > Chris > > > > > > > > > Von: Frank Richter [mailto:frank.richte...@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 > > Christian Wulff <christianwu...@gmx.de> schrieb am Mi., 2. Mai 2018 21:49: > Moin, > > ja, mit S0 Impulsen geht das, klar. Aber grottenlahm. > Ich habe zum Beispiel einen Wasserzähler, der seit Oktober 2016 (sind ja nur > 1,5 Jahre, also noch nicht soooo viel) bis heute 458733 Datensätze geloggt > hat. > > Wenn ich mit der VZ App v9.7 den Wasserzähler abfrage, dann addiert er glatte > 46 Sekunden lang alle S0 Impulse zusammen, bis das Ergebnis kommt. Das ist > mir zu langsam. > Wenn ich in die Datenbank schauen würde und den letzten Wert abfrage, und > dieser die Information enthält die ich suche, (nämlich zum Beispiel > 613390,5L) dann dauert die Abfrage des Wertes nur Millisekunden. > Übrigens dauert es 38 Sekunden, wenn ich die aktuell 458733 Datensätze des > Wasserzählers in der Administration der Datenbank folgendermaßen abfrage: > SELECT * FROM `data` WHERE channel_id = '16' > Is ja auch kein Wunder, dass es dauert bis man ein paar hunderttausend > Datensätze abgefragt und aufaddiert hat. > Aber warum muss man denn ein paar hunderttausend Werte abfragen und > aufaddieren, wenn man anstatt dummen S0 Bits auch die wirkliche Anzahl der > Impulse speichern kann? > Statt hundertausende Daten abfragen und addieren zu müssen, reicht dann die > Abfrage von einem einzigen Datensatz. > Will man einen Bereich wissen muss man nur zwei Datensätze abfragen und die > Differenz bilden. > Das geht dann logischerweise Faktor mehrere hunderttausendfach schneller > Und genau das ist der Grund ,warum ich von S0 Impulse nix halte und sie so > oft wie möglich versuche zu vermeiden. > > Ich schaue per http Abfrage über JSON über die API der Middleware in die > Datenbank. > (Ich habe mir ein eigenes Hardwarefrontend gebaut. > Das besteht aus einem ESP8266 und einem 2,8“ 320x200 Display für insgesamt 20 > Euro. > Das geht dann immer mit der Beleuchtung im Gäste WC an, fragt die Daten über > WLAN ab und stellt sie dar. > Leider hatte ich noch keine Zeit dies zum Nachbauen zu dokumentieren L > Die nächste Stufe in 4“ mit 480x320 liegt hier vor mir, muss ich nur Zeit für > haben) > > Warum ich das über einen ESP8266 machen will? > Weil ich schon 2 Stück ESP8266 laufen habe, die über WLAN Daten an den > Volkszähler senden. > 1x drei Drehzahlen von der kontrollierten BE- und Entlüftung meiner > Wärmepumpe. Da musste ich selber die Software schreiben bis das klappte. > 1x mit 15 Stück DS18b20 Temperatursensoren. Da konnte ich als Software eine > gepimpte Version von ESP Easy Mega nehmen. > Und weil ich keine Kabelverbindung (außer der Stromleitung) zum Carport > liegen habe, aber selbiges locker in WLAN Reichweite liegt. > Die galvanische Trennung auf der Signalebene ist sicherlich auch nicht > schlecht. Wer weiß schon was sich da draußen für böse Spannungen rumtreiben, > die meinen Raspi ärgern wollen. > > Den letzten Datensatz per http Request abzufragen ist sehr einfach: > 192.168.178.xx/middleware.php/data/xxxxx--UUID--xxxxx.json?from=now > Die Antwort ist ein JSON mit dem letzten timestamp und dem letzten Wert. > > Nun nochmal zu meinen Fragestellungen: > 1. Hat schon mal jemand eine Betriebsstunden- und/oder > Schaltspielerfassung mit einem Volkszähler realisiert? Wenn ja, wie? > 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? > 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? > 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? > > Hat vielleicht jemand ein paar gute Ideen wie man das umsetzen kann? > > Danke und liebe Grüße, > Chris > > Von: Rupert Schöttler [mailto:rupert.schoett...@gmx.de] > Gesendet: Dienstag, 1. Mai 2018 12:46 > An: volkszaehler-users@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 > > > > >
