MAX und die Kalender Module

[Wzut]

vor Jahren vor meiner FHEM Zeit hatte ich für die MAX Module die Software maxbuddy im Einsatz.
Damals hatte ich auch einer Erweiterung geschrieben um MAX Thermostate via Kalendereinträgen steuern zu können.
Der Vorteil gegenüber den realtiv starren Wochenprofilen lag hier bei Bedarf "ausser der Reihe" oder die besonderen Anforderungen von Schichtarbeitern.
Lange Rede kurzer Sinn :
Besteht Interesse daran das die MAX Module mit bestehenden FHEM Kalendermodulen (Calendar,CALVIEW, SSCAL) direkt zusammen arbeiten ?

Um zb. mit einem beliebigen Kalender (intern/extern) ein Thermostat gezielt zu ändern, würde es genügen einen Kalendereintrag zu erstellen mit Anfang/Ende Datum/Uhrzeit und dem Eintrag welches Thermostat wie verstellt werden soll, der Rest würde dann automatisch ablaufen.
Das könnten Einzeltermine sein , wie Morgen von 8:00 bis 10:00 das Bad auf 26 Grad hochheizen oder ganze Schichtpläne nach dem Muster in den geraden Kalenderwochen Profil Früh und in den ungeraden Profil Spät oder Schichten die sich nicht einfach stur von Montag bis Sonntag direkt abbilden lassen.

[thburkhart]

das wäre perfekt

Gesendet von meinem SM-G950F mit Tapatalk

[HeikoGr]

ja, das wäre deutlich intuitiver

[Beta-User]

[OT] eine Anregung von meiner Seite:

Eventuell wäre das mit der Calendar-Steuerung (Calendar sei synonym für Derivate zu verstehen) eine Sache, die mit einem kleinen Umweg dann auch für alle anderen Thermostattypen interessant wäre (bzw. via WeekdayTimer dann für alles, was irgendwie Temperaturanweisungen verarbeiten kann).

Der Umweg ginge so: Die Calendar-Info wird erst in ein weekprofile (bzw. in ein topic@weekprofile) übersetzt und von dort aus mit den weekprofile-Methoden gespeichert bzw. verteilt. Soweit ich das richtig verstanden habe, kann das auch (geänderte) Wochenlisten an MAX senden (und CUL_HM, HMCCUDEV,...).

Wäre etwas schwieriger einzurichten, dafür aber eben universell. (Vielleicht kann man ja auch beides parallel entwickeln/unterstützen?).

Generell war meine Erfahrung bei der Einführung des supports für weekprofile bei WeekdayTimer, dass gerade die, die flexible Arbeitszeiten hatten, dieses feature sehr hilfreich fanden. Gehe daher davon aus, dass an sowas insgesamt sehr großes Interesse besteht.
[/OT]

[JHo]

Der Umweg ginge so: Die Calendar-Info wird erst in ein weekprofile (bzw. in ein topic@weekprofile) übersetzt und von dort aus mit den weekprofile-Methoden gespeichert bzw. verteilt. Soweit ich das richtig verstanden habe, kann das auch (geänderte) Wochenlisten an MAX senden (und CUL_HM, HMCCUDEV,...).

Bin Nutzer von Weekprofile und fände das auch sehr interessant und hilfreich. Ich habe (auch) deshalb bei der Heizung auf MAX gesetzt, weil es anders als Z-Wave-Aktoren mit den Wochenprofilen autark ohne FHEM funktionieren kann. Wenn jetzt zu dieser Sicherheit noch der Komfort einer Kalenderlösung dazu käme... ein Traum!

[Plextor]

Ich kann mir nicht vorstellen, dass ein MAX-User etwas gegen diese tolle Idee einzuwenden hätte... 

+1

[Wzut]

@Beta-User , ich bin da für alles offen. Da ich eh noch ganz am Anfang stehe ist es sowieso wichtig Ideen und Wünsche zu sammeln um danach eine Marschrichtung festzulegen als jetzt einfach mal blind in irgend eine Richtung zu rennen.

