Verständnisfrage zu stateFormat

Begonnen von FHEMAN, 20 Januar 2016, 00:36:54

Vorheriges Thema - Nächstes Thema

FHEMAN

Hallo,

ich habe ein Schließerkontakt Interface HM-SCI-3-FM. Ich möchte bei Änderung des Kanal 1 den state am übergeordneten Interface anzeigen lassen. Den hübsche ich mir dann wiederum mit devstateicon auf. Meine Idee war stateFormat, da ich hier mit Perl Code ein wenig jonglieren kann.

Vereinfachtes Beispiel, was ich möchte:
ZitatSchliesserkontakt01 stateFormat { Value($name . ".Sw.01") } ==> state soll "open" anzeigen
Schliesserkontakt01.Sw.01 state: open

ZitatSchliesserkontakt01 stateFormat { Value($name . ".Sw.01") } ==> state soll "closed" anzeigen
Schliesserkontakt01.Sw.01 state: closed

Leider funktioniert die Anzeige bei Änderungen nicht zuverlässig.
Kann es sein, dass Änderungen bei den Kanälen nicht das stateFormat triggert? Muss ich hier etwas umständlicher mit userReadings arbeiten (verliere dann aber die devstateicon Funktion, da die nur auf STATE geht)?
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

marvin78

Die Frage ist, warum du das im übergeordneten Device haben möchtest und nicht einfach den Kanal als Device benutzt? Diesen kannst du ja auch mit devStateIcon und dem ganzen geraffel aufhübschen und er ist ein vollwertiges FHEM-Device. Bei mir verschwinden alle "Haupt-Devices" mit Kanälen in einem versteckten Raum und im Frontend arbeite ich nur mit den Kanälen.

Andernfalls solltest du im stateFormat eventuell mit ReadingsVal arbeiten, statt mit Value, weil die Triggerreihenfolge hier die bessere ist (reading vor STATE).

FHEMAN

Ich fasse verschiedene Kombinationen der Schaltzustände der Channels eines Device zu einem klaren Zustand aus. Daher wollte ich nicht in Channel 1 einen Zustand von Channel 2 auswerten + anzeigen und umgekehrt. Vermutlich muss ich mich da mal in userReadings einarbeiten. Grundsätzlich will ich aber Code, Dummies, Defines etc. vermeiden, weil die FHEM Oberfläche trotz diverser angelegter Räume schon jetzt unübersichtlich ist.
Value() habe ich ReadingsVal() aus diesem Grund auch vorgezogen und verwende es diversen Stellen. Ich wusste gar nicht, dass hier intern ein Unterschied besteht. Ich werde das einmal ausprobieren, danke für den Hinweis!
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

marvin78

Das was du machen möchtest, ist, wenn ich es richtig verstanden habe, ein Fall für structure.

Den Grund, warum du Value() vorziehst, verstehe ich ganz und garnicht.

frank

userreadings werden dir wohl auch nicht weiterhelfen, da sie ebenfalls von den readings des devices, in dem sie angelegt sind, getriggert werden müssen.

in ausnahmefällen, "kopiere" (setreading) ich mir mit notifys die readings in das device, wo ich unbedingt mit stateformat zusätzliche zustände aus anderen devices brauche/möchte.

ansonsten nutze readingsgroup, da kannst du dir bequem alles zusammenholen, was du möchtest.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

FHEMAN

ZitatDen Grund, warum du Value() vorziehst, verstehe ich ganz und garnicht.
Weil es schneller zu schreiben ist und ich mir keinen Defaultvalue ausdenken muss. Der Mehrwert ist zugegebenermaßen gering, aber warum sollte ich es nicht verwenden?

Zitatin ausnahmefällen, "kopiere" (setreading) ich mir mit notifys
Das ist ja eine Idee! Wenn ich mit dem Moloch "readginsgroup" nicht weiterkomme, löse ich es so!

Was ich nicht verstehe, ist, dass es verkehrt herum funktioniert. Also ich schließe Sw1 (closed), und im "Haupt-Device erscheint adhoc "open"... gibt es dafür eine Erklärung?
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB