Hallo zusammen
Nach über 1 1/2 Jahren mit fhem muss ich feststellen, das ich immer noch Anfänger bin. Ich hoffe, das meine Anfrage im richtigen Teil des Forums gelandet ist. Wenn nicht, bitte verschieben.
Als meine Heizung neulich morgens nicht eingeschaltet wurde, wollte ich der Ursache auf den Grund gehen und in der Logdatei des Aktors nachsehen, ob der Schaltbefehl überhaupt angekommen ist. Dazu habe ich über die Weboberfläche die Logdatei aufgerufen und bin auf "text" gegangen. Ein Klick auf "jump to the end" bewirkte nichts, außer das sich im Reiter des tabs ein drehenden Kringel befand. Also habe ich den Schieber am Bildrand ganz nach unten gezogen. Es dauerte ewig, bis sich der text nach und nach aufbaute. Die Einträge meines logfiles enden aber wohl am 27.03.2017 ???
Ähnlich verhält es sich, wenn ich versuche die Logdatei mittels Filezilla herunterzuladen um sie mit proton zu öffnen. Diese ist offenbar über 140 MB groß. Der Download hat sage und schreibe 2 Std. gedauert und auch hier waren die Einträge in der Datei im Juli zu Ende.
Mal abgesehen davon, das ich meine Logfiles alle irgendwie kleiner halten muss: Wie komme ich jetzt ans Ende des aktuellen Files?
edition
Hatte das Problem auch mal
Hab es so gelöst:
Internals:
DEF ./log/fhem-%Y-%m-%d.log fakelog
NAME Logfile
NR 12
NTFY_ORDER 50-Logfile
REGEXP fakelog
STATE active
TYPE FileLog
currentlogfile ./log/fhem-2017-11-11.log
logfile ./log/fhem-%Y-%m-%d.log
READINGS:
2017-11-11 00:00:01 linesInTheFile 0
Attributes:
nrarchive 7
EDIT: Versuch mal, ob Notepad++ die 140MB händeln kann.
Wie schon erwähnt, bin ich immer noch Anfänger.
Sehe ich es richtig, dass hier ein "fakelog" erzeugt wird, welches aus einem bestehenden Log einen Auszug anzeigt, oder bin ich auf dem Holzweg?
Hab grad mal nachgesehen. Bin auch "erst" 2 Jahre dabei.
Hab zwar schon viel mit FHEM experimentiert, aber auch für mich gibt
es noch viele unbekannte Sachen in FHEM.
So auch fakelog und was es damit auf sich hat.
Hab an Logfile nur eingestellt, dass es täglich ein neues Log gibt
und nur die 7 neuesten aufgehoben werden.
Ok, ich lade jetzt erst mal die Logdatei eines ähnlichen Aktors herunter, die nur 86MB groß ist und versuche die mit proton und Notepad++ zu öffnen. Wenn ich da Erfolg habe, versuche ich noch mal die große Datei.
Zum Thema fakelog werde ich mich erst einmal schlau lesen. Danke schon mal für die Anregeungen.
edition
Dein Problem wird wohl sein das Du wirklich alles vom Aktor logst und sicherlich kein event-on-change-reading oder ähnliches verwendest. Dazu kommt bestimmt noch das Du ein Jahreslog hast, da kommt so einiges zusammen.
Ja, richtig. Habe ich mich nicht weiter gekümmert. Wird alles geloggt, was kommt. Wird aber noch angepasst.
Stichwort Jareslog: Gibt es denn ein Monatslog? Wenn j, wie richte ich es ein?
Monatslog (das ist die Voreinstellung in der ausgelieferten fhem.cfg seit "immer"):
attr global logfile ./log/fhem-%Y-%m.log
nrarchive@Fakelog: Das funktioniert (wenn ueberhaupt) nur als Nebenwirkung, mit rechtzeitigen FHEM-Neustart. Besser:
attr global nrarchive 7
Grosse Dateien unter Unix: siehe "man tail"
Ja, bei den fhem.log Dateien wird monatlich eine neue angelegt. Bei den Sensoren und Aktoren wird aber nur eine Datei im Jahr angelegt. Kann ich die auch monatlich neu anlegen?
Hi,
ja, ergänze in der Definition ein %m für monatlich und oder ein %d für täglich.
Vergleich Mal hier im Thread. Da siehste wo das hin muss.
Grüße
Achim
Aaahhhh! Das hat schon mal funktioniert.
Ich habe das mal für meinen Schaltaktor mit Energiemessung im Keller angewendet. Das Log heißt jetzt nicht mehr "Aktor-2017.log" sondern "Aktor-2017-11.log". Dazu noch das RegexpPart angepasst und es werden nur noch 2 Werte statt 9 Werte geloggt. Der "state" des Aktor wird irgendwie nicht mitgeloggt. Werde es mal mit level, pct, oder timedon versuchen.
Wenn jetzt noch jemand sagen könnte, wie ich die Häufigkeit der Einträge beeinflussen kann, wäre ich doch schon am Ziel. Im Moment sind das ca. alle 2,5 min. Ich würde auf 3 oder 5 min gehen wollen. Das Atribut "actCycle" kann es ja wohl nicht sein. Das steht nämlich auf 000:10. Das wären 10 sec., oder 10 min, oder?
Wenn im Modul selbst nichts zu aendern ist, dann gibt es noch als letzten Ausweg (hoffentlich) event-min-interval
event-min-interval ist vorhanden. Ich habe jetzt .*:300 gesetzt. Scheint aber keine Auswirkung zu haben. Es wird weiterhin alle 2 bis 2,5 min ein Eintrag erzeugt. Auch in Verbindung mit event-on-update-reading ändert sich nichts.
edition
Event min Interval legt mindestens alle 5 min einen Eintrag an.
Was du brauchst ist evtl event-on-change-reading.
Mit dem Handy online, daher kurz gefasst...
Dann bekomme ich aber nur einen Eintrag, wenn sich ein Wert ändert, richtig? Das wollte ich in diesem Fall eigentlich nicht. Hier wird ein Schaltaktor mit Leistungsmessung geloggt. Der schaltet zusammen mit einem Thermostat einen Radiator im Keller. Der kommt aber nur gelegentlich zum Einsatz. Da würde dann Wochenlang evtl. nichts passieren. Für die Zentralheizung wäre das allerdings denkbar.
Ich beobachte mal, wie groß die log Dateien werden. Wenn das erträglich ist, lasse ich es so. Werden sie zu groß, denke ich noch mal drüber nach.
edition
Poste mal ein list von dem Aktor.
Dann können wir evtl eher sagen wo du ansetzen musst.
Und ja, für einen Powermeter ist event-on-change-reading nicht das wahre .
Mit dem Handy online, daher kurz gefasst...
Meinst du soetwas?
Internals:
DEF 45360A
IODev SCC
LASTInputDev SCC1
MSGCNT 549
NAME Heizung_Werkstatt
NOTIFYDEV global
NR 213
NTFY_ORDER 50-Heizung_Werkstatt
SCC1_MSGCNT 221
SCC1_RAWMSG A14B0845E45360A000000808BD1000000000008D1FF::-109:SCC1
SCC1_RSSI -109
SCC1_TIME 2017-11-12 22:32:04
SCC_MSGCNT 328
SCC_RAWMSG A14B0845E45360A000000808BD1000000000008D1FF::-64.5:SCC
SCC_RSSI -64.5
SCC_TIME 2017-11-12 22:32:04
STATE CMDs_done
TYPE CUL_HM
channel_01 Heizung_Werkstatt_Sw
channel_02 Heizung_Werkstatt_Pwr
channel_03 Heizung_Werkstatt_SenPwr
channel_04 Heizung_Werkstatt_SenI
channel_05 Heizung_Werkstatt_SenU
channel_06 Heizung_Werkstatt_SenF
lastMsg No:B0 - t:5E s:45360A d:000000 808BD1000000000008D1FF
protLastRcv 2017-11-12 22:32:04
rssi_at_SCC cnt:328 max:-62 lst:-64.5 min:-67 avg:-63.75
rssi_at_SCC1 cnt:221 avg:-106.11 max:-103.5 lst:-109 min:-110
READINGS:
2017-11-12 08:28:05 Activity alive
2017-11-07 15:40:13 CommandAccepted yes
2017-02-12 18:10:11 D-firmware 1.6
2017-02-12 18:10:11 D-serialNr NEQ0154689
2017-11-07 15:40:25 PairedTo 0x000FFF
2017-11-07 15:40:25 R-pairCentral 0x000FFF
2017-11-07 15:40:25 RegL_00. 02:01 0A:00 0B:0F 0C:FF 18:00 00:00
2017-11-07 15:59:30 powerOn 2017-11-07 15:59:30
2017-11-11 21:00:21 state CMDs_done
helper:
HM_CMDNR 176
mId 00AC
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +45360A,00,00,00
nextSend 1510522325.04446
prefIO
rxt 0
vccu
p:
45360A
00
00
00
mRssi:
mNo B0
io:
SCC -62.5
SCC1 -109
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat 01
role:
dev 1
prs 1
rssi:
at_SCC:
avg -63.7560975609756
cnt 328
lst -64.5
max -62
min -67
at_SCC1:
avg -106.119909502262
cnt 221
lst -109
max -103.5
min -110
tmpl:
Attributes:
IODev SCC
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
event-min-interval .*:300
event-on-update-reading .*
expert 2_raw
firmware 1.6
model HM-ES-PMSw1-Pl
room 05_Keller
serialNr NEQ0154689
subType powerMeter
webCmd getConfig:clear msgEvents
Zitatevent-min-interval ist vorhanden [...] Auch in Verbindung mit event-on-update-reading ändert sich nichts.
Achtung: die Kombination verschiedener Optionen ist nicht intuitiv. Aus dem Commandref:
Zitatevent-min-interval
This attribute takes a comma-separated list of reading:minInterval pairs. You may use regular expressions for reading. Events will only be generated, if at least minInterval seconds elapsed since the last reading of the matched type. If event-on-change reading is also specified, they are combined with OR: if one of them is true, the event is generated.