Vitoconnect - Verbesserte Version

Begonnen von stefanru, 14 Dezember 2024, 23:32:17

Vorheriges Thema - Nächstes Thema

Beta-User

Kurzer Zwischenstatus, hatte bisher aber weiter kaum Zeit, in den Code zu schauen:
- Bisher hatte ich kein "mapping"-Attribut gesetzt, demnach ist es "svn-Mapping". Falls der "eigentlich gewollte" default ein anderer ist: Warum stellen wir das nicht um?
- Der Versuch, einen Zeitplan zu setzen, ergibt (in der Konstallation) weiter auch mit der aktuellen Version die "Unbekannter setter"-Rückmeldung und ein "Aktion_Status"-Reading mit einem "Fehler ..."; wenn der Plan wieder gelesen wird, ist er weiter unverändert (habe nur an einer Stelle 5 Minuten früher angegeben).

Ursache für die Rückmeldung ist imo das "return;" in Verbindung mit dem "defined-or" in Zeile 1401 (dto für #1397). Also entweder das raus (kein "// ''") oder die Abfrage in Zeile 1405 ändern?

(Generell ist die Code-Doppelung an der Stelle unschön; auf die Schnelle unterscheidet sich das nur durch Bindestrich statt Unterstrich? Vielleicht könnte man an einer zentralen Stelle die Übersetzungstabelle unterbringen?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

stefanru

#166
Hi Beta-User,

ok jetzt ist mir alles klar.
Du verwendest SVN-Mapping.
Ich hatte alle fixe nur für das vitoconnect_raw_readings gemacht.

Das erklärt warum du den Fehler noch bekommen hast mit unknown value.
Das ist ab morgen gefixed.

Das Setzen der Scheduler habe ich auch nur für vitoconnect_raw_readings.

Solche neuen Features wollte ich eigentlich nicht mehr in den alten Mapping Methoden einbauen.
Ich kann aber mal schauen ob ich das doch irgendwie einfach eingebaut bekomme.
Man muss das Argument etwas massieren, dass es die API nimmt. So wie es von ihr geliefert wird geht es nicht im Setter.
Da muss ich mir meine Heizung mal auf SVN umstellen und das einbauen.
Kann aber etwas dauern.

Gruß,
Stefan

Beta-User

Lass mal gut sein, das muss einfacher werden....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

stefanru

Ja da gebe ich dir recht.
Das einfachste ist die raw readings zu nehmen und die API zu lesen und zu schreiben was das SetNew macht.
Ganz ohne diese Mappings.

Die Mappings habe ich eigentlich nur wegen der Kompatibilität drin.
Klar wir könnten noch SVN und Roger verheiraten, aber eigentlich wollte ich da keinen Aufwand mehr spendieren.

Am liebsten wäre mir die Nutzer stellen auf SetNew, also vitoconnect_raw_readings um.
Dann könnte ich das ganze Mapping Zeug entfernen und das Modul wäre 2/3 kürzer.

Gruß,
Stefan

Beta-User

Zitat von: stefanru am 09 März 2025, 21:59:18Am liebsten wäre mir die Nutzer stellen auf SetNew, also vitoconnect_raw_readings um.
Dann könnte ich das ganze Mapping Zeug entfernen und das Modul wäre 2/3 kürzer.
Was hindert dich, diesen Schritt zu tun?

Imo kann ja jeder user die alte Version beibehalten, dem das nicht gefällt...

Der erste Schritt wäre, für neue User das Setzen der Mappings-Attribute zu verhindern und "new" als default zu verwenden, damit noobs wie ich gleich die Variante verwenden, die du eigentlich haben willst.

Ungetesteter Vorschlag - der erfordert imo nur, dass man als Attributwert für "vitoconnect_raw_readings" auch "svn" zuläßt:
    if  (AttrVal( $name, 'vitoconnect_mapping_roger', 0 )) {
        #use roger setters
        $return = vitoconnect_Set_Roger ($hash,$name,$opt,@args);
    }
    elsif  ( AttrVal( $name, 'vitoconnect_raw_readings', 'svn') eq 'svn' ) {
        #use svn setters
        $return = vitoconnect_Set_SVN ($hash,$name,$opt,@args);
    }
    else {
        #use new dynamic parsing of JSON to get raw setters
        $return = vitoconnect_Set_New ($hash,$name,$opt,@args);
    }
Müßte man halt entsprechend ankündigen, aber die Betroffenen, die erst mal noch beim alten (svn-) Mapping bleiben wollen, haben die Chance dazu.

Danach können wir immer noch sehen, wie/ob man den Kompabilitätslayer drin läßt. Zumdindest auf den ersten Blick sieht das sehr nach "suchen und ersetzen" aus, um es einzukürzen und zu vereinheitlichen.

Dazu dann noch ein paar Log-Einträge wegen gesetzter "alter" Attribute - dann würde ich erst mal abwarten, wie groß der "Aufschrei" ist ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#170
Mahlzeit.

Habe mich mal versucht... Ist noch nicht fertig, aber zumindest wird jetzt per default das "raw-mapping" verwendet, und die "Dynamisierung" der "Roger"-Sets sieht zumindest auf den ersten Blick auch ok aus.

Später ggf. mehr, muss jetzt mal Schluss machen.

Hatte übrigens auch das "disconnected"-Problem nach einem update einer der Fritzboxen, Neustart nach update der anderen (zentralen) hat geholfen.

Das mit dem shedule setzen ging jetzt auch.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

Zitat von: Beta-User am 10 März 2025, 19:06:23Später ggf. mehr, muss jetzt mal Schluss machen.
Hier mal der diff und ein paar Erläuterungen dazu:
diff --git a/98_vitoconnect.pm b/98_vitoconnect.pm
index ce4b367..2c866d0 100644
--- a/98_vitoconnect.pm
+++ b/98_vitoconnect.pm
@@ -1,5 +1,5 @@
 #########################################################################
-# $Id: 98_vitoconnect.pm 29740 2025-03-09 16:03:37Z stefanru $
+# $Id: 98_vitoconnect.pm 29740 2025-03-10 Beta-User $
 # fhem Modul für Viessmann API. Based on investigation of "thetrueavatar"
 # (https://github.com/thetrueavatar/Viessmann-Api)
 #
@@ -1275,7 +1275,7 @@ sub vitoconnect_Initialize {
       . "vitoconnect_mappings:textField-long "
       . "vitoconnect_translations:textField-long "
       . "vitoconnect_mapping_roger:0,1 "
-      . "vitoconnect_raw_readings:0,1 "                 # Liefert nur die raw readings und verhindert das mappen wenn gesetzt
+      . "vitoconnect_raw_readings:0,1,svn "             # Liefert nur die raw readings und verhindert das mappen wenn auf 1 gesetzt; svn-Mapping, wenn auf svn gesetzt
       . "vitoconnect_disable_raw_readings:0,1 "         # Wird ein mapping verwendet können die weiteren RAW Readings ausgeblendet werden
       . "vitoconnect_gw_readings:0,1 "                  # Schreibt die GW readings als Reading ins Device
       . "vitoconnect_actions_active:0,1 "
@@ -1385,26 +1385,26 @@ sub vitoconnect_Set {
     Log3($name,5,$name." - Set val: $val, Set Opt: $opt");
    
     # Hier richtig?
-    return "set ".$name." needs at least one argument" unless (defined($opt) );
+    return "set $name needs at least one argument" if !defined $opt;
    
     # Setter für Device Werte rufen
-    my $return;
-    if  (AttrVal( $name, 'vitoconnect_raw_readings', 0 ) eq "1" ) {
-        #use new dynamic parsing of JSON to get raw setters
-        $return = vitoconnect_Set_New ($hash,$name,$opt,@args);
-    }
-    elsif  (AttrVal( $name, 'vitoconnect_mapping_roger', 0 ) eq "1" ) {
+    my $more_sets;
+    if  (AttrVal( $name, 'vitoconnect_mapping_roger', 0 )) {
         #use roger setters
-        $return = vitoconnect_Set_Roger ($hash,$name,$opt,@args);
-    }
-    else {
+        $more_sets = vitoconnect_Set_Roger ($hash,$name,$opt,@args);
+    }
+    elsif  ( AttrVal( $name, 'vitoconnect_raw_readings', 1) eq 'svn' ) {
         #use svn setters
-        $return = vitoconnect_Set_SVN ($hash,$name,$opt,@args);
+        $more_sets = vitoconnect_Set_SVN ($hash,$name,$opt,@args);
+    }
+    else {
+        #use new dynamic parsing of JSON to get raw setters
+        $more_sets = vitoconnect_Set_New ($hash,$name,$opt,@args);
     }
    
     # Check if val was returned or action executed with return;
-    if (defined $return) {
-      $val .= $return;
+    if (defined $more_sets) {
+      $val .= $more_sets;
     } else {
       return;
     }
@@ -2183,9 +2183,11 @@ sub vitoconnect_Set_SVN {
 sub vitoconnect_Set_Roger {
     my ($hash,$name,$opt,@args ) = @_;  # Übergabe-Parameter
 
-    if ($opt eq "HK1_Betriebsart" )                  {   # set <name> HKn_Betriebsart: sets HKn_Betriebsart to heating,standby
+    my $hknum;
+    if ($opt =~ m{HK([\d+]).Betriebsart} )                  {   # set <name> HKn_Betriebsart: sets HKn_Betriebsart to heating,standby
+    $hknum = $1 - 1;
         vitoconnect_action($hash,
-            "heating.circuits.0.operating.modes.active/commands/setMode",
+            "heating.circuits.$hknum.operating.modes.active/commands/setMode",
             "{\"mode\":\"$args[0]\"}",
             $name,$opt,@args
         );
@@ -2610,33 +2612,56 @@ sub vitoconnect_Set_Roger {
         return;
     }
 
-    my $val = "WW_einmaliges_Aufladen:activate,deactivate "
-        ."WW_Zirkulationspumpe_Zeitplan:textField-long "
-        ."WW_Zeitplan:textField-long "
-#       ."WW_Haupttemperatur:slider,10,1,60 "
-        ."WW_Solltemperatur:slider,10,1,60 "
-        ."WW_Temperatur_2:slider,10,1,60 "
-        ."WW_Betriebsart:balanced,off "
-        ."Urlaub_Start_Zeit "
-        ."Urlaub_Ende_Zeit "
-        ."Urlaub_stop:noArg ";
-
-    if (ReadingsVal($name,"HK1_aktiv","0") eq "1") {
-        $val .=
-             "HK1_Heizkurve_Niveau:slider,-13,1,40 "
-            ."HK1_Heizkurve_Steigung:slider,0.2,0.1,3.5,1 "
-            ."HK1_Zeitsteuerung_Heizung:textField-long "
-            ."HK1_Urlaub_Start_Zeit "
-            ."HK1_Urlaub_Ende_Zeit "
-            ."HK1_Urlaub_stop:noArg "
-            ."HK1_Betriebsart:active,standby "
-            ."HK1_Soll_Temp_comfort_aktiv:activate,deactivate "
-            ."HK1_Soll_Temp_comfort:slider,4,1,37 "
-            ."HK1_Soll_Temp_eco_aktiv:activate,deactivate "
-            ."HK1_Soll_Temp_normal:slider,3,1,37 "
-            ."HK1_Soll_Temp_reduziert:slider,3,1,37 "
-            ."HK1_Name ";
+    my $separator = '_';
+   
+    my $val = "WW${separator}einmaliges_Aufladen:activate,deactivate "
+        ."WW${separator}Zirkulationspumpe_Zeitplan:textField-long "
+        ."WW${separator}Zeitplan:textField-long "
+#       ."WW${separator}Haupttemperatur:slider,10,1,60 "
+        ."WW${separator}Solltemperatur:slider,10,1,60 "
+        ."WW${separator}Temperatur_2:slider,10,1,60 "
+        ."WW${separator}Betriebsart:balanced,off ";
+    if ($separator eq '_') { #Set_Roger
+        $val .= "Urlaub_Start_Zeit "
+        ."Urlaub_Ende_Zeit "
+        ."Urlaub_stop:noArg ";
+    } else { #svn setters
+        $val .= "Urlaub_Start "
+        . "Urlaub_Ende "
+        . "Urlaub_unschedule:noArg ";
+    }
+
+    for my $i (1..3) {
+    if ( ReadingsVal($name,"HK${i}${separator}aktiv",0) ) {
+        $val .=
+         "HK${i}${separator}Heizkurve_Niveau:slider,-13,1,40 "
+        ."HK${i}${separator}Heizkurve_Steigung:slider,0.2,0.1,3.5,1 "
+        ."HK${i}${separator}Zeitsteuerung_Heizung:textField-long "
+        ."HK${i}${separator}Betriebsart:active,standby,heating,dhw,dhwAndHeating,forcedReduced,forcedNormal ";
+        if ($separator eq '_') { #Set_Roger
+            $val .= "HK${i}_Urlaub_Start_Zeit "
+            ."HK${i}_Urlaub_Ende_Zeit "
+            ."HK${i}_Urlaub_stop:noArg "
+            ."HK${i}_Soll_Temp_comfort_aktiv:activate,deactivate "
+            ."HK${i}_Soll_Temp_comfort:slider,4,1,37 "
+            ."HK${i}_Soll_Temp_eco_aktiv:activate,deactivate "
+            ."HK${i}_Soll_Temp_normal:slider,3,1,37 "
+            ."HK${i}_Soll_Temp_reduziert:slider,3,1,37 ";
+        } else { #svn setters
+            $val .= "HK${i}-Urlaub_Start "
+            . "HK${i}-Urlaub_Ende "
+            . "HK${i}-Urlaub_unschedule:noArg "
+            . "HK${i}-Betriebsart:active,standby,heating,dhw,dhwAndHeating,forcedReduced,forcedNormal "
+            . "HK${i}-Solltemperatur_comfort_aktiv:activate,deactivate "
+            . "HK${i}-Solltemperatur_comfort:slider,4,1,37 "
+            . "HK${i}-Solltemperatur_eco_aktiv:activate,deactivate "
+            . "HK${i}-Solltemperatur_normal:slider,3,1,37 "
+            . "HK${i}-Solltemperatur_reduziert:slider,3,1,37 ";
+        }
+        $val .= "HK${i}${separator}Name ";
+    }
     }
+=pod
     if (ReadingsVal($name,"HK2_aktiv","0") eq "1") {
         $val .=
             "HK2_Heizkurve_Niveau:slider,-13,1,40 "
@@ -2669,6 +2694,7 @@ sub vitoconnect_Set_Roger {
           . "HK3_Solltemperatur_reduziert:slider,3,1,37 "
           . "HK3_Name ";
     }
+=cut
    
     return $val;
 }
@@ -2683,8 +2709,8 @@ sub vitoconnect_Attr {
     Log(5,$name.", ".$cmd ." vitoconnect_: ".($attr_name // 'undef')." value: ".($attr_value // 'undef'));
     if ($cmd eq "set")  {
         if ($attr_name eq "vitoconnect_raw_readings" )      {
-            if ($attr_value !~ /^0|1$/)                     {
-                my $err = "Invalid argument ".$attr_value." to ".$attr_name.". Must be 0 or 1.";
+            if ($attr_value !~ /^0|1|svn$/)                     {
+                my $err = "Invalid argument $attr_value to $attr_name. Must be 0, 1 or svn.";
                 Log(1,$name.", vitoconnect_Attr: ".$err);
                 return $err;
             }
@@ -3516,7 +3542,7 @@ sub vitoconnect_getResourceCallback {
             foreach my $key ( sort keys %$properties ) {
                
                
-                my $Reading = "";
+                my $Reading;
                
                 if ( scalar keys %translations > 0) {
                    
@@ -3540,20 +3566,20 @@ sub vitoconnect_getResourceCallback {
                  # Use build in Mapping Roger (old way)
                  $Reading = $RequestListRoger->{ $feature->{feature} . "." . $key };
                 }
-                else {
+                elsif ( AttrVal( $name, 'vitoconnect_raw_readings', 1 ) =~ m{0|svn}x ) {
                  # Use build in Mapping SVN (old way)
                  $Reading = $RequestListSvn->{ $feature->{feature} . "." . $key };
                 };
 
-                if ( !defined($Reading) || AttrVal( $name, 'vitoconnect_raw_readings', 0 ) eq "1" )
-                {  
-                    $Reading = $feature->{feature} . "." . $key;
-                }
-               
                 if ( !defined($Reading) && AttrVal( $name, 'vitoconnect_disable_raw_readings', 0 ) eq "1" )
                 {  
                     next;
                 }
+
+                if ( !defined $Reading && AttrVal( $name, 'vitoconnect_raw_readings', 1 ) !~ m{0|svn}x )
+                {  
+                    $Reading = $feature->{feature} . ".$key";
+                }
                
                 my $Type  = $properties->{$key}->{type};
                 my $Value = $properties->{$key}->{value};
@@ -4023,6 +4049,7 @@ sub vitoconnect_DeleteKeyValue {
 
 1;
 
+__END__
 
 =pod
 =item device
"vitoconnect_raw_readings" hätte damit einen weiteren zulässigen Wert "svn". Über den schaltet der Code zwischen dem neuen default "raw" und dem alten default "svn" um, wer also die svn-Variante haben will, kann die auf diesem Weg bekommen, muss aber eingreifen.

Anders gesagt: ganz ohne, dass man irgendwelche Attribute setzen müßte, bekommt man damit die raw-Mappings und setter :) .

Ein gesetztes "roger"-Mapping hat Vorrang, wer also bisher (warum auch immer) beide Attribute gesetzt hatte, bekommt "anders komische" Ergebnisse - sollte verschmerzbar sein.

Bei der sub vitoconnect_Set_Roger() habe ich (am Ende der Funktion zu finden) mal angefangen, die set-Befehle aus beiden mappings zusammenzuführen und nur da wirklich zu unterscheiden, wo es echte Unterschiede in der Benennung gibt, so dass sich das später ggf. leichter zusammenführen ließe, wenn man das will.
Der Teil beginnend mit
if ($opt =~ m{HK([\d+]).Betriebsart} )
ist für den Moment als Beispielcode gedacht, wie man das via pattern-match soweit reduzieren kann, dass man nicht 6 if-Aufrufe an unterschiedlichen Stellen braucht, um letztlich dasselbe zu bewirken. Ob das tatsächlich wie gedacht funktioniert, habe ich allerdings nicht getestet; wäre gut, wenn sich da jemand finden würde, der eine der alten mapping-Varianten nutzt und das auch weiter tun will (sonst gibt das halt eine Trockenübung, bis sich jemand beschwert?).

Meine Bitte wäre: Falls das auch aus deiner Sicht in die richtige Richtung geht, würde ich erst mal versuchen, den Code an diesen Stellen vollends zu verschlanken, die Doku entsprechend nachzuziehen, und mich dann erst an das Thema weekprofile zu machen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

stefanru

Hi Beta-User,

wow, da hast du dir ja viel Arbeit gemacht.
Ich finde die Idee, dass Raw Readings der neue Standard wird, großartig. Als neuer Entwickler hatte ich mich jedoch nicht getraut, gleich eine inkompatible Änderung vorzunehmen.

Nun wäre ich aber bereit dazu. Ich denke, es gibt noch nicht so viele Benutzer, und wir sollten sicherstellen, dass die Dokumentation aktuell ist, bevor wir die Änderung freigeben. Am besten machen wir im ersten Beitrag auch darauf aufmerksam.

Mit deiner Änderung ist gewährleistet, dass neue Nutzer automatisch Raw Readings verwenden. Das finde ich eine tolle Idee, da ich SVN und Roger nicht mehr warten möchte und sie am liebsten aussterben lassen würde. Sollte sich die API in irgendeiner Weise ändern, möchte ich diese nicht nachziehen müssen. Bei Raw Readings geht das wahrscheinlich automatisch oder mit geringem Aufwand.

Zurzeit komme ich nicht wirklich dazu, und bald steht auch wieder Urlaub an.

Du kannst gerne weitermachen, ich bin voll dabei. Wann ich die Zeit finde, das dann zu übernehmen, weiß ich aber noch nicht genau. Es kann noch etwas dauern.

Bugfixes mache ich weiterhin, aber ich glaube, das Modul ist im jetzigen Zustand funktionell ganz rund.

Natürlich abgesehen von der Weiterentwicklung, die du vorschlägst.

Passt das so für dich und hat es etwas Zeit?

Danke und Gruß,
Stefan

Beta-User

Zitat von: stefanru am 10 März 2025, 22:38:38Als neuer Entwickler hatte ich mich jedoch nicht getraut, gleich eine inkompatible Änderung vorzunehmen
Völlig nachvollziehbar, hatte als "Neuling" auch lange Hemmungen, Dinge anzufassen, die vielleicht nicht allen gefallen...

Letztlich geht es aber darum, dass du was für die Allgemeinheit zur Verfügung stellst, und das sollte halt (vor allem ) auch deinen Vorstellungen entsprechen und halbwegs (aus deiner Sicht) wartbar sein ;) .

Zitat von: stefanru am 10 März 2025, 22:38:38SVN und Roger nicht mehr warten möchte und sie am liebsten aussterben lassen würde
Nachvollziehbar - beide sind imo "irgendwie zufällig" in der Benennung. Mein Vorschlag läuft daraus hinaus, das soweit zu vereinfachen und zu vereinheitlichen, dass es mit überschaubarem Aufwand wartbar bleibt.
Und direkt nach der Übernahme eines Moduls ist eigentlich ein guter Zeitpunkt, da ist in der Regel die Bereitschaft der anderen User noch größer, Fehler zu "tolerieren", zu melden und mit zu fixen ;) .

Generell finde ich die "raw"-Benennung nicht besonders toll - mein Vorschlag wäre an der Stelle allerdings, dass wir uns bei Gelegenheit mal darüber beugen und sowas wie einen "Muster-Reading/setter"-Rahmen für Wärmeerzeuger allgemein überlegen (so ähnlich, wie es das bei PV-Anlagen bereits gibt). Das Mapping würde ich dann aber "add-on" sehen ;) .

Was auch (aus noob-Sicht) verbesserungfähig ist, ist das mit dem Passwort: "fake" ist irgendwie ein Würgaround, und rename ist imo im Moment gar nicht abgedeckt...
Sowas "gleich" zu bereinigen, ist zwar Aufwand, aber der entsteht sonst später beim User-support.

Was die Zeitfrage angeht, kann es auch bei mir wieder etwas dauern, bis es effektiv weitergeht - ist schwer abschätzbar, aber für manche Eingriffe braucht man eben ein paar Stündchen mehr oder weniger am Stück, um das wieder auf einen vertretbaren Stand zu bringen.

Mal sehen, Danke auf alle Fälle für deine positive Rückmeldung :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#174
Bitte so kurz vor dem Urlaub nicht erschrecken - anbei mein aktueller Zwischenstand als diff und .pm...

Habe die mappings (hoffentlich) so vereinheitlicht, dass man nur noch einen Code braucht und nicht mehr alles doppelt pflegen muss (da scheinen aber ein paar Wackler auch im alten Code drin gewesen zu sein?).

Dann das mit decode_json() so umgestellt, dass "alte" Probleme in $@ nicht an der falschen Stelle missinterpretiert werden. Dazu eine Frage: Wenn das decode schief geht, startet nicht in allen Fällen wieder ein timer. Absicht?

Dann habe ich die ersten Bruchstücke mal in den Code übernommen für das weekprofile-Thema.
Falls da jemand weiter dran basteln mag: Es ginge im ersten Schritt darum, die Funktion aufrufen zu können und als Ergebnis einen Reading-Inhalt zu schreiben, der auch an die Therme versendet werden könnte (sowohl für WW wie HKn - also leicht unterschiedlich!). 
Die untere Funktion stammt aus dem ebus-Package, da werden auch "on/off"-Paare gesucht, wir brauchen das hier halt (für HKn) noch etwas ausdifferenzierter mit "comfort" und "normal"...
Der Plan wäre, das entweder als "Schlüsselwörter" gleich von weekprofile liefern zu lassen, oder (finde ich eleganter), die Abgrenzung anhand der Wunsch- ("Raum-") Temperaturen zu machen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

neworder

Ich habs wahrscheinlich überlesen: Wie stelle ich auf raw_readings um? Sorry für die vielleicht schon mal beantwortete Frage  O:-)

Beta-User

Zitat von: neworder am 12 März 2025, 19:20:36Ich habs wahrscheinlich überlesen: Wie stelle ich auf raw_readings um? Sorry für die vielleicht schon mal beantwortete Frage  O:-)
Meine Fassung: alle "mapping"-Attribute weglassen/löschen.

Aktuelle svn-Fassung: Das "raw-reading-Attribut" (vitoconnect_raw_readings) wie empfohlen auf "1" stellen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

neworder

weia, da hab ich jetzt aber wieder auf dem Schlauch gestanden bis ich die Attributes gefunden habe. DANKE!

neworder

Und gleich mal probiert: heating.circuits.0.operating.normal.temperature klingt zwar anders, aber setzen des Wertes funktioniert bestens.

8)

wieder einer weniger in der "alten Welt"

stefanru

Hallo Beta-User,

vor meinem Urlaub werde ich nicht einchecken. 😊

Vielen Dank für deine Arbeit! Nach meinem Urlaub, in etwa drei Wochen, werde ich deine Änderungen überprüfen, testen und dann einchecken.

In der Zwischenzeit sollten wir versuchen, möglichst viele User über den Breaking-Change zu informieren.
Ich werde im ersten Beitrag bereits einige Informationen aufnehmen und rot kennzeichnen.
Ab jetzt hat jeder drei Wochen Zeit, sich Gedanken darüber zu machen, wie er weiter verfahren möchte:

  • Entweder auf SVN umstellen, wenn die neue Version gezogen wird.
  • Oder auf RAW Readings umsteigen und die Änderungen mitmachen.

Es sollte klar sein, dass RAW Readings die Hauptentwicklungslinie sein wird.
Ja, die Readings sind länger, aber man kann sie mit stateformat (ich werde auch meine Templates bereitstellen) oder im TabletUI an seine Wünsche anpassen.

Ein großer Vorteil ist, dass die Readings im Device denen in der API entsprechen.
Das bedeutet, wenn man ein Problem hat, kann man direkt mit diesen Namen im Viessmann-Forum nachfragen.
Viessmann und alle anderen wissen dann genau, worüber man sprichst.

Danke und viele Grüße,
Stefan