Modul weekprofile + FHEMWEB widget

[ToKa]

Hallo Risiko,

mir ist heute nach dem Neustart von fhem noch ein Fehler im Log aufgefallen:

Code Auswählen Erweitern


2021.02.17 08:18:23 2: ST_sz_THKV_Heizkoerper_Wand_wp_01(weekprofile_createTempMap): create map from eco:18.0,comfort:18.5,comfort_nite:19.0
2021.02.17 08:18:29 1: Including ./log/fhem.save
2021.02.17 08:18:29 1: PERL WARNING: Use of uninitialized value $attrMap in concatenation (.) or string at ./FHEM/98_weekprofile.pm line 1412.
2021.02.17 08:18:29 2: ST_sz_THKV_Heizkoerper_Wand_wp_01(weekprofile_createTempMap): create map from


Falls Du ein List vom device benötigst, sag Bescheid.

Viele Grüße
Torsten

[Risiko]

Danke.
Behoben und die Anzeige von '°C' bei Wörtern auch.

[ToKa]

Hallo Risiko,

vielen Dank für Änderung und Fehlerbegebung. Funktioniert!

VG
Torsten

[beaune]

Hallo,

zur Zeit wird in mehreren Threads zum eBus die Nutzung des weekprofile-Moduls für die Konfiguration von Zeitplänen in Heizungssteuerungen diskutiert. Ich habe mir das mal genauer für meine Vaillant-Anlage angesehen, und einige grundlegende Unterschiede in der Anwendung/Erwartungshaltung festgestellt:

• Bei der direkten Ansteuerung von Ventilen usw. ist fhem der ,,Master", der die Zeitprofile verwaltet und auf mehrere Geräte verteilt. Bei einer Heizungsanlage ist fhem nur das Vehikel, um Zeitpläne einzugeben. Die Verwaltung und Auswertung liegt weiterhin in der Heizungsanlage selbst.
• Bei der direkten fhem-Steuerung gibt man zu jedem Zeitintervall eine Soll-Temperatur ein. Bei Heizungsanlagen ist die Soll-Temperatur aber zentral verwaltet; die Zeitintervalle steuern nur, ob die Heizung im Normalbetrieb oder im Nachabsenkungsbetrieb läuft. Man konfiguriert dort also keine Temperaturwerte im Rahmen der Zeitprofile, und zeigt auch nur die ,,on"-Intervalle an, in denen die Heizung im Normalbetrieb läuft.
• Die Anzahl der möglichen Zeitintervalle ist durch die Heizungssteuerung fest vorgegeben; man kann nicht beliebig viele definieren.
• Die möglichen Profile (=Heizkreise bzw. Warmwasserbereitung) sind ebenfalls fest durch die Installation vorgegeben.

Man könnte jetzt sagen, die beiden Szenarien unterscheiden sich so stark, dass man dafür auch verschiedene Eingabemodule 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, beides in einem Modul zu vereinen, und hab einfach mal einen entsprechenden Vorschlag gemacht. Sieht auf den ersten Blick viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für eine Heizungssteuerung verwenden, behält aber auch alle vorhandenen Möglichkeiten, die man für eine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle und kompatible Ergänzung des Moduls. Bin gespannt was Ihr dazu sagt, und ob meine Anregungen vielleicht sogar ins Einzug ins Repository finden

Neue Attribute:

• maxNumInterval: limitiert die Anzahl eingebbarer Zeitintervalle zwischen 1 und 10; Default: 0 (=unlimitiert)
• fixedProfileSettings: Verhindert das Hinzufügen und Löschen von Profilen über die Oberfläche.  Die Option ist sinnvoll in Verbindung mit Geräten, die über eine feste Anzahl und Typen von Profile verfügen, z.B. Heizungen. Default: 0
• hideTemperatureSettings:  Blendet die Temperatureinstellungen sowohl in der Übersicht aus auch beim Editieren aus, und trägt stattdessen automatisch ,,on" bzw. ,,off" als Temperaturwert ein. In der Übersicht werden die Off-Intervalle ausgeblendet.
  Die Option ist sinnvoll in Verbindung mit Geräten, die globale Temperatureinstellungen unabhängig vom Intervall verwalten, und bei den Intervallen nur die on-Intervalle konfiguriert werden, z.B. bei Heizungen. Default: 0
• showLoadButton:   Wenn auf 1 gesetzt, blendet FHEM einen zusätzlichen Button ein, bei dessen Aufruf das Event LOAD_FROM_DEVICE getriggert wird.
  Die Option ist sinnvoll, wenn man direkt aus dem WeekProfile Control heraus ermöglichen will, vor dem Editieren Daten aus einem Gerät zu lesen.  Das gewählte Profil wird im Event mit übertragen. Default: 0.
