CUL_HM devStateIcon generation

[martinp876]

fhem bietet eine schöne (und nowendige) option, Icons entsprechend dem Status einer entity anzuzeigen. Die Handhabung aus der "Zentrale" ist m.E. optimal - aber das ist mir nicht hinreichend. Die Bedienung ist am Ende viel zu sperrig. Schliesslich soll es hier "automatisierung" sein - komplexe Zuweisungen in Attributen - das auch noch einzeln.
Generell weise ich Typ-attribute automatisiert zu und korrigiere das nach meinen Vorgaben bei jeden Reboot. Hierzu habe ich ein "User.cfg" welches durch notify am Ende des Ladevorgangs einhänge (meine Empfehlung - eigentlich ein Muss).

Code Auswählen Erweitern

define userCfg notify global:INITIALIZED include setup/c_User.cfg

in diesem file habe ich unter anderem ein

Code Auswählen Erweitern

attr TYPE=CUL_HM      devStateIcon {CUL_HM_getIcon($name)}
eingebaut, welches das Attribut zum Icon für alle CUL_HM devices automtisch setzt.
=> so stelle ich mir eine Systematik vor.

Die Anforderung
FHEM bietet automatisch stateIcons an - welche mir nicht aussagekräftig und passgenau genug sind. Ich will nach (m)einer Systematik die Icons zuweisen.
Um die Icons zu "ermitteln" bedarf es ggf die Kombination aus mehreren Readings - oder mehreren Entities.
Ein Aufruf MUSS für alle Entites genutzt werden können. Sonst macht es keinen Spass!!!!
Icon requirements
Die Zustands Pictogramme sollen
- aus dem Repository von FHEM stammen (was die Auswahl leider einschränkt)
- Aktivitäten farbig darstellen (also Licht an = bunt, Licht aus = sw, dimmer minimal = bunt da es an ist)
- möglichst viel Information beinhalten
=> meine aktuelle Auswahl ist getroffen und wird als default für CUL_HM zu Verfügung gestellt.
=> ich werden es noch erweitern! Es ist nicht komplett
die Implementierung
Einen integrierten Einbau in CUL_HM habe ich nicht gemacht - macht keinen Sinn. Ich habe keine Systematik gefunden, ein einfaches UND flexibles UserInterface zu erstellen.
Somit ist die Funktion CUL_HM_getIcon als default und Template zu verstehen.
Über die obige Attributs-Zuweisung kann Admin die Funktion einem oder allen entites zuweisen.
aktuell ist die Funktion auf CUL_HM beschränkt. Ich werde mir eine übergeordnete Funktion erstellen, welches nach TYPE auch andere Subroutines nutzt.
Die Icon-Ermittlung CUL_HM_getIcon
In der Funktion wird das Icon auf Basis mehrer Readings und Eigenschaften ermittelt. Die Programmierung wird relativ häufig aufgerufen, also sollte man auf Performace achten. Möglichst wenig If, wenig Calls is zum return.

Das Icon wird gemäß "status-prio" ermittelt. Wenn eine übergeordnete Entity ein gewichtiges Event zu melden hat, ist das Prio 1,... Wenn also das Device tot ist wird das Icon der Channels auf "tot" gesetzt...
- bei virtuellen Devices wird immer ein default icon ausgegeben - da sollte mir noch etwas einfallen.
- ist der Status des Device "dead" wird das RIP-icon in allen Entites dieses Device eingeblendet
- Fährt ein Rollo oder dimmt ein Dimmer wird dies passende "up" - "down" icon eingeblendet.
- die Berechnung des Dim / Rollo Zustands ist aus Level zu errechnen. Hierbei ist a) die Anzahl der Icons und b) die Endzustände zu betrachten. Leider ist die Namensgebung der Icons schlecht autmatisierbar (wer hat den das gemacht?).  Wichtig ist mir, dass minimal an/offen NIE als zu/aus dargestellt wird. gleiches gilt für 99.5 vs 100%
- Icons für Device - only entities zeigen den Zustand des Message-Interface dar - in Form einer Ampel.

Die gute Nachricht
keiner muss befürchten, das etwas überschrieben wird. Wer das Attribut nicht setzt wird nichts bemerken. Wer es testen will kann dies problemlos und reversibel.
Ich gehe davon aus, dass der Operator sich die Funktion kopiert und in "myUtils" umsetzt. Hier können dann eigene ideen und Prioritäten realisert werden - komplett unabhängig. Die Funktion ist somit ein Template und eine CUL_HM passende Ideensammlung


Wer gute Ideen zu Default hat, bitte Melden.
Ich wünsche mir eine FHEM einheitliche funktion für alle FHEM typen

[noansi]

Hallo Martin,

coole Funktion. 

Diesen Beitrag solltest vielleicht besser oben anpinnen, damit er nicht in der Versenkung verschwindet.

Gruß, Ansgar.

[noansi]

Hallo Martin,

ja, gelb macht sich besser für pending. 

Gruß, Ansgar.

[noansi]

Hallo Martin,

Vorschlag zur Unterscheidung Info_Cleared:

Code Auswählen Erweitern

  if($chn eq '00'){#execute device-only entites. Prio: 1)communication 3)battery
    return '.*:'
            .( $state   =~ m/^CMDs_.*err/s                 ? 'rc_RED'
              :$state   =~ m/^CMDs_(?:process|pending)/s   ? 'rc_YELLOW'
              :ReadingsVal($name,'battery','ok') ne 'ok'   ? 'measure_battery_0'
              :$state   eq 'CMDs_done'                     ? 'rc_GREEN'
              :$state   eq 'Info_Cleared'                  ? 'rc_STOP'
              :                                              'rc_RED'
             ).'.svg';
  }


Gruß, Ansgar.