set state setzt falschen state

[gromeck]

Hallo,
da ich das Problem mit FHEMWEB beobachte, habe ich hierher gepostet.

Ich habe folgendes:

Code Auswählen Erweitern


fhem@CasaDiLorenzi> list ForceAll2Admin   
Internals:
   CFGFN      fhem-CasaDiLorenzi-WhatsApp.cfg
   NAME       ForceAll2Admin
   NR         1363
   STATE      aus
   TYPE       dummy
   Readings:
     2017-05-25 07:57:41   state           aus
Attributes:
   devStateIcon an:general_an@orange aus:general_aus@grey .*:unknown@red
   event-on-change-reading .*
   group      System
   icon       user_unknown
   setList    state:an,aus
   sortby     0

In FHEMWEB wird daraus richtigerweise "set ForeAll2Admin state [an|aus]". Wähle ich nun aber "an" oder "aus" und klicke "set", so wird state auf "state an" bzw. "state aus" gesetzt.

Code Auswählen Erweitern


2017.05.25 08:03:04 4: FrontendWeb_192.168.0.60_50802 POST /fhem?cmd.setForceAll2Admin%3Dset%20ForceAll2Admin%20state%20aus&XHR=1&fwcsrf=csrf_717946454769466&fw_id=2111; BUFLEN:0
2017.05.25 08:03:04 5: Cmd: >set ForceAll2Admin state aus<
2017.05.25 08:03:04 4: dummy set ForceAll2Admin state aus


Richtig wäre doch aber, dass

Code Auswählen Erweitern


set ForceAll2Admin aus

im Backend ankommt?!

Das Verhalten scheint mir neu?

gromeck

[Frank_Huber]

IMHO müsste es "setstate ForeAll2Admin an" sein

Gesendet von meinem S3_32 mit Tapatalk

[MadMax-FHEM]

Du willst doch nur an/aus schalten/setzen!?

Reicht dann nicht einfach:

setList an aus

Habe es gerade mit einem TestDummy probiert und dann wird der STATE und auch das Reading state auf "an" bzw. "aus" gesetzt...

Gruß, Joachim

[gromeck]

Ja, stimmt, das geht, aber irgendwie ist die Dokumentation da offenbar nicht eindeutig.

Leider fehlt im Wiki die Syntax unter https://wiki.fhem.de/wiki/SetList, aber die Beispiele sagen:

Code Auswählen Erweitern

define Raumtemperatur dummmy
attr Raumtemperatur setList state:slider,10,0.5,30,1
:
attr Beschattung_auto setList state:aktiv,passiv

Die CommandRef ist da irgendwie unter dummy (https://fhem.de/commandref_DE.html#dummy) eindeutiger,  aber die Beispiele unter https://fhem.de/commandref_DE.html#FHEMWEB sind im Abschnitt webCmd dann wohl falsch.

gromeck

[gromeck]

IMHO müsste es "setstate ForeAll2Admin an" sein

Nein, Einspruch, dass verwendest du nur, wenn du den Status verändern willst ohne Events zu generieren oder an Geräte zu senden.

[rudolfkoenig]

die Beispiele unter https://fhem.de/commandref_DE.html#FHEMWEB sind im Abschnitt webCmd dann wohl falsch.

Sie wurden nach der Einfuehrung des readingsList dummy Attributes nicht angepasst, das habe ich jetzt nachgeholt.
Vermutlich wird in deinem Fall

Code Auswählen Erweitern

attr Raumtemperatur readingsList state

helfen.

P.S.:

Code Auswählen Erweitern

   event-on-change-reading .*
Kann bitte jemand die Stelle(n), wo dieser Quatch empfohlen ist, mir zeigen, oder am besten direkt entfernen?

[MadMax-FHEM]

P.S.:

Code Auswählen Erweitern

   event-on-change-reading .*
Kann bitte jemand die Stelle(n), wo dieser Quatch empfohlen ist, mir zeigen, oder am besten direkt entfernen?

Hallo Rudolf,

äh wieso Quatsch?

Ich weiß leider die Stelle(n) wo ich das her hab nicht mehr aber ich hab das schon öfters in Gebrauch, halt da wo ich nur wenige Events "abgreife" und das dann auch nur bei Änderung will, dachte das wäre der Sinn des Attributes!?

Z.B. PRESENCE, Tür-/Fensterkontakt, ...

Jetzt bin ich verwirrt, sorry...

Gruß und danke, Joachm

[gromeck]

Hallo Rudolf,

Vermutlich wird in deinem Fall

Code Auswählen Erweitern

attr Raumtemperatur readingsList state

helfen.

Aaah, ja, das funzt ... danke!
gromeck

[rudolfkoenig]

@Madmax-FHEM: "event-on-change-reading: .*" sagt, bitte alle Events erlauben. Ohne Attribut passiert das auch, mit Attribut wir aber jedes Event einzeln geprueft, ob das Event auf diesem Regexp passt. Weiterhin werden fuer alle event-* Attribute vor Generierung jedes Events fuer das betroffene Device Datenstrukturen angelegt, und danach wieder entfernt. D.h. in diesem Fall bremst das Attribut FHEM, ohne irgendwelche Vorteile.

In welchem Fall das Anlegen von event-on-change-reading ein Geschwindigkeitsvorteil bringt, haengt stark von den definierten Event-Verbraucher (wie notify/FileLog/DOIF/etc) ab, ich wuerde event-* aber erst dann einsetzen, wenn ich an den Verbrauchern nichts mehr optimieren kann.

[Frank_Huber]

Moin Moin,

das event-on-change verhindert doch auch das loggen gleicher daten. Hierdrin sehe ich den Vorteil davon.
Es wird nur geloggt und ein Event erzeugt wenn sich die Daten auch geändert haben.
Oder sehe ich hier was falsch?

Grüße
Frank

[rudolfkoenig]

@Frank_Huber: Du hast Recht, und sorry, ich habe event-on-change-reading mit event-on-update-reading verwechselt.

Ich sehe aber event-on-change Reading auch nur als "Ultima Ratio" (insb. mit dem Parameter .*), weil es diverse Nebeneffekte hat: kein Update in FHEMWEB, komisch gemalte Linien in SVG, evtl Probleme mit watchdog/sequence, etc. Ich meine das verursachende Modul sollte dafuer sorgen, dass Events "vertretbar" haeufig generiert werden.  Auf einem dummy angewendet verstehe ich den Sinn von event-on-change-reading gar nicht.

[MadMax-FHEM]

Ah, ok.

Beruhigt ein wenig...

Hallo Rudolf,

dann ist's ja (halb)gut.

War schon verwirrt, weil ich dachte nach etlichem Lesen etc. wüsste ich nun wie event-on-change-reading und eben event-on-update-reading funktioniert bzw. wofür was

Ja das mit den Linien etc. ist klar und auch wenn ich bewußt Reaktionen will, dann "unterdrücke" ich ja nicht.
Da nehme ich (meist) was das Modul so ausspuckt...

Es gibt aber eben auch Dinge die finde ich weniger wichtig bzw. reichen mir einmalig, eben bei Änderung.
Daher z.B. beim Fenstersensor habe ich es gesetzt...
...einmal auf/zu Meldung reicht mir...

Danke, Joachim