Bitte um Hilfe: Berechnung des (Oel-)Verbrauchs aktuell/gestern/vorgestern/xyz

Begonnen von Schotty, 28 Februar 2020, 09:49:28

Vorheriges Thema - Nächstes Thema

Schotty

Moin allerseits,

ich bitte um Hilfe von den Experten :)

Ich würde gerne meinen Heizölverbrauch errechnen lassen, und zwar
a) den aktuellen Stand von heute ab 0:00Uhr (mit jeweiliger Aktualisierung nach dem erfolgten Brennerstunden-Reading im 60min Intervall),
b) den Verbrauch von gestern,
c) den Verbrauch von vorgestern,
d) wenn ich dann verstanden habe, wie das mit der Berechnung der alten Werte funktioniert evtl auch noch andere Zeiträume (Woche/Monat/Jahr).
Später sollen die jeweiligen Tagesverbäuche (bspw aus der Berechnung des Vortags) dann auch in einem Logfile gespeichert werden.
(Das Beispiel würde ich dann später auch gerne für die Berechnung des Strom- und Wasserverbrauchs nutzen/anpassen.)

Um den Verbrauch zu ermitteln lese ich derzeit stündlich die Betriebsstunden der beiden Brennerstufen aus und ermittle den Verbrauch anhand dieser zugrundeliegenden Formel:

Verbrauchte Heizölmenge [l] = (Ölmassenstrom 1. Stufe [kg/h] / 0.84 * (Betriebsstunden 1. Stufe - Betriebsstunden 2. Stufe)) + (Ölmassenstrom 2. Stufe [kg/h] / 0.84 * (Betriebsstunden 2. Stufe))


Für meine Heizung sieht die Formel dann so aus:

Verbauch in l = (1.87 / 0.84 * (("BetrStdStufe1") - ("BetrStdStufe2"))) + (1.87 / 0.84 * ("BetrStdStufe2"))


Die Berechnung habe ich nach vielem trial&error prinzipiell auch schon hinbekommen *freu*. Dazu habe ich ein userReading erstellt und dort diesen Perl-Ausdruck als Attribut hinzugefügt:

Oelverbrauch { (1.87 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (1.87 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); }


Als weitere Variante habe ich dann diesen Ausdruck hinbekommen, das ist auch derjenige, der aktuell genutzt wird:

Oelverbrauch { my $Oelverbrauch; $Oelverbrauch = (1.87 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (1.87 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); sprintf("%.2f", $Oelverbrauch); }


Ich dachte mir, dass für die nachfolgenden Berechnungen dann entspr "my $Oelverbrauch_aktuell" etc angelegt werden könnte/müsste, daher die Erweiterung um "my $Oelverbrauch".

Direkt dazu folgende Fragen:
1.) Das Runden auf zwei Nachkommastellen ist hier nur testweise drin, für die Berechnung der daraus folgenden anderen Verbrauchsberechnungen sollte ich die für "$Oelverbrauch" vielleicht wieder rausnehmen, um Berechnungsfehler aufgrund der Rundungen zu minimieren. Richtig?
2.) Ist der Ausdruck soweit überhaupt schonmal in Ordnung, oder sind da irgendwelche versteckten Fehler drin, die ich nicht erkenne und die mir irgendwann auf die Füße fallen?

So weit, so (hoffentlich) gut. Nun wird so aber ja der Verbrauch des gesamten 'Heizungs-/Reglerlebens' berechnet, also der gesamten Brennerstunden. Wo ich jetzt nicht weiterkomme ist die weitere Berechnung für die o.g. Zeiträume.

Ich habe viel gelesen und bin u.a. auf
- OldReadingsVal,
- DOIF und
- difference bzw differential (da ich das "event-on-change"-Attribut gesetzt habe müsste ich wohl 'differential' verwenden, richtig?)
sowie diverse Forenbeiträge diesbzgl. gestoßen, stehe aber anscheinend auf dem Schlauch und weiß trotzdem nicht, wie ich jetzt am Besten weiter vorgehe. Meine wirren Überlegungen hierzu erspare ich Euch mal lieber, sonst wird das hier noch seitenfüllend.. ;)

Hier noch ein Listing von meinem Device:

