[gelöst] Dummy Loggen

[Beta-User]

Hab ich das falsch verstanden

Ja, vermutlich Wunschlesemodus...

addStateEvent wirkt sich NUR auf das aus, was der Eventhandler sieht, bei dem das Attribut gesetzt ist, nicht auf den Event-Monitor. Deswegen schreibt Rudi ja, dass man das Attribut am jeweiligen (!) Eventhandler setzen muss, wenn man DORT (ausnahmsweise (!)) state-Events haben will.

[MadMax-FHEM]

ALSO: WIR helfen in unserer FREIZEIT! so gut WIR können (und wollen)! Soviel dazu. WIR entscheiden was UNS nicht gefällt und ebenso WEM wir dann noch WIE helfen (wollen)...

Da DU ja was (Hilfe) willst ist es einfach nur "höflich" sich dem, der Hilfe gibt/geben will naja entsprechend... Nicht mehr und nicht weniger...

EDIT: und NICHT wieder "falsch" verstehen. Damit ist NICHT "bückeln und kriechen" gemeint...

-----------------------------

Das Attribut wirkt nur dort wo es gesetzt ist.
Da es beim "auswertenden" Device (in dem Fall FileLog) gesetzt ist, wirkt es nur dort... Und nicht beim "feuernden" Device (was eben im EventMonitor angezeigt wird)...


Dann können wir gerne weiter diskutieren warum ICH denke, dass meine RegEx sehr wohl "filtert" und DU "dagegenhalten", dass (angeblich) nicht...

Hast du es jemals ausprobiert!!?

Weil: meine RegEx dafür sorgt, dass nach dem DeviceNamen (VOR dem Doppelpunkt) NUR Zahlen kommen dürfen... Wenn also IRGENDEIN Readingname danach käme würde die RegEx NICHT greifen, ergo auch NICHT geloggt...

Bevor du einfach nur "rumschimpfst" (siehe Eingang), erst mal (genau) (ein)lesen und auch mal u.U. sich die Mühe machen es einfach zu testen. Punkt.

EDIT: wenn die RegEx so wäre, hättest du Recht ".*\d+"...

Gruß, Joachim

[Superposchi]

Also aktuell stelle ich den Dummy manuell um um es zu testen, heißt also dass ich theoretisch das Attribut dort stellen müsste.
Theoretisch deshalb, weil mir dies bei einem Dummy nicht als Möglichkeit gezeigt wird.
Bedeutet also im Umkehrschluss, dass wenn ein DOIF, notify oder was auch immer der Auslöser ist und in diesem das Attribut gesetzt ist, würde im Event Monitor das "state: " angezeigt. Ist das jetzt so richtig verstanden?

Egal ob Freizeit oder nicht, wer mit der Wahrheit ein Problem hat, hat selbst ein Problem im Umgang in einem Forum.
Anderen Vorhaltungen zu machen bringt dabei rein gar nichts. Vielleicht sollte man sich dann lieber mal selber an die Nase fassen.
Wenn hier die Spezialisten nicht mit eindeutigen, klaren Kommentaren die die Wahrheit wiedergeben nicht zurecht kommen, ist das deren Problem.
Mehr sage ich zu diesem Thema nicht mehr.

[Beta-User]

Ist das jetzt so richtig verstanden?

Wie klar soll es denn noch sein?

Nein. Das Attribut hat nur da Auswirkungen, wo es gesetzt werden kann. Eben hier bei der FileLog-Instanz. Fertig. Alles andere bekommt von dem dummy keine stateEvents, es sei denn, die betreffende Instanz (DOIF, whatever) würde dies explizit bei fhem.pl "bestellen" (durch ein dort jeweils gesetztes Attribut!).

Und diese ggf. als nervtötend empfundenen Hinweise, dass man bitte die Doku genau (!) liest, und ggf. die Module einsetzt, die für spezielle Dinge gedacht sind, sind nicht böse gemeint. Es ist nur so, dass die Erfahrung eben lehrt, dass alle die, die meinen, das Rad irgendwie neu erfinden zu müssen, damit früher oder später nicht weiterkommen.
Kannst du glauben oder auch nicht.

Daher würde ich auch davon Abstand nehmen, unbedingt das state-Event generieren zu wollen, sondern lieber den Blick auf "ignoreRegexp" lenken, um damit die oldreadings-Events nicht zu loggen. Wie es geht, steht in der commandref (zumindest passt bei mir der Link, der dazu in help FileLog erscheint).

[MadMax-FHEM]

Anderen Vorhaltungen zu machen bringt dabei rein gar nichts. Vielleicht sollte man sich dann lieber mal selber an die Nase fassen.

Keiner macht "Vorhaltungen"...

Und ja ich werde mich (hoffentlich) zukünftig an meiner Nase packen: ich werde einfach nicht mehr antworten...

Und wie wäre es denn mal das "Wunschlesen" abzuschalten und einfach zu lesen was geschrieben wird...

Ja beim dummy gibt es das Attribut nicht -> auslösendes Device...

Beim notify, FileLog, DOIF, ... gibt es das -> reagierendes Device

