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.
Vorgehensweise:
- Anfängerdoku lesen, u.a. zu Klammern und Semikola
- Perl lernen
- Unterprogramm in 99_myUtils schreiben
LG
pah
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
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.
Hallo rabehd,
Das devStateIcon, die rein aus einem State Wert bestehen funktionieren und habe ich auch Verstanden.
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.
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).
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
[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.)
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.
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...
Das geht nicht mit devstateicon, sondern mit stateFormat, z.B.
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.
attr E.Verb stateFormat {<Perl-Funktion>}
Der Perl-Aufruf muss halt einen von HTML erkennbaren Code zurückliefern, also z.B. SVG.
LG
pah
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?
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.
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.
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.
[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]
So konnte dank eurer Hilfe eine Lösung finden mit dem
userReadings
state {InternalVal($name, 'move', '')}
?!?
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?
Dieses Userreading sollte nicht "state" heißen...
LG
pah
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".
attr <Device> userReading move_internal:none {InternalVal($name, 'move', '')}
etabliert ein entsprechendes Reading, das auch im stateFormat verwendet werden kann.
LG
pah
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).
Das sind doch gerade meine Vorschläge von oben...
Die Frage muss also nur lauten: Warum der TE das nicht macht?
LG
pah
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.
Wie wäre es mit einem simplen
attr E.Verb stateFormat {InternalVal($name, 'move', '')}
Wie gesagt: Es braucht einen Trigger... Also einmal Schalten bitte ;) .
Super Danke Beta-User.
Nun konnte ich es auch mit dieser Variante erfolgreich Umsetzen und werde es auch dabei so belassen.
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