Fingerübung zum uzsu-widget "uzsuTimerEntry"

[Damian]

Habe mir mal den Spaß gemacht das hier auszuprobieren:

Code Auswählen Erweitern

defmod di_timer DOIF (["$SELF:Timer"]) { ## Änderung am wiget\
  if ("$EVENT"=~/^Timer (.*)\|(.*)\|(.*)$/) {\
    fhem "setreading $SELF Timer $1|$2|$3";;\
    fhem "setreading $SELF T_day $1";;\
    fhem "setreading $SELF T_time $2";;\
    fhem "setreading $SELF T_mode $3";;\
  }\
}\
DOELSEIF (["$SELF:^T_"]) ## Änderung an Readings\
(setreading $SELF Timer [$SELF:T_day]|[$SELF:T_time]|[$SELF:T_mode])\
DOELSEIF ([[$SELF:T_time]|[$SELF:T_day]] and [?$SELF:T_mode] eq "enabled") ## Timerdefinition\
  (set bla on)\

attr di_timer do always
attr di_timer setList Timer:uzsuTimerEntry
attr di_timer state [$SELF:Timer]
attr di_timer wait 0.1
attr di_timer webCmd Timer

Ich musste es allerdings kurz mit wait verzögern, da offenbar FHEM in zweiter Rekursion das Setzen des Timers verhindert.

Edit: Ich habe etwas aufgeräumt

[the ratman]

da hab ich ja was angerichtet - jetzt kriegt er auch noch nen kindlichen spieltrieb *bg*
nö, im ernst ... das macht schon was her. und schon killed man wieder einen nicht mehr benötigten dummy mehr.

und es läuft --> guckst du anhang

[Damian]

da hab ich ja was angerichtet - jetzt kriegt er auch noch nen kindlichen spieltrieb *bg*
nö, im ernst ... das macht schon was her. und schon killed man wieder einen nicht mehr benötigten dummy mehr.

und es läuft --> guckst du anhang

und der Trick ist, dass man im Gegensatz zu einer dummy-Lösung von außen die Readings mit "setreading di_timer time/day/time_mode" setzen kann und der Timer wird korrekt gesetzt und die Ansicht aktualisiert.

[the ratman]

naja, bei mir setzt er time_mode richtig mit "setreading DOIF_Timer time_mode disabled"
aber der button und alles andere bleibt wieder auf enabled *g*

hatte das auch gleich probieren müssen und mich erst mal gefreut ...

[Damian]

naja, bei mir setzt er time_mode richtig mit "setreading DOIF_Timer time_mode disabled"
aber der button und alles andere bleibt wieder auf enabled *g*

hatte das auch gleich probieren müssen und mich erst mal gefreut ...

Das Ding hat wohl seine eigenen Zustände, an die man vermutlich nicht dran kommt. Kann man überhaupt die Auswahl-Zeiten anpassen?

Besser fände ich einzelne wiget-Elemente,  die an ein Reading gekoppelt wären z. B. eine Auswahlbox zum ankreuzen (hier für Wochentage). Ich sehe schon, ich werde mir das Thema  "DOIF-gerechte wigets" auch noch vornehmen müssen

[the ratman]

gäbs ja sogar --> https://forum.fhem.de/index.php/topic,32660.0.html
hab das meiste ausprobiert und rennt. ich glaub der radiobutton-widget wollte nicht bei mir, der rest war aber o.k.
sehr interessieren könnte dich da auch der datetime.https://forum.fhem.de/index.php/topic,35736.0.html der poppt dir im inline-modus ne datums- und zeitauswahl auf.
beispiele siehe anhang ...

allerdings würd ich mir, wenn ich du wäre und das ganze einbinden wollen würde, das ganze genauer ansehen.
ich denke, die widgets waren irgendwann mal ein schnellschuß. teilweise wirds echt unbrauchbar - siehe z.b. die regler für den rgb colorpicker. der mag nicht immer machen, was er soll.

[Damian]