• hideTransferButton:  Wenn auf 1 gesetzt, wird der Button zum Transfer des gewählten Profils auf auswählbare FHEM-Devices ausgeblendet. Die Option ist sinnvoll, wenn direkt nach der Eingabe neuer Daten die weitere Verarbeitung ohne weitere User-Interaktion durchgeführt werden soll. Dies kann über Auswertung des Events WRITE_TO_DEVICE geschehen. Default: 0
• nolink: Wenn auf 1 gesetzt wird verhindert, dass der rechts neben dem Edit-Icon stehende Modulname ein Link ist (wie bei readingsGroups). Default: 0
• noheadings: Wenn auf 1 gesetzt wird verhindert, dass oberhalb des Controls nochmal der Modulname ausgegeben wird (wie bei readingsGroups). Default: 0

Neue Events:

• LOAD_FROM_DEVICE: wird aufgerufen, wenn der durch showLoadButton eingeblendete zusätzliche Button betätigt wird. Das aktuell ausgewählte Profil wird mit übergeben.
• WRITE_TO_DEVICE: wird aufgerufen, nachdem neue Daten gespeichert wurden. Das aktuell ausgewählte Profil wird mit übergeben, so dass der Anwender per notify entscheiden kann, welche Geräte automatisch mit neuen Daten versorgt werden sollen.

Sieht viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für ein spezifisches Gerät spezialisieren, und wird damit auch ,,kleinen" Anlagen gerecht, wo man wirklich nur die Heizung einstellen will und keine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle Ergänzung des Moduls. Bin gespannt, ob sich jemand dafür interessiert, oder was Ihr noch verbessern würdet. Die Implementierung und zwei Screenshots sind hier angehängt.

[DS_Starter]

Hallo beaune,

finde deine Erweiterungen interessant und hilfreich.
Ich habe seit ein paar Monaten ebenfalls eine Vaillant Anlage und will die noch in FHEM integrieren.
Momentan habe ich überhaupt noch kein Ebus integriert. Deswegen wäre es für mich interessant wie genau du deine Vaillant integriert hast. Ein paar Stellen zum Einlesen reichen mir, bin bislang nur nicht dazu gekommen mich damit eingehender zu befassen.

Die Nutzung von weekprofile reduziert sich bei mir auf die Thermostatsteuerung mit HM Classic.
Deswegen werde ich deine Moduländerung erstmal auf Kompatibilität testen und melden wenn mir etwas auffallen sollte.

Gleich jetzt der Hinweis, dass die Umlaute in der Hilfe schon direkt im Modul falsch geschrieben sind und natürlich auch so dargestellt werden, z.B.

Code Auswählen Erweitern


Mit dem Modul 'weekprofile' können mehrere Wochenprofile verwaltet und an unterschiedliche Geräte
  übertragen werden. Aktuell wird folgende Hardware unterstützt:
.....


Generell würde ich mir wünschen, dass die Commandref etwas lesbarer gestaltet wird und die Einblendung der Hilftexte bei Auswahl eines Attributes mit angezeigt werden. Dieses hat  sich m.M. nach inzwischen als Standard etabliert.
Aber das ist eher ein Wunsch in Richtung Risiko. 
An dieser Stelle ein großer Dank an Risiko für dieses Modul !!

Grüße,
Heiko 

[Risiko]

Generell würde ich mir wünschen, dass die Commandref etwas lesbarer gestaltet wird und die Einblendung der Hilftexte bei Auswahl eines Attributes mit angezeigt werden. Dieses hat  sich m.M. nach inzwischen als Standard etabliert.

Ok. Muss ich mich mal damit beschäftigen. Noch keine Ahnung wie das geht...
Aber danke für den Hinweis

[Risiko]

Sieht viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für ein spezifisches Gerät spezialisieren, und wird damit auch ,,kleinen" Anlagen gerecht, wo man wirklich nur die Heizung einstellen will und keine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle Ergänzung des Moduls. Bin gespannt, ob sich jemand dafür interessiert, oder was Ihr noch verbessern würdet. Die Implementierung und zwei Screenshots sind hier angehängt.

Hallo beaune,

ich schaue es mir bei Gelegenheit an und wenn es mit in das Konzept passt, habe ich nichts gegen eine Aufnahme.

Risiko

[Beta-User]

Ok. Muss ich mich mal damit beschäftigen. Noch keine Ahnung wie das geht...
Aber danke für den Hinweis