Aber da du jetzt schon konkret weekprofile angesprochen hast : das kommt IMHO ins Spiel sobald es sich lohnt an einem ganzen Wochenprogramm zu schrauben  -> Stichwort Schichtplan. Bei einem einmaligen Ausnahmefall ala nur mal eben morgen denke ich ist es einfacher und sinnvoller direkt über MAX_Temperature zu gehen. Wie auch immer, der zweite Schritt ist mit den Autoren der diversen Kalendermodule zusammen zu arbeiten um überhaupt den jeweiligen Kalendereintrag innerhalb der MAX Module zu habe. DS_Starter als Autor von SSCAL hat mir schon Unterstützung zugesagt, ich denke von den anderen werde ich sie auch bekommen sobald ich konkret sagen kann was ich denn überhaupt will und ggf. zusätzlich benötige.

[Beta-User]

Kein Ding.

Deine Idee hatte ich so verstanden, dass es grundsätzlich darum geht, jeweils den auf dem Device gespeicherten Wochenplan zu ändern und das Teil weiter autonom "wursteln" zu lassen, oder? Die Alternative wäre, sowas wie einen "holiday/Party-Modus"-Befehl aus dem nächsten Kalender-Event abzuleiten, der dann das eigentliche Wochenprofil nur zeitweilig überlagert? Oder wolltest du temporär eine zeitlich befristete "manuelle" Kontrolle von FHEM aus über die Thermostate übernehmen (analog dem, was z.B. WeekdayTimer macht)?

Die weekprofile-Idee ging zunächst mal von ersterem aus, was auch 1:1 auf die HM-Varianten übertragbar sein sollte:
So wie ich weekprofile verstanden hatte, kann das nämlich bereits jetzt selbst entscheiden, ob auf Basis einer Änderung z.B. nur für den Folgetag dann auch nur für diesen einzelnen Tag Änderungen an das Thermostat übertragen werden sollen, das minimiert afaik also bereits eventuellen Datenverkehr zu den Thermostaten; sollte das also die Überlegung hinter einer eigenen Lösung sein, wäre es evtl. sinnvoll, da mit @risiko mal zu sprechen, wie das konkret für welchen Device-Type aussieht. Er war auch bei der WeekdayTimer-Sache sehr hilfsbereit (hatte aber nur begrenzt Zeit), von daher könnte es sich lohnen, das näher zu beleuchten.
Im Hinterkopf habe ich auch noch den Eindruck, dass weekprofile aus einer Zeit stammt, die sehr MAX- (und FHT-irgendwas) geprägt war, von daher ist das credits-Thema da vermutlich ziemlich oben auf der Prio-Liste .

(Interessant finde ich dann die Frage, wie man den "Calendar-Modus" mit einem "Default-Modus" verheiratet und dann wieder auf den "Normalplan"-Modus zurückkommt. Aber auch das könnte man ggf. durch einen "einfachen" Vergleich zwischen einem unabgewandelten weekprofile, den auf dem Device befindlichen Profilen und den Kalenderangaben von heute irgendwie regeln; auch der Spagat zwischen "so viel wie nötig ins EEPROM schreiben" und das gleichzeitig zu minimieren ist ein spannender Aspekt!).

[Risiko]

Hallöchen.

Ich biete hier mal meine Unterstützung an.
Es ist richtig, dass weekprofile nur die Änderungen und nicht das ganze Profil an das Device\Thermostat sendet.
Somit wären meiner Meinung nach auch "einmalige Ausnahmefälle" einstellbar ohne viel Traffic zu erzeugen. So jedenfalls meine Annahme.
Sehe auch keinen Vorteil das direkt über das Device, z.B. auf manuell setzen, zu machen. Das autarke Arbeiten der Thermostate ohne FHEM war\ist mir auch wichtig.

Bin mal auf die weiteren Diskussionen gespannt.

Risiko.

[Wzut]

