Dummy für FTUI Thermostat Widget und verzögerte Input Auswertung

[thinman]

Hallo Allerseits,

ich habe mein Heizungssteuerung bisher mit einfachen TabletUI Widgets gelöst. Jetzt würde ich gerne etwas mehr machen (Anwesenheit, Urlaub, etc.)
Dafür würde ich gern die Thermostat FTUI Widget vom echten Hardware Device abkoppeln. Allerdings weiß ich nicht wie.
Ich brauche drei Werte (Temperatur, ValveStellung und DesiredTemperatur). Der Widget kann aber nur für die Temperatur ein andere Device annehmen.
Ein Dummy kann wiederum nur ein Wert haben. Gibt es eine Möglichkeit ein Dummy Device mit 3 Werten zu haben?

Zweite Frage: wie kann ich ein Zeitverzögere Input realisieren?
Wenn ich am Thermostat Widget was einstelle, kann es passieren, dass ich nicht auf Anhieb das richtige Wert treffe.
Dann werden nacheinander alle "versuche" an die MAX Thermostat gesendet und das geht schnell auf die Kosten von CUL Kredite.
Auch wenn ich DesiredTemperature mit ein Notify "auslagere" wird dies trotzdem nach jeden Input getriggert.
Kann ich irgendwie ein Delay einbauen um die Auswertung generell 1-2 Sekunden zu verzögern bis der Anwender das richtige Wert getroffen hat?

Danke schon mal für Ratschläge.
Gruß
Steve

[viegener]

Ein Dummy kann wiederum nur ein Wert haben. Gibt es eine Möglichkeit ein Dummy Device mit 3 Werten zu haben?

Ja, schau mal nach readingList im Device dummy in der Commandref

[viegener]

Zweite Frage: wie kann ich ein Zeitverzögere Input realisieren?
Wenn ich am Thermostat Widget was einstelle, kann es passieren, dass ich nicht auf Anhieb das richtige Wert treffe.
Dann werden nacheinander alle "versuche" an die MAX Thermostat gesendet und das geht schnell auf die Kosten von CUL Kredite.
Auch wenn ich DesiredTemperature mit ein Notify "auslagere" wird dies trotzdem nach jeden Input getriggert.
Kann ich irgendwie ein Delay einbauen um die Auswertung generell 1-2 Sekunden zu verzögern bis der Anwender das richtige Wert getroffen hat?

Ein delay im eigentlichen Sinne auf dem tablet ui kenne ich nicht, aber wenn Du schon einen Dummy hast, kannst Du doch das Widget nur Änderungen an dem Dummy vornehmen lassen und noch einen zusätzlichen Knopf im UI einbauen, der dann die Änderungen in den MAX-Thermostat übernimmt.
Also

- Änderungen einstellen mit dem Thermostat widget - wobei dieses an den Dummy gebunden ist
- Pushbutton, der auf ein notify triggert
- Das notify übernimmt die Readings aus dem dummy und macht ein set auf den MAX-Device

[thinman]

Vielen Dank!

Zu Frage 2: Ein Commit Knopf ist ein gutes Workaround, wenn auch nicht so elegant wie ein Delay. Kann ich aber damit leben.
Zu Frage 1:
Wenn ich in readingList Variablen definiere, z.B:

Code Auswählen Erweitern

define DrehThermo dummy
attr DrehThermo readingList valveposition desiredTemperature temperature
wie muss ein Notify aussehen, um die andere Wete zu setzen und diese nach dem Notify auch im Widget erscheinen zu lassen?

Code Auswählen Erweitern

define Tempi_Notify notify DrehTermo:desiredTemperature.* set DrehTermo:temperature $EVTPART1
funktioniert nicht.
DrehTermo:temperature wird nicht geändert und auch das Widget wird nicht geupdatet.

Sorry wenn ich elementare Sachen nachfrage aber das Programmieren in FHEM erschließt mich noch nicht so wirklich.
(Früher habe kleinere Programme in C geschrieben daher ist Programmierung nicht ganz unbekannt für mich.
Die Kombination vom FHEM und Perl kapiert aber mein Kopf noch nicht. Wahrscheinlich bin zu alt geworden...  )