Anbei die auf "id" umgestellte Fassung von beaune. Die kaputten Umlaute sind (hoffentlich) auch wieder ok, es wäre ggf. nett, wenn "jemand" sich dann noch die Mühe machen könnte, die noch fehlenden setter, getter und Attribute (in DE und EN) zu ergänzen. Bitte dazu einen Editor verwenden, der die Umlaute (und ggf. Zeilenumbrüche) nicht wieder kaputt macht (unter Wind.* z.B. notepad++).

Das beinhaltet keine Aussage, ob ich den Vorschlag jetzt gut finde oder nicht - dazu habe ich mir schlicht noch keine Meinung gebildet. Wollte nur "nichts wegwerfen", was schon da ist.
Allerdings finde ich die Zahl der Attribute ziemlich hoch und würde ggf. mal die Überlegung in den Raum werfen, ob es nicht einfacher wäre, diese "speziellen" Darstellungseinstell-Optionen einfach in ein "Einheitsattribut" zu packen und dann "option1=x option2=y bla=1" als Syntax (via parseParams) zu verwenden.

@Risiko:
Zwei Dinge schwirren mir noch im Kopf rum:
- zum einen hatte ich irgendwann abgespeichert, dass man FHEM neu starten muss, wenn man neue Clients erkennen lassen will. Wäre ggf. möglich, das im Rahmen der NotifyFn mit abzufangen;
- zum anderen ist das userAttr "weekprofile" ja (aus Sicht der commandref) eigentlich eines, das zu weekprofile gehört. Dazu müsste man aber den betreffenden "fremden Modul-Instanzen" mitteilen, dass die Hilfe aus weekprofile kommt. Da es nur einzelne Instanzen betrifft (und nicht alle), müsste für diese Fälle dann addToDevAttrList aufgerufen werden, siehe Link unten (erster commit, die Schleife war da aber schon da).

@DS_Starter:
Falls du DbLog auch auf "id'" umstellen willst (was ich v.a. für die globalen Attribute klasse fände!) hier der Link zu den patches, die bzgl. AutoShuttersControl dafür erforderlich sind - https://github.com/fhem/AutoShuttersControl/pull/96

[beaune]

Vielen Dank schon mal für Euer Interesse!

@Risiko:
Wenn Du Fragen zu meinen Änderungsvorschlägen hast oder ich noch irgendwas zuliefern kann, sag einfach Bescheid! Vielleicht hast Du ja auch noch Ideen, wie man es noch besser machen kann. Ist ja nur ein erster Vorschlag, der allerdings auch praktisch schon im Einsatz ist und da ganz gut funktioniert.

@Beta-User:
Du hast Recht, es sind relativ viele neue Attribute. Ich hatte auch überlegt, das zusammenzufassen, mich am Ende aber dagegen entschieden, da viele der Erweiterungen auch für sich genommen Sinn machen und nicht zwingend in der Kombination nötig sind. Z.B. so etwas wie ,,nolink" oder ,,noheadings": Das hat wenig mit weekprofile zu tun und ist einfach analog zu Readingsgroup so gemacht, weil man es von da halt schon kennt. Ich fand es charmant, hier möglichst wenig Abhängigkeiten zu schaffen und den Code damit überschaubar zu halten. Aber das ist natürlich alles Geschmackssache.

Die fehlenden getter/setter/Attribute hab ich versucht zu ergänzen und hoffentlich nichts vergessen. Sonst sag nochmal Bescheid. Die neue Version ist beigefügt.

@DS_Starter:
Ich schreib mal ein paar Stichpunkte zum Thema eBus-Integration zusammen.

