Hallo.
Ich habe eine Zigbee Schaltsteckdose.
Das autocreate hat ein FileLog angelegt, das im Minutentakt Einträge erzeugt.
Außerdem ist dort nicht der Status enthalten, es bringt mir so gar nichts.
2021-12-15_20:18:17 Steckdose_D lastseen: 2021-12-15T19:18Z
2021-12-15_20:19:17 Steckdose_D lastseen: 2021-12-15T19:18Z
2021-12-15_20:20:17 Steckdose_D lastseen: 2021-12-15T19:19Z
Da mir das Log so extrem groß wurde und ich das nicht umgestellt bekomme, habe ich das ganze erst mal deaktiviert.
Wie erreiche ich das nur "state" geloggt wird?
Dort steht on/off und das reicht ja.
Danke.
Die Frage ist ja ob Du das wirklich brauchst im Log? Bringt es Dir einen Mehrwert? Wenn nicht lösche das Logdevice.
Ich wusste gar nicht das HUEDevice überhaupt ein Logfile an legt. Bei mir tut es das jedenfalls nicht.
Ich möchte nur on und off loggen.
Jetzt wo du es sagst...es war vorher eine 433Mhz Steckdose, diese habe ich ausgetauscht und das Device einfach umbenannt. Deshalb auch das Log.
Ich habe nun die DEF des Logfile auf state:.* geändert.
(Schon gruselig das ich vorher ewig gesucht und nach dem posten das dann gefunden habe)
So wie es aussieht, loggt es dann gar nichts, on und off steht aber im state ?!
Dann hab ich noch onoff:.* dazu gepackt und jetzt habe ich
onoff: 1
onoff: 0
Das ist ok.
Ein anderes Gerät bietet mir nur on:.* Und off:.* getrennt an (oben in der regex Zeile) mal sehen ob das auch geht.
Danke.
zeig mal bitte ein list vom logfile device
Hier erscheint nur onoff: 0 oder onoff: 1
Internals:
DEF ./log/Steckdose_A-%Y-%m.log Steckdose_A:onoff:.*|Steckdose_A:state:.*
FD 69
FUUID 5c549d00-f33f-b7a0-dd56-7596dcd751edc901
NAME FileLog_Steckdose_A
NOTIFYDEV Steckdose_A
NR 38
NTFY_ORDER 50-FileLog_Steckdose_A
REGEXP Steckdose_A:onoff:.*|Steckdose_A:state:.*
STATE active
TYPE FileLog
currentlogfile ./log/Steckdose_A-2021-12.log
logfile ./log/Steckdose_A-%Y-%m.log
READINGS:
2021-12-16 16:51:06 linesInTheFile 12
Attributes:
logtype text
nrarchive 2
room HUEDevice
Hier erscheint jetzt gar nichts mehr im Log:
Internals:
DEF ./log/Steckdose_D-%Y-%m.log Steckdose_D:state:.*
FD 71
FUUID 5c549d00-f33f-b7a0-9aaf-ca3f6aed6ee55844
NAME FileLog_Steckdose_D
NOTIFYDEV Steckdose_D
NR 37
NTFY_ORDER 50-FileLog_Steckdose_D
REGEXP Steckdose_D:state:.*
STATE active
TYPE FileLog
currentlogfile ./log/Steckdose_D-2021-12.log
logfile ./log/Steckdose_D-%Y-%m.log
READINGS:
2021-12-16 07:37:21 linesInTheFile 4
Attributes:
disable 0
logtype text
nrarchive 2
room HUEDevice
Das onoff reicht mir.
Aber eigentlich sollte ja auch was passieren wenn ich state:.* verwende, oder ?
onoff und state sind zwei unterschiedliche readings.
das event für state enthält normalerweise den reading namen nicht.
für notify gibt es das addStateEvent attribut.
am besten schaust du dir die ganzen zusammenhänge noch mal in ruhe an und verwendest mal den event monitor zum zu sehen was passiert.
DEF ./log/Steckdose_D-%Y-%m.log Steckdose_D:(on|off)
Könnte man nehmen um state zu bekommen. Halt eben nur on oder off
Zitat von: CoolTux am 16 Dezember 2021, 17:27:24
DEF ./log/Steckdose_D-%Y-%m.log Steckdose_D:(on|off)
Könnte man nehmen um state zu bekommen. Halt eben nur on oder off
...oder vielleicht lieber
DEF ./log/Steckdose_D-%Y-%m.log Steckdose_D:o[nf]+...?
Das state und onoff zwei unterschiedliche readings sind, weiß ich.
Warum dann aber bei state:.* gar nichts kommt, verstehe ich nicht.
Im eventmonitor erscheint on und off und 100 pct für Helligkeit usw.
Ich habe nun mal
DEF ./log/Steckdose_D-%Y-%m.log Steckdose_D:(on|off)
getestet und das funktioniert.
Ich erhalte ein on und off. Das ist dann schon besser.
Jetzt weiß ich das ich so auch andere Log´s verändern kann.
Danke für die schnelle Hilfe
Zitat von: Loctite am 16 Dezember 2021, 18:47:10
Das state und onoff zwei unterschiedliche readings sind, weiß ich.
Warum dann aber bei state:.* gar nichts kommt, verstehe ich nicht.
Im eventmonitor erscheint on und off und 100 pct für Helligkeit usw.
Ich habe nun mal
DEF ./log/Steckdose_D-%Y-%m.log Steckdose_D:(on|off)
getestet und das funktioniert.
Ich erhalte ein on und off. Das ist dann schon besser.
Jetzt weiß ich das ich so auch andere Log´s verändern kann.
Danke für die schnelle Hilfe
Weil der Event kein state enthält. Schau mal in den Eventmonitor. Für state ist der Event ein anderer wie für andere Readings.
*Kopfschüttel*
addStateEvent nicht nachgelesen, und dann zielsicher die zweitbeste Variante kopiert....
Bin dann mal raus.
Zitat von: CoolTux am 16 Dezember 2021, 18:52:08
Weil der Event kein state enthält. Schau mal in den Eventmonitor. Für state ist der Event ein anderer wie für andere Readings.
Hm, sorry, verstehe ich nicht so ganz.
Ich war ja im Eventmonitor:
2021-12-17 17:37:58 HUEDevice Steckdose_A onoff: 1
2021-12-17 17:37:58 HUEDevice Steckdose_A pct: 100
2021-12-17 17:37:58 HUEDevice Steckdose_A onDas erhalte ich wenn ich die Steckdose an schalte.
onoff und pct sind readings. Das on ist vom state.
Eigentlich dachte ich das wäre egal ob nun dieses "state" davor steht oder nicht und FHEM entfernt das nur, warum auch immer in dem Fall
@Beta-User
Die zweitbeste Variante ist manchmal doch auch Ok...oder nicht ?
Ich dachte mir, da du nicht geschrieben hast, das (on|off) komplett falsch ist und es auch direkt funktioniert hat, weiß ich ehrlich gesagt nicht was ich da jetzt noch anzweifeln sollte.
Mit dem onoff: 1 war ich ja auch schon zufrieden.
Leider ist bei dem device auch gar kein addStateEvent möglich. Es steht nicht zur Auswahl und wenn ich es per attr hinzufügen will, dann geht das auch nicht.
Also habe ich beim FileLog device nachgeschaut...ja da gibt es so was.
Auch beim DOIF Modul gibt es das.
Ist das attribut gesetzt funktioniert auch state:.*
Ok, das ist gut zu wissen.
ZitatDie zweitbeste Variante ist manchmal
...
Nö. Sie ist ...immer nicht so gut und eben weniger performant... Also beschwer dich nicht, wenn du irgendwann wegen solcher Mogeleien Probleme bekommst...
Wie gesagt, du hast mit keiner Zeile geschrieben das der Vorschlag schlecht oder falsch ist !
Und jetzt sprichst du von "Mogeleien" ?
Warum hast du denn nicht einfach dazu gesagt: Achtung! Was der da geschrieben hat ist bullshit, wenn du das machst stürzt FHEM ab und wir haben Klimawandel !
Du hast geschrieben, Zitat:
...oder vielleicht lieber
DEF .....
...?
Das (on|off) sah nun mal einfacher aus als das andere. Und da kann ich eben auch mal (open|closed) draus machen ohne jetzt mit diesen "Platzhalter" zu arbeiten.
Ich weiß gar nicht warum du mich jetzt so angehst
Ok...vielleicht bist du gerade genervt, wovon auch immer. Kommt vor, dafür kann ich aber nichts. :-*
Wünsche dir trotzdem einen schönen Abend ! :)
...und jetzt bin ich raus
Versuche auch raus zu finden in wie weit das besser sein soll. Jörg Dein Reges matcht auf on of aber auch auf ok oder o2 aber nicht auf off. Zumindest laut regex101 Webseite. Übersehe ich was? Ich muss das mal am PC testen und nicht am Tablet
Das Stichwort ist NOTIFYDEF. Den Unterschied sieht man aber nur, wenn wirklich ein Device vorhanden ist, das paßt, sonst nicht.
Und die Regex ist "o" gefolgt von entweder beliebig vielen "f" oder "n". Wie du auf "ok" kommst, ist mir nicht klar.
Siehe auch (Kurzfassung): https://forum.fhem.de/index.php/topic,116701.0.html, und (Langform) Grundsätzliche Codingfragen / Performance: https://forum.fhem.de/index.php/topic,117075.0.html
Habe das bei regex101 getestet, aber mein altes Tablet hat da einen Streich gespielt und nicht korrekt angezeigt. Ich schaue mir die Threads gerne an.
Dann mal viel Spaß beim Stöbern.
Der "ausführliche" Thread ist btw. der Anlaß, warum ich so nachdrücklich hinter diesen vermeintlichen "Kleinigkeiten" her bin wie unsaubere Trigger bei allen möglichen Event-Handlern und fehlenden trigger-Angaben bei userReadings.
Wie man in diesem "Performance"-Thread erkennen kann, gibt viel Kleinzeug am Ende halt ein komplett unperformantes System (OT: ich glaube nicht, dass andere Lösungen die zugrundeliegenden Themen besser lösen, sondern ggf. nur besser verstecken).
Von daher:
Zitat von: Loctite am 17 Dezember 2021, 21:03:52
Wie gesagt, du hast mit keiner Zeile geschrieben das der Vorschlag schlecht oder falsch ist !
Und jetzt sprichst du von "Mogeleien" ?
Warum hast du denn nicht einfach dazu gesagt: Achtung! Was der da geschrieben hat ist bullshit, wenn du das machst stürzt FHEM ab und wir haben Klimawandel !
[...]
Ok...vielleicht bist du gerade genervt, wovon auch immer. Kommt vor, dafür kann ich aber nichts. :-*
Zwei Dinge nerven mich tatsächlich:
a) dass allgemein (auch in Entwicklerkreisen) diese Themen eher weniger bekannt sind
b) dass User wie du nicht "freundliche Schubser" ernster nehmen und gleich irritiert sind, wenn man nicht gleich "bullshit" ruft. Das wäre nämlich sachlich falsch, auch die "unsaubere Fassung" funktionier ja.
Daher "lieber"...
Ansonsten hätte ich mir ja die Mühe sparen können, überhaupt was zu schreiben ;) .
Schönes entspanntes WE allen,
Beta-User
Zitat von: Beta-User am 18 Dezember 2021, 09:01:47
Dann mal viel Spaß beim Stöbern.
Der "ausführliche" Thread ist btw. der Anlaß, warum ich so nachdrücklich hinter diesen vermeintlichen "Kleinigkeiten" her bin wie unsaubere Trigger bei allen möglichen Event-Handlern und fehlenden trigger-Angaben bei userReadings.
Wie man in diesem "Performance"-Thread erkennen kann, gibt viel Kleinzeug am Ende halt ein komplett unperformantes System (OT: ich glaube nicht, dass andere Lösungen die zugrundeliegenden Themen besser lösen, sondern ggf. nur besser verstecken).
Von daher:Zwei Dinge nerven mich tatsächlich:
a) dass allgemein (auch in Entwicklerkreisen) diese Themen eher weniger bekannt sind
b) dass User wie du nicht "freundliche Schubser" ernster nehmen und gleich irritiert sind, wenn man nicht gleich "bullshit" ruft. Das wäre nämlich sachlich falsch, auch die "unsaubere Fassung" funktionier ja.
Daher "lieber"...
Ansonsten hätte ich mir ja die Mühe sparen können, überhaupt was zu schreiben ;) .
Schönes entspanntes WE allen,
Beta-User
In der Tat ist dieses Thema zu ganze an mir vorbei gegangen. Liegt wohl daran das dies eine allgemeine Eigenart von FHEM ist.
Ich bin aber nun gerade dabei dies auf zu arbeiten. Werden wohl noch Fragen aufkommen mein lieber Jörg. Ich melde mich ;D
Zitat von: CoolTux am 18 Dezember 2021, 09:05:39
In der Tat ist dieses Thema zu ganze an mir vorbei gegangen. Liegt wohl daran das dies eine allgemeine Eigenart von FHEM ist.
Ich bin aber nun gerade dabei dies auf zu arbeiten. Werden wohl noch Fragen aufkommen mein lieber Jörg. Ich melde mich ;D
Gerne.
Bei der Gelegenheit noch ein mysteriöser Hinweis auf eine weitere "Kammer der Mysterien" - das "Reihenfolgeproblem" bei mehreren voneinander abhängigen Eventhandlern. Startpunkt wäre hier: https://forum.fhem.de/index.php/topic,124813.0.html
Und da ist er schon.
Nur damit ich das mal verstehe. Die Aussagen im ersten von Dir verlinkten Thread das der Parser nur dieses und jenes aber nicht solches versteht führt mich zu der Annahme das ich einen erheblichen Mehraufwand beim erstellen von Notifys (RegEx) habe. Aber das kann man sich ja dann mal anschauen.
Nun erstmal ein einfaches Beispiel.
Wenn ich das richtig verstanden habe listet mir ein:
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEFalle Notifys auf welche eine nicht optimale RegEx besitzen, korrekt?
Ein
r(r|g)_\w+:location:.Haustuerist also dabei. Wenn ich nun Deinem Beispiel von oben folge sollte ein
r[rg]_\w+:location:.Haustuerbesser sein.
Dennoch wird nach einem
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEFwieder dieses Notify gelistet. Scheint also noch nicht korrekt zu sein. Interessant wird es für mich bei so einem Beispiel.
Fensterkontakt.*(_F[1-4]|Dachfenster):(open|closed)oder
HandyMarko:batteryPercent:.(100|9[0-9])Auf was genau kann ich meine RegEx strecken bei einer Aussage wie
ZitatDer Parser versteht nur sowas wie dev1 oder dev1:event1 oder dev1:event1|dev2:event2. Folgendes kapiert er nicht: dev:(event1|event2), und sowas wie dev.*event schon gar nicht. Nicht exisitierende dev's oder "Teilprobleme" fuehren auch zu einem "unoptimierten" Regex.
Zitatdev1:event1 oder dev1:event1|dev2:event2
kann kaum Zielführend sein. Dann kann ich gleich alle events einzeln aufzählen.
r[rg]_\w+:location:.HaustuerDas hier scheint zu mindestens laut regex101 zu matchen
Ja das mit dem "Reihenfolgeproblem" bei mehreren voneinander abhängigen Eventhandlern hatte ich mitgelesen. Anstrengend ::)
Nur mal so am Rande. Das ganze Notify RegEx Dingens schreit förmlich nach einem Webinar ;D
Generell: Rudi hatte mich wegen meiner "tiefergelegten regexe" auch mal auf's Glatteis geführt. Da habe ich gelernt: der interne Parser ist deutlich was anderes wie normale regex...
Du solltest dich in Martins Thread im Developer-Bereich einklinken ;) .
Auf die Schnelle erst mal:
\w+ kann man sich sparen, weil Devicenamen nie Leerzeichen enthalten => .* oder .+;
Immer, wenn runde Klammern und Pipes zusammenkommen, ist das "tödlich" => Bandwurm (ja, meine <trigger> sehen zwischenzeitlich wirklich so aus...).
Das ist alles nicht sonderlich schön, lustig oder intuitiv. Daher: Martins Thread...
Meinst Du mit Martins Thread den 2. von Dir verlinkten weiter oben?
Nein, den "Attribute für notify+at"-Thread
Zitat von: Beta-User am 18 Dezember 2021, 10:12:26
Nein, den "Attribute für notify+at"-Thread
Ah den. Ja den habe ich etwas mitgelesen. Danke Dir.
Bin gerade echt geplättet
rr_.*:location:.Haustuer|rg_.*:location:.Haustuer
Schön das dieses hier akzeptiert wird verliert aber jegliche Flexibilität.
Gerade bei meinen virtuellen Fensterkontakten reichte es einfach einen neuen anzulegen und mehr musste ich nicht machen. Wenn ich nach dieser Methode hier gehen würde müsste ich jedesmal das Notify erweitern. Sorry aber das ist doch "krank". Es muss besser gehen :'(
Aus einem einfachen
Fensterkontakt.*(_F[1-4]|Dachfenster):(open|closed)
muss ein
Fensterkontakt.*:open|Fensterkontakt.*:closed
Und das wäre unglaublich ungenau. Ausserdem kann man nach ansetzen einer RegEx anscheinend keinen weiteren RegEx Teil mehr einsetzen
{notifyRegexpCheck('Fensterkontakt.+')}
Fensterkontakt.+: devspec FensterkontaktBadezimmer_F1,FensterkontaktDachfenster,FensterkontaktSteven_F1,FensterkontaktSteven_F2 (OK)
{notifyRegexpCheck('Fensterkontakt.+zimm.*')}
Fensterkontakt.+zimm.*: no match (ignored)
Sorry aber das absolut inakzeptabel.
ihr verrennt euch glaube ich gerade etwas.
notifyRegexpCheck ist nicht dazu da die regex wirkich zu prüfen. das wäre garnicht möglich ohne sie wirklich auszuführen.
es ist dazu da eine version zu finden die man schneller prüfen kann um möglichst viele falsche matches zu erkennen und die eigentliche regex in der device NotifyFn so selten wie möglich auszuführen. aber ohne das aus versehen ein richtiger match übersehen wird.
es geht hier darum einfach fälle zu erkennen ohne die echte regex bemühen zu müssen. deshalb ist es hier völlig ok wenn ein event durchgelassen wird das eigentlich nicht matched. so lange es nicht zu oft passiert. das wird dann später in der echten regex prüfung abgefangen. umgekehrt wäre es aber ein problem.
wenn man notifyRegexpCheck genauer machen würde (was beliebig kompliziert werden kann) wäre es auch langsamer und somit sinnlos da man dann auch gleich die richtige regex prüfen könnte.
das bedeutet umgekehrt auch das man sich bei der eingabe für notifyRegexpCheck nicht verkünsteln sollte um die aufgabe nicht noch schwerer zu machen als sie schon ist.
Es wird immer schlimmer
(AnniKraussStr|r(r|g)_.*):(home|absent|gone)
Wird zu
AnniKraussStr:home|AnniKraussStr:absent|AnniKraussStr:gone|rr_.+:home|rr_.+:absent|rr_.+:gone|rg_.+:home|rg_.+:absent|rg_.+:gone
Von dem ganzen mal ob. @Andre Ich glaube ich stehe gerade alleine da mit dem verrennen.
Also was ich verstehe, es macht Sinn die RegEx so zu wählen das NOTIFYDEV funktion hat. Also lediglich auf die tatsächlich gemeinten Devices die NotifyFn aufzurufen. Aber alles andere kann doch meiner Meinung nach Flexibel bleiben.
So kann ich meiner Meinung nach aus
AnniKraussStr:home|AnniKraussStr:absent|AnniKraussStr:gone|rr_.+:home|rr_.+:absent|rr_.+:gone|rg_.+:home|rg_.+:absent|rg_.+:gone
Doch noch ein
AnniKraussStr:(home|absent|gone)|rr_.+:(home|absent|gone)
machen können. So das vernünftig die Devices erkannt werden. Aber das funktioniert leider nicht.
Na ja.
Ausgangspunkt war: Einfacher Eventhandler, nicht optimierter <trigger>.
Sollte man ab einem bestimmten Level "ja klar" rufen, wenn da der Vorschlag zur Optimierung kommt.
Es ist aber auch "nur" eine Option, wie man Dinge optimieren kann.
Bei deinen "Kopfzerbrechern" ist es vielleicht so, dass eine "if"-Abfrage nach dem Event und direktes Rausspringen effizient wäre, wenn es "das falsche" ist.
Bei anderen "Sammel-Regexen" ist es besser, einen "Global-Handler" ohne NOTIFYDEV zu haben wie viele kleine (nicht optimierte) Event-Handler.
Kurz: Man muss es im Einzelfall entscheiden, welcher Weg der passende ist, und (v.a.) man sollte alle Wege kennen.
That's all...
(Ansonsten wäre es besser, grundlegende Design-Fragen im Developer-Bereich zu diskutieren, auch wenn das Niveau da so hoch ist, dass ich auch den Eindruck habe, nicht qualifiziert genug zu sein, um da was substantielles beizutragen).