[viegener]

Wenn Du am dummy per readingList zusätzliche Readings definiert hast, wird der Set Befehl z.B. wie folgt ausgelöst:

Code Auswählen Erweitern

set DrehTermo temperature 23

Ich verstehe aber Deinen notfiy nicht
Wenn die desiredTemperature am dummy gesetzt wird, willst Du doch die Temperatur am MAX-Device und nicht am Dummy ändern. Mit Deinem notify kopierst Du nur jede Änderung von desiredTemperature nochmals nach temperature???

[thinman]

Ich verstehe aber Deinen notfiy nicht
Wenn die desiredTemperature am dummy gesetzt wird, willst Du doch die Temperatur am MAX-Device und nicht am Dummy ändern. Mit Deinem notify kopierst Du nur jede Änderung von desiredTemperature nochmals nach temperature???

Ich experimentiere nicht auf mein Live System. Ich will erst verstehen, was ich mache und dann ans umsetzen des tatsächlichen Steuerung gehen.
Bei MAX geht der CUL Kredit sehr schnell weg wenn man fehlerhafte Sachen probiert.

Danke, ich weiß nicht warum ich ein Doppelpunkt dazwischen geklemmt habe. Meine anderen Notifys funktionieren ja.
Es funktioniert allerdings nur in FHEM. Im TabletUi werden die Werte Temperatur und Valveposition (welche ich auch mit Notify gesetzt habe) erst im Widget dargestellt wenn ich ein Page Reload mache.
Gibt es ein Möglichkeit eine Widget Update nach der Auslösung der Notify zu forcieren?

[viegener]

Falscher Ansatz: Ein update zu forcieren hilft nicht gegen Dein Problem

Also wenn das Reading upgedated wird per notify soltle ein Event entstehen -> Siehe Event monitor

Wenn Du von Hand die Änderung des Readings macht sollte das tablet ui widget sich updaten (zumindest wenn polling etc richtig eingestellt sind)

Beides überprüfen und gegebenenfalls korrigieren

Achso: Ich verstehe trotzdem nicht was Du mit dem notify bezweckst - wenn Du simulieren willst, solltest Du einen Dummy für den MAX-Thermostat anlegen und nicht denselben Dummy nochmal verwenden.

[thinman]

Ob ich in die selber Dummy schreibe oder in eine andere müsste im Prinzip ja egal sein. Mir geht es ums Prinzip des Widget Aktualisierung.
Ich habe aber ein neue Dummy gemacht und schreibe mit der Notify die Werte da rein.

Code Auswählen Erweitern

define DrehThermo dummy
attr DrehThermo readingList valveposition desiredTemperature temperature

define Maxi dummy
attr Maxi readingList desiredTemperature valveposition temperature
attr Maxi setList valveposition:10 temperature:22

define Tempi_Notify notify DrehThermo:desiredTemperature.* set Maxi temperature $EVTPART1
define Tempi_Notify2 notify DrehThermo:desiredTemperature.* set Maxi valveposition $EVTPART1
define Tempi_Notify3 notify DrehThermo:desiredTemperature.* set Maxi desiredTemperature $EVTPART1

Ergebnis das selbe:
- Event Monitor schreibt nur mit extreme (Minuten) Verzögerung obwohl (attr global updateInBackground 1) ist gesetzt.
- Longpoll ist für mein WEB Instanz gesetzt (attr WEB longpoll 1)
- Der Notify wird definitiv ausgeführt weil nach einen Page Reload stehen im neuen Dummy/Widget die richtige Werte.
- Ohne Page Reload updatet das Widget nicht.

als Noob bin ich total ratlos und je länger ich die verschiedene Beispiele und CommandRefs lese, umso verwirrter bin ich.
Eigentlich musste es funktionieren, tut es aber nicht.

[thinman]

Hier ist noch das LOG Eintrag:

Code Auswählen Erweitern