• Meine Heizungsanlage besteht aus Therme ecoTEC plus VC DE 206/5-5 R2 , Mischermodul VR61 für die Fußbodenheizung, Funk-Bedienterminal und Regler calorMATIC 470f und Funkaußenfühler VR21.
• Den eBUS hab ich über den eBus-Adapter 3 angekoppelt. Ich nutze dabei aktuell die WLAN-Option.
• Infos zum Adapter, Anschluß, Optionen usw. findest Du unter https://adapter.ebusd.eu/.
• Zur softwaremäßigen Integration braucht Du den eBUS-Dämon. Den findest Du nebst Doku und Installationsanleitung hier: https://github.com/john30/ebusd. Damit kannst Du dann schon mal über die Kommandozeile Parameter lesen und schreiben.
• Im Git findest Du auch csv-Dateien, die quasi Gerätebeschreibungsdateien der eBUS-Geräte darstellen. Die werden zwar automatisch geladen, es empfiehlt sich dennoch, sie lokal abzulegen, falls das Internet mal nicht geht, oder falls man was ändern/ergänzen will, was nicht ganz abwegig ist.
• Zur FHEM-Integration gibt es Wiki-Dokus, die allerdings nicht sehr übersichtlich und teilweise veraltet sind. Da muß man dann sich dann doch manchmal durch aktuelle Threads wühlen, was manchmal etwas mühsam ist, weil die einfach schon sehr lang sind.
• Es gibt hier mehrere Integrationswege (ECMD, GAEBUS, MQTT, siehe https://wiki.fhem.de/wiki/EBUS), wobei ich mich persönlich nur mit MQTT beschäftigt habe, weil ich glaube, dass dieser Weg am wenigsten spezifisch ist und auch am besten gepflegt werden kann, weil er einfach standardisiert ist. Ganz intuitiv ist der Anfang dann aber leider doch nicht.
• Zum MQTT-Weg liest Du am besten hier nach: https://wiki.fhem.de/wiki/EBUS-MQTT2. Auch das ist nicht mehr zu 100% aktuell. Wichtig ist hier das Grundverständnis, dass man ein eBUS-Bridge-Device braucht, dass dann die Nachrichten sortiert und weiteren MQTT-Devices zuordnet, die dann stellvertretend für die oben genannten Komponenten der Heizung sind. Und dass man das Autocreate zunächst abschalten muß, bis man das Bridge Device hat. Um das zu installieren gibt es ein attrTemplate, das allerdings nur so ähnlich heißt wie in der Doku beschrieben, irgendwas mit eBUS und Splitter.
• Anschließend kannst Du noch weitere Templates installieren, die allerdings meiner Meinung nach allesamt nicht wirklich für den produktiven Einsatz brauchbar sind. Da ist dann auch so etwas wie ein Vorläufer des weekprofiles dabei, aber wirklich noch weit weg von dem, was wir hier jetzt vorliegen haben. Man kann da mal rein schauen und kann da Anregungen und Infos rausziehen, die man braucht, um sich eine eigene Lösung zu bauen. Aber mehr als Beispielcharakter hat das nicht, funktioniert teilweise auch nicht oder wirft Warnings.
• Was Du nur verstehen mußt ist, wie lesen und schreiben funktioniert, also wie die MQTT-Topics aufgebaut sind. Vieles wird schon automatisch angelegt, aber zumindest im aktuellen Stand muß man dann doch schon mal Hand anlegen, unsinniges löschen, Dinge umbenennen usw. Da gibt's zwar auch Ansätze, alles weiter zu automatisieren (https://forum.fhem.de/index.php/topic,122048.0.html) , aber ich stehe dem etwas skeptisch gegenüber. Das Ganze ist schon recht komplex, und bis zu einem gewissen Grade muß man einfach einsteigen, um es zu verstehen und damit auch Anpassungen durchführen zu können. Heizungsanlagen sind halt auch immer sehr individuell, insbesondere was man wirklich ständig sehen oder einstellen können will/muß. Da läßt sich nicht alles generisch lösen. Eine etwas geschlossenere Doku würde da schon helfen.

So viel fürs Erste... Ich füge als Anregung noch einen Screenshot bei, wie sich die Heizung bei mir im Dashboard auf nem iPhone darstellt, sehr kompakt, aber das Wichtige ist da, natürlich mit gepatchtem weekprofile  . Wenn Du irgendwo weitere Details brauchst frag einfach nach.

[Beta-User]

Dank zurück für's Erweitern/Ergänzen.

Das mit den settern (Event) finde ich spontan inhaltlich nicht so gelungen - der Event ist aus meiner Perspektive nur "Nebensache".

"parseParams" hatte ich deswegen genannt, weil es ermöglicht, eine beliebige (Teil-) Auswahl zu setzen und dabei keine bestimmte Reihenfolge einhalten zu müssen. Daher ist das ideal, wenn man einen ganzen Stall von "ein/aus"-Möglichkeiten hat, die man beliebig kombinieren kann, das ganze an sich aber eher selten gebraucht wird. Es macht dann ggf. aber Sinn, eine Verifizierung durchzuführen um dem User gleich beim Setzen mitzuteilen, wenn er was falsch geschrieben hat usw.. (Wer RHASSPY kennt: da habe ich das relativ exzessiv so gemacht, code ist in contrib zu finden).

Bzgl. ebus und Heizungen: Das ist hier m.E. ziemlich OT, und beaune hat wohl auch recht, wenn er darauf hinweist, dass das ganze (teilweise) ziemlich Kraut und Rüben ist. Das liegt aber - soweit ich das beurteilen kann - v.a. daran, dass die Konfiguration auf der ebus-Seite (csv's) irgendwie (je nachdem, wer welches Gerät mit welchem Kenntnisstand hat) "unfertig" ist. Ich kann nur den Versuch anbieten, das ganze auf der FHEM-Seite einigermaßen komfortabel bedien- und auswertbar zu machen, was unerfreulich viel Coding braucht...
Aber auch da: je mehr sich damit auseinandersetzen, desto besser ist am Ende das Ergebnis für alle....

[Risiko]

@Risiko:
Zwei Dinge schwirren mir noch im Kopf rum:
- zum einen hatte ich irgendwann abgespeichert, dass man FHEM neu starten muss, wenn man neue Clients erkennen lassen will. Wäre ggf. möglich, das im Rahmen der NotifyFn mit abzufangen;

Das ist eigentlich schon drin.

- zum anderen ist das userAttr "weekprofile" ja (aus Sicht der commandref) eigentlich eines, das zu weekprofile gehört. Dazu müsste man aber den betreffenden "fremden Modul-Instanzen" mitteilen, dass die Hilfe aus weekprofile kommt. Da es nur einzelne Instanzen betrifft (und nicht alle), müsste für diese Fälle dann addToDevAttrList aufgerufen werden, siehe Link unten (erster commit, die Schleife war da aber schon da).

Kommt mit auf die ToDo-Liste  Danke dafür

[Beta-User]

Das ist eigentlich schon drin.

Ups, sorry, hatte ich wohl nicht aus meinem internen Speicher gelöscht ...

Kommt mit auf die ToDo-Liste  Danke dafür

Gerne!

[Risiko]

Anbei die auf "id" umgestellte Fassung von beaune. Die kaputten Umlaute sind (hoffentlich) auch wieder ok, es wäre ggf. nett, wenn "jemand" sich dann noch die Mühe machen könnte, die noch fehlenden setter, getter und Attribute (in DE und EN) zu ergänzen. Bitte dazu einen Editor verwenden, der die Umlaute (und ggf. Zeilenumbrüche) nicht wieder kaputt macht (unter Wind.* z.B. notepad++).

Habe heute die Version mit der Umstellung auf id's eingecheckt. Nochmal Danke.

[DS_Starter]

@beaune, vielen Dank für die ausführliche Auflistung !! 
Ich nehme mir es mal für den Herbst vor und komme gerne auf dich und dein Wissen zurück.

Grüße,
Heiko

[Risiko]

Vielen Dank schon mal für Euer Interesse!

@Risiko:
Wenn Du Fragen zu meinen Änderungsvorschlägen hast oder ich noch irgendwas zuliefern kann, sag einfach Bescheid! Vielleicht hast Du ja auch noch Ideen, wie man es noch besser machen kann. Ist ja nur ein erster Vorschlag, der allerdings auch praktisch schon im Einsatz ist und da ganz gut funktioniert.

@beaune
Danke für die Erweiterung und die Beschreibung. Ich habe mich heute ein wenig damit beschäftigt.

Wenn ich es richtig verstehe, möchtest du nur Zeitpläne für Heizung ist AN verwalten. Zeitpläne für AUS und Temperaturen gibt es nicht. Die Keywords ON,OFF sind unter der Haube auch Temperaturen.
Das ist meiner Meinung nach schon eine gewaltige Vergewaltigung des Moduls! Viele Funktionen gehen dann nicht  (auch wenn du die ggf. auch gar nicht verwendest). Wäre hier weekdaytimer oder was Anderes nicht besser?
Ich muss mich noch weiter damit beschäftigen, um entscheiden zu können, ob eine Integration wirklich Sinn macht. Wenn ja, wäre meiner Meinung nach ein konkreter Modus sinnvoll. Also wenn man explizit diesen Modus ohne Temperaturen verwendet, dann würden auch einige Attribute, Befehle, etc. wegfallen. Sonst gibt es viele ungültige Kombinationsmöglichkeiten\Varianten.

Was machst du denn eigentlich mit den Zeitplänen in weekprofile - nur visualisieren?
Du schreibst, die "Temperaturen werden Zentral verwaltet". Das verstehe ich leider nicht. Wäre es denn nicht sinnvoll, diese Temperaturen mit einstellen zu können? Wie\wer stellt diese Temperatur denn ein?

Die Anzahl der neuen Attribute halte ich auch für hoch.  Die Bündelung  zusammengehöriger Attribute (bspw. Visualisierungsoptionen) in ein Attribut, halte ich auch für sinnvoll.

Risiko