Neues Modul: GasCalculator

Begonnen von Sailor, 21 Januar 2016, 12:48:11

Vorheriges Thema - Nächstes Thema

Gisbert

Hallo Sailor,

vielen Dank für deine hilfreichen Erklärungen. Das Modul läuft sehr gut und ich lerne es immer besser kennen.

Was hat es mit diesem Attribut auf sich, in der commandref finde ich keine Erklärung:
attr Gaszaehler SiPrefixPower W
Warum W und nicht kW, und was würde sich dadurch ändern?

Ich logge den Tagesverbrauch und die momentane Leistung. Ich habe den Zähler bereits auf eine Aktualisierung von 15 Sekunden gesetzt, dennoch erhalte ich keine glatte Linie für den momentanen Verbrauch, sondern die Kurve springt häufig zwischen 2 Niveaus, siehe anghängtes Bild. Gibt es dafür eine Lösung, ohne die Abfragefrequenz deutlich zu erhöhen?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Sailor

Gallo Gisbert

Zitat von: Gisbert am 02 April 2020, 07:19:54
Was hat es mit diesem Attribut auf sich, in der commandref finde ich keine Erklärung:
attr Gaszaehler SiPrefixPower W
Warum W und nicht kW, und was würde sich dadurch ändern?

Der Wert der geloggt wird, würde um Faktor 1000 kleiner... Kilo = 103 eben

Zitat von: Gisbert am 02 April 2020, 07:19:54
Ich logge den Tagesverbrauch und die momentane Leistung. Ich habe den Zähler bereits auf eine Aktualisierung von 15 Sekunden gesetzt, dennoch erhalte ich keine glatte Linie für den momentanen Verbrauch, sondern die Kurve springt häufig zwischen 2 Niveaus, siehe anghängtes Bild. Gibt es dafür eine Lösung, ohne die Abfragefrequenz deutlich zu erhöhen?

Das ist die Krux... Die momentane Leistung wird als Mittelwert zwischen zwei Messpunkten ermittelt.

Machst du das Intervall zu lang, bekommst du nur einen mittleren Wert über den entsprechenden Zeitraum ohne jedoch zu wissen, wo und wie hoch die Spitzenleistungen waren.

Machst du das Intervall zu klein, bekommst du zwar die Position der Spitzenleistungen, aber die kleinen Werte fangen an zu zittern da es sein kann, das ein Impuls nicht im entsprechenden Intervall eingefangen wurde. Das ist ein bekanntes Digitalisierung-Problem der Messtechnik: Es gibt nur 0 der 1.

Ich habe das Problem schon Mal für den Bruder "ElectricityCalculator" dargestellt und eine EXCEL-Tabelle dafür erstellt:
https://forum.fhem.de/index.php/topic,57106.msg1015526.html#msg1015526

Andererseits, die Kurve wird nie "glatt" sein können: Wenn die Heizung heizt, verbrauchst du Gas und die Leistung geht hoch.
Wenn sie wieder abschaltet, dann geht es wieder runter.  ;)

Ich habe mal den Chart von meiner Heizung angehängt: Lila ist die Heizleistung basierend auf Gasverbrauch in kW, die schwarze Fläche der Tagesverbrauch in kWh.
Mann kann deutlich die Modulation des Brenners erkennen und sobald Heißwasser (DHW - Domestic Hot Water) benötigt wird, geht die Leistung auf 100%.

Ab 00:00 Uhr bis ca. 04:00 Uhr versucht die Heizung immer mal wieder zu testen ob Jemand warmes Heizwasser braucht. Die Vorlauftemperatur steigt jedesmal sprunghaft an und die Antwort heißt somit: Nein. Dementsprechend ist die Leistung nur als kleiner Peak vorhanden.

Um 04:00Uhr brauche ich Duschwasser auf 60°C und die Leistung geht kurzfristig auf 15kW => Vorlauftemperatur in den Speicher kurzfristig auf 80°C.

Ab 22:00 Uhr geht es in die Nachtabsenkung: Die Thermostatventile schließen alle, die Vorlauftemperatur steigt kurz an, die Heizung reagiert darauf und schaltet ab...

Gruß
    Sailor
******************************
Man wird immer besser...

Gisbert

Hallo Sailor,

ZitatNebenbei, denn Offset brauchst du seit Kurzem nicht mehr selbst berechnen. Einfach den Befehl
set myGasCalculator SyncCounter <AktuellerMechanischerZaehlerstand>
eingeben und schon wird das Attribut gesetzt.

