Modul weekprofile + FHEMWEB widget

[Heimweh]

@Risiko

Ich benutze Chrome. Alle Änderungen werden richtig gespeichert in der cfg Datei, aber FHEM liest es nicht neu ein sondern zeigt immer alles an wie vor meiner Änderung.

[Risiko]

Hallo Heimweh,

ich verwende auch Chrome und kann keine Probleme feststellen.
Kannst du bitte verbose auf weekprofile auf 5 stellen und die Datei fhemweb_weekprofile.js mit Meldungen zum Test verwenden! Mit Logmeldungen und Messages posten.
Die Datei muss nach 'www/pgm2/'

[borsTiHD]

Hallo,

erstmal rießen Lob für das Plugin.
Ich finds klasse und nutze es ausgibig um meine Heizprofile zu verwalten, welche ich dann per Dummy Schalter meiner entsprechenden Schicht dann direkt auf meine Themorstate schicken lasse.

Allerdings vermisse ich ein gutes Feature, das ich früher bei meiner Qivicon nutzen konnte.
Die meiste Zeit über will ich egt meinen Thermostaten eine gewünschte Temperatur von 22°C schicken.
Doch hin und wieder (wenns draußen richtig kalt ist), hätte ich gerne eine gewünschte Temperatur von 23°C (ja das macht mir viel aus  ).
Und genau hier fehlt mir jetzt das Feature von der Qivicon... dort konnte man zwei Temperaturen als Variable festlegen und schnell ändern, was sich dann wiederum auf den Wochenplan ausgewirkt hatte, wo die zwei Variablen übernommen wurden.

Kurzgefasst, ich hätte gerne die Möglichkeit Variablen in dem Wochenplan, anstatt feste Temperaturen festzulegen.

Also anstatt:

Code Auswählen Erweitern

Mon 00:00-15:00 6.0 °C 15:00-22:00 22.0 °C 22:00-24:00 6.0 °C

So etwas:

Code Auswählen Erweitern

Mon 00:00-15:00 6.0 °C 15:00-22:00 $temp °C 22:00-24:00 6.0 °C

Dann könnte ich letzendlich meine "Wohlfühltemperatur" zentral anpassen und ändern, was sich wiederum auf alle meine Pläne auswirken würde (ich nutze Profile für meine unterschiedlichen Schichten: Frühschicht, Tagschicht, Spätschicht, Nachtschicht, Frei).
Ist nur ein Vorschlag, vielen Dank. 

[Risiko]

Hallo borsTiHD,

so richtig habe ich leider den Sinn noch nicht verstanden. Wieso machst du das nicht mit mehr Profilen. z.B. Spätschicht_22,Spätschicht_23? So häufig wirst du doch diese "Wohlfühltemperatur" nicht ändern, oder?
Wo soll die Temperatur für die Variable $temp definiert werden und was soll passieren, wenn sich dieser Wert ändert?

[borsTiHD]

Hi, erstmal danke für die schnelle Antwort. 
Ich habe derzeit 6 Wochenpläne erstellt, mit jeweils einer Aufteilung für 3 Raumbereiche (Bad, Schlafzimmer, Wohnbereich).
Damit komme ich auf insgesamt 18 unterschiedliche Pläne (Screenshot im Anhang).

Die Wochenpläne selbst habe ich keinem Thermostat zugewiesen, ich habe mir eine kleine Funktion gebaut in Verbindung mit einem Dummy Schalter (Screenshot im Anhang).
Sobald ich im Dummy Schalter beispielsweise Spätschicht anklicke, wird meinen Thermostaten entsprechend ihrer Zugehörigkeit, der Wochenplan "wp_Spaetschicht" mit dem Profil "Wohnbereich (da sind 3 Thermostate zugewiesen), Bad (1 Thermostat) und Schlafzimmer (1 Thermostat)" zugeteilt.

Soweit bin ich damit auch sehr zufrieden und das klappt wunderbar.
Jetzt habe ich aber in allen Plänen die festen 22°C drin stehen, zu den Zeiten an denen ich es gerne geheizt habe und 6°C zu den Zeiten an denen nicht geheizt werden soll.

Mein Wunsch wäre es jetzt, zu all diesen Zeiten in denen ich derzeit die festen 22°C drin habe, eine Variable stehen hab um bei Bedarf niedrigere, oder höhere Temperaturen einzustellen, ohne gleich 16 Wochenpläne anpassen zu müssen.
Ich würde also gerne über den Wochenplan nur noch die "Zeitpunkte" bestimmen an denen ich heize oder nicht heize und die Temperatur über ein zusätzliches Dropdown Menü anpassen.
Hoffe ich konnte es so besser erklären. 

