Reading-Abhängiges ReadOnly?

tante ju · 02 August 2016, 01:56:44

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?

n4rrOx · 02 August 2016, 08:48:06

Hi,

ich hätte zwar eine Idee, aber das wäre wohl ein dreifacher Umweg

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.

tante ju · 02 August 2016, 11:40:53

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

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.

n4rrOx · 02 August 2016, 12:47:00

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

setstate · 04 August 2016, 07:01:41

durchaus interessant und im FTUI machbar.
Ich werde das Thema im Auge behalten ...

NoMercy · 23 August 2016, 12:29:36

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

setstate · 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

Code Auswählen

data-readonly-get="myDevice:myReading"

oder wenn es das gleiche Device ist, die Kurzform

Code Auswählen

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

tante ju · 24 August 2016, 10:46:54

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

Code Auswählen Erweitern
data-readonly-get="myDevice:myReading"

oder wenn es das gleiche Device ist, die Kurzform
Code Auswählen Erweitern
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

NoMercy · 11 Oktober 2016, 11:56:17

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

setstate · 11 Oktober 2016, 12:11:49

Alle Änderungen passieren nur noch im Master-Zweig.

NoMercy · 11 Oktober 2016, 14:04:11

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:

Code Auswählen


<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

setstate · 11 Oktober 2016, 22:43:04

Sorry, das readonly wurde nicht an Thermostat vererbt, wie ich fälschlicher Weise meinte.

Habe ich jetzt erst nachgeholt

Code Auswählen

data-lock="mydevice:myreading"

NoMercy · 12 Oktober 2016, 10:20:40

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

Ulm32b · 12 Oktober 2016, 23:03:17

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

setstate · 13 Oktober 2016, 00:07:32

Button, Push, Switch, Pagebutton können das genauso. ~~Link noch nicht~~
Und Link jetzt auch ...

Code Auswählen

data-lock="device:reading"

"true" oder "1" oder "on" als Reading-Value sperren das Widget

Ulm32b · 15 Oktober 2016, 11:08:24

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

betonmoewe · 24 Oktober 2016, 18:32:25

@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

setstate · 24 Oktober 2016, 23:06:21

Dimmer versteht jetzt aus data-lock

betonmoewe · 24 Oktober 2016, 23:35:03

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

Gollum2 · 25 Oktober 2016, 12:43:52

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

Rudy · 18 November 2016, 19:41:39

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?

setstate · 18 November 2016, 23:13:48

spinner hat es nun auch bekommen: data-lock

Code Auswählen


<div data-type="spinner"
    data-device="dummy2"
    data-min="10"
    data-max="30"
    data-unit="°"
    data-lock="dummy1:STATE"
    class="valueonly">
</div>

Rudy · 19 November 2016, 13:31:59

Zitat von: setstate am 18 November 2016, 23:13:48
spinner hat es nun auch bekommen: data-lock

Code Auswählen Erweitern
<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.

Garbsen · 01 Dezember 2016, 21:17:32

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?

Ralf.E · 02 Januar 2017, 13:06:48

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 ...

Code Auswählen Erweitern
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

setstate · 02 Januar 2017, 14:56:20

Stimmt.
Ist jetzt geändert, sodass auch nur mit der Angabe des Readings funktioniert.
Danke

tante ju · 16 Juli 2017, 18:58:00

Bin auch endlich dazu gekommen, das auszuprobieren. Funktioniert super. Danke dafür.

Ulm32b · 18 Juli 2017, 23:14:11

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

Standarduser · 19 Juli 2017, 20:24:38

Hast du es schonmal mit dem classchanger Widget probiert?
https://wiki.fhem.de/wiki/FTUI_Widget_Classchanger

Ulm32b · 19 Juli 2017, 22:39:53

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:

Code Auswählen

<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