ja, aber die Dinger erzeugen nach meinem Verständnis "nur" Ereignisse und lassen sich von außen wohl nicht setzen. Sinnvoll finde ich eben eine Kopplung an etwas (z. B. ein Reading), wenn man das setzt, soll der Zustand automatisch im wiget übernommen werden, ohne jedes mal sich selbst kümmern zu müssen.

Wenn ich was anpacken würde, dann müsste es universell sein und nicht nur für eine uzsu gut sein. 

[the ratman]

ich würd in dem fall eher auch an verschönern und den waf denken *g*

was du willst, is mir klar. allerdings - wie geschrieben - würd ich mir da lieber was eigenes basteln.
vielleicht findet man ja wenigstens fertigs java-zeugs dafür im netz

[Damian]

ich würd in dem fall eher auch an verschönern und den waf denken *g*

was du willst, is mir klar. allerdings - wie geschrieben - würd ich mir da lieber was eigenes basteln. ich trau den widgets nicht so wirklich.
was ich aber glaube gelesen zu haben, das die tablet-ui leute diese widgets nur in ihre verzeichnisse schieben müssen. nachdem die sicher besser gewartet wären ... vielleicht kann man die ganzen tabletui-widgets für uns mißbrauchen?

Klar, deswegen habe ich mich da immer rausgehalten, das Einzige, was ich bisher aus Not gemacht habe, ist das column-Attribut in fhemweb. Es gibt sicherlich schon zig Lösungen zu dem Thema, die alle ihre Vor- und Nachteile haben.

[the ratman]

ich wette, dir wird was einfallen.

der weg - zumindest für leute wie mich ohne programmierkenntnisse - war ja schon ab dem doif der richtige.
es ist so ne erleichterung, nicht 1oo at's, notifys und dummys verwenden zu müssen ...

[justme1968]

wie bei jedem anderen fhemweb widget wird auch bei den uzsu widgets der dargestellte status angepasst/übernommen wenn man das zugehörige reading von außen setzt. egal ob dummy oder doif.

das einzige problem mit den uzsu widgets ist der style der noch nicht in fhemweb integriert ist. d.h. man muss ihn sich selber auf der jQuery seite generieren damit es so wie im ersten post ausschaut.

[Damian]

wie bei jedem anderen fhemweb widget wird auch bei den uzsu widgets der dargestellte status angepasst/übernommen wenn man das zugehörige reading von außen setzt. egal ob dummy oder doif.

Dann stimmt da was nicht, wenn man in dem Bespiel aus dem erst Posts das Reading time_mode auf enabled setzt wird der Status des DOIF-Moduls entsprechend durch die state-Definition angepasst, aber das wiget interessiert sich nicht dafür und bleibt im alten Zustand.

[justme1968]

und im event monitor ist das zugehörige event zu sehen ?

[Damian]

und im event monitor ist das zugehörige event zu sehen ?

Code Auswählen Erweitern

Events (Filter: di_timer.*)   FHEM log   ResetCreate/Modify Device

2017-03-24 21:21:20.002 DOIF di_timer time_mode: enabled
2017-03-24 21:21:20.002 DOIF di_timer Di,Do,So|02:00|enabled

ich würde ja sagen

[justme1968]

das ist kein event auf ein reading mit namen Timer sondern für state. in setList und webCmd verwendest du aber Timer als reding und kommando namen.

wenn das reading in state landet muss auch setList und webCmd auf state konfiguriert werden. das ist allgemein in fhemweb so:

- damit die longpoll aktualisierung im frontend funktioniert muss das reading für das eine setList oder ein widgetOverride konfiguriert wird gleiche sein wie das reading des events.
- damit beim seiten aufbau das widget den aktuellen wert anzeigt muss das kommando den gleichen namen haben wie das reading

das ist bei allen widgets so. egal ob slider, dropdown, uzsu, ...

ps: ich kann das beispiel von oben nicht probieren weil ich das hier bekomme:

Code Auswählen Erweitern

reload 98_DOIF.pm
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1088.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1095.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1096.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1097.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1101.