Weekprofile und Heating_Control

Begonnen von RMD, 28 Dezember 2016, 13:25:55

Vorheriges Thema - Nächstes Thema

RMD

Hallo.

Besteht die Möglichkeit, Profile aus dem Weekprofile direkt nach Heating_Control zu übertragen, quasi das die dort abgebildeten Zeiten gleich zum Steuern durch Fhem verwendet werden können?

Danke

amenomade

Hi.

Ich habe den gleichen Bedarf, um die Automatik von der FritzBox zur Steuerung von den FBDECT Thermostaten zu überschreiben. Da ich nix im Forum gefunden habe, habe ich folgendes gebastelt:

Script in 99_myUtils:
use JSON;

sub
DecodeWeekprofile($$$$)
{
     my ($HCdevice,$device,$wp,$profile) = @_;
     my $json = fhem ("get $wp profile_data $profile");
     my $result = decode_json( $json );
     my $day;
     my $wert;
     my $output="";
     my %weekday = ( 'Mon' => '1', 'Tue' => '2', 'Wed' => '3', 'Thu' => '4', 'Fri' => '5', 'Sat' => '6', 'Sun' => '0');
     while ( ($day,$wert) = each($result) ) {
           my @timetable = @{@{$wert}{"time"}};
           my @temptable = @{@{$wert}{"temp"}};
           my $l = scalar @timetable;
           $output = $output.$weekday{$day}."\|00:05\|". $temptable[0]." ";

           if ($l > 1) {
                foreach my $i (0..$l-2) {
                     $output = $output.$weekday{$day}."\|".$timetable[$i]."\|". $temptable[$i+1]." ";
                }
           }
     }
     fhem( "defmod $HCdevice Heating_Control $device $output" );
     Log 1,("DecodeWeekprofile $device, $wp, $profile: $output on $HCdevice\n");
}


Notify auf dem Weekprofile, der das HC definiert/ändert:
define nt_kuWp notify ku_wpHeizung { DecodeWeekprofile("ku_HC", "Heizung_Kueche","ku_wpHeizung", "default") }

Gruß
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Panik

#2
Hallo amenomade,

ich habe dein Codeschnipsel hier gefunden und wollte es mal einbauen.
Leider hat sich wohl über die Zeit an Perl in Fhem was geändert, denn ich bekomme den Fehler:

Experimental each on scalar is now forbidden at ./FHEM/99_myUtils.pm line 953. Type of arg 1 to each must be hash or array (not private variable) at ./FHEM/99_myUtils.pm line 953, near "$result) "


Hast du zufällig ein angepasstes Codestück?
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Kann WeekdayTimer mittlerweile ootb...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Panik

Hallo Beta-User,

Danke. Das funktioniert. Bzw. funktionierte schon vor meiner Anfrage.

Weekdaytimer ist nur ein Zwischenschritt bei meiner Ansteuerung.
D.h. ich muss dann sowiso nochmal in die 99MyUtils und was eigenes anfügen.
Von daher wollte ich im Nebeneffekt den Park der Module verringern und in
einer eigenen Funktion vorher noch das entsprechende weekprofile abklappern...

Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Das mit myUtils verstehe ich nicht. WeekdayTimer kann direkt das Wochenprofil aus weekprofile auslesen bzw. auch weekprofile weiß, wie es WeekdayTimer ansprechen muss, damit dort das neue Profil (z.B. bei Topic-Wechsel) aktiviert wird.

Anders gesagt: In der Regel braucht man pro "dummem" Thermostat (oder einer einheitlich angesteuerten Gruppe von Thermostaten) nur einen einzigen WeekdayTimer (und nicht mehr wie früher einen Stall von Heating_Control).
Den (bzw. die alle!) "hängt" man an ein (einziges! sauber konfiguriertes) weekprofile-Device dran und schon werden alle bei einem Topic-Wechsel auf das jeweils passenden Profil abgeändert, Fisch geputzt.

Zusammenfassung wäre hier zu finden: https://forum.fhem.de/index.php/topic,105987.msg999062.html#msg999062 (auch mit Link zum WDT-Thread).

Ansonsten solltest du mal zeigen, was du eigentlich erreichen willst (was aber m.E. nichts mehr mit dem ursprünglichen Thread zu tun hat => neuen anfangen).

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Panik