BUSY       0
   CHANGED   
   DEF        http://xxx/JQ=8330,8331,8332,8333 3600
   FUUID      5e529bd3-f33f-e3ee-b51e-81f554a571758fec
   Interval   3600
   JSONEnabled 1
   LASTSEND   1582876277.44982
   MainURL    http://xxx/JQ=8330,8331,8332,8333
   ModuleVersion 3.5.22 - 7.2.2020
   NAME       SOB_Diagnose
   NOTIFYDEV  global
   NR         37
   NTFY_ORDER 50-SOB_Diagnose
   STATE      ???
   TRIGGERTIME 1582879877.44924
   TRIGGERTIME_FMT 2020-02-28 09:51:17
   TYPE       HTTPMOD
   addr       http://xxx:80
   auth       0
   data       
   displayurl http://xxx/JQ=8330,8331,8332,8333
   header     
   host       xxx
   httpversion 1.0
   ignoreredirects 1
   loglevel   4
   path       /JQ=8330,8331,8332,8333
   protocol   http
   redirects  0
   timeout    2
   url        http://xxx/JQ=8330,8331,8332,8333
   value      0
   QUEUE:
   READINGS:
     2020-02-27 17:41:09   BetrStdStufe1   13725
     2020-02-27 17:41:09   BetrStdStufe2   5625
     2020-02-28 08:51:19   Oelverbrauch    30554.46
     2020-02-27 17:41:09   StartsStufe1    152762
     2020-02-27 17:41:09   StartsStufe2    162228
   REQUEST:
     data       
     header     
     ignoreredirects 0
     retryCount 0
     type       update
     url        http://xxx/JQ=8330,8331,8332,8333
     value      0
   sslargs:
Attributes:
   enableControlSet 1
   event-on-change-reading 1
   reading01JSON 8330_value
   reading01Name BetrStdStufe1
   reading02JSON 8331_value
   reading02Name StartsStufe1
   reading03JSON 8332_value
   reading03Name BetrStdStufe2
   reading04JSON 8333_value
   reading04Name StartsStufe2
   room       Unsorted
   userReadings Oelverbrauch { my $Oelverbrauch; $Oelverbrauch = (1.87 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (1.87 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); sprintf("%.2f", $Oelverbrauch); }
   userattr   reading01JSON reading01Name reading02JSON reading02Name reading03JSON reading03Name reading04JSON reading04Name
   webCmd     reread


Könnt bzw. würdet Ihr mir helfen?

Danke & Gruß

EDIT: IP im Listing entfernt..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

gerd54

Hallo Schotty,
schau dir mal den hourCounter in FHEM an, mit dem habe ich auch meinen Gasverbrauch protokolliert.
vg
Gerd

Schotty

Werde ich machen, danke! Aber um den Verbrauch (also ja im Grunde die Differenz) anzeigen/ausrechnen zu lassen, ist das doch noch nicht das Richtige, oder? Aber ich guck's mir erstmal in Ruhe an.. ;)
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

HeikoGr

wenn du dir die Werte nur anzeigen lassen möchtest, kann ich dir evtl. hiermit helfen:

Zitat von: HeikoGr am 14 November 2019, 21:57:04
Ich vergleiche den Tagesverbrauch Erdgas von gestern mit heute. (Macht nicht immer Sinn, ich weiß - Solange ich aber noch keine Jahreswerte vorliegen habe brauchte ich etwas zum üben).

Die Funktion zieht von allen allen angezeigten Datenpunkten der Graphen den minimum-Wert ab. Somit startet jeder Graph bei 0.

in der GPLOT Datei:
#lp DbLog:mariadb,postFn='postFnMinShift':GasZaehler:Zaehler
#lp DbLog:mariadb,offset=1*(60*60*24),postFn='postFnMinShift':GasZaehler:Zaehler


in der 99_myUtils.pm Datei
sub postFnMinShift($$) {
  my($devspec,$array) = @_;
  my $min = 0;

  foreach my $point ( @{$array} ) {
    $min = $point->[1] if !$min || $point->[1] < $min;
  }   
     
  foreach my $point ( @{$array} ) {
    $point->[1] -= $min;
  }   

  return $array;
}


Beta-User

@gerd54:

Hour Counter ist nicht das richtige/optimale dafür, das ist eine "Betriebsstundenzähler", und nicht im eigentlichen Sinne ein Impulszähler.

@Schotty
Es gibt für diverse "Verbauchsthemen" spezielle "Calculator"-Module (Gas, Water, Energy). Etwas generischer ausgerichtet ist "statistics", das erzeugt periodenbezogene Readings bei seinen "Klienten".

[OT] wegen der Sensor-Frage mit dem Näherungsteil: Falls du nicht direkt LAN verwenden willst, wäre evtl. MySensors interessant (mit einem anderen Transceiver als nRF24). Sollte sich ohne größere Anpassungen auch mit dem Näherungssensor abbilden lassen: https://www.mysensors.org/build/pulse_water, den Code auf MQTT@Arduino umzubauen, dürfte auch nicht besonders schwierig sein. [/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Schotty

Erst schonmal 'danke' an Euch, dass Ihr mir auf die Sprünge helfen wollt, leider hakt es bei mir noch immer..

@HeigoGr: Danke, aber leider verstehe ich das Beispiel schonmal gar nicht und wüsste auch momentan nicht, wie ich das auf meinen Fall übertragen könnte :(

@Beta-User: Die Module und 'statistics' werde ich mir dann auch nochmal genauer ansehen, ich bin letztlich bei den genannten 'OldReadingsVal' etc hängen geblieben. Mir ist nur leider nicht klar, wie ich das tagesweise hinbekomme und wie der Wert des Vortags etc intern gespeichert und zur Berechnung/Anzeige dann wieder hinzugezogen werden kann.
Bzgl. OT:
Auf MySensors bin ich durch verschiedene Beiträge von dir auch gestoßen, dann auch in Verbindung mit RS485 für die Anbindung an den FHEM-RPi. Ich musste nämlich leider feststellen, dass ich auch kein LAN-Kabel in den Keller bekomme *grrrr*, eine zweiadrige Leitung mit Glück aber schon (es führt eine abgetrennte alte Heizungsrohrleitung durch den Boden/die Decke in den Keller, allerdings ist die schon mit diversen Kabeln vollgestopft ;) ). Zum Glück habe ich mit der MQTT-Geschichte für den Ardu bisher 'nur' ca 3-4Tage verplempert, das hält sich noch in Grenzen..  ::) Warst du es auch, der bzgl eines solchen Themas mal etwas bzgl CAN anstelle von RS485 geschrieben hatte..? Da werde ich sonst aber nochmal einen extra Thread erstellen, weiß aber noch nicht genau, in welchem Board (Hausautomations-Systeme/Sonstige-Systeme?) das korrekt aufgehoben ist..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Zitat von: Schotty am 28 Februar 2020, 11:37:05
@Beta-User: Die Module und 'statistics' werde ich mir dann auch nochmal genauer ansehen, ich bin letztlich bei den genannten 'OldReadingsVal' etc hängen geblieben. Mir ist nur leider nicht klar, wie ich das tagesweise hinbekomme und wie der Wert des Vortags etc intern gespeichert und zur Berechnung/Anzeige dann wieder hinzugezogen werden kann.
statistics erzeugt dazu ganz automatisch eigene Readings beim Ausgangsdevice. Also einfach ein (ordentlich getriggertes!) "monotonic"-userReading anlegen, darauf das statistics-Device "ansetzen" und dann bekommst du über die Zeit normale "zeitabschnittsbezogene" Readings, die du auch auswerten und loggen kannst.

