[läuft prinzipiell] ebus, MQTT2 und weekprofile

[Beta-User]

Hallo zusammen,

in den bisherigen attrTemplate ist zur Erstellung bzw. Änderung von Wochenprogrammen eine Lösung enthalten, die die ganzen Readings "einsammelt", die durch json2nameValue in der "complex"-Einstellung generiert werden, und das ganze dann auf dummy-Devices mappt und von dort aus dann wieder einsammelt und dann auf Anforderung wieder als Wochenprofil an den ebusd sendet. Wie das funktioniert, hatte Reinhart hier dargestellt.

Das funktioniert zwar, aber am Ende muss man das ganze doch irgendwie "manuell" bedienen - kurz: es entspicht mAn. nicht unbedingt dem, was möglich wäre. Meine persönliche Vision von dem ganzen Thema Heizungssteuerung sieht so aus, dass die Schaltzeiten aller Heizungsgeräte miteinander synchron laufen und zum jeweiligen Anforderungsprofil passen; und das sieht eben an einem Feiertag ggf. anders aus wie an einem Spätschichttag, normalen Arbeitstag oder bei Homeoffice, in den Ferien, etc. pp...

Hier soll daher eine Lösung entwickelt werden, die
- das Modul weekprofile nutzt, um verschiedene Profile zu verwalten, die dann auch sehr einfach gewechselt werden können; (Für die, die das nicht kennen: weekprofile kann über das hier nicht dargestellte feature "Topic" sämtliche Heizungsgeräte mit individuell zum jeweiligen Topic passenden Profilen versorgen, dazu braucht man dann am Ende nur einen einzigen, kurzen Befehl...)
- die vom ebus kommenden MQTT-Daten dann auch gleich so aufbereitet, dass man nicht die ganzen Datenpunkte irgendwie "verstreut" hat, sondern das ganze konsolidiert;
- "heute" auf "Feiertagsmodus" umstellen kann;
- die Zahl der Events und (potentiellen) Schreibvorgänge in Richtung ebus möglichst gering hält;
- ....?

Mein Problem: ich habe keinen ebus, und kann daher nur simulieren und mir denken, wie es in etwa funktionieren müsste...

Daher: keine Gewähr - weder für den Code, noch für das, was ggf. hinter dem ebusd passiert!

Den erforderlichen Code bekommt man mit

Code: [Auswählen]

{ Svn_GetFile('contrib/AttrTemplate/99_attrTmqtt2_ebus_Utils.pm', 'FHEM/99_attrTmqtt2_ebus_Utils.pm', sub(){ CommandReload(undef, '99_attrTmqtt2_ebus_Utils') }) }(bzw. nach dem morgigen update mit einem attrTemplate)

Da sind drei neue Funktionen drin:
-FHEM::aTm2u_ebus::j2nv() ist ein "wrapper" um json2nameValue, der das "_value" aus dem Readingnamen eliminiert (m.E. für alle ebus-MQTT2-Geräte interessant)
- FHEM::aTm2u_ebus::upd_day_profile() - Das konsolidiert die ganzen Einzelwerte zu Tagesprofilen (leider fehlt noch Info, wo die Art des Tagesprofils herkommt)
- FHEM::aTm2u_ebus::send_weekprofile() - holt die Profildaten aus dem weekprofile-Device und sendet sie an den ebus.
Dabei kann man eine "Grenztemperatur" festlegen, welche "on" von "off" trennen soll, im Code ist die mal auf 20° festgelegt. Steht also im weekprofile 20° oder höher, ist das eine Einschaltphase, die gilt, bis eine Temperatur kleiner 20° kommt, das ganze maximal für 3 Perioden...

Falls jemand Testen will, hier ein paar Zeilen zur Konfiguration als Beispiele...
Ein MQTT2-Device als "Heizungsgerät" (gleich für die Topic-Funktion mit "brenner" benannt):

Code: [Auswählen]