€dit:
Achso, die 22°C und 23°C waren jetzt nur ein Beispiel.

Wo soll die Temperatur für die Variable $temp definiert werden und was soll passieren, wenn sich dieser Wert ändert?

Das wäre mir erstmal nicht sooo wichtig.
Schön wäre natürlich ein definierbares Devices für das Webinterface von FHEM (ähnlich meinem Dummy Schalter, nur mit einem Dropdown Menü für die Temperatur), aber auch ein Wert in einer Funktion unter "99_myUtils.pm", oder einer *.cfg fänd ich schon super.
Dann wünschenswert wäre wenn der Wochenplan einfach beim "senden" zu einem Thermostat den Wert aus der Variable nimmt.

Meinst du der Aufwand lohnt sich nicht entsprechend?

[Risiko]

Hallo borsTiHD,

habe ich verstanden. Könnte mir folgendes Vorstellen:

Ein Attribut in weekprofile mit einer Liste von Variablennamen z.B. tempVars = temp1,temp2,...tempN.
Diese tauchen dann auch als Readings auf (default 20°): temp1= 20°. Diese kann man dann natürlich ändern.
In den Wochenplänen kann man dann statt feste Werte die Variablennamen aus der Liste verwenden $temp1..$tempN
Bevor dann ein Wochenplan gesendet oder abgefragt wird, werden die Variablen entsprechend ihrer Werte aus den Readings ersetzt.
Beim erstellen der Wochenpläne in FHEMWEB tauchen die Variablennamen wie auch on,off in der Dropdownbox auf.

Denke, dass ist eine generische Lösung und hilft hoffentlich mehreren Leuten.
@All - ein kurzes Feedback dazu wäre super. Wann ich natürlich zu der Umsetzung komme, kann ich noch nicht sagen.

Noch eine Anmerkung zu deiner speziellen Konstellation. Ich bin der Meinung, dass man alles mit einem einzigen weekprofile durch Verwendung von Topics realisieren kann. Bei Topics kann man auch Referenzen auf andere Pläne machen! Hast du dir das schon mal angesehen?

[kadettilac89]

Denke, dass ist eine generische Lösung und hilft hoffentlich mehreren Leuten.
@All - ein kurzes Feedback dazu wäre super. Wann ich natürlich zu der Umsetzung komme, kann ich noch nicht sagen.

Hi risiko,

ich nutze weekprofile auch schon eine Weile und finde die Idee mit generischen Werten super.

Wie viele Variablen würdest du zusätzlich einbauen? Ich denke egal wie viele, entweder es sind zu wenige, oder es wird unübersichtlich.

Ein anderer Gedankengang:
1) Werte aus beliebigem Device per readingsval oder Funktionen übernehmen.
2) Im Weekprofile bräuchtest du ein Attribut namens "source" das default (nicht gesetzt) feste Werte im Weekprofile (wie jetzt) erwartet, wenn "source = generic" ist, wird die im Feld hinterlegte Funktion eingestellt. Das könnte ein readingsval, oder auch eine Funktion in 99_myutils sein.
3) Damit das visuell auch ansprechend bleibt, wäre die Ausgabe des aktuellen Wertes auch nett
4) Eine Funktion "refresh" oder so wäre dann auch nötig, um per event auf Änderungen reagieren zu können bzw. ein reload anzustoßen. "send_to_device" gibt es schon, müsste man testen ob das ausreicht. Hängt halt von der Implementierung ab.

Beispiel:
Dummy dy_Temperaturen hat ein UserReading, Temp1_day, Temp2_day, Temp3_day, Temp1_night... und so weiter. Damit könnte man sich beliebige Gruppen, Scenarien abbilden, der Rest wird dann gemacht wenn per notify auf eine Änderung reagiert wird.

Vorteil, völlig generisch
Nachteil, für weniger "geübte" mehr Fehlerquellen und Dokumentation etwas aufwändig.

[Risiko]

Hallo kadettilac89,

danke für deinen Vorschlag. Ganz verstanden habe ich ihn leider nicht. Du willst also, dass weekprofile aus einem Device Readings ausliest !?
Das ist aber nicht der Sinn des Moduls. Es soll eben relativ einfach Wochenpläne verwalten. Wenn die Pläne primär aus einem anderen Device kommen, dann ist das Ganze für mich Sinn frei oder ich hab es eben nicht verstanden

[kadettilac89]