Das funktioniert anscheinend anders als ich erwartet habe, oder es liegt ein Bug vor.
Ich hatte beim Reading ..._Total_monotonic_Meter den Wert 6954.85, auf dem mechanischen Gaszähler den Wert 6954.82, den ich nach obigen set-Befehl eingegeben habe, wenn schon, dann exakt richtig.

Als Resultat habe ich nun ein Reading von 13909.670 - was mache ich nur falsch?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Sailor

Hallo Gisbert

Zitat von: Gisbert am 02 April 2020, 21:24:28
Das funktioniert anscheinend anders als ich erwartet habe, oder es liegt ein Bug vor.
Ich hatte beim Reading ..._Total_monotonic_Meter den Wert 6954.85, auf dem mechanischen Gaszähler den Wert 6954.82, den ich nach obigen set-Befehl eingegeben habe, wenn schon, dann exakt richtig.
Als Resultat habe ich nun ein Reading von 13909.670 - was mache ich nur falsch?

Ups, das hätte nicht passieren dürfen. Offensichtlich sind die Offsets addiert worden...

Setze mal das Attribut fuer den Offset auf 0 und führe den Befehl nochmal durch...

Gruß
    Sailor
******************************
Man wird immer besser...

Gisbert

Hallo Sailor,

ich hab verschiedenes (was, weiß ich nicht mehr genau) versucht, aber jedesmal wurde irgendwas anderes schlimmer.
Da ich das Modul erst ca. 2-3 Tage genutzt habe, habe ich mich zu einem radikalen Schnitt entschlossen, d.h. das GasCalculator-Device gelöscht und neu definiert. Bei dem zulieferndem Device für den Zähler habe ich ebenfalls dafür gesorgt, dass dieser bei Null anfängt. Das Reading ...Meter habe ich auf den gleichen Wert (in cbm) wie den mechanischen Zähler gesetzt; dabei bleibt es mit manuellen Eingriffen bis auf weitetes.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Gisbert

Hallo Sailor,

ich bekomme gelegentlich falsche Zählimpulse, die nicht durch einen Gasverbrauch verursacht sein können.
Das angehängte Bild zeigt, dass heute morgen und auch gegen 12:00 ein minimaler Gasverbrauch angezeigt wird, was aber sicher nicht richtig sein kann, da die Vorlauftemperatur zu den jeweiligen Zeiten in keinster Weise reagiert hat.

Gibt es dazu eine wirksame Gegenmaßnahme oder muss man es so akzeptieren?
Wie ist deine Meinung dazu?

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Sailor

Hallo Gisbert

Zitat von: Gisbert am 13 April 2020, 13:49:49
ich bekomme gelegentlich falsche Zählimpulse, die nicht durch einen Gasverbrauch verursacht sein können.
Das angehängte Bild zeigt, dass heute morgen und auch gegen 12:00 ein minimaler Gasverbrauch angezeigt wird, was aber sicher nicht richtig sein kann, da die Vorlauftemperatur zu den jeweiligen Zeiten in keinster Weise reagiert hat.

a) Mir fällt auf, dass deine Rücklauftemperatur größer ist als deine Vorlauftemperatur. Demnach scheinen deine Heizkoerper Wärme aufzunehmen anstatt sie abzugeben.  :o
b) Lege mal die Temperatur deines Warmwasser-Boilers mit in dieses Diagramm.

Gruß
    Sailor

******************************
Man wird immer besser...

mirror

#322
Hallo,
die Vorlauftemperatur ist in einer "normalen" Phase schon 3grd höher - wird ja als Spreizung angezeigt. Allerdings wenn WW gemacht wird ist sie tiefer und verzögert. Das heißt sie wird nicht direkt am Kesselauslauf abgenommen sondern irgendwo am Heizkreis. Wenn WW, dann sieht die HZ mal nichts. Im anhängenden Bild sind die Verhältnisse am Kesselein und -ausgang bei mir dargestellt.
Das erklärt natürlich nicht die Gasspitzen am Morgen und Mittag, aber die Aussage, daß der Vorlauf nicht reagiert ist nicht ganz richtig.
Gruß,
Dietmar
Edit: Was mir noch auffällt, daß Gas Current Power nur beim WW machen hochgeht, nicht aber beim Heizen (z.B. ab 19Uhr) mit geschätzt 4-5kW vor sich hinlümmelt.

