Hallo
mein Shelly 2.5 schreibt sehr viel ins Log
Dies will ich mit "ignoreRegexp" eingrenzen. Leider funktioniert es nur teilweise. Ist dieses attr begrenzt?
Der erste Til wird nicht mehr aufgezeichnet, aber ab dem 7ten Eintrag wird wieder fleißig geschrieben?
Hier ein List
Internals:
DEF ./log/MV_Brunnen-%Y.log MV_Brunnen
FD 17
FUUID 5c4b2e6d-f33f-b033-41ef-f3461981b36aa98d
NAME FileLog_MV_Brunnen
NOTIFYDEV MV_Brunnen
NR 138
NTFY_ORDER 50-FileLog_MV_Brunnen
REGEXP MV_Brunnen
STATE active
TYPE FileLog
currentlogfile ./log/MV_Brunnen-2020.log
logfile ./log/MV_Brunnen-%Y.log
READINGS:
2020-12-12 14:48:31 linesInTheFile 7573183
Attributes:
ignoreRegexp .*new_fw.* | .*id.* | .*mac.* | .*fw_ver.* | .*ip.* | .*model.* | .*input_0.* | .*event_cnt.* | .*event.* | .*temperature_f.* | .*overtemperature.*
logtype text
room Logs
Und ein Bild vom LogFile
Was mach ich da falsch?
Danke
Helmut
Ich würde zuerst die Leerzeichen entfernen
warum zuerst "her mit allem" und dann aber sagen du & du dann doch nicht, statt gleich nur das zuzulassen was man wirklich will ?
M.E. liegt das Problem weniger auf der FileLog-Seite, sondern zu einem großen Teil an ungünstigen event-on-change-etc.-Attributen an dem MQTT2_DEVICE (das ist doch das ausgangsdevice, oder?).
Speziell zu Shelly@MQTT2_DEVICE warte ich seit Monaten darauf, dass jemand auf den Zug aufspringt und sich mal tiefgreifend Gedanken macht, ob das, was ich da irgendwo mal kurz zusammengeklöppelt habe denn jetzt ein "guter Standard" (bekanntzumachen via attrTemplate) werden soll. Über https://forum.fhem.de/index.php/topic,116162.msg1104833.html#msg1104833 (https://forum.fhem.de/index.php/topic,116162.msg1104833.html#msg1104833) wäre ggf. dann die passende "Generaldiskussion" zu finden.
Die Auswirkungen, wenn man da nicht sauber vorgeht und das dann noch nicht optimalen regexp kombiniert (egal, ob FileLog, notify oder anderer Event-Handler) kann man dann z.B. hier sehen (in dem konkreten Beitrag ist auch zu finden, wie man z.B. für notify feststellen kann, wie groß das "Problem" ggf. ist): https://forum.fhem.de/index.php/topic,116547.msg1109967.html#msg1109967
@Helmi55
Zitat2020-12-12 14:48:31 linesInTheFile 7573183
Mehr als 7 Millionen Datensätze - definitiv eine "viel" zu hohe Zahl.
Zitat von: Wzut am 12 Dezember 2020, 19:48:41
warum zuerst "her mit allem" und dann aber sagen du & du dann doch nicht, statt gleich nur das zuzulassen was man wirklich will ?
Auf jeden Fall sehr empfehlenswert. Will man nur bestimmte Readings loggen, ist die Einschränkung bei der FileLog-
Definition die beste Lösung. Der Einsatz von
ignoreRegexp dient in einem solchen Fall nur dem nicht abwendbarem Feinschliff, sofern notwendig.
Zitat
Was mach ich da falsch?
Diese Frage ist nicht wirklich beantwortbar, da unklar ist, was Du genau machen willst.
Um einer brauchbaren Lösung näherzukommen, wäre ein
list von
MV_Brunnen hilfreich.
Die Readings, die Du wirklich loggen willst, solltest Du aufführen.
Sollte der Vorwärtsweg nicht möglich sein, müsstest Du die unerwünschten Readings nennen. Im Hinterkopf sollte man dabei immer haben, dass mit z.B. Firmware-Updates u.U. wieder neue, unerwünschte Readings dazukommen ...
Generell kann man sagen:
*** Ebene #1 ***
Verwendung von "
event-on-change-reading .*" beim Event-liefernden Device. Readings für Temperatur, Verbrauch, usw. werden u.U. noch durch die Angabe eines Schwellwertes verfeinert. Will man nur für bestimmte Readings Events bekommen, kann man hier auch eine geeignete Liste hinterlegen.
*** Ebene #2 ***
Bei der FileLog-
Definition wird festgelegt, welche Werte man loggen will. Sollte die Angabe für die Eingrenzung nicht ausreichen, kann man via
ignoreRegexp das Logging weiter beeinflussen. "Neuerdings" kann man auch via
filelog-event-min-interval das Log-Verhalten einschränken - bei power-Devices von shelly oder innr nicht ganz uninteressant.
Hallo und Danke für eure Lösungsansätze
@ Amenomade
Du hast recht - ich brauche eine Brille - ich habe das im Wiki als Leerzeichen angesehen ;D 8)
@Wzut
Das ist sicher der einfachere Weg
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:(on|off)
@OdfFhem
Danke für deine Hilfe. Ziel war es für mich nur aufzuzeichnen ob on off beim Magnetventil richtig funktioniert (hier habe ich im Moment das Aufwändige
Ausschlussverfahren ignoreRegexp eingegeben) und bei der BrunnenHeizung habe ich jetzt wie oben nur on|off geschrieben.
Ach ja und event-on-change-reading habe ich jetzt natürlich auch .* gesetzt.
@Beta-User
Du hast vollkommen recht, die Shellies senden eine Datenflut.
Aber deine Ansätze sind MIR als einfacher, kleiner User eine oder mehrere Nummern zu groß
Sicher könnte ich auch schon in den Templates Veränderungen durchführen, aber das ist mir zu unsicher
Nochmals Danke für eure Hilfen und einen schönen 3. Advent
Ich schließe das Thema noch nicht - hoffe das es noch Diskussionen geben wird
Zitat von: Helmi55 am 13 Dezember 2020, 11:17:13
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:(on|off)
M.E. besser:
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:o[nf]+Schau dir einfach an, ob da ein NOTIFYDEV erscheint.
Servus ja tut es (ist aber schon hohe Programmierkunst oder? 8))
das bedeutet alles was mit o anfängt und auf n und f ändert wird berücksichtigt z. B. oben
Danke
Helmut
Nein, es war was anderes gemeint. Vor und nach der Änderung mal ein list nach dem genannten Schlagwort durchsuchen, dann wird es evtl. klarer ;) .
Hab das gerade noch in meinen Post eingefügt
das bedeutet alles was mit o anfängt und auf n und f ändert wird berücksichtigt z. B. oben
Nochmal eine Langfassung:
Wir haben hier zwei Themen: zum einen die Frage einer optimierten regexp beim Eventhandler (hier: FileLog).
Zum anderen die Frage der "guten" Gestaltung des Ausgangsdevices, dass es _nur die Events erzeugt_, die du auch brauchst.
Zum ersten Punkt: Ein Eventhandler, der NOTIFYDEV grundsätzlich unterstützt, aber dieses nicht in den Internals anzeigt, bekommt einfach alle Events (d.h., auch von ganz anderen Geräten, einfach alles) und muss dann entscheiden, ob diese ihn überhaupt interessieren. Ist die regexp "gut", bekommt er nur noch Events von den Geräten, auf die NOTIFYDEV zutrifft, also weniger.
Das ganze ist eine reine Performance-Frage, beide regexp führen zu passenden Einträgen im Log.
Deswegen: Ändere das define mal in beide Varianten und schau dann jeweils mal in ein list, ob du NOTIFYDEV findest...
Du kannst das alternativ mit einer speziellen Funktion testen:
{ notifyRegexpCheck('Heizung_Brunnen:(on|off)') } bzw.
{ notifyRegexpCheck('Heizung_Brunnen:o[nf]+') }
Das andere Thema ist komplexer:
In dem einen Beitrag war eine "Muster"-RAW-Definition. in der sind m.E. folgende Zeilen interessant:
attr Muster_Shelly1pm event-on-change-reading state,temperature:0.2,online,loadState,overtemperature,Verbrauch_Total_kWh,relay_0_.*,relay0,input0
attr Muster_Shelly1pm event-on-update-reading stat[ERT].*
attr Muster_Shelly1pm timestamp-on-change-reading state,online,loadState,overtemperature
[...]
shellies/shelly1pm-123456789012/temperature_f:.* {}\
Fangen wir mit der letzten an:
Zunächst mal erzeugt jeder Match in der readingList ein Event, wenn ein Reading erzeugt wird. Da wir hier aber in der Regel nur die °C-Werte beachten, interessieren uns die in Fahrenheit umgerechneten Werte gar nicht. Diese letzte Zeile sagt also schlicht: Mache nichts, erzeuge kein Reading.
Eigentlich würde man sich wünschen, dass das in der Shelly-firmware konfigurierbar wäre, so müssen wir diesen Unsinn eben irgendwie bearbeiten.
Die Alternative wäre, die Zeile nicht zu schreiben und stattdessen das autocreate-Attribut am Gerät auf "0" zu setzen. Da ich davon ausgehe, dass jemand früher oder später da Änderungen vornimmt und das vermutlich auch kaum ein Performance-Unterschied macht, würde ich das mit dem "mache nichts" eigentlich auch gerne zum Standard machen.
Zu dieser Frage kann sich auch jeder "normale" User äußern, das ist keine komplexe Angelegenheit.
Das mit den ersten beiden anderen ist genau das, was OdfFhem als "Ebene 1" beschrieben hat.
Auch da würde mich eigentlich nur interessieren, ob das auch für andere soweit taugliche Einstellungen sind, dass die für >80% der Fälle als "brauchbar" angesehen werden können.
Ist also auch nur "verstehen und Meinung abgeben".
Das dritte aus der "eocr"-Familie "timestamp-on-change-reading" ist ein bisschen spezieller. Da geht es darum, dass mit event-on-... zwar kein Event erzeugt wird, aber der Zeitstempel trotzdem aktualisiert wird. Mit anderen Worten: die Antwort auf die Frage: "Wann wurde xy eingeschaltet?" wird falsch beantwortet, wenn man ReadingsAge() verwendet.
Mit diesem Attribut wird das geändert. Auch da ist eben die schlichte Frage: Ist das ein sinnvoller Vorschlag oder nicht...
Deine Meinung würde mich interessieren ;) .
Hallo guten Abend
hier noch das List vom MV_Brunnen - war ich noch schuldig -sorry
Internals:
CID shellyswitch25_686C74
DEF shellyswitch25_686C74
DEVICETOPIC MV_Brunnen
FUUID 5fd5df5d-f33f-b033-3db7-a66e9062a71f65f4
IODev myBroker
LASTInputDev myBroker
MSGCNT 7128
NAME MV_Brunnen
NR 541
STATE off
TYPE MQTT2_DEVICE
myBroker_MSGCNT 7128
myBroker_TIME 2020-12-13 18:30:34
READINGS:
2020-12-13 10:31:12 actions_stats_skipped 0
2020-12-13 10:31:41 associatedWith Heizung_Brunnen
2020-12-13 10:31:09 attrTemplateVersion 20200831
2020-12-13 10:31:12 cfg_changed_cnt 1
2020-12-13 10:31:12 cloud_connected false
2020-12-13 10:31:12 cloud_enabled false
2020-12-13 18:30:34 event
2020-12-13 18:30:34 event_cnt 0
2020-12-13 10:31:12 fs_free 122237
2020-12-13 10:31:12 fs_size 233681
2020-12-13 11:05:53 fw_ver 20201128-102046/v1.9.2@e83f7025
2020-12-13 10:31:12 has_update false
2020-12-13 11:05:53 id Brunnen__switch25-686C74
2020-12-13 18:30:34 input1 0
2020-12-13 10:31:12 inputs_1_event
2020-12-13 10:31:12 inputs_1_event_cnt 0
2020-12-13 10:31:12 inputs_1_input 0
2020-12-13 10:31:12 inputs_2_event
2020-12-13 10:31:12 inputs_2_event_cnt 0
2020-12-13 10:31:12 inputs_2_input 0
2020-12-13 11:05:53 ip 10.0.0.155
2020-12-13 11:05:53 mac 2CF432686C74
2020-12-13 10:31:12 meters_1_counters_1 0.000
2020-12-13 10:31:12 meters_1_counters_2 0.000
2020-12-13 10:31:12 meters_1_counters_3 0.000
2020-12-13 10:31:12 meters_1_is_valid true
2020-12-13 10:31:12 meters_1_overpower 0.00
2020-12-13 10:31:12 meters_1_power 0.00
2020-12-13 10:31:12 meters_1_timestamp 1607855472
2020-12-13 10:31:12 meters_1_total 0
2020-12-13 10:31:12 meters_2_counters_1 0.000
2020-12-13 10:31:12 meters_2_counters_2 0.000
2020-12-13 10:31:12 meters_2_counters_3 0.000
2020-12-13 10:31:12 meters_2_is_valid true
2020-12-13 10:31:12 meters_2_overpower 0.00
2020-12-13 10:31:12 meters_2_power 0.00
2020-12-13 10:31:12 meters_2_timestamp 1607855472
2020-12-13 10:31:12 meters_2_total 0
2020-12-13 11:05:53 model SHSW-25
2020-12-13 10:31:12 mqtt_connected true
2020-12-13 11:05:53 new_fw false
2020-12-13 11:05:53 online true
2020-12-13 18:30:34 overtemperature 0
2020-12-13 10:31:12 ram_free 35132
2020-12-13 10:31:12 ram_total 48704
2020-12-13 18:30:34 relay1 off
2020-12-13 18:30:34 relay_1_energy 9
2020-12-13 18:30:34 relay_1_kWh 0.00
2020-12-13 18:30:34 relay_1_power 0.00
2020-12-13 10:31:12 relays_1_has_timer false
2020-12-13 10:31:12 relays_1_is_valid true
2020-12-13 10:31:12 relays_1_ison false
2020-12-13 10:31:12 relays_1_overpower false
2020-12-13 10:31:12 relays_1_overtemperature false
2020-12-13 10:31:12 relays_1_source input
2020-12-13 10:31:12 relays_1_timer_duration 0
2020-12-13 10:31:12 relays_1_timer_remaining 0
2020-12-13 10:31:12 relays_1_timer_started 0
2020-12-13 10:31:12 relays_2_has_timer false
2020-12-13 10:31:12 relays_2_is_valid true
2020-12-13 10:31:12 relays_2_ison false
2020-12-13 10:31:12 relays_2_overpower false
2020-12-13 10:31:12 relays_2_overtemperature false
2020-12-13 10:31:12 relays_2_source input
2020-12-13 10:31:12 relays_2_timer_duration 0
2020-12-13 10:31:12 relays_2_timer_remaining 0
2020-12-13 10:31:12 relays_2_timer_started 0
2020-12-13 10:31:12 serial 3
2020-12-13 18:30:34 state off
2020-12-13 18:30:34 temperature 34.98
2020-12-13 18:30:34 temperature_f 94.96
2020-12-13 10:31:12 temperature_status Normal
2020-12-13 10:31:12 time 10:31
2020-12-13 10:31:12 tmp_is_valid true
2020-12-13 10:31:12 tmp_tC 34.80
2020-12-13 10:31:12 tmp_tF 94.65
2020-12-13 10:31:12 unixtime 1607855472
2020-12-13 10:31:12 update_beta_version 20201202-140039/v1.9.3-rc3@50c6ab57
2020-12-13 10:31:12 update_has_update false
2020-12-13 10:31:12 update_new_version 20201128-102046/v1.9.2@e83f7025
2020-12-13 10:31:12 update_old_version 20201128-102046/v1.9.2@e83f7025
2020-12-13 10:31:12 update_status idle
2020-12-13 10:31:12 uptime 36
2020-12-13 10:31:12 voltage 223.59
2020-12-13 10:31:12 wifi_sta_connected true
2020-12-13 10:31:12 wifi_sta_ip 10.0.0.155
2020-12-13 10:31:12 wifi_sta_rssi -27
2020-12-13 10:31:12 wifi_sta_ssid xxxxxxxxx
Attributes:
IODev myBroker
comment Channel 2 for MQTT2_shellyswitch25_686C74
devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen"; my $light = ReadingsVal($name,"state","off"); my $cons = ReadingsVal($name,"relay_1_power","unknown"); my $temp = ReadingsVal($name,"temperature","-100");"<div><a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C<b></b>"}
event-on-change-reading .*
model shelly25_split
readingList shellies/Brunnen__switch25-686C74/relay/1:.* state
shellies/Brunnen__switch25-686C74/relay/1:.* relay1
shellies/Brunnen__switch25-686C74/input/1:.* input1
shellies/Brunnen__switch25-686C74/online:.* online
shellies/announce:.* { $EVENT =~ m,..id...Brunnen__switch25-686C74...mac.*, ? json2nameValue($EVENT) : return }
shellies/Brunnen__switch25-686C74/announce:.* { json2nameValue($EVENT) }
shellies/Brunnen__switch25-686C74/relay/1/power:.* relay_1_power
shellies/Brunnen__switch25-686C74/relay/1/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }
shellies/Brunnen__switch25-686C74/temperature:.* temperature
shellies/Brunnen__switch25-686C74/overtemperature:.* overtemperature
shellies/Brunnen__switch25-686C74/temperature_f:.* temperature_f
shellies/Brunnen__switch25-686C74/relay/1/energy:.* relay_1_energy
shellies/Brunnen__switch25-686C74/relay/1/energy:.* {'relay_1_kWh' => sprintf("%.2f",$EVENT/60/1000)}
shellies/Brunnen__switch25-686C74/longpush/1:.* longpush_1
shellies/Brunnen__switch25-686C74/input_event/1:.* { json2nameValue($EVENT) }
shellyswitch25_686C74:shellies/Brunnen__switch25-686C74/info:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setList off:noArg shellies/Brunnen__switch25-686C74/relay/1/command off
on:noArg shellies/Brunnen__switch25-686C74/relay/1/command on
1 Kanal davon ist im Brunnenhaus für die Heizung im Winter zuständig und
der 2 Kanal davon schaltet jeden Tag um 7 Uhr ein Magnetventil für 30 Sekunden am Windkessel ein (hilft das keine Luft in den langen Leitungen zum Haus ist)
und hier möchte ich nun gerne auf einen Blick im Logfile sehen ob das ordentlich abgehandelt wurde, bzw. ob der Heizlüfter richtig arbeitet.
Ich könnte es natürlich auch noch mit einer Pushover Meldung verknüpfen um ganz sicher zu sein.
So mache ich es zum Beispiel bei meiner Teststation von der ich meine Unifi NanoStations anpinge und bei absent bekomm ich eine Meldung aufs handy
Aber Gott sei Dank das funktioniert jetzt bestens und ich hab keine Ausfälle mehr.
Ich habe jetzt bei der Heizung_Brunnen folgende def im LogFile
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:o[nf]+
Und bekomme eine schöne Auswertung:
Danke Beta-user für deine Zeit und genaue Erklärung - muss ich mir in Ruhe durcharbeiten
Zitat von: Helmi55 am 13 Dezember 2020, 18:44:10
Danke Beta-user für deine Zeit und genaue Erklärung - muss ich mir in Ruhe durcharbeiten
Gerne :) .
Du bist btw. bei weitem nicht der einzige User mit dieser Art Problem (aber einer der Wenigen, die das thematisieren, wenn auch am "falschen Ende", von daher: Respekt!).
Danke auch für das list. Ich habe nur den einen "Muster-"Shelly und den schon länger nicht mehr upgedated. Mit jedem update scheint der Hersteller die MQTT-Schnittstelle noch "geschwätziger" gemacht zu haben; unschön. Von daher wird wohl v.a. der "info"-Topic nochmal etwas näherer Betrachtung bedürfen.
Muß wohl mal ein update machen, ist eher schwierig zu erklären, was mir in Bezug auf das Topic so alles im Kopf rumschwirrt. (Falls einer mitliest, der mehr mit dem "workshop" anfangen kann, wäre es toll, wenn derjenige die Hand heben würde und fertige Vorschläge für jsonMap & eocr&Co liefern möchte...)
Servus
wie meinst du das "am falschen Ende"?
Tja ich frage halt hier im Forum wenn ich mich nicht auskenne bzw. wenn ich durch wiki oder Cref nicht klug werde
Habe dafür auch schon viel Kritik einstecken müssen, aber ich denke mir dazu ist ja das Forum da.
Nice eve
Helmut
Zitat von: Helmi55 am 14 Dezember 2020, 18:57:46
Tja ich frage halt hier im Forum wenn ich mich nicht auskenne
da hast aber jetzt etwas gründlich falsch verstanden .... mit dem falschen Ende war das FileLog gemeint, frei nach dem Motto was am Anfang erst gar nicht da ist muss man später nicht mit Gewalt platt schlagen.
OK alles klar.
Aber ein FileLog brauch ich doch (in meinem Fall halt nur mit der Anzeige on|off)
Sicher war mein Ansatz der Falsche - nicht ausschließen - sondern nur die 2 Loggen
So hab ich das ja nun umgesetzt. Das ignore ist mir als erstes "Aufgestoßen"
Nice Eve
Helmut