slider mit variablen Grenzen möglich?

[GaiusMarius]

Hallo allerseits,

das Attribut

Code Auswählen Erweitern

attr <device> setList state:slider,15,1,300
ist von mir gerne genommen und funktioniert.

Allerdings sind in dieser Schreibweise die Werte (<min>, <step>, <max>) fest verdrahtet.
Kann ich dort auch Variablen verwenden?

So ein wenig in der Art von (Pseudo-Code mit Fantasie-Perl-Aufruf innerhalb {})

Code Auswählen Erweitern

attr <device> setList state:slider,{ReadingVal("<device2>", "state", 0)},1,300?

Bei mir hängen die Grenzen, in denen sich der Slider bewegen soll, von Einstellungen in anderen Devices ab und ändern sich zu Laufzeit...

Danke!

[MadMax-FHEM]

Das Attribut wird (wenn dort Perl überhaupt geht [noch nicht getestet]) einmalig beim "Anlegen" bzw. dann bei Änderung des Attributes "ausgewertet"...
...danach ist es eben "fix" der DANN "berechnete" Wert.

EDIT: ob das überhaupt mit Perl dort geht kannst du ja selber einfach mal testen. Tut ja nicht weh...

Wenn sich danach etwas am "Ausgangswert" (Beispiel device2) ändert, dann ist das dem Attribut "egal"

Was geht: notify auf den Wert: device2:state o.ä. und dann eben:

Code Auswählen Erweitern


{fhem("attr <device> setList state:slider," . ReadingsVal('<device2>','state','0') . ",1,300")}


EDIT: wobei "state" ungeschickt ist, weil das im Event normalerweise nicht "drin steht"... Kann man machen, muss man aber beim Notify dann "einstellen" (soweit mir bekannt)...

Allerdings hast du dann das "rote Fragezeichen" und wenn du dann ohne "save" ein shutdown restart machst, ist die Änderung auch wieder weg...

Besser wäre in diesem Fall vermutlich ReadingsNum

Gruß, Joachim

[GaiusMarius]

Hi MadMax-FHEM,

ich wollte direkt in meiner Anfrage nicht zu pessimistisch sein und dort schon hineinschreiben, dass ich selber glaube, dass meine Anforderung nicht funktionieren kann...

Es wäre nur möglich, wenn die Ausdrücke <min>, <step>, <max> jedesmal, wenn das Widget gezeichnet wird, ausgewertet würden. Ich nehme an, dass dies nicht der Fall ist. Aber ich bin leider nicht in der Lage, meine Vermutung im Code zu überprüfen. 

(wenn dort Perl überhaupt geht [noch nicht getestet])

Ich habe ein wenig mit Perl-Ausdrücken in geschweiften Klammern herumprobiert und keinen Erfolg gehabt. Was aber auch an meinen Fähigkeiten liegen kann...

Code Auswählen Erweitern

{fhem("attr <device> setList state:slider," . ReadingsVal('<device2>','state','0') . ",1,300")}

Ist auch mein Ausweg. Die Speicher-Aufforderung ist letztlich völlig korrekt. Es hat sich ja etwas an der Definition geändert.

Vielen Dank.

P.S.: Falls jemand doch noch eine Idee hat: Ich lasse das Thema noch ein bisschen offen...

[Beta-User]

Vermutlich kann das schon funktionieren, aber ich nehme an, dass man dazu devStateIcon-Perl braucht.
Im MQTT-Bereich gibt es einen aktuellen Thread zu sonos2mqtt, da bekommen wir den slider immerhin schon mal angezeigt, aber es ist nicht klar, wie er zu parametrieren ist. Da findest du aber auf alle Fälle die relevanten Zeilen in FHEMWEB.pm, vielleicht wirst du ja schlau draus...

(OT: es ist allg. hier nicht erwünscht, dass man Threads schließt, also bitte immer offen lassen, es sei denn, es gäbe einen triftigen Grund dazu, es anders zu machen; siehe auch den letzten der in diesem Forumbereich angepinnten Beiträge.)

[TomLee]

Im MQTT-Bereich gibt es einen aktuellen Thread zu sonos2mqtt, da bekommen wir den slider immerhin schon mal angezeigt, aber es ist nicht klar, wie er zu parametrieren ist.

Mich hat das letzte Woche ein paar Tage beschäftigt, nachdem ich irgendwann auf diesen Thread gestossen bin hatte ich genug von informid und allem was dazu gehört und hab Damian angeschrieben, mit der Frage ob er damals eine Lösung gefunden hattte, das die Widgets die Statusupdates überleben und uns da evtl.  weiter helfen kann 

Seine Antwort, kurz und bündig:

Die Statuszeile über FW_summary zu beeinflussen habe ich damals wieder verworfen, da es nicht funktionierte, wie ich es wollte...

... Über devStateIcon kann man beliebigen HMTL-Code darstellen, aber so viel ich weiß, keine FHEM-Widgets darstellen, die man bedienen kann, dafür  gibt es wiederum...

Gruß

Thomas

[Beta-User]

Danke für die Info. MMn. sollte man das nochmal gesondert und auf das slider-Widget bezogen (v.a. an Rudi als Maintainer von FHEWEB) fragen, ob und wie es ggf. geht. Insbesondere die Aussage von herrmannj ist die, dass es gehen müßte, und auch Damian hat nur geschrieben, dass es _anders_ ging, als er das wollte, und was ich danach gesehen habe, war, dass er komplett eigene Widgets gebaut hat.