defmod MQTT2_ebusd_hc1 MQTT2_DEVICE MQTT2_ebusd_hc1 attr MQTT2_ebusd_hc1 userattr weekprofile
attr MQTT2_ebusd_hc1 readingList ebusd/hc1/Set:.* { FHEM::aTm2u_ebus::j2nv($EVENT, '', $JSONMAP) }\
  ebusd/hc1/MaxDHWTemp:.* { FHEM::aTm2u_ebus::j2nv($EVENT, '', $JSONMAP) }\
  ebusd/hc1/ProgramChooseSwitch:.* { FHEM::aTm2u_ebus::j2nv($EVENT, '', $JSONMAP) }\
  ebusd/hc1/SummerWinterChangeOverTemperature:.* { FHEM::aTm2u_ebus::j2nv($EVENT, '', $JSONMAP) }\
  ebusd/hc1/StartOfHoliday.Day:.* { FHEM::aTm2u_ebus::j2nv($EVENT, 'Day_', $JSONMAP) }\
  ebusd/hc1/StartOfHoliday.Month:.* { FHEM::aTm2u_ebus::j2nv($EVENT, 'Month_', $JSONMAP) }\
  ebusd/hc1/Adaption:.* { FHEM::aTm2u_ebus::j2nv($EVENT, '', $JSONMAP) }\
  ebusd/hc1/HolidayTemp:.* { FHEM::aTm2u_ebus::j2nv($EVENT, '', $JSONMAP) }\
  ebusd/hc1/HP1.*:.* { FHEM::aTm2u_ebus::upd_day_profile( $NAME, $TOPIC, $EVENT, 'So|Mo|Di|Mi|Do|Fr|Sa' ) }\
  ebusd/hc1/HP1.*:.* HP1_last_json
attr MQTT2_ebusd_hc1 setList Sunday ebusd/hc1/hcTimer.Sunday/set\
Monday ebusd/hc1/hcTimer.Monday/set\
Tuesday ebusd/hc1/hcTimer.Tuesday/set\
Wednesday ebusd/hc1/hcTimer.Wednesday/set\
Thursday ebusd/hc1/hcTimer.Thursday/set\
Friday ebusd/hc1/hcTimer.Friday/set\
Saturday ebusd/hc1/hcTimer.Saturday/set\
weekprofile { FHEM::aTm2u_ebus::send_weekprofile($NAME, $EVTPART1, $EVTPART2) }\
today_holiday_weekprofile { FHEM::aTm2u_ebus::send_weekprofile( $NAME, $EVTPART1, $EVTPART2, 'holiday' ) }
attr MQTT2_ebusd_hc1 setStateList on off
attr MQTT2_ebusd_hc1 weekprofile brenner
Wer nicht möchte, dass die Daten effektiv an den ebus gehen, kann ja in der setList "unpassende" Topics nehmen, und dann mit einem Tool wie mosquitto_sub checken, was auf der MQTT-Seite passiert, wenn man die Profile gewechselt... .

Ein weekprofile Device:

Code: [Auswählen]

defmod wp weekprofile Das füllen wir mit zwei Profilen (EDIT: das hier ist eine Abkürzung, später kann man die Profile sehr viel komfortabler über das Web-Interface von weekprofile editieren, erweitern, ...) :

Code: [Auswählen]

set wp profile_data default {"Wed":{"time":["12:00","16:00","18:00","20:00","24:00"],"temp":["18.0","23.5","5.0","20.0","15.0"]},"Sun":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["11:00","15:00","17:30","21:00","24:00"]},"Sat":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["11:30","16:30","18:30","20:20","24:00"]},"Tue":{"time":["12:00","16:00","18:00","20:00","24:00"],"temp":["18.0","23.5","5.0","20.0","15.0"]},"Mon":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["12:00","16:00","18:00","20:00","24:00"]},"Fri":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["12:00","16:00","18:00","20:00","24:00"]},"Thu":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["12:00","16:00","18:00","20:00","24:00"]}}

Code: [Auswählen]

set wp profile_data test {"Thu":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["12:04","16:04","18:04","20:04","24:00"]},"Tue":{"time":["12:02","16:02","18:02","20:02","24:00"],"temp":["18.0","23.5","5.0","20.0","15.0"]},"Fri":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["12:05","16:05","18:05","20:05","24:00"]},"Mon":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["12:01","16:01","18:01","20:01","24:00"]},"Wed":{"time":["12:03","16:03","18:03","20:03","24:00"],"temp":["18.0","23.5","5.0","20.0","15.0"]},"Sun":{"time":["11:00","15:00","17:30","21:00","24:00"],"temp":["18.0","23.5","5.0","20.0","15.0"]},"Sat":{"temp":["18.0","23.5","5.0","20.0","15.0"],"time":["11:36","16:36","18:36","20:26","24:00"]}} Und hier noch ein paar Befehle zum testen:

