Hallo,
Ich nutze DBLogging.
Ich nutze DbLogExclude.* und include dann die Readings die ich auch will.
Nun ist mit aufgefallen, dass errechnete Readings nicht ins Log kommen.
Es werden immer nur die Readings geschrieben, die das Gerät auch liest.
Wie kann ich das ändern?
Gruß
Hallo Maci,
du must zunächst sicherstellen, dass dein errechnetes Reading einen Event erzeugt.
Ist das so ? (Eventmonitor).
Grüße,
Heiko
Ja es wird eine Event erzeugt.
Auszug aus dem Eventmonitor:
2020-04-05 09:08:47.199 ESPEasy Regenwasser_Wasserstand Distance: 169.57
2020-04-05 09:08:47.199 ESPEasy Regenwasser_Wasserstand Wasserstand: 134.43
Das Reading Distance wird geloggt, das Reading Wasserstand nicht.
Dieses Reading wird über ein notify errechnet und dann per setreading im Device eingetragen.
Wollte im dem Device urspünglich das per userReadings lösen, aber hier hat die Formel immer zu Fehlermeldungen geführt und nicht berechnet.
Im notify läuft es.
Hier noch List meines Devices:
Internals:
DEF 192.168.1.201 80 espBridge Regenwasser_Wasserstand
ESP_BUILD 20000
ESP_BUILD_GIT v2.0-20180220
ESP_BUILD_NOTES - Mega
ESP_NODE_TYPE_ID ESP Easy Mega
ESP_SLEEP 0
ESP_UNIT 2
ESP_VERSION 2
FUUID 5e88bafd-f33f-0d7f-3bad-6213c5f19a2e3f17
FVERSION 34_ESPEasy.pm:0.186080/2019-02-16
HOST 192.168.1.201
IDENT Regenwasser_Wasserstand
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MAX_CMD_DURATION 1
MSGCNT 152
NAME Regenwasser_Wasserstand
NOTIFYDEV global
NR 435
NTFY_ORDER 50-Regenwasser_Wasserstand
PORT 80
STATE Füllstand Zisterne: 134.79 cm | gemessene Wasserspiegelentfernung: 169.21 cm
SUBTYPE device
TYPE ESPEasy
VERSION 2.18
espBridge_MSGCNT 152
espBridge_TIME 2020-04-05 09:13:47
Helper:
DBLOG:
Distance:
DBLogging:
TIME 1586070827.31481
VALUE 169.21
READINGS:
2020-04-05 09:13:47 Distance 169.21
2020-04-05 09:13:47 Entfernung 169.21
2020-04-05 05:43:28 Fehlmessungen 11
2020-04-05 09:13:47 Wasserstand 134.79
2020-04-05 09:10:12 presence present
2020-04-05 09:13:47 state Dis: 169.21
helper:
fpc 1586021605.41653
pm:
Encode 1
JSON 1
received:
Distance 1586070827.31345
sec:
admpwd
Attributes:
DbLogExclude .*
DbLogInclude Wasserstand,Distance
IODev espBridge
Interval 300
alias Wasserstand_Regenwassertank
group Zisterne
icon sani_irrigation
mqttName Zysterne
mqttReadings Wasserstand
mqttRoom Regenwasser
presenceCheck 1
readingSwitchText 1
room 3.08_Regenwasser
setState 3
sortby 1
stateFormat {sprintf("Füllstand Zisterne: %.2f cm | gemessene Wasserspiegelentfernung: %.2f cm ",ReadingsVal($name,"Wasserstand",0),ReadingsVal($name,"Distance",0))}
Zur Vollständigkeit noch das List des Notifys:
Internals:
CFGFN
DEF Regenwasser_Wasserstand:Distance.* {
# Einlesen und berechnen der Werte
my $tiefe = ReadingsVal("TiefeRegenwassertank","state",0);
my $entfernung = ReadingsVal("Regenwasser_Wasserstand","Distance",0);
my $entfernung_last = ReadingsVal("Regenwasser_Wasserstand","Entfernung",0);
my $wasserstand_last = ReadingsVal("Regenwasser_Wasserstand","Wasserstand",0);
my $diff = ReadingsNum("DiffMessung","state",0);
my $fehler = ReadingsNum("Regenwasser_Wasserstand","Fehlmessungen",0);
# Berechnung
my $wasserstand = ($tiefe - $entfernung );
# Plausibilität prüfen
if ( ($entfernung < ($entfernung_last+$diff)) && ($entfernung > ($entfernung_last-$diff)) ) {
# Ausgabe wenn Messung ok
fhem ("setreading Regenwasser_Wasserstand Wasserstand $wasserstand");
fhem ("setreading Regenwasser_Wasserstand Entfernung $entfernung");
} else {
# Ausgabe wenn Messung falsch
fhem ("setreading Regenwasser_Wasserstand Wasserstand $wasserstand_last");
$fehler = $fehler +1;
fhem ("setreading Regenwasser_Wasserstand Fehlmessungen $fehler");
}
}
FUUID 5e88d13a-f33f-0d7f-b035-aa9a367c0b337a15
NAME nWasserstand
NOTIFYDEV Regenwasser_Wasserstand
NR 2062
NTFY_ORDER 50-nWasserstand
REGEXP Regenwasser_Wasserstand:Distance.*
STATE 2020-04-05 09:13:47
TRIGGERTIME 1586070827.31692
TYPE notify
Helper:
DBLOG:
state:
DBLogging:
TIME 1586024762.2145
VALUE active
READINGS:
2020-04-04 20:58:59 state active
Attributes:
DbLogExclude .*
group Zisterne
room 3.08_Regenwasser
Da der Event erzeugt wird, ist der nächste Schritt zu schauen was DbLog damit macht.
Dazu stellst du verbose 4 im DbLog ein und auch verbose4Devs auf Regenwasser_Wasserstand. Dadurch bleibt das Log übersichtlich.
Hier ein Logauszug mit SMA_Energymeter als Beispiel:
Zitat2020.04.05 09:28:33.820 4: DbLog LogDB1 -> ################################################################
2020.04.05 09:28:33.821 4: DbLog LogDB1 -> ### start of new Logcycle ###
2020.04.05 09:28:33.822 4: DbLog LogDB1 -> ################################################################
2020.04.05 09:28:33.823 4: DbLog LogDB1 -> number of events received: 16 for device: SMA_Energymeter
2020.04.05 09:28:33.823 4: DbLog LogDB1 -> check Device: SMA_Energymeter , Event: Bezug_WirkP_Zaehler_Diff: 0
2020.04.05 09:28:33.827 4: DbLog LogDB1 -> added event - Timestamp: 2020-04-05 09:28:33, Device: SMA_Energymeter, Type: SMAEM, Event: Bezug_WirkP_Zaehler_Diff: 0, Reading: Bezug_WirkP_Zaehler_Diff, Value: 0, Unit:
2020.04.05 09:28:33.828 4: DbLog LogDB1 -> check Device: SMA_Energymeter , Event: Bezug_WirkP_Kosten_Diff: 0.0000
2020.04.05 09:28:33.832 4: DbLog LogDB1 -> added event - Timestamp: 2020-04-05 09:28:33, Device: SMA_Energymeter, Type: SMAEM, Event: Bezug_WirkP_Kosten_Diff: 0.0000, Reading: Bezug_WirkP_Kosten_Diff, Value: 0.0000, Unit:
Du siehst immer die Abfolge check und added, falls der check erfolgreich war.
check bezieht sich dabei auf die Auswertung der Regex und Bedingungen (DbLogInclude etc.) in DbLog.
Wenn kein "added" erscheint, wird der Event aussortiert. Frage ist dann warum.
Ein List vom DbLog wäre dann noch hilfreich und eventuell auch ein DbLog verbose 5 je nach Sachlage.
Grüße,
Heiko
Hallo Heiko,
Ich habe das jetzt so eingestellt, wie beschrieben.
Hier habe ich gesehen, das Event Wasserstand kommt im DBLog gar nicht an.
Es kommt nur das Event Distance vor.
Eigenartig ist, dass es ja schon mal funktioniert hat. Hier war jedoch die Fomel zur Berechnung inkl. der Plausibilitätsprüfung im Device.
Jedoch eine ältere Version der Formel (mit Fehlern).
ich werde jetzt versuchen die Formel wieder als Userreading im Device zu integrieren.
mal sehen, ob das zum Erfolg führt.
Gruß
Georg
Hallo Georg,
Da beißt sich die Katze in den Schwanz. :)
Wahrscheinlich ist es ein Reihenfolge-Problem.
DbLog/Filelog ist im Prinzip auch nur ein Eventhandler wie Notify auch.
Der Wert im setreading wird im notify berechnet/gesetzt. Da sind die Events schon bei DbLog "durch" und Wasserstand gab es zu dem Zeitpunkt noch nicht.
Ich glaube da gabs auch schon diverse Diskussionen hier bzgl. setreading aus notify heraus. Ich weiß nicht ob ich die Möglichkeit habe die Reihenfolge im Modul programmtechnisch zu verändern. Müsste mal Rudi bei Gelegneheit fragen, aber der Fall kommt so selten vor dass ich es auch immer wieder vergesse bzw. es wichtigeres gibt ...
Ja, userreading sollte klappen. Muss auch hinzukriegen sein.
Grüße,
Heiko
Ein notify wid doch nicht mehr ausgeführt, wenn das gleiche device sich ändert ... könte es das sein? Dann müsste "nur" ein kurzes sleep vor dem setreading rein ...
Hallo,
Nach dem das mit der Formel in den Userreadings nicht klappt.
Fehler:
PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand"
PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain"
PERL WARNING: Deep recursion on subroutine "main::fhem"
usw. hat sich dann auch noch Fhem aufgehängt.
Ich habe es jetzt so gelöst, dass das notify nicht in das Device schreibt sondern in ein dummy.
Hier werden dann die Werte brav geloggt.
Ist zwar nicht die elegante Art, aber es funktioniert ohne Fehler.