2017.09.17 21:21:28 4: Connection accepted from WEB_192.168.100.80_54757
2017.09.17 21:21:28 4: WEB_192.168.100.80_54757 GET /fhem/?cmd=set+DrehTermo+desiredTemperature+32&XHR=1&_=1505675307554; BUFLEN:0
2017.09.17 21:21:28 5: Cmd: >set DrehTermo desiredTemperature 32<
2017.09.17 21:21:28 5: Starting notify loop for DrehTermo, 1 event(s), first is desiredTemperature: 32
2017.09.17 21:21:28 5: Triggering Tempi_Notify
2017.09.17 21:21:28 4: Tempi_Notify exec set Maxi temperature $EVTPART1
2017.09.17 21:21:28 5: Cmd: >set Maxi temperature $EVTPART1<
2017.09.17 21:21:28 5: Starting notify loop for Maxi, 1 event(s), first is temperature: 32
2017.09.17 21:21:28 5: End notify loop for Maxi
2017.09.17 21:21:28 5: Triggering Tempi_Notify2
2017.09.17 21:21:28 4: Tempi_Notify2 exec set Maxi valveposition $EVTPART1
2017.09.17 21:21:28 5: Cmd: >set Maxi valveposition $EVTPART1<
2017.09.17 21:21:28 5: Starting notify loop for Maxi, 1 event(s), first is valveposition: 32
2017.09.17 21:21:28 5: End notify loop for Maxi
2017.09.17 21:21:28 5: Triggering Tempi_Notify3
2017.09.17 21:21:28 4: Tempi_Notify3 exec set Maxi desiredTemperature $EVTPART1
2017.09.17 21:21:28 5: Cmd: >set Maxi desiredTemperature $EVTPART1<
2017.09.17 21:21:28 5: Starting notify loop for Maxi, 1 event(s), first is desiredTemperature: 32
2017.09.17 21:21:28 5: End notify loop for Maxi
2017.09.17 21:21:28 5: End notify loop for DrehTermo
2017.09.17 21:21:28 4: WEB: /fhem/?cmd=set+DrehTermo+desiredTemperature+32&XHR=1&_=1505675307554 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/

Scheint zu tun was es soll aber ohne update im TabletUI.

[viegener]

Ergebnis das selbe:
- Event Monitor schreibt nur mit extreme (Minuten) Verzögerung obwohl (attr global updateInBackground 1) ist gesetzt.

Wenn der Event Monitor erst Minuten später die Änderung bekommt, dann ist etwas faul! Ausserdem kann das tablet UI sie auch nicht früher bekommen. Die Änderungen im tablet werden auch über die Events gesteuert.

Die Events in FHEM sind zentral für Interaktionen zwischen devices (notify etc) und auch die Oberflächen (tablet UI und webUI) laufen darüber um Veränderungen anzuzeigen

[thinman]

Was ich aber nicht verstehe:
Ändere ich den Wert im TabletUI Widget, ändert sich im FHEM sofort und ohne Verzögerung der Wert für die entsprechende Dummy.
Mache ich ein Page Reload im TabletUI Fenster, ändert sich das Widget auch sofort.
Also, wird der Notify sofort ausgeführt. Dennoch sehe ich im Event Monitor erst Minuten später die Meldung und dennoch erfolgt ohne Reload kein Update der FTUI Widgets.

Das was faul ist, ist mir klar. Aber was? Wie finde ich der Grund für dieses Verhalten?

Wenn ich Zeit habe, räume ich das fhem.cfg komplett leer und schreibe nur mein Test Dummies rein.
Mal sehen ob dieses Delay dann trotzdem bleibt.

[thinman]

KORREKTUR!
Windows ist sch..e 

Die Forum Einträge bezüglich Event Monitor haben mich stutzig gemacht und hab auf mein Android Smartphone eine Seite mit Event Monitor und eine mit mein TabletUI Interface aufgemacht.
Hier funktioniert alles wie es soll: Widget Update kommt sofort und auch der Event Monitor listet alles sofort auf.

Offensichtlich kann man ein Windoof PC mittlerweile zu nichts mehr zu gebrauchen. 
Es geht also alles, und ich kann zum tatsächlichen System-umbauen übergehen.
Sorry, dass ich Eure Zeit damit geraubt habe und danke für die Hilfe!