Modul weekprofile + FHEMWEB widget

[onurbi]

Schau mal was du in Device WEB (oder dem entsprechenden Web-Frontend) im Attribut longpoll hast. Teste mal 1 oder websocket ..

longpoll hatte den Wert 0. Der Versuch es auf 1 zu stellen, macht eigentlich keinen Sinn. Der Wert websocket im Grunde ebenso, hat aber, getestet, keine Verbesserungswirkung.
Die Zeit habe ich nochmal gestoppt: 50s. Mit dem Chrome und dem Edge ist es genauso.

Verstehe, ein refresh ist in der Software keiner drin. Dann ist das ist ja echt eine harte Nuss.

Wenn jemand noch eine Idee hat, was ich prüfen könnte...

[kadettilac89]

Die Frage ob es lohnt hier lange zu analysieren. Die Profile erstellt man einmalig und dann ändert man ggf. mal einen Wert. Workaround immer wieder speichern.

Du kannst mal in der Entwicklerkonsole schauen ob du da irgend welche Daten siehst die gesendet oder empfangen werden. Konsole in Chrome <F12> Taste, wenn alle 50 Sekunden der Refresh gemacht wird siehst du das ggf. da.

Hast du das auch auf dem Handy, anderen PC? Addon installiert wie Autorefresh oder sowas?

[Risiko]

An der Stelle ein großes Danke an Risiko für's Einbauen der Unterstützung von MQTT2_DEVICE als neuen Client für weekprofile!

Hallo Beta-User,

danke für die tolle Zuarbeit. Musste ja nicht viel machen.
Macht es Sinn, jetzt bereits was dazu im wiki zu schreiben?
Vielleicht hole ich mir ja auch mal so ein Teil.

[onurbi]

Die Profile erstellt man einmalig und dann ändert man ggf. mal einen Wert. Workaround immer wieder speichern.

Eine Katastrophe ist nicht. Wie es halt so ist, nach Wochen kommt eine Anpassung, man denkt nicht dran und ist gefrustet...

Du kannst mal in der Entwicklerkonsole schauen

Gute Idee. In der JS-Konsole sieht man den Refresh (refresh.log)

Auch im Wireshark ist es gut verfolgbar (2020-12-16 23_02_51-_WLAN.png) alle 44s.

Mir fällt auf, dass es POSTs sind. Bei einem manuellen Refresh mit F5 ist es ein GET und die Seite zeigt wieder die Zusammenfassung des Weekprofiles und ich verlasse damit den Editmode.
Der Autorefresh (fühlt sich echt wie einer an, ist aber kein solches Addon installiert)

Hast du das auch auf dem Handy, anderen PC? Addon installiert wie Autorefresh oder sowas?

Ja, tritt auch auf dem Android Handy auf (Chrome).

[Beta-User]

Vielleicht hole ich mir ja auch mal so ein Teil.

Eine Hardware-Empfehlung kann ich dazu nicht wirklich aussprechen, die firmware scheint irgendwie noch nicht ausgereift zu sein, und der Code auf der FHEM-Seite, was Profile betrifft, ist es möglicherweise auch noch nicht...
Und ob die Funktionsweise der Profile (auf den Thermostaten) an sich schon klar ist, da bin ich mir auch noch nicht wirklich sicher .

