(Gelöst) devStateIcon, das nicht nur aus dem State besteht

Begonnen von Fabiango, 09 Juli 2019, 09:54:22

Vorheriges Thema - Nächstes Thema

Beta-User

[OT]
@pah: Danke für die Klarstellung. Wieder was gelernt... :)
(Dass niemand gezwungen wird, ist klar; ich wäre allerdings nie drauf gekommen, dass der betr. User mit Screenreader diese W3C-Option nicht kannte/kennt...)

(Und bevor ich mir jetzt einen Kopf mache, ob devStateIcon ggf. nur ausgeführt wird, wenn was angezeigt werden soll und wann stateFormat, lassen wir das jetzt damit sein Bewenden haben, oder...?)
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Fabiango

So konnte dank eurer Hilfe eine Lösung finden mit dem

userReadings
state {InternalVal($name, 'move', '')}

Beta-User

?!?
Zitat von: DJCrazy am 10 Juli 2019, 14:03:27
So konnte dank eurer Hilfe eine Lösung finden mit dem

userReadings
state {InternalVal($name, 'move', '')}
was ist denn das?
Geht denn ein einfaches stateFormat-Attribut nicht?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Prof. Dr. Peter Henning

Dieses Userreading sollte nicht "state" heißen...

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 10 Juli 2019, 14:41:23
Dieses Userreading sollte nicht "state" heißen...
... und nicht nur das... userReadings ohne sauberen Trigger sind auch .... "suboptimal".
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Prof. Dr. Peter Henning

attr <Device> userReading move_internal:none {InternalVal($name, 'move', '')}
etabliert ein entsprechendes Reading, das auch im stateFormat verwendet werden kann.

LG

pah

Beta-User

DASS es mit einem userReadings-Eintrag geht, ist klar; die Frage ist aber: Warum nicht gleich schlicht den direkten Weg via stateFormat in der Perl-Variante?!?

Der einzige Nachteil ist der, dass stateFormat erst dann "aktiv wird" (also STATE gefüllt wird), wenn es seit Start von FHEM mindestens einen Event für das Devices gab; aber sonst hat doch diese Umpackerei mit userReadings den m.E. nachteiligen Effekt, dass man ein weiteres Event erzeugt, oder übersehe ich grade was wichtiges? (kann ja sein, dass man das zusätzliche Event ausdrücklich haben will, dann ist es was anderes).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Prof. Dr. Peter Henning

Das sind doch gerade meine Vorschläge von oben...
Die Frage muss also nur lauten: Warum der TE das nicht macht?

LG

pah

Fabiango

#23
Ich habe nur diese Variante alleine mal hin bekommen.
Wenn es eine einfachere und bessere Variante gibt dürft ihr mir diese gerne sagen.

Beim stateFormat-Attribut weiss ich nicht wie der Code aussehen müsste.

Beta-User

Wie wäre es mit einem simplen
attr E.Verb stateFormat {InternalVal($name, 'move', '')}
Wie gesagt: Es braucht einen Trigger... Also einmal Schalten bitte ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Fabiango

Super Danke Beta-User.
Nun konnte ich es auch mit dieser Variante erfolgreich Umsetzen und werde es auch dabei so belassen.

Beta-User

Zitat von: DJCrazy am 10 Juli 2019, 17:40:43
Super Danke Beta-User.
Nun konnte ich es auch mit dieser Variante erfolgreich Umsetzen und werde es auch dabei so belassen.
:) Gerne!

Ist nicht so ganz einfach zu durchschauen, wie die Attribute zur Anzeige da zusammenwirken. Das muß man wohl mehr wie einmal durchgespielt haben, damit man ein Gefühl dafür entwickelt... :D
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors