STATE-Variable im Log?

Begonnen von akw, 31 März 2014, 20:56:11

Vorheriges Thema - Nächstes Thema

akw

Hi,

ich habe folgendes Problem: Für meine Handy-App sammle ich Live-Daten vom Log (so wie der "Event Monitor" in pgm2).

Wenn ich z.B. mein HUEDevice einstelle, bekomme ich:
2014-03-31 20:48:05 HUEDevice HUEDevice5 bri: 108
2014-03-31 20:48:05 HUEDevice HUEDevice5 level: 42 %
2014-03-31 20:48:05 HUEDevice HUEDevice5 pct: 42
2014-03-31 20:48:05 HUEDevice HUEDevice5 dim43%


Soweit klasse, aber leider fehlt hier die besonders wichtige Angabe, was aktuell in der STATE-Variable steht. Diese kann ja durch das Attribut stateFormat eingestellt werden.

Es wäre extrem unpraktisch wenn ich in meiner App das Log pollen müsste, um dann bei jeder Änderung explizit z.B. mit "list HUEDevice5" den aktuellen STATE abzufragen.
Client-seitig kann ich den STATE auch nicht aus stateFormat herleiten, da dieser ja theoretisch durch einen PERL-Ausdruck {} gesetzt sein könnte.

Gibt es eine konfigurierbare Möglichkeit, STATE-Änderungen in's Log zu kriegen?
Ich hätte gerne etwas wie

2014-03-31 20:48:05 HUEDevice HUEDevice5 STATE: 42%
oder vielleicht besser:
2014-03-31 20:48:05 HUEDevice HUEDevice5 42%

(In meinem "stateFormat"-Attribut steht: "pct%")


Ciao, Arno

FHEM-SVN auf MacMini OSX 10.7.5

FS20,FHT,HMS,CUL_WS,CUL_HM,KS300,HUE,FB_DECT

FHEMobile: www.fhemobile.de

betateilchen

Zitat von: akw am 31 März 2014, 20:56:11
Soweit klasse, aber leider fehlt hier die besonders wichtige Angabe, was aktuell in der STATE-Variable steht.
Diese kann ja durch das Attribut stateFormat eingestellt werden.

STATE ist kein Reading, sondern ein Internal, deshalb gibt es dafür keinen Logeintrag.

Versuch doch mal, anstatt mit stateFormat mit einem userReading zu arbeiten. Das sollte mMn auch geloggt werden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

so wie du dir das vorstellst geht das nicht.

STATE wird nicht geloggt und es gibt keine events dafür.

state wird geloggt und erzeugt events aber ist nicht immer eindeutig zu parsen.

die einzige möglichkeit wirklich an STATE zu kommen ist es mit Value abzufragen oder selber stateFormat auszuwerten.

da STATE eigentlich eine frontend geschichte ist und nicht unbedingt für jedes frontend gleich sein muss könnte man fast sgen es gehört eigentlich in jedes frontend getrennt rein...
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

akw

Zitat von: justme1968 am 31 März 2014, 21:10:00
da STATE eigentlich eine frontend geschichte ist und nicht unbedingt für jedes frontend gleich sein muss könnte man fast sgen es gehört eigentlich in jedes frontend getrennt rein...

Hi,

aber da liegt dann doch ein Design-Fehler vor, oder habe ich es immer noch nicht verstanden?

Das Frontend (z.B. meine App) benötigt STATE, da hier die Ausgabe drin ist, die der User haben möchte! Aber ich bekomme STATE als Internal nicht automatisch mit, sondern muss es pro Device per list, jsonlist oder xmllist laden. :-(

Meiner Meinung nach sollte es kein Internal, sondern ein spezielles Reading sein. Das würde die Handhabung für Frontends deutlich vereinfachen.

Ich habe scheinbar nur folgende Möglichkeit:
* Wenn neue Log-Einträge eines Gerätes ankommen, das stateFormat Attribut parsen.
* Falls es {} enthält, muss das Gerät extra gepolled werden
* Ansonsten alle Readings durchgehen und im stateFormat-String die Readings-Keys durch die Values ersetzen. (Die Keys müssen vorher nach Stringlänge sortiert werden, denn HUEDevice hat z.B. 'ct' und 'pct'..)

Das Problem damit ist, dass ich bei jeder Erweiterung/Änderung vom stateFormat-Format hinterherhinke..

Ciao, Arno
FHEM-SVN auf MacMini OSX 10.7.5

FS20,FHT,HMS,CUL_WS,CUL_HM,KS300,HUE,FB_DECT

FHEMobile: www.fhemobile.de

justme1968

ich würde sagen STATE und stateFormat sind spezifisch für das fhemweb frontend. ein frontend das nicht auf perl aufbaut und im fhem prozess läuft würde einen eigenen mechanismus implementieren. für etwas das vermutlich aus der zeit stammt da es nur ein einziges frontend gab würde ich sagen design fehler ist etwas hart.

aber wie wäre es wenn du dich an den web port hängst und die nachrichten auswertest die fhem für die longpoll updates an den client schickt. da bekommst du genau das was du möchtest. sogar inklusive der icons die der anwender für diese web instanz konfiguriert hat.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ich bin auch etwas ungluecklich mit der Situation, da selbst FHEMWEB mit longpoll das state Reading nicht aktualisieren kann. Einem Frontend bleibt entweder die Auswertung der FHEMWEB-longpoll-Nachrichten (was nur fuer HTML-basierte Frontends trivial ist), oder die Abfrage von {Value("name")} nach jedem Event, was offensichtlich auch nicht optimal ist.

Sinnvoll faende ich fuer state & STATE zwei neue Event zu generieren, was FileLog, DbLog, notify, etc erst mit gesetzten "processStateEvents" Attribut beachten. Bin nur noch nicht sicher, wie/wann man die STATE Aenderung erkennen soll.

rudolfkoenig

@Arno: ich meine dein Problem ist unabhaengig vom stateFormat: woher weisst Du was Status, und was Reading ist?

betateilchen

Zitat von: rudolfkoenig am 01 April 2014, 09:52:16
Sinnvoll faende ich fuer state & STATE zwei neue Event zu generieren,

Ich finde, für ein Internal (STATE) braucht es keinen Event. Es würde m.E. ausreichen, für state einen Event zu haben, auf den man zuverlässig triggern kann und somit eine Gleichbehandlung zu anderen Readings hergestellt ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

ich denke auch das STATE kein reading ist und nicht den gleichen mechnismus wie die readings verwenden sollte.

zumal STATE bzw. das was im frontend als STATE dargestellt wird ja nicht unbedingt ein text ist sondern auch ein icon sein kann. hier wäre es für andere frontends glaube ich auch wichtig an die icons zu kommen. also das was der benutzer gerade konfiguriert hat. der weg kann ja durchaus lang sein: state/stateFormat -> STATE -> devStateIcon -> icon. das in jedem frontend nachzubauen ist unglücklich.

state gleich zu behandeln wie alle anderen readings und ein event zu erzeugen wäre aber klasse.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Zitatstate gleich zu behandeln wie alle anderen readings und ein event zu erzeugen wäre aber klasse.
Ok, da ich es optional und zunaechst deaktiviert haben will, ist die Frage ob man lieber einen globales Attribut oder eins per notify/FileLog/etc haben will. FHEMWEB wuerde es immer haben wollen, das spricht fuer modulspezifisch.

betateilchen

Ich bin auch für modulspezifisch.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

modulspezifisch ist vermutlich erst mal am nebenwirkungs ärmsten.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Hab das addStateEvent Attribut fuer die Module notify, FileLog, watchdog, FHEMWEB und eventTypes eingefuehrt, die Voreinstellung ist 0 (aus). Ausnahme: FHEMWEB Detailansicht (bzw. longpoll fuer statusupdates), hier ist Voreinstellung 1 (an), d.h. in der Detailansicht wird die state Readings-Zeile ab sofort bei Aenderung auch rot gefaerbt. Fuer das Event Monitor muss man das Attribut in FHEMWEB explizit auf 1 setzen.

Falls ein Modul addStateEvent unterstuetzen moechte, dann darf es nicht mehr direkt auf $devhash->{CHANGED} zugreifen, sondern muss diese Liste per deviceEvents($devhash) abholen. Diese Funktion ist in fhem.pl definiert.

Nach einer Uebergangszeit sollten wir Voreinstellung auf 1 (an) aendern.

akw

#13
Zitat von: rudolfkoenig am 06 April 2014, 08:40:09
Hab das addStateEvent Attribut fuer die Module notify, FileLog, watchdog, FHEMWEB und eventTypes eingefuehrt, die Voreinstellung ist 0 (aus).

Grossartig, das ist meiner Meinung nach der richtige Weg!


Aber was ist mit STATE? Der bleibt nach wie vor auf dem alten Wert...
FHEM-SVN auf MacMini OSX 10.7.5

FS20,FHT,HMS,CUL_WS,CUL_HM,KS300,HUE,FB_DECT

FHEMobile: www.fhemobile.de