Code: [Auswählen]

{ FHEM::aTm2u_ebus::send_weekprofile('MQTT2_ebusd_hc1', 'wp','default') }
{ FHEM::aTm2u_ebus::send_weekprofile('MQTT2_ebusd_hc1', 'wp','test') }
{ FHEM::aTm2u_ebus::send_weekprofile('MQTT2_ebusd_hc1', 'wp','test','holiday','15') }
set wp send_to_device test MQTT2_ebusd_hc1
set MQTT2_ebusd_hc1 today_holiday_weekprofile wp defaultBin mal auf euer feedback gespannt - ist sicher noch nicht perfekt, aber ich hoffe, man kann erkennen, was es "bringen" könnte...

[beaune]

So, jetzt bin ich endlich mal dazu gekommen, mir weekprofile näher anzuschauen. Das ist ein sehr schönes Widget mit vielen Möglichkeiten… allerdings auch einigen Möglichkeiten, die eigentlich nicht so gut zur Verwendung als Eingabemaske für meine Vaillant-Heizung passen. Vielleicht brauchts hier noch ein paar Attribute, um Einschränkungen vorzunehmen. Aber jetzt mal im Einzelnen, was mir auffällt bzw. was meiner Meinung nach noch nicht optimal ist. Zur Verdeutlichung hänge ich einen Auszug aus der Menüführung des Heizungsbedienung calorMATIC 470f bei.

• Weekprofile geht davon aus, dass man für jedes Zeitintervall eine andere Temperaturvorgabe machen kann. Bei der Heizung ist das aber anders: Da definiert man einmalig, was der Tag- und was der Nachtsollwert ist. Alle Zeit-Intervalle, die man dann angibt, bedeuten dann: „Sollwert Tag“ (Ausnahme: Eingabe von Ferientagen). Es ist also nicht sinnvoll, dass man bei jedem Zeitintervall eine Temperatur eingeben kann. Vorschlag: per neuem Attribut „hideTemperatureSettings“ die Temperatur-Auswahlliste in der Editieransicht ausblenden, vielleicht sogar generell.
• Man kann in Weekprofile beliebig viele Zeitintervalle pro Tag definieren. Die Heizung kennt aber genau 3. Man muß nicht alle verwenden, aber mehr als 3 geht nicht. Vorschlag: per neuem Attribut „maxNumInterval“ eine maximale Anzahl von Intervallen angebbar machen. Sobald das Maximum erreicht ist, kann man mit „+“ in der Editieransicht kein weiteres hinzufügen.
• Man kann in Weekprofile beliebig viele Profile hinzufügen oder auch löschen. Die Heizung kennt aber genau 4 Profile: Heizkreis 1, Heizkreis 2, Warmwassererzeugung, Warmwasserzirkukation. Es wäre daher wünschenswert, dass man diese 4 Profile per Konfiguration anlegt (geht schon), aber nicht per „-“ in der Oberfläche wieder löschen kann (kann versehentlich leicht passieren), und auch das Hinzufügen per  „+“ macht keinen Sinn und sollte daher nicht angeboten werden. Vorschlag: per neuem Attribut  „fixedProfileSetting“ die Bedienelemente zum Hinzufügen/Löschen von Profiles ausblenden.

Das wärs zur reinen Bedienung. Wo ich noch unsicher bin, ist bei der Werteübertragung. Auch hier gibt es ja einen grundsätzlichen Unterschied zur ursprünglich verfolgten Vorgehensweise in fhem:

• Bei der direkten Ventilansteuerung ist fhem der „Master“ der die Steuerung vornimmt. Die Sollwerte sind nur in fhem gespeichert.
• Bei Heizungsanlagen ist fhem nur die Eingabemaske; die eigentliche Steuerung obliegt weiter der Heizung, und die Wertevorgabe kann wahlweise über die Heizungsbedienung oder fhem erfolgen.

Damit stellt sich dann die Frage: wann synchronisiert man eigentlich die fhem-Werte mit der Heizung?