Nein, weekprofile bleibt weiterhin das führende Device. Was ich vorschlage ist, die dynamischen Werte aus beliebigen Quellen per readingsval oder 99_myutils-Funktion.

Dein Vorhaben war diese dynamischen Werte als Attribut im Weekprofile zu pflegen wenn ich das richtig deute. Dadurch müssten die Werte wieder in den weekprofiles (mehrfach?) definiert werden.

Vielleicht haben wir ähnliche Ideen und reden aneinander vorbei.

Beispiel, ich hoffe, dass ich mich verständlicher ausdrücke ...

Source soll hier mal ein Dummy sein
Dummy namens dy_Temp
attr1: temp_day_1
attr2: temp_day_2
attr3: temp_day_3

Im Weekprofile ist folgender Zeitplan für einen Tag :
Mon   00:00-06:00   14.0 °C   06:00-07:00   16.0 °C   07:00-22:00   20.0 °C   22:00-24:00   16.0 °C

Die Werte werden aus dem Dummy übernommen
Mon   00:00-06:00   =dy_Temp-attr_day_1   06:00-07:00   =dy_Temp-temp_day_2   07:00-22:00   =dy_Temp-temp_day_3   22:00-24:00   =dy_Temp-temp_day_1

[Risiko]

Hallo kadettilac89,

ich denke, ich habe deinen Ansatz verstanden. Finde ihn aber zu kompliziert. Man müsste ja auch noch definieren, welches Plan man über dieses "fremde" Device (in deinem Beispiel das Dummy) manipulieren möchte. Weiterhin muss man meiner Meinung nach sehr viel Aufwand in das Dummy oder die Funktion stecken und ich wäre dann für den Support und Fragen verantwortlich! Finde ich nicht so prickelnd. Wer diesen Aufwand in einer 99_myutils-Funktion treiben möchte, kann dies jetzt auch schon tun. Er schreibt sich eine Funktion, die einen Wochenplan im json-Format zusammenstellt und ihn dann per set einfach an weekprofile übergibt\ändert!

Also kurzum, du hast mich noch nicht überzeugt 

Risiko.

[borsTiHD]

Frohes Neues erstmal an alle. 

Hallo borsTiHD,

habe ich verstanden. Könnte mir folgendes Vorstellen:

Ein Attribut in weekprofile mit einer Liste von Variablennamen z.B. tempVars = temp1,temp2,...tempN.
Diese tauchen dann auch als Readings auf (default 20°): temp1= 20°. Diese kann man dann natürlich ändern.
In den Wochenplänen kann man dann statt feste Werte die Variablennamen aus der Liste verwenden $temp1..$tempN
Bevor dann ein Wochenplan gesendet oder abgefragt wird, werden die Variablen entsprechend ihrer Werte aus den Readings ersetzt.
Beim erstellen der Wochenpläne in FHEMWEB tauchen die Variablennamen wie auch on,off in der Dropdownbox auf.

Denke, dass ist eine generische Lösung und hilft hoffentlich mehreren Leuten.
@All - ein kurzes Feedback dazu wäre super. Wann ich natürlich zu der Umsetzung komme, kann ich noch nicht sagen.

Ja genau, sowas meinte ich, danke das du dir dazu Gedanken machst. 
Würde mich freuen wenn du sowas umgesetzt bekommst.

Noch eine Anmerkung zu deiner speziellen Konstellation. Ich bin der Meinung, dass man alles mit einem einzigen weekprofile durch Verwendung von Topics realisieren kann. Bei Topics kann man auch Referenzen auf andere Pläne machen! Hast du dir das schon mal angesehen?

Hm... danke für den Hinweis, werde mich da die Tage mal einlesen und mal was ausprobieren.
Derzeit hab ich das wie gesagt mit dem einen Dummy Device als Schalter, mit dem ich quasi bestimme welche Schicht ich habe (der kleinere Screenshot von meinem vorherigen Post).
Darauf reagiert ein Notify, das eine Funktion aus meiner "99_myUtils.pm" öffnet und übergibt nur den Schichtnamen.

Die Funktion sieht derzeit so aus (Grundgerüst hab ich von jemand anderem hier im Forum übernommen und dann meinen Bedürfnissen angepasst, bzw umgeschrieben):

Code Auswählen Erweitern