Gisbert

Hallo Sailor,

die Temperaturen werden nicht von der Heizung geliefert, sondern von auf den Leitungen befestigten Sensoren, bzw. bei Speicher durch einen ins Schutzrohr eingeschobenen Sensor. Die Heizung ist eine Buderus-Gastherme, die sich derzeit im Sommermodus befindet, d.h. die FBH ist aus, der Speicher ist aber natürlich in Betrieb. Beim Aufheizen schaltet ein elektrisch betriebener 3-Wegehahn so, dass die Energie in den Speicher geht. Jetzt fängt etwas Spekulation an, deshalb ist das meine Interpretation der Dinge, ohne in die Beschreibung der Gastherme reinzuschauen. Beim Heizen des Speichers ist es auf jeden Fall immer so, dass die "Rücklauftemperatur" höher als die "Vorlauftemperatur" und beide aber kleiner als die Speichertemperatur.

Lange Rede, kurzer Sinn, an den zuvor genannten Umständen liegt es nicht, dass kurze Counts zu einer Zeit, in der die Heizung keinen Betrieb hat bzw. haben darf, aufgetreten sind.
Meine Interpreation ist die, dass der induktive Näherungssensor, den ich am mechanischen Gassensor habe, gerade an der Stelle ist, an der er noch nicht zählt, dass aber durch winzige Schwankungen des Zählrades ein Zählimpuls ausgelöst wird. Wenn das stimmt, müsste das gelegentlich bei allen Installationen mit der gleichen Hardware (= indiktiver Näherungssensor, ESP8266 mit ESPEasy, Puls Counter) auftreten und nicht als der absolute Ausnahmefall bei mir. Es wäre natürlich super, wenn irgendein Kraut (darf auch gerne Software sein ;D) dagegen wirkt.

Als Bilder habe ich alle relevanten Daten in ein Diagramm reingebracht; ich hoffe, dass man noch alles erkennt. Zusätzlch habe ich die interessanten Bereich noch herausgezoomt.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Gisbert

Hallo Sailor und andere Interessierte,

nachdem ich kürzlich von einzelnen Fehlmessungen, zumindest glaube ich, dass es sich um solche handelt, berichtet habe, ergibt sich heute zwischen ca. 16:00 und 20:00 eine ganze Reihe von kurzen Impulsen, die auf Fehlmessungen hindeuten.

Das GasCalculator-Modul verarbeitet die Daten aus einem anderen Fhem-Device, weshalb ich die Ursache eher dort sehe, bzw. in der zugrunde liegenden Hardware (induktiver Näherungssensor, ESP8266 mit ESPEasy und Puls Counter).

Falls ihr eine Idee habt, wie man dieser Sache Herr wird, dann bitte her damit.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Sailor

Hallo Gisbert

Zitat von: Gisbert am 14 April 2020, 21:52:38
Das GasCalculator-Modul verarbeitet die Daten aus einem anderen Fhem-Device, weshalb ich die Ursache eher dort sehe, bzw. in der zugrunde liegenden Hardware (induktiver Näherungssensor, ESP8266 mit ESPEasy und Puls Counter).
Falls ihr eine Idee habt, wie man dieser Sache Herr wird, dann bitte her damit.

Sag mal, du kochst nicht zufällig mit Gas oder?

Wenn das Fehlmessungen sind, kannst du sie ganz leicht daran identifizieren, dass dein Counter im GasCalculator schneller läuft als der Mechanische.

Gruß
    Sailor
******************************
Man wird immer besser...

Gisbert

Zitat von: Sailor am 15 April 2020, 08:10:04
Sag mal, du kochst nicht zufällig mit Gas oder?

Wenn das Fehlmessungen sind, kannst du sie ganz leicht daran identifizieren, dass dein Counter im GasCalculator schneller läuft als der Mechanische.

Gruß
    Sailor

Hallo Sailor,

ich koche nicht mit Gas, ein Leck würde man riechen, und der Counter im GasCalculator läuft (leider) schneller als der mechanische Zähler.

Nach 10 Tagen hat der GasCalculator 1.43 cbm mehr auf dem Zähler als der mechanische. Überwiegend war in dieser Zeit nur der WW-Speicher in Betrieb, was vermutlich das Risiko für Fehlmessungen erhöht. Die Differenz kam nicht auf einen Schlag sondern nach und nach. Das erste Mal ist es mir aufgefallen, als die Differenz bei 0.5 cbm lag.