• Für das Schreiben ist das noch relativ einfach: Weekprofile stellt ein Event „PROFILES_SAVED“ zur Verfügung. Das könnte man verwenden, um die Daten per MQTT zu übertragen. Hier würde ich übrigens bevorzugen, dass dies nicht direkt automatisch erfolgt, sondern man Eingriffsmöglichkeiten hat. Man könnte z.B. erstmal irgendwelche anlagenspezifischen Plausibilitätsprüfungen vornehmen, oder auch überprüfen, ob bzw. was sich überhaupt geändert hat, um nur die notwendigsten eBus-Kommunikationen anzustoßen.
• Was das Lesen angeht, bin ich aber unschlüssig. Es gibt ja zumindest meines Wissens kein Event, dass bei Anzeige eines Profils aufgerufen wird, so dass man dann automatisch die Daten für dieses Profil von der Heizung holen könnte. Alternativ könnte man hier einen Button verwenden, der einen gezielten Upload durchführt. Dazu könnte man vielleicht den „-->“ zweckentfremden. Aber das müßte dann ja auch irgendwie konfigurierbar werden, also dass man hier keine Device-Auswahl mehr haben möchte, sondern nur ein Event bekommen möchte, auf das man reagieren kann. Das gibt’s bislang auch nicht.

In Summe sind das alles Sachen, die man wahrscheinlich mit überschaubarem Aufwand hinkriegen kann. Vielleicht hab ich aber auch irgendwas noch nicht richtig verstanden. Bin gespannt auf Feedback.

[Beta-User]

Vorab mal vielen Dank für die ausführliche Rückmeldung!

Vielleicht hab ich aber auch irgendwas noch nicht richtig verstanden. Bin gespannt auf Feedback.

"richtig" ist so eine Sache, viele Wege führen nach Rom .

Mein gedankliches Konzept hinter der weekprofile-Integration weicht jedenfalls in einigen Punkten deutlich von dem ab, was du zu erwarten scheinst ...

- weekprofile ist dazu gedacht, _generisch_ Profile zu verwalten, ziemlich unabhängig vom eigentlichen Zielgerät. Hauptfolgerung: Spezielle Anpassungswünsche (in Richtung von dessen Maintainer @Risiko) sollte man nur dann adressieren, wenn es wirklich notwendig ist . Z.B. kennt auch Homematic eine Begrenzung der Zahl der Schaltzeiten (auf 6 oder 7) und/oder Tag- und Nachttemperaturen, ohne dass das bei der Anlage der Wochenprofile irgendwie berücksichtigt würde (erst beim Versenden spielt das uU. eine Rolle). Derartige Besonderheiten muss/kann also nur der Anwender kennen und bei der Erstellung der Profile berücksichtigen.

- weekprofile soll geänderte Profile nicht automatisch versenden. Das geschieht (in der Regel) _aus anderen Gründen_ (z.B. Ferienbeginn/-ende). Es hält lediglich eine _Vielzahl von Profilen_ für diverse Anwendungsszenarien vor - wobei man (über "topics") das jeweils aktuelle Szenarium direkt an eine Mehrzahl von Zielgeräten verteilen kann. Bei Topic-Nutzung (das ich - nicht nur in diesem Zusammenhang -  empfehlen würde) hat man z.B. _alle Profile für alle Geräte in einem einzigen weekprofile-Device_. Jedes Zielgerät (bzw. jede Gruppe) bekommt einen Namen, unter dem es referenziert wird (der steht dann in den Zielgeräten im weekprofile-Attribut), und zu jedem Gerät dann einen Satz von Wochenprofilen (die ganz oder in Teilen auch lediglich Referenzen auf andere Wochenprofile sein können). Ändert man dann den Topic an diesem einen weekprofile, verteilt es die zugehörigen Profile an alle Zielgeräte, die den Topic kennen, den man eingestellt hat... Komfortabler geht es mAn. kaum . Die Einrichtung ist natürlich entsprechend aufwändig, aber via Referenzierung ggf. auch schnell gemacht. 

Etwas konkreter in Richtung der MQTT/ebus-Geschichte gesprochen:

