Modul weekprofile + FHEMWEB widget

[kadettilac89]

das hast du falsch verstanden.

tempON
Temperature für 'on'. z.B. 30
tempOFF
Temperature für 'off'. z.B. 4

Wenn du ein wenig zurückblätterst siehst du die Diskussion dazu. Der Wunsch war, dass eine Variable gesetzt werden kann und diese im weekprofile ersetzt wird. Eine Variable damit man nicht so viel klicken muss.

Aktuell wird bei OFF der Wert 00.0 gesetzt und du hast immer ein geschlossenes Thermostat ... außer in deinem Wohnzimmer würde die Temp darunter liegen.

Ich vermute, dass Risiko mit der Umsetzung noch nicht ganz fertig ist. Ich habe nicht gesehen, dass er die Funktion als Neuerung kommuniziert hat.

Interessehalber habe ich mal den Sourcecode angesehen und das Modul zum Test etwas angepasst ... wenn man in der Sub noch on/off durch die entsprechenden Werte ersetzt kann man das ans Thermostat senden. Neu die letzten if-Staements. Aber am besten einfach warten

Code Auswählen Erweitern


##############################################
sub weekprofile_sendDevProfile(@)
{
  my ($device,$prf,$me) = @_;
  my $type = weekprofile_getDeviceType($me, $device,"SND");
 
  return "Error device type not supported" if (!defined ($type)); 
  return "profile has no data" if (!defined($prf->{DATA}));

    my $tempON = AttrVal($me, "tempON", undef);
    my $tempOFF = AttrVal($me, "tempOFF", undef);
 
  if ($type eq "WEEKPROFILE") {
      my $json = JSON->new;
      my $json_text = undef;
     
      eval ( $json_text = $json->encode($prf->{DATA}) );
      return "Error in profile data" if (!defined($json_text));
     
      return fhem("set $device profile_data $prf->{TOPIC}:$prf->{NAME} $json_text",1);
  }

  my $devPrf = weekprofile_readDevProfile($device,$type,$me);
 
  # only send changed days
  my @dayToTransfer = ();
  foreach my $day (@shortDays){
    my $tmpCnt =  scalar(@{$prf->{DATA}->{$day}->{"temp"}});
    next if ($tmpCnt <= 0);
   
    if ($tmpCnt != scalar(@{$devPrf->{$day}->{"temp"}})) {
      push @dayToTransfer , $day;
      next;
    }
   
    my $equal = 1;
    for (my $i = 0; $i < $tmpCnt; $i++) {

if ( ($prf->{DATA}->{$day}->{"temp"}[$i] eq "on" ) && defined($tempON) ) {
$prf->{DATA}->{$day}->{"temp"}[$i] = $tempON;
}

if ( ($prf->{DATA}->{$day}->{"temp"}[$i] eq "off" ) && defined($tempOFF)) {
$prf->{DATA}->{$day}->{"temp"}[$i] = $tempOFF;
}


[Risiko]

Hallo zusammen,

ich bin leider aktuell sehr eingespannt und konnte somit noch nicht mit der Umsetzung beginnen.
Steht aber auf der ToDo Liste.
Aktuell sollte On bzw. durch die jeweiligen Werte aus den Attributen ersetzt werden. Je nach Thermostat wird das aber anders interpretiert.

Risiko.

[treborst]

Hallo Risiko,

alles klar, keine Eile, der Sommer ist noch fern 
Problem erkannt ist schon mal ein gutes Statement.
Ich nutze Homematic HM-CC-RT-DN Thermostate und da funktioniert aktuell nur "OFF"; "ON" wird ebenfalls als "OFF" interpretiert.

Vielen Dank für dein Modul

Gruß
Robert

[Risiko]

Interessehalber habe ich mal den Sourcecode angesehen und das Modul zum Test etwas angepasst ... wenn man in der Sub noch on/off durch die entsprechenden Werte ersetzt kann man das ans Thermostat senden. Neu die letzten if-Staements. Aber am besten einfach warten

Ich muss hier nochmal nachhacken.
Aktuell ist es so, dass on und off direkt zum Device gesendet wird. Bei MAX kann man z.B. desiredTemperature on setzen. Wenn das bei HM nicht geht, dann müsste man wirklich on,off durch die entsprechenden Werte ersetzen. Bei MAX ist das jedenfalls nicht notwendig.

[Risiko]

Ich nutze Homematic HM-CC-RT-DN Thermostate und da funktioniert aktuell nur "OFF"; "ON" wird ebenfalls als "OFF" interpretiert.

Dann ist das meiner Meinung nach ein Fehler in CUL_HM. Im Log sollte beim Senden (verbose 4) off bzw on richtig stehen.

[kadettilac89]

Ich muss hier nochmal nachhacken.
Aktuell ist es so, dass on und off direkt zum Device gesendet wird. Bei MAX kann man z.B. desiredTemperature on setzen. Wenn das bei HM nicht geht, dann müsste man wirklich on,off durch die entsprechenden Werte ersetzen. Bei MAX ist das jedenfalls nicht notwendig.

Ich konnte das Verhalten von treborst reproduzieren - off wird mit Temperatur 0.0 °C zurückgeliefert obwohl on gesetzt wurde.

Verständnisfrage, welches Verhalten ist gewünscht bzw. vorgesehen?

on = weekprofileparameter tempON
off = weekprofileparameter tempOFF

ODER

on = <HM-Heizkörper>-R-dayTemp
off = <HM-Heizkörper>-R-nightTemp
---> hier auch Antwort auf deine Frage: Ja, HM unterstützt auch ein on/off. Die R-**Temp-Werte sollten dann intern verwendet werden.

Ich ging davon aus, dass die Werte aus weekprofile tempON/OFF ersetzt und gesetzt werden sollten, darum hab ich im Modul die Werte ersetzt. Es gab vor kurzem eine Diskussion genau in die Richtung. Wenn nicht, wofür sind die Parameter?

... ich denke dass noch irendwo eine Abfrage was anderes zurückliefert o. ä. vielleicht auch weil HM ggf. anders reagiert als MAX.

Wenn du mir sagst, welches Verhalten du einbauen möchtest kann ich am Wochenende nochmal testen und schaun ob ich was finde.

EDIT: ich glaube ich weiß was das Verhalten verursacht.

Man kann zwar set desired-temp on / off setzen. - OK so weit. Da bleibt auch der Wert mit on/off im Device.

ABER

wenn man die Templiste mit on setzen will wird 00.0 als Temperatur gesetzt.

set <heizkörper>_Clima tempListWed 24:00 on
wird so gespeichert:         R_4_tempListWed   24:00 00.0

Mit der Temperatur 00.0 kann dein Master-weekprofile natürlich nichts mehr anfangen. Ob nun das CUL_HM fehlerhaft ist, oder der Thermostat einfach nur numerische Werte akzeptiert weiß ich nicht.

[Risiko]

set <heizkörper>_Clima tempListWed 24:00 on
wird so gespeichert:         R_4_tempListWed   24:00 00.0

Mit der Temperatur 00.0 kann dein Master-weekprofile natürlich nichts mehr anfangen. Ob nun das CUL_HM fehlerhaft ist, oder der Thermostat einfach nur numerische Werte akzeptiert weiß ich nicht.

Das ist meiner Meinung nach genau das Problem. Bei MAX sind on=30.5 und off=4.5.
Aktuell sind die Attribute tempOff bzw. tempOn primär für die FHEMWEB-GUI. Zwischen diesen Werten wird in 0.5° die Dropdownlist gefüllt. Im Wochenplan stehen nicht die Werte sondern off bzw. on und es wird auch on\off gesendet.

Da es bei MAX egal ist, ob man off oder <= 4.5 sendet würde ich jetzt zur Vereinheitlichung doch on/off durch die entsprechenden Werte ersetzen und dann die Werte ans Thermostat senden. Beim Lesen dann natürlich anders herum.
Anbei eine Version zum testen wo das so umgesetzt sein sollte.

Risiko

EDIT: Neue Version angehangen

[kadettilac89]

Test sieht schon mal gut aus..

Paramter im Thermostat

Code Auswählen Erweitern


tempOFF  5
tempON   29

Ausgangssituation

Code Auswählen Erweitern


Tue 00:00-24:00 11.0 °C

Werte neu gesetzt und gespeichert

Code Auswählen Erweitern


Tue 00:00-10:00 11.0 °C 10:00-14:00 off °C 14:00-16:00 11.0 °C 16:00-20:00 on °C 20:00-24:00 off °C

Nachdem Thermosat Befehle abgearbeitet hatte

Code Auswählen Erweitern


R_3_tempListTue    10:00 11.0 14:00 05.0 16:00 11.0 20:00 29.0 24:00 05.0

Anzeige master

Code Auswählen Erweitern


Tue 00:00-10:00 11.0 °C 10:00-14:00 0off.0 °C 14:00-16:00 11.0 °C 16:00-20:00 on.0 °C 20:00-24:00 0off.0 °C


Sobald der master-Heizplan aktuallisiert wurde, wird on / off  als 0off.0 oder on.0 angezeigt. ... vermutlich durch regex beim Ersetzen.

Noch eine Frage, ist es gewollt, dass im Temperatur-Dropdown die Werte genau von ON - OFF auswählbar sind? Für den FAll, dass ON auf 21 °C gesetzt wird ist es nicht möglich eine höhere Temperatur einzutragen. Z. B. höhere Temperatur für eine halbe Stunde am Morgen.

[Risiko]

Hallo kadettilac89,
danke fürs testen.

Sobald der master-Heizplan aktuallisiert wurde, wird on / off  als 0off.0 oder on.0 angezeigt. ... vermutlich durch regex beim Ersetzen.

Verstehe ich leider nicht. Wie sehen denn die Readings vom Device aus?

Noch eine Frage, ist es gewollt, dass im Temperatur-Dropdown die Werte genau von ON - OFF auswählbar sind? Für den FAll, dass ON auf 21 °C gesetzt wird ist es nicht möglich eine höhere Temperatur einzutragen. Z. B. höhere Temperatur für eine halbe Stunde am Morgen.

Das kommt aus der Philosophie von MAX.
Alle größeren Werte als On (bei MAX 30.5) werden so on (30.5) reduziert. Bei Off (4.5) alles was kleiner ist. Daher kann man ein MAX nur Werte in diesem Bereich setzen. Deshalb ist es so umgesetzt. On bzw. begrenzen also den Wertebereich. Das ist doch beim HM auch so, oder?

[kadettilac89]

Hallo kadettilac89,
danke fürs testen.

gerne

Verstehe ich leider nicht. Wie sehen denn die Readings vom Device aus?

Ich teste hier "Schweinereien". Ich habe als ON / OFF ganze Gradwerte gesetzt. Ohne dem Punkt und der dezimalen Null.
5 statt 5.0

Dadurch hat Regex dann nicht alles ersetzt. Du könntest beim speichern des Attributes ggf. immer .0 anhängen wenn es eine ganze Zahl ist. Damit sollte es dann funktionieren.

Das kommt aus der Philosophie von MAX.
Alle größeren Werte als On (bei MAX 30.5) werden so on (30.5) reduziert. Bei Off (4.5) alles was kleiner ist. Daher kann man ein MAX nur Werte in diesem Bereich setzen. Deshalb ist es so umgesetzt. On bzw. begrenzen also den Wertebereich. Das ist doch beim HM auch so, oder?

Das ist bei HM genau so ... denke ich. Ich meine es anders.

Beispiel.
tempOFF  17     .... wäre die Temperatur für Abwesenheit
tempON   21     .... wäre die Temperatur für Anwesenheit

Im Dropdown ist dann nur OFF, 17.5, 18.0, 18.5, 19.0, 19.5, 20.0, 20.5, ON
Es ist aber nicht möglich z. B. 24 zu setzen. Kommt aus der fhemweb_weekprofile.js, da setzt du bei Zeile 567 den min- und maxwert auf die beiden Temperaturen aus dem Parameter. Das sind dann die Begrenzer in Schleife 584.

Das wäre hinderlich wenn das Bad den ganzen Tag auf 21 Grad sein soll, nur morgens für eine halbe Stunde auf 24 wenn die Kinder drin sind. Ich würde den Bereich auf 4.5 - 30.5 (Maximum) belassen, und zusätzlich am Anfang OFF einfügen, am Ende noch ON.

[Risiko]

Du könntest beim speichern des Attributes ggf. immer .0 anhängen wenn es eine ganze Zahl ist. Damit sollte es dann funktionieren.

Kann ich machen.

Ich meine es anders.

Beispiel.
tempOFF  17     .... wäre die Temperatur für Abwesenheit
tempON   21     .... wäre die Temperatur für Anwesenheit

Dafür waren die Attribute nie gedacht! Sondern für den Wertebereich entsprechend der Thermostate. Ggf. werde ich weitere Variablen einführen. Ist hier ja schonmal diskutiert worden.

[Tom_S]

kurze Frage. Nutzt jemand das attr "widgetEditOnNewPage"
wenn ich das gesetzt habe, kann ich das Profil nicht mehr ändern. Habe jetzt lange gesucht, und festgestellt, das es nur daran liegt.
Ich habe es jetzt noch mal auf einem anderen System getestet. Mit dem gleichen Ergebnis. Auf das Zahnrad klicken -> Temperatur ändern -> speichern, und alles ist wie es war. Ich meine das hat schon mal funktioniert.

LG Tom

[treborst]

Hallo Risiko, Hallo kadettilac89,

habe die Diskussion, welche um meine Frage entstanden ist, mit Interesse verfolgt-
Leider ist der Ausgang nicht in meinem Sinne, da ich die Funktion "Temp_ON"/"Temp_OFF" anders verstehe als es jetzt umgesetzt wurde.

Nach meinem Verständnis hat "ON" bzw "OFF" nichts mit einer Temperatur zu tun, sondern soll die Ventilstellung dauerhaft auf "ON" (100%) bzw. "OFF" (0%) stellen.
Für das von kadettilac89 beschriebene Szenario gibt es die Register "R-nightTemp" und "R-dayTemp"; diese Voreinstellungen lassen sich beliebig nach unten oder oben korrigieren.

Bis zu meiner Anfrage hat es ja auch schon "zur Hälfte" funktioniert, die Vorgabe "OFF" wurde richtig umgesetzt, das Ventil ist dauerhaft geschlossen.
Nur der Wert "ON" wurde im Thermostat falsch gesetzt (OFF statt ON)

Mit der jetzigem Umsetzung wird der im Userattribut "weekprofile" hinterlegte Wert für ON bzw. OFF (bei mir 4 bzw. 34) im Thermostat eingetragen.
Die Einstellung des Ventils bleibt aber weiterhin auf "OFF" also 0% unabhängig vom geforderten Wert (OFF/ON)

Mit der Umsetzung dass ich für "ON/OFF" einen unteren bzw. oberen Wert definieren muss, kann ich leben (auch wenn das für ein HomeMatic Thermostat nicht nötig sein sollte).
Aber bitte setzt es so um, dass bei "ON" das Ventil zu 100% geöffnet ist.

Das Modul "Weekprofile" ist für mich eine lang gesuchte Lösung, da mir der Umgang mit den HM_Info Templates zu umständlich war und ich nach einer Umsetzung mit GUI lange gesucht habe.
Deshalb ist es mir wichtig, dass wegen unterschiedlicher Ansichten vorhandene Funktionen nicht "verbogen" und damit nicht mehr brauchbar werden.

Freue mich auf den Fortgang der Diskussion.

Grüße
Robert

[Risiko]

kurze Frage. Nutzt jemand das attr "widgetEditOnNewPage"
wenn ich das gesetzt habe, kann ich das Profil nicht mehr ändern. Habe jetzt lange gesucht, und festgestellt, das es nur daran liegt.
Ich habe es jetzt noch mal auf einem anderen System getestet. Mit dem gleichen Ergebnis. Auf das Zahnrad klicken -> Temperatur ändern -> speichern, und alles ist wie es war. Ich meine das hat schon mal funktioniert.

LG Tom

Hallo Tom,

ich schaue es mir bei Gelegenheit mal an.

[Risiko]

Mit der jetzigem Umsetzung wird der im Userattribut "weekprofile" hinterlegte Wert für ON bzw. OFF (bei mir 4 bzw. 34) im Thermostat eingetragen.
Die Einstellung des Ventils bleibt aber weiterhin auf "OFF" also 0% unabhängig vom geforderten Wert (OFF/ON)

Hier unterscheiden sich leider HM und MAX. Da bei MAX Temperaturen <= OFF  (4.5°) Ventil zu und Tempertauren >=on (30.5) Ventil 100% auf bedeutet, habe ich kürzlich eben statt on/off zu senden auf die korrespondierenden Temperaturen umgestellt. Für MAX ergibt sich da keine Änderung. Das heißt also, wenn man bei HM eine Temperatur kleiner als R-nightTemp sendet, geht das Ventil nicht automatisch auf Off?