Zusammenfassung zweier Dummys und einem DOIF

[M_I_B]

Moin Kinnaz,

gar nicht so einfach manchmal, das passende Board zu finden; hoffe das passt hier ...

Im Zusammenhang mit meinen "Übungen" wollte ich mal was zusammen bosseln (siehe unten). Derzeit setze ich mit dem DOIF bei Änderungen an "taste"den "state" von "text", um das mit anzuzeigen... Finde ich ziemlich umwegig... Nur wie geht es einfacher?
Ich vermute mal, das man den Status von "taste" direkt ohne Umweg über das DOIF im Dummy "text" darstellen kann... Meine Versuche sind leider kläglich gescheitert...

Mag wer helfen wollen?

Code Auswählen Erweitern


define text dummy
attr text alias Textfeld
attr text group Licht
attr text readingList a b
attr text room Test
attr text setList a:textFieldNL b:iconRadio,#808080,-1,ios_off_fill@red,0,ios_on_till_fill@blue,1,ios_on_fill@lime
attr text sortby 31
attr text webCmd a:b

define taste dummy
attr taste webCmd on:off
attr taste room Test

define set_taste DOIF ([taste]) (set text [taste])
attr set_taste do always


PS: Gibt es irgend einen Parameter, mit dem man die Feldbreite von textFieldNL beeinflussen kann, speziell verkleinern?

[rudolfkoenig]

Ob ein DOIF oder ein notify die Verbindung zwischen zwei Komponenten herstellt, ist eher Geschmacksache.
Sonst muesste man in dummy die Funktionalitaet einer notify einbauen. Es gibt so ein Zwitterding namens cloneDummy, ich meine aber, dass es in diesem Fall auch nicht hilft.

PS: Gibt es irgend einen Parameter, mit dem man die Feldbreite von textFieldNL beeinflussen kann, speziell verkleinern?

Nein, vermutlich geht es nur ueber eine eigene .css Datei

[M_I_B]

... hach ... zu schade (in Bezug auf beide Fragen) Wäre ja auch zu schön gewesen

Danke für die schnelle Antwort; dann baue ich davon mal ein Template, da ich dieses Konstrukt ziemlich oft benötige

[Damian]

... hach ... zu schade (in Bezug auf beide Fragen) Wäre ja auch zu schön gewesen

Danke für die schnelle Antwort; dann baue ich davon mal ein Template, da ich dieses Konstrukt ziemlich oft benötige

Welches Template meinst du?

[Beta-User]

Moin,

wieder mal die Frage, warum so viele Dummy's? Brauchst du das für die UI?

Ansonsten könntest du dir readingsGroup (funktioniert jedenfalls mit FHEMWEB super) mal ansehen, da kann man auch "kreuz und quer" andere Devices mit manipulieren. Wiki ist dazu eigentlich ganz gut, aber grade für das Setzen von Werten am Ausgangsdevice/Reading vorbei gibt es hier ein nettes Beispiel.

Vielleicht hilft das weiter...

Gruß, Beta-User

[M_I_B]

@Damian:
Ich meine die Templates, die man für solch wiederkehrende Sachen selber bauen kann, um die dann nur noch mit den benötigten Parametern aufzurufen; ist meine andere "Probieren geht über studieren" Baustelle

@Beta-User:
Danke für den Hinweis. Mit den ReadingGroups habe ich auch schon ein paar Sachen gemacht. Ich hatte nur die Hoffnung, das so was inzwischen geht und ich es nur wie üblich nicht mitbekommen habe 
Das sind gar nicht viele Dummy's... Das waren vorher bestimmt 4x so viele. Deshalb miste ich ja gerade aus... Aber ohne solche Teile komme ich nicht aus, wenn ich über die WebUI auf alles einfluss nehmen möchte. Dieses Konstrukt z.B. bietet später die Möglichkeit zu entscheiden, ob ein Leuchtmittel(Gruppe) an/aus oder auf Automatik steht, wobei die Automatik wiederum abhängig ist von Faktoren wie Umwelt, Zeit, Präsenz u.ä. Dingen... So grob umschrieben zumindest

[Damian]

Wenn du DOIF einsetzt, dann kannst du neuerdings statt Dummys DOIF_Readings nehmen. Die du sogar über uiTable mit FHEMWEB-Widgets setzen und visualisieren kannst. Diese Readings kannst du im gleichen DOIF zur Automatisation nutzen.

Der Vorteil dieser Lösung ist, dass du ein Problem inkl. Bedienung und Visualisierung innerhalb eines Moduls realisieren kannst ohne nach außen unnötige Events, wie bei Dummys, zu generieren.

P. S. DOIF unterstützt inzwischen "echte" Templates für FHEMWEB-Widgets.

[M_I_B]

... ja, da habe ich auch schon drüber gelesen, das Du da wieder was Schickes verbrochen hast Nur leider habe ich bis auf ein paar rudimentäre Dinge so gut wie nix davon kapiert  Da fehlen mir noch etliche Beispiele, die ein DAU wie ich auch nachvollziehen kann Ich bin da eher der klassische "learning by doing" Typ und kann oft auch ausgiebigen Dokumentationen selten in die Praxis umsetzen. Ich brauche bei so was immer Starthilfe in Form von Beispielen, bis ich irgend wann kapiert habe wie's geht ...

[Damian]

... ja, da habe ich auch schon drüber gelesen, das Du da wieder was Schickes verbrochen hast Nur leider habe ich bis auf ein paar rudimentäre Dinge so gut wie nix davon kapiert  Da fehlen mir noch etliche Beispiele, die ein DAU wie ich auch nachvollziehen kann Ich bin da eher der klassische "learning by doing" Typ und kann oft auch ausgiebigen Dokumentationen selten in die Praxis umsetzen. Ich brauche bei so was immer Starthilfe in Form von Beispielen, bis ich irgend wann kapiert habe wie's geht ...

Ich werde  in den Ferien ein paar typische Anwendungen (z. B. Rollladensteuerung, Heizungssteuerung ...) ins Wiki stellen. Dort werde ich auf die Bedienung/Visualisierungs-Elemente und Automatisierung innerhalb eines Moduls eingehen.

[M_I_B]

... dsa wäre natürlich super! Dann hätte ich wieder was zum Rumprobieren


BTW... Lohnt keinen neuen Fred ...

Kann es wohl sein, das dieses Widget "iconSwitch" falsch rum ist? Wenn ich ...

c:iconSwitch,off,it_television@gray,on,it_television@lime

... benutze, dann ist c=off wenn das Symbol grün ist und umgekehrt ?!? Ich dachte, die Notation ist "Zustand1, Symbol1, Zustand2, Symbol2, ..."   

[Ellert]

Das in iconSwitch angezeigte Icon zeigt den Zustand an, in den bei Betätigung geschaltet wird. Wenn die Maus über das Icon fährt, wird der aktuelle Zustand angezeigt. Das ist insbesondere dann sinnvoll, wenn mehr als 2 Zustände zyklisch geschaltet werden. Das steht auch so in der Hilfe.

Als Alternative gibt es uzsuToggle, allerdings ohne Icon.

Siehe auch https://wiki.fhem.de/wiki/FHEMWEB/Widgets

[M_I_B]

... ahhh ok, das hatte ich irgendwie nicht gerafft  Danke für die Aufklärung ...