- Jeder der "Profilempfänger" (Heizkreis 1, Heizkreis 2, Warmwassererzeugung, Warmwasserzirkukation) muss gesondert angesprochen werden können. Daher generiert der myUtils-Analyse-Code (siehe den Weishaupt-Thread) auch für jedes dieser Geräte ein eigenes MQTT2_DEVICE.
- weekprofile kennt die Besonderheiten von ebus nicht, und auch MQTT2_DEVICE als Anknüpfungspunkt ist zu wenig spezifisch => die Konvertierung in "hardwaregerechte Sprache"  muss durch speziellen Code erfolgen. Entsprechender myUtils-Code ist in contrib zu finden, bitte die commandref dazu mal ansehen. Grundgedanke: alles, was oberhalb einer bestimmten Temperatur ist, ist "an", alles darunter "aus"; dabei werden max. drei "an/aus"-Paare gebildet. Der Code berücksichtigt dann auch weitere "Kleinigkeiten", wie Senden nur bei Änderung und ggf. Zusammenfassen von Mo-Fr bzw. Mo-So usw., wenn alle Schaltzeiten entsprechend an den Tagen gleich sind.

Hoffe, das ist jetzt etwas klarer geworden?

[Beta-User]

Vielleicht noch zum Thema weekprofile (und Topic-Nutzung) ein paar Links. Die betreffen zwar WeekdayTimer, aber das macht keinen großen Unterschied, ob FHEM (via WeekdayTimer) die Schaltzeiten selbst verwaltet, oder (via MQTT2_DEVICE) nur eine Übersetzung in das jeweilige Zielformat vorgenommen wird, das dann via MQTT an die Hardware weitergegeben wird und die Schaltzeiten dann dort überwacht werden.

Eine Zusammenfassung wäre in diesem Beitrag in [neues feature] WeekdayTimer mit weekprofile steuern zu finden, der ganze Thread ist aber m.E. auch einigermaßen aufschlussreich.

In Weekprofil: Topics und Weekdaytimer kann man das ganze dann auch noch etwas (zu?) ausführlich nachlesen, jedenfalls sind da einige Anfängerfragen (und typische Fehler?) drin und am Ende wohl erfolgreich geklärt...

[beaune]

Danke erstmal für die Erklärungen und Hinweise auf andere Threads. Es ist tatsächlich so, dass ich nicht verstanden hatte, wie sehr generisch Du weekprofile siehst. Ich hab es eher wie ein spezielles Eingabecontrol gesehen, einen „knob“ für die Zeitprogramme meiner Heizung, wo man eben auch wie bei anderen Bedienelementen die direkte Interaktion und nicht nur eine Eingabeschablone erwartet.

Vielleicht ist das einfach auch Geschmackssache, wie man es verwendet. Ich kann schon nachvollziehen, dass so eine zentrale Einstellmöglichkeit für viele Zeitprogramme sinnvoll sein kann, wenn man damit z.B. viele Thermostate füttern möchte. Klar will man dann nicht für jeden Thermostaten eine separate Eingabe in seinem Dashboard haben. Bei Heizungen ist es aber dann doch anders; davon gibt es genau eine, und die Einstellungen, die man dort vornimmt, sind eher globaler Natur und damit thematisch in einem Dashboard an anderer Stelle einzuordnen. Auch Umschaltungen wie: zuhause/abwesend sind in der Heizungssteuerung schon konfiguriert, und es gibt zumindest bei mir keine weiteren Geräte, die die Info auch bräuchten; die vielfältigen Möglichkeiten wie Topics helfen da gar nicht. Ich finde daher beides sinnvoll: generisch für mehrere Geräte mit Steuerungsfunktion, aber auch als spezifische Eingabemaske für ein Gerät, so wie andere Bedienelemente eben auch spezifisch sind.

Das Problem mit der Generik ist vielleicht auch, dass dies Einfluß auf die einfache Bedienung haben kann. Eine Benutzeroberfläche soll den Anwender intuitiv führen. Ich finde nicht, dass der Anwender Besonderheiten wie die mögliche Anzahl von Schaltzeiten „kennen muß“. Im Gegenteil; ich erwarte, dass eine Benutzeroberfläche das „weiß“ und nur die sinnvollen Eingaben zulässt. Erst Eingaben anzunehmen und dann später zu verwerfen oder Fehlermeldungen zu bringen, halte ich nicht für gut. Das betrifft aber auch nicht unbedingt nur meinen Aspekt singulären Heizung; auch wenn man z.B. Eingaben für mehrere Homematik-Geräte macht, könnte es doch sinnvoll sein, die Begrenzung der Anzahl der Schaltzeiten in der Oberfläche einstellen zu können. Wie komplex das wird ist wieder eine Frage, wie generisch es wirklich sein muß: Sind es alles gleichartige Geräte, für die man in einem weekprofile Einstellungen vornimmt, oder sind es völlig verschiedene. Letzteres kann theoretisch natürlich sein; in der Praxis glaube ich nicht so richtig dran.