ZitatBzgl. OT:
Auf MySensors [...]
Yep, ich bin der mit der "speziellen" RS485-Variante. Wenn's nur um eine 1:1-Verbindung geht, kannst du völlig bedenkenlos die normalen MAX485-Bausteine nehmen; wenn du mir per pm deine Adresse schickst, kann ich mal nachsehen, ob ich noch was im Keller liegen habe... (Für "spezielle Fälle" kostet das nix!), zum Austesten/rein 1:1 sollte auch eine "Überkreuzverkabelung" möglich sein, nur längere Strecken dürften so nicht gehen.

Zum Einstieg wäre neben der "build-Seite" vielleicht noch das hier interessant:

https://wiki.fhem.de/wiki/MySensors_Starter_Guide

Fragen zu MySensors ansonsten am besten im entsprechenden Forenbereich: https://forum.fhem.de/index.php/board,96.0.html

Nachtrag:
Über noch zwei Strippen - oder notfalls sogar die 2 RS485-Strippen (mit einer speziellen Schaltung, die ich aber nicht verstehe...) - ließe sich die RS485-Node auch mit Strom versorgen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Schotty

@Beta-User:
Also 'automatische Readings' klingt schonmal super!  ;D Dann werde ich mich da nochmal mit beschäftigen und dann hier nochmal melden, kann aber etwas dauern (Stichwort 'Hermeneutischer Zirkel' ;) )..

