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

Fabiango · 09 Juli 2019, 09:54:22

Hallo FHEM Freunde,

Ich brauche eure Unterstützung bei der Status Anzeige meiner Markise.
Hier beise ich mir seit Tagen die Zähne aus

Ich möchte gerne ein devStateIcon anzeigen lasssen, wenn die Markise auf die my Position fährt.
Aktuell zeigt es nur an das Sie geschlossen wäre, was nicht richtig ist.

Wie das ganze logisch funktionieren würde ist mir klar, nur eben nicht wie man es in FHEM implementieren kann.

FUNKTION:
Wenn Zeile (Internal) move = stop und Zeile (Reading) state = open dann soll einer neuer Status/Icon "myPosition" raus gegeben werden.

Könnt ihr mir hier die Lösung erklären?
Für einige von euch sicher was ganz einfaches.

Danke & Gruss,
Fabian.

Prof. Dr. Peter Henning · 10 Juli 2019, 05:53:28

Vorgehensweise:
- Anfängerdoku lesen, u.a. zu Klammern und Semikola
- Perl lernen
- Unterprogramm in 99_myUtils schreiben

LG

pah

Fabiango · 10 Juli 2019, 09:45:48

Danke pah für den Hinweis.
Da ich gerne fortlaufend lerne und die Funktion zeitnahe gerne kennen lernen & umsetzen möchte wäre ich doch auf eure Hilfe aus dem Forum Dankbar.

Ich dachte es gibt eventuell eine einfachere Möglichkeit per doif oder devstateicon

rabehd · 10 Juli 2019, 09:59:36

Ich vermute nicht, dass Du ein drittes Icon möchtest. Deine Beschreibung wift schon die ersten Fragen auf, bitte auf die richtige Bezeichnung achten. Du meinst wohl devstateicon.
Lies mal was das ist. Eine Darstellung anhand des state-Wertes oder einem Funktionsergebnis.

Definiere/beschreibe mal die verschiedenen Zustände die Du sehen willst. Findest Du die in state? Wenn sollte devstateicon einfach zu definieren sein. Sonst den Hinweis von pah beachten.

Fabiango · 10 Juli 2019, 10:10:45

Hallo rabehd,

Das devStateIcon, die rein aus einem State Wert bestehen funktionieren und habe ich auch Verstanden.

Code Auswählen

closed:awning open:awning.off eingefahren:awning.off ausgefahren:awning

Mir geht es um ein devStateIcon Zustand der aus dem Move-Wert und State-Wert besteht.

Beta-User · 10 Juli 2019, 10:19:32

Das ist in vielerlei Hinsicht weiter sehr nebulös:

Soll es jetzt immer nur ein einziges Icon geben, das für den jeweils aktuellen Zustand steht, oder soll es unter bestimmten Umständen zwei oder mehr Icons geben (beides geht!)?

Dann wissen deine potentiellen Helfer nicht, was der jeweilige Zustand ist. Ein Screenshot ist dafür ungeeignet. Ein "list" (Anfängerdoku, wie bereits von pah indirekt angedeutet...) wird benötigt (bzw. ggf. mehrere), die das wiedergeben, welchen Zustand das Device in dem jeweiligen Stadium hat, das du visualisieren willst (ggf. ergänzt um Events)...

Wenn du den Zustand (unter bestimmten Bedingungen) aus zwei Readings ableiten willst, brauchst du ein Perl-devStateIcon (oder ein Perl-stateFormat). Dass es sowas gibt, steht wieder in der Doku (insbesondere zu dem von dir selbst ins Spiel gebrachten devStateIcon).

Prof. Dr. Peter Henning · 10 Juli 2019, 10:32:55

In den SmartHome Hacks und im Wiki - https://wiki.fhem.de/wiki/Digitaler_Bilderrahmen_mit_lcd4linux#Erzeugen_von_Balkendiagrammen - habe ich schon vor langer Zeit einen Weg beschrieben, wie man ein selbstdefiniertes Widget, das dynamische Werte anzeigt, als devstateicon einbindet. Geht mit einem externen Skript, welches das entsprechende Bild aus den Readings generiert.

Eine komfortable Erweiterung dazu steht im derzeit in Druck befindlichen Buch, siehe Bild.
Dabei wird das Bild als SVG dynamisch durch eine Perl-Funktion erzeugt. Auch Animationen sind damit möglich.

LG

pah

Beta-User · 10 Juli 2019, 10:44:49