In Richtung Benutzeroberfläche geht auch mein Punkt mit den Temperaturen. Man kann natürlich überall die Temperatur anzeigen, die für „an“ bzw. für „aus“ stehen. Und soweit ich sehe kann man für die Grenztemperaturen auch alternativ Namen ausgeben. Fakt ist aber, dass man damit viel unnütze Information auf dem Monitor hat, Platz aber immer knapp ist.

Wie auch immer, für beide Szenarien gibt es gute Gründe. Man könnte jetzt sagen, das Anwendungsszenario unterscheidet sich so stark, dass man dafür auch verschiedene weekprofile-Module braucht. Es ist auch bestimmt nicht gut, zu viele Verzweigungen in ein Modul zu packen. Ich glaube aber in diesem Fall, dass es nicht so schwierig ist, sowohl die generische als auch die spezifische Zeitprogrammzuordnung in einem Modul zu vereinen, zumal auch der (beschränkt) generische Einsatz von einigen von mir vorgeschlagenenen Attribute profitieren könnte.

Hinsichtlich der Kommunikation mit dem physikalischen Gerät bin ich durchaus der Meinung, dass man manches automatisch machen könnte und auch sollte. Wenn ein solches Control speziell für ein Gerät wie eine Heizungsanlage steht, ist es aus Anwendersicht nicht verständlich, warum man zunächst ein Profil eingeben, dies speichern und dann nochmal separat an ein virtuelles Gerät (MQTT-Device) übertragen soll.  Als Anwender bin ich zufrieden, wenn ich die Heizkreise in einer Combobox auswählen kann, dann die dazu passenden Zeiten äquivalent zur Anzeige am Heizungsreger selbst sehe, und diese gezielt ändern kann. Da erwartet man natürlich, dass hier nach Speicherung eine Übertragung automatisch stattfindet, ist an der Heizung selbst ja auch so. Man könnte dies ggf. darüber lösen, dass man auch MQTT-Devices als Master-Device für weekprofile zulässt, aber da sich eine Heizungsanlage auf mehrere MQTT-Devices aufteilt, ist das nicht ganz so easy. Meiner Meinung nach reicht es aber völlig aus, wenn man per notify auf die Speicherung eines dedizierten Profils reagieren kann. Damit steht es dem Anwender frei zu entscheiden, ob er gleich eine Übertragung initiieren will, ob irgendwelche gerätespezifischen Besonderheiten/Datenumwandlungen erfolgen müssen usw.

Um hier voran zu kommen hab ich jetzt einfach mal was implementiert. Vielleicht hilfts ja Leuten, die da ähnlich wie ich denken, und vielleicht kann ich den Maintainer ja doch überzeugen, das eine oder andere davon zu übernehmen… hier gehts in erster Linie um die UI, und für die Weiterverarbeitung „unter dem Deckel“ ergeben sich  neue Freiheitsgrade. Die Implementierung und die nähere Beschreibung der neuen Attribute/Events habe ich in diesem Thread hinterlegt: https://forum.fhem.de/index.php/topic,46117.msg1172819.html#msg1172819

[Beta-User]

 
Vorab mal "Hut ab!" - einen konkreten Vorschlag einzureichen ist schon mal was, auch wenn ich etwas Sorge habe, dass das weekprofile-Modul dann für viele "noch undurchsichtiger" wird....

Was die Frage nach einem "Rückweg" von MQTT2_DEVICE nach weekprofile angeht ("Master device") bin ich etwas skeptisch, weil ich im Moment nicht sehe, auf welche standardisierte Weise diese Profil-Daten denn abzufragen wären (und die sind bei den beiden heute bekannten Varianten ebus und zigbee2tasmota auch noch sehr unterschiedlich...). Aber wer weiß, vielleicht nimmt sich jemand der Sache mal konkret an, und es kommt was verwertbares raus.

