Modul weekprofile + FHEMWEB widget

[bismosa]

Hallo!

Da wir heute mal wieder im kalten saßen, da die Heizung noch auf Werktag gestellt war, habe ich mir weekprofile mal wieder genauer angeschaut und die Funktion "useTopics" entdeckt.
Genau das, was ich gebrauchen kann  Mal "eben schnell" alle Thermostate umprogrammieren.

2 kleine Probleme, die ich dabei nun hatte:
1.) Ich nutze nur 4 Zeitprogramme für jedes Profil. Schön wäre es, wenn man ein komplettes Topic kopieren könnte...würde etwas klickerei ersparen...gerade, wenn da mal mehrere Profile hinzukommen.

2.) Mir fehlt ein wenig die Kontrolle, ob ich bei allen Thermostaten den richtigen Plannamen vergeben habe. Ich hatte die Commandref so verstanden, dass diese Kontrolle mit

Code Auswählen Erweitern

get <name> profile_references *
durchführen kann. Hier kommt jedoch nichts...und mit

Code Auswählen Erweitern

get <name> profile_references <Planname>
kommt nur "0"

Habe ich etwas übersehen?

Gruß
Bismosa

[Risiko]

Hallo Bismosa,

da ich aktuell im Urlaub bin nur kurz folgendes:
zu 1:
Eine Kopie erstellen geht doch ganz einfach. Zu kopierendes Profil auswählen und "+" Button in FHEMWEB drücken. Oder mit dem Befehl "set copy_profile"
zu 2:
Da hast du was falsch verstanden. Referenzen sind dafür dar, ein Profil mehrfach z.B. für zwei Thermostate ohne Kopie verwenden zu können. Die Zuordnung zum Thermostat erfolgt über das userAttr "weekprofile", was du in den Thermostatdefinitionen verwenden musst.

Hast du dir schon den wiki-Artikel https://wiki.fhem.de/wiki/Weekprofile durchgelesen?

Mehr dann ggf. im neuen Jahr.
Risiko.

[bismosa]

Hallo!

Ist ja alles nicht so eilig. Ich wünsche einen schönen Urlaub!

zu 1) Ja...das erstellt eine Kopie von einem Profil. Ich würde mir eine Funktion wünschen, die gleich alle Profile eines Topics kopiert. 

zu 2.) Stimmt. Gelesen habe ich den Wiki-Eintrag. Aber bin wohl mit den Begrifflichkeiten durcheinander geraten  Also würde ich mir hier noch eine Funktion wünschen, die anzeigt welche Geräte (ggf. mit welchem Profil) verbunden sind. Dann hat man noch eine Überprüfung, ob man sich vielleicht irgendwo vertippt hat 

Und wo wir hier gerade bei "wünsch dir was" sind...
3.) Soweit ich weiß, könntest Du die "userAtrr" auch Global vorgeben, das man dies nicht mehr unter "userAttr" eintragen muss. Richtig genial (ich weiß aber nicht, ob FHEM das kann) wäre es, wenn es nur bei unterstützten Geräten des Moduls diese Attribute auftauchen.

Bitte nicht falsch verstehen! Ich finde das Modul SUPER!  Ich bin da ein totaler Fan von. Es sind auch nur Vorschläge...ich weiß...besser wäre gleich einen Patch zu liefern...aber dazu komme ich leider derzeit nicht. Außerdem weiß ich nicht, ob diese Funktionen überhaupt von anderen Usern bzw. von Dir gewünscht wären 

Schönen Urlaub weiterhin!

Gruß
Bismosa

[Risiko]

zu 1) Ich würde mir eine Funktion wünschen, die gleich alle Profile eines Topics kopiert. 

Ok. Verstehe leider noch nicht wirklich den Sinn. Man muss dann doch ehe alle Profile noch bearbeiten. Vielleicht könntest du deinen Anwendungsfall etwas formulieren. Ggf. könnte ich mir einen Befehl "set copy_topic" vorstellen. In die GUI (FHEMWEB) wie beim "+" würde ich aber verzichten wollen.

zu 2.)  Also würde ich mir hier noch eine Funktion wünschen, die anzeigt welche Geräte (ggf. mit welchem Profil) verbunden sind. Dann hat man noch eine Überprüfung, ob man sich vielleicht irgendwo vertippt hat 

Halte ich auch für sinnvoll. Muss ich mir mal überlegen, wie dass aussehen könnte. Wird aber etwas dauern.

3.) Soweit ich weiß, könntest Du die "userAtrr" auch Global vorgeben, das man dies nicht mehr unter "userAttr" eintragen muss. Richtig genial (ich weiß aber nicht, ob FHEM das kann) wäre es, wenn es nur bei unterstützten Geräten des Moduls diese Attribute auftauchen.

Das würde ich nicht automatisch machen bzw. mache ich mit Absicht nicht, da nicht alle User diese Verbindung wollen\benötigen. UserAttr sollten jeweils explizit vom User gesetzt werden. Ggf. könnte ich mir aber ein Befehl wie "set add_userAttr_to_devices" vorstellen, der das Setzen übernimmt. Sehe ich aber nicht als wichtig.