oh je da habe ich wieder was angefangen .... aber schauen wir uns doch mal an wie so etwas laufen könnte :
(eigentlich müsste man das als Flußdiagramm malen)
a. der User trägt irgend etwas in seinen Kalender ein das dafür sorgen soll das sich etwas an einem Thermostat ändert.
b. die heutigen FHEM Module (Calender,CALVIEW,SSCal) lesen den Kalender und stellen die eingetragenen Termine in Readings da.

c. hier fehlt nun eine Instanz die diese Readings prüft und entscheidet ob es nötig ist andere Module zu informieren.
Diese Arbeit könnte z.b. von einer sub in der 99_myUtils gemacht werden einem eigenen Modul oder von weekprofile direkt.

d. die Instanz unter c. ist der Meinung es handelt sich beim eingetragenen Termin um ein Ereignis über das weekprofile informiert werden muß und die Startuhrzeit ist auch erreicht dann macht weekprofile ganz normal Herstellerunabhängig weiter
e. es ist kein Termin für weekprofile sondern einer für ein Thermostat direkt dann muß diese Info direkt weiter zu den zusändigen Modulen (MAX , CUL:HM ) usw.

Bei diesem Ablauf hätte ich Null Arbeit, denn woher das Stellkomando kommt ist dem MAX Modul völlig egal, es versucht es auszuführen und gibt eine eventuelle Fehlermeldung zurück. Wenn dies der Ablauf sein sollte führen wir die Diskussion am falschen Ort.

was ich machen könnte wäre bei Punkt c. einsteigen , weekprofile informieren oder ein MAX Device.
Würde für MAX User keinen Unterschied machen, ist dann aber nicht mehr unabhängig vom Ziel Device, denn ich glaube kaum das ein HM User ein MAX Device definiert um dann via Kalendereintrag sein HM Thermostat zu steuern.

[Beta-User]

oh je da habe ich wieder was angefangen .... aber schauen wir uns doch mal an wie so etwas laufen könnte :
(eigentlich müsste man das als Flußdiagramm malen)
[...]

Ich find's grundsätzlich super, dass jemand das Thema aufgreift!

Vor meinem geistigen Auge entsteht grade das Bild eines generalisierten Moduls, das nicht nur auf dem Weg Calendar (u.ä.) Temperatur-"Profilabweichungen"  erhält, sondern z.B. auch von Telegram&Co. her angesteuert werden könnte:

Code Auswählen Erweitern

set <zentralmodul> overdrive <devspec für Thermostate> <desired-temp> <von [[[YYYY]MM]DD]> <bis ...>

Code Auswählen Erweitern

set <zentralmodul> changeProfile_once <devspec für Thermostate> <desired-temp> <von [[[YYYY]MM]DD]HH:mm> <bis ...>

Code Auswählen Erweitern

set <zentralmodul> changeProfile_permanent_day <devspec für Thermostate>  <ab [[[YYYY]MM]DD]> <bis ...> <Profil>


Code Auswählen Erweitern

set <zentralmodul> [...] Dann bräuchte man nur eine Art "plugin-System", das Timer verwaltet und ggf. z.B. WeekdayTimer für temporäre Änderungen "überschreibt" (oder Urlaubsmodi bei CUL_HM für kommende Perioden setzt, zwischen manuell und auto umschaltet usw.) und überwacht, wann welcher Timer temporär oder dauerhaft an beliebige Temerartusteuerdevices gegeben werden sollen bzw. dann auch wieder auf den Ausgangszustand / ein Standardprofil (gem. topic@weekprofile) zurückgekehrt werden soll.

Das würde es ermöglichen, ein paar Muster-Eventhandler zu zeigen, die dann jeder auf seine Bedürfnisse anpassen kann (z.B. Start- und Endezeit aus dem Calendar-Event (z.B. der Erinnerung) zu entnehmen, Ort kann dann ein einzelnes Thermostat sein oder ein room=..., dazu noch die Soll-Temperatur im Betreff).

"Eigentlich" sollte das nicht sooo schwer sein, es sollte jedenfalls von der Grundanlage her als modulares System möglich sein...