Wie dem auch sei...
Nach deinen Rückmeldungen gehe ich mal davon aus, dass jedenfalls der Weg von weekprofile über MQTT2_DEVICE bis hin zur Therme funktioniert, wenn auch "im weekprofile-Standard" von der Bedienseite her nicht ganz so, wie du das optimal findest...?

[beaune]

Hm, da muß ich glaube ich mit einem klaren jein antworten 

Da ich schon bei der Durchsicht der ganzen Threads erkannt hatte, dass die notwendigen Bedienhandlungen zum Schreiben nicht zu meiner Vorstellung passen, habe ich mir relativ früh die Frage gestellt, was man denn ändern müßte, und ob das vom Unfang her vertretbar wäre. Und wie es dann so ist: wenn man erstmal anfängt, sich im Code zu orientieren, findet man auch schnell die entsprechenden Stellen, und hat dann einfach schon die Lösung, die man haben möchte. Sprich: ich habe den Originalweg nie praktisch ausprobiert, sondern bei den Tests immer schon die gepatchte Variante des weekprofiles verwendet. Und die verwendet im Gegensatz zum Original einen neuen Event beim Schreiben, wodurch die eigentliche Initiierung der MQTT-Kommunikation in ein notify wandert, in dem dann der MQTT2-Server aufgerufen wird. Also eher so, wie Reinhard es in seiner Version mit den vielen Dummys mal gemacht hatte. Das ist glaube ich nicht das, was Du Dir vorgestellt hättest... Aber ja, das funktioniert wunderbar und ist bei mir seit einigen Tagen in der praktischen Anwendung.

[Beta-User]

  Na ja, was ich mir mal vorgestellt hatte, sei mal dahingestellt - wichtig ist letztendlich, ob dann am Ende was rauskommt, das aus User-Sicht sinnvoll ist, und das kann durchaus auch was anderes sein wie die ursprüngliche Überlegung, zumal ich ja die Funktionsweise und das Zusammenspiel der Komponenten nicht kenne, die via ebus adressiert werden .

Ich vermute ja immer noch, dass man eigentlich immer gleichzeitig Tag/Nachtabsenkung, Umlaufpumpe für WW, ... synchron halten will und daher sowas wie ein Topic-Wechsel bei vordefinierten, zusammenpassenden Einzelprofilen sinnvoll ist, aber du wirst das schon besser wissen .

Jedenfalls: Solange dein Code den JSON nicht plötzlich anders strukturiert ist alles gut - wer wann warum aus welchem Grund dem MQTT2_DEVICE mitteilt, dass das Profil doch bitte abzuholen ist, macht keinen Unterschied. Wichtiger ist, ob die Umwandlung von "weekprofile-Type" nach "ebus-Type" klappt, und da höre ich ein "Jawoll, klappt sehr gut" raus .

Du könntest jetzt noch einen "setter" + Perl-Code generieren, der ein vom Bus kommendes Profil nach weekprofile übersetzt, sollte nicht besonders schwierig sein, nachdem du ja jetzt etwas in dem Thema drin bist?

Jetzt schauen wir auf alle Fälle mal, was Risiko zu deinen Vorschlägen zu sagen hat und ich hoffe, dass es auch (zufriedene) Nutzer für das feature gibt.

Damit wäre der [WIP]-Status des Threads dann eigentlich passé, oder?


Falls jemand mitliest, der ebus@MQTT2_DEVICE nutzt und das noch nicht mitbekommen hat: Es gibt seit kurzem ein "spezielles attrTemplate", das die automatisch (optimalerweise mit autocreate auf "complex") erstellten readingList-Attribute der diversen "Kinder" analysieren kann und dann "typische Fälle" mit (hoffentlich) passenden Spezialfunktionen behandelt.
Rückmeldung und eventuelle Fragen dazu bitte entweder dann im "allgemeinen ebus-attrTemplate-Thread" oder im "Weishaupt-MQTT2"-Thread.

[beaune]

Ich vermute ja immer noch, dass man eigentlich immer gleichzeitig Tag/Nachtabsenkung, Umlaufpumpe für WW, ... synchron halten will

