Hallo,
da ich das Problem mit FHEMWEB beobachte, habe ich hierher gepostet.
Ich habe folgendes:
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.
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
set ForceAll2Admin aus
im Backend ankommt?!
Das Verhalten scheint mir neu?
gromeck
IMHO müsste es "setstate ForeAll2Admin an" sein
Gesendet von meinem S3_32 mit Tapatalk
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
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:
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
Zitat von: Frank_Huber am 25 Mai 2017, 09:11:50
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.
Zitatdie Beispiele unter https://fhem.de/commandref_DE.html#FHEMWEB (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
attr Raumtemperatur readingsList state
helfen.
P.S.:
event-on-change-reading .*Kann bitte jemand die Stelle(n), wo dieser Quatch empfohlen ist, mir zeigen, oder am besten direkt entfernen?
Zitat von: rudolfkoenig am 25 Mai 2017, 09:58:01
P.S.:
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
Hallo Rudolf,
Zitat von: rudolfkoenig am 25 Mai 2017, 09:58:01
Vermutlich wird in deinem Fall
attr Raumtemperatur readingsList state
helfen.
Aaah, ja, das funzt ... danke!
gromeck
@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.
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
@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.
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