Bin aber mal gespannt, welche Ideen dazu noch kommen.

(Und ja, dieser Forumsbereich ist irgendwie unpassend, aber was soll's...)

[Wzut]

"Eigentlich" sollte das nicht sooo schwer sein, es sollte jedenfalls von der Grundanlage her als modulares System möglich sein...

nein ist es IMHO auch nicht, aber wie immer : Ideen haben und umsetzen sind zwei Paar Schuhe wobei ich dir zutraue das du das schaffst
Aber der Ansatz ist schon richtig und brauchen tut man aus dem Kalender "nur" drei Felder : Start , Ende und Titel/Beschreibung.
Start und Ende sind klar, die Syntax für die Beschreibung hängt vom Endgerät ab, die kennt aber eh jeder der das Endgerät auch schon einsetzt.
D.h. im einfachsten Fall steht da einfach ein Set Kommando, das blind weitergegeben wird. Sollte der User da Mist eingetragen haben reagiert das Enddevice schon mit einer entsprechenden Fehlermeldung.

[Beta-User]

Danke für die Blumen, das wäre vermutlich tatsächlich zu schaffen... Aber da waren ein paar Baustellen, die mir im Moment wichtiger wären .

Es ist schon richtig, dass der User sein jeweiliges Endgerät kennt und daher "nur" den "passenden" Kalendereintrag oä. erstellen muß. MMn. bringt das ganze aber erst dann einen richtigen Mehrwert, wenn es Befehl und Hardware abstrahiert und im Prinzip ein universeller Befehl ausreicht, um eine beliebige Gruppe von Geräten zu steuern, (also 1-n Geräte, ohne dass es eine Beschränkung gäbe, dass die alle dieselbe Hardware/Technik/... nutzen).

Wäre also eigentlich eher eine Art "extension" zu weekprofile?

Will mich aber nicht komplett rausmogeln: V.a., wenn dazu Anpassungen an WeekdayTimer (das z.B. Z-Wave- oder Bluetooth-Thermostate ohne eigene Wochenpläne verwalten kann) erforderlich wären: Gerne...

[OT @Risiko]
Willkommen an Bord 
und gleich eine Frage: Wäre es möglich, weekprofile so anzupassen, dass bei configDB-Nutzung die cfg in die configDB abgespeichert wird? (Das dürfte nur kleine Anpassungen an den Speicher- und Leseanweisungen erfordern, fhem.pl stellt dafür Mechanismen bereit). Hätte den Vorteil, dass der Teil - wie manches andere auch - in der Datenbankfile liegt und daher ggf. einfacher umgezogen werden kann...[/OT]

[Risiko]

Hallo Beta-User,

mir ist noch nicht klar, wie so eine Erweiterung für weekprofile aussehen könnte, damit es einfach bleibt und wirklich einen Mehrwert bringt.
Ansonsten macht es aus meiner Sicht keinen Sinn. Jedenfalls nicht für weekprofile. Dann schon eher ein neues Modul. Dafür habe ich aber keine Zeit.

Code Auswählen Erweitern


set weekprofile changeProfile_once <base_profile> <desired-temp> <von [[[YYYY]MM]DD]HH:mm> <bis ...>

könnte ich mir vorstellen. Den Rest deiner Beispiele leider nicht.

Zum Thema configDB.
1. Könntest du es bitte im weekprofile Thread anbringen. Da gehört es hin
2. Wenn es technisch machbar ist, dann sicherlich
3. Leider habe ich da keine Erfahrung. Müsste mich erstmal damit beschäftigen und ggf. im Development-Bereich nachfragen oder weißt du was Konkreteres?

[Wzut]

Müsste mich erstmal damit beschäftigen und ggf. im Development-Bereich nachfragen oder weißt du was Konkreteres?

Ist realtiv einfach und habe ich bei allen meinen Modulen die Dateien schreiben/lesen : Immer zum schreiben FileWrite und zum lesen FileRead benutzen,
da diese beiden Funktionen configDB unterstützen, so hat es Udo schon oft hier im Forum geschrieben.