Hallo, ich möchte gerne einen Dummy zur Kontrolle in eine Logdatei schreiben lassen, bekomme es aber einfach nicht hin.
Ich habe gesehen, dass es dazu bereits einige Threads gibt, doch leider brachte keiner eine direkte Lösung für mich.
Ich habe ein FileLog-Device mit folgendem Befehl erstellt:
define FileLog_Homestatus_Marko FileLog ./log/Homestatus_Marko-%Y.log Homestatus_Marko:state\.*
Die Datei wurde auch angelegt, es wird nur leider nichts hineingeschrieben. Es soll einfach der Status des Device aufgezeichnet werden.
Wo liegt der Fehler?
Zitat
Wo liegt der Fehler?
Vermutlich im Regex.
Wie hast du das FileLog erstellt?
Was soll denn '\.*' ?
Warum nicht einfach per Eventmonitor anlegen lassen?
https://wiki.fhem.de/wiki/Event_monitor
Gruß, Joachim
Schau in den Eventmonitor: state ist normalerweise nicht Bestandteil des Events! Das Reading state bildet da eine Ausnahme.
Einfach dies als regEx liefert nicht das gewünschte Ergebnis?
Homestatus_Marko
Gruß Otto
Danke, das war die Lösung.
Noch eine Nachfrage dazu:
Der Dummy hat ein zusätzliches Reading (über ReadingsOld) um den vorherigen Statuszustand aufzuzeichnen, der wird jetzt natürlich mitgeloggt.
Wenn "state" zur Eingrenzung des Readings nicht funktioniert, wie kann ich dann die Readings eingrenzen?
Mal mit dem Attribut 'addStateEvent' beim FileLog-Device probieren.
Und schon mal den Tipp mit dem Eventmonitor angesehen?
Gruß, Joachim
Ja den Tipp habe ich gesehen, doch weiß ich nicht was er mir bringen soll.
Im Eventmonitor wird lediglich folgendes gelistet:
2020-12-29 09:58:32.721 dummy Homestatus_Marko 3
2020-12-29 09:58:32.721 dummy Homestatus_Marko state_old: 1
Wie soll mir das hierbei weiterhelfen?
addstateEvent muss ich mir mal genauer ansehen, hatte es nur überflogen als ich das Device erstellt habe.
P.S. bezieht sich das addstateEvent nicht rein auf DOIF?
Nein.
Gibt es bei notify, FileLog, ...
Oder wird dir das nicht "angeboten"?
Und wie geschrieben: es stimmt halt die RegEx nicht ;)
Und der Tip: naja lass dir halt mal ein FileLog anlegen mit EXAKT dem markierten "Suchmuster".
Und: halt für die "Zukunft"... ;)
define FileLog_Homestatus_Marko FileLog ./log/Homestatus_Marko-%Y.log Homestatus_Marko:3
Kommen dort nur Zahlen?
Immer Einstellig?
Je nachdem halt die RegEx anpassen
define FileLog_Homestatus_Marko FileLog ./log/Homestatus_Marko-%Y.log Homestatus_Marko:\d
Oder
define FileLog_Homestatus_Marko FileLog ./log/Homestatus_Marko-%Y.log Homestatus_Marko:\d+
Regex-Test: https://regex101.com/
Gruß, Joachim
Ja, es sind immer Zahlen zwischen 1 und 4 für verschiedene Stati die dargestellt werden können.
Aber das ist doch nicht das Problem, es sollen ja alle verschiedenen Zustände geloggt werden.
Meine Nachfrage bezog sich ja auf das ausblenden des anderen Readings für den alten Zustand.
Das Problem ist ja, dass ich beim Regex nicht "state" mit einbauen kann um den Filter einzugrenzen, nicht der Wert den das Device annimmt.
Wenn Rudi "addStateEvent" in die Doku zu FileLog einbaut, darfst du davon ausgehen, dass das kein Zufall ist. Von daher kannst du natürlich weiter rumexperimentieren und rumlamentieren, oder eben die Doku zu Rate ziehen: https://fhem.de/commandref_modular_DE.html#FileLog (https://fhem.de/commandref_modular_DE.html#FileLog)
EDIT: leider ist der Link kaputt, weil sich DbLog den Anker schnappt. M.E. sollte er korrekterweise nach https://fhem.de/commandref_modular_DE.html#notify und die dortige Attributbeschreibung gehen (das kann nur der Modulautor von DbLog fixen).
(Nebenbei: Es ist immer noch "lustig", dass du Bewohner unbedingt mit dummy abbilden willst...).
Also ich wurde zu DOIF verlinkt und nicht zu FileLog, insofern ist meine Frage wohl berechtigt, da der Text dort sinngemäß aussagt:
"Wenn das Attribut gesetzt ist wird dem Reading state bei einem Event anders als sonst üblich ein state vorangestellt, so wie bei allen anderen Readings ebenfalls der Readingname vorangestellt wird. Somit kann mit einem DOIF explizit darauf reagiert werden."
Nebenbei: Es ist traurig, dass du immer noch meinst deine Art ist die einzig richtige Art. Lass es mich doch machen wie ich es für mich als richtig erachte.
Es funktioniert, was ich von deinem Vorschlag in meinem Speziellen Fall nicht sagen kann. Denn auch wenn du es nicht glaubst habe ich es ausprobiert und es war für meine Konstellation ein wahrer Alptraum, da die Informationen für den Status nicht aus einer Quelle/Auslöser stammen und so ein Szenario offensichtlich nicht vorgesehen ist.
Es mag seltsam sein, dass dein Browser einen anderen Anker ranzieht wie meiner, es ist aber so, dass dieses Attribut in allen ordentlich programmierten Eventhandlern dieselbe Wirkung hat: Es wird (auch) ein Event mit dem vorangestellten "state: " von fhem.pl an die NotifyFn des betreffenden Moduls übergeben; (beachte das Leerzeichen). (du hast da nur nur etwas unschön aus der Doku zitiert).
Von daher: Setze das Attribut bei dem FileLog, ergänze die Regex passend und alle sind glücklich.
Hier noch im O-Ton das, was Rudi (auch zu FileLog) zu sagen hat (aus der verlinkten cref zu notify):
Zitat
addStateEvent
Das mit dem state Reading verknüpfte Event ist speziell, da das dazugehörige Prefix "state: " entfernt wird, d.h. $EVENT ist nicht "state: on", sondern nur "on". In manchen Fällen ist es aber erwünscht das unmodifizierte Event zu bekommen, d.h. wo "state: " nicht entfernt ist. Für diese Fälle sollte addStateEvent auf 1 gesetzt werden, die Voreinstellung ist 0 (deaktiviert).
Achtung:
- dieses Attribut muss beim Empfänger (notify, FileLog, etc) gesetzt werden.
- dieses Attribut zeigt nur für solche Geräte-Events eine Wirkung, die readingFnAttributes (https://fhem.de/commandref_modular_DE.html#readingFnAttributes) unterstützen.
Zitat von: Superposchi am 29 Dezember 2020, 10:33:04
Ja, es sind immer Zahlen zwischen 1 und 4 für verschiedene Stati die dargestellt werden können.
Aber das ist doch nicht das Problem, es sollen ja alle verschiedenen Zustände geloggt werden.
Meine Nachfrage bezog sich ja auf das ausblenden des anderen Readings für den alten Zustand.
Das Problem ist ja, dass ich beim Regex nicht "state" mit einbauen kann um den Filter einzugrenzen, nicht der Wert den das Device annimmt.
Wenn nur Zahlen kommen, dann "blendet" meine RegEx sehr wohl das unerwünschte Reading aus...
(zumindest in meinen Tests)
EDIT: wenn nur Zahlen zwischen 1 und 4 kommen (können), dann geht die RegEx auch noch "genauer". Wo/wie du testen kannst hatte ich ja verlinkt...
Ansonsten eben (wurde ja "diskutiert"): addStateEvent und RegEx anpassen...
Und dafür, dass DU Hilfe willst/suchst bist du (nicht nur hier) sehr...
Gruß, Joachim
so, habe das Event im FileLog-Device gesetzt (auf 1 gestellt), leider macht das im Event Monitor keinen Unterschied. Dort wird weiterhin lediglich folgendes angezeigt:
2020-12-29 11:24:03.675 dummy Homestatus_Marko 3
2020-12-29 11:24:03.675 dummy Homestatus_Marko state_old: 1Also kein Zusatz von "state: "
Somit greift auch eine angepasste Regex nicht.
Nur am Rande, ich habe nichts zitiert, sondern sinngemäß (extra dazugeschrieben) wiedergegeben. Das ist ein riesen Unterschied.
Da das Event (1-4) bei beiden Readings auftritt, sehe ich nicht wo deine Regex ein Reading ausblenden soll. Deine Regex filtert doch lediglich das angezeigte Event, nicht das Reading.
Und ich sehe nicht was an der Wahrheit irgendwas sein soll. Ich rede/schreibe frei Schnauze und geradeaus. Keine Ahnung warum sich hier Leute davon immer wieder angegriffen fühlen.
P.S. Interessanterweise wird im Log das "state" angezeigt, siehe:
2020-12-29_11:34:18 Homestatus_Marko state: 1
2020-12-29_11:34:18 Homestatus_Marko state_old: 3
Hab ich das falsch verstanden oder sollte das Attribut das "state" nicht auch im anzeigen Event Monitor ?
ZitatHab 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.
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
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.
Zitat von: Superposchi am 29 Dezember 2020, 11:59:01
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).
Zitat
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
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?
Zitat von: Superposchi am 29 Dezember 2020, 12:37:56
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:
define FileLog_Homestatus_Marko FileLog ./log/Homestatus_Marko-%Y.log Homestatus_Marko:.*
attr FileLog_Homestatus_Marko addStateEvent 1Du kannst sogar dasselbe Ausgangs-Device nochmal loggen:
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).
Vielleicht hilft ein Bild?
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.
Zitat von: Superposchi am 29 Dezember 2020, 13:49:39
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 :) .
Zitat von: Beta-User am 29 Dezember 2020, 13:59:53
EDIT: @amenomade: Schöne Visualisierung übrigens :) .
Daumen hoch!
Und zeigt doch genau wie es ist...
...und auch was NICHT ist...
Gruß, Joachim
ZitatKeine 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:
ZitatAlso 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.
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 ;) .
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.
ZitatWas 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.
in der regel ist es am einfachsten und sichersten immer "normale" readings zu nutzen.
Abgesehen davon, dass ein Dummy keine Readings hat, wird hier schön wieder die Frage aufgeworfen was denn "normale" Readings sind.
Für mich persönlich ist das state-Reading das ursprünglichste überhaupt, da es die Grundlage für den Zustand des Gesamtdevice angibt. Das es ein besonderes Verhalten hat, muss man ja erst mal wissen.
Wer ist der Auslöser? Das Device, das ein Event erzeugt: PRESENCE, dummies, aber grundsätzlich alle Fhem-Devices erzeugen Events.
Wer ist der Empfänger? Das Device, das ein Event bekommt oder benutzt, oder worauf es reagiert. Auch hieroben "auswertendes" Device genannt.
Ein dummy erzeugt ein Event, dieses Event wird von einem FileLog Device empfangen und dieses FileLog Device schreibt was in der Log.
Jetzt verstehe ich richtig? Du hast einige dummies angelegt, um die echte Zieldevices testweise zu simulieren, z.B. um deinen Saugroboter zu simulieren, ohne dass der echte Saugroboter angeht? Und dann willst Do loggen, was der fake-Saugroboter gemacht hat (was der echte Saugroboter gemacht hätte)?
Dann musst Du es dir mehr-stufig darstellen:
- PRESENCE generiert ein event "present", er ist der Auslöser dieses Events. Dieses Event wird von einem DOIF abgefangen (da ist der DOIF das Zieldevice)
- DOIF macht in Abhängigkeit davon ein "set fake-Roboter 1". fake-Roboter generiert ein event "1", er ist des Auslöser dieses (anderen) Events. Dieses Event wird von einer FileLog abgefangen (da ist FileLog das Zieldevice), und es wird was in der Datei entspr. geschrieben
Auf einem dummy kann man beliebige Readings mit "setreading" setzen.
Was frank meinte ist: im Beispiel PRESENCE sollte man in einem DOIF oder notify eher das Event auf Reading "presence" als das auf "state" abfangen und auswerten (das PRESENCE Device generiert beide). Sprich: ich schreibe mein notify:
- define xx notify presencedevice:presence:.absent
lieber als
- define xx notify presencedevice:.absent
Auch ein dummy hat afaik immer ein "state"-Reading (sobald er irgendwie gesetzt wurde und nicht zusätzlich readingList etc. angelegt ist).
Nur ist eben gerade "das Problem", dass ein "Ding" in der Realität in der Regel nicht nur einen Zustand hat, sondern weitere "Eigenschaften", die wir eben Readings nennen. "Früher" scheint FHEM auch "einfacher" gestrickt gewesen zu sein, da gab es eben vorrangig "die eine Eigenschaft", zu finden in STATE. Das erklärt ggf. etwas die Schwierigkeiten, die viele User mit "state" und "STATE" haben, und oft in alten Dokumentationsteilen "Value()" verwendet ist (gleich wieder aus der Liste der bekannten Funktionen streichen und was eindeutiges dafür verwenden!).
Muss man eben wissen, dass das mit "state"/"STATE" eine spezielle Kiste ist.
Und mit "Für mich persönlich ist..." kommt man leider bei den "harten Fakten" nicht weiter. Das muss man einfach so nehmen wie es ist.
(nota bene: ich persönlich finde das auch nicht unbedingt gelungen und habe mir erst mal Schläge für die Aussage eingefangen, dass man Value() "abschaffen" sollte (gemeint war: aus dem Anfängerwortschatz zugunsten von exakteren Abfrage-Varianten verbannen).)
Und da wir grade bei Konventionen sind:
Du solltest wenigstens die Readings und deren Werte etc. in deinem dummy-structure-Konstrukt so benennen, dass sie mit RESIDENTS&Co kompatibel sind. Früher oder später wirst du das nämlich mit einiger Wahrscheinlichkeit haben wollen (weil es in weiten Teilen "usus" ist und daher vieles, z.B. bei Benachrichtigungen und Strukturierungen etc. vereinfachen kann)...
Auch wenn dies hier eigentlich nicht gewünscht wird adressiere ich mein Posting jetzt mal.
@amenomade
Ich weiß nicht wie und woher du deine Aussage nimmst oder auf die Idee von diesem Fake-Saugroboter kommst.
Also noch mal langsam und in Ruhe:
Ich habe für jeden Bewohner ein Presence-Device, dass abhängig der WLan-Erkennung vom zugeordneten Handy-Device an der Fritzbox geschaltet wird.
Dazu habe ich ein DOIF, welches über die Readings verschiedener Devices ein Userreading im Handy-Device der jeweiligen Person setzt.
Weiter kommt pro Bewohner ein DOIF, dass abhängig der Readings/Userreadings die genannt wurden ein Dummy-Device (Homestatus_xxx pro person) auf 1-3 setzt (4, also Urlaub, geht aktuell nur manuell). Zur besseren Übersicht kommen dazu noch zwei structure-devices, die einmal absolut, also wenn beide den gleichen Status haben, und einmal relativ, also wenn irgendein Bewohner zu Hause ist, den Status anzeigen.
Abhängig der personengebundenen und der personenunabhängigen Dummys/Structures werden dann andere Aktionen ausgelöst wie z.B. das der Saugroboter 30 Minuten nach absoluter Abwesenheit (also wenn beide abwesend sind) gestartet wird.
Diese Aktionen haben aber immer wieder mal "Fehlstarts", daher möchte ich die Dummys/structures jetzt gerne mal mitloggen um im nachhinein sehen zu können welchen Status die jeweiligen Devices zum Auslösezeitpunkt hatten.
@Beta-User
Grundsätzlich hat jedes Device ein state-Reading soweit mir bekannt ist. Es wird aber nur angezeigt wenn andere Readings vorhanden sind.
Anders als deine Ausführung kann ein Ding (Device) nur einen EINZIGEN Zustand haben. Jeder Zustandswechsel überschreibt das jeweilige Reading.
Für mich persönlich bedeutet, dass es keine Standardlösungen gibt. Jeder hat andere Voraussetzungen und Gegebenheiten, die auf die persönlichen Umstände angepasst werden müssen. Man muss es nehmen wie es ist funktioniert eben genau nicht, da es keine Universallösung gibt die bei allen Usern passt.
Was deinen letzten Absatz angeht werde ich mir das mal durch den Kopf gehen lassen. Ich muss eben schauen wie das am einfachsten bzw. ob überhaupt auf meine Situation umsetzbar ist.
Zitat von: Superposchi am 29 Dezember 2020, 19:26:34
Auch wenn dies hier eigentlich nicht gewünscht wird adressiere ich mein Posting jetzt mal.
@amenomade
Ich weiß nicht wie und woher du deine Aussage nimmst oder auf die Idee von diesem Fake-Saugroboter kommst.
Also noch mal langsam und in Ruhe:
Ich habe für jeden Bewohner ein Presence-Device, dass abhängig der WLan-Erkennung vom zugeordneten Handy-Device an der Fritzbox geschaltet wird.
Dazu habe ich ein DOIF, welches über die Readings verschiedener Devices ein Userreading im Handy-Device der jeweiligen Person setzt.
Weiter kommt pro Bewohner ein DOIF, dass abhängig der Readings/Userreadings die genannt wurden ein Dummy-Device (Homestatus_xxx pro person) auf 1-3 setzt (4, also Urlaub, geht aktuell nur manuell). Zur besseren Übersicht kommen dazu noch zwei structure-devices, die einmal absolut, also wenn beide den gleichen Status haben, und einmal relativ, also wenn irgendein Bewohner zu Hause ist, den Status anzeigen.
Abhängig der personengebundenen und der personenunabhängigen Dummys/Structures werden dann andere Aktionen ausgelöst wie z.B. das der Saugroboter 30 Minuten nach absoluter Abwesenheit (also wenn beide abwesend sind) gestartet wird.
Diese Aktionen haben aber immer wieder mal "Fehlstarts", daher möchte ich die Dummys/structures jetzt gerne mal mitloggen um im nachhinein sehen zu können welchen Status die jeweiligen Devices zum Auslösezeitpunkt hatten.
@Beta-User
Grundsätzlich hat jedes Device ein state-Reading soweit mir bekannt ist. Es wird aber nur angezeigt wenn andere Readings vorhanden sind.
Anders als deine Ausführung kann ein Ding (Device) nur einen EINZIGEN Zustand haben. Jeder Zustandswechsel überschreibt das jeweilige Reading.
Für mich persönlich bedeutet, dass es keine Standardlösungen gibt. Jeder hat andere Voraussetzungen und Gegebenheiten, die auf die persönlichen Umstände angepasst werden müssen. Man muss es nehmen wie es ist funktioniert eben genau nicht, da es keine Universallösung gibt die bei allen Usern passt.
Was deinen letzten Absatz angeht werde ich mir das mal durch den Kopf gehen lassen. Ich muss eben schauen wie das am einfachsten bzw. ob überhaupt auf meine Situation umsetzbar ist.
Ich habe das aus deiner Aussage "Der Dummy Homestatus_Marko ist nicht der Auslöser, sondern das Ziel-Device" genommen. Ok, habe ich mich geirrt.
Dann einfach nur das 2. Teil meines Posts mitberücksichtigen:
- der Auslöser ist
doch das dummy. Es generiert ein Event. Dies muss geloggt werden => FileLog entsprechend einstellen.
Ganz schön viele Devices/structures etc. ABER: du musst "durchblicken", das ist (nat.) die Hauptsache!
(ist halt evtl. schwer zu helfen, wenn man als Helfender nicht [auch] den Überblick hat)
Trotzdem eines (einfach damit nicht aneinander vorbei "geredet" wird / oder weniger): etwas "genauer" mit den Bezeichnungen sein... Z.B. (wenn ich falsch liege, dann liegt es eben genau "daran" ;) ):
userReadings vs. "eigene Readings".
Meinst du in deiner Beschreibung tatsächlich "userReadings" oder eher "eigene Readings"?
userReadings: ist ein Attribut bei einem Device. Wenn sich am Device "etwas ändert", es also einen Event gibt (Reading ändert sich), dann wird das userReadings "evaluiert" und wenn der Trigger (hoffentlich einer vorhanden) "greift" (also die RegEx "passt"), dann wird es auch "berechnet" und das entsprechende userReadings (darum auch "Mehrzahl", weil eben mehrere Readings "berechnet" werden können) wird "gesetzt"...
EDIT: ein userreadings wird (daher) auch nur "betrachtet", wenn sich an dem Device wo eben das Attribut "dran hängt" auch was ändert! (wird oft "übersehen")...
"eigene Readings": mittels "setreading Device ReadingName Wert" kann man (im Prinzip) jedem Device ein Reading "seiner Wahl" verpassen...
Nur damit nicht in die "falsche Richtung" gedacht wird beim Helfen...
Gruß, Joachim
Zitat von: Superposchi am 29 Dezember 2020, 19:26:34
@Beta-User
Grundsätzlich hat jedes Device ein state-Reading soweit mir bekannt ist. Es wird aber nur angezeigt wenn andere Readings vorhanden sind. [...]
Falsch.
Ein Device (in FHEM) kann viele Readings haben, aber ob es "state" gibt, entscheidet in der Regel der Maintainer. Bei MySensors gibt es das in der Regel z.B. nicht, und nicht mal bei dummy muss es das geben.
Ein "Ding" (also irgendein Gerät in der realen Welt) kann ein Device in FHEM ergeben, oder auch mehrere. Auch das liegt (überwiegend) in der Hand des Maintainers.
Und z.B. eine Lampe hat heutzutage oft nicht nur den "zentralen Zustand" ein/aus (bei Tasmota/MQTT übrigens "eigentlich" in Readings mit Namen "POWER.*" zu finden), sondern oft noch "brightness" oder "pct" und/oder ein oder mehrere Farbangaben.
Vielleicht hat ja jemand Lust, dir einen dummy zu bauen, bei dem man alles mögliche an Readings setzen kann, ohne "state" (oder "STATE") anzufassen...
@amenomade
ZitatDann einfach nur das 2. Teil meines Posts mitberücksichtigen:
- der Auslöser ist doch das dummy. Es generiert ein Event. Dies muss geloggt werden => FileLog entsprechend einstellen.
Nein, eben nicht. Das DOIF welches den Dummy schaltet ist der Auslöser und der Dummy das Zieldevice.
@MadMax-FHEM
Ja das stimmt, es sind wirklich viele Devices beteiligt, aber das ist dem Problem mit der Erkennung beim Aufstehen geschuldet. Dazu gab es ja einen eigenen Thread. Hab einiges ausprobiert, aber bisher hat sich diese Lösung als einzige funktionierende herausgestellt.
Wenn du es so schreibt, handelt es sich um eigene Readings. Wobei UserReadings doch im Prinzip auch eigene Readings sind, nur eben berechnete mit Formelinhalt statt fest gesetztem Wert, oder nicht?
@Beta-User
Irgendwie reden wir aneinander vorbei. Ein Device kann mehrere Readings haben und jedes Reading kann EINEN Zustand haben, das Device selbst übernimmt in der Regel den Zustand der im state-reading steht.
Zitat von: Superposchi am 29 Dezember 2020, 20:00:35
@amenomadeNein, eben nicht. Das DOIF welches den Dummy schaltet ist der Auslöser und der Dummy das Zieldevice.
Naja, das mit Ziel-Device und Auslöser ist halt auch so ein "Sprach-Dingens"...
Auslöser ist ein Event (und eigentlich kein Device ;) ) darauf kann mit einem Event-Handler (notify/DOIF/FileLog/...) reagiert werden.
Events kommen meist, wenn sich bei einem echten Gerät Daten ändern. Dann werden normalerweise eben entsprechende Readings in dem Device gesetzt und Events gefeuert (sofern nicht vom Modulautor "unterbunden" oder per event-on-change etc. "unterbunden"/"eingeschränkt" / Aber auch ob und welche readings im Device gesetzt werden, wenn sich an einem "echten" Gerät etwas ändert liegt beim Modulautor)...
Zitat von: Superposchi am 29 Dezember 2020, 20:00:35
@MadMax-FHEM
Ja das stimmt, es sind wirklich viele Devices beteiligt, aber das ist dem Problem mit der Erkennung beim Aufstehen geschuldet. Dazu gab es ja einen eigenen Thread. Hab einiges ausprobiert, aber bisher hat sich diese Lösung als einzige funktionierende herausgestellt.
Wenn du es so schreibt, handelt es sich um eigene Readings. Wobei UserReadings doch im Prinzip auch eigene Readings sind, nur eben berechnete mit Formelinhalt statt fest gesetztem Wert, oder nicht?
Auch "eigene Readings" können doch bevor sie "gesetzt werden" berechnet werden: {my $value=ReadingsVal("Device","Reading","Ersatz") * 2; fhem("setreading AnderesDevice AnderesReading $value")}
Wichtig ist halt die "Besonderheit" bei userReadings (oder auch mehrere): der Auslöser ist ein Event ABER der muss "vom" Device wo das userReadings dran hängt "gefeuert" werden (also es muss sich beim Device "was tun"). Das setreading kann "überall" aufgerufen werden und auch von verschiedenen Stellen getriggert werden, z.B. es ist in einer Sub in myUtils, die von verschiedenen notify/DOIF/... aufgerufen wird... userreadings ist also ein Eventhandler der an Events des Devices "gekoppelt" ist wo eben das Attribut gesetzt ist.
Ich hoffe ich habe es "verständlich" formuliert ohne "falsch" zu werden...
Gruß, Joachim
dummy kann mehr, wenn man will. ohne state STATE
und dann ist der dummy auch einfach zu loggen
Ihr schreibt mir einfach zu viel
defmod Test_Noten dummy
attr Test_Noten readingList Superposchi Supercat
attr Test_Noten room ANZ
attr Test_Noten setList Superposchi:6,5,4,3 Supercat:1,2,3,4
attr Test_Noten webCmd Superposchi:Supercat
nur so mal als Beispiel
ZitatAuslöser ist ein Event (und eigentlich kein Device ;) ) darauf kann mit einem Event-Handler (notify/DOIF/FileLog/...) reagiert werden.
Naja, ich würde es eher so formulieren Auslöser ist ein DOIF, notify etc., also eine getriggertes Device und das Event ist meiner Meinung nach eher die Reaktion auf den Auslöser. Aber ja, das Ganze zeigt wie wichtig gleiche Formulierungen und Bezeichnungen sind. Und leider scheitert es daran hier im Forum immens, denn viele User nutzen für das gleiche leider unterschiedliche Begriffe.
Also sicher ist, dass notify/DOIF/FileLog/... (im Normalfall) KEINE Auslöser sind.
Es sind "Eventhandler" (wurde ja schon mehrfach geschrieben)...
D.h. die REAGIEREN auf Events...
Zitat von: https://wiki.fhem.de/wiki/Notify
Das Hilfsmodul notify dient dazu Ereignisse über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit notify und anderen Eventhandlern [1] ist es möglich, Logikfunktionen im FHEM abzubilden.
[1] hierzu gehören u.a. auch DOIF, THRESHOLD und watchdog
Und ja sie können DARAUFHIN weitere Aktionen (auch Events, z.B. durch setreading, auslösen, meist aber eher indirekt durch Schalten von Devices welche dann evtl. wieder Events "feuern") auslösen...
...müssen das aber nicht.
Ein notify/DOIF/FileLog/... macht OHNE einen Event (der "passt"): GAR NICHTS...
Somit wird es wohl zwischen dir und anderen (weiterhin) unklar bzw. genau "andersrum" sein wenn von Auslöser und Ziel gesprochen wird...
Gruß, Joachim
Zitat von: Superposchi am 29 Dezember 2020, 20:00:35
@amenomadeNein, eben nicht. Das DOIF welches den Dummy schaltet ist der Auslöser und der Dummy das Zieldevice.
Das DOIF ist der Auslöser eines
Befehls. Dieser Befehl setzt den Dummy in einem bestimmten Zustand. Wenn der Dummy diesen Zustand erreicht, löst er ein
Event aus: "na guckt mal, ich habe jetzt den Zustand 3", und darüber (Events) reden wir. Auf diesem Event können andere Devices (notify, DOIF, oder eben FileLog) reagieren, es sei mit einem weiteren Befehl oder durch Schreiben in einer Log-Datei.
Aber ich gebe dir zu: wenn Du unbedingt deine eigene Terminologie haben willst, die zur Fhem-Logik mit Events nicht passt, und dir einfach nicht die Mühe gibst, die Erklärungen zu verstehen, sondern dich nur über Vokabel beschwerst, werden wir immer einander vorbei reden. Dann aber zukünftig ohne mich.
Sorry, an welcher Stelle habe ich mich noch mal beschwert? Ich habe geschrieben wie ich es verstehe, mehr nicht.
Wenn selbst das nicht erlaubt ist, warum schließt ihr das Forum dann nicht gleich und nehmt nur treue Gefolgsleute auf?
Aber das ist genau das was ich weiter vorn schon mal geschrieben habe. Viele User hier benehmen sich wie Prinzessinnen, die nicht regelmäßig rangenommen werden.
Das ist schlimmer wie im bissigsten Girls-Club, ganz ehrlich.
Und noch mal ganz ehrlich, ich kann nicht mehr. Jedes Wort auf die Goldwaage legen zu müssen nur um niemanden eventuell zu verletzen, das geht an die Nerven.
Und ich werde einen Teufel tun mich geistig kaputt zu machen nur um niemanden zu verprellen.
Mal langsam.
Wir bleiben sachlich und du wirst "persönlich"/angreifend...
(zumindest versuche ich es / nein ich habe nicht rückwirkend gesucht, ob es mir auch gelungen ist ;) )
Wichtig ist halt nun mal um helfen zu können, dass eben die "Nomenklatur" des Systems eingehalten wird.
Die haben ja nicht "wir" erfunden, sondern es ist halt wie es ist...
Du darfst ja (für dich) gerne deine Sicht haben/behalten aber wenn du Hilfe suchst, dann solltest du es so formulieren, dass es auch verstanden werden kann.
Hat nichts mit: es ist nicht erlaubt eine eigene Sicht zu haben zu tun...
Wenn man ein System nutzt/nutzen will, dann sollte man sich das eben aneignen, mehr versuchen wir nicht, als es zu erläutern...
Ansonsten ist es eben schwer zu helfen, weil eben du was anderes (deine Sicht) siehst/schreibst als "alle anderen" verstehen...
Das kann ja nicht zusammengehen...
Nicht mehr und nicht weniger ist von MEINER (unserer) Seite die letzten Posts passiert...
Gruß und raus, Joachim
Ich werde nicht persönlich, ich sage nur wie es ist. Sobald ich in irgendeiner Weise auch nur das geringste Schreibe, das eine andere Sicht, eine andere Formulierung oder sonst was darstellt - selbst wenn es nur zum Zweck der Erläuterung ist - wird hier eurerseits mit Blockade gedroht. Nicht ich bin es der hier persönlich reagiert, sondern ihr, doch ihr merkt das nicht einmal mehr.
Ja ich suche Hilfe und ja ich versuche zu lernen, mir das Vokabular anzueignen und mich der Konvention hier im Forum anzupassen. Doch wie bereits im letzten Post geschrieben kann ich nicht alles was ich über Jahre hinweg gelernt habe nicht einfach vergessen. Also ich weiß nicht wie andere das machen, aber ich habe damit ein Problem. Das ist weder böse gemeint, noch bösartig oder vorsätzlich. Das Problem ist einfach, dass die hier im Forum genutzten Verben und Konventionen so extrem von meiner Realität abweichen. Und es wird vermutlich Jahre dauern das umzulernen.
Was ich in meinem letzten Post ausdrücken wollte, ist einfach gesagt, die Tatsache, dass ich einfach am Ende meiner Kräfte bin und mich geistig nicht weiter kaputt machen lasse nur weil ich in meiner Realität andere Begrifflichkeiten und Verben kenne als hier genutzt werden. Ich bin es satt bei jeden zweiten Kommentar zu lesen "dann aber ohne mich" oder "fordere nicht", "wiederspreche nicht" etc.. wie du selbst schreibst kommt es darauf an die gleichen Definitionen und Verben zu nutzen. Manchmal ist es dazu notwendig die verschiedenen Seiten beim Namen zu nennen, doch das wird hier eben wie schon geschrieben direkt als Böswilligkeit dargestellt.
Ich will doch niemandem ans Bein pinkeln, aber ich kann auch nicht bei jedem Satz den ich schreibe 20 Minuten überlegen wie ich es formuliere nur damit sich niemand auf den Schlipps getreten fühlt. Genauso wenig kann ich aus Englisch Französisch machen nur weil ihr in eurer Gemeinschaft beschlossen habt, dass Französisch ab jetzt Englisch heißt. So kommt es mir jedenfalls vor wenn das was ich im realen Leben über Jahre gelernt habe hier komplett ignoriert und durch anderes ersetzt wird.