[OT] Hast du das mit dem SVG-Widget eigentlich aus stateFormat raus in devStateIcon verschoben?
(Es gab da jemanden mit Screenreader, der die Grafikinfo in STATE nicht lustig fand...)
[/OT]
@TE: vielleicht hilft dir das 2. Beispiel hier direkter: https://wiki.fhem.de/wiki/DeviceOverview_anpassen#Perl-Variante(Das kann man so ähnlich auch in stateFormat machen und dann "einfaches" devStateIcon mit einer weiteren regex nutzen.)

Fabiango · 10 Juli 2019, 10:51:07

Zitat von: Beta-User am 10 Juli 2019, 10:19:32
Das ist in vielerlei Hinsicht weiter sehr nebulös:

Soll es jetzt immer nur ein einziges Icon geben, das für den jeweils aktuellen Zustand steht, oder soll es unter bestimmten Umständen zwei oder mehr Icons geben (beides geht!)?

Dann wissen deine potentiellen Helfer nicht, was der jeweilige Zustand ist. Ein Screenshot ist dafür ungeeignet. Ein "list" (Anfängerdoku, wie bereits von pah indirekt angedeutet...) wird benötigt (bzw. ggf. mehrere), die das wiedergeben, welchen Zustand das Device in dem jeweiligen Stadium hat, das du visualisieren willst (ggf. ergänzt um Events)...

Wenn du den Zustand (unter bestimmten Bedingungen) aus zwei Readings ableiten willst, brauchst du ein Perl-devStateIcon (oder ein Perl-stateFormat). Dass es sowas gibt, steht wieder in der Doku (insbesondere zu dem von dir selbst ins Spiel gebrachten devStateIcon).

Hallo Beta-User,

zu deinen Fragen die uns sicher weiter bringen.
1. Es soll immer nur ein einziges Icon angezeigt werden das zudem statisch ist. (keine dynamischen Anzeige)
2. Die List bzw. Zustand werde ich am Ende anfügen.
3. So wie es aussieht geht es mir schon um ein devStateIcon mit einerPerl Funktion, die ich jedoch alleine nicht hinbekomme.

List:

Internals:
ADDRESS 000001
DEF 000001 A2 04B2
FUUID 5d03de47-f33f-b42a-fc5a-b8e05f1e368191b0
IODev CUL_0
NAME Markise
NR 168
STATE eingefahren
TYPE SOMFY
move off
CODE:
1 000001
READINGS:
2019-07-09 16:12:37 enc_key A2
2019-07-09 16:12:37 exact 0
2019-07-09 16:12:37 position 0
2019-07-09 16:12:37 rolling_code 04B2
2019-07-09 16:12:37 state open
Attributes:
IODev CUL_0
alias Markise
devStateIcon closed:awning open:awning.off eingefahren:awning.off ausgefahren:awning
eventMap on:raus
off:rein
open:eingefahren
closed:ausgefahren
fp_Grundriss 55,210,1,
group Markise
model somfyshutter
room Wohnzimmer
sortby 1
webCmd raus:stop:rein

Zustand Markise eingefahren: (Hier ist das Icon OK)
STATE = eingefahren
TYPE = SOMFY
move = off
devStateIcon = eingefahren:awning.off

Zustand Markise ausgefahren: (Hier ist das Icon OK)
STATE = ausgefahren
TYPE = SOMFY
move = on
devStateIcon = ausgefahren:awning

Zustand Markise auf myPosition: (Hier möchte ich ein anderes Bild / ;Markise auf 50%)
STATE = eingefahren
TYPE = SOMFY
move = stop
devStateIcon =

? (diesen Perl Code dazu benötige ich)

Falls noch weitere Angaben nötig sind bitte melden. Bin hier wirklich noch Anfänger.

Beta-User · 10 Juli 2019, 10:59:28

Das ist zwar kein list (gibt mal "help list" in die Kommandozeile ein!), aber wenn es eigentlich so ist, dass einfach nur der Wert des Internals "move" den richtigen Zustand hergibt, dann würde ich schlicht:

- via stateFormat-Perl den Wert des Internals in STATE bringen (siehe commandref zu InternalVal()

),
- devStateIcon "ganz normal" verwenden (brauchst du eventMap?), und
- ggf. dann das devStateIcon mit allen drei Argumenten ("stop:<halbesIcon>:off") verwenden,
- "notfalls" noch iVm. webCmd und cmdIcon...

Aber jetzt mußt du die Arbeit wirklich vollends selbst zu Ende bringen und die Stichworte nachlesen...

Prof. Dr. Peter Henning · 10 Juli 2019, 11:54:59

Das geht nicht mit devstateicon, sondern mit stateFormat, z.B.

Code Auswählen