OT: Bzgl RS485: Danke für das großzügige Angebot! PM geht raus..
So ganz bin ich in dem Thema aber noch nicht drin (auch was die RPi-Seite angeht) - aber was ich bisher so gelesen habe, klingt das für mein Vorhaben sehr passend und lässt sich dann im Erfolgsfall ja auch auf den Stromzähler und andere weiter entfernte Sensoren erweitern (WLAN ist für mich einfach nicht das Gelbe vom Ei..). 
Stromversorgung (bspw im Keller) ist nicht das Problem, es könnte also bei der reinen Datenleitung bleiben. Aber dann werde ich demnächst evtl nochmal eine extra Anfrage im genannten Forenbereich stellen, erstmal muss ich mich noch mehr einlesen.. Danke nochmals!
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

...dann gehe ich nachher mal suchen  ;D ...

Den Verweis auf die "RPi-Seite" verstehe ich nicht ganz. Kann ja nur bezogen sein auf das Gateway. Aber dafür würde ich dringend ein ganz oridinäres serielles Gateway (=USB, 2. Arduino) empfehlen, das paßt an jeden Rechner... (Ich nutze dafür einen Pro Micro (ATMega32U4), der hat 2 serielle HW-Schnittstellen; wenn du schon mal einen "Maple" programmiert hast: Der sollte auch gehen).
Auf FHEM-Seite ist es auch easy: GW definieren und warten, dass autocreate die Dinge anlegt, that's it...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Schotty

Zitat von: Beta-User am 28 Februar 2020, 13:11:59
wenn du schon mal einen "Maple" programmiert hast
Ich = Programmier-N00b, also eher nicht - musste auch gerade erstmal danach googeln, was dat überhaupt ist.. ;D

Zitat
Auf FHEM-Seite ist es auch easy: GW definieren und warten, dass autocreate die Dinge anlegt, that's it...
Ok, also das klingt zumindest schonmal attraktiv.. Aber wie ich befürchte, wirds am Ende (für mich) dann doch nicht ganz so easy sein.. ;)
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

gerd54

nochmal mein hourCounter,
mit dem Plot Editor und dem entsprechenden Eintrag in "function" = delta-h hat es bei mir eine stündliche Anzeige des Verbrauches gebracht, damit bin ich zufrieden.
vg
Gerd

Schotty

..sehe ich mir auf jeden Fall auch an, nochmal danke @Gerd54. Falls nicht beim aktuellen Fall, so werde ich es sicherlich irgendwann mal woanders gebrauchen können ;)
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Zitat von: Schotty am 28 Februar 2020, 13:35:52
Ich = Programmier-N00b, also eher nicht - musste auch gerade erstmal danach googeln, was dat überhaupt ist.. ;D
;D Dann bleib' für's GW erst mal bei einen Nano, der Appetit kommt dann beim Essen, und mit MySensors habe ich mich in die C-/C++-Welt eingearbeitet (bin kein IT'ler und habe davor - wenn überhaupt - allenfalls mal "Excel-Funktionen" gebastet...), was dann im Ergebnis auch für Perl hilfreich war, auch wenn manches da "ganz anders" ist...

Zitat
Ok, also das klingt zumindest schonmal attraktiv.. Aber wie ich befürchte, wirds am Ende (für mich) dann doch nicht ganz so easy sein.. ;)
Nope, das ist wirklich easy, wenn du nur Werte empfangen willst, mußt du schlicht nichts tun als zu warten, bis die Werte da sind (ok, je nachdem braucht man einen Browser-refresh, nachdem die Readings erstmals angelegt wurden, aber sonst)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Schotty

Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Schotty

Moin,
ich muss das Thema leider nochmal aufgreifen, so 100%ig läuft's bei mir noch nicht :(

