Hallo,
ich möchte gerne einige Zählerstände im Haus erfassen. Dazu habe ich mir
folgendes zusammengeschustert:
- ESP32 + Sensoren zur Erfassung des Zählerstands
- MQTT Server zur Übergabe der Daten
- InfluxDB + Grafana zum Sammeln und Anzeigen der Daten
Nun stellt sich mir aber noch eine grundsätzliche Frage: wie sollen die
Daten in der Datenbank abgelegt werden? Ich sehe da zwei Optionen:
a) Der µC sendet in festen Zeitintervallen (z.B. jede Minute) den
Absolutwert (=Zählerstand).
Nachteile:
Der Sensor muss beim ersten Start mit dem aktuellen Zählerstand
initialisiert werden. Wenn mal der Strom ausfällt (oder der Controller
aus irgend einem Grund neustartet), fängt er wieder von vorne an, und
müllt die Datenbank (ggf. unbemerkt) mit falschen Werten zu.
Man könnte den Wert auch regelmäßig im Flash persistieren und beim Start
wieder von da auslesen, was zumindest die Neustart-Problematik lösen
würde.
b) Der µC sendet in festen zeitabständen ein Delta (Änderung des
Zählerstandes seit der letzten Übertragung)
Vorteile:
Der Sensor muss nichts über den tatsächlichen/absoluten Zählerstand
wissen. Das macht das Leben einfacher.
Was ich nun gar nicht einschätzen kann ist welche der beiden Methoden
mit InfluxDB und Grafana besser funktioniert.
Wenn ich z.B. b) wähle, und dann in Grafana den absoluten Zählerstand
anzeigen möchte, muss ich ja SÄMTLICHE Werte in der Datenbank
aufsummieren (+ einen festen Offset). Das klingt teuer.
Von daher erscheint mir Option a) besser, auch wenn sie in der
Implementierung aufwändiger ist...
Wie macht ihr das? Habt ihr Erfahrungen was gut funktioniert (und was
nicht?)?
Mellopock schrieb:> a) Der µC sendet in festen Zeitintervallen (z.B. jede Minute) den> Absolutwert (=Zählerstand).>> Nachteile:> Der Sensor muss beim ersten Start mit dem aktuellen Zählerstand> initialisiert werden. Wenn mal der Strom ausfällt (oder der Controller> aus irgend einem Grund neustartet), fängt er wieder von vorne an, und> müllt die Datenbank (ggf. unbemerkt) mit falschen Werten zu.> Man könnte den Wert auch regelmäßig im Flash persistieren und beim Start> wieder von da auslesen, was zumindest die Neustart-Problematik lösen> würde.
Dem Sensor kann der Wert doch egal sein. Es muss nur der Wert ausgelesen
und an die Datenbank geschickt werden. In der Datenbank stehen alle
absoluten Werte mit Zeitstempel.
Bei Deltawerten ist die Gefahr, dass sich mit der Zeit eine Abweichung
zur Realtität einstellst, wenn z.B. einmal ein Wert nicht eingetragen
werden konnte...
Verständnisloser schrieb:> Dem Sensor kann der Wert doch egal sein. Es muss nur der Wert ausgelesen> und an die Datenbank geschickt werden. In der Datenbank stehen alle> absoluten Werte mit Zeitstempel.
Der Sensor kann allerdings keinen Absolutwert auslesen. Beim Gaszähler
z.B. dreht einfach immer wieder ein Magnet vorbei, den ich dann mit dem
µC erkennen kann.
Mellopock schrieb:> Der Sensor kann allerdings keinen Absolutwert auslesen.
Das konnte ich ja nicht wissen.
Dann brauchst du die Möglichkeit "manuell" in der Datenbank Werte
eintragen zu können.
z.B. wenn der Sensor mal ausfällt, oder eine zeitlang keine Werte
sendet. Andernfalls wäre der absolute errechnete Wert ungleich dem
Tatsächlichen.
Mellopock schrieb:> möchte gerne einige Zählerstände im Haus erfassen.
Bitte etwas konkreter.
Besonders wichtig halte ich die Erläuterung des Funktionsprinzips des
Zählers bzw. wie erfolgt die Erfassung eines Zählimpulses.
Damit nichts verloren geht muss bei Ausfall der Stromversorgung
natürlich mit Batterie o. ä. gepuffert werden.
Mellopock schrieb:> Der Sensor kann allerdings keinen Absolutwert auslesen.
Dann hast du auch keine Zählerstände, sondern verfolgst mit deinem µC
nur den Verbrauch/Durchfluss.
Wolle G. schrieb:> Besonders wichtig halte ich die Erläuterung des Funktionsprinzips des> Zählers bzw. wie erfolgt die Erfassung eines Zählimpulses.> Damit nichts verloren geht muss bei Ausfall der Stromversorgung> natürlich mit Batterie o. ä. gepuffert werden.
Hier geht es erst mal um den Gaszähler und die Wasseruhr. Bei beiden
lassen sich die Umdrehungen anhand eines Magneten bzw. durch einen
Reflektor nachverfolgen.
Wolle G. schrieb:> Damit nichts verloren geht muss bei Ausfall der Stromversorgung> natürlich mit Batterie o. ä. gepuffert werden.
Das würde den Rahmen meines Bastelprojekts wohl sprengen ;-)
Falls es tatsächlich zu Ausfällen kommt, würde ich von Hand
nachkorrigieren (das muss natürlich vorgesehen werden).
Wolfgang schrieb:> Dann hast du auch keine Zählerstände, sondern verfolgst mit deinem µC> nur den Verbrauch/Durchfluss.
Richtig. Womit ich wieder bei meiner Eingangsfrage bin: soll ich lieber
den Verbrauch mitloggen (und InfluxDB/Grafana die Arbeit machen lassen)
oder schon im Sensor versuchen daraus Absolutwerte/Zählerstände zu
machen?
Du hast eine Datenbank, benutze sie.
Du hast Deltaverbräuche mit Zeitstempel.
Was hindert dich die in der Vergangenheit liegenden zu einer Summe zu
berechnen und irgendwo in der Datenbank abzulegen. Z.B. ein Wert pro
Tag.
Für den aktuellen Verbrauch nimmst du jetzt den letzten berechneten
Absolutwert plus alle neueren Deltas.
Wie viele Milliarden Werte willst du eigentlich abspeichern?
Mellopock schrieb:> oder schon im Sensor versuchen
Völliger Nonsens. Du hast eine Datenbank und einen PC der unendlich
Rechenkapazität hat. Warum soll der Sensor rechnen und wichtige Werte
speichern?
In der Datenbank stehen die Rohdaten, ggf. konzentriert wenn die Menge
zu groß wird (Zusammenfassung alter Daten.
A)Evtl. würde ich mal über regelmäßige Fotos nachdenken. Es gab schon
Zähler mit "Zahlenspüngen", die deswegen ausgetauscht wurden.
B)Deiner Erfassung sollte HINTERHER eine Plausibilitätsprüfung folgen um
grobe Fehler zu entdecken.
Mellopock schrieb:> Womit ich wieder bei meiner Eingangsfrage bin: soll ich lieber> den Verbrauch mitloggen (und InfluxDB/Grafana
Gratulation zur Auswahl von dem Hippster-Müll.
> die Arbeit machen lassen)> oder schon im Sensor versuchen daraus Absolutwerte/Zählerstände zu> machen?
Es ist völlig egal für die Richtigkeit der Ergebnisse. Fällt der Strom
aus dann stimmen ab dem Punkt bei beiden Varianten die Ergebnisse nicht.
Ohne eine Möglichkeit manuell deine Messdaten auf einen Bezugspunkt
(manuell abgelesener Gesamtwert) zu setzen taugen beide Systeme nichts.
Das heißt, wir reden nur darüber wo der Bezugswert gespeichert wird.
Wenn's weiter nichts ist ...
Man könnte ein anderes Kriterium heranziehen: Was passiert bei einem
längeren Ausfall der Funkstrecke? Theoretisch kann der Sensor
"unendlich" lange weiter Gesamtwerte aufsummieren, auch wenn er sie
nicht senden kann. Bei Deltas ist irgendwann der mögliche
Zwischenspeicher im Sensor voll. Allerdings kann ein Sensor auch das
merken und dann anfangen Deltas aufzusummieren.
Das bedeutet, auch dabei ist es egal.
Nebenbei, auch bei Deltas im Normalbetrieb muss der Sensor über
Intervalle (10 Minuten, Stunde, Tag, Woche?) aufsummieren können. Du
willst doch nicht für jede einzelne Bewegung des Rädchens am Zähler
Daten senden?
Bleiben so Dinge wie was ist einfacher und mit weniger Resourcen zu
programmieren. Da beides kein Hexenwerk ist ist auch das egal.
Würfel es aus wenn du dich nicht entscheiden kannst. Oder nimm die
Variante Gürtel und Hosenträger, sende beide Arten von Daten. Das nützt
zwar nichts, aber vielleicht beruhigt es dich.
Mellopock schrieb:> Hallo,> ich möchte gerne einige Zählerstände im Haus erfassen. Dazu habe ich mir> folgendes zusammengeschustert:> - ESP32 + Sensoren zur Erfassung des Zählerstands> Nun stellt sich mir aber noch eine grundsätzliche Frage:> den Absolutwert (=Zählerstand)...(oder)> ein Delta .
Was für Zähler sind das? Welche Schnittstelle?
Aus einem Zähler mit m-Bus oder ModBus Schnittstelle liest du einfach
die Absolutwerte aus und legt einen Zeitstempel daneben.
Feddisch.
Ein MID konformer Zähler müllt dich nicht mit falschen Werten voll.
Fehler werden automatisch korrigiert.
Gaszähler (Balgengeräte) mit Schnittstelle sind teuer und man bekommt
sie oft nicht vom Netzbetreiber gemietet.
S0 -Impulszählerei ist eine Differenzerfassung die integriert werden
muss. Fehler die unterwegs passieren leben weiter.
Mellopock schrieb:> Wolle G. schrieb:>> Damit nichts verloren geht muss bei Ausfall der Stromversorgung>> natürlich mit Batterie o. ä. gepuffert werden.>> Das würde den Rahmen meines Bastelprojekts wohl sprengen ;-)
??? Es müssen ja nicht gleich hochgezüchtete LiPo-Akkus sein, eigentlich
muss es garkein Akku sein. Eine etwas dickere Lithium-Primärzelle würde
für viele Jahre reichen, so "viel" wie der Erfassungs-uC zu tun hat.
Andererseits: Damit wirklich nichts verloren geht, müsste man Gas,
Wasser und Strom absperren, sobald die Erfassung nicht richtig läuft
(Watchdog, Magnetventile, Schütz...). Auf jeden Fall fällt ein normaler
PC oder WLAN eher aus als der Strom aus der Steckdose, ein AVR mit
Batterie ist hier auf dem Land allerdings zuverlässiger.
Hannes J. schrieb:> Man könnte ein anderes Kriterium heranziehen: Was passiert bei einem> längeren Ausfall der Funkstrecke?
Zum Beispiel, weil der PC nicht rund um die Uhr laufen soll oder Windows
ein Update macht.
> Theoretisch kann der Sensor "unendlich" lange weiter Gesamtwerte> aufsummieren, auch wenn er sie nicht senden kann. Bei Deltas ist> irgendwann der mögliche Zwischenspeicher im Sensor voll.> Allerdings kann ein Sensor auch das merken und dann anfangen> Deltas aufzusummieren.
Oder die alten Daten einfach überschreiben. Wenn die Monate lang niemand
abgeholt hat, werden sie wohl nicht wichtig sein. Für wenige Euros gibt
es ein paar MegaByte NOR-Flash im SO-16 Gehäuse. Dazu eine
Netzausfallerkennung und ein etwas dickerer Elko im Netzteil und man hat
einen unkaputtbaren Speicher. Ich würde da sogar mit jedem Zählimpuls
einen Zeitstempel speichern, dann ist auch später jede beliebige
Auswertung möglich.
Mit zwei Chips kann man schreiben, während der andere gelöscht wird.
Löschzyklen sind kein Problem, laut Datenblatt gehen mehr als 100000 und
man muss frühestens nach 2 Millionen Zählimpulsen einmal löschen. Da
kann kein PC mithalten. Der darf dann auch für 4 Wochen Urlaub
ausgeschaltet bleiben und man weiß hinterher immer noch sekundengenau,
wann die Kühltruhe gekühlt hat...
Udo S. schrieb:> Völliger Nonsens. Du hast eine Datenbank und einen PC der unendlich> Rechenkapazität hat. Warum soll der Sensor rechnen und wichtige Werte> speichern?
So viel Rechenkapazität hat mein Raspberry Pi Zero nun auch nicht ;-)
Hannes J. schrieb:> Gratulation zur Auswahl von dem Hippster-Müll.
Aha. Gibt zur Aufzeichnung von Zeitreihen besser geeignete Datenbanken?
Gibt zur Visualisierung von Zeitreihen bessere Oberflächen?
Dann mal raus mit der Sprache!
Sebastian L. schrieb:> Was für Zähler sind das? Welche Schnittstelle?
Wie oben geschrieben: dumme Zähler mit drehenden Magneten oder
Reflektorplättchen.
Mellopock schrieb:> Sebastian L. schrieb:>> Was für Zähler sind das? Welche Schnittstelle?> Wie oben geschrieben: dumme Zähler mit drehenden Magneten oder> Reflektorplättchen.
Miete dir von deinem Messstellenbetreiber Zähler mit Schnittstelle oder
schalte eigene Zähler mit Schnittstelle nach Wahl dahinter. Die
Messstellenbetreiber sind mit EU DIR 2002/2018 jetzt in Zugzwang und da
kann man ja mal anfragen wie die das lösen wollen und welche Optionen
die anbieten.
Meine Diehl Hydrus Wasserzähler geben mir selbsständig Alarm wenn du in
24h keinen 0-Verbrauch erreichst.
Du schreibst dass der Gaszähler dir einen Magnetimpuls geben kann. Ein
Microcontroller kann den nicht auslesen. Hierzu braucht es einen Sensor
am Microcontroller. Da dürfte ein Reed Kontakt reichen, von dem der
Microcontroller die Impulse zählt.
Das ist inkrementelle Messung und den Absolutwert musst du somit manuel
korrigieren.
Ein 0-Verbrauchsalarm ist sinnvoll, ob das dann ein Fehlalarm war, weil
der Reed Kontakt runtergefallen ist, muss man je Fall entscheiden.
Sebastian L. schrieb:> Meine Diehl Hydrus Wasserzähler geben mir selbsständig Alarm wenn du in> 24h keinen 0-Verbrauch erreichst.
Mein Kamstrup-Wasserzaehler theoretisch auch, aber der Wasserversorger
besteht darauf, dass der Schluessel fuer das M-Bus Telegramm seiner ist
und rueckt den nicht raus.
wendelsberg
Bauform B. schrieb:> ??? Es müssen ja nicht gleich hochgezüchtete LiPo-Akkus sein, eigentlich> muss es garkein Akku sein. Eine etwas dickere Lithium-Primärzelle würde> für viele Jahre reichen, so "viel" wie der Erfassungs-uC zu tun hat.
Eben. Meine Heizkostenverteiler loggen über den Tag und senden täglich
Daten. Die Batterie ist auf Kalibrierungsdauer von 10 Jahren ausgelegt.
Alarme sollte man aber vorher absenden können.
> Hannes J. schrieb:>> Man könnte ein anderes Kriterium heranziehen: Was passiert bei einem>> längeren Ausfall der Funkstrecke?
Wenn keine Quittung des Empfängers kommt, dann wird in einer Stunde /
morgen halt nochmal gesendet. Das macht jeder Heizkostenverteiler oder
Stromzähler so.
Darum hat ModBus eine Empfangsbestätigung.
>> Theoretisch kann der Sensor "unendlich" lange
Der Sensor kann das theoretisch leider nicht. Man kann aber heute für
kleines Geld und Aufwand einen Logger zwischen Messumformer und
Kommunikationseinheit setzen.
Praktisch ist das dann alles in einem "Kästchen".
> Oder die alten Daten einfach überschreiben.
Ja - irgendwann macht man halt einen Recycle.
Aber vorher setzt man noch ein paar Alarme ab.
> Ich würde da sogar mit jedem Zählimpuls> einen Zeitstempel speichern, dann ist auch später jede beliebige> Auswertung möglich.
Zur Samplerate sollte man sich ein paar Gedanken machen - Wenn die
Prozesse die überwacht werden sollen. Die Geschwindigkeit eines
Supertankers loggt man auch nicht jede ms.
