Hi,
ich habe ein DoIf mit readings.
Leider werden die Readings nicht in die DB gelogged.
Habe:
DbLogInclude sum,sum_hour
und habe set_Reading ("sum_hour",::round(get_Reading("sum",0)/3600,1),1);;
mit 1 für triggerd, fals das was damit zu tun hat.
Hier das list des DoIf:
Internals:
DEF subs {
sub sum {
set_Reading ("end",time());;
set_Reading ("diff",get_Reading("end")-get_Reading("begin"));;
set_Reading ("begin",0);;
set_Reading ("sum_day",get_Reading("sum_day",0)+get_Reading("diff"));;
}
}
{ if ([ESPEasy_Heizung_langerSensor:Temperature:diff] > 0 and get_Reading("begin",0) == 0) {
set_Reading ("begin",time());;
} elsif ([ESPEasy_Heizung_langerSensor:Temperature:diff] < 0 and get_Reading("begin",0) > 0) {
sum();;
}
}
{ [00:01];;
if (get_Reading("begin",0) > 0) {
sum();;
set_Reading ("begin",time());;
}
set_Reading ("sum",get_Reading("sum",0) + get_Reading("sum_day",0),1);;
set_Reading ("sum_day",0);;
set_Reading ("sum_hour",::round(get_Reading("sum",0)/3600,1),1);;
}
FUUID 5e52bfbc-f33f-0c45-9da4-1d69e7252ce1bd92
MODEL Perl
NAME di_kessel
NOTIFYDEV ESPEasy_Heizung_langerSensor,global
NR 1440
NTFY_ORDER 50-di_kessel
STATE 15.1 h
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-02-26 22:21:25 Device ESPEasy_Heizung_langerSensor
2020-02-26 22:17:09 begin 0
2020-02-26 22:21:25 block_01 executed
2020-02-26 00:01:00 block_02 executed
2020-02-26 22:17:09 diff 16
2020-02-26 22:21:25 e_ESPEasy_Heizung_langerSensor_Temperature 63.00
2020-02-26 22:17:09 end 1582751829
2020-02-25 18:05:07 mode enabled
2020-02-23 19:09:00 state initialized
2020-02-26 00:01:00 sum 54430
2020-02-26 22:17:09 sum_day 24076
2020-02-26 00:01:00 sum_hour 15.1
2020-02-26 22:19:09 timer_01_c02 27.02.2020 00:01:00
Regex:
accu:
ESPEasy_Heizung_langerSensor:
accu:
Temperature ^ESPEasy_Heizung_langerSensor$:^Temperature:
cond:
ESPEasy_Heizung_langerSensor:
0:
Temperature ^ESPEasy_Heizung_langerSensor$:^Temperature:
1:
accu:
ESPEasy_Heizung_langerSensor Temperature:
dim 2
value:
63.25
63.00
condition:
0 if (::ReadingValDoIf($hash,'ESPEasy_Heizung_langerSensor','Temperature','','diff') > 0 and get_Reading("begin",0) == 0) {
set_Reading ("begin",time());;
} elsif (::ReadingValDoIf($hash,'ESPEasy_Heizung_langerSensor','Temperature','','diff') < 0 and get_Reading("begin",0) > 0) {
sum();;
}
1 ::DOIF_time_once($hash,0,$wday);;
if (get_Reading("begin",0) > 0) {
sum();;
set_Reading ("begin",time());;
}
set_Reading ("sum",get_Reading("sum",0) + get_Reading("sum_day",0),1);;
set_Reading ("sum_day",0);;
set_Reading ("sum_hour",::round(get_Reading("sum",0)/3600,1),1);;
days:
helper:
DEVFILTER ^global$|^ESPEasy_Heizung_langerSensor$
NOTIFYDEV global|ESPEasy_Heizung_langerSensor
event Temperature: 63.00
globalinit 1
last_timer 1
sleeptimer -1
triggerDev ESPEasy_Heizung_langerSensor
triggerEvents:
Temperature: 63.00
triggerEventsState:
Temperature: 63.00
internals:
intervalfunc:
localtime:
0 1582758060
perlblock:
0
1
readings:
all ESPEasy_Heizung_langerSensor:Temperature
realtime:
0 00:01:00
time:
0 00:01:00
timeCond:
0 1
timer:
0 0
timers:
1 0
trigger:
triggertime:
1582758060:
localtime 1582758060
hash:
uiState:
uiTable:
Attributes:
DbLogInclude sum,sum_hour
room ESPEasy,UG
stateFormat sum_hour h
Danke und Gruß,
Stefan
Ich nehme an, dass DBLog ereignisgesteuert arbeitet. Wenn du im Event-Monitor die passenden Events zu sum und sum_hour siehst, dann ist irgendetwas in DBLog nicht richtig konfiguriert.
Hi,
die events sehen so aus:
2020-02-28 16:22:44 DOIF di_kessel sum_day: 16923
Das DBLogInclude sieht so aus:
DbLogInclude sum,sum_hour,sum_day
Das sollte doch alles so stimmen.
Ich arbeite bei allen Devices mit DbLogInclude und es geht überall aber bei dem DOIF scheinbar nicht?
Kann ich das noch weiter untersuchen? Verbose 5 am di_kessel device oder am DB device?
Gruß,
Stefan
Zitat von: stefanru am 28 Februar 2020, 16:35:15
Hi,
die events sehen so aus:
2020-02-28 16:22:44 DOIF di_kessel sum_day: 16923
Das DBLogInclude sieht so aus:
DbLogInclude sum,sum_hour,sum_day
Das sollte doch alles so stimmen.
Ich arbeite bei allen Devices mit DbLogInclude und es geht überall aber bei dem DOIF scheinbar nicht?
Kann ich das noch weiter untersuchen? Verbose 5 am di_kessel device oder am DB device?
Gruß,
Stefan
speziell wird aber sum_day ohne Trigger geschrieben:
set_Reading ("sum_day",get_Reading("sum_day",0)+get_Reading("diff"));;Mit Trigger wäre es:
set_Reading ("sum_day",get_Reading("sum_day",0)+get_Reading("diff"),1);;
Ja das habe ich zu Testzwecken geändert.
Sorry hatte ich nicht gesagt.
Habe sum_day auch mit trigger geschrieben
set_Reading ("sum_day",get_Reading("sum_day",0)+get_Reading("diff"),1);;
und ins DbLogInclude aufgenommen um nicht immer einen Tag warten zu müssen.
Leider logged nichts in die DB.
Gruß,
Stefan
Du kannst es mit konventionellem setreading versuchen:
subs {
sub sum {
set_Reading ("end",time());
set_Reading ("diff",get_Reading("end")-get_Reading("begin"));
set_Reading ("begin",0);
my $sum_day= get_Reading("sum_day",0)+get_Reading("diff");
#set_Reading ("sum_day",get_Reading("sum_day",0)+get_Reading("diff"),1);
fhem "setreading $SELF sum_day ".$sum_day;
}
}
evtl. sum_day nicht im DOIF, sondern in einem Dummy ablegen: statt $SELF einen vorhanden Dummy angeben, den du dann loggen kannst.
Hi Damian,
ja denke das wird gehen, mit dummy auf jeden fall.
Werd mal testen ob setreading schon ausreicht oder ein dummy nötig ist.
Denke aber das DbLog das auch können sollte. Sind doch einfach nur Readings, sollte doch nicht stören dass die an nem DoIf hängen.
Gruß,
Stefan
Hallo zusammen,
ZitatDenke aber das DbLog das auch können sollte....
Kann es auch :)
Soviel ich gelesen habe, wird ja ein Event erzeugt. DbLog arbeitet Event gesteuert.
@Stefan, um mehr zu sehen setze dblog auf verbose 5 und dazu noch das Attr verbose4Devs auf den Namen deines DOIF Device sonst erschlägt dich die Masse der Informationen.
Dann siehst du etwa folgendes (Beispiel AutarkyQuote)
Zitat
2020.02.28 21:20:33.260 4: DbLog LogDB -> ################################################################
2020.02.28 21:20:33.260 4: DbLog LogDB -> ### start of new Logcycle ###
2020.02.28 21:20:33.261 4: DbLog LogDB -> ################################################################
2020.02.28 21:20:33.261 4: DbLog LogDB -> number of events received: 2 for device: Dum.Energy
2020.02.28 21:20:33.261 4: DbLog LogDB -> check Device: Dum.Energy , Event: AutarkyQuote: 0.0
2020.02.28 21:20:33.266 5: DbLog LogDB -> parsed Event: Dum.Energy , Event: AutarkyQuote: 0.0
2020.02.28 21:20:33.267 5: DbLog LogDB -> DbLogExclude of "Dum.Energy": GridConsumption,GridFeedIn,AutarkyQuote,SelfConsumptionQuote
2020.02.28 21:20:33.267 5: DbLog LogDB -> DbLogInclude of "Dum.Energy": AutarkyQuote
2020.02.28 21:20:33.269 4: DbLog LogDB -> added event - Timestamp: 2020-02-28 21:20:33, Device: Dum.Energy, Type: DUMMY, Event: AutarkyQuote: 0.0, Reading: AutarkyQuote, Value: 0.0, Unit:
2020.02.28 21:20:33.269 4: DbLog LogDB -> check Device: Dum.Energy , Event: T: 805.5
2020.02.28 21:20:33.273 5: DbLog LogDB -> parsed Event: Dum.Energy , Event: T: 805.5
2020.02.28 21:20:33.273 5: DbLog LogDB -> DbLogExclude of "Dum.Energy": GridConsumption,GridFeedIn,AutarkyQuote,SelfConsumptionQuote
2020.02.28 21:20:33.274 5: DbLog LogDB -> DbLogInclude of "Dum.Energy": AutarkyQuote
2020.02.28 21:20:33.276 4: DbLog LogDB -> added event - Timestamp: 2020-02-28 21:20:33, Device: Dum.Energy, Type: DUMMY, Event: T: 805.5, Reading: T, Value: 805.5, Unit:
Dann muss man natürlich schauen was mit dem DOIF Event passiert ...
Grüße,
Heiko
Das fhem "setreading $SELF sum_day ".$sum_day;" hat leider auch nichts gebracht.
Dann mache ich jetzt Verbose an und melde mich.
verbose 5
verbose4Devs di_kessel
Das erschlägt mich jetzt schon?
Scheint alles mit Verbose 5 gelogged zu werden nicht nur di_kessel?
Habe auch Verbose 4 probiert, da es bei Verbose4Devs so stand, logged aber immer noch alles.
Zumindest habe ich immer solche Sachen:
2020.02.28 22:07:11 4: DbLog logdb -> ################################################################
2020.02.28 22:07:11 4: DbLog logdb -> ### new get data for SVG ###
2020.02.28 22:07:11 4: DbLog logdb -> ################################################################
2020.02.28 22:07:11 4: DbLog logdb -> main PID: 4884, secondary PID: 16482
2020.02.28 22:07:11 4: logdb - Processing Statement:
SELECT
TIMESTAMP,
DEVICE,
READING,
VALUE
FROM history WHERE 1=1 AND DEVICE = 'meineWetterstation' AND READING = 'Illuminance' AND TIMESTAMP >= '2020-02-28 00:00:00' AND TIMESTAMP <= '2020-02-29 00:00:00' ORDER BY TIMESTAMP
Naja ich finde das di_kessel schon da drin. Ich logge jetzt einfach weiter.
Hier mal was er zum di_kessel bis jetzt hat:
2020.02.28 22:02:31 4: DbLog logdb -> ################################################################
2020.02.28 22:02:31 4: DbLog logdb -> ### start of new Logcycle ###
2020.02.28 22:02:31 4: DbLog logdb -> ################################################################
2020.02.28 22:02:31 4: DbLog logdb -> number of events received: 1 for device: di_kessel
2020.02.28 22:02:31 4: DbLog logdb -> check Device: di_kessel , Event: mode: enabled
2020.02.28 22:02:31 5: DbLog logdb -> parsed Event: di_kessel , Event: mode: enabled
2020.02.28 22:02:31 5: DbLog logdb -> DbLogInclude of "di_kessel": sum,sum_hour,sum_day
Danke!
Naja, ein SVG solltest du bei der Untersuchung grad mal nicht aufrufen sonst kommen diese Ausgabedaten noch ins Log.
Bezüglich di_kessel kommt aber nur der Event "mode: enabled", dein "sum|sum_hour|sum_day" fehlt bis jetzt ...
parsed Event: di_kessel , Event: mode: enabled
Ok jetzt hab ich was:
2020.02.28 22:11:05 4: DbLog logdb -> ################################################################
2020.02.28 22:11:05 4: DbLog logdb -> ### start of new Logcycle ###
2020.02.28 22:11:05 4: DbLog logdb -> ################################################################
2020.02.28 22:11:05 4: DbLog logdb -> number of events received: 1 for device: di_kessel
2020.02.28 22:11:05 4: DbLog logdb -> check Device: di_kessel , Event: diff: 6
2020.02.28 22:11:05 4: DbLog logdb -> ################################################################
2020.02.28 22:11:05 4: DbLog logdb -> ### start of new Logcycle ###
2020.02.28 22:11:05 4: DbLog logdb -> ################################################################
2020.02.28 22:11:05 4: DbLog logdb -> number of events received: 1 for device: di_kessel
2020.02.28 22:11:05 4: DbLog logdb -> check Device: di_kessel , Event: sum_day: 25368
2020.02.28 22:11:05 4: DbLog logdb -> added event - Timestamp: 2020-02-28 22:11:05, Device: di_kessel, Type: DOIF, Event: sum_day: 25368, Reading: sum_day, Value: 25368, Unit:
2020.02.28 22:13:15 4: DbLog logdb -> ################################################################
2020.02.28 22:13:15 4: DbLog logdb -> ### start of new Logcycle ###
2020.02.28 22:13:15 4: DbLog logdb -> ################################################################
2020.02.28 22:13:15 4: DbLog logdb -> number of events received: 1 for device: di_kessel
2020.02.28 22:13:15 4: DbLog logdb -> check Device: di_kessel , Event: sum_day: 25373
2020.02.28 22:13:15 5: DbLog logdb -> parsed Event: di_kessel , Event: sum_day: 25373
2020.02.28 22:13:15 5: DbLog logdb -> DbLogInclude of "di_kessel": sum,sum_hour,sum_day
2020.02.28 22:13:15 4: DbLog logdb -> added event - Timestamp: 2020-02-28 22:13:15, Device: di_kessel, Type: DOIF, Event: sum_day: 25373, Reading: sum_day, Value: 25373, Unit:
Das sieht doch gut aus, oder?
Ok,
hab meinen Fehler gefunden!
Das Device ist kleingeschrieben in der DB und die ist Case Sensitive.
Seltsam ist, dass ich am Anfang auch klein geschrieben gesucht hatte und auch nach tiemstamp.
Wahrscheinlich hatte ich da trigger nicht gesetzt.
Sorry für die unnötige Anfrage.
Ich danke euch.
Gruß,
Stefan
War doch nicht unnötig ... hast wieder eine Vorgehensweise zur Fehlersuche beim Logging gelernt. Kann man immer mal brauchen ;)
LG,
Heiko