attr E.Verb stateFormat <embed src='fhem/SVGX_widget?type=bar&subtype=pink&size=200x120&p1=energy&s1=35.0 kWh&p2=power&s2=1 kW&p3=EV'/>

im Falle der o.a. Widgets, oder als ingesamter Perl-Aufruf.

Code Auswählen

attr E.Verb stateFormat {<Perl-Funktion>}
Der Perl-Aufruf muss halt einen von HTML erkennbaren Code zurückliefern, also z.B. SVG.

LG

pah

Fabiango · 10 Juli 2019, 11:57:56

Zitat von: Beta-User am 10 Juli 2019, 10:59:28
Das ist zwar kein list (gibt mal "help list" in die Kommandozeile ein!), aber wenn es eigentlich so ist, dass einfach nur der Wert des Internals "move" den richtigen Zustand hergibt, dann würde ich schlicht:

- via stateFormat-Perl den Wert des Internals in STATE bringen (siehe commandref zu InternalVal() ),
- devStateIcon "ganz normal" verwenden (brauchst du eventMap?), und
- ggf. dann das devStateIcon mit allen drei Argumenten ("stop:<halbesIcon>:off") verwenden,
- "notfalls" noch iVm. webCmd und cmdIcon...

Aber jetzt mußt du die Arbeit wirklich vollends selbst zu Ende bringen und die Stichworte nachlesen...

Für das sogenannte "halbesIcon" ist nicht nur der Wert des Internals "move" zuständig sondern eine kombination aus Internals "move" und Readings "state"
Somit muss es sicher anders gelöst werden wie bei deinem Vorschlag?

Beta-User · 10 Juli 2019, 12:10:59

Zitat von: DJCrazy am 10 Juli 2019, 11:57:56
Für das sogenannte "halbesIcon" ist nicht nur der Wert des Internals "move" zuständig sondern eine kombination aus Internals "move" und Readings "state"
Somit muss es sicher anders gelöst werden wie bei deinem Vorschlag?

Ohne lists kann man diese Frage nicht beantworten..., wie oft willst du diese Antwort haben?

Und: Klar geht das auch mit einer Kombination, wird dann aber eben komplexer mit ein paar (Perl-) if (ggf. mit ... elsif ... else).

Btw.: Ohne dass ich Code hier sehe, werde ich nichts mehr dazu schreiben.

@pah:
Dass der Ursprungscode nur mit stateFormat konzipiert war, ist jedenfalls mir klar. Das "Problem" dabei ist, dass er eben Grafikdaten zurückliefert, was bei usern mit Screenreadern Kopfschmerzen bereitet (und von zentralen Entwicklern afaik als Mißbrauch des stateFormat angesehen wird). Das Argument aus dem Thread, dass die Größenvorgabe da irgendwie auch rein muß, und das in devStateIcon schwierig ist oder evtl. gar nicht geht, ist bekannt...
Ich muß aber zugeben, das nicht weiter vertieft zu haben und nur das Problem zu kennen, aber weder das Verhalten, wenn man die embed-Anweisung in devStateIcon packt, noch einen Ansatz zur Vermeidung des unerwünschten STATE-Inhalts liefern zu können.

rabehd · 10 Juli 2019, 12:27:43

ZitatFür das sogenannte "halbesIcon" ist nicht nur der Wert des Internals "move" zuständig sondern eine kombination aus Internals "move" und Readings "state"

Wirklich?
Du gibt an das Du 3 verschiedene Ikon haben möchtest.
Diese unterscheiden sich nach Deinen Angaben jeweils im Internal "move" (off, on, stop).
Also fehlen hier Infos oder der Vorschlag von Beta-User passt.

Prof. Dr. Peter Henning · 10 Juli 2019, 13:05:39

Zitatwas bei usern mit Screenreadern Kopfschmerzen bereitet

Pardon, das ist eines meiner langjährigen Forschungsgebiete, darum kann ich klar sagen: Unsinn.

Erstens wird ja niemand gezwungen, beliebigen HTML-Code in das Attribut stateFormat zu schreiben.

Zweitens kann man selbstverständlich in den HTML-Code auch die Accessability-Attribute schreiben, die das W3C vorsieht - damit kann jeder Screenreader mit den Daten umgehen. Siehe dazu https://www.w3.org/WAI/fundamentals/accessibility-principles/

LG

pah

P.S.: Auch das Missbrauchsargument halte ich für falsch. Die betreffenden "zentralen Entwickler" sind m.E. ein wenig zu sehr in veralteten textuellen Denkweisen verhaftet - das ist eben nicht mehr Stand der Technik.