Risiko.

[bismosa]

Hallo!

Vielleicht könntest du deinen Anwendungsfall etwas formulieren

Ich versuche es mal...
Topic "default" mit 4 Profilen (Wohnzimmer, Kinderzimmer, Bad, Schlafzimmer).
Nun habe ich ein neues Topic erstellt:
"Urlaub" ebenfalls mit diesen 4 Profilen, wo die Einstellungen zu den 4 Profilen (Default) aber sehr ähnlich sind.

Also quasi eine 1:1 Kopie des gesamten Topics mit allen Profilen, damit diese dann wieder angepasst werden können. Diese Profile benötige ich ja auch, da ja alle Heizkörper auf diese Profile reagieren.

Man muss dann doch ehe alle Profile noch bearbeiten

Auch wieder wahr. Vielleicht habe ich auch nur zu kompliziert dabei gedacht. Es ist halt auch ein wenig Einstellerei am Anfang einfach notwendig.

Halte ich auch für sinnvoll. Muss ich mir mal überlegen, wie dass aussehen könnte. Wird aber etwas dauern.

Ich hatte ja die Funktion "get <name> profile_references *" falsch verstanden. Ich hätte hier eher die Funktion "device_profiles" erhofft.
Hier mal Quick&Dirty was ich erwartet hätte:

Code Auswählen Erweitern

  $list .= ' device_profiles:noArg';
  if($cmd eq "device_profiles") {
my $retHTML = "";
   
    foreach my $dev (@{$hash->{SNDDEVLIST}}){
      my $prfName = AttrVal($dev->{NAME},"weekprofile",undef);       
      next if (!defined($prfName));
     
      Log3 $me, 5, "$me(Set): found device $dev->{NAME}";
  $retHTML .= "$dev->{NAME} - $prfName <br>";
    }
return $retHTML;
  }
 
  $list =~ s/ $//;
  return "Unknown argument $cmd choose one of $list";
}
###########################################

Hier wird nur eine Liste erzeugt mit Gerätename - Profilname. Ist auf jeden Fall schon mal sehr hilfreich 
Schöner wäre es vielleicht, wenn diese Liste immer in den Internals auftaucht (Irgendwo hatte ich das neulich noch gesehen...finde es aber gerade nicht wieder).
Kann bestimmt auch noch verbessert werden....z.B. Geräte ohne das Reading mit anzeigen etc.

Wird aber etwas dauern.

Ist ja alles nicht eilig 

Das würde ich nicht automatisch machen bzw. mache ich mit Absicht nicht, da nicht alle User diese Verbindung wollen\benötigen. UserAttr sollten jeweils explizit vom User gesetzt werden. Ggf. könnte ich mir aber ein Befehl wie "set add_userAttr_to_devices" vorstellen, der das Setzen übernimmt. Sehe ich aber nicht als wichtig.

Ja...Nein. Nicht die Attribute per Code verändern. Das wäre zu gefährlich, das da was überschrieben bzw. ungewolltes verändert wird. Ich habe gerade mal versucht mich einzulesen. Wenn ich es richtig verstanden habe geht es so:
addToAttrList($attrib); -> Attribut zu Global hinzufügen -> in allen Geräten verfügbar
addToDevAttrList($name, $attrib); -> Attribut zu einem Device hinzufügen -> Nur bei dem Device verfügbar

Schade, schön wäre es, wenn man die Attribute für bestimmte Devices (gefiltert mittels Devspec oder so) festlegen könnte. Sonst muss man ja laufend prüfen, ob ein neues Gerät hinzugekommen ist? Keine Ahnung, wie das funktioniert.

Gruß
Bimsosa

[bismosa]

Und was ich noch vergessen habe:

Ich finde das Modul wirklich super! Das soll kein Meckern sein, sondern sind alles nur "freie" Vorschläge 

Und was ich noch vergessen habe:

(Irgendwo hatte ich das neulich noch gesehen...finde es aber gerade nicht wieder)

So etwas lässt mir ja keine Ruhe...aber ähnlich ist es z.B. im ReadingsWatcher gelöst. Allerdings über Readings:

Code Auswählen Erweitern

Readings
alive 0 07.01.2020 21:47
devices 1 07.01.2020 21:47
readings 0 07.01.2020 21:47
state ok 07.01.2020 21:47
timeoutdevs none 07.01.2020 21:47
timeouts 0 07.01.2020 21:47

Und die Devices erscheinen auch unter "Probably associated with"

Außerdem wird hier auch das Attribut in Global erstellt um es bei jedem Device hinzuzufügen. Vielleicht ist das ja eine gute Vorlage?

Gruß
Bismosa

[Risiko]

Hallo Bismosa,

danke für deine Ausführungen.
Leider habe ich aktuell wenig Zeit.
Werde mir aber bei  Gelegenheit mal Gedanken machen und mich dann wieder melden.

Risiko.

[Moerk]

Hallo,

erstmal vielen Dank an Risiko und die vielen Tester und Ideengeber hier die dieses tolle Modul entwickelt haben.