(Falls es jemanden interessiert, es geht um diese Thermostate: https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html, eingebunden via zigbee2mqtt/MQTT2_DEVICE, Thread dazu: https://forum.fhem.de/index.php/topic,116535.0.html.

Tendenziell halte ich das Profilkonzept 5+2/6+1/7 (bzw. das, was ich meine, was es bedeuten soll) für etwas beschränkt, aber der Markt für Thermostate, die eigenständig nach Profil fahren können, ist andererseits eben auch ziemlich beschränkt.
Die neueren Fibaro "knobs" können das (ZWave), und (afaik) das eqiva-BTLE-Modell. Beides aber noch "nicht wirklich" von FHEM unterstützt (bei ZWave gibt es die Option, Wochenprofile zu versenden, aber effektiv scheint das kaum einer zu nutzen und das Format scheint "komisch" zu sein).

Tendenziell wäre es aber m.E. wünschenswert, zumindest auch noch die Interaktion mit ZWave hinzubekommen (für die Hardware, die die Class CLIMATE_CONTROL_SCHEDULE kennt). Da muss man aber vorher einen Referenzwert ermitteln und dann einzelne Tage rausschicken. Sollte aber an sich auch nicht das Hexenwerk sein, das in weekprofile direkt zu integrieren; bin mal gespannt, wann sich der erste findet, der passende Hardware+Interesse mitbringt...

Eine Sache ist mir jetzt allerdings aufgefallen:
Zumindest das ZigBee-Thermostat "denkt" scheinbar nicht in Tagesabläufen (also "von bis"), sondern nur in Schaltzeitpunkten, es gilt eben auch über Nacht/00:00 Uhr hinaus das, was am Vorabend zuletzt gültig war. Vermutlich kann man auch einen 00:00-Uhr-Schaltzeitpunkt setzen, aber man "verbrät" damit dann eben speichertechnisch gesehen auch einen Datenpunkt. Das ist dann nicht optimal, wenn nur eine gewisse Zahl von Schaltzeitpunkten übermittelt/gespeichert werden können.
Eventuell wäre es für manche Implementierungen hilfreich, die JSON-Daten hierzu passend aufbereitet (und ohne "ab 00:00 Uhr") abfragen zu können, denn diese Transformation ist etwas tricky und wäre ggf. im Detail auch noch zu diskutieren...

Etwas OT @all: Es gibt für ebus@MQTT2_DEVICE eine m.E. nicht ganz optimale Lösung, was on/off-Profile angeht (k.A., was das eigentliche Zielgerät angeht, das ganze wird über eBus_Calormatic_TimeProgramm konfiguriert, und am Ende wir eigentlich nur für jeden Wochentag eine Anweisung wie diese abgesetzt: "set ebusMQTT publish ebusd/BASE_DEV/hcTimer.Wednesday/set 07:00;;10:00;;12:00;;16:30;;18:00;;22:00;;Mo-Fr").
Also falls da jemand noch der Überzeugung ist, dass das mit weekprofile einfacher zu verwalten ginge: einfach im ebus-attrTemplate-Thread einen Link zu einem neuen Thread in MQTT aufmachen, dann entwickeln wir da was .

Macht es Sinn, jetzt bereits was dazu im wiki zu schreiben?

Bin grade erst mal noch dabei, jemanden zu coachen, der dann den WDT-Teil bzw. auch das mit der Topic-Benutzung etwas im Wiki ausbaut.
Für das, was jetzt für den Thermostaten im svn ist, fehlt noch eine commandref, und wenn die dann steht und die Tests von den beiden, die diesen Thermostaten haben passen, dann kommt es in den "MQTT-workshop", erst danach wäre dann ein (vermutlich separater) Artikel im Wiki sinnvoll, auf den man dann von allen Seiten her verlinken würde? Oder wie siehst du das?

[ToKa]

Hallo Risiko,

dank der Arbeit von Beta-User lässt sich ja nun über WDT auch weekprofile für meine Z-Wave Thermostate nutzen. Beta-User hat nun in einer Testversion WDT_eventMap eingeführt, so dass man auch andere Werte statt Temperaturen an die Thermostate senden kann. Also z.B. "eco", "comfort" oder bei den Z-Wave Thermostaten von Eurotronic "tmHeating" und "tmEnergySaveHeating".

Ich würde das gerne nutzen in Kombination mit weekprofile und dem widget. Soweit ich es versucht und verstanden habe, kann ich per json auch nicht numerische Werte z.B. "eco" in einem weekprofile anstelle einer Temperatur eintragen. Das wird dann sogar sauber im FHEMWEB Widget angezeigt.

Wäre es denn möglich, anstelle der Dropdowns mit den Temperaturen auch eine vordefinierte Auswahl an Texten anzuzeigen und auszuwählen? Vielleicht gesteuert über ein Attribut zum Wechseln zwischen Temperaturen und "individuellen" Werten, wobei diese ja vielleicht über ein weiteres Attribut kommasepariert definiert werden können.

Bin auf Deine Antwort gespannt...

Beste Grüße
Torsten

[Beta-User]

Ähm, nur zur Klarstellung: Anlass für das mapping in WDT (siehe diesen Beitrag/Thread) war eher die Überlegung, dass weekprofile typischerweise Temperaturen liefert, es aber manche Hardware gerne "anders "hätte. Man kann also mit der Testversion mAn. sehr gut einfach auf der weekpofile-Seite bei Temperaturen bleiben und "übersetzt" das dann im WDT über das Mapping in "andere" Anweisungen, so dass die Profile in weekprofile gerade reine Temperaturlisten bleiben können .

Davon abgesehen kann ich mir vorstellen, dass es einen gewissen Bedarf an weiteren "keywords" neben "on" und "off" gibt, aber das hat auch nur am Rande was mit WDT zu tun...

(OT: Hier gabe es User, die das logging von weekprofile gerne anders hätten: Max & Weekprofile Log-Einträge).

[Risiko]

(OT: Hier gabe es User, die das logging von weekprofile gerne anders hätten: Max & Weekprofile Log-Einträge).

Danke. Erledigt.

[Risiko]

Bin auf Deine Antwort gespannt...

Vorstellbar wäre es schon. Sehe es persönlich aber aktuell nicht für sinnvoll (Aufwand vs. Nutzen) und weil unterschiedliche Geräte mit unterschiedlichen Temperaturbezeichnungen arbeiten und es keinen "Standard" gibt ("tmHeating" und "tmEnergySaveHeating" zeigen das gleich auf).
Aktuell wird sogar explizit 'on' bzw 'off' durch eine entsprechende Temperatur ersetzt (siehe Attribut tempOn, tempOff).

Wegen der Geräteabhängigkeit siehe ich das Mapping (so wie auch Beta-User) eher beim Gerät als bei weekprofile.
Wenn es mehr Leute mit so einem Wünsch gibt\gäbe, würde ich ggf. nochmal darüber nachdenken (daher vorstellbar  )

Risiko

[Beta-User]

Hmm, viele unterschiedliche Gerätetypen mit "keywords" unterstützen zu wollen, sehe ich im Moment auch nicht als zielführend an, zumal man das dann wohl nicht als "Profil" an das eigentliche Endgerät senden kann.

ABER: es gibt bzgl. diverser Modi schon eine Art Standard - nämlich das, was bei Sprachsteuerung "typischerweise" gemappt wird. Da scheint sowas wie COOL, HEAT, usw. üblich zu sein (ca. etwas mehr wie eine Handvoll einschl. ON und OFF). Wenn man diese "keywords" unterstützen könnte, wäre "wenigstens" das Profil sprechend - allerdings müsste man sich dann einen würgaround finden für die Geräte, die dann "Direktadressaten" wären (CUL_HM etc.)...

Na ja, eine 100% passende Lösung für die Gesamtproblematik gibt es nun mal leider eher nicht; bei Interesse suche ich aber gerne den Link für die keywords.

[ToKa]

Hallo Ihr Beiden,

entweder ich habe mich falsch ausgedrückt oder Ihr denkt an eine eierlegende Wollmichsau 

Um es noch einmal verständlicher zu machen. Es geht mir gar nicht darum, dass weekprofile ein Mapping macht, sondern nur darum, anstelle der Temperaturen "im widget" auch alpha-Werte benutzen zu können. Hierzu war mein Vorschlag gedacht, ein Attribut in weekprofile einzuführen, das es erlaubt individuelle Werte zu benutzen. Wenn 0, dann Verhalten wie bisher, wenn 1, dann benutze die Werte aus dem zweiten Attribut z.B.: "on", "off" oder "eco", "comfort" und diese werden dann an das verknüpfte Gerät gesendet (was aktuell wahrscheinlich nur für WDT Sinn macht, aber das bleibt ja dem Anwender überlassen).

Beispiel:

• weekprofile mit dem Attribut für indiv. Werte = 1 und Atribut indiv. Werte = eco, comfort ==> im widget kann ich zwischen eco und comfort für die einzelnen Schaltzeiten wählen und dies wird entsprechend gespeichert
• weekprofile verknüpft mit WDT ==> weekprofile überträgt an den WDT die Schaltzeiten mit eco oder comfort
• WDT mapt über WDT_eventMap eco ==> tmEnergySaveHeating und comfort ==> tm Heating und sendet dies dann an mein Z-Wave Thermostat

Das ganze funktioniert jetzt schon, wenn ich weekprofile per json z.B. mit eco befülle. Schöner wäre es eben über das widget.

Beste Grüße
Torsten

[Risiko]

Hallo Torsten,

ich habe dich denke ich schon richtig verstanden.
Den Nutzen gegenüber dem Implementierungsaufwand sehe ich aktuell überhaupt nicht. Sondern eher Probleme - gerade in Verbindung mit Topics, wo man ja allgemein Profile verwaltet und an
unterschiedliche Geräte unterschiedlicher Hersteller senden kann. Jedes Gerät interpretiert die "alpha-Werte" anders oder kennt sie nicht.

und diese werden dann an das verknüpfte Gerät gesendet (was aktuell wahrscheinlich nur für WDT Sinn macht, aber das bleibt ja dem Anwender überlassen).

Ich glaube du überblickst die Komplexität nicht und siehst nur deinen Anwendungsfall (Stichwort Nutzen). Klingt für mich wie eine 1:1 Zuordnung und nur ein Hersteller.

Das ganze funktioniert jetzt schon, wenn ich weekprofile per json z.B. mit eco befülle. Schöner wäre es eben über das widget.

Das ist bis jetzt nicht gewollt und funktioniert eben nicht richtig im Zusammenhang mit der Anzeige und ggf. anderen Sachen. Also keine Garantie!

Wenn sich wie gesagt mehrere Leute dafür interessieren, sich Tester und ggf. Mitentwickler finden, wäre ich ggf. bereit über eine mögliche Umsetzung nachzudenken.

Trotzdem Danke für deine Mühe.

[ToKa]

Danke, dass Du Dir die Mühe machst, Dich damit zu beschäftigen.

Ich habe mir tempOn und tempOff mal angeschaut und das ist ja schon fast, das was ich mir vorstelle. Da Du ja für die "json"-Variante Deine Hand nicht ins Feuer legst, zur Sicherheit noch die Frage zur Funktionsweise mit tempOn / tempOff.

Wenn ich das Intervall auf mit tempOn / tempOff auf 18 - 18.5 einschränke, zeigt mir das Widget nur noch off und on zur Auswahl an. Dies wird auch gespeichert und an meinen WDT übertragen. Dort kann ich dann das mapping machen.  Oder gibt es hierbei auch Funktionseinschränkungen?

Beste Grüße
Torsten

[Risiko]

Hallo Torsten,

ja so ist es (leider) im Moment. tempOn sollte aber größer als tempOFF sein. Sollte auch eine Warnung im Log geben.
Da WDT (und MQTT2_DEVICE) das Profil holt und nicht weekprofile das Profil sendet, bekommt WDT die Keywords 'on/off zu "sehen".
Beim Senden eines Profils, wird on/off durch die Werte der Attribute ersetzt.
Ist leider aktuell inkonsistent und zwingt mich wohl doch jetzt nochmal darüber nachzudenken 
Ich werde mit Beta-User Rücksprache halten, ob weekprofile aktuell immer nur Temperaturen liefern sollte! Wäre meines Erachtens richtiger.

Risiko.

[ToKa]

Hallo Risiko,

ich habe aus einem weekprofile Device heraus mit "set send_to_device" mein WDT Device (Testversion von Beta-User) mit den Werte versorgt. Und im WDT steht nun on und off... oder habe ich da mit dem "holen" etwas falsch verstanden? Das Ergebnis bleibt das gleiche, wenn ich vom WDT aus ein "set weekprofile" aufrufe. Die Daten werden aktualisiert und on / off verwendet.

Einen kleinen "Schönheitsfehler" gibt es beim Ändern der Daten im weekprpfile widget. Dort wird immer Off angezeigt auch wenn vorher On eingestellt war und beim Speichern dann auch mit Off überschrieben. TempOff 18.0 / TempOn 18.5.

Beste Grüße
Torsten