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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.