Hier geht es aber doch darum, dass ein in FHEMWEB vorhandenes widget genutzt werden soll.

Auch Byte09 scheint mit Bordmitteln zufrieden gewesen zu sein.

Der verlinkte Thread hat mich also eher in der Überzeugung bestärkt, dass es geht.

[TomLee]

Hier geht es aber doch darum, dass ein in FHEMWEB vorhandenes widget genutzt werden soll.

#4

Was du siehst sind FHEMWEB-Widgets. Sie werden in  FW_detailFn bzw. in FW_summary über ...

[TomLee]

In den Bildern sehe ich den temp_ring und mein Gedanke war dabei das der ja auch per statusupdates aktualisiert wird und er eine Lõsung gefunden haben muß, er hat es aber anders gelõst, wie er sagt.

[Beta-User]

Ich bin da dem Bauchgefühl nach eher bei

Alle ?

Ich glaube das ist ein x-y Problem. "Ich möchte x machen um y zu erreichen. Wie mache ich x?" Besser wäre "was muss ich machen um y zu erreichen?"

Weil ich das aber nicht im Detail weiß und von Javascript noch weniger Ahnung habe wie von Perl, hatte ich vorher nach Lektüre des ganzen Thread empfohlen, die Frage "wie kann ich y erreichen?" nochmal konkret an der Stelle zu stellen, wo jemand kompetentes was dazu sagen kann. Man kann ja dabei auch direkt Bezug nehmen auf diese alte Diskussion (nur bitte nicht wieder direkt dort aufgreifen, das setzte m.E. auf einer anderen Ebene der Darstellung von Geräten auf). Und es bringt auch wenig, wenn wir diese Diskussion hier weiterführen .

Genau: Er wollte (vermutlich) etwas anderes, und war jedenfalls mit den Lösungsmöglichkeiten innerhalb nicht zufrieden. Genau deswegen schreibe ich ja, dass ich _glaube_, dass es mit einem einfachen (Farb? bzw- Helligkeits-) Slider gehen müßte (genau das ist doch das feature, was herrmannj bei WifiLight brauchte und Anfang 2018 dann bereits anders gelöst hätte, als mit dem "harten" Eingriff...).

[GaiusMarius]

Leider kann ich keinen inhaltlichen Beitrag leisten - nur noch einmal meinen Anwendungsfall darstellen, damit ihr nicht über meine Absichten spekulieren müsst:

Dem Homematic-Bewegungsmelder kann man mitteilen, wie lange er nach der Erkennung einer Bewegung warten soll, bevor er die nächste Bewegung meldet. Anders ausgedrückt: Obwohl sich ständig etwas bewegt, schickt der Bewegungsmelder nur in Intervallen Erkennungsmeldungen.

Möchte man nun - ganz banal - auf Grund dieser Bewegung Licht anschalten, wäre es sinnvoll, wenn die Lichteinschaltdauer nicht kürzer als die Zeit der Wiederhohlungsintervalle ist.
Sonst stehe ich - trotz Bewegung - im Dunkeln. Jedenfalls so lange, bis sich der Bewegungsmelder bequemt, eine neue Bewegungserkennung zu senden...

Hier wäre es also schön, wenn ich den Minimalwert meines Slider für die Leuchtdauer nicht unter dem Wert für die Wiederhohlungsintervalle einstellen könnte. Da das Wiederhohlungsintervall aber auch mittels eines Sliders eingestellt wird, setzt der Leuchtdauerslider auf einem Variablen Wert auf.

(Ich persönlich empfinde dies nicht als problematisch - wenn ich vergesse, die Leuchtdauer nachzuziehen, stehe ich halt kurz im Dunkeln und ändere danach die Leuchtdauer. Fertig...)

[Beta-User]

Mal abgesehen davon, dass ich gerne verstehen würde, wie das mit dem Slider funktionieren würde, hier noch ein paar Gedanken zu anderen Optionen zur Lösung des "im-Dunkel-stehens"-Problems:

Zeig doch mal das list von dem bzw. einem Event-Handler, mit dem du das Licht anschaltest. Vielleicht läßt sich das anders lösen, indem man eine max-Abfrage (Achtung: irritierenderweise mit maxVal() maxNum()) macht, und die aktuelle Mindesteinschaltdauer durch den slider _oder_ das Wiederholungsintervall (+ kurze Hysteresezeit) bestimmt. Dann stimmt zwar die Anzeige in dem Slider-Einstellungs-Dummy nicht wirklich, aber das dürfte besser vermittelbar sein, als im Dunkeln zu stehen?

Andere Variante: userReadings nutzen und den Slider zwangsweise auf einen größeren Wert stellen, wenn das Intervall des BM es nicht hergibt?

[GaiusMarius]

Vielleicht läßt sich das anders lösen,

Du kümmerst dich / ihr kümmert euch rührend um mich und dabei habe ich bereits ein schlechtes Gewissen, da mir das Thema nicht wirklich wichtig ist... 
Wie du schon geschrieben hast, gibt es viele andere Möglichkeiten der Lösung. Der Einfachheit halber starte ich jetzt mit der 'Dann-Stehe-Ich-Halt-Im-Dunkeln'-Lösung.

Ich habe nur das Problem, dass, wenn etwas nicht funktioniert, ich nicht weiß, ob es an FHEM - im Sinne von: nicht implementiert - oder mir - in Sinne von: hat davon noch keine Ahnung - liegt. Daher frage ich dann einfach nach diesem Detail.