[gelöst] Dummy Loggen

Superposchi · 29 Dezember 2020, 15:03:53

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.

amenomade · 29 Dezember 2020, 15:15:53

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

Beta-User · 29 Dezember 2020, 15:24:49

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)...

Superposchi · 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.

amenomade · 29 Dezember 2020, 19:35:20

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.

MadMax-FHEM · 29 Dezember 2020, 19:39:07

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

Beta-User · 29 Dezember 2020, 19:48:41

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...

Superposchi · 29 Dezember 2020, 20:00:35

@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.

MadMax-FHEM · 29 Dezember 2020, 20:12:13

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

LuckyDay · 29 Dezember 2020, 21:10:30

dummy kann mehr, wenn man will. ohne state STATE
und dann ist der dummy auch einfach zu loggen

Ihr schreibt mir einfach zu viel

Code Auswählen

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

Superposchi · 29 Dezember 2020, 22:08:56

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.

MadMax-FHEM · 29 Dezember 2020, 22:16:26

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

amenomade · 29 Dezember 2020, 22:44:39

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.

Superposchi · 29 Dezember 2020, 23:12:48

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.

MadMax-FHEM · 29 Dezember 2020, 23:28:26

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