Und nirgendwo steht, dass es im Eventmonitor auftaucht/auftauchen muss...

Gruß und fertig, Joachim

[Superposchi]

Also mal grundsätzlich an beide von euch. Das Problem ist nicht, dass ich irgendein Wunschlesen anwende, sondern daran, dass ich das was ich in der CommandRef und hier im Forum lese oft nicht in Einklang bringe. Ich habe einfach ein grundsätzlich anderes Verständnis/Logik.
Beispiel wenn du von FileLog-Instanz sprichst, bedeutet das für mich, dass das Attribut im FileLog angewendet werden soll.
Für mich wäre es verständlicher wenn direkt geschrieben wäre, das es nicht im FileLog-Device angewendet werden muss, sondern im Auslöser-Event.
Diese Info kam jetzt erst im letzten Post, nach 5 maligen hin- und herschreiben.

Ich will keinem etwas, aber ich komme mit eurer Umgangsart/Ausdrucksweise einfach nicht klar weil sie für mich allem wiederspricht was ich bisher gelernt habe. Deshalb auch immer mal wieder meine Hinweise, dass es vielleicht weniger an mir liegt als an euch, da hier im Forum eine ganz spezielle Art herrscht mit der nicht jeder klar kommt.

Habe es jetzt gelöst indem im entsprechenden DOIF das Attribut angewendet habe und das Regex entsprechend um ein cmd ergänzt. Problem ist also gelöst und ich hoffe, dass wir eine einer Diskussion über das Benehmen mal drum herum kommen.

Ich kann genauso wenig alles was ich in 40 Jahren gelernt habe über Board werfen wie ihr euer angelerntes Forumsinternes Benehmen. So ist es eben manch mal einfach. Mein Tipp wäre, schaut einfach mal außerhalb in anderen Foren (mit völlig anderen Themen) und schaut euch AUCH mal den Umgang und die Gepflogenheiten (z.b. das Adressieren in Posts) dort an. Vielleicht versteht mich der ein oder andere dann etwas besser. Das heißt ja nicht das ihr eure Gepflogenheiten über Board werfen sollt. Jedes Forum hat seine persönlichen Gepflogenheiten und man sollte sich als User anpassen soweit es geht, aber hier sind die Regeln schon sehr speziell und abweichend. Das müsst ihr schon zugeben, oder?

[Beta-User]

Beispiel wenn du von FileLog-Instanz sprichst, bedeutet das für mich, dass das Attribut im FileLog angewendet werden soll.
Für mich wäre es verständlicher wenn direkt geschrieben wäre, das es nicht im FileLog-Device angewendet werden muss, sondern im Auslöser-Event.
Diese Info kam jetzt erst im letzten Post, nach 5 maligen hin- und herschreiben.

NEIN! Immer noch falsch verstanden. Das Attribut modifiziert aber das, was die betreffende Instanz als Event von den Geräten, die es "abboniert hat" "sieht", NICHT das Ausgangs-Device.

Und ein FHEM-Device = eine Instanz eines Moduls, also (abgesehen von temproären at) alles, was mit define in der cfg landet:

Code Auswählen Erweitern

define FileLog_Homestatus_Marko FileLog ./log/Homestatus_Marko-%Y.log Homestatus_Marko:.*
attr FileLog_Homestatus_Marko addStateEvent 1

Du kannst sogar dasselbe Ausgangs-Device nochmal loggen:

Code Auswählen Erweitern

define FileLog_Homestatus_Marko2 FileLog ./log/Homestatus_Marko2-%Y.log Homestatus_Marko:.*Beide Instanzen werden parallel laufen, aber ein unterschiedliches Log schreiben, weil sie unterschiedliche Dinge zu sehen bekommen...

Ansonsten noch viel Spaß mit deinem "spezialisierten" FHEM...
(Es wird hier vermutlich erst mal übersehen werden, wenn du so spezielle Dinge wie addStateEvent an vielen Stellen einsetzt).

[amenomade]

Vielleicht hilft ein Bild?

[Superposchi]

Also irgendwie ist unsere Begriffswelt zu weit auseinander.

Um etwas im state-Reading zu loggen muss ich das als Regex mit angeben wenn ich nur dieses eine Reading loggen will, richtig?
Also muss ich es so biegen, dass im Event Monitor ein "state" vor das Event gesetzt wird, richtig?
Dazu muss im Auslöse-Device (also DOIF, notify etc.) das Attribut für dieses Device gesetzt werden, richtig?

Keine Ahnung ob ein Bild da alleine aussagekräftig genug ist, aber eine gute Idee.

[Beta-User]

Also muss ich es so biegen, dass im Event Monitor ein "state" vor das Event gesetzt wird, richtig?

NEIN!

Der Event-Monitor ist ein GENERELLES Hilfsmittel, es zeigt die Events so an, wie die "abonnierten" Geräte das normalerweise erwarten und nimmt auf "verbogene" keine Rücksicht.

Du verbiegst das jeweils nur für ein Zieldevice, und dann muss die regex eben so sein, wie das Zieldevice das _modifizierte_ Event erhält.