Ich habe das gleiche Verhalten wie Vrob01 beobachtet, welches eine Nutzung von ON/OFF mit MAX! Thermostaten nicht erlaubt:

Das habe ich schon probiert, dann setzt er die Temperatur zwar korrekt auf 30.0°C (oder 5°C), aber eben nicht auf on/off. Bei MAX sind die Werte 4.5°C und 30.5°C spezielle Werte mit denen die Thermostate dauerhaft auf 0% bzw. 100% Öffnung gesetzt werden können

Da er das in seinem ersten Post gut erläutert hat mache ich das hier nicht noch mal.

Das Problem ist hier tatsächlich in dem Modul "MaxCommon.pm" welches den erlaubten Temperaturbereich zwischen 5 und 30 Grad, sowie den Schlüsselwörtern "on" und "off" festlegt.

Man kann leider nicht einfach diese Schlüsselwörter in die Attribute ,,tempON" und ,,tempOFF" übernehmen, da dann das Drop-Down Menü für die Temperaturauswahl im Widget nicht mehr gefüllt wird.

Auch wenn Risiko das Modul so entwickelt hat das es möglichst wenig Device-spezifische Optionen enthält, habe ich eine Eingebaut um dieses verhalten abzufangen (3 Zeilen ab Zeile 415).

Wenn die Werte für ON/OFF 4.5 bzw. 30.5 sind werden die entsprechenden Schlüsselwörter in die Temperatur übernommen (aber eben nur bei diesen beiden Werten und bei MAX!) und nicht mehr die hinterlegten Werte.

Dadurch kann man nun on und off nutzen, habe es getestet mit Heizungs- und Wandthermostaten.
Da ich nur die MAX! Geräte habe und keinen HM wäre es toll wenn das jemand noch mal einsetzen kann der HM hat um auszuschließen das es hier unerwünschte Nebeneffekte gibt.

Viele Grüße, Mirko

[Risiko]

Hallo Moerk,

meiner Meinung nach ist es ein Fehler in MaxCommon.pm.
Ein

Code Auswählen Erweitern


set <device> desiredTemperature 4.5

wird auch automatisch in off umgesetzt.
Bei

Code Auswählen Erweitern


set <device> weekprofile Fri 4.5,6:00 ....

gibt es den beschriebenen Fehler. Ich habe die Erwartungshaltung, dass hier 4.5 (oder kleiner) auch automatisch in off umgesetzt wird. Natürlich äquivalent für on.

Wenn ich mal Zeit hätte, würde ich sogar einen Patch für den neuen Maintainer wzut bereitstellen 

Vielleicht kann es ja jemand anderes bei Ihm anbringen. Ich selbst nutze on|off nicht.

Risiko

[Wzut]

Ich habe die Erwartungshaltung, dass hier 4.5 (oder kleiner) auch automatisch in off umgesetzt wird

nur Erwartungen zu haben nützt nichts,  da Wzut schon ein alter Mann ist beherrscht er die Kunst des Gedankenlesens nicht und so muss man mit ihm ganz altmodisch reden (bzw. schreiben)

[Risiko]

So hier !? 
https://forum.fhem.de/index.php/topic,107753.msg1017180.html#msg1017180

[Moerk]

Guten Morgen,

vielen Dank an Risiko für die weitere Analyse und Einschätzung und an Wzut für die Aufnahme und den Fix.
Nun funktioniert die on/off Geschichte einwandfrei, ohne meinen Eingriff 

Viele Grüße,
Mirko

[Wzut]

kein Problem

dass hier 4.5 (oder kleiner) auch automatisch in off umgesetzt wird. Natürlich äquivalent für on.

erlaubt ist jetzt aber auch nur 4.5 bzw 30.5 zusätzlich. Ich kann natürlich noch vor dem senden auch kleiner 4.5 in 4.5 wandlen falls das in irgendeiner Form Sinn macht.
Bei on dann halt alles oberhalb 30.5

[Risiko]

Ich denke, dass ist nicht so wichtig und zudem Ansichtssache. Werte kleiner off bzw. größer on kann über FHEMWEB keiner senden.
Wenn es trotzdem vorkommt, dann ist eine Fehlermeldung evtl. sogar angebrachter. Hier hat der User einen Fehler gemacht (Konfiguration, etc.)

Risiko.

[Risiko]

Hallo.

Auf Grundlage von 

bismosa

Beitrag habe ich einen neuen get Befehl (nur bei Verwendung von Topics)

Code Auswählen Erweitern


get <weekprofile> associations 0|1

eingebaut.
Der zweite Parameter steuert nur das Ausgabeformat (0 - HTML Tabelle, 1-json Liste).

In einer Ausbaustufe könnte ich mir auch vorstellen, dass man in der HTML Ansicht gleich die Verbindung setzen kann. Profil bei jedem Device dann als Dropdown auswählbar.
Dann macht\führt auch der Bediener die Verbindung explizit und das Atribut 'weekprofile' wird dann ins Device gesetzt.
Ob das an diese Stelle (FHEMWEB uiDialog) mgl. ist, weiß ich noch nicht.

Morgen dann per Update verfügbar.

Risiko