Hallo zusammen,
Ich würde gerne eine Steckdose ab einer bestimmten Zeit abschalten, sobald der Stromverbrauch unter einen bestimmten Wert fällt.
Meine Idee war, das Modul WeekdayTimer zu verwenden, da ich darin zum einen perfekt alle Zeiten vorgeben kann (z.B. morgens tagabhängig, sobald alle aus dem Haus sind...), zum anderen eine Bedingungen in Abhängigkeit eines Stromverbrauch abzufragen kann.
Soweit ich es derzeit verstanden habe, wird die Bedingung nur zum definierten Zeitpunkt einmalig abgefragt. Hoffentlich habe ich das nicht falsch verstanden. Besteht die Möglichkeit, die Bedingung so auszuwerten, wie es beim Modul Heating_Control für den Windowsensor gehandhabt wird? So, dass der Schaltvorgang bei nicht erfüllter Bedingung zum definierten Zeitpunkt nur verzögert wird und bei Erfüllung der Bedingung im Nachhinein ausgeführt wird?
Ich bin mir leider nicht sicher, was das auf andere Anwendungsscenarien bei der Verwendung der "condition" für Auswirkungen hat. Soweit reicht mein Horizon noch nicht. Ggf. bräuchte man für dieses Feature ein attr oder weiteren Parameter.
Als kleines Debuggingscenario habe ich mir folgende Devices definiert:
define WDTimer_mit_Bedi WeekdayTimer dummy_schalter Di|19:42|off (ReadingsVal("dummy_trigger", "state", "0") < 15)
attr WDTimer_mit_Bedi verbose 5
#Als kleine "Helferlein" habe ich mir noch zwei Dummys definiert, um die Umgebung abzubilden:
define dummy_trigger dummy
define dummy_schalter dummy
Ich hoffe, ich stelle mir das nicht zu einfach vor und hoffentlich ist diese Frage nicht schon beantwortet, Suche war erfolglos.
Schöne Grüße,
John
ps: Beide erwähnten Module sind eine große Erleichterung. Vielen Dank!
Hallo,
du wirst dem dummy_trigger wohl einen Wert zuweisen müssen damit die Abfrage wahr werden kann.
Oder wie wird der Dummy gefüttert (fehlt noch was?)?
Zitat(ReadingsVal("dummy_trigger", "state", "0") < 15)
Wobei ein Dummy per se keine Readings hat - einen Dummy frage ich persönlich immer per Value ab.
In diesem Punkt kann ich mich aber irren und du hast dem Dummy noch Readings spendiert die du hier nicht zeigst.
Dein Anforderung
ZitatIch würde gerne eine Steckdose ab einer bestimmten Zeit abschalten, sobald der Stromverbrauch unter einen bestimmten Wert fällt.
kannst du mAn nur per notify auf das Reading des Stromverbrauchs setzen.
Also wenn Stromverbrauch < x dann define Steckdose_aus at +00:05:00 set Steckdose off
Grüße
Hallo Puschel74,
Da war ich wohl zu sparsam. Vermutlich wäre es klüger gewesen, die Testumgebung entweder garnicht oder vollständig zu nenne. Produktiv heißen die Devices natürlich etwas anders und sind keine Dummies. Sorry für die Verwirrung!
Für eine komplette Testumgebung bekommt dummy_trigger natürlich einen Wert zugewiesen:
z.B.:
set dummy_trigger 10
oder
set dummy_trigger 20
Damit man einen Initialwert hat und sieht, was der dummy_schalten so macht und der Timer tut, was er soll:
set dummy_schalter on
Für das was ich mir vorgestellt habe, wollte ich wochentagsabhängig und auch noch vormittag/nachmittags unterschiedliche Zeiten angeben. Über ein notify ließe sich das natürlich ohne das Modul realisieren (ich hoffe, ich habe Dich richtig verstanden). Bei der Anzahl wird aber recht unübersichtlich. Das Modul WeekdayTimer ist genial, Profile anzulegen und dieses wollte ich mir zu Nutze machen.
Ich komme gerade auf die Idee, mit dem Timer einen passenden THRESHOLD zu aktivieren. Intern arbeitet der vermutlich ähnlich, wie ein notify, daher komme ich drauf.
Mein ursprünglicher Gedanke war, soweit ich es verfolgen konnte, ist WeekdayTimer aus dem Modul Heating_Control entstanden. Und in letzterem ist die Art der Verzögerung schon eingebaut. D.h. wenn ein windowsensor zum Schaltzeitpunkt noch "Open" meldet, wird das Schalten verzögert.
Wenn ich Dich noch nicht richtig verstanden haben sollte, bräuchte ich leider noch einmal einen weiteren kleinen Hinweis.
Die Kombination mit dem THRESHOLD werde ich aber morgen erst einmal versuchen zusammenzustecken.
Ich werde vom Ergebnis berichten.
Vielen Dank schon einmal,
schöne Grüße,
John
Hallo zusammen,
das ist erstmal derzeit dabei rausgekommen:
### Definiert die Zeiten, zu denen die Überprüfung des Standbystroms (ein THRESHOLD mit Namen "standbyoff") aktiv sein soll.
### Dabei wir "standbyoff" jeweils mit "active" bzw. "deactivated" gesteuert.
define WDTimer_standbyoff WeekdayTimer standbyoff Mi|20:55|active Mi|20:58|deactivated
### Definiert die Überprüfung des Standbystroms. Hier ist sicherlich noch ein Code-Dreher drin, sollte aber funktionieren.
### Bei Werten unter 20 wird der Befehl "set dummy_schalter off" gesendet.
### Bei Werten oberhalb von 15 passiert garnichts. Es soll ja nur verzögert ausgeschaltet werden.
define standbyoff THRESHOLD dummy_verbrauch:state:5:20 dummy_schalter||set @ off|1
### Dieses notify, wird leider doch noch benötigt, um den THRESHOLD zu deaktivieren, nachdem der Schalter
### einmalig automatisch ausgeschaltet wurde.
### Sonst geht der Schalter jedesmal wieder durch den THRESHOLD gesteuert aus, bevor man den Stromverbraucher wieder anschalten kann.
### Das vorzeitige Schalten deaktiviert natürlich auch das "Verzögern".
### Das sollte aber nicht so schlimm sein, denn der Schalter ist ja dann schon aus.
define standbyoff_once_only notify dummy_schalter:off IF ([WDTimer_standbyoff:state] eq "active") (set standbyoff deactivated)
Als Umgebung fehlen natürlich noch der Schalter und der Stromverbrauch:
define dummy_verbrauch dummy
define dummy_schalter dummy
Sowie zum debuggen war dieses hilfreich (das geht bestimmt auch einfacher):
define WDTimer_log FileLog ./log/dummy-%G-%V.log WDTimer_standbyoff:.*
define standbyoff_log FileLog ./log/dummy-%G-%V.log standbyoff:.*
define standbyoff_once_only_log FileLog ./log/dummy-%G-%V.log standbyoff_once_only:.*
define dummy_trigger_log FileLog ./log/dummy-%G-%V.log dummy.*
define dummy_plot SVG WDTimer_log:dummy_plot:CURRENT
Und der relevante Auszug aus dem Plot-file:
#FileLog 3:dummy_schalter.*:on:$fld[2]=~"on"?90:80
#FileLog 3:standbyoff.*:60:$fld[2]=~"active"?70:60
#FileLog 3:dummy_verbrauch.*:0:
#FileLog 3:WDTimer_standbyoff.*:40:$fld[2]=~"active"?50:40
plot "<IN>" using 1:2 axes x1y1 title 'Schalter' ls l0 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'Threshold_status' ls l1 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'Verbrauch' ls l2 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'Timer' ls l3 lw 1 with steps
Damit das ganze sinnvolle Startwerte bekommt, kann man noch die Initialwerte einmal zu definieren:
set dummy_verbrauch 30
set dummy_schalter on
set standbyoff desired 20
Um den Schalter wieder anzuschalten reicht ein "normaler" Weekdaytimer, den spare ich mir hier aber mal.
Geschaltet wird im Beschriebenen natürlich nur virtuell.
Das hier beschreibt nur ein Testscenario, um das Prinzip zu testen.
So, ich hoffe, ich habe nichts vergessen und keine Fehler mehr drin (Namen hab ich einige Male angepasst...).
Vielleicht kann es jemand brauchen/noch vereinfachen. Bzw. Feuer frei ???
Ich teste nun mal in der Produktivumgebung...
Schöne Grüße,
John
Zitat
Soweit ich es derzeit verstanden habe, wird die Bedingung nur zum definierten Zeitpunkt einmalig abgefragt. Hoffentlich habe ich das nicht falsch verstanden. Besteht die Möglichkeit, die Bedingung so auszuwerten, wie es beim Modul Heating_Control für den Windowsensor gehandhabt wird? So, dass der Schaltvorgang bei nicht erfüllter Bedingung zum definierten Zeitpunkt nur verzögert wird und bei Erfüllung der Bedingung im Nachhinein ausgeführt wird?
WD und HC sind im Prinzip gleich(Es wird weitestgehend identischer Code genutzt).
Im WD ist kein windsensor oder etwas ähnliches definierbar.
Man könnte so etwas aber nachrüsten, müsste dann vielleicht aber anders benannt werden.
Man könnte so etwas wie ein PseudoGerät(dummy) definieren, das den Wert
open oder
closed haben muss. Wenn es open ist, wird verzögert geschaltet. Über die Benamsung und Zustände sollte man nochmals nachdenken.
Ich glaube das wäre leicht zu machen., da der Code bereits existiert.
Also wenn Interesse besteht, dann baue ich so etwas bei Gelegenheit ein.
Hallo Dietmar,
Vielen Dank für Deine Antwort. So etwas in der Richtung hatte ich gehofft und wäre natürlich der Luxus.
Mein ursprünglicher Gedanke war, den Zustand der "Bedingung" (wahr/falsch) zu verwenden. So wäre man maximal flexibel bei der Benamsung und Verwendung. Darüber hinaus gibt es die Definition der "Bedingung" ja bereits auch schon und wird an das Modul übergeben.
Wenn man den Zustand der "Bedingung" also im Modul mit open/closed interpretieren würde, könnte man ggf. in den bestehenden Code des Windowsensors einfädeln, d.h. die "Bedingung" stellt den Zustand des erwähnten Pseudogeräts. Soweit ich per verbose 5 gesehen habe, wird der Zustand des Sensors ja nach wie vor auch im "WDT" ausgewertet. Daher kam ich auch drauf. 8)
Aber:
- Ich weiß nicht, wie das mit anderen Anwendungsscenarien harmonisiert, sodas es sein könnte, dass man das "neue" Verhalten mit einen Attribut oder neuem Parameter verknüpfen sollte.
- Ob das Verhalten des Verzögern dann standardmäßig oder erst mit Parameter aktiviert wird, mag ich ebenfalls nicht beurteilen. Da habe ich derzeit wohl einen recht subjektiven Blickwinkel. ;)
- Vielleicht stelle ich mir das zu einfach vor...
Der Wörkeraunt scheint zwar zu funktionieren, ich freue mich aber immer, wenn ich bestehende Modulfunktionen nutzen kann und der "Endanwendercode" vereinfacht wird. Daher, wenn die Gelegenheit da ist, stelle ich mich selbstredend gerne zum Testen zur Verfügung.
Interesse meinerseits besteht in jedem Falle. Bin ich diesbezüglich eigentlich der einzige?
Vielen Dank schon einmal für das geniale Modul,
schöne Grüße,
John
Ich habe für WDT und HC eine Erweiterung gebaut, die mit dem Attribut delayedExecution
define hc5 WeekdayTimer Brunnen de so-sa|{strftime('%H:%M:%S',localtime(time()+10))}|on;
attr hc5 verbose 5;
attr hc5 delayedExecution 1
jederzeit am WDT bzw. HC (per notify) ein- und wieder ausgeschaltet werden kann. Klinkt sich in die existierende Logik zum Fensterkontakt ein. Die Liste der Fensterkontakte kann zusätzlich genutzt werden.
Wäre dies nach deinem Geschmack.
Ich prüfe die Erweiterung noch ein wenig. Wenn fehlerfrei, checke ich die beiden Module ein.
Das triff genau den Kern der Sache. Klasse.
Verständnisfrage:
Zitat von: Dietmar63 am 21 Juni 2014, 19:10:10
define hc5 WeekdayTimer Brunnen de so-sa|{strftime('%H:%M:%S',localtime(time()+10))}|on;
Das ist vermutlich nur das Beispiel aus Deiner Testumgebung und ich vermute, die Definition ist so geblieben?
Diejenigen, die HC derzeit schon einsetzen, müssen natürlich das Attribut noch nachlegen. Ich kann aber nachvollziehen, nicht beide Module unabhängig pflegen zu wollen. Und ein weiteres Feature gibt es dort ja auch. ;)
Wenn Du die Module noch irgendwo testen möchtest, lasse sie mir gerne zukommen. 'Beide bei mir im Einsatz.
Schöne Grüße,
John
Die Erweiterung funktioniert soweit, aber ich bin mit der Lösung nicht wirklich zufrieden.
Ich werde die Erweiterung wahrscheinlich so lassen, aber noch folgendes zusätzliches Attribut ergänzen:
define hc5 WeekdayTimer Brunnen de so-sa|{strftime('%H:%M:%S',localtime(time()+10))}|on;
attr hc5 verbose 5;
attr hc5 delayedExecutionCond (verzoegerteAusfuehrung($device, $time, $value ))
verzoegerteAusfuehrung($device, $time, $value ) gehört in die 99_Utils und wird immer dann aufgerufen, wenn eine Schaltung erfolgen müsste.
$device = "myWeekdayTimer1"
$time = "16:30:00"
$value = "on"
Wenn die Funktion true liefert, wird die Ausführung verzögert. Ob es bei den Parametern aus dem Beispiel bleibt, kann ich noch nicht abschließend sagen. Diese Variante hätte aber den Vorteil, dass man nicht ständig das delayedExecution attribute ändern müsste, wenn sich die Voraussetzungen für die Ausführung des WDT ändern.
Meine ursprüngliche Idee war ja, das bereits programmierte Verhalten von HC zu verwenden, da auch für den Endanwender so schön schlank. Mit dem Attribut wäre das schon sehr nah dran gewesen. Ansonsten funktioniert der geschilderte Workaround derzeit natürlich auch bei mir.
Ich kenne leider die Gründe nicht, warum Du mit Deiner Lösung nicht zufrieden bist. Und es scheint, ich könnte im Moment aber nicht helfen. Falls doch...
Schöne Grüße,
John
ich habe die Versionen von WDT und HC erweitert, so dass folgendes möglich ist:
define hc5 WeekdayTimer Brunnen de so-sa|{strftime('%H:%M:%S',localtime(time()+10))}|ox;
attr hc5 verbose 5;
attr hc5 room wdtest; attr hc5 delayedExecutionCond isVerzoegert("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
folgendes Protokoll(rückwärts):
2014.06.27 21:25:48 5: [hc5] setting Timer: hc5_Update 27.06.2014 21:26:48
2014.06.27 21:25:48 5: [hc5] removing Timer: hc5_Update
2014.06.27 21:25:48 3: verzoegerteAusfuehrung------------>1
2014.06.27 21:25:48 3: event---------->ox
2014.06.27 21:25:48 3: hc------------->hc5
2014.06.27 21:25:48 3: wdt------------>hc5
2014.06.27 21:25:48 3: tim------------>21:12:57
2014.06.27 21:25:48 3: nam------------>Brunnen
2014.06.27 21:25:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("hc5","hc5","1403896377","Brunnen","ox")
2014.06.27 21:25:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
2014.06.27 21:25:48 4: [hc5] Next switch 28.06.2014 21:12:57
2014.06.27 21:25:48 5: [hc5] no switch in the yesterdays because of the devices type(Brunnen is not a heating).
2014.06.27 21:25:48 4: [hc5] is not disabled
2014.06.27 21:25:48 4: [hc5] 27.06.2014 21:12:57 ; aktParam: 0.0 ; newParam: ox
2014.06.27 21:25:48 5: setModifier------------>
2014.06.27 21:24:48 5: [hc5] setting Timer: hc5_Update 27.06.2014 21:25:48
2014.06.27 21:24:48 5: [hc5] removing Timer: hc5_Update
2014.06.27 21:24:48 3: verzoegerteAusfuehrung------------>1
2014.06.27 21:24:48 3: event---------->ox
2014.06.27 21:24:48 3: hc------------->hc5
2014.06.27 21:24:48 3: wdt------------>hc5
2014.06.27 21:24:48 3: tim------------>21:12:57
2014.06.27 21:24:48 3: nam------------>Brunnen
2014.06.27 21:24:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("hc5","hc5","1403896377","Brunnen","ox")
2014.06.27 21:24:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
2014.06.27 21:24:48 4: [hc5] Next switch 28.06.2014 21:12:57
2014.06.27 21:24:48 5: [hc5] no switch in the yesterdays because of the devices type(Brunnen is not a heating).
2014.06.27 21:24:48 4: [hc5] is not disabled
2014.06.27 21:24:48 4: [hc5] 27.06.2014 21:12:57 ; aktParam: 0.0 ; newParam: ox
2014.06.27 21:24:48 5: setModifier------------>
2014.06.27 21:23:48 5: [hc5] setting Timer: hc5_Update 27.06.2014 21:24:48
2014.06.27 21:23:48 5: [hc5] removing Timer: hc5_Update
2014.06.27 21:23:48 3: verzoegerteAusfuehrung------------>1
2014.06.27 21:23:48 3: event---------->ox
2014.06.27 21:23:48 3: hc------------->hc5
2014.06.27 21:23:48 3: wdt------------>hc5
2014.06.27 21:23:48 3: tim------------>21:12:57
2014.06.27 21:23:48 3: nam------------>Brunnen
2014.06.27 21:23:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("hc5","hc5","1403896377","Brunnen","ox")
2014.06.27 21:23:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
2014.06.27 21:23:48 4: [hc5] Next switch 28.06.2014 21:12:57
2014.06.27 21:23:48 5: [hc5] no switch in the yesterdays because of the devices type(Brunnen is not a heating).
2014.06.27 21:23:48 4: [hc5] is not disabled
2014.06.27 21:23:48 4: [hc5] 27.06.2014 21:12:57 ; aktParam: 0.0 ; newParam: ox
2014.06.27 21:23:48 5: setModifier------------>
2014.06.27 21:22:48 5: [hc5] setting Timer: hc5_Update 27.06.2014 21:23:48
2014.06.27 21:22:48 5: [hc5] removing Timer: hc5_Update
2014.06.27 21:22:48 3: verzoegerteAusfuehrung------------>1
2014.06.27 21:22:48 3: event---------->ox
2014.06.27 21:22:48 3: hc------------->hc5
2014.06.27 21:22:48 3: wdt------------>hc5
2014.06.27 21:22:48 3: tim------------>21:12:57
2014.06.27 21:22:48 3: nam------------>Brunnen
2014.06.27 21:22:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("hc5","hc5","1403896377","Brunnen","ox")
2014.06.27 21:22:48 3: verzoegerteAusfuehrungCond------------>isVerzoegert("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
2014.06.27 21:22:48 4: [hc5] Next switch 28.06.2014 21:12:57
2014.06.27 21:22:48 5: [hc5] no switch in the yesterdays because of the devices type(Brunnen is not a heating).
2014.06.27 21:22:48 4: [hc5] is not disabled
2014.06.27 21:22:48 4: [hc5] 27.06.2014 21:12:57 ; aktParam: 0.0 ; newParam: ox
2014.06.27 21:22:48 5: setModifier------------>
mit folgender Funktion in 99_utils:
############################################################
sub isVerzoegert($$$$$) {
my($hc, $wdt, $tim, $nam, $event ) = @_;
Log 3, "nam------------>$nam";
Log 3, "tim------------>" . strftime('%H:%M:%S',localtime($tim));
Log 3, "wdt------------>$wdt";
Log 3, "hc------------->$hc";
Log 3, "event---------->$event";
return 1;
# isVerzoegert ("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
}
Die Parameter
"%HEATING_CONTROL"
"%WEEKDAYTIMER"
"%TIME"
"%NAME"
"%EVENT"
werden durch den Namen der devices, der Ausführungszeit und des events ersetzt.
@Joshi:
du solltest vielleicht gleich mit dieser Version testen.
Sorry, war gestern unterwegs und bin erst heute zum Testen gekommen. Hier schon mal ein Zwischenstand:
Versionen nach Update:
# $Id: 98_Heating_Control.pm 6172 2014-06-29 01:22:10Z magenbrot $
# $Id: 98_WeekdayTimer.pm 6057 2014-06-04 19:27:19Z dietmar63 $
Getestete Versionen:
# $Id: 98_Heating_Control.pm 6172 2014-06-29 01:22:10Z magenbrot $
# $Id: 98_WeekdayTimer.pm 4055 2013-10-16 20:44:49Z dietmar63 $ (aus PN)
Code aus sub isVerzoegert in 99_myUtils.pm eingefügt.
Heating_Control funktioniert einwandfrei. Testmatrix schicke ich gleich mal zur Info per Mail.
Die bisherige Funktion von WeekdayTime konnte ich erfolgreich testen.
Bei der Verwendung der Attribute für WDT habe ich offensichtlich noch nicht den richtigen Syntax verstanden bzw.
beide Attribute haben derzeit noch keine Auswirkung aber auch keine Fehlermeldung. Das Modul funktioniert genau so als wenn die Attribute nicht gesetzt wären. Hier möchte ich in der kommenden Woche nochmal selbst genau schauen, warum das bei mir anders aussieht...
Meine derzeitige Definition lautet:
define WDT_Test WeekdayTimer BD_Luefter de So|19:31|on So|19:32|off So|19:33|on So|19:34|off (ReadingsVal("WDT_condition", "state", "on") eq "on")
attr WDT_Test delayedExecutionCond isVerzoegert()
Aber wie geschrieben, können wir das gerne erstmal auf unbestimmte Zeit verschieben. Die Lösung oben funktioniert ja bei mir.
Wenn ich weiter bin, melde ich mich.
Schöne Grüße,
John
Mit dem letzten Update scheint bei mir die Verzögerung des Heating_Controls Moduls nicht mehr richtig zu funktionieren.
Das derzeitige Verhalten:
Während das Fenster offen ist, wird die Solltemperatur in recht unregelmäßigen Abständen immer wieder auf die Temperatur ohne geöffnetes Fenster gesetzt. Vermutlich durch den FHT selbst wird wieder auf die Fensteroffen-Absenktemperatur gesetzt und es ergibt sich ein schönes Muster im Plot.
Einen Ausschnitt aus einem normalen Log und einem Log mit verbose 5 habe ich einmal angehängt.
Die Version des Moduls lautet:
Zitat
# $Id: 98_Heating_Control.pm 6186 2014-06-30 21:10:20Z dietmar63 $
Definiert über:
define SZ_HeatingControl Heating_Control SZ_Heiz Mo-So|00:03|19.0 Mo-Fr|09:00|17.0 Mo-Fr|15:00|18.0 Mo-Fr|16:00|19.0
Ich habe an der Definition nichts verändert und bin relativ sicher, dass es erst seit dem Update auftritt.
Bis auf den einen HC habe ich nun erstmal alle anderen disabled, um das Verhalten weiter einzugrenzen.
Kann jemand das Verhalten bei sich ebenfalls feststellen oder habe ich mir etwas kaputt gespielt?
Ich probiere das Verhalten derweil weiter zu isolieren.
Leider ist bei dem Verhalten auch kein Muster zu anderen Schaltpunkten zu erkennen, daher bis ich derzeit ein bisschen lost.
Warum das geöffnete Fenster im 2. Plot noch nicht richtig angezeigt wird, ist noch ein Problem des Plotfiles und der Darstellung, es war offen.
Schöne Grüße,
John
ich denke es wird mit dem update zu tun haben. Ich verstehe aber nicht warum bei dir so ein Verhalten auftritt.
Kannst du die gesamte Definiton des HC posten.
Kannst du weiterhin den HC mit verbose 5 loggen und einen Auszug des logs bei offenem Fenster posten.
habe jetzt das Protokoll gefunden - danke, sehe vielleicht schon das Problem.
gefunden
Ich musste die Methode Heating_Control_FensterOffen() verschieben. Leider habe ich zu weit verschoben, so dass zunächst geschaltet wurde und dann erst der Fensterkontakt geprüft wird.
Werde ich ändern, dann wird es wieder funktionieren.
eingecheckt
Oh man, das scheint bei Dir Stress verursacht zu haben. Sorry! Ich wollte doch erstmal nur wissen, ob es bei jemand anders auch so ist...
Echt cool, danke, mit einer so schnellen Antwort hatte ich wirklich nicht gerechnet. :D
Habe mir das Modul aus SVN gezogen, da es per Update soweit ich weiß erst ab ca. 8 zum mir käme und ich gleich zur Arbeit muss. Es geht also heute schon in den Test. Irgendein Fenster wird sicherlich wieder offen sein...
Das Log sieht in jedem Falle schon sehr vielversprechend aus.
Ich melde mich heute Abend nochmal zur finalen Bestätigung.
Schöne Grüße,
John
Perfekt. Man kann gut erkennen, wann ich das gefixte Modul ausgetauscht habe.
Vielen Dank für den super schnellen Fix!
Schöne Grüße,
John