# Heizungssteuerung mit Profilen
sub setTemp($) {
  my ($profil) = @_;

  if($profil eq "Komfort"){
    fhem( "set .*_Clima controlMode auto" );

fhem( "set wp_Komfort send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Komfort send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Komfort send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Komfort eingestellt." );
  }
  if($profil eq "Früh"){
    fhem( "set .*_Clima controlMode auto" );

fhem( "set wp_Fruehschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Fruehschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Fruehschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Frühschicht eingestellt." );
  }
  if($profil eq "Tag"){
    fhem( "set .*_Clima controlMode auto" );

fhem( "set wp_Tagschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Tagschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Tagschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Tagschicht eingestellt." );
  }
  if($profil eq "Spät"){
    fhem( "set .*_Clima controlMode auto" );

fhem( "set wp_Spaetschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Spaetschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Spaetschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Spätschicht eingestellt." );
  }
  if($profil eq "Nacht"){
    fhem( "set .*_Clima controlMode auto" );

fhem( "set wp_Nachtschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Nachtschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Nachtschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Nachtschicht eingestellt." );
  }
  if($profil eq "Sommer"){
    fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Sommer send_to_device default HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima,HM_2F8A1D_Clima,HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Sommer eingestellt." );
  }
  if($profil eq "Off"){
    fhem( "set .*_Clima controlMode manual" );
fhem( "set TelegrammBot message ♨ Heizungsplan wurde deaktiviert. Mode: manual" );
  }
}
# //Heizungssteuerung mit Profilen

[Rewe2000]

Hallo,

zuerst mal alles Gute im neuen Jahr 2018.

Wollte gerade mal weekprofile im Zusammenspiel mit einer CCU2 testen, aber irgendwie muss ich da etwas entscheidendes übersehen haben. Mein Fhem hängt sich nach dem Befehl "define <name> weekprofile" komplett auf. In der Oberfläche ist die eingefrorene Seite des weekprofiles noch zu sehen aber das wars auch schon.
Nach einem start des fhem Servers (Raspi3) fährt dieser wieder hoch, das Device weekprofile ist aber nicht mehr vorhanden.

"sudo apt-get install libjson-pp-perl" habe ich nachinstalliert, fhem ist aktuell, der Raspi wurde auch neu gestartet.

Im Log ist folgendes noch zu lesen:

Code Auswählen Erweitern

2018.01.03 15:26:17 2: HMCCURPC: Updated devices. Success=56 Failed=0
2018.01.03 15:26:17 1: Perfmon: possible freeze starting at 15:26:14, delay is 3.399
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/98_weekprofile.pm line 581.

Mit einem List des Device kann ich leider nicht dienen, da ich soweit erst gar nicht komme .

Hab ich da noch etwas übersehen?
Klappt das (derzeit) überhaupt nur mit HmIP Komponenten über eine CCU2 (HMCCU; HMCCURPC)?

Es wäre nett wenn mir jemand noch einen entsprechenden Hinweis geben könnte.

Hinweis:
Auch die Anlage über "define <name> weekprofile <MasterDevice>" liefert kein anderes Ergebnis. Versucht habe ich es mit einem HmIP-WTH-2.

Gruß Reinhard

[Risiko]

Hallo Rewe2000,

leider kann ich zum Thema CCU2 nicht viel beitragen, da ich keine habe.
Die Änderungen hierzu sind vom Mitglied vocaris. Ggf. ihn mal direkt anschreiben, wenn er hier.

Du benötigst "libjson-perl"!!

[Rewe2000]

Hallo Risiko,

danke für die Antwort, ich habe Fhem gemäß Wiki installiert, da war libjson-perl bereits dabei.
Ich habe die aktuelle Version (2.90-1) auf dem Raspi, sollte eigentlich passen.

Die aktuell im Repository von Fhem enthaltene Version von weekprofile sollte doch eigentlich die CCU2 unterstützen, oder muss ich dazu die "alte" Testversion hier im Forum laden?

Ich werde vocaris bitten, mir hierzu mal einen Tipp zu geben.
Oder gibt es User, welche das Modul zusammen mit einer CCU2 einsetzen?

Gruß Reinhard

[Risiko]

Ich habe die aktuelle Version (2.90-1) auf dem Raspi, sollte eigentlich passen.

Ich habe sogar nur 2.53-1. Welche perl Version verwendest du? Ein einfaches

Code Auswählen Erweitern

define test weekprofile geht schon nicht?

Die aktuell im Repository von Fhem enthaltene Version von weekprofile sollte doch eigentlich die CCU2 unterstützen, oder muss ich dazu die "alte" Testversion hier im Forum laden?

Ja. Wenn du direkt das Repository verwendest oder update in FHEM durchgeführt hast. Aktuell ist Rev. 15568
Im Anhang und morgen per Update eine  neue Version (Rev. 15778) mit verbesserter Fehlerbehandlung.