***GELÖST*** Device Reading state, unklares Verhalten bei Notify und FileLog

[duu75]

Bei der Fehlersuche bei einem Problem mit HUE bin auf folgendes Phänomen gestoßen, was mir bisher so nicht klar war bzw. nie aufgefallen ist.
Warum kann man das Reading "state" eines Devices nicht loggen bzw. warum triggert es kein Notify, wenn ich es so explizit in den RegexpPart im Notify oder FileLog angebe?

..... DeviceXYZ:state:.*

Auch andere Schreibweisen gehen nicht wie z.B.  DeviceXYZ:state.* oder DeviceXYZ:sta.*

Gebe ich nur das Device ohne spezifisches Reading state an, wird geloggt und auch im Notify getriggert auf Änderungen.

Das ganze scheint mit dem Namen des Readings beginnend mit "stat..." zu tun zu haben, weil bei einem Reading "status" ist das gleiche Problem.

Ist das so gewollt und warum?
Ist das ein Bug?

Gruß
Dirk

[Beta-User]

Es gibt sogar ein Attribut für dieses "Problem" .

[Torxgewinde]

...darf der OP jetzt raten, sich ggf. schlecht fühlen, dass das ja jeder weiß außer ihm? Dies ist der Anfängerbereich vom Forum, helft doch bitte.

[Beta-User]

...darf der OP jetzt raten, sich ggf. schlecht fühlen, dass das ja jeder weiß außer ihm? Dies ist der Anfängerbereich vom Forum, helft doch bitte.

Nein. Er soll sich die commandref zu notify und/oder FileLog ansehen, dann wird er "addStateEvent" vermutlich in den dortigen Attributen finden... Oder einfach die "Modulspezifischen Attribute" in FHEMWEB mal durchgehen, dann poppt da zu diesem Attribut bei notify sogar genau das auf, was der TE sucht.

Anfänger heißt für mich übrigens "Hilfe zur Selbsthilfe".

[duu75]

...darf der OP jetzt raten, sich ggf. schlecht fühlen, dass das ja jeder weiß außer ihm? Dies ist der Anfängerbereich vom Forum, helft doch bitte.

Nein. Er soll sich die commandref zu notify und/oder FileLog ansehen, dann wird er "addStateEvent" vermutlich in den dortigen Attributen finden... Oder einfach die "Modulspezifischen Attribute" in FHEMWEB mal durchgehen, dann poppt da zu diesem Attribut bei notify sogar genau das auf, was der TE sucht.

Anfänger heißt für mich übrigens "Hilfe zur Selbsthilfe".

Was meist du wohl, was ich bereits getan habe!
Ich war auch schon selber über addStateEvent gestolpert bei der sogenannten "SELBSTHILFE".

So wie das aber, in den von mir gefundenen Stellen, beschrieben war, war ich fälschlicherweise davon ausgegangen, dass es nur den String "state:" stripped oder eben nicht.

Nach nun erfolgter genauerer Suche unter den verschiedenen Modulen wie Notify, Log etc. sind dann hier und da auch noch einige weitere Infos zu finden, die allerdings meiner Ansicht nach auch nicht sehr eindeutig beschrieben sind.
Bleibt mir dann noch das Testen an meinem konkreten Beispiel, ob es das Problem löst.

Alleine nur der Hinweis auf addStateEvent hätte mir ja schon gereicht, um danach detaillierter zu suchen, anstelle des arroganten "Es gibt sogar ein Attribut für dieses "Problem""
Scheint aber überall immer mehr in Mode zu kommen.

Dennoch vielen Dank für den Tip!

Und das Attribut addStateEvent erklärt aber trotzdem nicht, warum es auch mit einem Reading status nicht geht.
Und state und status ist nicht das gleiche Reading.
Oder gibt es auch noch ein addStatusEvent?
Oder warum triggert das Reading status kein Notify?

[Beta-User]

Und das Attribut addStateEvent erklärt aber trotzdem nicht, warum es auch mit einem Reading status nicht geht.
Und state und status ist nicht das gleiche Reading.
Oder gibt es auch noch ein addStatusEvent?
Oder warum triggert das Reading status kein Notify?

Habe kurz mal eines meiner HUEDevice's angesehen. Da gab es aber keinen "status", von daher kann ich das nicht nachvollziehen.

Nochmal kurz zusammengefaßt:
notify und Filelog reagieren auf die Events, wie sie im Eventmonitor angezeigt werden, daher auch die Empfehlung an Anfänger, diese Devices damit auch anlegen zu lassen. Da (Eventmonitor) wird (nur!) "state" ohne die explizite Angabe des Readingnamens ausgeworfen.

Du findest also die Lösung der Frage, warum das mit "status" anscheinend nicht klappt dann eben auch im Eventmonitor.

[Torxgewinde]

Danke!

[Prof. Dr. Peter Henning]

Wir sollten noch eines klar festhalten: An dem Hinweis "Es gibt sogar ein Attribut für dieses "Problem"" ist nichts, aber auch gar nichts "arrogant".

pah

[duu75]

Wir sollten noch eines klar festhalten: An dem Hinweis "Es gibt sogar ein Attribut für dieses "Problem"" ist nichts, aber auch gar nichts "arrogant".

pah

Wenn Sie das so sehen!
Ich in meiner Situation und meiner höflich gestellten Frage im Anfängerbereich, habe das allerdings so gesehen.

[duu75]

Und das Attribut addStateEvent erklärt aber trotzdem nicht, warum es auch mit einem Reading status nicht geht.
Und state und status ist nicht das gleiche Reading.
Oder gibt es auch noch ein addStatusEvent?
Oder warum triggert das Reading status kein Notify?

Habe kurz mal eines meiner HUEDevice's angesehen. Da gab es aber keinen "status", von daher kann ich das nicht nachvollziehen.

Nochmal kurz zusammengefaßt:
notify und Filelog reagieren auf die Events, wie sie im Eventmonitor angezeigt werden, daher auch die Empfehlung an Anfänger, diese Devices damit auch anlegen zu lassen. Da (Eventmonitor) wird (nur!) "state" ohne die explizite Angabe des Readingnamens ausgeworfen.

Du findest also die Lösung der Frage, warum das mit "status" anscheinend nicht klappt dann eben auch im Eventmonitor.

Das Reading status habe ich beim Tüfteln und Fehlersuchen einfach mal auf dem Device mittels setreading gesetzt, um zu schauen, ob es an dem Reading beginnend mit stat.... liegt.
Merkwürdigerweise funktioniert jetzt status im Log und notify auch ohne addstatevent, nach einem FHEM Restart.
Hmm..sei es drum.

Jedenfalls hat das addstateevent MEIN Problem lösen können.
Danke.

[Beta-User]

Schön, dass es klappt wie es soll.

Markierst du den Thread noch als [gelöst], damit sich hier keiner mehr bemüßigt fühlt, unnötigerweise Befindlichkeiten zu diskutieren? Danke!