"statistics" habe ich eingerichtet/versucht einzurichten, aber ich befürchte, da habe ich wohl noch nicht alles richtig gemacht. Hier das 'list' (MYSENSOR_10 bitte ignorieren, das gibt's derzeit gerade nicht):

Internals:
   DEF        MYSENSOR_10|MQTT2_DVES_058A19|SOB_Diagnose
   DEV_REGEXP MYSENSOR_10|MQTT2_DVES_058A19|SOB_Diagnose
   FUUID      5e70d675-f33f-e3ee-a421-0d923476fe3849a5
   NAME       Statistiken
   NOTIFYDEV  global,MYSENSOR_10|MQTT2_DVES_058A19|SOB_Diagnose
   NR         42
   NTFY_ORDER 10-Statistiken
   PREFIX     stat
   STATE      Updated stats for: MQTT2_DVES_058A19
   TYPE       statistics
   Helper:
     DBLOG:
       monitoredDevicesHTTPMOD:
         logdb:
           TIME       1585220925.55956
           VALUE      SOB_Diagnose
       monitoredDevicesMQTT2_DEVICE:
         logdb:
           TIME       1585220925.40656
           VALUE      MQTT2_DVES_058A19
       monitoredDevicesMYSENSORS_DEVICE:
         logdb:
           TIME       1585220925.48174
           VALUE      MYSENSOR_10
       state:
         logdb:
           TIME       1586862212.20085
           VALUE      Updated stats for
   READINGS:
     2020-03-26 12:08:45   monitoredDevicesHTTPMOD SOB_Diagnose
     2020-03-26 12:08:45   monitoredDevicesMQTT2_DEVICE MQTT2_DVES_058A19
     2020-03-26 12:08:45   monitoredDevicesMYSENSORS_DEVICE MYSENSOR_10
     2020-04-14 12:59:55   nextPeriodChangeCalc 2020-04-14 13:59:55
     2020-04-14 13:03:32   state           Updated stats for: MQTT2_DVES_058A19
   fhem:
     modulVersion $Date: 2019-12-24 00:07:57 +0100 (Tue, 24 Dec 2019) $
     nextPeriodChangeTime 1586865595
Attributes:
   dayChangeTime 00:05
   deltaReadings Oelverbrauch,value11,volume1,Strom__gesamt
   specialDeltaPeriods SOB_Diagnose:Oelverbrauch:Hour:24,SOB_Diagnose:Oelverbrauch:Day:7:30,MYSENSOR_10:value11:Hour:24,MYSENSOR_10:value11:Day:7:30,MYSENSOR_10:volume1:Hour:24,MYSENSOR_10:volume1:Day:7:30,MQTT2_DVES_058A19:Strom__gesamt:Hour:24,MQTT2_DVES_058A19:Strom__gesamt:Day:7:30MQTT2_DVES_058A19:energy:Hour:24


Die Readings sehen allerdings 'komisch' aus und passen auch nicht wirklich:

READINGS:
     2020-04-14 13:08:52   BetrStdStufe1   3764
     2020-04-14 13:08:52   BetrStdStufe2   390
     2020-04-14 13:08:52   Oelverbrauch    8001.14
     2020-04-14 13:08:52   StartsStufe1    22786
     2020-04-14 13:08:52   StartsStufe2    22805
     2020-04-14 13:08:52   statOelverbrauch Hour: 2.07 Day: 268.33 Month: 268.33 Year: 268.33 (since: 2020-03-18_20:00:35 )
     2020-04-14 12:59:55   statOelverbrauchHour24 8.28
     2020-04-14 12:59:55   statOelverbrauchLast Hour: 0.00 Day: - Month: - Year: -

Der einzige Wert, der mir einigermaßen passend erscheinen könnte, wäre "statOelverbrauchHour24".

Zum Vergleich die Statistiken vom Stromzaehler:

     2020-04-14 13:18:04   statStrom__gesamt Hour: 0 Day: 246 Month: 246 Year: 246 (since: 2020-03-18_20:59:55 )
     2020-04-14 12:59:55   statStrom__gesamtHour24 11
     2020-04-14 12:59:55   statStrom__gesamtLast Hour: 2 Day: - Month: - Year: -

Sieht mir genau so unsinnig aus :(
-> Habe ich da mit "specialDeltaPeriods" irgendwie Bockmist gebaut..?  :o

Zitat von: Beta-User am 28 Februar 2020, 11:57:07
statistics erzeugt dazu ganz automatisch eigene Readings beim Ausgangsdevice. Also einfach ein (ordentlich getriggertes!) "monotonic"-userReading anlegen, darauf das statistics-Device "ansetzen" und dann bekommst du über die Zeit normale "zeitabschnittsbezogene" Readings, die du auch auswerten und loggen kannst.
Mein o.g. userReading habe ich jetzt um 'monotonic' erweitert:

attr userReading Oelverbrauch monotonic { my $Oelverbrauch; $Oelverbrauch = (1.74 / 0.84 * (ReadingsVal("SOB_Diagnose","BetrStdStufe1","") - ReadingsVal("SOB_Diagnose","BetrStdStufe2","")) + (2.18 / 0.84 * ReadingsVal("SOB_Diagnose","BetrStdStufe2",""))); sprintf("%.2f", $Oelverbrauch); }

Wäre zumindest das dann jetzt soweit schonmal korrekt?

Was genau meinst du mit "(ordentlich getriggertes!)" Reading bzw wie kann ich sicherstellen, dass das Reading "ordentlich getriggert" wird?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/