Hallo Beta-User,

eine kurze Antwort zu geben, ist fast nicht möglich.
Einen anderen Thread zu eröffnen bringt auch nix, da mein ursprüngliches Anliegen
erhalten bleibt (Tip für den Code-Bug).

Weekdaytimer ist sicher ein Klasse Modul und ich habe es ja im Einsatz.
Doch trotz aller Flexibilität Weekprofile=>Weekdaytimer bleibt der gesetzte Zeitplan ein
starres Konstrukt.
Ich brauche daher zwischen Weekdaytimer und dem Device noch eine Schicht mit
endgültigen Bedingungsabfrage.
Z.B. gehe ich 2h spazieren, zum Arzt, einkaufen u.ä. brauche ich eine Sonderbehandlung.
Dies tätige ich mittels MSwitch. Andere nehmen Doif oder Notify(+ Code in myUtils)
Das reagiert auf das einzige für mich nützliche Ding im Weekdaytimer: currValue
In meinem MSwitch setze ich dann mehrere Befehle auch mit diversen anderen Parametern ab ...


Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Vorab für eventuelle Mitleser: Da dieser Thread "Heating_Control" im Titel trägt: Das ist "deprecated" und seit längerem nicht mehr Bestandteil des Modulverzeichnisses. Wir reden nur noch über WeekdayTimer - der ist (abgesehen von einigen neuen, zusätzlichen Optionen) funktionsgleich

Zitat von: Panik am 03 Februar 2022, 06:03:23
(Tip für den Code-Bug).
each($result)ist das Problem, weil $result eigentlich ein Hash ist. (Perl-) "each" will aber ein Array haben. So sollte es gehen:
each(keys %{$result})
Zitat
Doch trotz aller Flexibilität Weekprofile=>Weekdaytimer bleibt der gesetzte Zeitplan ein
starres Konstrukt.
Ich brauche daher zwischen Weekdaytimer und dem Device noch eine Schicht mit
endgültigen Bedingungsabfrage.
Z.B. gehe ich 2h spazieren, zum Arzt, einkaufen u.ä. brauche ich eine Sonderbehandlung.
Das würde ich eher (m.E. sehr, sehr flexibel) über einen Topic-Wechsel am weekprofile lösen. Damit tauscht man ggf. einfach das grade aktive Profil aus und gut ist, dein gewünschter Ausgangswert "currValue" sollte dann unmittelbar passen...

Zitat
Dies tätige ich mittels MSwitch. Andere nehmen Doif oder Notify(+ Code in myUtils)
Das reagiert auf das einzige für mich nützliche Ding im Weekdaytimer: currValue
In meinem MSwitch setze ich dann mehrere Befehle auch mit diversen anderen Parametern ab ...
Klingt in meinen Ohren (unabhängig vom konkret eingesetzten Eventhandler) überkompliziert, aber wie dem auch sei, ich hoffe, obiger Fix hilft dir weiter...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Panik

Hallo Beta-User,

Danke erst mal für deine Code-Hilfe!

Vielleicht denk ich tatsächlich zu kompliziert und es geht mit dem Topic-Tausch viel besser.  ;)
Ich werde es jedenfalls mal testen!
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

 :) dann mal viel Spaß beim Testen und Tüfteln.

Das mit den Topics ist am Anfang etwas "sperrig", bis man sich mal eingedacht hat.

Vielleicht noch ein paar kleine Tipps dazu, wie ich meine, dass es einfacher ist:
- ein weekprofile für alle Thermostate in der Installation
- Nicht jeder Thermostat muss alle Topics kennen.
- Referenzierungen innerhalb weekprofile machen das Leben sehr viel leichter

z.B. "kurzabwesend_mann" kann andere Thermostate regeln wie "kurzabwesend_frau", und "kurzabwesend_eltern" kann das eigentliche Profil beinhalten, auf das die beiden einfach verweisen...

Setzt du dann "kurzabwesend_mann", greift sich eine beliebige Zahl von Thermostaten (aber eben ggf. nicht alle) die Werte aus "kurzabwesend_eltern".

Geht aber natürlich auch andersrum, indem du dem WDT sagst, er soll sich ein bestimmtes Profil holen - das wäre ggf. der einfachere Weg, um dann wieder auf "frau ist wieder da" zu stellen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files