Die Ursache wäre damit eingegrenzt auf die Messung. Ich benutze ESPEasy, GIT version: mega-20190202, Pulse Counter, Debounce Time 1000 ms, Mode type FALLING zum Auslesen des induktiven Näherungssensors.

Gibt es bessere Einstellungen bei ESPEasy, andere Software oder zusätzliche elektronische Filter, z.B. Schmitt-Trigger, um dieses Problem in den Griff zu bekommen?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Sailor

Hallo Gisbert

Zitat von: Gisbert am 15 April 2020, 08:52:57
Gibt es bessere Einstellungen bei ESPEasy, andere Software oder zusätzliche elektronische Filter, z.B. Schmitt-Trigger, um dieses Problem in den Griff zu bekommen?

Da kann ich dir leider nicht helfen. Da wäre ein neuer Beitrag im entsprechenden Unterforum besser als hier...

Gruß
    Sailor
******************************
Man wird immer besser...

my-engel

Zitatein Leck würde man riechen

Nicht unbedingt...
Wenn das Gasregelventil in der Therme nicht richtig schließt, entweicht fortlaufend minimal Gas über den Schornstein.
Aber wenn der mechanische Zähler langsamer läuft scheint es etwas anderes zu sein.

MfG Uwe

Dracolein

Moin zusammen,

Frage zum Gas- und watercalculator gleichermaßen:

Habe beide Module am laufen, beide Module tun augenscheinlich zuverlässig ihren Job.
Wenn ich meinen Raspberry Pi neustarte(n muss), wird fhem eigentlich vom OS vernünftig heruntergefahren. Jedoch sehe ich am nächsten Tag immer einen völlig utopisch hohen Verbrauchswert von Gas & Wasser des Vortages (& entsprechend in Folge auch alle anderen Auswertungs-Parameter).
Ursächlich sollte hier der jeweilige Counter die "Schuld" tragen, doch mir ist absolut unklar, wieso das passiert und ob es Abhilfe gibt?

Hier beispielhaft mein Zähler für den Gasverbrauch als Device:

Internals:
   DEF        192.168.178.100 80 ESP_Bridge ESP_Easy1_reedkontakt
   ESP_BUILD  20104
   ESP_BUILD_GIT mega-20200204
   ESP_BUILD_NOTES  - Mega
   ESP_Bridge_MSGCNT 1860
   ESP_Bridge_TIME 2020-07-06 09:32:51
   ESP_NODE_TYPE_ID ESP Easy Mega
   ESP_SLEEP  0
   ESP_UNIT   ESP Easy
   ESP_VERSION 2
   FUUID      5e4b9e12-f33f-4dec-70a4-577ccbaeae8b3b8d
   HOST       192.168.178.100
   IDENT      ESP_Easy1_reedkontakt
   INTERVAL   300
   IODev      ESP_Bridge
   LASTInputDev ESP_Bridge
   MAX_CMD_DURATION 1
   MSGCNT     1860
   NAME       ESPEasy_ESP_Easy1_reedkontakt
   NOTIFYDEV  global
   NR         83
   NTFY_ORDER 50-ESPEasy_ESP_Easy1_reedkontakt
   PORT       80
   STATE      ree: 0 ree: 4565302 ree: 50239
   SUBTYPE    device
   TYPE       ESPEasy
   VERSION    2.18
   READINGS:
     2020-07-06 09:32:51   Total           69121
     2020-07-06 09:30:53   presence        present
     2020-07-06 09:32:51   reedkontakt_Count 0
     2020-07-06 09:32:51   reedkontakt_Time 4565302
     2020-07-06 09:32:51   reedkontakt_Total 50239
     2020-07-06 09:32:51   state           ree: 0 ree: 4565302 ree: 50239
   helper:
     fpc        1593797670
     pm:
       Encode     1
       JSON       1
     received:
       reedkontakt_Count 1594020771
       reedkontakt_Time 1594020771
       reedkontakt_Total 1594020771
   sec:
     admpwd     
Attributes:
   IODev      ESP_Bridge
   Interval   300
   alias      Gaszaehler_Hardware
   event-on-change-reading .*
   group      ESPEasy Device
   presenceCheck 1
   readingSwitchText 1
   room       ESPEasy,Sensoren
   setState   3
   userReadings Total monotonic {ReadingsVal("ESPEasy_ESP_Easy1_reedkontakt","reedkontakt_Total",0)}

Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;