KURZ: Das (addStateEvent) ist eine SPEZIALFUNKTION (die hier auch die meisten nicht kennen!) und du als Anfänger solltest die Finger davon lassen, weil du die Hintergründe dazu nicht durchschaust. DEUTLICH genug?
Wenn du das andere Reading NICHT loggen willst, nimmst du "ignoreRegexp" und setzt das passend. Auch klar genug ausgedrückt?

EDIT: @amenomade: Schöne Visualisierung übrigens .

[MadMax-FHEM]

EDIT: @amenomade: Schöne Visualisierung übrigens .

Daumen hoch!

Und zeigt doch genau wie es ist...
...und auch was NICHT ist...

Gruß, Joachim

[amenomade]

Keine Ahnung ob ein Bild da alleine aussagekräftig genug ist, aber eine gute Idee.

Na gut. Wenn ich richtig verstanden habe, hätte ich mir die Mühe sparen können. Hast Du es mindestens angeschaut? Anscheinend nicht, weil:

Also muss ich es so biegen, dass im Event Monitor ein "state" vor das Event gesetzt wird, richtig?

Ich habe geschrieben: das echte Event ist immer nur « 1 »

Was ist da in deiner Begriffswelt nicht verständlich? "Das Event ist immer « 1 »" heisst: so ist es. Immer. Kann man nicht umbiegen. Das Event bleibt immer so wie es ist. Musst Du es biegen? NEIN. Kannst Du nicht. Immer heisst immer. Der Eventmonitor sammelt die Events so wie sie sind.

Was man umbiegen kann, ist wie die Zieldevices dieses immer gleich bleibende Event "sehen". Das Attribut addStateEvent eines Zieldevices setzt so zu sagen einen Übersetzungsfilter auf dem Eingang dieses Zieldevices.

Aber ich gebe Beta-User zu: lass lieber die Finger weg von addStateEvent.

[Beta-User]

Zu der Visualisierung noch. Dachte, sowas könnte man ins Wiki einbauen. Aber da liefert die Suche genau 3 (!) Treffer zu addStateEvent, was zeigt, dass es bisher wohl keinen Klärungsbedarf zu dem Thema gab (und eines scheint ein Versehen zu sein)...

@amenomade: Über die Frage, was "echtes Event" ist, kann man vermutlich unter den Experten eine längere Diskusion führen, ich neige vorläufig zu der Auffassung, dass eigentlich das im Event-Monitor angezeigte Event "verbogen" ist. Es ist aber in der kurzen Variante die übliche Konvention, und den Rest kann man sich dann über Code-Analyse und die Darstellung in https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify erschließen, wenn man unbedingt mag...
Ändert aber nichts daran, dass man als Einsteiger nicht gleich "alles anders" machen sollte; Rudi hätte schon einen "Startschuss" gesetzt, wenn er Pläne hätte, das Verhalten in der näheren Zukunft (2-4 Jahre) zu ändern .

[Superposchi]

Hallo amenomade, das Bild ist übersichtlich und ich hatte es mir flüchtig angesehen. Flüchtig weil ich erst den Text beantworten wollte.
Jetzt habe ich es gerade noch mal genau angeschaut, dabei ist mir auch der anscheinend vorhandene Denkfehler aufgefallen, der vielleicht das Problem ist.

Der Dummy Homestatus_Marko ist nicht der Auslöser, sondern das Ziel-Device.
Ich habe verschiedene Auslöser wie zum Beispiel ein Presence-Device oder ein DOIF-Device, dass je nach dem wie verschiedene geben und so Eigenschaften gefüllt sind dem Dummy einen bestimmten Wert (1-4) und so einen gewissen Status (Anwesend, Schlafend, Abwesend, Urlaub) symbolisieren. Das ganze für zwei Personen. Zusätzlich noch ein Structure um diese beiden Personen in einem Device zu überwachen, also wenn beide den gleichen Status haben.
Ausgehend von diesen Stati werden andere Aktionen ausgelöst, wie zb unser Saugroboter.

Da es aber immer wieder zu unerklärlichen Fehlauslösern kommt (heute Nacht ging der Saugroboter um 4 Uhr früh los) will ich gerne die Dummys mit den Stati loggen um sie nachträglich auswerten zu können.

Was man umbiegen kann, ist wie die Zieldevices dieses immer gleich bleibende Event "sehen". Das Attribut addStateEvent eines Zieldevices setzt so zu sagen einen Übersetzungsfilter auf dem Eingang dieses Zieldevices.

Und genau das meine ich mit verbiegen. Verbiegen im Sinne von absichtlicher Veränderung vom Originalzustand, in dem Fall das "state" künstlich ins Event einfügen.

Ich lasse ja auch die Finger davon, hab ja wie bereits geschrieben schon eine Lösung erarbeitet. Wollte es nur verstehen weil ich halt lernen will.
Sonst wird einem ja immer gleich Unwillen und Faulheit vorgeworfen.

[frank]

in der regel ist es am einfachsten und sichersten immer "normale" readings zu nutzen.