Nein das ist sicher nicht so. Wenn man z.B. eine Kombination aus Fussbodenheizung und konventionellen Heizkörpern hat, muß man die Zeiten schon alleine aufgrund der physikalischen Wärmeübergangseigenschaften anders gestalten. Die Fußbodenheizung braucht viel länger zum warm werden; da machen kurze Auszeiten gar keinen Sinn. Zumindest muß man sie morgens viel früher einschalten, als den Heizkreis mit den übrigen Heizkörpern, wenn man morgens warme Füße haben will. Schaltet man alles früh ein, verschwendet man hingegen Energie. Und noch extremer ist es mit dem Warnwasser: das ist ja quasi ad-hoc warm; die Therme braucht nur wenige Minuten, um den Warmwasserspeicher wieder auf Temperatur zu bringen.

Klar könnte man jetzt versuchen, feste Zeitoffsets zu ermitteln usw. Aber ob sich das wirklich lohnt... Heizungen sind halt schon sehr individuell und brauchen Freiheitsgrade.

[Beta-User]

  Meine Rede:
Das konkrete Profil "pro Zielgerät" ist unterschiedlich, aber: Alle grade wirksamen Profile müssen zueinander passen. Genau das "müssen zueinander passen" ist der Sinn von "useTopic" - das bedeutet grade nicht, dass das jeweilige (Einzel-) Profil für alle Zielgeräte identisch sein müsste (aber sein kann), sondern, dass der "Profil-Satz" zueinander passend gewählt werden kann  .

Genau deswegen ist es auch nicht notwendig, immer gleich ein geändertes (Einzel-) Profil an das Zielgerät zu senden. Das Profile erstellen ist eher eine vorbereitende Einmal-Aktion, (nur) für die Topic-Auswahl (oder das Szenarium für alle, falls dir das besser gefällt), dafür braucht man eigentlich einen "schönen setter"...

EDIT:
Sorry, falls das mit "synchron" früher irgendwie so rübergekommen sein sollte, dass ein Profil immer für alle Zielgeräte identisch sein müßte. So war es nie gemeint. Eher in die Richtung: Schalte vor der eigentlichen Heizzeit die Wasserbereitung ein (und ggf. etwas später die Umwälzpumpe an), damit das (zu den Heizzeiten) "konfliktfrei" läuft, mache dann die FB-Heizung (ggf. mit etwas höherer Vorlauftemp), und zum Schluss werden die "normalen" HK bedient, und wenn man dann aufsteht, ins Homeoffice geht, ... ist jeweils alles fein...

[beaune]

Das mag alles sein, wenn man mehrere Topics braucht. Gibts bei mir aber nicht, die Zeiten sind immer identisch! Ausnahme wäre Urlaub oder so, aber dafür haben Heizungssteuerungen einen eigenen Kalender, in dem man Tage außer Haus oder Urlaubstage pflegen kann. Es gibt also nur ein Topic, und deshalb ist da auch nichts auszuwählen. Daher macht es eben doch Sinn, Änderungen an einem Profil direkt ans Gerät zu senden.

[Beta-User]

Wie so oft: Es kommt auf die Umstände drumrum an...

Du scheinst ein gut isoliertes Haus zu haben und den Heiz-Grundbedarf vorwiegend mit einer (prinzipbedingt sehr trägen) FB-Heizung zu decken. Völlig klar, dass da (bzgl. der Heizerei) nur längerfristige Abwesenheiten überhaupt irgendwie berücksichtigt werden. Stellt sich die Frage, ob man in so einem Umfeld wesentlich mehr braucht wie die Option, hin und wieder die Uhr wieder richtig zu stellen .
Ich komme gedanklich eher aus einem mäßig isolierten Altbau, bei dem Ferien usw. massiv das Nutzungsprofil über den Tag beeinflussen, und bei dem heizungsmäßig nicht mehr genug geht, wenn grade Warmwasserbereitung angesagt ist... (Ich habe nur leider eine Junkers...)

Es ist in deinem Setup auch ok, wenn man dann Änderungen direkt auf den Bus schiebt, aber meine gedankliche Hauptzielgruppe bleibt eher der Kreis derer, die einen gewissen Bedarf in die Richtung "halte verschiedene Anwendungsszenarien auf einen Schlag synchron" haben.

Beides ist ja legitim, auch das ist (und war) nie die Frage.