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..
Hallo Schotty,
schau dir mal den hourCounter in FHEM an, mit dem habe ich auch meinen Gasverbrauch protokolliert.
vg
Gerd
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.. ;)
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;
}
@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 (https://www.mysensors.org/build/pulse_water), den Code auf MQTT@Arduino umzubauen, dürfte auch nicht besonders schwierig sein. [/OT]
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..
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 (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 (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.
@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!
...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...
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.. ;)
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
..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 ;)
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)...
Kein IT-ler? Ok, das hätte ich jetzt nicht gedacht.. ;D
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?
Zitat von: Schotty am 14 April 2020, 13:23:28
Was genau meinst du mit "(ordentlich getriggertes!)" Reading bzw wie kann ich sicherstellen, dass das Reading "ordentlich getriggert" wird?
Ich wollte erst mal auf das das eingehen, denn das sollte in jedem Fall sauber sein:
Die userReading
s werden neu berechnet, wenn sie getriggert werden. Das macht grundsätzlich jeder Vorgang zur Reading-Aktualisierung, mit Ausnahme der "internen" Aktualisierung. Mit "interner" Aktualisierung ist z.B. der update von einem userreadings-Wert gemeint; das verhindert Endlosschleifen (ist bei/innerhalb notify+setreading ähnlich, was hier aber keine Rolle spielt)...
Ergo: Dein Oelverbrauch wird auch aktualisiert, wenn "StartsStufe1" aktualisiert wird (oder sonst eben "irgendwas". Aufgrund des Perl-Codes tippe ich mal darauf, dass es eigentlich nur Sinn macht, das Ding neu zu berechnen, wenn sich BetrStdStufe2 oder BetrStdStufe1 ändern?
Das ergäbe:
attr userReadings Oelverbrauch:BetrStdStufe[12].* 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); }Allerdings: "monotonic" ist eigentlich dafür gemacht, weiterzuzählen, wenn der zugrundeliegende Zähler auch mal wieder "bei 0" anfangen kann, und dem Gefühl nach setzt das auch voraus, dass es _ein_ Zählerwert ist - du hast hier zwei, das hatte ich bei deinem Eingangsbeitrag wohl übersehen ::) . Ich vermute, dass dein Zähler "hart" ist und nicht zurückgesetzt wird?
Dann würde ich "monotonic" doch eher nicht nutzen, sorry für den hier irreführenden Hinweis. So sollte es klappen (vorausgesetzt, die Formel paßt):
attr userReadings Oelverbrauch:BetrStdStufe[12].* { 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); }Wenn wider Erwarten doch ein Rücksetzen erfolgen sollte, müßten wir uns was anderes überlegen...
Zitat von: Beta-User am 14 April 2020, 13:47:53
Ergo: Dein Oelverbrauch wird auch aktualisiert, wenn "StartsStufe1" aktualisiert wird (oder sonst eben "irgendwas". Aufgrund des Perl-Codes tippe ich mal darauf, dass es eigentlich nur Sinn macht, das Ding neu zu berechnen, wenn sich BetrStdStufe2 oder BetrStdStufe1 ändern?
Danke, das stimmt, im Grunde würde eine Neuberechnung reichen, wenn sich der Wert von
BetrStdStufe1&2 ändert, die Starts sind für den Ölverbrauch in dem Fall uninteressant. Wenn ich irgendwann mal verstanden habe, wie das Ganze funktioniert, dann würde ich evtl auch nochmal die Starts überwachen, ist für weitere Optimierungen des Brennerverhaltens ja auch nicht uninteressant ;)
Zitat
Allerdings: "monotonic" ist eigentlich dafür gemacht, weiterzuzählen, wenn der zugrundeliegende Zähler auch mal wieder "bei 0" anfangen kann, und dem Gefühl nach setzt das auch voraus, dass es _ein_ Zählerwert ist - du hast hier zwei, das hatte ich bei deinem Eingangsbeitrag wohl übersehen ::) . Ich vermute, dass dein Zähler "hart" ist und nicht zurückgesetzt wird?
Genau, der Zähler wird nicht zurückgesetzt, der Heizungsregler zählt fleißig vor sich hin und ich frage nur die Werte ab.
Zwei Zählerwerte habe ich, da ich zwei Brennerstufen habe. In meiner ersten 'Berechnungsformel' hatte ich
einen kg/h-Wert (Ölmassenstrom) für beide Stufen genommen, nach Durchsicht der Unterlagen dann aber für die unterschiedlichen Stufen angepasst (Stufe 2 haut mehr Öl durch als Stufe 1). Evtl muss ich den Wert irgendwann auch nochmal korrigieren (muss nochmal genau den Pumpendruck messen etc).
Zitat
Dann würde ich "monotonic" doch eher nicht nutzen, sorry für den hier irreführenden Hinweis. So sollte es klappen (vorausgesetzt, die Formel paßt):
attr userReadings Oelverbrauch:BetrStdStufe[12].* { 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); }
Das 'monotonic' hatte ich auch vorhin erst hinzugefügt, hab's jetzt so wie du geschrieben hattest angepasst - danke! :)
Für mein Verständnis:
Wenn ich das richtig sehe, dann hast du also 'nur'
:BetrStdStufe[12].* hinter "Oelverbrauch" hinzugefügt.
D.h., der Doppelpunkt zeigt quasi an, dass danach
eine Bedingung der Trigger kommt, den es zu berücksichtigen gibt? In diesem Fall dann also: Wenn sich
BetrStdStufe ändert, dann ist das der Trigger, um
userReadings Oelverbrauch neu zu berechnen. Ist das
[12] dann die 'Zusammenfassung' für die Readings BetrStdStufe1 & BetrStdStufe2 und
.* nimmt dann quasi alles mit, was bei BetrStdStufe an Werten kommt?
Wenn es also BetrStdStufeX und BetrStdStufeY heißen würde, würde man dann [XY] schreiben? Ist vermutlich gerade richtig doof ausgedrückt, aber ich weiß nicht, wie ich es anders formulieren soll, um die Logik/Syntax dahinter etwas besser zu verstehen :( ;)
EDIT: Formulierung ver(schlimm?)bessert ;)
Zitat von: Schotty am 14 April 2020, 15:01:04
Für mein Verständnis:
Wenn ich das richtig sehe, dann hast du also 'nur' :BetrStdStufe[12].* hinter "Oelverbrauch" hinzugefügt.
D.h., der Doppelpunkt zeigt quasi an, dass danach eine Bedingung der Trigger kommt, den es zu berücksichtigen gibt?
Ja. Ungefährer Link zur Doku: https://fhem.de/commandref_modular_DE.html#readingFnAttributes
Zitat
In diesem Fall dann also: Wenn sich BetrStdStufe ändert, dann ist das der Trigger, um userReadings Oelverbrauch neu zu berechnen. Ist das [12] dann die 'Zusammenfassung' für die Readings BetrStdStufe1 & BetrStdStufe2 und .* nimmt dann quasi alles mit, was bei BetrStdStufe an Werten kommt?
Wenn es also BetrStdStufeX und BetrStdStufeY heißen würde, würde man dann [XY] schreiben? Ist vermutlich gerade richtig doof ausgedrückt, aber ich weiß nicht, wie ich es anders formulieren soll, um die Logik/Syntax dahinter etwas besser zu verstehen :( ;)
EDIT: Formulierung ver(schlimm?)bessert ;)
Genau. Ist eigentlich eine "einfache regex", zu Testen z.B. mit "unseren pdf-Links".
Vermutlich bin ich hier "zu exakt", weil es ja nur 1 und 2 gibt, und man das daher hier auch weglassen könnte, also einfach nur "Oelverbrauch:BetrStdStufe.*" schreiben... Aber es ging ja auch ums Lernen ;) .
Zitat von: Beta-User am 14 April 2020, 15:14:06
Ja. Ungefährer Link zur Doku: https://fhem.de/commandref_modular_DE.html#readingFnAttributes
Ja danke, u.a. da treibe ich mich ja auch rum - aber du weißt ja, Theorie und Praxis und so.. ;)
Zitat
Vermutlich bin ich hier "zu exakt", weil es ja nur 1 und 2 gibt, und man das daher hier auch weglassen könnte, also einfach nur "Oelverbrauch:BetrStdStufe.*" schreiben... Aber es ging ja auch ums Lernen ;) .
Perfekt :)
Bzgl der statistics-Geschichte beobachte ich das dann jetzt erstmal ein paar Tage, wie es sich mit dem geänderten userReadings verhält? Oder fallen dir da bereits grobe Schnitzer auf, die grundsätzlich falsch sind..?
:)
Grobe Schnitzer? ...habe ansonsten nicht danach gesucht ;D , und bin selbst noch recht neu in der "statistics"-Materie. Will sagen: viel mehr als (mit geschultem Auge...) Doku wälzen ist an der Stelle bei mir auch nicht, und wenn's jetzt einigermaßen plausibel funktioniert, bin ich auch froh ;D .
Achso, ok, dann erstmal danke für's Optimieren des userReadings :)
Also für mich sehen die Statistiken nicht passend aus, aber dann warte ich einfach noch ein bissl und vielleicht meldet sich ja noch jemand, der den 'Hasen im Pfeffer' sieht (oder ich versuche mein Glück nochmal mit einem entspr neuen Thread).. ;)
Moin Beta-User,
ich habe gerade mal einen Blick auf 'Oelverbrauch' geworfen:
READINGS:
2020-04-15 10:08:52 BetrStdStufe1 3768
2020-04-15 10:08:52 BetrStdStufe2 391
2020-04-15 10:08:52 Oelverbrauch 8009.95
2020-04-15 10:08:52 StartsStufe1 22815
2020-04-15 10:08:52 StartsStufe2 22834
2020-04-15 10:59:55 statOelverbrauch Hour: 0.00 Day: 277.14 Month: 277.14 Year: 277.14 (since: 2020-03-18_20:00:35 )
2020-04-15 10:59:55 statOelverbrauchHour24 10.88
2020-04-15 10:59:55 statOelverbrauchLast Hour: 2.07 Day: - Month: - Year: -
Demzufolge wurden die Statistiken um 10:59 aktualisiert, obwohl 'BetrStdStufe' und 'Oelverbrauch' zu dem Zeitpunkt nicht aktualisiert wurden (bzw. vorher um 10:08).
Ist das so korrekt?
Ich hätte jetzt angenommen, die Aktualisierung der Statistiken würden mit deiner Anpassung des userReadings (Oelverbrauch:BetrStdStufe[12].*) dann auch nur stattfinden, wenn sich 'Oelverbrauch' aktualisiert..? Oder hat das quasi nichts miteinander zu tun?
EDIT:
Nachtrag: Um 11:08 wurden die Daten des Heizungsreglers korrekt aktualisiert (alle 60min), damit fand auch eine Aktualisierung (nur!) von 'statOelverbrauch' statt:
READINGS:
2020-04-15 11:08:52 BetrStdStufe1 3768
2020-04-15 11:08:52 BetrStdStufe2 391
2020-04-15 11:08:52 Oelverbrauch 8009.95
2020-04-15 11:08:52 StartsStufe1 22817
2020-04-15 11:08:52 StartsStufe2 22836
2020-04-15 11:08:52 statOelverbrauch Hour: 0.00 Day: 277.14 Month: 277.14 Year: 277.14 (since: 2020-03-18_20:00:35 )
2020-04-15 10:59:55 statOelverbrauchHour24 10.88
2020-04-15 10:59:55 statOelverbrauchLast Hour: 2.07 Day: - Month: - Year: -
Also wurde 'Oelverbrauch' auch aktualisiert, obwohl sich die Werte bei 'BetrStdStufe' nicht geändert haben :o
So ganz verstehe ich die Arbeitsweise dahinter nicht :(
Btw: Was ist deiner Meinung nach der richtige Ort für meine Frage hinsichtlich 'statistics' - hier bei den Anfängerfragen oder im Board 'Unterstützende Dienste'?
Hmm, der richtige Ort? Schwierig... Der Modulautor liest vermutlich hier nicht mit, aber ich bin auch nicht überzeugt, dass wir ihn wirklich brauchen:
Es ist m.E. richtig, dass statistics die periodischen Werte (bzw. die zwischenzetlichen Änderungen) jeweils zum Ende der Periode "wegschreibt". Ziel ist es ja, (via FileLog, das afaik keine Datenbankauswertung unter Berücksichtigung von Zeitstempeln kennt) Daten so aufzubereiten, dass man sie vor allem auch plotten kann. Dafür braucht man eben diese Aktualisierungsvorgänge, die dann auch wieder von FileLog (als Eventhandler) erkannt werden.
Ergo: in meiner Gedankenwelt ist alles iO., wenn um kurz vor der ganzen Stunde die statistics-Readings erneuert werden.
Ok, das klingt ja schonmal gut :)
Was mich (neben den m.M.n. nicht-passenden Statistiken -> das wäre dann ja auch das Fragethema für den neuen Thread) nur eben wundert ist, dass 'Oelverbrauch' auch aktualisiert wurde, obwohl sich die Werte von BetrStdStufe ja nicht geändert haben. Meinem Verständnis nach hätte das nach der gestrigen Ergänzung des Triggers doch nicht passieren 'dürfen'?
Es stört mich jetzt nicht wirklich, wundert mich nur eben, dass der Trigger anscheinend nicht 'berücksichtigt' wurde..?
An den Zeitstempeln der Readings kann man m.E. nicht ablesen, dass der Trigger nicht richtig wirkt: Es wurden alle Readings um 10:08:52 bzw. genau eine Stunde später aktualisiert. Dass sich der Wert ggf. nicht ändert, ist sachlich richtig, da ja keine Änderung stattfand, sondern nur getriggert wurde.
Wenn du das auschalten wolltest (was ich nicht empfehle, da alle Stunde ja nicht ständig ist), wäre event-on-change die richtige Adresse.
Achso - ich nahm jetzt an, dass userReadings in dem Fall dann auch gar nicht erst aktualisiert wird. Alln's kloar, dann lasse ich das alles so :)
event-on-change ist (für mich persönlich) ein anderes 'Problem'-Thema, wo es beim Verständnis auch noch hakt - ich sag ja: ich muss mich für's PDF gar nicht groß anstrengen, um den 'DAU' zu mimen 8) ;D
Zitat von: Schotty am 15 April 2020, 12:07:10
event-on-change ist (für mich persönlich) ein anderes 'Problem'-Thema, wo es beim Verständnis auch noch hakt
Das ist ziemlich facettenreich und insgesamt sehr viel spannender, als es zunächst vielleicht den Anschein macht. Wer da in die Irre läuft, ist nicht zwangsläufig ein DAU, und was man in diesem Umfeld wie macht, hängt auch von den konkreten Umständen und Bedürfnissen ab ;) .
Vielleicht eine Kurzfassung:
In Schritt 1 entscheidet der Modulautor, ob die Anweisung triggern soll, ein oder mehrere Readings zu schreiben. Mit event-on-change kann jetzt der User in Schritt 2 entscheiden, ob er es doch nicht triggernd haben will bzw. bei welchen Abweichungen usw. (zum ungekehrten Fall: event-on-update).
Manchmal ist es auch nicht der Modulautor selbst, der das Zusammenspiel beeinflusst:
Denn manche Geräte senden nur Infos, wenn sich was ändert bzw. wenn gemessen wurde. Das ist an sich der einfachste Fall, aber gelegentlich kommt es vor, dass auch das "schlecht" ist, weil der User bestimmte Zustände plotten will, und daher eben hin und wieder den aktuellen (unveränderten) Wert in den LogFiles braucht.
Aber andere Geräte melden ständig auch unveränderte Werte (die Shelly@MQTT@default-Einstellung), die an sich eher statisch sind, z.B. der Zustand eines Relais. Das kann auch Probleme machen, wenn du das z.B. dazu nutzen willst, ein anderes Gerät zu schalten, aber eben nur dann, wenn es angeschaltet wird, nicht, wenn es meldet "bin immer noch an"...
FHEM selbst kann nicht wissen, ob eine bloße Erneuerung vorliegt oder ein neuer Meßwert, selbst, wenn der unverändert ist. Ergo muß man das ggf. mühsam abschichten und dann ggf. die Gegenausnahmen und zeitlichen Grenzen festlegen (event-min-interval, event-on-update)...
Zitat von: Beta-User am 15 April 2020, 12:43:29
Wer da in die Irre läuft, ist nicht zwangsläufig ein DAU
Ach, du bist so gut zu mir, danke (auch für die Erklärung) :-* ;D
Zitat von: Schotty am 15 April 2020, 15:10:33
Ach, du bist so gut zu mir, danke (auch für die Erklärung) :-* ;D
Gern geschehen; ich (bzw. wir) brauch(en) diese Art der "anderen Erklärung" m.E. ja "irgendwann" (wenn sie taugt); wiederfinden wäre dann schön ;D .
Yupp, das Wiederfinden sollte nicht das Problem sein, ich werde bei Gelegenheit auch nochmal gezielt nach deinen Erklärungen für mich suchen und sie gesammelt abspeichern.
Der Grund für das 'Nicht-Funktionieren' bei mir, wenn ich e-o-c gesetzt hatte (Problem war: es wurde nichts mehr aktualisiert, auch wenn sich bspw der Brennerstatus geändert hatte), war jedoch offensichtlich ein ganz anderer (trivial und DAU-anmutend): Ich hatte e-o-c im Device gesetzt, aber keine Readings angegeben, da ich annahm, dass es dann für alle Readings von dem Device gelten würde. Funktioniert so aber anscheinend nicht ;)
Jetzt habe ich explizit die Readings mit angegeben und es scheint zu funktionieren :)
EDIT: Evtl hätte es mit attr SOB_Brenner event-on-change-reading .* funktioniert, dass e-o-c auf alle Readings im Device SOB_Brenner greift..?! Muss ich mal testen.. ;)