Weiß jemand, ob und ggf wie es möglich ist, widgets abhängig von einem Reading auf readonly zu schalten?
konkret geht es um einen Party-Modus. Ich habe ein Dummy, welches bei diversen Automationen abgefragt wird. Ist es gesetzt ("Party"), dann fahren z.B. keine Rollladen und die Gartenbewässerung springt nicht an usw.
Jetzt möchte ich natürlich verhindern, daß jemand am zentralen Monitor manuell was schaltet. Der Spieltrieb ist ja durchaus stark :-)
Grundsätzlich würde so ein Reading-Abhängiges Read-Only ja durchaus Sinn machen, wenn Dinge in Abhängigkeit zueinander stehen.
Geht sowas?
Hi,
ich hätte zwar eine Idee, aber das wäre wohl ein dreifacher Umweg :o ;D
1) Der Dummy beinhaltet weiterhin den Status
2) In FTUI gibt es einen Switch, der zwischen Party, Sonstwas, UndNochWasAnderes, etc. umschalten kann
3) Ein notify / DOIF beobachtet den Dummy
4) Wenn der Dummy auf Party geschaltet wird benennt das notify / DOIF die zu sperrenden Geräte einfach um, so dass Sie zwar in FTUI vorhanden sind, aber die Anfrage "in's leere läuft"
5) Wird der Dummy wieder auf "normal" geschaltet benennt das notify / DOIF die gesperrten Geräte wieder in die urspünglichen Namen um und eine Steuerung in FTUI sollte wieder möglich sein?
Alternativ zum Umbennenen kannst dich vllt mal schlau machen, ob jedes deiner zu sperrenden Geräte das Attribut "disable" unterstützt, damit sollte es ebenfalls inaktiv sein.
Beide Wege hätten wohl aber den Nachteil das es ggf. Fehlermeldungen in FTUI / den Logs erscheinen würden.
Zitat von: n4rrOx am 02 August 2016, 08:48:06
Hi,
ich hätte zwar eine Idee, aber das wäre wohl ein dreifacher Umweg :o ;D
1) Der Dummy beinhaltet weiterhin den Status
2) In FTUI gibt es einen Switch, der zwischen Party, Sonstwas, UndNochWasAnderes, etc. umschalten kann
3) Ein notify / DOIF beobachtet den Dummy
4) Wenn der Dummy auf Party geschaltet wird benennt das notify / DOIF die zu sperrenden Geräte einfach um, so dass Sie zwar in FTUI vorhanden sind, aber die Anfrage "in's leere läuft"
5) Wird der Dummy wieder auf "normal" geschaltet benennt das notify / DOIF die gesperrten Geräte wieder in die urspünglichen Namen um und eine Steuerung in FTUI sollte wieder möglich sein?
Alternativ zum Umbennenen kannst dich vllt mal schlau machen, ob jedes deiner zu sperrenden Geräte das Attribut "disable" unterstützt, damit sollte es ebenfalls inaktiv sein.
Beide Wege hätten wohl aber den Nachteil das es ggf. Fehlermeldungen in FTUI / den Logs erscheinen würden.
Interessanter Ansatz. Allerdings soll FHEM ja weiterlaufen. Wenn ich devices umbenenne oder disable, dann funktionieren auch Automatisierungen nicht mehr, die davon abhängen. Ich könnte jetzt natürlich reihenweise Dummies aufsetzen, die von FTUI gesteuert werden. Aber das replizieren zwischen den Wirkinterfaces und den Dummies wird es vermutlich killen.
Klar,
das war auch mein Gedanke ..... machbar wäre es auch über weiteren Programmieraufwand, dass in diesem Fall auch Automatismen weiterlaufen ..... nur wäre der Aufwand deutlich höher...
Der elegantere Weg wäre eine neue Option in FTUI, die das Auslösen in Abhängigkeit eines anderen Readings verhindern kann.
Ich glaube dazu kann aber nur setstate was sagen :S
durchaus interessant und im FTUI machbar.
Ich werde das Thema im Auge behalten ...
Hi,
ich hätte daran auch Interesse.
Ich habe einen RTR (Busch Jäger/KNX) im Einsatz, bei dem die Änderung der Komfort-Raumtemperatur über die Erhöhung des Basiswertes funktioniert. Allerdings wird nur die Komfort-Raumtemperatur erhöht. Ich nutze das Thermostat-Widget für die Temperatureinstellung-Sollwert und ein Homestatus-Widget für die verschiedenen Betriebsmodi des RTR (Komfort, Standby, Nacht und Frostschutz).
Es wäre echt cool, wenn ich das Thermostat-Widget einfach readonly schalten könnte, wenn der RTR nicht auf Betriebsmodus "Komfort" steht.
Im Moment löse ich das ganze über eine ganze Reihe von DOIFs .... Ziemliches gefriggel :(
Gruß,
Michael
War nicht so einfach ...
Aber jetzt können alle vom Knob abgeleiteten Widgets über ein FHEM Reading auf Readonly gesetzt werden
data-readonly-get="myDevice:myReading"
oder wenn es das gleiche Device ist, die Kurzform
data-readonly-get="myReading"
Im Reading muss dann 'true' stehen, damit das Widget nicht mehr bedienbar gesetzt wird. Ich werde aber noch '1' und 'on' als gültige Werte ergänzen.
Example finden man in www/tablet_eval/test-popup.html
Zitat von: setstate am 23 August 2016, 23:15:41
War nicht so einfach ...
Aber jetzt können alle vom Knob abgeleiteten Widgets über ein FHEM Reading auf Readonly gesetzt werden
data-readonly-get="myDevice:myReading"
oder wenn es das gleiche Device ist, die Kurzform
data-readonly-get="myReading"
Example finden man in www/tablet_eval/test-popup.html
Schick. Danke. Werde es kurzfristig ausprobieren, wenn es das Wetter erlaubt :)
Hallo setlist,
vielen Dank für die schnelle Umsetzung. Ein Frage:
Wenn ich das richtig verstehe erbt das Thermostat-Widget von Knob, oder? Deine Anpassungen für "ReadOnly" sind im Eval- oder Master-Branch (sorry für die Frage)? Falls sie im Eval sind, reicht es, wenn ich Knob und Thermostat aus der Eval nutze? Hintergrund: ich habe derzeit nur eine TabletUI aus dem Master-Branch am Start und würde ungern eine Eval zusätzlich aufsetzen, um readonly zu testen.
Danke und Gruß,
Michael
Alle Änderungen passieren nur noch im Master-Zweig.
Hi setstate,
danke für die Info. Könntest Du mir bitte nochmal mental "über die Straße helfen"...
Ich versuche ein Thermostat-Widget auf "readonly" zu setzen, wenn der Betriebsmodus nicht "Komfort" ist, d.h. es soll nur dann die Raumtemperatur verändert werden können. Bei allen anderen Modi (Standby, Nacht, etc.) soll keine Änderung der Raumtemperatur über das Widget möglich sein.
Es funzt aber nicht und ich bin etwas verwirrt... Mein Verständnis ist folgendes: ich kann im Thermostat-Widget (da es aus der Klasse "Knob" stammt) ein "data-readonly-get" aus einem Reading heraus auf "true" setzen. Dann sollte das funzen, oder?
Ich habe einen Dummy (RTR_Buero_Dummy), der alle von mir benötigten Readings für das Thermostat-Widget hat, u.a.:
- ValvePosition
- Widget_ReadOnly (setzen von Readonly)
- desired-temp
- measured-temp
- etc.
Das Reading "Widget_ReadOnly" setze ich über ein DOIF, abhängig wie der Betriebsmodus des RTR gesetzt ist, also "true" für alle Betriebsmodi außer "Komfort".
Mein Widget habe ich folgendermaßen gebaut:
<div class="container top-narrow">
<div data-type="thermostat"
data-device="RTR_Buero_Dummy"
data-min="7"
data-max="25"
data-step="0.5"
data-readonly-get="Widget_ReadOnly"
data-cmd="setreading"
class="">
</div>
</div>
Irgendwas habe ich wohl übersehen. Was mache ich falsch?
Danke und Gruß,
Michael
Sorry, das readonly wurde nicht an Thermostat vererbt, wie ich fälschlicher Weise meinte.
Habe ich jetzt erst nachgeholt
data-lock="mydevice:myreading"
Hi setstate,
1000 Dank für die superschnelle Umsetzung. Es funzt perfekt und spart mir bei 12 RTRs, die ich jetzt so nutzen kenn, eine ganze Menge "DOIFs" ;)
Gruß,
Michael
Höchst interessant.
Genial wäre es, wenn Readonly auch bei Button, Link und Push über ein device gesteuert werden könnte. Anwendungen gäbe es zuhauf.
Beste Grüße
Ulm32b
Button, Push, Switch, Pagebutton können das genauso. Link noch nicht
Und Link jetzt auch ...
data-lock="device:reading"
"true" oder "1" oder "on" als Reading-Value sperren das Widget
:) :)
SUPI. Dreimal Daumen hoch! Herzlichen Dank.
Die Animation der gesperrten Widgets war eine zusätzliche freudige Überraschung.
Diese Baustelle kann ich damit schließen. Andere sind noch offen ...
Ulm32b
@setstate
wäre es denn viel Aufwand, diese lock Möglichkeit auch beim Dimmer Widget einzubauen ???
Wäre echt super (da es da auch die Klasse readonly nicht gibt).
Viele Grüße
Die Betonmöwe
Dimmer versteht jetzt aus data-lock
das ging ja wirklich richtig fix...
Ein grosses DANKESCHÖN
Die Betonmöwe
d.h. nach einem Update müsste es funktionieren oder dauert es noch bis es richtig veröffentlicht ist ?
Ach, ist ja schon da ... funktioniert klasse
Zitat
data-lock="device:reading"
data-warn="device:reading"
"true" oder "1" oder "on" als Reading-Value sperren das Widget
Wäre es nicht super, wenn das READING des Devices nicht unbedingt true, 1 oder on sein müsste?
Mir schwebt sowas vor:
z.B. Warn:
data-warn-state='["Low","Critical"]'
Das wären dann die Values vom Reading, die zur Anzeige führen würden.
Setstate: Wäre sowas Umzusetzen? und ist das Sinnvoll?
Gruß
Gollum
Ich könnte das data-lock Attribut noch sehr gut bei datetimepicker und spinner gebrauchen. Wäre es möglich das dort noch zu ergänzen? :-X :)
spinner hat es nun auch bekommen: data-lock
<div data-type="spinner"
data-device="dummy2"
data-min="10"
data-max="30"
data-unit="°"
data-lock="dummy1:STATE"
class="valueonly">
</div>
Zitat von: setstate am 18 November 2016, 23:13:48
spinner hat es nun auch bekommen: data-lock
<div data-type="spinner"
data-device="dummy2"
data-min="10"
data-max="30"
data-unit="°"
data-lock="dummy1:STATE"
class="valueonly">
</div>
Super. Vielen Dank.
P.S.: Für den datetimepicker brauche ich es auch nicht mehr. Habe da ein bisschen was umgebaut.
Moin
Mache gerade meine ersten Schritte im Tabletui, Herausforderung (bisher nie html programmiert) aber spannend (copy/Paste + trial/error)
Dieses ReadOnly ist ein interessantes Detail, derzeit brauche ich es nicht konkret, baue es aber vorsichtshalber in alle Devices und Steuerungen mit ein. (Wenn ich es gleich mache, spare ich mir später Arbeit, da ich weitere Devices dann per copy/Paste anlege)
Frage / Problem: wenn ich das Reading in FHEM setze, dann wirkt sich das im Tabletui erst aus, wenn ich im Browser auf Aktualisieren gehe, genauso umgekehrt, wenn ich das Reading wieder auf 0 setze, bleibt das Devices im Tabletui gesperrt.
Wie schaffe ich es, dass sich das automatisch aktualisiert?
Zitat von: setstate am 13 Oktober 2016, 00:07:32
Button, Push, Switch, Pagebutton können das genauso. Link noch nicht
Und Link jetzt auch ...
data-lock="device:reading"
"true" oder "1" oder "on" als Reading-Value sperren das Widget
Gerade mal ausprobiert: die Doku spricht (nur) von einem
data-lock="reading" was bei mir nicht funktioniert hat. Mit
data-lock="device:reading" geht es dann...
Ralf
Stimmt.
Ist jetzt geändert, sodass auch nur mit der Angabe des Readings funktioniert.
Danke
Bin auch endlich dazu gekommen, das auszuprobieren. Funktioniert super. Danke dafür.
Beim Essen kommt der Appetit: Nachdem data-lock so viele Leute glücklich macht, möchte ich vorsichtig die Frage stellen, ob die Umsetzung folgender Option sinnvoll und machbar wäre:
Bei aktiviertem data-lock wird das Icon (Vor- und Hintergrund) auf half-transparent (oder so) gesetzt. Damit würde bereits vor einer Betätigung signalisiert, dass hier keine Aktion möglich ist. Z.B. als CSS-Klasse data-lock-indicate oder data-lock-show.
Dies mit Bordmitteln über data-colors zu realisieren, erscheint mir zumindest nicht trivial, weil die Sperre ja sowohl im on- wie im off-Zustand gesetzt werden kann und die Farben damit von 2 Readings abhängig wären.
Beste Grüße
Ulm32b
Hast du es schonmal mit dem classchanger Widget probiert?
https://wiki.fhem.de/wiki/FTUI_Widget_Classchanger
Ja, classchanger hatte ich schon versucht, ohne Erfolg. Wahrscheinlich liegt es daran, dass das data-device, welches über den switch geschaltet wird, ein anderes ist, über welches der Zustand "gesperrt" definiert wird. Classchanger kennt anscheinend nur ein data-device.
Mein funktionierender Code mit data-lock lautet:
<div data-type="switch" class="large left-space-3x" data-device="Garage_Nord_Fahrbefehl_auf" data-icon="fa-chevron-up" data-on-color="hsl(50,100%,50%)" data-lock="Garage_Nord_Fahrbefehl_auf_gesperrt:readonly" data-get-on="on" data-get-off="off"></div>
Ich könnte mir zwar vorstellen, dass man über Hilfsdummies zum Ziel kommt, aber ich schrecke davor zurück, einen zunehmend undurchsichtigen Code zu installieren.
Viele Grüße
Ulm32b