Reading-Abhängiges ReadOnly?

[tante ju]

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]

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]

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]

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]

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

[NoMercy]

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]

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"

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]

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]

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]

Alle Änderungen passieren nur noch im Master-Zweig.

[NoMercy]

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 Erweitern


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

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

Habe ich jetzt erst nachgeholt

Code Auswählen Erweitern

data-lock="mydevice:myreading"

[NoMercy]

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]

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]

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