[erledigt] stateFormat und commend.ref

Begonnen von JoWiemann, 09 Februar 2022, 11:59:19

Vorheriges Thema - Nächstes Thema

JoWiemann

Hallo,

ausgelöst durch ein Module und die Nachfrage beim Maintainer, warum er denn hash->{STATE} direkt beschreibt ist dann präsent geworden, dass wirklich sehr viele Module dies tun. Meine bitte wäre dies in der command.ref entsprechend zu vermerken.

Vielen Dank und Grüße

Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

rudolfkoenig

Der commandref ist fuer die Benutzer gedacht, und nicht fuer den Modulentwickler.
Sowas ist in der Wiki besser aufgehoben, oder in (der noch unvollstaendigen) docs/fhem_api.tzxt

JoWiemann

Ist schon richtig. Aber der Benutzer sollte wissen, dass stateFormat nicht immer so funktioniert, wie er es erwartet.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Beta-User

In der Regel sind das ja nicht viele Stellen, und (vermutlich) geht es auch darum, den Wert nicht-triggernd zu setzen.

Von daher wäre es vermutlich doch (statt sich die Frage zu stellen, wie man das dokumentiert) einfacher, das (in diesen Fällen vermutlich nicht genutzte) Reading "state" nichttriggernd zu setzen und den Rest per evalStateFormat zu erledigen, oder?
Aso in diese Richtung:
readingsSingleUpdate($hash, 'state', 'active', 0);
evalStateFormat($hash);
       
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JoWiemann

Zitat von: Beta-User am 09 Februar 2022, 12:31:09
In der Regel sind das ja nicht viele Stellen

Für das einzelne Modul richtig. Aber, es sind einfach seeeehr viele Module.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Beta-User

Zitat von: JoWiemann am 09 Februar 2022, 12:39:03
Für das einzelne Modul richtig. Aber, es sind einfach seeeehr viele Module.
Ahh, es geht also wirklich um einen ergänzenden Hinweis bei der Hilfe zu stateFormat, in diese Richtung:
Hinweis: Manche Module aktualisieren STATE ganz oder teilweise direkt. In diesen Fällen kann es zu abweichenden Anzeigen kommen.

PS: Zwei der seeeehr vielen Module habe ich grade (jetzt eben auch in diese Richtung) "in der Mache"...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JoWiemann

Zitat von: Beta-User am 09 Februar 2022, 13:04:38
Ahh, es geht also wirklich um einen ergänzenden Hinweis bei der Hilfe zu stateFormat, in diese Richtung:
Hinweis: Manche Module aktualisieren STATE ganz oder teilweise direkt. In diesen Fällen kann es zu abweichenden Anzeigen kommen.

Das war meine Intension. Vielleicht doch zu unpräzise ausgedrückt.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

rudolfkoenig

Habe die beiden Dokus angepasst.

JoWiemann

Zitat von: rudolfkoenig am 09 Februar 2022, 14:41:51
Habe die beiden Dokus angepasst.

Hallo Rudi,

vielen Dank.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM