Neues Modul - Heating_Control, WeekdayTimer

[kubuntufan]

Guden,

Wäre es möglich das Modul Heating_Control so zu erweitern das man das 98_PID20.pm Modul füttern kann.

Gruß KubuntuFan

P.S: Habe die Änderungen selbst gemacht. Lade sie hoch sobald ich sie fertig getestet habe.

Im Anhang die Änderungen.

[Gunther]

Letztes Jahr habe ich mich hier mit meinen 9 FHTs ja irgendwann ausgeklinkt, da der Funkverkehr zu stark wurde. Da ich gerade Schrit für Schritt auf Homematic umsteige wollte ich mich mal erkundigen, inwieweit sich dadurch Funkprobleme lösen. Gibt es Erfahrungswerte mit 9 Homematic-Heizkörper-Thermostaten inkl. Wandthermostat und Fenstersensor? Ggf. macht ja auch eine Mischung aus 5 Homematic und 4-5 FHTs Sinn.

Freue mich über Erfahrungsberichte und Feedback. (Ich konnte zum zulässigen Funkverkehr und wirklichen Verhalten der Homematic-Geräte leider keine aussagekräftige Seite finden).

[Dietmar63]

ich habe von HM keine Ahnung.

[Dietmar63]

@kubuntufan
klar, kann ich einbauen

[Petrosilius Zwackelmann]

Hallo Dietmar,

gibt es seit dem Update vom 2014-03-16 eine Änderung bei der Verwendung von @ und %?
Was ist denn mit some obsolet gemeint?
Danke für einen Hinweis.

Danke
Manuel

Im Changelog steht
support for $NAME, $EVENT beside of @, %(some obsolet)

Ich übergebe bei meiner Heizungssteuerung @ und % an die Funktion SET_FHT, dort wird dann abhängig vom Home_Status entschieden ob die Heizung tatsächlich hochgedreht werden soll. Seit einiger Zeit habe ich FHEM-Abstürze und seit dem suche ich die Ursache.

Code Auswählen Erweitern

define HC_SZ_WE Heating_Control SZ_hzg de 07:05|16.0 08:05|16.0 {if ($we){&SET_FHT("@","%")}}
attr HC_SZ_WE group Wochenende
attr HC_SZ_WE room HEIZUNG
attr HC_SZ_WE windowSensor SZ_fenster

define HC_SZ_WT Heating_Control SZ_hzg de 04:35|16.0 05:35|16.0 {if (!$we){&SET_FHT("@","%")}}
attr HC_SZ_WT group Wochentag
attr HC_SZ_WT room HEIZUNG
attr HC_SZ_WT windowSensor SZ_fenster

Code Auswählen Erweitern

sub SET_FHT {
my ($fht, $DESIRED_temp) = @_;
if (Value("HOME_Status") == 1) {
Log(3,"HOME_Status 1 in sub SET_FHT erkannt - es wird $fht auf $DESIRED_temp gestellt");
fhem("set $fht desired-temp $DESIRED_temp");
}
elsif (Value("HOME_Status") == 0) {
Log(3,"HOME_Status 0 in sub SET_FHT erkannt - Temperatur von $fht wird auf 17°C abgesenkt");
fhem("set $fht desired-temp 17");
}
}

[Dietmar63]

Die Verwendung von @ und % verursacht bei der einen oder anderen Nutzung Probleme. Beispiel: email Adresse bei einem notify und FB_mail.

Deshalb soll mittelfristig auf $name $event umgestellt werden. Im wird beides unterstützt.

Du solltest bei der Verwendung keinen Unterschied bemerken.

Abstürtze? wie machen sie sich bemerkbar?
Was stürzt ab? Wann?
Hast du Hinweise im Log?
Hardware?

[mgernoth]

Hallo,

seit einiger Zeit scheint bei mir Heating_Control fhem zum Absturz zu bringen, wenn Heating_Control_SetAllTemps() aufgerufen wird:

Code Auswählen Erweitern


Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_Control.pm line 316.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_Control.pm line 355.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_Control.pm line 405.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_Control.pm line 581.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_Control.pm line 454.
Use of uninitialized value in hash element at ./FHEM/98_Heating_Control.pm line 525.
...
Use of uninitialized value $dev in hash element at /local/fhem/fhem.pl line 3107.
Use of uninitialized value $dev in hash element at /local/fhem/fhem.pl line 2665.
Undefined subroutine &main::_Update called at /local/fhem/fhem.pl line 2448.


Anscheinend wird in Heating_Control_Update() auf das Element "HASH" des übergebenen Hashes zugegriffen, welches aber nicht existiert. Der übergebene Hash ist schon der richtige. Mein Quick-Fix sieht im Moment so aus und scheint zu funktionieren:

Code Auswählen Erweitern


Index: FHEM/98_Heating_Control.pm
===================================================================
--- FHEM/98_Heating_Control.pm (revision 5427)
+++ FHEM/98_Heating_Control.pm (working copy)
@@ -556,7 +556,8 @@
            next;
         }
      }
-     Heating_Control_Update($hash);
+     my $myHash->{HASH}=$hash;
+     Heating_Control_Update($myHash);
      Log3 undef, 3, "Heating_Control_Update() for $hash->{NAME} done!";
   }
   Log3 undef,  3, "Heating_Control_SetAllTemps() done!";


Ich war mir nicht sicher, ob Heating_Control_Update() noch von anderen Stellen evtl. aufgerufen wird, weshalb ich Heating_Control_SetAllTemps() angepasst habe.

Gruß
  Michael

[Dietmar63]

So ist es richtig!
Das Problem ist mir noch nicht aufgefallen.
Danke! Ich werde es reparieren und einchecken.

[Roger]

Hatte auch das Problem, dass 98_Heating_Control.pm 5390 2014-03-31 mir FHEM zum Absturz brachte.
Dank der Änderung von mgernoth läuft es nun wieder.

[tpm88]

Hallo,

bei Interesse - in der Rubrik Code Schnipsels habe ich vorgestellt, wie man einem WeekdayTimer im Webfrontend einen "Enable/Disable" Button spendieren kann.

http://forum.fhem.de/index.php/topic,23655.msg169141.html#msg169141

@Dietmar: Motivation für obige Lösung war ein WAF-kompatibler Button zum Aktivieren/Deaktivieren eines Timers für die Gartenbewässerung, damit die "Holde" hierfür nicht in der Definition des Timers manuell das "disable" Attribut setzen muss. Vielleicht könnte man hierzu ja auch ein set Kommando für WeekdayTimer / Heating_Control einführen (set <dev> enable / set <dev> disable).

Diskutieren könnte man auch, ob der der derzeitige "state" eines WeekdayTimers, nämlich der aktuelle Schaltzustand des geschalteten Objekts, wirklich sinnvoll ist. Den Schaltzustand sehe ich ja ohnehin am Device selber - der "state" eines Timers könnte dann z.B. auch "enabled" oder "disabled" sein. Das würde sich auch individuell mit stateFormat machen lassen.

Gruß
Tobias

[T.ihmann]

Wäre es dann vielleicht sinnvoll, daß man standardmäßig in der Weboberfläche auf einen Button enable / disable klicken könnte. Das wäre m.E. sinnvoll. Im Moment stellt das Symbol ja nur den aktuellen Status dar und es ist nichts klickbar...

[Dietmar63]

Code Auswählen Erweitern


define update_timer_status at +*00:01 { my $timer;
          foreach $timer ('timer_Wasser_01', 'timer_Wasser_02')
            { if ($attr{$timer}{disable}) { fhem "setreading $timer active disabled" }
              else { fhem "setreading $timer active enabled" }
            }
        }


ich könnte den HC und WD ein Reading verpassen, das bei set disable 0/1 feuert, dann kannst du darauf per notify reagieren und mußt nicht pollen.

(set <dev> enable / set <dev> disable).

ich denke darüber nach und setze es eventuell um, obwohl es bei keinem anderem Gerät so gemacht wird.

Code Auswählen Erweitern

Diskutieren könnte man auch, ob der der derzeitige "state" eines WeekdayTimers, nämlich der aktuelle Schaltzustand des geschalteten Objekts, wirklich sinnvoll ist. Den Schaltzustand sehe ich ja ohnehin am Device selber - der "state" eines Timers könnte dann z.B. auch "enabled" oder "disabled" sein. Das würde sich auch individuell mit stateFormat machen lassen.

ja,  kann man sicher drüber diskutieren, ich denke darüber nach, wie man es sowohl für WD und HC umsetzen kann, so dass man die exitierenden Installationen nicht zu stark verändert. Dann hätte ich zuviel zu tun, im Moment leider wenig Zeit. 

[tpm88]

Code Auswählen Erweitern


define update_timer_status at +*00:01 { my $timer;
          foreach $timer ('timer_Wasser_01', 'timer_Wasser_02')
            { if ($attr{$timer}{disable}) { fhem "setreading $timer active disabled" }
              else { fhem "setreading $timer active enabled" }
            }
        }


ich könnte den HC und WD ein Reading verpassen, das bei set disable 0/1 feuert, dann kannst du darauf per notify reagieren und mußt nicht pollen.

Könnte das Modul auch bereits auf das Setzen des Attributs "disable" ein solches Reading "feuern"?
=> dann bräuchte man weder die polling at Krücke noch das ein userReading

ich denke darüber nach und setze es eventuell um, obwohl es bei keinem anderem Gerät so gemacht wird.

Ich weiß, dass das ein Sonderweg wäre.

Code Auswählen Erweitern

Diskutieren könnte man auch, ob der der derzeitige "state" eines WeekdayTimers, nämlich der aktuelle Schaltzustand des geschalteten Objekts, wirklich sinnvoll ist. Den Schaltzustand sehe ich ja ohnehin am Device selber - der "state" eines Timers könnte dann z.B. auch "enabled" oder "disabled" sein. Das würde sich auch individuell mit stateFormat machen lassen.

ja,  kann man sicher drüber diskutieren, ich denke darüber nach, wie man es sowohl für WD und HC umsetzen kann, so dass man die exitierenden Installationen nicht zu stark verändert. Dann hätte ich zuviel zu tun, im Moment leider wenig Zeit.

Mit einem zusätzlichen Reading müsste man das existierende Modulverhalten bezüglich state gar nicht ändern. Wer möchte, könnte es dann per stateFormat individuell anpassen.

Gruss
Tobias

[Dietmar63]

ich habe eine Version von WD und HC fertiggestellt, die folgende Erweiterung beinhaltet:

mit

Code Auswählen Erweitern


set <wd/hc> enable
set <wd/hc> disable

kann das Attribute disable gesetzt werden.

Gleichzeitig wird ein neues Reading disabled gepflegt, das  analog zum Attribut geführt wird und bei einer Änderung notifys feuert, so dass jemand darauf regieren kann. Das Ändern des Atttibuts disable über die Weboberfläche führt auch zu einer Aktualisierung des Readings disabled.

Ich prüfe noch ein wenig, ob alles funzt, dann checke ich es ein.
Vielleicht wird das eine oder andere einfacher dadurch.

[Dietmar63]

sowohl Heating_Control als auch WeekdayTimer um ein

Code Auswählen Erweitern

Set wd disable
Set wd enable

ergänzt, und setzt das Attribut disable auf 0 bzw. 1
Die Änderung des Attibuts disable wird dann im Reading disabled als notify-Trigger zur Verfügung gestellt.

probiert es mal aus!