Hallo FHEMler,,
ich nutze FHEM seit Mitte 2012 für meine Haussteuerung auf einer fritzbox 7270 und bin begeistert was man damit so alles machen kann - klasse!
Ich habe soeben auf die neue Version gewechselt, ein bißchen herumprobiert und auf Basis des Modules Twilight ein neues Modul erstellt, das meine Version einer Heizungsteuerung realisiert.
Eintrag in fhem.cfg:
define <name> Heating_Control <device> <switching times> <condition>
Bspiel für Wohnzimmer:
define HCW Heating_Control HeizungWohnen 12:00:25_12:30:22_17:00:22.5 $we && !isVerreist()
in diesem Fall würde das Gerät HeizungWohnen um
um 12:00 Uhr auf 25°,
um 12:30 Uhr auf 22°,
um 17:00 Uhr auf 22.5°
gestellt. HeizungWohnen muss als FHT definiert sein.
Die Schaltzeit-punkte und Temperaturen werden einfach im Format HH:MM:temp und durch Underscore getrennt aufgezählt.
Als letztes folgt eine Bedingung, die für alle Schaltvorgänge erfüllt sein muss. Im obigen Beispiel sollen die drei Schaltungen am Wochenende erfolgen, wenn ich nicht verreist(99_Utils) bin.
Mit diesem Modul ist es bei mir möglich die endlosen at-Einträge durch einen Eintrag abzulösen!
Wenn Interesse daran besteht, stelle ich das Modul der Allgemeinheit zur Verfügung. Ich muss mir nur noch eine Sourceforge-Id besorgen.
Kleine Designanmerkung: anstatt underscore würde ich Pipe "|" nehmen. Macht alles ein wenig lesbarer und intuitiver
Ansonsten find ich es erstmal nicht schlecht.....
Die condition kann man auch in {} setzen?
Und warum nimmst du überhaupt Underscore und kein Leerzeichen, und liest einfach bis zum letzten Param -1 aus?
Zumindest in contrib sollte es rein, besser aber in Absprache mit Rudi in den FHEM-Ordner, Vorausetzung: Supportwille und Dokumentation am Ende des Moduls
Hallo Zusammen,
ich habe großes Interesse an diesem Modul. Ich plane zur Zeit den Umstieg auf FHEM (von Contronics), da jetzt alle PC mit Linux laufen. Ich habe einige FHT und andere FS20 Komponenten im Einsatz. Aktuell läuft FHEM bereits und lauscht schon mal mit. Und ich belese mich erst einmal hier, besonders da Perl für mich neu ist. Und da kommt dieses Modul gerade recht.
Beste Grüße
Dirk
ZitatKleine Designanmerkung: anstatt underscore würde ich Pipe "|" nehmen. Macht alles ein wenig lesbarer und intuitiver
Und warum nimmst du überhaupt Underscore und kein Leerzeichen, und liest einfach bis zum letzten Param -1 aus?
Ich hatte ursprünglich natürlich Leerzeichen vorgesehen - intuitiver ja - leider stellte sich aber aber nach der Definition von Steuerungen in der fhem.cfg heraus, dass im Modul die Parameter nur bis zum ersten Leerzeichen ankamen. Direkt in die Oberfläche eingegeben funktionierte alles. Den Grund dafür habe ich nicht weiter analysiert, weil es mir zunächst nur darauf ankam, dass Modul zum Funktinieren zu bringen.
ZitatDie condition kann man auch in {} setzen?
in einer älteren Version hatte ich einen kompletten <Command>(Command bei at> angehängt. Das habe ich später wieder gegen die <condition> condition - damit eine Zeile in fhem.cfg nicht zu lang wird. {} habe ich noch nicht ausprobiert - im Moment muss man sie fortlassen. Die komplette Codezeile inclusive der {} werden im Modul ergänzt. Wie auch immer die fertige Version aussieht - ich bin für Vorschläge offen.
ZitatZumindest in contrib sollte es rein, besser aber in Absprache mit Rudi in den FHEM-Ordner, Vorausetzung: Supportwille und Dokumentation am Ende des Moduls
Ich hatte Rudi schon eine Mail geschickt. Neue Module seien Willkommen. Er meinte ich solle mir nur eine Sourceforge-id besorgen, er würde mich für SVN zulassn, dann könnte ich das Modul einchecken. Was ist contib? Dokumentation und Support sind jedenfalls kein Problem. Es ist ja nicht kompliziert zu benutzen.
Freut mich, wenn ich etwas beisteuern kann.
Hallo
nicht schwer zu verstehen - wenn man Modulschreiber ist ;-)
Du hast noch keine Ahnung was an "Arbeit" auf dich noch zukommt - zukommen wird.
Aber anyway -
danke erstmal für dein Engagement und für deine Erweiterung (Modul)
Grüsse
Hi,
ist das an das Modul HCS angelehnt oder etwas ganz anderes?
Was ist der Unterscied?
Gruß, Uli
Hallo,
nein - Heating_Control funktioniert nicht gleich!
HCS verändert mit Verzögeruungslogiken und abhängig von der Stellung der Ventilantriebe den An- Auszustand der Zentralheizung. Dazu muss ein Schaltaktor an der Heizung angebracht werden - Arbeit für einen ausgebildeten Elektriker.
Ich überlasse diese Aufgabe meiner Zentralheizung selbst. Sie merkt meiner Meinung nach selbst, ob das Wasser im Kreislauf zusätzliche Wärme benötigt.
Mein Modul ist aus der Tatsache heraus entstanden, dass ich im Verlaufe eines Tages unterschiedliche Temperaturen in den jeweiligen Räumen benötige.
Beispiel:
Morgens um 6:20 Uhr soll es in der Küche schön warm sein. FHT-Kueche bekommt den Befehl um 5:40 auf 23° zu heizen.
Um 8:00 ist die ganze Familie aus dem Haus. Dann stellt Heating_Control die Temperatur für FHT-Küche wieder auf 18°. Die Temperatur bleibt dann den ganzen Morgen angenehm warm. Es wird aber kein zusätzliche Wärme von den Heizkörpern der Küche abgegeben.
Um 13:00 Uhr kommen die Familienmitglieder langsam nach Hause, so dass um 12:30 wieder 23° von Heating_Control an FHT-Kueche gesendet wird.
Nach dem Mittagessen so gegen 14:00 verlagert sich das Geschehen von der Küche in andere Räume, wo dann eine ähnliche Steuerung existiert. In der Küche wird von FHT-Kueche wieder 18° eingestellt, was dann abends zum Abendbrot nochmals auf 23° verändert wird.
HCS geht ganz andere Wege.
Ich gehe einfach davon aus, dass wenn meine Heizkörper keine Wärme anfordern, die Heizung von selbst bemerkt, dass sie nicht heizen muss. Ich hoffe ich liege nicht ganz falsch.
Gruß Dietmar
Hallo,
Frage am Rande:
Wie schaltet deine Heizung die Heizwasserpumpe ein und aus?
Bei mir läuft das auch über fhem - als einen gelernten Elektriker voraussetzt da ich
einen Schaltaktor für die Wasserpumpe angebracht habe.
Oder hast du eine Diff.Druck Pumpe die erkennt das ein Heizventil geöffnet ist?
Grüße
Hallo,
ZitatWie schaltet deine Heizung die Heizwasserpumpe ein und aus?
Bei mir läuft das auch über fhem - als einen gelernten Elektriker voraussetzt da ich
einen Schaltaktor für die Wasserpumpe angebracht habe.
Oder hast du eine Diff.Druck Pumpe die erkennt das ein Heizventil geöffnet ist?
Die Heizwasserpumpe wird bei mir gar nicht geschaltet. Ob meine Heizung selbst an- oder abschaltet, kann ich nicht sagen. Vielleicht rüste ich diese Funktion nach, gehört nicht zu meinen vorrangigen Projekten, zumal ich kein Elektriker bin.
Ich will nur abhängig von der Tageszeit automatisch unterschiedliche Temperaturen in den Räumen einstellen können.
Gruß Dietmar
Interessante Geschichte. Könnte man das auch mit geringem Aufwand auf max portieren?
mit MAX kenne ich mich nicht aus.
Gruß Dietmar
Zitat von: orti-otto schrieb am Sa, 05 Januar 2013 16:21HCS verändert mit Verzögeruungslogiken und abhängig von der Stellung der Ventilantriebe den An- Auszustand der Zentralheizung. Dazu muss ein Schaltaktor an der Heizung angebracht werden - Arbeit für einen ausgebildeten Elektriker.
mal ein vergleich aus sicht des autors von HCS:
beide module verfolgen einen anderen zweck, können aber (ohne es getestet zu haben) zusammen wirken.
mit HCS verfolge ich den weg der energieeinsparung bei gleichzeitigem erhalt des komforts (= "wohlfühltemperatur"). dazu greife ich direkt in die steuerung der heizungsanlage ein. siehe dazu:
FHEM Modul zur (erweiterten) Heizungssteuerung. dabei bin ich weder "heizungsbauer" noch "ausgebildeter elektriker". nach studium der betriebsanleitung oder besser der installationsanleitung meiner vaillant therme bin ich auf die brücke für einen raumthermostat gestossen. und genau hier setze ich an: ist der raumthermostat offen, dann geht die heizungsanlage davon aus, das kein heizbedarf anliegt. und das hat auch einfluss auf die pumpe, die dann ebenfalls ausgeschaltet wird. lediglich der warmwasserkreis bleibt davon unberührt. HCS richtet sich dabei nicht ausschliesslich nach ventilstellungen, sondern bei bedarf an temperaturen. man kann also entweder nach temperatur oder ventilstellung regeln. das ganze dann auch noch mit weiteren funktionen wie overdrive, eco-mode, etc. unter- bzw. übersteuern. HCS berücksichtigt dabei die sog. hysterese. weitere funktionen, wie burst-mode, gäste oder partymodus sind schon in der queue. durch die vorbereitungen für den aufbau des forums, sowie andere projekte (fhem update, fhem statistics, fheminfo,...) musste ich aber eine pause in der weiterentwicklung von HCS einschieben. ich hoffe, dass ich die weiterentwicklung in den nächsten wochen wieder aufnehmen kann.
das modul heating_control verfolgt einen anderen weg: hier geht es aus meinem verständnis nach um frei definierbare zeiträume, wann welche temperatur vorgehalten wird. die steuerung der heizungsanlage bleibt dabei sich selber überlassen.
aus meiner gesammelten erfahrung führt dies jedoch nur bedingt zu einsparpotentialen, da ja die heizungsanlage (je nach betriebsart) weiterhin "ihr" programm fährt.
beispiel aus meiner anlage:
die vaillant therme läuft bei mir zeitgesteuert. d.h. das direkt an der anlage zeiten eingestellt werden, wann sie auf leistung gehen soll oder in welcher zeit eine absenktemperatur gilt. ich weiss es im moment nicht genau und bin auch gerade zu faul zum nachsehen aber man kann davon ausgehen, das ich meine therme so programmiert habe, das sie von mo-fr 06:30 bis 22:30 und sa-so von 07:30 bis 23:30 auf heizbetrieb gehen soll. in allen anderen zeiten, geht sie auf die absenktemperatur von 17°.
da ich seit jahren mittels 1-wire (die ursprüngliche 1-wire anbindung an FHEM stammt von mir) das verhalten meiner heizungsanlage studieren konnte (siehe
Heiz- und Warmwasserkreis überwachen, haben diese werte mir viele rückschlüsse liefern können.
so z.b. das (m)eine heizung bei nicht vorhandenem wärmebedarf (also kein ventil offen) in regelmässigen abständen (ich glaub so alle 10-20 min.) temperatur auf den vorlauf gibt um am rücklauf zu erkennen ob irgendwo wärme angefordert wird. und genau hier kann man mit HCS gegenwirken: "wenn kein wärmebedarf anliegt, dann schalte das "virtuelle raumthermostat" in form eines HM-aktors einfach auf aus!".
daher ist das modul heating_control eine gute ergänzung zu HCS oder umgekehrt. je nachdem aus welcher sicht man es sehen will ;-)
bei mir sieht das im moment z.b. so aus:
im folgenden graph sieht man sehr gut, wann die heizung in betrieb ist und den anliegenden wärmebedarf über vor- / rücklauf in bezug auf die aussentemperatur regelt. hier ist die heizungsanlage also seiner eigenen steuerung überlassen, die man dann zusätzlich mit dem modul von dietmar regeln kann. die orangen / gelben blöcke zeigen, wann HCS über den HM-aktor "eingegriffen hat", also wann die heizungsanlage auf heizbetrieb geschaltet wurde.
(siehe Anhang / see attachement)
dazu der abhängige stromverbrauch der heizungsanlage. durch die schaltung des simulierten raumthermostats wird eben auch die heizkreispumpe ausgeschaltet:
(siehe Anhang / see attachement)
und dazu der gasverbauch:
(siehe Anhang / see attachement)
anhand der graphen sieht man sehr schön das zusammenspiel und die auswirkungen von HCS.
irgendwo habe ich auch noch einen graph von "vor HCS" zeiten bzgl. des gasverbrauchs, wo man sehr schön sehen kann, wie die heizungsanlage ihre messung des anliegenden wärmebedarfs über die vor- / rücklauftemperatur ermittelt, was letztlich wieder zu einem höherem verbrauch führt.
wie man an dieser (vielleicht sehr ausführlichen) darstellung sieht, verfolgen beide module einen anderen weg bzw. haben einen anderen zweck. ich glaube uli fragte u.a. danach.
wer es noch ausführlicher haben will, der besuche die zwei obigen links. dort habe ich den aufbau und die steuerung über HCS mit einem HM-aktor näher beschrieben.
gruss martin
Hallo,
vielen Dank für die ausführliche Erklärung.
Hast du eine Vorstellung davon, was Du an Gas mit der Steuerung sparst?
Ich besitze auch eine Vailant. Ich glaube sie funktioniert ähnlich.
Vielleicht ergänze ich HCS. Nächste Woche kommt der Heizungsbauer - ich werde ihn fragen.
Gruß Dietmar
hiya dietmar,
werte habe ich leider noch nicht, da ich HCS erst im 4. quartal 2012 veröffentlicht habe. ich gehe aber mal vorsichtig mit einer schätzung von bis zu 10% (vielleicht sogar mehr) aus (ich werde wahrscheinlich auch keine genaueren werte bekommen, da ich im vorjahr noch im haus eine wohnung vermietet hatte und da das gesamte heizverhalten ja noch ganz anders war).
es entfallen ja a) die ganzen intervalle die die heizung von sich aus auf den heizkreislauf gibt und b) ist es ja nicht nur so, wie in den graphen zuvor zu sehen, dass die heizung von 07 - 22 uhr durchläuft. sobald es draussen wieder etwas wärmer wird, greift HCS auch tagsüber häufiger ein:
(siehe Anhang / see attachement)
hier sieht man z.b. das zwischen ca. 0:00 bis 06:00 uhr heizbedarf anlag (wahrscheinlich weil ich da mal wieder eine nacht programmiert habe ;-)), dann aber bis ca. 15:15 uhr alle räume so warm waren, das die heizung halt auch ausbleiben konnte und erst wieder ab ca. 15:15 bis 20:00 uhr laufen musste. und wie bereits geschrieben: man hat ja nicht nur die einsparung am gasverbrauch sondern in meinem aufbau auch am stromverbrauch, da eben dann auch die pumpe nicht läuft.
wenn du tatsächlich eine gleiche oder ähnliche therme einsetzt, dann solltest du dir mal meinen aufbau näher ansehen. da brauch man wirklich kein elektriker sein: heizung vom stromkreis trennen, kabel an "Klemme 3-4-5" und mit z.b. HM-LC-Sw1-SM verbinden. der muss natürlich mit 230v eingespeisst werden. aber dafür gibts ja sicherungen. ;-)
ABER:
man hantiert hier dennoch mit 230 volt und sollte sich im klaren sein, was man tut!
daher lieber einen "fachmann" dran lassen, wenn man sich das nicht zutraut. auch sollte man darauf achten, das die schaltzeiten nicht zu kurz gewählt werden. deshalb habe ich in HCS auch die "idleperiod" eingebaut. siehe auch: FHEM Modul HCS überarbeitet
(//www.fischer-net.de/hausautomation/fhem/54-fhem-modul-hcs-ueberarbeitet.html).
gruss martin
Mein Heizungsbauer hat mir empfohlen für meine Gas-Brennwerttherme zur täglichen Regelung nicht permanent den ganzen Heizkessel in Standby zu schicken und wieder zu starten, da der Regelkreis versucht diese Pausen mitauszugleichen und damit in den Zeiten, in denen er heizt, zuviel heizt (d.h. zu hohe Schwankungen nach oben). Er meinte, daß eine moderne Pumpe der entscheidende Faktor ist: extrem wenig Stromverbrauch und eine recht intelligente Regelung mit Daten vom Vorlauf (Druck, Temperatur), Rücklauf, Außen und Heizkesseltemperatur und hat empfohlen lieber die Heizkörperthermostate mit Intelligenz auszustatten. Daher habe ich mir für den Alltag etwas ähnliches wie Heating_Control mit MAX Thermostaten gebastelt (d.h. nur bei Anwesenheit abhängig vom jeweiligen Tagesplan werden die jeweiligen Heizkörpertemperaturen erhöht, z.B. "Flieger um 6 Uhr morgens -> Temperatur im Bad unten auf 20 Grad ab 4.30 Uhr"). Für die Ausnahmesituationen wie Urlaub habe ich dann zusätzlich mit einem FS20 WS1 Aktor (muß dringend durch HM ersetzt werden) eine Möglichkeit dennoch den Heizkessel komplett in Standby (Standby = nur Frostschutz) zu schalten. Empfehlung hier vom Heizungsbauer ist übrigens den Heizkessel trotzdem jede Woche mal kurz für 1 Stunde anzuschalten, damit die Pumpe nicht festrostet (mache ich mit einem "at").
Ciao,
gagga
hiya gagga,
so ist das mit den heizungsbauern. der eine so, der andere so. ich möchte hier auf keinen fall eine berufsgruppe verunglimpfen aber ich habe da so meine erfahrungen gesammelt und komme zu dem schluss: viele heizen auch nur mit wasser ;-)
wie ich zu dieser meinung komme?
ich habe vor 2-3 jahren einen hydraulischen abgleich meiner anlage durchführen wollen. dazu habe ich ca. 15 fachbetriebe angerufen, ihnen mein vorhaben geschildert. einige hatten überhaupt kein interesse, andere waren der meinung das es sich für mich nicht richtig lohnen würde und andere kamen mir vor, als ob sie das wort noch nie gehört haben. bei enigen hatte ich als laie das gefühl mehr darüber zu wissen als die gesprächspartner (und nein, es waren keine azubis, sondern zum grösstenteil die inhaber).
nach vielen, vielen telefonaten wurde ich letztlich fündig. ein heizungsbauer (vater, sohn) die total engagiert waren, sich auch nach einem langen telefonat wo ich alle meine fragen beantwortet bekam auch noch die mühe machten, meine anlage gut eine woche vor weihnachten komplett(!) zu vermessen und berechnet haben und dann auch noch rechtzeitig vor weihnachten das ganze umzusetzen.
ich habe ein mehrere seiten langes protokoll mit allen werte und berechnungen erhalten, viele, viele gute tips und ratschläge, besonders auch zu meiner temperaturerfassung mittels 1-wire. ich glaube in einem artikel auf meiner homepage habe ich das auch erwähnt.
so konnte ich in meinem fall den gasverbrauch um ca. 900 m^3 senken (vorher ~2900 - 3100 m^3). nach dem hydraulischem abgleich ~2000 m^3. das was andere heizungsbauer als uninteressant oder für mich "nicht lohnend" abgetan hatten, ist für mich schon eine "hausnummer". nächste abrechnung (11/2013) wird für mich interessant, denn dann kann habe ich den vergleich, was mir HCS tatsächlich an einsparung gebracht hat (unter berücksichtigung des momentan sehr warmen winters).
das entscheidene bei meiner umsetzung ist jedoch, das ich die anlage nicht auf irgendeine weise manipuliere, sondern genau den weg gehe, den der hersteller vorgesehen hat: über einen raumthermostat. nur das dieser bei mir halt keiner ist, sondern ein HM-aktor. d.h. es kommt im ergebnis das gleiche heraus. ob ich nun die anlage über den vorgesehen raumthermostat regele oder über den "virtuellen thermostat" ala HM-aktor. entscheidend dabei ist aus meiner sicht die hysterese zu berücksichtigen. also ein ständiges schalten zu vermeiden.
da ich seit mehr als 4 jahren (vielleicht auch mehr) meine temperaturen (vorlauf, rücklauf, etc.) erfasse, habe ich auch den vergleich, das es bei mir eben nicht zu dem verhalten geführt hat (also höherer verbrauch).
ich zitiere meinen bezirksschornsteinfegermeister (gutes wort für z.b. galgenraten ;-)), der mal sagte: "die meisten kennen nur: mach das es warm wird. und sie machen es dann.". sicherlich ändern sich die zeiten und gesetze und das kann man bestimmt auch nicht verallgemeinern, zumal da auch einiges an weiterbildung gefordert und geboten wird.
bitte nicht falsch verstehen:
a) will ich hier keinesfalls der berufsgruppe unfähigkeit unterstellen, noch
b) den "besserwisser" geben.
das sind lediglich erfahrungswerte, die ich in mehreren jahren gesammelt habe und damit bisher sehr gut gefahren bin. letzlich muss aber jeder für sich entscheiden welchen weg er geht. DAS genau ist ja das geniale an der umsetzung mit FHEM. getreu dem eigentlichem perl-gedanken: timtowtdi - there is more than one way to do it.
ich könnte fast wetten:
dietmar schrieb, das nächste woche sein heizungsbauer kommt. wenn dietmar ihn nun mal vollkommen unvoreingenommen und ohne das hier diskutierte befragen würde, dann würden wir eine weitere meinung erhalten.
in diesem sinne...
gruss martin
Hallo,
auf Wunsch per PM stelle ich den aktuellen Stand des Moduls Heating_Control zum Testen für alle bereit.
Ich würde sagen, dass es den gefühlten Versionsstand 0.9 hat.
Eintrag in fhem.cfg:
define <name> Heating_Control <device> <switchingtimes> (<condition>)|commmand>
Ich habe noch einige Erweiterungen vorgenommen:
Die Parameter werden jetzt formal mit regulären Ausdrücken geprüft.
Bei den <switchingtimes> gibt es keine Begrenzung der Anzahl bei der times. Sie müssen nicht sortiert sein(ist aber besser). Zu einem Zeipunkt ist nur ein Schaltbefehl möglich. Es kann nach den <switchingtimes> entweder eine Bedigung(muss in Klammern gesetzt werden) oder ein <command> folgen. Der <command> entspricht vollständig dem, was nach einem "at" als <command> folgen kann. Die Sonderzeichen @ und % werden durch das <device> und die Temperatur ersetzt. Es sind deshalb die folgenden Varianten möglich:
Beispiel für Wohnzimmer:
#condition
define HCW1 Heating_Control HeizungWohnen 12:00:25_12:30:22_17:00:22.5 ($we && !isVerreist())
# Aufzählung
define HCW2 Heating_Control HeizungWohnen 12:00:25_12:30:22_17:00:22.5 set @ desired-temp %;; set Licht an
# perl-call
define HCW3 Heating_Control HeizungWohnen 12:00:25_12:30:22_17:00:22.5 { schalteHeizung(@,%) }
# perl
define HCW4 Heating_Control HeizungWohnen 12:00:25_12:30:22_17:00:22.5 { fhem("set @ desired-temp %") if($we) }
# shell(so nicht sinnvoll)
define HCW5 Heating_Control HeizungWohnen 12:00:25_12:30:22_17:00:22.5 "/bin/echo "Teatime" > /dev/console
Das sollte jeden Bedarf abdecken.
Ich hoffe der Rest ist selbsterklärend.
Hallo,
ich bin gerade dabei meine gewöhnlichen Wandthermostate, die pro Zimmer die entsprechenden 230V Stellantriebe einer Fußbodenheizung bisher bedienen, auszutauschen.
Dazu entnehme ich Zimmertemperaturen mit 1-wire-DS18B20 und möchte über ein HM-SW1PBU-FM-Schalter anstelle der Wandthermostate die Stellantriebe schalten. Der Schalter hat den Vorteil im Gegensatz zu einem 230V Zwischenschaltaktor, dass man ihn bis zum nächsten Schaltvorgang manuell schalten kann und damit das aktuelle Programm übersteuern kann.
Nun möchte ich ein Wochenprogramme definierten, dass den Schalter über die entnommene Temperatur über den DS18B20 ansteuert.
Da hier keine gewöhnlichen Thermostate FHT bzw. HM zum Einsatz kommen, stelle ich mir die Frage, ob ich mit euren Modulen hier weiter komme, oder doch selbst etwas programmieren muss.
Auf die Frage, warum ich nicht FHT- oder HM-Thermostate genommen habe - es ist einfach eine Preisfrage bei 22-Stellventilen und nur 6 Thermostaten (ein Thermostat schaltet mehrere Stellantriebe pro Zimmer), vor allem, wenn man schon so viele 230V Stellantriebe im Einsatz hat.
Gruß
Damian
ich habe das Modul in meinen FHEM Ordner kopiert und bekomme beim "reload 98_Heating_Control.pm" folgende Fehlermeldung:
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
@ Damian:
ich denke, du mußt Dir so etwas wie ein Software-FHT selbst bauen:
So nach dem Motto: wenn die Temperatur zu niedrig ist, dann öffne die Stellantriebe eines Raumes auf 50%.
Wenn die Temperatur erreicht ist, dann schließe die Ventiele des Raumes usw.
Ohne FHT mußt du hat selbst steuern. Ein solches Modul gibt es wohl noch nicht. Mir ist jedenfalls keines bekannt.
Diese SoftwareFHT kannst Du dann durch HCS oder Heating_Control steuern.
Dietmar
Hallo,
nutzt Du vielleicht eine ältere Perlversion?
Bei mir funktioniert folgender Code:
foreach my $st (sort (keys $hash->{SWITCHINGTIME}))
...
Ich habe die FM im Netz gefunden. Das Problem tritt wohl mit älteren Perlversionen auf.
Im Anhang eine Version bei der ich folgendes geändert habe. Ich hoffe die Änderung löst das Problem. Bei mir läuft jedenfalls alles:
foreach my $st (sort (keys %{$hash->{SWITCHINGTIME}}))
Zitat von: orti-otto schrieb am Mo, 14 Januar 2013 19:25@ Damian:
ich denke, du mußt Dir so etwas wie ein Software-FHT selbst bauen:
So nach dem Motto: wenn die Temperatur zu niedrig ist, dann öffne die Stellantriebe eines Raumes auf 50%.
Wenn die Temperatur erreicht ist, dann schließe die Ventiele des Raumes usw.
Ohne FHT mußt du hat selbst steuern. Ein solches Modul gibt es wohl noch nicht. Mir ist jedenfalls keines bekannt.
Diese SoftwareFHT kannst Du dann durch HCS oder Heating_Control steuern.
Dietmar
Ja, habe ich mir schon gedacht.
Werde aber erstmal meine HM-Schalter mit Notifys abhängig von den Zimmertemparaturen schalten und damit die vorhandenen 230V Stellantriebe steuern. Das bekomme ich schneller hin;)
Gruß
Damian
PS: Es soll laut elv dieses Jahr ein MAX-System für Fußbodenheizung rauskommen. FHT, HM, MAX sind bisher alle nicht fußbodenheizungtauglich.
[quote title=Damian schrieb am Mo, 14 Januar 2013 19:40]
Zitat von: orti-otto schrieb am Mo, 14 Januar 2013 19:25@ Damian:
Gruß
Damian
PS: Es soll laut elv dieses Jahr ein MAX-System für Fußbodenheizung rauskommen. FHT, HM, MAX sind bisher alle nicht fußbodenheizungtauglich.
Sorry aber ich verwende unsere FHT80B in Verbindung mit den zugehörigen Stellantrieben für die Regelung von 3 Fussbodenheizkreisen im Dachgeschoss und es funktioniert, bei uns,
einwandfrei.
Warum sollen die FHT nicht für Fussbodenheizung tauglich sein?
Nur weil Fussbodenheizungen i.d.R. mit einem Rücklauftemperaturbegrenzer betrieben werden?
Ich hab bei uns die Vorlauftemperatur so weit gedrosselt das dem Estrich und den Fliesen nichts passieren kann und das Dachgeschoss wird wunderbar warm.
Als Raumtemperatur habe ich 19 °C vorgegeben und das ist, für uns, perfekt.
Und auch das Wohnzimmer wird über den Heizkörper noch angenehm auf 22 °C temperiert.
Also nicht gleich alles so pauschal abtun ;-)
Grüße
Zitat von: orti-otto schrieb am Mo, 14 Januar 2013 19:25@ Damian:
Also nicht gleich alles so pauschal abtun ;-)
Grüße
Ich denke allein wegen der Größe, wird das bei den meisten konventionellen Fußbodenheizung-Verteilern (bei uns sind es 5 cm Abstand nebeneinander) nicht funktionieren. Zumindest sind die laut Doku alle für konventionelle Heizkörper ausgelegt. Dass es mal funktionieren kann, habe ich nicht ausgeschlossen.
Und zum Thema Kennlinie gibt´s hier etwas von elv:
http://www.elv.de/topic/max-thermostat-fuer-fussbodenheizung.htmlGruß
Damian
Ich habe jetzt auch noch dazugelernt.
Du bist nicht der Einzige der Stellantriebe direkt ansprechen will
Für FS20 gibt es mit PID wohl so etwas wie ein Software-FHT.
Vielleicht kann man PID für HM anpassen. Die Schaltcodes sind sicherlich etwas anders.
Aber eine Möglichkeit ist bestimmt vorhanden.
http://www.fhemwiki.de/wiki/FHT_8v_direkt_ansprechen (//www.fhemwiki.de/wiki/FHT_8v_direkt_ansprechen)
PID ist genau das was ich mit Software-FHT gemeint habe. Ich kannte das Modul bisher nicht.
Und das Beste, Heating_Control lässt sich meiner Meinung nach damit sogar einfach verbinden.
Ich habe die attr-Zeilen alle fort gelassen, damit Du das Wesentliche erkennst:
define stellantrieb.01 FHT8V 1234
define heizung.01 PID CUL_WS_1 stellantrieb.01
define Heating_Control 15:00:25_15:30:21_17:30:22.5 set heizung.01 desired %
oder
define Heating_Control 15:00:25_15:30:21_17:30:22.5 { fhem ("set heizung.01 desired %") }
% wird dann jeweils durch die Temperatur ersetzt.
Heating_Control ist im Grude nur ein Iterator, der zu den angegebenen Zeitpunkten den Code ausführt.
Ich habe ein veränderte Version von Heating_Control eingestellt, weil es ein kleines Problem mit dem Laden gab.
Viel Glück!
Zitat von: orti-otto schrieb am Mo, 14 Januar 2013 20:16Ich habe jetzt auch noch dazugelernt.
Du bist nicht der Einzige der Stellantriebe direkt ansprechen will
Für FS20 gibt es mit PID wohl so etwas wie ein Software-FHT.
Hallo Dietmar,
das ist tatsächlich ein interessanter Ansatz, vor allem in Kombination mit deinem Modul - kannte ich auch noch nicht.
Ich werde es mir genauer anschauen.
Gruß
Damian
ich war vorhin etwas zu schnell
richtig ist:
define stellantrieb.01 FHT8V 1234
define heizung.01 PID CUL_WS_1 stellantrieb.01
define HC1 Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 set @ desired %
oder
define HC1 Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") }
% wird dann jeweils durch die Temperatur ersetzt.
@ wird durch das <device> ersetzt.
ein Problem könnten die Codes sein, die in Homematic verwendet werden.
Ich meine mal gelesen zu haben, dass HM sich mit der Offenlegung der Protokolle sehr zurückhält.
Dietmar
Zitat von: orti-otto schrieb am Mo, 14 Januar 2013 20:48ein Problem könnten die Codes sein, die in Homematic verwendet werden.
Ich meine mal gelesen zu haben, dass HM sich mit der Offenlegung der Protokolle sehr zurückhält.
Dietmar
wieso, es geht doch hier um einen einfachen an/aus Schalter, der in FHEM über CUL gepairt wird oder habe ich hier etwas nicht verstanden?
Ich habe mir mal erlaubt das Modul zu verändern.
Folgende Änderungen:
- Liste der Schaltzeiten mit Leerzeichen getrennt
- Die Temperatur ist von der Uhrzeit mit Pipe (|) getrennt. Dieses erhöht IMHO mit dem vorherigen Punkt die Lesbarkeit immens
- Als STATE Initialzustand wird die aktuelle Temperatur des Thermostates ausgelesen
- Es werden nun auch MAX Thermostate unterstützt
- neues Reading: nextValue, zeigt die nächste zu wechselnde Temperatur an
- an den aktuellen Entwicklungsstand von fhem.pl angepasst, insbesondere ReadingsBulkUpdate
- Codeoptimierung: einige interne Variablen in den {helper} Bereich verlagert
- kleinere Codeoptimierungen
Bitte um Tests und Rückmeldungen
Wenn der Author nicht dagegen hat würde ich auch die Doku schreiben (gibt es da ggf schon etwas??) und nach ausführlichen Tests und Rückmeldungen bei Buggy-free ins FHEM-svn schieben. ggf kann ich auch dem author anbieten ihm bei support unter die arme zu greifen
Ich habe mir mal erlaubt das Modul zu verändern.
Folgende Änderungen:
Liste der Schaltzeiten mit Leerzeichen getrennt
Die Temperatur ist von der Uhrzeit mit Pipe (|) getrennt. Dieses erhöht IMHO mit dem vorherigen Punkt die Lesbarkeit immens
So ähnich hatte ich es auch vor - es funktionierte nur nicht. Die Ursache habe ich zunächst nicht gesucht. Es war mir wichtig das Modul zu Laufen zu bringen. Ich meine mich erinnern zu können, dass das Problem darin bestand, dass ich in der Funktion Heating_Control_Define in der Variablen $def immer nur die erste Schlatzeit bekommen habe. Somit war ich zunächst gezwungen dafür zu sorgen, dass der Parameter switchingtimes als ein Parameter erkannt wurde. Wie Du es gemacht hast, habe ich nicht herausgefunden. Ich hoffe es funktioniert.
Als STATE Initialzustand wird die aktuelle Temperatur des Thermostates ausgelesen
Es werden nun auch MAX Thermostate unterstützt
neues Reading: nextValue, zeigt die nächste zu wechselnde Temperatur an
an den aktuellen Entwicklungsstand von fhem.pl angepasst, insbesondere ReadingsBulkUpdate
Codeoptimierung: einige interne Variablen in den {helper} Bereich verlagert
kleinere Codeoptimierungen
Ich bin mit den Änderungen natürlich einverstanden, kann sie aber im Moment nicht testen. Ich werde das vermutlich morgen machen. Wie oben schon beschrieben, es ist mein erstes Modul, somit kenne ich nocht nicht alle Feinheiten, um korrekte Module zu schreiben.
Bitte um Tests und Rückmeldungen
Wenn der Author nicht dagegen hat würde ich auch die Doku schreiben (gibt es da ggf schon etwas??) und nach ausführlichen Tests und Rückmeldungen bei Buggy-free ins FHEM-svn schieben. ggf kann ich auch dem author anbieten ihm bei support unter die arme zu greifen
Wenn Du willst kannst du gern eine Doku schreiben. Es gibt nichts als das Modul und diesen Thread. Ich habe noch keine Sourceforge-id, somit kann ich eh noch nicht einchecken. Im Übrigen: Du warst ja richtig fleißig!
Wenn wir schon bei Änderungen sind:
Wie wäre es mit einem Wochenprogramm, also Schaltzeiten abhängig von den Wochentagen, wie es jedes Wandthermostat unterstützt.
Ich denke, dass es ein sehr wichtiges Feature ist, um die Sache praxistauglich zu sein.
Gruß
Damian
kann man mit dem vorhandenem Modul ja machen:
Einträge in fhem.cfg:
define HC-So Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") if($wday == 0) }
define HC-Mo Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") if($wday == 1) }
define HC-Di Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") if($wday == 2) }
define HC-Mi Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") if($wday == 4) }
...
wobei ich nicht glaube, dass man jeden Tag andere Zeiten schalten möchte. Aber wer will kann, und es ist trotzdem übersichtlich!
wer es nicht so detailiert möchte macht es so:
define HC-Sa-So Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") if($we) }
define HC-Mo-Sa Heating_Control heizung.01 15:00:25_15:30:21_17:30:22.5 { fhem ("set @ desired %") if(!we) }
Zitat von: orti-otto schrieb am Di, 15 Januar 2013 19:39kann man mit dem vorhandenem Modul ja machen:
In der Tat:)
Gruß
Damian
Ich bin ab prüfen, ggf umsetzen, wie man das machen kann. Ich finde es schon userFriendly wenn man pro Thermostat nur eine(!) Definition angeben kann.
define HCW1 Heating_Control heizung.01 15:00|25 12345|15:30|21 24|17:30|22.5
Bedeutung der Schaltzeiten: <Nr der Tage>|<Uhrzeit>|<Temperatur>
Die Schaltzeit 15Uhr gilt jeden Tag da keine Tage angegeben wurden.
Die Schaltzeit 15:30 gilt nur werktags, Mo-Fr
Die Schaltzeit 17:30 gilt nur Die und Do
Mo = 1, ..... So = 7
Die Angabe Condition|Command bleibt wie gehabt
Zitat von: Tobias schrieb am Mi, 16 Januar 2013 08:15Ich bin ab prüfen, ggf umsetzen, wie man das machen kann. Ich finde es schon userFriendly wenn man pro Thermostat nur eine(!) Definition angeben kann.
define HCW1 Heating_Control heizung.01 15:00|25 12345|15:30|21 24|17:30|22.5
Bedeutung der Schaltzeiten: <Nr der Tage>|<Uhrzeit>|<Temperatur>
Die Schaltzeit 15Uhr gilt jeden Tag da keine Tage angegeben wurden.
Die Schaltzeit 15:30 gilt nur werktags, Mo-Fr
Die Schaltzeit 17:30 gilt nur Die und Do
Mo = 1, ..... So = 7
Die Angabe Condition|Command bleibt wie gehabt
Könntest du bitte diese Version zum Testen bereitstellen.
Gruß
Damian
Hallo miteinander,
falls es jemanden interessiert, ich habe das PID-Modul für Fußbodenheizung modifiziert.
Ich kann jetzt mit dem Modul 1-Wire Temperatursensoren auslesen und beliebige ON/OFF-Aktoren schalten, die dann wiederum konventionelle 230V Stellantriebe schalten. Lässt sich nun wunderbar mit dem Heating_Control-Modul kombinieren.
Gruß
Damian
define HCW1 Heating_Control heizung.01 15:00|25 12345|15:30|21 24|17:30|22.5
ich finde nicht dass die Erweiterungen mit den Wochentagen wirklich übersichtlicher ist.
besser wäre:
define HCW1 Heating_Control heizung.01 15:00|25 Mo-Fr|15:30|21 Mo,Di,Sa|24|17:30|22.5
Bei komplizierten Verteilungen der Heizzeiten, ist das aus meiner Sicht nicht gut zu pflegen .
die gesamten Heizzeiten in einer Zeile unterzubringen halte ich für nicht möglich.
ich müßte folgende Zeilen zusammen erfassen.
define HeizungKueche_wt Heating_Control HeizungKueche 05:35:25_06:30:22_07:00:18___12:00:25_12:30:22_14:00:19_15:30:20_17:45:22_18:30:18 (!$we && !isVerreist())
define HeizungKueche_we Heating_Control HeizungKueche 06:45:25_07:30:22_09:00:19___12:00:22__________14:00:20___________________18:30:20 ( $we && !isVerreist())
#
define HeizungWohnen_wt Heating_Control HeizungWohnen 15:00:25_15:30:21_17:30:22.5_20:00:22_22:00:18 (!$we && !isVerreist())
define HeizungWohnen_we Heating_Control HeizungWohnen 12:00:25_12:30:22_14:00:21____________22:00:18 ( $we && !isVerreist())
Bei mir gibt es zurZeit nur die Unterscheidung zwischen Werktags und Wochenende.
ich habe mal Percode gesucht wie man mehre Tage in Perl abfragen kann:
if( $wday ~~ [ 1, 2, 3 ] ) ; Mo, Di, Mi
wenn ich deine Version des Moduls lade bekomme ich einen Fehler:
2013.01.16 20:43:59 3: BefehlHC return value: Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/98_Heating_Control.pm line 42.
2013.01.16 20:43:59 3: reload 98_Heating_Control : Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/98_Heating_Control.pm line 42.
Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/98_Heating_Control.pm line 42.
jetzt funzt es auch bei mir - ich habe nicht die neueste Version von fhem ...
Hallo,
ist sicher ne blöde Frage, aber wie komme ich an das modifizierte PID-Modul von Damian?
Danke, Gruß Stefan
Zitat von: Stefan 69 schrieb am Do, 17 Januar 2013 16:17Hallo,
ist sicher ne blöde Frage, aber wie komme ich an das modifizierte PID-Modul von Damian?
Danke, Gruß Stefan
Es ist keine blöde Frage, denn die Anpassungen habe ich bisher nur auf meinem Rechner gemacht und nicht veröffentlicht. Die Lösung ist nicht allgemein gültig, da ich das PID-Modul für mich so umgebaut habe, dass es nicht mehr zum alten PID kompatibel ist.
Da es nur ein einfaches Thermostat nachbildet ohne PID-Regelung, hat es mit dem ursprünglichen PID-Modul nicht mehr viel zu tun.
Wenn natürlich Interesse besteht würde ich mein Modul entsprechend anders benennen und hier zum Download bereitstellen, da ich bisher, wie die anderen Autoren hier, kein offizieller Entwickler von FHEM-Modulen bin.
Gruß
Damian
DANKE!
Lasse mir das mal durch den Kopf gehen.
Gruß Stefan
Hi Damian,
Zitatfalls es jemanden interessiert, ich habe das PID-Modul für fußbodenheizung modifiziert.
ja, das interessiert mich in der Tat brennend.
Kannst Du dein angepasstes Modul mal hier posten?
Teggi
Zitat von: teggi schrieb am Fr, 18 Januar 2013 09:51Hi Damian,
Zitatfalls es jemanden interessiert, ich habe das PID-Modul für fußbodenheizung modifiziert.
ja, das interessiert mich in der Tat brennend.
Kannst Du dein angepasstes Modul mal hier posten?
Teggi
siehe hier:
Link
Habe mal eine neue Version hier die jetzt auch Wochenprofile kann, siehe screenshot.
Beispiel:define HCW Heating_Control WZ_Heizung 07:00|15 67|10:00|19 12345|15:30|18.0 16:00|19.0 67|19:00|18 12345|20:00|10 67|21:00|10
Bitte testen und Rückmeldung ;)
jetzt auch mit Modul:
Also bei mir funktioniert die Erweiterung mit den Tagessteuerung - bisher keine Probleme.
Ich überlege, ob ich eine Erweiterung vornehme, bei der die Tage in der Form "Mo,Di,Fr" angeben werden können.
Das scheint mir nicht so schwer zu sein. Es würde die Sache noch etwas lesbarer machen.
Dietmar
Hi Dietmar,
macht aber auch das Define noch länger...
Falls du das trotzdem so umsetzen solltest, würde ich nur im Heating_ControlDefine ansetzen und dort gleich die Tage in die entsprechenden Nummern umsetzen.
Die Updatefunktion auf Tagesnamen umzubauen halte ich für extrem schwierig.
Ich bin g erade dabei die Doku zu schreiben, würde dann alles ins SVN schubsen.
Falls alles funktioniert, kannst du hier das Diff einstellen? ( diff -Nu <heating_Control_alt.pm> <heating_Control_neu.pm> )
ja wird länger - ist aber auch besser lesbar und es funzt. Es war mir irgendwie eine Herausforderung auch dies zu schaffen:
Jetzt ist beides möglich:
define hc Heating_Control HeizungKueche 123|05:35|25 ($we)
define hc Heating_Control HeizungKueche Sa,So,Mi|05:35|25 ($we)
Dietmar
Muss ich einfach die Datei in den FHEM-Ordner kopieren?
Leider sehe ich diese in der FHEM Oberfläche auch nach einem Reboot der FB nicht...
Gibt es da noch einen Kniff?
hab mal drüber geschaut, sieht gut aus ;)
Hast du noch etwas anderes als das define geändert? Bei mir habe ich zwischenzeitlich nur die Doku geschrieben, bzw bin noch dabei. Bei soviel Einstellmöglichkeiten kommt viel TExt raus, und dann gleich 2x, DE + EN
Ich glaube ich habe nur in def geändert, bin aber nicht ganz sicher
Verständnisfrage zu
define hc Heating_Control HeizungKueche Sa,So,Mi|05:35|25 ($we)
würde das nicht bedeuten: Schalte Sa, So und Mi um 5:35 auf 25° aber nur wenn Wochenende ist?
stimmt ist in sich nicht schlüssig - aber du hast es richtig verstanden.
define hc Heating_Control HeizungKueche Sa,So,Mi|05:35|25 ($we)
Bei dieser Definition wird nur Sa, So geschaltet.
Im Prinzip hat man durch die Angabe der einzelnen Tage vor den Schaltzeiten und der Bedingung bzw. eines Kommandos oder eines Perlausrucks extrem viele Möglichkeiten, die sich natürlich auch widersprechen können.
Dietmar
ZitatMuss ich einfach die Datei in den FHEM-Ordner kopieren?
ja - bald wird es per update verfügbar sein.
ZitatLeider sehe ich diese in der FHEM Oberfläche auch nach einem Reboot der FB nicht...
Gibt es da noch einen Kniff?
Ich bin nicht sicher was Du sehen willst.
Das Modul sieht man nicht.
Du must in fhem.cfg eine Zeile folgender Art einfügen:
define HCW1 Heating_Control heizung.01 15:00|25 Mo,Di|15:30|21 34|15:30|21
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 ($we)
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 (!$we)
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 { fhem("set @ desired-temp %")}
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 { perlUpro(@,%,undnocheinParameter)}
Danke für die Antwort.
Leider bekomme ich beim Speichern der fhem.cfg folgende Fehlermeldung:
invalid Device, given Device not found
Hinzugefügt habe ich zum Test
# Heizungsplan
define HCW1 Heating_Control eg_az_Heizung Mo,Di,Mi,Do,Fr|19:46|26
Das Modul habe ich in den FHEM-Ordner kopiert und neu gestartet. Was mache ich falsch?
achja: eg_az_Heizung ist mein Device.
Oder muss ich HCW1 oder Heating_Control anpassen?
Es muss daran liegen, dass das device eg_az_Heizung nicht oder noch nicht defniert ist.
ich bekomme den gleichen Fehler, sieht aber so aus:
invalid Device, given Device <eg_az_Heizung> not found
doch das ist definiert. Zumindest arbeite ich damit und kann die FHT-Steuerung anpassen und sehe die Grafen dazu...
gibt es weitere Ideen?
die Änderung konnte ich auf Heating_Control_Define($$) beschränken
Zitat von: orti-otto schrieb am Do, 24 Januar 2013 20:49die Änderung konnte ich auf Heating_Control_Define($$) beschränken
ich glaub, jetzt stehe ich auf der Leitung. Muss ich hier etwas ändern oder ist das eine Änderung im Modul. Sorry für mein DAU-Verhalten...
die Änderung konnte ich auf Heating_Control_Define($$) beschränken
war eine Antwort für Tobias, der auch Änderungen am Modul vorgenommen hat.
Wir müssen den Code nochmals mischen, und er wollte wissen wo ich die letzen Änderungen vorgenommen habe.
Modul bitte nicht ändern.
Die Beispiele für Dich waren in
Link (http://forum.fhem.de/index.php?topic=10011.msg59844#msg59844)
hast Du genau diese Fm bekommen?
invalid Device, given Device <eg_az_Heizung> not found
ne da stand nur das was ich vorher gepostet habe.
Habe nochmal gebootet und nun gehts... :-) Danke!
genial wäre nun natürlich noch ein Raster das man nicht über die cfg sondern ähnlich der Soll-Temperatur mit einem set setzen kann.
Wie bekomme ich in der Übersicht des Devices zumindest die Werte angezeigt wie oben in einem Screeenshot gezeigt?
Click mal in der Übersicht auf HCW1. Wenn du Übersteuern willst kennst du direkt das Gerät schalten!
Zitat von: Gunther schrieb am Do, 24 Januar 2013 22:56Wie bekomme ich in der Übersicht des Devices zumindest die Werte angezeigt wie oben in einem Screeenshot gezeigt?
ok den Heizungsplan habe ich nun unter Heating_Control gefunden. Klasse, danke!
Das Modul ist spitze. Vielen Dank dafür!
Eine Frage: Schon eine Idee für die "berühmte Ausnahme"? D.h. man hat seinen Wochenplan definiert, möchte aber möglichst einfach eine Ausnahme definieren, d.h. einen anderen Tagesplan z.B. "Muß früh zum Flieger also Bad früher warm" oder "Party! Wohnzimmer warm bis morgens um 5".
Google Calendar Verknüpfung? (damit auch einfach in die Zukunft eine Ausnahme planbar) Sonst eine Idee?
Ciao,
gagga
viele schöne Ideen.
sind aber auch aufwendig in der Umsetzung und vielleicht auch kompliziert in der Bedienung.
Du kannst Dir mehrere Heating_Control definieren.
Wir könnten dem Modul noch eine disable-Funktion spendieren(wie bei at oder notify) dann könnte man über die Oberfläche temporär an- und abschalten.
Dir ist vielleicht bekannt, dass man in der Detailansicht der Geräte die "DEF" per modify temorär ändern kann.
hier ist alles bestens beschrieben:
http://fhem.de/Heimautomatisierung-mit-fhem.pdf (//fhem.de/Heimautomatisierung-mit-fhem.pdf)
Zitat von: Martin Fischer schrieb am Sa, 05 Januar 2013 19:54hiya dietmar,
werte habe ich leider noch nicht, da ich HCS erst im 4. quartal 2012 veröffentlicht habe. ich gehe aber mal vorsichtig mit einer schätzung von bis zu 10% (vielleicht sogar mehr) aus (ich werde wahrscheinlich auch keine genaueren werte bekommen, da ich im vorjahr noch im haus eine wohnung vermietet hatte und da das gesamte heizverhalten ja noch ganz anders war).
es entfallen ja a) die ganzen intervalle die die heizung von sich aus auf den heizkreislauf gibt und b) ist es ja nicht nur so, wie in den graphen zuvor zu sehen, dass die heizung von 07 - 22 uhr durchläuft. sobald es draussen wieder etwas wärmer wird, greift HCS auch tagsüber häufiger ein:
(siehe Anhang / see attachement)
hier sieht man z.b. das zwischen ca. 0:00 bis 06:00 uhr heizbedarf anlag (wahrscheinlich weil ich da mal wieder eine nacht programmiert habe ;-)), dann aber bis ca. 15:15 uhr alle räume so warm waren, das die heizung halt auch ausbleiben konnte und erst wieder ab ca. 15:15 bis 20:00 uhr laufen musste. und wie bereits geschrieben: man hat ja nicht nur die einsparung am gasverbrauch sondern in meinem aufbau auch am stromverbrauch, da eben dann auch die pumpe nicht läuft.
wenn du tatsächlich eine gleiche oder ähnliche therme einsetzt, dann solltest du dir mal meinen aufbau näher ansehen. da brauch man wirklich kein elektriker sein: heizung vom stromkreis trennen, kabel an "Klemme 3-4-5" und mit z.b. HM-LC-Sw1-SM verbinden. der muss natürlich mit 230v eingespeisst werden. aber dafür gibts ja sicherungen. ;-)
ABER:
man hantiert hier dennoch mit 230 volt und sollte sich im klaren sein, was man tut!
daher lieber einen "fachmann" dran lassen, wenn man sich das nicht zutraut. auch sollte man darauf achten, das die schaltzeiten nicht zu kurz gewählt werden. deshalb habe ich in HCS auch die "idleperiod" eingebaut. siehe auch: FHEM Modul HCS überarbeitet
.
gruss martin
Wie bekommst Du die schönen Bilder in den Text hinein. Manchmal sagt ein Bild mehr aus als tausend Worte. Wie kann man von der FHEM-Oberfläche hardcopys machen und dann als Bild einfügen ohne große Bildprogramme zu starten? Ich habe mir das übrigens mit den Klemmen 3-4-5 meiner Vailant angesehen. Sieht einfach aus - werde hcs bald ausprobieren. Was meinst Du? Kann man nicht einfach eine schaltbare Steckdose von fs20 nehmen und ein Kabel an die Klemmen führen?
Hi Dietmar,
bitte am MOdul erstmal nichts ändern da ich auf deiner Version weiter aufbaue. Insb. die Doku und Code aufräumen
gruss
Hier mal die deutsche Doku, würdeich jetzt so lassen falls bis heute mittag keine Änderungswünsche reinkommen
######################################
Heating Control
Define
define <name> Heating_Control <device> <profile> <command>|<condition>
Bildet ein Wochenprofil für ein <device>, zb. Heizkörper, ab. Es können für jeden Tag unterschiedliche Schaltzeiten angegeben werden. Ist das <device> ein Heizkörperthermostat (zb. FHT8b, MAX) so wird die zu setzende Temperatur im <profile> automatisch mittels set <device> desired-temp <temp> dem Device mitgeteilt. Ist eine <condition> angegeben und ist zum Schaltpunkt der Ausdruck unwahr, so wird dieser Schaltpunkt nicht ausgeführt.
Alternativ zur Automatik kann stattdessen eigener Perl-Code im <command> ausgeführt werden.
Folgende Parameter sind im Define definiert:
device
Das an den Schaltpunkten zu schaltende Device.
profile
Angabe des Wochenprofils. Die einzelnen Schaltzeiten sind durch Leerzeichen getrennt Die Angabe der Schaltzeiten ist nach folgendem Muster definiert:
[<Wochentage>|]<Uhrzeit>|<Temperatur>
Wochentage: optionale Angabe, falls nicht gesetzt wird der Schaltpunkt jeden Tag ausgeführt. Für die Tage an denen dieser Schaltpunkt aktiv sein soll, ist jeder Tag mit seiner Tagesnummer (Mo=1, ..., So=7) oder Name des Tages (Mo, Die, ..., So) einzusetzen.
Uhrzeit:Angabe der Uhrzeit an dem geschaltet werden soll, Format: HH24:MI
Temperatur:Angabe der zu setzenden Temperatur als Zahl
command
Falls keine Condition in () angegeben wurde, so wird alles weitere als Command interpretiert. Perl-Code ist in {} zu setzen. Wichtig: Falls ein Command definiert ist, so wird zu den definierten Schaltzeiten nur(!) das Command ausgeführt. Falls ein desired-temp Befehl abgesetzt werde soll, so muss dies explizit angegeben werden.
Folgende Parameter werden ersetzt:
@ => das zu schaltende Device
% => die zu setzende Temperatur
condition
Bei Angabe einer Condition ist diese in () zu setzen und mit validem Perl-Code zu versehen.
Der Rückgabedatentyp der condition muss boolean sein.
Die Parameter @ und % werden interpretiert.
Beispiel:
define HCB Heating_Control Bad_Heizung 12345|05:20|21 12345|05:25|12 17:20|21 17:25|12
Mo-Fr wird die Temperatur um 05:20Uhr auf 21°C, und um 05:25Uhr auf 12°C gesetzt. Jeden Tag wird die Temperatur um 17:20Uhr auf 21°C und 17:25Uhr auf 12°C gesetzt.
define HCW Heating_Control WZ_Heizung 07:00|16 Mo,Die,Mi|16:00|18.5 20:00|12 {fhem("set dummy on"); fhem("set @ desired-temp %");}
Zu den definierten Schaltzeiten wird nur(!) der in {} angegebene Perl-Code ausgeführt.
define HCK Heating_Control KZ_Heizung 07:00|16 16:00|18.5 20:00|12 ($sunshine=0))
Die zu setzendeTemperatur wird nur gesetzt, falls die globale Variable $sunhine=0 ist.
Set
N/A
Get
N/A
Attributes
disable
loglevel
event-on-update-reading
event-on-change-reading
stateFormat
Mir sind nur zwei Kleinigkeiten aufgefallen:
oder Name des Tages (Mo, Die, ..., So) -> Abkürzungen mit 2 oder mit 3 Buchstaben oder egal?
HH24:MI -> würde ich als "HH:MM (HH im 24 Stunden Format)" schreiben
Ich habe mir das Modul aus dem Post vom 23.1. geladen und in mein FHEM Verzeichnis auf einer FritzBox 7390 kopiert. FHEM ist per update auf den letzten Stand gebracht.
Wenn Heating_Control geladen werden soll, kommt folgende Meldung:
Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/98_Heating_Control.pm line 43.
Habe ich was übersehen?
Zitat von: Uli schrieb am Fr, 25 Januar 2013 09:45Ich habe mir das Modul aus dem Post vom 23.1. geladen und in mein FHEM Verzeichnis auf einer FritzBox 7390 kopiert. FHEM ist per update auf den letzten Stand gebracht.
Wenn Heating_Control geladen werden soll, kommt folgende Meldung:
Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/98_Heating_Control.pm line 43.
Habe ich was übersehen?
Kommt dann, wenn dein
fhem.pl veraltet ist. Mach mal ein "shutdown restart"
Zitat von: Tobias schrieb am Fr, 25 Januar 2013 07:21Hi Dietmar,
bitte am MOdul erstmal nichts ändern da ich auf deiner Version weiter aufbaue. Insb. die Doku und Code aufräumen
gruss
ok - hatte ich auch erst einmal nicht vor.
disable einbauen wäre vielleicht einfach möglich!
Asche auf mein Haupt! Ich hätte wetten können, dass ich FHEM mindestens 1x nach dem Update neu gestartet habe. Anscheinend lag ich da falsch...
Jetzt läuft es aber. Tolles Modul! Vielen Dank für die Arbeit!!!
> Wie bekommst Du die schönen Bilder in den Text hinein. Manchmal sagt ein Bild mehr aus als tausend Worte.
unter kde (linux) reicht ein druck auf die "Druck" taste der tastatur. dann öffnet sich KSnapshot und ich kann dann auswählen ob ich einen kompletten screenshot, einen rechteckigen bereich oder den inhalt eines fenster speichern will.
ein ähnliches tool gibt es auch (kostenlos) für windows. musst du mal googlen.
> Ich habe mir das übrigens mit den Klemmen 3-4-5 meiner Vailant angesehen. Sieht einfach aus
ist es auch ;-)
> - werde hcs bald ausprobieren. Was meinst Du? Kann man nicht einfach eine schaltbare Steckdose
> von fs20 nehmen und ein Kabel an die Klemmen führen?
sicherlich kannst du auch eine FS20 ST-3 o.ä. nehmen. mir war die bidirektionale rückmeldung wichtig. deshalb habe ich dort HomeMatic eingesetzt.
gruss martin
Danke für die Antworten. Aber wie bekommt man die Bilder jetzt am einfachsten in die Texte hinein?
Alle Beispiele die ich in der Hilfe gefunden habe nutzen Links wie z. Bsp.: http://fudforum.org/forum/images/fudlogo.gif (//fudforum.org/forum/images/fudlogo.gif)
Muss ich die Bilder erst hochladen?
> Danke für die Antworten. Aber wie bekommt man die Bilder jetzt am einfachsten in die Texte hinein?
achso.. das meinst du ;-)
unter der texteingabebox kannst du dateien hochladen. wenn du eine datei hochgeladen hast, dann kannst du den das bild in die nachricht einfügen. dazu steht dann neben der hochgeladenen datei in link, den du klicken musst.
(siehe Anhang / see attachement)
gruss martin
So, die ersten Thermostate laufen mit Heating_Control. Feine Sache. Vielen Dank dafür.
Einen kleinen Erweiterungs-/Änderungswunsch hätte ich.
Wäre es Möglich sowas wie Mo-Fr für Mo,Di,Mi,Do,Fr einzubauen, also das mann die Tage als Bereich eingeben kann. Ich denke das würde die Übersichtlichkeit nochmal erhöhen.
Ich denke darüber nach. Es sollte möglich sein.
Aber erst will Tobias die doku fertigstellen, es in SVN einchecken - dann können wir über sinnvolle Veränderungen nachdenken.
solltet Ihr mal bei nextValue 0°C und bei nextUpdate 01.01.1970 00:00:00 stehen haben, habt Ihr vermutlich irgendwo einen : anstatt der | als Trenner genutzt. Das hatte ich eben irgendwo zwischen Uhrzeit und Temperatur. Das wurde erst mal übernommen aber die oben genannten Fehler traten dann auf.
Nun ist ja mit dem Modul eine ganze Menge möglich, leider wird offenbar die Temperatur auf Zahl geprüft, sonst könnte man damit eine Wochenzeitschaltuhr realisieren:
z. B.
define HCW2 Heating_Control HeizungWohnen 12:00|on 12:30|off 17:00|on set @ %
Gruß
Damian
wenn Du dies etwas genauer beschreiben könntest - könnte ich danach suchen.
die Prüfung auf reuläre ausdrücke sollte nicht viele falsche Definitionen zulassen.
ist ganz einfach möglich - man muss die Zahlen nur in der Definition zulassen.
Wenn Tobias mit der Doku fertig ist, und eingcheckt hat, können wir die Erweiterung vornehmen.
bist Du mit der Doku schon weitergekommen?
Wann stellst Du den Stand zur Verfügung?
Ich würde gern weiterentwickelen.
nimm mal dieses... nur die Doku ändert sich erstmal noch...
Ich komme immer nur unter der Woche dazu, eher weniger am WE
aktuelle version eingecheckt.
Ab morgen per update verteilt.
Bitte um ausführliche Test bevor weiter entwickelt wird
insbesondere ob ein Schalten am Sonntag funktioniert
Ich habe noch einmal eine Frage zu hcs und meiner Vailant 196(ca. 13 Jahre alt).
Die Brücke 3-4-5 habe ich gefunden - nur ein einfache Kabel.
Meine Vailant hat aber auch ein Centralgerät VRC-VC mit Außenfühlersteuerung.
Sie ist über die Platine angeschlossen und moduliert die Vorlauftemperatur.
Ich habe bei den Artikeln zur Calorimatik(ähnlich) ... gelesen, dass wenn etwas an 789 angeschlossen ist, dass dann die Brücke bei 345 geschlossen sein muss. Macht es dann denn Sinn, wenn ich zusätzlich zum Centralgerät VRC-VC mit Außenfühlersteuerung noch per FHEM über 34 die Heizung an- bzw. abschalte. Ich habe jetz eine zeitlang hcs mitlaufen lassen ohne wirklich etwas zu schalten- funktioniert gut!!
Was meinst Du dazu?
Hi,
über 34 könntest Du mittels fhem die Heizung "abwürgen".
Bei mir läuft das so, dafür habe ich keine Ventilstelltriebe.
Aus meiner Sicht sollte man entweder Ventilstelltriebe oder "Heizung abwürgen". Im doppelten Ansatz erkenne ich keinen Mehrwert.
Gruß, Uli
Nach dem heutigen Update bekome ich für Definitionen mit z.B Mo,Di,Mi|16:00|24 immer
invalid daylist in hc.og.bad <mo,di,mi,do,fr> 123... | Sa,So,...
Und dann habe ich beim Umschalten zur nächsten Solltemperatur (um 23:55 soll auf 16° gestellt werden) sowas:
2013.01.29 23:54:30 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:00 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:01 2: CUL_HM set og_bad_thermostat desired-temp 20 rxt:12
2013.01.29 23:55:01 2: CUL_HM set og_bad_thermostat desired-temp 16 rxt:12
sorry, nutz mal bitte folgendes.
das Sonntagsproblem ist damit aber noch nicht gelöst oder?
Sonntagsproblem gelöst, Tests aber noch nicht abgeschlossen. Probierts mal bitte aus
wo ist es denn?
Danke, werde ich ausprobieren
na hier... Link (http://forum.fhem.de/index.php?topic=10011.msg61148#msg61148)
Ich hatte es mir angesehen und nicht entdeckt was du geändert hast um das Sonntagsproblem zu lösen.
Ich werde es ausprobieren - leider aber erst am Sonntag.
Bin dann mal weg.
Zeile 207:
$wday=7 if($wday==0);
Das funktioniert aber nach einem update geht es wieder nicht.
Mit 1234| ... funktionierts
Zitat von: Tobias schrieb am Mi, 30 Januar 2013 09:52sorry, nutz mal bitte folgendes.
ich wollt auch nur wissen obs nun geht.
Fix ist eingecheckt. Morgen per Update verfügbar
Vielen Dank
Hallo,
zuallererst, dass Modul ist super. Endlich kann man einfach einen Schaltplan bestimmen.
Ich habe aber ein Problem mit der condition. Ich würde gerne die Schaltzeiten ausführen nur wenn ein Dummyschalter "Off" ist. Wenn der Schalter "On" ist soll eine Standarttemperatur eingestellt werden.
Ich habe den den Schalter und eine Dummy Variable HomeStatus definiert. Mit HomeStatus soll dann endschieden werden ob der Schaltplan der Heating_Control ausgeführt wird oder nicht.
Eintrag in fhem.cfg
### Dummy Schalter LEAVE HOME #####
define Leave_Home FS20 1034 1a
attr Leave_Home dummy 1
attr Leave_Home room HAUS
define HomeStatus dummy
set HomeStatus 0
define act_on_Leave_Home notify Leave_Home {\
if ("%" ne "off") {\
fhem("set Heizung_AZS desired-temp 17;;set HomeStatus 1")\
}\
else {\
fhem("set HomeStatus 0")\
}\
}
##### Heating Control Unit########
define HCU Heating_Control Heizung_AZS 07:00|18 14:40|8 (!$HomeStatus)
Problem Log-File meldet mir die Fehlermeldung:
Global symbol "$HomeStatus" requires explicit package name at (eval 17) line 1.
Welchen Fehler mache ich hier?
Wäre nett wenn ihr mit weiterhelfen könntet.
Grüße
Stefan
so kann das natürlich nicht funktionieren....
so sollte es richtig sein:
##### Heating Control Unit########
define HCU Heating_Control Heizung_AZS 07:00|18 14:40|8 ($ReadingsVal('HomeStatus', 'state',0)==1)
Hallo Super! Ohne $ hat es geklappt.
define HCU Heating_Control Heizung_AZS 07:00|18 17:35|9 17:45|10 17:55|11 18:05|12 (ReadingsVal("HomeStatus", "state",0)==0)
Jetz habe ich aber das Problem, dass die Werte zu den Schaltzeiten anscheinend öfter übertragen werden.
2013.01.31 17:35:01 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:00 2: FHT set Heizung_AZS desired-temp 9.0
2013.01.31 17:45:01 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:00 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:00 2: CUL_0: unknown message EOB
2013.01.31 17:55:01 2: FHT set Heizung_AZS desired-temp 10.0
2013.01.31 17:55:01 2: CUL_0: unknown message EOB
2013.01.31 17:55:01 2: FHT set Heizung_AZS desired-temp 11.0
2013.01.31 17:55:01 2: CUL_0: unknown message EOB
2013.01.31 18:05:00 2: FHT set Heizung_AZS desired-temp 11.0
2013.01.31 18:05:00 2: FHT set Heizung_AZS desired-temp 11.0
2013.01.31 18:05:00 2: FHT set Heizung_AZS desired-temp 11.0
2013.01.31 18:05:00 2: FHT set Heizung_AZS desired-temp 11.0
2013.01.31 18:05:00 2: FHT set Heizung_AZS desired-temp 11.0
Irgend eine Idee?
Hallo,
ich habe zu dem Modul mal eine Anfänger Frage. Kann ich in einer Definition im Teil command eine Abfrage für $we unterbringen? Ich möchte so eine Ausnahme im Zeitplan für Ferien und Feiertage definieren. Eine holiday Datei erstelle ich entsprechend dafür. Wenn ja, wie sollte die Definition dann aussehen?
Beste Grüße
Dirk
define HCW1 Heating_Control heizung.01 15:00|25 Mo,Di|15:30|21 34|15:30|21
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 ($we)
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 (!$we)
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 { fhem("set @ desired-temp %")}
oder
define HCW1 Heating_Control heizung.01 15:00|25 15:30|21 { perlUpro(@,%,undnocheinParameter)}
Ja, das ist problemlos möglich: siehe obige Beispiele
Ich habe immer noch das Ding mit dem mehrfachen setzen der desired-temp.
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:00 2: CUL_HM set eg_ez_thermostat desired-temp 20 rxt:12
2013.02.04 14:00:01 2: CUL_HM set eg_ez_thermostat desired-temp 16 rxt:12
Das tritt nicht immer auf, aber schon mehrmals am Tag. Es wird dann immer mehrmals die alte desired-temp gesetzt und zum Schluß dann die Neue.
Das gleiche Problem habe ich auch. Bei meinem Arbeitskollegen trat dieser Fehler heute ebenfalls auf. Irgendwie noch ein bisschen buggy.
Weil das leidige Sonntagsproblem bestand, hab ich auf die svn-Version aktualisiert.
Bei meiner bisher funktionierenden Definitiondefine BAD_TIMER Heating_Control VFHT_BAD_desired_temp Mo,Di,Mi,Do,Fr|06:00|22.0 Mo,Di,Mi,Do,Fr|08:00|18.0 Mo,Di,Mi,Do,Fr|17:00|20.5 Mo,Di,Mi,Do,Fr|22:00|18.0 Sa,So|09:00|20.5 Sa,So|23:00|18.0 set @ %°C
wird der state nun statt 20.5°C
auf05.02.2013 17:00:00: 20.5°C
also nextUpdate + nextValue gesetzt.
Auch eine Definition mit{fhem("set @ %°C")} ändert daran leider nichts.
Generelle Anmerkung:
Tolles Modul, Vielen Dank für die Arbeit! Ich würde es noch toller finden, wenn das Modul Heating_Control nicht nur für eine Heizung gedacht wäre, sondern ein generisches Zeitschalt-Modul mit dem man beliebig schalten & walten kann. Ich weiß, das kann man mehr oder weniger jetzt schon, aber es wird zB. immer in den state ein °C angepappt und so...
der "state" ist nur de Vorschlag des Entwicklers.
Das Attribut "stateformat" ist dein Freund um das anzuzeigen was du möchtest
was willst Du mit diesem Komando erreichen?
set @ %°C
damit wird dann keine Heizung mehr gesteuert. Es fehlt desired-temp oder so!
aus set @ %°C wird dann in Heating_Control set VFHT_BAD_desired_temp 21°C.
Dieses Kommando wird dann als FHEM-Kommando ausgeführt und bewirkt nichts bzw. nichts sinvolles - oder habe ich die Absicht nicht richtig verstanden?
Haben die anderen Nutzer des Moduls nicht daselbe Problem mit dem merfachen Setzen der vorherigen Temperatur?
Kann es sein, dass wenn man zwischen den Schaltpunkten die Temperatur manuell verstellt, dieses Problem auftritt??
Zitat von: orti-otto schrieb am Mi, 06 Februar 2013 14:23was willst Du mit diesem Komando erreichen?
set @ %°C
damit wird dann keine Heizung mehr gesteuert. Es fehlt desired-temp oder so!
aus set @ %°C wird dann in Heating_Control set VFHT_BAD_desired_temp 21°C.
Dieses Kommando wird dann als FHEM-Kommando ausgeführt und bewirkt nichts bzw. nichts sinvolles - oder habe ich die Absicht nicht richtig verstanden?
In verbindung mit einem FHT8V-Heizkörperventil (ohne einen FHT zum pairen und regeln), einem CUL_WS-Temperatursensor und dem PID-Modul ist der besagte VFHT_BAD_desired_temp zwar nur ein dummy, über dessen state bzw. notify ich das das "desired $temp" des PID und eben weitere Aktionen auslöse... ;)
Doch, ich habe das gleiche Problem. Bin mir nicht mal sicher ob mein Heating Control aber überhaupt was setzt. Mein Log sieht bspw. so aus:
2013-02-06 20:00:00 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:00 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:00 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
2013-02-06 20:00:00 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:00 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:00 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
2013-02-06 20:00:01 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:01 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:01 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
2013-02-06 20:00:01 FHT fht_office desired-temp 13
2013-02-06 20:00:01 Heating_Control office_prof nextUpdate: 07.02.2013 02:00:00
2013-02-06 20:00:01 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:01 Heating_Control office_prof 07.02.2013 02:00:00: 13°C
Und der entsprechende Config:
define office_prof Heating_Control fht_office 12345|08:00|21 20:00|13 02:00|13 06:00|13 6|09:00|21 7|10:00|21 (ReadingsVal("@", "mode", "auto" ) eq ("auto" || "manual"))
Ich habe das Gefühl, ich habe es falsch definiert.
Zitat von: dr_laplace schrieb am Mi, 06 Februar 2013 15:44Haben die anderen Nutzer des Moduls nicht daselbe Problem mit dem merfachen Setzen der vorherigen Temperatur?
Kann es sein, dass wenn man zwischen den Schaltpunkten die Temperatur manuell verstellt, dieses Problem auftritt??
nein eigentlich nicht - ich nutze HC mit fs20 und habe folgenden output:
2013.02.06 18:30:01 2: FHT set HeizungKueche desired-temp 18.0
2013.02.06 17:45:01 2: FHT set HeizungKueche desired-temp 22.0
2013.02.06 17:30:01 2: FHT set HeizungWohnen desired-temp 22.5
2013.02.06 15:30:01 2: FHT set HeizungKueche desired-temp 20.0
2013.02.06 15:30:01 2: FHT set HeizungWohnen desired-temp 21.0
2013.02.06 15:00:01 2: FHT set HeizungWohnen desired-temp 25.0
2013.02.06 14:00:01 2: FHT set HeizungKueche desired-temp 19.0
2013.02.06 12:30:01 2: FHT set HeizungKueche desired-temp 22.0
2013.02.06 12:00:01 2: FHT set HeizungKueche desired-temp 25.0
2013.02.06 12:00:00 2: FHT set HeizungKueche desired-temp 18.0
2013.02.06 12:00:00 2: FHT set HeizungKueche desired-temp 18.0
2013.02.06 06:50:01 2: FHT set HeizungKueche desired-temp 18.0
2013.02.06 06:15:01 2: FHT set HeizungKueche desired-temp 22.0
2013.02.06 05:35:01 2: FHT set HeizungKueche desired-temp 25.0nichts ist doppelt.
meine def sieht so aus:
define HeizungKueche_we Heating_Control HeizungKueche 06:45|25 07:30|22 09:00|19 12:00|22 14:00|20 18:30|18 ( $we && !isVerreist())Zitat2013-02-06 20:00:00 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:00 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:00 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
sieht aus als wenn du eine Version mit Log-Einträgen nutzt, die in der aktuellsten Version nicht enthalten sind.
prüft mal, ob in der Detaiansicht die Zeiten stimmen:
(siehe Anhang / see attachement)
ich hänge eine Erweiterung des Moduls an diesen Beitrag, die die Angabe der Tage in der Form Sa,Mo-Di|18:30|22.5 ermöglicht.
Das Modul läuft bei mir seit letzter Woche stabil. Die Doku habe ich auch ein wenig verändert.
@Tobias:
bitte auf dieser Version weiterarbeiten.
Zitat von: sengelking schrieb am Mi, 06 Februar 2013 20:18Doch, ich habe das gleiche Problem. Bin mir nicht mal sicher ob mein Heating Control aber überhaupt was setzt. Mein Log sieht bspw. so aus:
2013-02-06 20:00:00 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:00 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:00 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
2013-02-06 20:00:00 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:00 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:00 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
2013-02-06 20:00:01 Heating_Control office_prof nextUpdate: 06.02.2013 20:00:00
2013-02-06 20:00:01 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:01 Heating_Control office_prof 06.02.2013 20:00:00: 13°C
2013-02-06 20:00:01 FHT fht_office desired-temp 13
2013-02-06 20:00:01 Heating_Control office_prof nextUpdate: 07.02.2013 02:00:00
2013-02-06 20:00:01 Heating_Control office_prof nextValue: 13°C
2013-02-06 20:00:01 Heating_Control office_prof 07.02.2013 02:00:00: 13°C
Und der entsprechende Config:
define office_prof Heating_Control fht_office 12345|08:00|21 20:00|13 02:00|13 06:00|13 6|09:00|21 7|10:00|21 (ReadingsVal("@", "mode", "auto" ) eq ("auto" || "manual"))
Ich habe das Gefühl, ich habe es falsch definiert.
(siehe Anhang / see attachement)
sieht richtig aus, ist leider nicht sortiert.
define yy at +00:00:03 { Log 3, ReadingsVal("HeizungKueche", "mode", "auto" ) }
liefert in meinem Log manual.
Die Heizung FHT muss jedenfalls auf manual stehen!
folgender Befehl wird vermutlich nicht true:
HC erzeugt:
fhem("set HeizungKueche desired-temp 13") if(ReadingsVal("HeizungKueche", "mode", "auto" ) eq ("auto" || "manual"))
so
define office_prof Heating_Control HeizungKueche 12345|08:00|21 20:00|13 02:00|13 06:00|13 6|09:00|21 7|10:00|21 (ReadingsVal("@", "mode", "auto" ) eq "manual")
funktioniert es:
Log:
2013.02.06 22:07:30 3: nextSwitch=07.02.2013 02:04:01
2013.02.06 22:07:30 3: Ende------------>office_prof
2013.02.06 22:07:30 2: FHT set HeizungKueche desired-temp 13.0
2013.02.06 22:07:30 3: command------------>{ fhem("set HeizungKueche desired-temp 13") if(ReadingsVal("HeizungKueche", "mode", "auto" ) eq "manual")}
2013.02.06 22:07:30 3: NowSwitch: 06.02.2013 22:07:29 ; AktDesiredTemp: 18.0 ; newDesTemperature: 13
2013.02.06 22:07:30 3: d------------>2
2013.02.06 22:07:30 3: nextSwitch------------>1360199041--->07.02.2013 02:04:01
2013.02.06 22:07:30 3: Jetzt:06.02.2013 22:07:29 -> Next: 07.02.2013 02:04:01 -> Temp: 13
2013.02.06 22:07:30 3: wday-days[d]----------->3 4
2013.02.06 22:07:30 3: secondsToSwitch------------>-72209
2013.02.06 22:07:30 3: st------------>02:04
2013.02.06 22:07:30 3: days[1]------------>4
2013.02.06 22:07:30 3: d------------>1
2013.02.06 22:07:30 3: nowSwitch------------>1360184849--->06.02.2013 22:07:29
2013.02.06 22:07:30 3: Jetzt:06.02.2013 22:07:29 -> Next: 06.02.2013 20:03:01 -> Temp: 13
2013.02.06 22:07:30 3: wday-days[d]----------->3 3
2013.02.06 22:07:30 3: secondsToSwitch------------>-7469
2013.02.06 22:07:30 3: st------------>20:03
2013.02.06 22:07:30 3: nowSwitch------------>1360184849--->06.02.2013 22:07:29
2013.02.06 22:07:30 3: Jetzt:06.02.2013 22:07:29 -> Next: 06.02.2013 08:03:01 -> Temp: 21
2013.02.06 22:07:30 3: wday-days[d]----------->3 3
2013.02.06 22:07:30 3: secondsToSwitch------------>-50669
2013.02.06 22:07:30 3: st------------>08:03
2013.02.06 22:07:30 3: nowSwitch------------>1360184849--->06.02.2013 22:07:29
2013.02.06 22:07:30 3: Jetzt:06.02.2013 22:07:29 -> Next: 06.02.2013 06:03:01 -> Temp: 13
2013.02.06 22:07:30 3: wday-days[d]----------->3 3
2013.02.06 22:07:30 3: secondsToSwitch------------>-57869
2013.02.06 22:07:30 3: st------------>06:03
2013.02.06 22:07:30 3: nowSwitch------------>1360184849--->06.02.2013 22:07:29
2013.02.06 22:07:30 3: Jetzt:06.02.2013 22:07:29 -> Next: 06.02.2013 02:03:01 -> Temp: 13
2013.02.06 22:07:30 3: wday-days[d]----------->3 3
2013.02.06 22:07:30 3: secondsToSwitch------------>-72269
2013.02.06 22:07:30 3: st------------>02:03
2013.02.06 22:07:30 3: days[0]------------>3
2013.02.06 22:07:30 3: d------------>0
2013.02.06 22:07:30 3: wday------------>3
2013.02.06 22:07:29 3: Begin------------>office_prof
Meine Detailansicht sieht ein bischen anders aus. Ich habe jetzt mal definiert wie "orti-otto ".
define HeizungKueche_we Heating_Control Heizung_AZS 06:45|25 07:30|22 09:00|19 12:00|22 14:00|20 18:30|18
Im Feld state steht bei mir aber die gleiche Temperatur wie im Feld "next value". Außerdem steht bei mir noch das Datum drin. Müsste da nicht die aktuelle Temperatur stehen?
(http://s12.postimage.org/wqmucxaa5/img_heizung.png)
Was meinst du mit der Version der Log-Einträge? Habe ich vielleicht eine andere Version?
Danke für die Hilfe
readingsBulkUpdate ($hash, "nextUpdate", strftime("%d.%m.%Y %H:%M:%S",localtime($nextSwitch)));
readingsBulkUpdate ($hash, "nextValue", $nextDesTemperature . "°C");
readingsBulkUpdate ($hash, "state", $newDesTemperature."°C");
state ist der aktuell eingestellte Temperaturwert.
nextValue ist die Temperatur für die nächste Schaltung zum Zeitpunkt nextUpdate
Warum steht dann bei mir 25°. Es üsste doch 18° dort stehen.
Hab ich irgendwie eine andere Version des Moduls. Ich habe fhem eingentlich auf aktuellen Stand.
Heute erst "update" ausgeführt.
(siehe Anhang / see attachement)
Diese Anzeige kann lt. Programmcode wie er mir vorliegt nicht auftreten.
mein Standard-HC sagt im Moment ist 18 Grad eingestellt. Morgen um 12 Uhr wird 25 Grad geschaltet:
(siehe Anhang / see attachement)
Ich habe das Modul nur über die update Funktion von fhem erhalten. Liegt hier mein Fehler? Das sollte doch eigentlich der richtige Weg sein oder?
Werde es morgen mal manuel reinkopieren und testen.
vom Prinzip her ist das richtig.
Das Modul gibt es aber erst seit Anfang des Jahres.
Ich habe in den letzten zwei Monaten gelernt Module zu schreiben, habe noch keine Möglichkeit die Sourcen per SVN hochzuladen.
Tobias hat das Hochladen übernomen.
Die Idee für HC stammt von mir. Tobias hat geholfen die Angabe von Tagen vor den Schlatzeiten und noch einiges mehr einzubauen, so dass es im Moment eine Co-Produkton ist.
ich habe noch eine neue Version angehängt. Bei dieser Version werden die Schaltzeiten in den Profilen sortiert angezeit, egal wie sie definiert werden.
(siehe Anhang / see attachement)
man kann die Tage mit dieser Version übrigens auch so angeben. Die Lesbarkeit steigt dadurch nochmals:
define hc Heating_Control HeizungWohnen Mo-Di,Mi-Sa|05:35|17
267 InternalTimer($nextSwitch, "Heating_Control_Update", $hash, 0);
268 readingsBeginUpdate($hash);
269 readingsBulkUpdate($hash, "nextUpdate", strftime("%d.%m.%Y %H:%M:%S",localtime($nextSwitch)));
270 readingsBulkUpdate($hash, "nextValue", $nextDesTemperature . "°C");
271 readingsBulkUpdate($hash, "state", strftime("%d.%m.%Y %H:%M:%S",localtime($nextSwitch)). ": " . $nextDesTemperature."°C");
272 readingsEndUpdate($hash, defined($hash->{LOCAL} ? 0 : 1));
der über update gelieferte code sieht anders aus und enthält einen Fehler:
readingsBulkUpdate($hash, "state", strftime("%d.%m.%Y %H:%M:%S",localtime($nextSwitch)). ": " . $nextDesTemperature."°C");
Nimm mal das von mir zuletzt eingestellte Modul. Dann sieht die Welt wieder besser aus.
Wenn es in Ordnung ist werden wir(Tobias) es wieder hochladen.
ZitatreadingsBulkUpdate($hash, "state", strftime("%d.%m.%Y %H:%M:%S",localtime($nextSwitch)). ": " . $nextDesTemperature."°C");
war übrigens gewollt. Die aktuelle Temperatur sieht man auch im State des Thermostates. vielmehr interessiert die nächste schaltzeit. Wem das nicht gefällt kanns ja über stateformat ändern....
ich bin auch gerade am Suchen warum die Schaltzeit mehrmals übertragen wird....
Wenn du mit deiner fertige Version ein Diff gegenüber die aktuelle svn-version machst, kann ich wieder syncronisieren und hochladen
readingsBulkUpdate ($hash, "state", $newDesTemperature."°C");
Ich würde diesen State für sinnvoller halten. Den Temperatur state des Thermostats kann ja auch per Hand verändert werden.
An der Heating_Control würde mann aber den Wunschwert sehen und könnte unter Umständen auf diesen zurücksetzen.
Einigen wir uns doch aufreadingsBulkUpdate ($hash, "currentValue", $newDesTemperature."°C"); ;)
Also bei mir gehts jetzt so:
define office_prof Heating_Control HeizungKueche 12345|08:00|21 20:00|13 02:00|13 06:00|13 6|09:00|21 7|10:00|21 (ReadingsVal("@", "mode", "auto" ) ne "holiday")
ja das sieht gut aus - der ursprüngliche Perlausdruch wurde nie wahr.
Also ich habe jetzt über das Wochenende das eingestellte Modul aus dem Forum getestet. Es ist leider das gleiche Verhalten. Ich habe um 12:06 die Temeratur manuel auf 22 Grad gestellt.
2013.02.10 12:06:58 2: FHT set Heizung_AZS desired-temp 22.0
Zum Schazeitpunkt um 21 Uhr kam es dann wieder zu den Mehrfachausgabe.
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:00 2: FHT set Heizung_AZS desired-temp 18.0
2013.02.09 21:00:01 2: FHT set Heizung_AZS desired-temp 17.0
2013.02.09 22:08:33 2: FHT set Heizung_EZ desired-temp 17.0
Irgend eine neue Idee?
ich bin dran, habe auch schon etwas gefunden. Muss aber noch weiter testen.
Ja - ich melde mich heute Abend dazu!
Hallo,
bei mir ist die gleiche Fehlfunktion vorhanden, dabei ist es egal ob ich am Thermostat verstelle oder per Fhem. Es übernimmt die manuelle Einstellung nicht (etliche mal der vorherige Wert, dann der neue) und zum Schaltzeitpunkt dann das selbe Spiel. Hoffe Ihr findet das Problem.
Grüsse Molli
Hallo,
ich habe das Problem der Mehrfacheinträge im Log auch. Ich habe heute früh meinen ersten Heating_Control definiert. Er hat auch gleich allein die Temperatur entsprechend Zeitplan eingestellt. Und heute Abend zum nächsten Schaltpunkt waren dann drei Einträge im Log. Das einzige was ich habe, sind zwei HC für diesen FHT. Und zwar einen mit der Bedingung Wochenende und einen mit der Bedingung nicht Wochenende. Ich habe aber keine Temperatur per Hand eingestellt.
Beste Grüße
Dirk
ich denke wir haben das Problem lokalisiert.
wer selbst Hand anlegen will und nicht warten kann bis Tobias das Modul online gestellt hat kann folgendes ändern:
(siehe Anhang / see attachement)
in Zeile 227 folgende Änderung eintragen. Es reicht die Ergänzung des '=':
if ($now >= $next) {Dann sollte da Problem nur noch selten auftreten!
Erklärung:
ZitatIn der produktiven Version wird bei einem Treffer auf der exakten Schaltzeit erst bei der "Schaltzeit + eine Sekunde" geschaltet.
kann man hier: Link (http://forum.fhem.de/index.php?topic=10011.msg63372#msg63372) schön sehen.
Wenn dann vorher wie im Thread beschrieben die Temperatur verstellt wurde, erfolgt bei mir ca. 10 mal ein Verstellen der Temperatur, weil desired-temp noch nicht mit der neuen desired-temp übereinstimmt. Auf schnelleren Rechnern wird das entsprechend häufiger passieren. Mit der Änderung wird exakt zur Schaltzeit die neue Temperatur eingestellt.
Hallo Dietmar,
also bei funktioniert es.
Herzlichen Dank.
Bei mir auch, Dankeschön!!!
Hallo,
ich habe mal eine andere Frage uzu diesem Modul. Ich möchte für verschiedene Situationen verschieden Zeiten und Temperaturen nutzen. Dafür bietet sich ja die Condition in diesem Modul an. Dazu habe ich mir DummySchalter gebaut. Nun möchte ich das HeatingControlModul in Abhängingkeit dieser DummySchalter ausführen. Das sieht dann in etwa so aus:
define HCU Heating_Control Heizung_AZS 07:00|18 17:35|9 17:45|10 17:55|11 18:05|12 ($WirSindDa eq "on")
Ohne die Condition funktioniert es. Mit ihr nicht. Was mache ich da falsch?
Viele Grüße
Steffen
Dummys sind FHEM-Variablen und Perl nur über Funktionen zugänglich.
Du musst die Funktion ReadingsVal nutzen.
In diesem Thread findest du ein Beispiel:
Link (http://forum.fhem.de/index.php?topic=10011.msg63150#msg63150)
genau genommen mußt Du es so machen:
define HCW Heating_Control WZ_Heizung 08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
Also es scheint mit:
define hc_Wohnzimmer_Normal Heating_Control hz_Wohnzimmer 3|21:35|25 (ReadingsVal("WirSindDa", "state", "on" ) eq "on")
zu gehen.
Danke für die Hilfe!
Wie verhält sich das Modul eigentlich mit einem Fensterkontakt. Muß ich das über die Condition abfangen oder hat das Modul da was im Bauch.
Da gibt es nichts extra - muss auch nicht sein.
Wenn beim Gerät, das gesteuert werden soll (FHT) einen Fensterkontakt angemeldet ist, wird sein Signal automatisch berücksichtigt.
Bei FHTs von fs20 ist das jedenfalls so.
Ich kann mir nicht vorstellen, dass es bei MAX oder HM anders ist.
Dann wird also beim Fenster-auf-Signal die dafür vorgesehene Temperatur vom FHT selber eingestellt und wenn das Fenster wieder zu ist auf die Wunschtemperatur des Heizungsmodul?
Da muss ich nochmal was zum Grundverständnis des Moduls fragen. Es setzt die Wunschtemperatur einmal wenn der vorgegebene Zeitpunkt erreicht ist und die Bedingung erfüllt ist. Dazwischen macht es nichts oder?
Ich glaube schon. Ich habe es aber noch nicht ausprobiert. Ich habe hier zwar so ein Ding herumliegen, habe aber nocht nicht
die Notwendigkeit gesehen es anzuschließen - war halt mehr damit beschäftigt HC zu bauen.
Der FHT muss jedenfalls auf manuell stehen, damit die Schlatbefehle ausgeführt werden.
Am besten mal ins Handbuch des FHT schauen - MAX und HM könnten anders funktionieren.
Heating_Control hat keine Fuktion für Fensterkontakte.
ja - genau.
Es wird immer nur zu den definierten Schaltzeitpunkten aktiv und verändert ggf. die Temperatur.
Danach legt es sich schlafen bis zum nächsten Schaltzeitpunkt.
Wie eine Menge von at-Kommandos.
Bei mir sind dadurch ca. 25 "at" ersetzt worden.
Also das Modul ist ja echt mal klasse! Kann man es eigentlich vom "Heating-Control-Modul" in ein allgemeines "Schaltzeit-Modul" erweitern?
Ich finde es dahingehend halt sehr klasse, weil man damit ja die ganzen at-Strings deutlich reduzieren kann.
Super wäre, wenn man nicht nur Temperaturen setzen kann, sondern auch schaltzustände "on"/"off" sowie vielleicht noch "lock"/"unlock" (für die Keymatic).
Ist das möglich?
Gruß,
Dennis
...und mit mehreren Bedingungen sieht es dann so aus?
define hc_Wohnzimmer_Normal Heating_Control hz_Wohnzimmer 3|21:35|25 ((ReadingsVal("WirSindDa", "state", "on" ) eq "on") && !(ReadingsVal("WirSindWeg", "state", "on" ) eq "on"))
Würde das ausgeführt werden wenn WirSindDa und nicht WirSindWeg gesetzt ist?
Die Idee ein allgemeines Schaltmodul mit Wochenprogramm zu erstellen ist mir bei der Erstellung von hc auch gekommen - habe sie aber dann nicht gleich verwirklicht. Aufbauend auf HC ist der Aufwand gering.
Wir müssen dann aber auch darüber nachdenken ob HC dann weiter bestehen soll. Das neue Modul kann dann nämlich auch die Funktion von HC übernehmen. Das würde dann die Flut von Modulen eindämmen.
Im Moment haben wir noch mit einigen kleinen Bugs zu kämpfen, danach werden wir sehen was wir machen.
Ich werde heute Abend eine neue Version einchecken. Bei der ist dann die Angabe der Wochentage in der Form Sa-Mo,Do möglich - sehr übersichtlich.
sieht auf dem ersten Blick ok aus - aber bei den vielen Klammern und Sonderzeichen kann man nie wissen.
Ich prüfe solche Ausdrücke immer mit
define yy at +00:00:03 { Log 3, ReadingsVal("WirSindDa", "state", "on" ) eq "on" && !ReadingsVal("WirSindWeg", "state", "on" ) eq "on"}
und gebe sie in der fhem-Oberfläche vor save ein(nicht auf save clicken sondern nur return-Taste drücken), dann im log nachsehen was passiert. Am besten die Einzelzeile einzeln prüfen dann zusammenbauen.
mir sind zu lange Ausdrücke in der fhem.cfg ein Graus. Deshalb lagere ich soche Sache in die 99_utils aus.
ich habe das Modul in mit dem bugfixing hochgeladen - es kann jetzt über die updatefunktion eingespielt werden.
Bitte die Doku beachten - es sind neue Sachen möglich.
Sorry für die Frage, aber wo finde ich die Doku?
Ich benutze das Modul seit einer Woche. Funktioniert soweit ganz gut. Leider scheinen die normalen Schaltzeiten des FHT dazwischen zu funken. Ich habe nicht immer die Temperatur die ich erwarte. Im Schaltplan sieht alles ganz gut aus. Wie macht ihr das mit den normalen Schaltzeiten im FHT?
Ich lade jetzt einmal in der Woche die verschiedenen Temperaturen (Tag, Nacht, Fenster auf) runter.
ich habe fs20 FHT im Einsatz. Diese muss ich auf manuell umstellen, so dass nur noch HC schaltet.
Manuelle Steuerungen werden zur jeweils nächsten Schaltzeit durch HC übersteuert.
Ich lade jetzt einmal in der Woche die verschiedenen Temperaturen (Tag, Nacht, Fenster auf) runter.
Was meinst du damit? Wenn du HC nutzt werden sie nicht gebraucht.
Ich habe hier nochmal eine Frage zum Thema heating_control in Zusammenhang mit dem Zuhausestatus gemäß Wiki:
Wie bekomme ich es hin, das beim Verstellen des Status sich etwas ändert gemäß Plan in hc und ich diese Werte nicht im Homestatus eingeben muss.
Kann ich hc beim Setzen eines Status auffordern zur gegebenen Zeit die Einstellungen nochmal aktiv zu setzen und gemäß Homestatus den richtigen Eintrag zu wählen?
Wenn du wie im Beispiel beschrieben HC so
define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
definierst, erfolgt keine weitere Schaltung seitens HC, wenn WeAreThere nicht auf yes steht.
Ein notify erledigt den Rest: Ich habe mit
define Befehl5a notify WeAreThere:no {fhem ("set HeizungKueche desired-temp 18;; set HeizungWohnen desired-temp 18") }
erreicht, dass beim Setzen des Dummys die Temperaturen korrigiert werden. So bleiben sie bis ich WeAreThere wieder auf yes setze.
Zur Zeit gibt es keine Möglichkeit automatisch die Pläne zu ändern. Ich habe mir so geholfen, dass ich zwei HC angelegt habe. Über die Bedingungvariable kannst du steuern wann welcher HC schalten soll.
Ich weiss. Gebraucht wird nur die Fenster-Auf-Temperatur. Die andren beiden lade ich mit runter um zu sehen ob wirklich immer das Modul Heating_Control schaltet oder das FHT selber. Deswegen nehme ich für Tag- und Nachttemperatur eine die sonst nicht im Heating_Control vorkommt.
Außerdem habe ich jetzt bei allen FHT's die Schaltzeiten --:-- eingestellt. Jetzt sollten sie nie mehr selber schalten. Als Modus "Auto". Das ist mir sympatischer als "Manu". ...und es scheint zu funktionieren.
soweit habe ich das noch nicht ausprobiert - schön dass es funzt.
Also ich habe bei mir dir FHT auf auto stehen und die haben auch ihr schaltprogramm. Funktioniert einwandfrei bei mir mit HC zusammen. Ist auch gut so. Benutze HC mehr oder weniger als failsafe. So wird in der Nacht auch mehrmals die Absenktemperatur gestellt, falls jemand spät abends im Wohnzimmer nochmal einheizt.
Leider bekomme ich nach aktuellem 'fhem update force' immernoch folgende Fehlermeldung:
fhem> reload 98_Heating_Control
syntax error at /usr/local/FHEM/share/fhem/FHEM/98_Heating_Control.pm line 101, near "$anzahl ~"
syntax error at /usr/local/FHEM/share/fhem/FHEM/98_Heating_Control.pm line 103, near "} else"
Woran kann das liegen?
ist mir ehrlich gesagt ein Rätsel:
Hier hat sich lt. SVN Repositoriy nichts, außer die Umlaute im Kommentar geändert:
Syntaktisch ist das aber alles korrekt. Wenn ich bei mir den reload ausführe funktioniert er.
Bist Du in der Lage die Programmstelle bei deiner Installation in Augenschein zu nehmen?
Dann poste die Stelle bitte einmal. Vielleicht ist bei Dir nicht alles angekommen.
Es müßte jedenfalls etwa so aussehen:
97 for(my $i=0; $i<@a; $i++) {
98 #prüfen auf Angabe eines Schaltpunktes
99 my @t = split(/\|/, $a[$i]);
100 my $anzahl = @t;
101 if ( $anzahl ~~ [2,3]) {
102 push(@switchingtimes, $a[$i]);
103 } else {
104 #der Rest ist das auzuführende Kommando/condition
105 $conditionOrCommand = trim(join(" ", @a[$i..@a-1]));
106 last;
107 }
108 }
Teilweise habe ich mit dem Upload von Umlauten ins SVN Probleme.
Da sie aber in Kommentaren sind dürfte das keine Auswirkungen haben.
Es ist aber möglich, dass verschiedene Plattformen anders reagieren.
Hat sonst noch jemand Probleme? Vielleicht hilft es das Problem zu umschiffen zunächst das Modul aus dem Forum zu laden:
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/98_Heating_Control.pm?revision=2753 (//fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/98_Heating_Control.pm?revision=2753)
Welche Hardware/Betriebsystem nutzt Du?
Danke für die schnelle Antwort.
Meine lokale 98_Heating_Control.pm ist absolut identisch mit dem Link. Ich habe auch schon eine vorher gepostete Variante probiert: dabei bekomme ich die gleichen Fehler (gleiche Codestelle, andere Zeilenzahl entsprechend).
Auf "reload" bin ich gekommen, nachdem ich ein "cannot load module Heating Control" bekommen habe. Das war mein erster Versuch mit dem Modul.
Das FHEM läuft auf einer Synology 1512+ (x86 Atom CPU). Die 98_He...pm liegt unter /usr/local/FHEM/share/fhem/FHEM. Vielleicht ist das eine seltene Basis, verwendet evtl. andere Perl Bibliothek?
Übrigens eine tolle Idee mit dem Modul, freue mich schon auf den Testeinsatz.
Prüf mal welche Perlversion du einsetzt. Ich habe hier:
http://de.wikipedia.org/wiki/Perl_ (//de.wikipedia.org/wiki/Perl_)(Programmiersprache)
folgendes gefunden:
ZitatPerl 5.10 [Bearbeiten]Neben verringertem Speicherverbrauch und einer erneuerten und nun auch austauschbaren Regex-Maschine brachte diese Version am 18. Dezember 2007 unter der Führung von Rafaël Garcia-Suarez vor allem Neuerungen, die dem Entwurf von Perl 6 entstammen und deren Gebrauch entweder einzeln oder kollektiv mit use feature ':5.10'; angemeldet werden muss oder kürzer use v5.10;. Dies gilt ab dieser Version für alle Funktionen, welche die Kompatibilität brechen könnten. Hierzu zählen say, given und when (analog zur switch-Anweisung in C), der smartmatch-Operator (~~), der defined or-Operator (//) und state-Variablen, welche die Erzeugung von Closures vereinfachen. Weitere nennenswerte Neuheiten umfassen den verlagerbaren Installationspfad, stapelbare Dateitestoperatoren, definierbare lexikalische Pragmas, optionale C3-Serialisierung der Objektvererbung und field hashes (für ,,inside out"-Objekte). Die Regex-Engine arbeitet nun iterativ statt rekursiv, was nun rekursive Ausdrücke ermöglicht. Komplexe Suchanfragen können nun auch verständlicher und weniger fehleranfällig durch named captures formuliert werden. Die Spezialvariablen $# und $* sowie die Interpreterschnittstellen perlcc und JPL wurden entfernt.
Im folgenden Jahr wurden die Quelle von Perforce auf Git umgestellt, was die Entwicklung und Herausgabe neuer Versionen wesentlich vereinfachte.
Eine gute Idee, leider habe ich wohl schon 5.10:
synology> perl -v
This is perl, v5.10.0 built for i686-linux-gnu
Ich werde aber auch das Gefühl nicht los, dass er mit der if-clause ein Problem hat. Bin nicht so perl-erfahren, kann man die Bedingung evtl. anders formulieren?
Nachtrag: es wird bei mir doch kein perl 5.10 verwendet!
Wenn ich das Skript um "use 5.010;" ergänze, dann bekomme ich folgenden Fehler:
fhem> reload 98_Heating_Control
Perl v5.10.0 required--this is only v5.8.6, stopped at /usr/local/FHEM/share/fhem/FHEM/98_Heating_Control.pm line 30.
BEGIN failed--compilation aborted at /usr/local/FHEM/share/fhem/FHEM/98_Heating_Control.pm line 30.
Also entweder bekomme ich das richtige perl 5.10, das Voraussetzung für das Skript ist, zum Laufen. Oder jemand hat einen Vorschlag, wie man die Bedingung ohne 5.10-Spezialität formuliert ;-)
Man kann die Stelle leicht anders formulieren. Mache ich heute abend.
habe es soeben geändert und schon eingeckeckt - nach einem update sollte es auch auf der 5.8er Version von Perl laufen.
Vielen Dank, Problem gelöst!
Zur Info: Synology hat ein Perl 5.8.6 mitgeliefert. Mittels "ipkg install perl" bekommt man zwar perl 5.10, aber dieses liegt unter /opt/bin/perl. Es wird auch normalerweise verwendet. Nur dass fhem direkt auf /usr/bin/perl verweist und von daher immer perl 5.8.6 verwendet werden wird. Was natürlich für alle Modulle ebenso gilt.
In meinem fhem-2013-02.log habe ich gefunden das die Einträge mehrfach vorkommen. Das bedeutet das die auch mehrfach gesendet werden. Aber warum? Mache ich was falsch.
Das Log-File sieht so aus:
8x------------------------------------------
2013.02.20 09:45:00 2: FS20 set TerrariumHauptspot on
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:00 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:00:01 2: FHT set hz_Wohnzimmer desired-temp 17.0
2013.02.20 16:30:01 2: FHT set hz_Olymp desired-temp 21.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:00:00 2: FHT set hz_Ines desired-temp 17.0
2013.02.20 17:47:39 2: FS20 set ExtraSchalter on
8x------------------------------------------
Hast Du Dir die neueste Version per update gezogen?
Es war ein Fehler enthalten, der aber eigentlich korrigiert sein sollte.
Im Verzeichnis \fhem\usr\share\fhem\FHEM\ ist die Datei 98_Heating_Control.pm vom 7.2.13. Klingt ziemlich aktuell.
nein, das ist nicht sehr aktuell - gerade in der letzen Woche habe ich es mehrmals freigegeben:
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/98_Heating_Control.pm?view=log (//fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/98_Heating_Control.pm?view=log)
Selbst die Dokumentation habe ich mehrfach verändert.
Entweder einen Komplettupdate von fhem durchführen oder das einzelne Modul ersetzen.
Mein update geht nicht mehr. Egal was ich eingebe. "update stable full force" zum Beispiel geht nicht. Das Modul ändert sich nicht. Was kann ich tun?
ich meine man muss nur "update" eingeben - ich hatte auch mal ein solches Problem mit dem update.
wenn das nicht klappt folgenden Link aufrufen:
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/98_Heating_Control.pm?view=log (//fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/98_Heating_Control.pm?view=log)
und das Programm direkt über den Downloadlink herunterladen, ins fhem-Verzeichnis kopieren, reload 98_Heating_Control ausführen und im fhem-log prüfen ob alles ok ist.
Ich finde das Modul super. Es kann mir eine Menge "at" Regeln ersparen. Es gibt nur noch eins, was mich davon abhält, in meiner Konfiguration alle Regeln umzustellen. Für mich als MAX-Benutzer ist es unheimlich praktisch, für desired temperature die Werte "comfort" und "eco" benutzen zu können. Diese "symbolischen Werte" sind in den Ventilen gespeichert und auch für manuelles Umschalten direkt abrufbar. Manchmal justiere ich diese Werte nach. Wenn ich in den Regeln die Temperaturwerte verwenden muss, müsste ich dann auch alle Regeln wieder neu eingeben.
Wäre es nicht möglich, auch diese "Werte" zuzulassen?
- Michael
Ich werde deinen Wunsch heute prüfen.
Auf dem ersten Blick, scheint es mir aber möglich zu sein, so eitwas umzusetzen.
Es muss dann wahrscheinlich etwas mehr umgebaut werden.
Kann ich dich dann als Tester einsetzen - ich habe kein MAX?
Ja klar, ich teste das gerne.
Hallo,
es wurde hier mehrfach der Erweiterungswunsch für eine Wochenzeitschaltuhr geäußert.
Nun wollte ich nicht mehr länger auf eine Umsetzung warten und habe für mich gerade das Modul erweitert.
(siehe Anhang / see attachement)
Bei Interesse kann ich hier die paar Änderungen für die Entwickler posten.
Gruß
Damian
schick mir bitte deine Version des Moduls per PM, dann arbeite ich sie ein und stelle das Modul online.
Ich habe Deine Änderungen 1:1 übernommen und inzwischen eingecheckt.
Ich nutze das Heating-Control gerne und finde es sehr gelungen.
Ein zeitlicher Offset als zusätzliches Attribut wäre hilfreich.
Meine Zielvorstellung:
Der Schaltzeitpunkt des Heating_Controls bedeutet nicht mehr wie bisher:
"Setze den Sollwert des Thermostats xy"
sondern
" zu diesem Zeitpunkt soll der Raum die Solltemperatur erreicht haben"
Wenn ich etwa weiss, dass es ca. 1,5 Std. dauert, bis der Raum von 16 auf 19 Grad geheizt ist,
wäre das neue Attribut wie folgt zu realisieren.
attr myHeatingControl time_offset 01:30
Vielleicht findet der Vorschlag ja Anhänger
John
Ich habe es bisher immer so gehalten, dass ich bei der Definition der Schaltzeitpunkte selbst das offset immer so gut es ging eingerechnet habe.
Also wenn ich morgens um 6:30 in der Küche frühstücken will muss ich um 5:45 die Heizung anschalten.
Machbar wäre es sicherlich eine solche Erweiterung einzubauen.
Ich habe allerdings noch keine Vorstellung wie ich es machen könnte, es dürfte aber in jedem Fall einiges an Aufwand bedeuten und auch nicht ganz unkompliziert sein.
In den Sommermonaten werde ich bestimmt nicht dazu kommen.
Ich hoffe, der Sommer noch kommt!
Probleme mit der Sommerzeitumstellung:
Link (http://forum.fhem.de/index.php?topic=12012.msg71089#msg71089)
Ich glaube ich habe einen Weg gefunden HC gegen Sommerzeitumstellungen immun zum machen.
War gar nicht so schwer!
Ich werde es einbauen testen und bei Gelegenheit in SVN einchecken.
Zitat von: Dietmar63 schrieb am So, 17 Februar 2013 17:34Wenn du wie im Beispiel beschrieben HC so
define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
definierst, erfolgt keine weitere Schaltung seitens HC, wenn WeAreThere nicht auf yes steht.
Ein notify erledigt den Rest: Ich habe mit
define Befehl5a notify WeAreThere:no {fhem ("set HeizungKueche desired-temp 18;; set HeizungWohnen desired-temp 18") }
erreicht, dass beim Setzen des Dummys die Temperaturen korrigiert werden. So bleiben sie bis ich WeAreThere wieder auf yes setze.
Zur Zeit gibt es keine Möglichkeit automatisch die Pläne zu ändern. Ich habe mir so geholfen, dass ich zwei HC angelegt habe. Über die Bedingungvariable kannst du steuern wann welcher HC schalten soll.
Ich hatte vor einiger Zeit nach der Umsetzung von HC mit dem Homestatus gefragt.
Bei mir kann der Dummy "HomeStatus" die Werte 1-4 übernehmen (
http://www.fhemwiki.de/wiki/Zuhause-Status)
Nun habe ich folgendes geschrieben:
define eg_bz_Heizung_Heizungsplan_zuhause Heating_Control eg_bz_Heizung Mo,Di,Mi,Do|03:08|23 Mo,Di,Mi,Do|23:00|18 Fr,Sa,So|06:00|23 Fr,Sa,So|12:00|21 Fr,Sa,So|23:00|18 (ReadingsVal("HomeStatus" < 3 )
define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo,Di,Mi,Do,Fr,Sa,So|03:08|10 Mo,Di,Mi,Do,Fr,Sa,So|17:00|10 Mo,Di,Mi,Do,Fr,Sa,So|01:00|10 (ReadingsVal(Value("HomeStatus") > 2 )Leider bekomme ich dabei eine Fehlermeldung:
2013.04.01 03:07:58 3: Not enough arguments for main::ReadingsVal at (eval 130) line 1, near "2 )"
syntax error at (eval 130) line 1, at EOF
2013.04.01 03:08:00 3: Not enough arguments for main::ReadingsVal at (eval 131) line 1, near "2 )"
syntax error at (eval 131) line 1, at EOF
2013.04.01 03:08:01 3: Not enough arguments for main::ReadingsVal at (eval 132) line 1, near "3 )"
syntax error at (eval 132) line 1, at EOF
2013.04.01 03:08:01 3: Not enough arguments for main::ReadingsVal at (eval 133) line 1, near "2 )"
syntax error at (eval 133) line 1, at EOFFehlt mir etwas?
Die Bedingung aus dem Zitat oben verstehe ich leider nicht voillständig: (ReadingsVal("WeAreThere", "state", "no") eq "yes")
Was bedeutet das "state"?
Die Bedingungen sind syntaktisch noch nicht korrekt. Versuch es mal mit folgende Änderungen:
define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
define eg_1 Heating_Control eg_bz_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("HomeStatus", "state", 1) < 3)
define eg_2 Heating_Control eg_bz_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("HomeStatus", "state", 1) > 2)
bei "state" handelt es sich um ein Reading eines dummys. Geräte haben oft viele verschiedene Readings - man könnte auch Statusvariable dazu sagen. Einfach mal in der Oberfläche von fhem auf ein Gerät clicken - dann kann man sich Details ansehen.
Ich habe die Texte deiner beiden Zeilen ein wenig gekürzt, damit Du erkennst wie die Readings ausgelesen werden können.
Unterhalb von "no" habe ich "1" angegeben. Das mußt Du deinen Verhältnissen anpassen. Es handelt sich um den Wert, der "ausgelesen" wird, wenn das Reading "state" nicht gefunden wird.
Also den hinteren Teil der beiden letzen Zeilen ins cfg dann solltest du weiterkommen. Ich habe nicht getestet, sollte aber trotzdem funktionieren.
Lieben Dank für die schnelle Antwort!
Ich habe nun das Coding angepasst, bekomme aber leider gar nichts mehr im Log. Habe um 15:03 versucht mit zwei Heizungs-Controll-Devices entsprechend des Komestatus zu schalten:
define eg_bz_Heizung_Heizungsplan_zuhause Heating_Control eg_bz_Heizung Mo,Di,Mi,Do|15:03|23 Mo,Di,Mi,Do|23:00|18 Fr,Sa,So|06:00|23 Fr,Sa,So|12:00|21 Fr,Sa,So|23:00|18 (ReadingsVal("HomeStatus", "state", 1) < 3)
define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo,Di,Mi,Do,Fr,Sa,So|15:03|10 Mo,Di,Mi,Do,Fr,Sa,So|17:00|10 Mo,Di,Mi,Do,Fr,Sa,So|01:00|10 (ReadingsVal ("HomeStatus", "state", 1) > 2)
Habe ich einen Denkfehler? Wenigstens bekomme ich keine Error-Meldung mehr.
EDIT: scheint nun zu gehen. Hatte wohl keine Änderung im Log, da ich keinen Temperaturwechsel hatte.
Ein Fehler noch:
Im Log erscheint nun (HomeStatus = 4) statt einmal mehrmals:
2013.04.01 15:19:46 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:01 2: FHT set eg_bz_Heizung desired-temp 10.0
Woand liegt das?
{Log 3, ReadingsVal ("HomeStatus", "state", 1) }
Gib mal obigen Code in die Kommandozeile von fhem ein und kontrolliere das Log.
Dort müsstest du den aktuellen HomeStatus finden.
Achtung HC verändert die Temperatur nur wenn es etwas zu Ändern gibt.
Könnte daran liegen, dass du nicht die neueste Version hast. Update ausfuhren und alles ist gut.
Hallo,
eine Verständnisfrage / Anmerkung:
Was ist die eigentliche Intention die gesamte Steuerung der Schaltzeitpunkte (incl. Wochenplan) der einzelnen Temperaturreglern (FHTs) durch die Zentrale (sprich Fhem) zu machen, wo doch die einzelnen FHTs Wochenschaltpläne mit bis zu zwei Tageszeitperioden pro Tag erlauben und somit autark die Regelung für die einzelnen Räume vornehmen können?
Für die wenigen Räume, in denen mehr als zwei Perioden benötigt werden, lässt sich das einfach mit Bordmitteln (sprich Party-Funktion) der FHT realisieren. Pro zusätzliche Tageszeitintervall per ,,at" ein Aufruf der FHT Partyfunktion z.B. als Subroutine in der Form
{fht_party("<FHT-dev-name>","<Zeit-Interval>","<desired-temp>")}
Die gesamten Parameter (für den impliziten holiday-short Befehl, der von fht_party erzeugt werden muss) werden in einem Funkbefehl an das FHT Gerät übertragen. Ein weiteres (Funk-)Kommando am Ende des zusätzlichen Tagestemperaturintervalls ist nicht erforderlich. Auch bei einer großen Anzahl von FHT-Geräten wird somit allein konzeptionsbedingt , die häufig auftretenen Kommunikationsprobleme bei einer großen Anzahl von FHT Geräten weitestgehend verhindert.
Insbesondere wenn man (später) weitere Komfortfunktionen realisieren möchte, wie z.B. das temporäre ad hoc Aufheizen eines Fitnessraumes, Bügelzimmers oder Hobbyraumes per Mausklick oder per (IR-) Fernbedienung ist es von Vorteil, wenn die entsprechende FHTs im auto mode der FHT Geräte laufen . Per Party-Funktion, diesmal per Mausklick getriggert, wird der Schaltplan für die angegeben Zeit im FHT Gerät außer Kraft gesetzt (und lässt sich ggf. per Mausklick bzw. durch einfaches Drücken der ,,FUNKTION" Taste am FHT Gerät vorzeitig wieder aufheben).
Wegen den Kommunikationproblemen bei einer großen Anzahl von FHT Geräten bin ich von einen ,,zentralistischen" Ansatz bei der Steuerung der FHTs völlig abgekommen und nutze die dezentrale Funktionen der FHTs, wo immer möglich. Mit dieser Lösung bin ich sehr zufrieden und plane nun sogar meine letzten Räume (13. und 14.) mit FHT auszurüsten (ursprünglich hatte ich hierfür schon HM im Visier) .
Viele Grüße,
Ludger
P.s. Wechsel auf Sommerzeit wird von den FHTs automatisch durchgeführt. Lediglich wenn man, wie ich, um Mitternacht die Aufstehzeit noch ad hoc variiert und den Schaltzeitpunkt für den Wechsel von Nacht auf Tag für alle FHT Geräte per Party-Funktion am Wochenende individuell anpasst und dies ausgerechnet zwischen 1:30 und 3:00 Uhr scheduled erzielt man nicht bei allen Geräten das gewünschte Ergebnis :).
Die FHTs bieten nur eine Heiz- und eine Absenktemperatur für den gesamten Tag.
Zitat von: LudgerR schrieb am Mo, 01 April 2013 19:53Hallo,
Was ist die eigentliche Intention die gesamte Steuerung der Schaltzeitpunkte (incl. Wochenplan) der einzelnen Temperaturreglern (FHTs) durch die Zentrale (sprich Fhem) zu machen, wo doch die einzelnen FHTs Wochenschaltpläne mit bis zu zwei Tageszeitperioden pro Tag erlauben und somit autark die Regelung für die einzelnen Räume vornehmen können?
Persönlich bin ich von dem Heating_Control-Modul begeistert, weil es für meine MAX! Ventile in FHEM keine Möglichkeit gibt, Wochenpläne zu erstellen, die auf das Ventil übertragen werden. (Wenn es das für FHTs gibt, habe ich es in FHEM nicht gefunden.) Natürlich hätten "autonome" Wochenpläne auch etwas (werden grundsätzlich auch von MAX! unterstützt).
Unabhängig davon sehe ich aber einen Vorteil von Heating_Control darin, in den Plänen Bedingungen unterzubringen. Ich benutzte das zwar nicht in allen Räumen, aber in einigen ist es ganz sinnvoll in den Schulferien anders zu regeln.
Gruß
Michael
Zitat von: Dietmar63 schrieb am Mo, 01 April 2013 15:32Könnte daran liegen, dass du nicht die neueste Version hast. Update ausfuhren und alles ist gut.
Danke für Deine Hilfe, Dietmar!
Das Update habe ich durchgeführt. Nun kann ich auch Mo-Fr nutzen.
Ich möchte nun in Abhängigkeit von genau einem Status die Temperaturen setzen, bekomme aber bei folgendem Coding:
define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo-So|08:30|16 Mo-So|16:30|20 Mo-So|22:00|16 (ReadingsVal ("HomeStatus", "state", 1) = 3)
attr eg_bz_Heizung_Heizungsplan_weg room Badezimmerdiese Fehlermeldung:
2013.04.01 22:42:11 3: Can't modify non-lvalue subroutine call in scalar assignment at (eval 376) line 1, near "3)"
Hast Du dazu eine Idee.
Eine weitere Frage: Ich bekomme leider manchmal ein volles Log mit 20-30 folgender Meldungen:
2013.04.01 22:39:50 2: CUL_0: unknown message LOVF
2013.04.01 22:39:51 2: CUL_0: unknown message LOVF
2013.04.01 22:39:51 2: CUL_0: unknown message LOVF
2013.04.01 22:39:51 2: CUL_0: unknown message LOVF
...
...
Nachdem ich FHEM neu starte, den Cul resette oder etwas anderes (?) mache, setzt mir irgendwas im Log verschiedene FHTs:
2013.04.01 22:53:44 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.01 22:53:44 2: FHT set eg_az_Heizung desired-temp 15.0
2013.04.01 22:53:45 2: FHT set eg_ku_Heizung desired-temp 19.0
2013.04.01 22:53:45 2: FHT set eg_ki_Heizung desired-temp 15.0
2013.04.01 22:53:45 2: FHT set og_sz_Heizung desired-temp 15.0
Warum passiert das? Können dadurch die Funktprobleme und die LOVF-Meldungen auftreten?
define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo-So|08:30|16 Mo-So|16:30|20 Mo-So|22:00|16 (ReadingsVal ("HomeStatus", "state", 1) == 3)
attr eg_bz_Heizung_Heizungsplan_weg room Badezimmer
Kleiner Fehler bei =. Verwende ==
LOVF bekommst du wenn du zu viele Kommandos in fhem versendet. Ein Google und du bekommst viele Tipps dazu .
Beim Start jedes HC wird die Temperatur auf den passenden aktuellen Wert gesetzt
Hallo Dietmar,
warum nicht die Anzahl der Parameter von 1 (desired-temp) auf (zumindest) 2 erweitern ?
Damit würde aus deinem ursprünglichen Heating-Control Modul ein ziemlich flexibles ,,Wochenschaltplan" Modul, das auch für andere Zwecke verwendet werden könnte.
In meinem Fall als intensiver Nutzer der Party/Urlaubs Funktion der FHT Geräte könnte ich die Funktion
{fht_party("<FHT-dev-name>","<Zeit-Interval>","<desired-temp>")}
als Komando
{fht_party("@","$","%")}
in Heating-Control spezifizieren, vorausgesetzt ein zusätzlicher (optionaler) Parameter (zu desired-temp) ließe sich vorgeben und würde im command ausgewertet.
Anstelle von
define HCW1 Heating_Control heizung.01 15:00|19.1 Mo-Fr|17:30|21
sehe die Defintion möglicherweise so
define HCW1 Heating_Control heizung.01 15:00|19.1_120 Mo-Fr|17:30|21_300
bzw. folgendermaßen aus
define HCW1 Heating_Control heizung.01 15:00|19.1:120 Mo-Fr|17:30|21:300
Gruß,
Ludger
In meinem Haushalt spielen feste Wochenschaltpläne nur eine untergeordnete Rolle, feste Ferienzeiten mit planbarer Anwesenheit von Familienmitgliedern gibt es nicht. Das kurzeitige Aufheizen von Räumen auf Komfort-Temperatur außerhalb der Regelzeiten steht im Vordergrund.
Ich finde es halt praktisch, wenn der Sohnemann sein Studierzimmer per Fernbedienung (oder Smartphone) in einen oder mehrstündigen Partymodus setzen kann und spätestens beim Verlassen des Hauses durch kurze Betätigung der FUNKTION sTaste auf dem FHT Gerät bequem wieder in den Absenkmodus wechseln kann.
Abgesehen von wenigen Ausnahmen, wo ich mehr als zwei Komforttemperaturintervalle benötige, hinterlege ich keine Schaltzeiten für FHT Geräte in Fhem. Ich habe auch kein Problem damit bei umfangreichen Änderung des Schaltprogrammes dies am FHT Gerät selbst zu tun. Die Schaltzeiten der einzelnen FHTs sehe ich ja in den Readings bzw. im zugehörigen Plot der Geräte, wenn ich ,,desired-temp" zusätzlich zu ,,measured-temp" und Actuator % auswerte.
Der Ansatz komplette Wochenschaltprogramme für alle FHT Geräte kompakt zentral in Fhem zu haben und flexibel zu verwalten ist halt sehr verführerisch. Bei einer großen Anzahl von FHT Geräten stößt man jedoch schnell an die (Funk-) Grenzen.
Mir ging es primär darum aufzuzeigen (um anderen leidvolle Erfahrungen zu ersparen), dass man mit den Grundfunktionen der FHT Geräte einiges flexibel realisieren kann und man nicht für jedes FHT Gerät die Steuerung
komplett über die Zentrale (Fhem) realisieren muss.
Gruß,
Ludger
Ich habe im Moment nur zwei FHT im Einsatz.
Mehr ist bei mir im Moment auch nicht geplant, da ich noch Standalone-thermostate habe, die auch ganz gut funktionieren.
ZitatDer Ansatz komplette Wochenschaltprogramme für alle FHT Geräte kompakt zentral in Fhem zu haben und flexibel zu verwalten ist halt sehr verführerisch. Bei einer großen Anzahl von FHT Geräten stößt man jedoch schnell an die (Funk-) Grenzen.
Warum sollte das so sein? Pro FHT wird vielleict 6-10 mal am Tag geschaltet. In Räumen, in denen nicht viele verschiedene Schaltzeiten notwendig sind entsprechend seltener. Bisher habe ich noch kein Problem mit den (Funk-) Grenzen gehabt - habe aber auch nur zwei FHT an der Zentrale angeschlossen.
Praktisch ist es jedenfalls in der Lage zu sein aus der Ferne die Heizung einschalten zu können.
@Ludger:
Dieser Wunsch ist heute schon realisert. Der Parameter hinter der Zeit ist einfach nur Text, der anstelle von % weitergegeben wird:
Versuch mal folgendes:
define HCW1 Heating_Control heizung.01 15:00|19.1:120 Mo-Fr|17:30|21:300 {fht_party("@","%")}
Als zweiten Parameter bekommst Du dann in fht_party 19.1:120 bzw. 21:300 geliefert.
Du musst den Parameter nur selbst auseinander nehmen und verwerten.
Hallo Dietmar,
wenn die Schaltbefehle für die einzelnen FHT Geräte insgesamt schön über die Zeitachse verteilt sind, funktioniert das ganz gut. Wenn aber für 6 bis 10 Thermostate gleichzeitig für 6:30 der Wechsel auf die Tagestemperatur über ein CUL/CUNO device geschickt wird, kann dies schnell zu Kommunikationsproblemen führen, abgesehen davon, dass es erhebliche Zeitverzögerungen gibt, bis endlich die neuen Temperaturwünsche an allen Geräten angekommen sind. Das ist der Grund, warum ich morgens und abends die Steuerung per FHT Wochenschaltplan mache (--> alle Geräte im auto modus) und während des Tages zusätzliche Zeitintervalle mit (z.T. erhöhter) Komforttemperatur per Party-Funktion steuere, entweder geplant per "at" oder ad hoc per IR-FB bzw. Handy. Zusätzlich schalte ich hin- und wieder für einige Räume, die an diesem Tag nicht mehr benutzt werden, die "desired-temp" vor Erreichen des Schaltpunktes am Abend per IR-FB vorzeitig auf Absenktemperatur. Seitdem ich so verfahre ist LOVL trotz 12 FHTs glücklicherweise ein Fremdwort geworden.
Mit diesem Verfahren ist auch sichergestellt, das ein Raum nicht den ganzen Tag bis zur Nachtabschaltung der Heizung wegen eines nicht empfangenen Absenktemperatur unnötigerweise aufgeheizt bleibt.
Die Steuerung per Party-Funktion hat m.E.ein schönes Goodie. Die geplanten Schaltzeitpunkte lassen sich mit dieser Funktion sehr schön aus dem Stehgreif "temporär überschreiben". Der letzte Party-/Urlaubs-Befehl zählt für die gesamt angegebene Dauer, ganz gleich, ob er per Mausklick/touch oder am FHT Gerät selbst ausgeführt wurde.
Das der Wochenschaltplan der FHTs nicht zentral in einer schönen Übersicht vorliegt, mag zwar ein Manko sein. Zumindestens die Readings der FHT Geräte halte ich aktuell indem ich jede Nacht ab 22:30 die Schaltzeitpunkte für den kommenden Tag plus Tages- und Absenktemperatur per "report1/2" von den FHTs anfordere und somit auf den aktuellen Stand halte. Übrigens, alle routinemäßigen Funk-Kommandos an die FHTs schedule ich (automatisch generiert) mit einem Zeitintervall von rund 15 Minuten. Nur so konnte ich bei mehr als 10 FHTs die Limitierung im Funkbereich aufgrund der 1% Regel und durch Befehlswiederholung in den Griff bekommen. Da der meiste Funkverkehr in der Nacht läuft (Update der Schaltpunkte ab 22:30 Uhr, ad hoc Überschreibung des morgendlichen "Tagesbeginns" einzelner bzw. aller FHTs ab 1:30 Uhr (am), habe ich bis auf die zuätzlichen Komforttemperatur-Intervalle im Tagesverlauf kaum Funkbelastung durch Steuerung der FHT Geräte.
Bei wenigen FHT Geräten sehe ich wenig Probleme dies auschließlich von der Zentralen per Heating-Control zu machen und die FHTs u.U. sogar im "manu" Betrieb zu fahren. Wer jedoch plant mit 10 oder mehr FHT Geräten die Temeratur komfortabel (und mit wenig Fehlern zu steuern), sollte das zeitgleiche Schalten von mehreren FHTs per Funk möglichst (konzeptionell) vermeiden / minimieren. In dem Fall kann Heating-Control sicherlich die Steuerung während des Tages erleichtern und insbesondere Bedingungen wie Anwesenheit während der Ferienzeiten etc. gut abbilden.
Gruß,
Ludger
Ich verfolge die Diskussion hier gespannt, da mich leider die Thematik mit den Funktüberschreitungen auch trifft. Ich habe 8 FHTs im Einsatz. Dazu noch 3 von den Hygrostaten.
Hier mal das aktuelle Log nachdem ich per Heizungsplan nur 3 FHTs umgestellt habe :-( :
2013.04.02 17:42:16 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.02 17:42:17 2: FHT set eg_ki_Heizung desired-temp 20.0
2013.04.02 17:42:17 2: FHT set eg_ku_Heizung desired-temp 19.0
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:53 2: CUL_0: unknown message LOVF
2013.04.02 17:42:53 2: CUL_0: unknown message LOVF
2013.04.02 17:43:28 2: CUL_0: unknown message LOVF
2013.04.02 17:43:28 2: CUL_0: unknown message LOVF
2013.04.02 17:43:29 2: CUL_0: unknown message LOVF
2013.04.02 17:43:29 2: CUL_0: unknown message LOVF
2013.04.02 17:43:56 2: CUL_0: unknown message LOVF
2013.04.02 17:44:49 2: CUL_0: unknown message LOVF
2013.04.02 17:44:50 2: CUL_0: unknown message LOVF
2013.04.02 17:44:50 2: CUL_0: unknown message LOVF
2013.04.02 17:45:24 2: CUL_0: unknown message LOVF
2013.04.02 17:45:24 2: CUL_0: unknown message LOVF
2013.04.02 17:45:24 2: CUL_0: unknown message LOVF
2013.04.02 17:45:25 2: CUL_0: unknown message LOVF
2013.04.02 17:46:47 2: CUL_0: unknown message F2A2CE2
2013.04.02 17:49:03 2: CUL_0: unknown message LOVF
2013.04.02 17:49:03 2: CUL_0: unknown message LOVF
2013.04.02 17:49:04 2: CUL_0: unknown message LOVF
2013.04.02 17:49:04 2: CUL_0: unknown message LOVF
2013.04.02 17:49:16 2: CUL_0: unknown message LOVF
2013.04.02 17:49:18 2: CUL_0: unknown message LOVF
2013.04.02 17:49:18 2: CUL_0: unknown message LOVF
2013.04.02 17:49:19 2: CUL_0: unknown message LOVF
2013.04.02 17:49:19 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:51:14 2: CUL_0: unknown message LOVF
2013.04.02 17:51:14 2: CUL_0: unknown message LOVF
2013.04.02 17:52:40 2: CUL_0: unknown message LOVF
2013.04.02 17:52:57 2: CUL_0: unknown message LOVF
2013.04.02 17:52:57 2: CUL_0: unknown message LOVF
2013.04.02 17:52:57 2: CUL_0: unknown message LOVF
2013.04.02 17:53:12 2: CUL_0: unknown message LOVF
2013.04.02 17:53:12 2: CUL_0: unknown message LOVF
2013.04.02 17:54:08 2: CUL_0: unknown message LOVF
2013.04.02 17:54:08 2: CUL_0: unknown message LOVF
2013.04.02 17:54:09 2: CUL_0: unknown message LOVF
2013.04.02 17:54:09 2: CUL_0: unknown message LOVF
2013.04.02 17:54:35 2: CUL_0: unknown message LOVF
2013.04.02 17:54:35 2: CUL_0: unknown message LOVF
2013.04.02 17:54:35 2: CUL_0: unknown message LOVF
2013.04.02 17:54:36 2: CUL_0: unknown message LOVF
2013.04.02 17:55:14 2: CUL_0: unknown message LOVF
2013.04.02 17:55:14 2: CUL_0: unknown message LOVF
2013.04.02 17:57:06 2: CUL_0: unknown message LOVF
2013.04.02 17:58:38 2: CUL_0: unknown message LOVF
2013.04.02 17:58:38 2: CUL_0: unknown message LOVF
2013.04.02 17:58:38 2: CUL_0: unknown message LOVF
2013.04.02 17:58:39 2: CUL_0: unknown message LOVF
2013.04.02 17:59:04 2: CUL_0: unknown message LOVF
2013.04.02 17:59:05 2: CUL_0: unknown message LOVF
2013.04.02 18:00:37 2: CUL_0: unknown message LOVF
2013.04.02 18:00:37 2: CUL_0: unknown message LOVF
2013.04.02 18:00:37 2: CUL_0: unknown message LOVF
2013.04.02 18:00:38 2: CUL_0: unknown message LOVF
2013.04.02 18:01:02 2: CUL_0: unknown message LOVF
2013.04.02 18:01:03 2: CUL_0: unknown message LOVF
2013.04.02 18:01:19 2: CUL_0: unknown message LOVF
2013.04.02 18:01:20 2: CUL_0: unknown message LOVF
2013.04.02 18:01:20 2: CUL_0: unknown message LOVF
2013.04.02 18:01:20 2: CUL_0: unknown message LOVF
2013.04.02 18:02:43 2: CUL_0: unknown message LOVF
2013.04.02 18:02:44 2: CUL_0: unknown message LOVF
2013.04.02 18:02:44 2: CUL_0: unknown message LOVF
2013.04.02 18:02:59 2: CUL_0: unknown message LOVF
2013.04.02 18:03:00 2: CUL_0: unknown message LOVF
2013.04.02 18:03:16 2: CUL_0: unknown message LOVF
2013.04.02 18:03:16 2: CUL_0: unknown message LOVF
2013.04.02 18:03:16 2: CUL_0: unknown message LOVF
2013.04.02 18:05:12 2: CUL_0: unknown message LOVF
2013.04.02 18:05:12 2: CUL_0: unknown message LOVF
2013.04.02 18:05:12 2: CUL_0: unknown message LOVF
2013.04.02 18:05:45 2: CUL_0: unknown message LOVF
2013.04.02 18:05:45 2: CUL_0: unknown message LOVF
2013.04.02 18:05:45 2: CUL_0: unknown message LOVF
2013.04.02 18:05:46 2: CUL_0: unknown message LOVF
2013.04.02 18:05:47 2: CUL_0: unknown message LOVF
2013.04.02 18:05:47 2: CUL_0: unknown message LOVF
2013.04.02 18:05:47 2: CUL_0: unknown message LOVF
2013.04.02 18:05:48 2: CUL_0: unknown message LOVF
2013.04.02 18:06:55 2: CUL_0: unknown message LOVF
2013.04.02 18:06:55 2: CUL_0: unknown message LOVF
2013.04.02 18:07:44 2: CUL_0: unknown message LOVF
2013.04.02 18:07:44 2: CUL_0: unknown message LOVF
2013.04.02 18:07:45 2: CUL_0: unknown message LOVF
2013.04.02 18:08:14 2: CUL_0: unknown message LOVF
2013.04.02 18:08:14 2: CUL_0: unknown message LOVF
2013.04.02 18:09:03 2: CUL_0: unknown message LOVF
2013.04.02 18:09:03 2: CUL_0: unknown message LOVF
2013.04.02 18:09:03 2: CUL_0: unknown message LOVF
2013.04.02 18:09:04 2: CUL_0: unknown message LOVF
2013.04.02 18:09:04 2: CUL_0: unknown message LOVF
2013.04.02 18:09:04 2: CUL_0: unknown message LOVF
2013.04.02 18:09:05 2: CUL_0: unknown message LOVF
2013.04.02 18:09:42 2: CUL_0: unknown message LOVF
2013.04.02 18:09:42 2: CUL_0: unknown message LOVF
2013.04.02 18:09:42 2: CUL_0: unknown message LOVF
2013.04.02 18:09:43 2: CUL_0: unknown message LOVF
2013.04.02 18:10:30 2: CUL_0: unknown message LOVF
2013.04.02 18:10:30 2: CUL_0: unknown message LOVF
2013.04.02 18:10:49 2: CUL_0: unknown message LOVF
2013.04.02 18:10:50 2: CUL_0: unknown message LOVF
2013.04.02 18:11:02 2: CUL_0: unknown message LOVF
2013.04.02 18:11:02 2: CUL_0: unknown message LOVF
2013.04.02 18:11:03 2: CUL_0: unknown message LOVF
2013.04.02 18:11:03 2: CUL_0: unknown message LOVF
2013.04.02 18:25:18 2: CUL_0: unknown message LOVF
2013.04.02 18:25:18 2: CUL_0: unknown message LOVF
2013.04.02 18:26:29 2: CUL_0: unknown message LOVF
2013.04.02 18:26:30 2: CUL_0: unknown message LOVF
2013.04.02 18:26:30 2: CUL_0: unknown message LOVF
Der Autor des CULMAX-Moduls hat genialer Weise irgendwann ein Queuing beim Senden der Befehle implementiert. Seitdem habe ich keine Probleme mehr mit LOVF. Vielleicht braucht FHT das auch.
@gunter, Ludger
Die LOVF scheinen tatsächlich das zu bestätigen, was du, Ludger vorher gesagt hast.
Dass das Problem aber schon nach 3 fht auftritt, könnte an zusätzlichen Funkproblemen liegen - kann ich aber nicht genau sagen.
Wie gesagt, beim Start bekommen alle fht ihre Start temp, deshalb die drei desired-temp.
Ehrlich gesagt bin ich ratlos - in der Dokumentation liest man, daß Probleme ab so ca. 10 fht zu erwarten sind. Bei zwei fht habe ich noch kein Problem.
Kannst du Tests durchführen, ob bei dir zusätzliche Probleme vorliegen?
gib mal folgende in der Oberfläche oder dem fhem.cfg ein:
define yy at *+00:01:00 get CUL_0 raw T02
dann bekommst du infos über deinen fht-Puffer und kannst prüfen ob sich etwas tut:
http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT (//www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT)
mit
get CUL raw X
bekommst die freien Zeiten des cul angezeigt. Mal sehen, ob wir es für dich nutzbar machen können.
FS20 und FHT scheit bei vielen FHT wirklich ein Problem zu sein.
Matthias Gehre hat wie unter folgenden Link nachzulesen ist
Link (http://forum.fhem.de/index.php?topic=10222.msg64146#msg64146)
für 14_CUL_MAX.pm Queueing eingeführt.
Es merkt sich die Kommandos und sendet erst dann wieder, wenn genug "Credit" vorhanden ist.
Aus meiner Sicht eine absolute Notwendigkeit für einen sicheren Betrieb, wenn zu einem bestimmten
Zeitpunkt gehäuft Sende-Kommandos auftauchen.
Wenn kein Acknowledge kommt wird bis zu 3x ein erneuter Sendeversuch gestartet.
Damit ist die Zustellung SEHR sicher.
Die MAX-User haben seit dieser Zeit mit dem Heating_control kein Problem mehr.
Als Workaround bietet sich folgendes an:
Die Sende-Befehle nicht alle zum gleichen Zeitpunkt senden, sondern z.B. um 5 Minuten versetzt. (Damit wird Credit gesammelt)
So hab ich das Problem vor der Einführung des Queueings gelöst.
John
ZitatDie MAX-User haben seit dieser Zeit mit dem Heating_control kein Problem mehr.
Hatten sie denn ein Problem?
Vorher ja. Allerdings trat das Problem unabhängig von Heating_Control bei mir auf, weil ich zu viele "at" Kommandos zur gleichen Zeit hatte. Jetzt ist alles gut.
ich habe mal einige Tests durchgeführt und noch mehrere HC eingebaut um Last zu simulieren:
Folgender output:
CUL_0 raw => 21 900
2013.04.02 20:10:47 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.02 20:09:47 3: CUL_0 raw => N/A
CUL_0 raw => 21 852
2013.04.02 20:08:47 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.02 20:07:47 3: CUL_0 raw => N/A
CUL_0 raw => 21 882
2013.04.02 20:06:47 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.02 20:05:47 3: CUL_0 raw => 0938:412E
CUL_0 raw => 21 886
2013.04.02 20:04:47 3: CUL_0 raw => 0938:412E
2013.04.02 20:03:37 1: define: Wrong timespec +00:01:00: either HH:MM:SS or {perlcode}
2013.04.02 20:02:44 3: CUL_0 raw => 0938:412C 0938:412E
2013.04.02 20:01:44 3: CUL_0 raw => 0938:412D 0938:412C 0938:412E
2013.04.02 20:01:00 2: FHT set HeizungWohnen desired-temp 23.0
2013.04.02 20:00:44 3: CUL_0 raw => 0938:412D 0938:412C
2013.04.02 20:00:00 2: FHT set HeizungWohnen desired-temp 22.0
2013.04.02 19:59:44 3: CUL_0 raw => 4C60:411E 0938:412D
2013.04.02 19:58:44 3: CUL_0 raw => 4C60:4120 4C60:411E 0938:412D
2013.04.02 19:57:37 2: FHT set HeizungWohnen desired-temp 22.5
2013.04.02 19:57:37 2: FHT set HeizungKueche desired-temp 15.0
2013.04.02 19:57:37 2: FHT set HeizungWohnen desired-temp 23.0
2013.04.02 19:57:37 2: FHT set HeizungKueche desired-temp 16.0
Die Pufferung funktioniert im CUL. Alles wird nach und nach abgebaut.
Bei mir stören aber auch keine zusätzichen FHT.
ich protokolliere mit:
define yy at +*00:01:00 get CUL_0 raw T02;; get CUL_0 raw X
@ Michael ...
ob Probleme mit at oder mit HC, ist bestimmt egal.
@ Gunter.
die LOVF bekommst du wegen des fehlenden credits(Sendelimit).
protokoliere mal mit:
define yy at +*00:01:00 get CUL_0 raw T02;; get CUL_0 raw X
dann verstehen wir vielleicht besser was passiert.
Auf der WEb-Site des CULS findet sich das unscheinbare Reading credit10ms.
Es behinhaltet die verfügbaren 10ms Slots des CULS zum Zeitpunkt des letzten Sendebefehls (siehe zugeordneter Zeitstempel)
Den aktuellen Credit kann man berechnen, indem man die Differenz dieses Zeitstempels zur aktuellen Zeit in Sekunden hinzu addiert.
Vielleicht hilft das für besseres Verständnis.
John
Bisher:
2013.04.02 20:37:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 195
2013.04.02 20:38:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 199
2013.04.02 20:39:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 152
2013.04.02 20:40:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 180
2013.04.02 20:41:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 102
Ich schaue später nochmal.
Zitat von: John schrieb am Di, 02 April 2013 20:39Auf der WEb-Site des CULS findet sich das unscheinbare Reading credit10ms.
Es behinhaltet die verfügbaren 10ms Slots des CULS zum Zeitpunkt des letzten Sendebefehls (siehe zugeordneter Zeitstempel)
Den aktuellen Credit kann man berechnen, indem man die Differenz dieses Zeitstempels zur aktuellen Zeit in Sekunden hinzu addiert.
Vielleicht hilft das für besseres Verständnis.
John
Danke für die Erläuterung. Ehlicherweise habe ich aber gar nichts verstanden... ;-)
Vielleicht ist mir die Erklärung zu Credit hier besser gelungen:
Link (http://forum.fhem.de/index.php?topic=11769.msg69387#msg69387)
auch dieser Link erklärt das 868 MHz Band (siehe Bereich 1 Allgemein duty cycle= < 1%)
http://www.rn-wissen.de/index.php/Funkmodule#Das_neue_868_MHz_Band (//www.rn-wissen.de/index.php/Funkmodule#Das_neue_868_MHz_Band)
John
@ Gunter:
CUL_0 raw => 21 195
CUL_0 raw => 21 199
CUL_0 raw => 21 152
CUL_0 raw => 21 180
CUL_0 raw => 21 102
sieht für mich erst mal so aus als wenn du wenig credit hast - und dass du gleich Probleme bekommst, 102 ist nicht viel.
Ich hatte immer so um die 900
@John: Danke für die Links!
@Dietmar: Habe ich eine Chance die Credits zu erhöhen?
Was ist, wenn ich den Cul zwischendurch resette?
Über Nacht gehen die Credits bis auf 900 hoch.
Hier ein kleiner Auszug aus dem Log. Dazwishen sind immer komische Meldungen.
CUL_0 raw => 21 707
2013.04.03 02:35:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 735
2013.04.03 02:36:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 698
2013.04.03 02:37:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 742
2013.04.03 02:38:38 2: CUL_0: unknown message F5208A5
2013.04.03 02:38:39 2: CUL_0: unknown message F5208A5
2013.04.03 02:38:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 729
2013.04.03 02:39:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 699
2013.04.03 02:40:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 630
2013.04.03 02:41:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 674
2013.04.03 02:42:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 734
2013.04.03 02:43:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 770
2013.04.03 02:44:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 765
2013.04.03 02:45:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 727
2013.04.03 02:46:57 3: CUL_0 raw => N/A
...
...
...
CUL_0 raw => 21 576
2013.04.03 03:27:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 507
2013.04.03 03:28:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 526K019291293D
2013.04.03 03:29:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 586
2013.04.03 03:30:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 646
2013.04.03 03:31:57 3: CUL_0 raw => N/A
Um 5 Uhr schalten die FHTs vom Bad und der Küche das erste mal per HC:
2013.04.03 04:58:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 708
2013.04.03 04:59:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 662
2013.04.03 05:00:00 2: FHT set eg_bz_Heizung desired-temp 23.0
2013.04.03 05:00:00 2: FHT set eg_ku_Heizung desired-temp 22.0
2013.04.03 05:00:57 3: CUL_0 raw => 1A04:412C
CUL_0 raw => 21 682
2013.04.03 05:01:57 3: CUL_0 raw => 1A04:412C
CUL_0 raw => 21 669
2013.04.03 05:02:57 3: CUL_0 raw => 1A04:412C
CUL_0 raw => 21 697
2013.04.03 05:03:57 3: CUL_0 raw => 1A04:412C
CUL_0 raw => 21 668
2013.04.03 05:04:57 3: CUL_0 raw => 1A04:412C
CUL_0 raw => 21 704
2013.04.03 05:05:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 641
2013.04.03 05:06:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 554
2013.04.03 05:07:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 548
2013.04.03 05:08:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 477
2013.04.03 05:09:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 520
2013.04.03 05:10:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 516
2013.04.03 05:11:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 536
2013.04.03 05:12:57 3: CUL_0 raw => N/A
CUL_0 raw => 21 595
Kann ich das Logging auch wieder ausstellen?
delete yy
Auf die Credits hast du keinen Einfluss. Sie fest in der Firmware des CUL eingebaut, damit die 1% Regel nicht verletzt wird.
Prüf mal wie es sich mit den Credits verhält wenn die drei HC starten und dann die LOVF kommen bzw. prüf mal wie sich Dein System ohne die drei HC bezüglich der Credits verhält.
Dietmar,
hatte ich mir schon gedacht, das es so funktioniert. War halt nur eine Anregung dein Modul zu einer allgemeinen komfortablen Wochen-Zeitschaltuhr (ZSU) auszubauen. Ist halt bequemer wenn man die Parameterliste nicht selbst splitten muß und sie sofort z.B. als Parameter $1,$2,... in fhem "set" Befehlen bzw. eigenen Funktionen als Wert verwenden kann. (Als Delimeter in der Definitionzeile würde ich nun ein Komma , anstatt : oder _ nun präferieren). Für meine Rolladen, die ich demnächst per Funksteuerung aufrüste, oder zur Schaltung der vielen Fensterbank-Lampen meiner Frau könnte dies eine kompakte Steuerung sein. Einzige Voraussetzung hiefür wäre jedoch noch den Schaltzeitpunkt als ausführbarer Perlcode angeben zu können, damit sunrise() und ähnliche Funktionen auch zur Verfügung stehen.( Der Appettit kommt beim Essen :) )
Gruß,
Ludger
HC ist eigentlich schon eine ZSU - müßte nur umbenannt werden, ich traue mich nur nicht weil es schon recht weit verbreitet ist.
In den Sommermonaten werde ich wahrscheinlich nicht dazu kommen grundlegende Sachen an HC zu verändern.
@ Gunther
Hast Du schon einmal weiter probiert woran es liegen könnte, dass du soviele LOVFs bekommst.
Ich habe mich ein wenig schlau gemacht, und geprüft, ob man irgendwie das verfügbare credit lesen kann, um dann die Temperatur nur dann zu setzen, wenn der credit auf einen bestimmten Wert wieder angewachsen ist.
Ich meine, man könnte es schon machen(im FHT): Softbuffer wäre das Stichwort, aber ich weiß nicht genau, ob es in deinem Fall(bei 11 FHT) dann ausreicht. Das ganze wäre aufwendig, weil das FHT-Modul ganz anders fuktionieren würde.
Wenn ich es richtig gesehen habe, hattest Du die Probleme beim Start - weil gleich 3 Temperaturen gesetzt wurden.
@Dietmar: Leider scheinen die LOVFs weiter zu kommen.
Hier mein Log:
2013.04.10 21:54:02 3: necessaryCredit------------>150
2013.04.10 21:54:02 3: key------------>1:1365623642.0966:0
2013.04.10 21:54:02 3: name------------>eg_ku_Heizung: desired-temp 19.0
2013.04.10 21:54:02 3: buffer------------>N/A
2013.04.10 21:54:02 3: credit10ms------------>497
2013.04.10 21:54:02 3: waitTime------------>0
2013.04.10 21:54:02 2: FHT set eg_ku_Heizung desired-temp 19.0
2013.04.10 21:54:02 3: waitTime------------>120
2013.04.10 21:54:02 3: Puffergroesse: 0
2013.04.10 21:54:02 3: necessaryCredit------------>150
2013.04.10 21:54:02 3: key------------>1:1365623642.30009:1
2013.04.10 21:54:02 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.10 21:54:02 3: buffer------------>1A04:4126
2013.04.10 21:54:02 3: Puffergroesse: 1
2013.04.10 21:54:02 3: SOFTBUFFERTIMER------------>30
2013.04.10 21:54:02 3: necessaryCredit------------>150
2013.04.10 21:54:02 3: key------------>1:1365623642.46482:2
2013.04.10 21:54:02 3: name------------>eg_ki_Heizung: desired-temp 15.0
2013.04.10 21:54:02 3: key------------>1:1365623642.30009:1
2013.04.10 21:54:02 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.10 21:54:02 3: buffer------------>1A04:4126
2013.04.10 21:54:02 3: Puffergroesse: 2
2013.04.10 21:54:32 3: necessaryCredit------------>150
2013.04.10 21:54:32 3: key------------>1:1365623642.46482:2
2013.04.10 21:54:32 3: name------------>eg_ki_Heizung: desired-temp 15.0
2013.04.10 21:54:32 3: key------------>1:1365623642.30009:1
2013.04.10 21:54:32 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.10 21:54:32 3: buffer------------>1A04:4126
2013.04.10 21:54:32 3: Puffergroesse: 2
2013.04.10 21:54:32 3: SOFTBUFFERTIMER------------>30
2013.04.10 21:55:02 3: necessaryCredit------------>150
2013.04.10 21:55:02 3: key------------>1:1365623642.46482:2
2013.04.10 21:55:02 3: name------------>eg_ki_Heizung: desired-temp 15.0
2013.04.10 21:55:02 3: key------------>1:1365623642.30009:1
2013.04.10 21:55:02 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.10 21:55:02 3: buffer------------>1A04:4126
2013.04.10 21:55:02 3: Puffergroesse: 2
2013.04.10 21:55:02 3: SOFTBUFFERTIMER------------>30
2013.04.10 21:55:32 3: necessaryCredit------------>150
2013.04.10 21:55:32 3: key------------>1:1365623642.46482:2
2013.04.10 21:55:32 3: name------------>eg_ki_Heizung: desired-temp 15.0
2013.04.10 21:55:32 3: key------------>1:1365623642.30009:1
2013.04.10 21:55:32 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.10 21:55:32 3: buffer------------>N/A
2013.04.10 21:55:32 3: credit10ms------------>506
2013.04.10 21:55:32 3: waitTime------------>0
2013.04.10 21:55:32 2: FHT set eg_bz_Heizung desired-temp 23.0
2013.04.10 21:55:32 3: waitTime------------>120
2013.04.10 21:55:32 3: Puffergroesse: 1
2013.04.10 21:55:32 3: SOFTBUFFERTIMER------------>120
2013.04.10 21:57:32 3: necessaryCredit------------>150
2013.04.10 21:57:32 3: key------------>1:1365623642.46482:2
2013.04.10 21:57:32 3: name------------>eg_ki_Heizung: desired-temp 15.0
2013.04.10 21:57:32 3: buffer------------>N/A
2013.04.10 21:57:32 3: credit10ms------------>504
2013.04.10 21:57:32 3: waitTime------------>0
2013.04.10 21:57:32 2: FHT set eg_ki_Heizung desired-temp 15.0
2013.04.10 21:57:32 3: waitTime------------>120
2013.04.10 21:57:32 3: Puffergroesse: 0
2013.04.10 22:00:00 3: necessaryCredit------------>150
2013.04.10 22:00:00 3: key------------>1:1365624000.02021:3
2013.04.10 22:00:00 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.10 22:00:00 3: buffer------------>1635:411E
2013.04.10 22:00:00 3: Puffergroesse: 1
2013.04.10 22:00:00 3: SOFTBUFFERTIMER------------>30
2013.04.10 22:00:00 3: FS20 set eg_ku_JalousieLinks off
2013.04.10 22:00:30 3: necessaryCredit------------>150
2013.04.10 22:00:30 3: key------------>1:1365624000.02021:3
2013.04.10 22:00:30 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.10 22:00:30 3: buffer------------>1635:411E
2013.04.10 22:00:30 3: Puffergroesse: 1
2013.04.10 22:00:30 3: SOFTBUFFERTIMER------------>30
2013.04.10 22:01:00 3: FS20 set eg_ku_JalousieRechts off
2013.04.10 22:01:00 3: necessaryCredit------------>150
2013.04.10 22:01:00 3: key------------>1:1365624000.02021:3
2013.04.10 22:01:00 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.10 22:01:00 3: buffer------------>N/A
2013.04.10 22:01:00 3: credit10ms------------>255
2013.04.10 22:01:00 3: waitTime------------>0
2013.04.10 22:01:00 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.10 22:01:00 3: waitTime------------>120
2013.04.10 22:01:00 3: Puffergroesse: 0
2013.04.10 22:18:21 2: CUL_0: unknown message LOVF
2013.04.10 22:22:30 2: CUL_0: unknown message LOVF
2013.04.10 22:22:30 2: CUL_0: unknown message LOVF
2013.04.10 22:22:31 2: CUL_0: unknown message LOVF
2013.04.10 22:24:28 2: CUL_0: unknown message LOVF
2013.04.10 22:24:29 2: CUL_0: unknown message LOVF
2013.04.10 22:24:29 2: CUL_0: unknown message LOVF
2013.04.10 22:24:29 2: CUL_0: unknown message LOVF
2013.04.10 22:24:30 2: CUL_0: unknown message LOVF
2013.04.10 22:26:25 2: CUL_0: unknown message LOVF
2013.04.10 22:26:26 2: CUL_0: unknown message LOVF
2013.04.10 22:26:26 2: CUL_0: unknown message LOVF
2013.04.10 22:27:03 2: CUL_0: unknown message LOVF
2013.04.10 22:27:03 2: CUL_0: unknown message LOVF
2013.04.10 22:27:03 2: CUL_0: unknown message LOVF
2013.04.10 22:27:04 2: CUL_0: unknown message LOVF
2013.04.10 22:28:08 2: CUL_0: unknown message LOVF
2013.04.10 22:29:38 2: CUL_0: unknown message LOVF
2013.04.10 22:41:58 2: CUL_0: unknown message LOVF
2013.04.10 22:43:05 2: CUL_0: unknown message LOVF
2013.04.10 22:43:05 2: CUL_0: unknown message LOVF
2013.04.10 22:43:05 2: CUL_0: unknown message LOVF
2013.04.10 22:43:06 2: CUL_0: unknown message LOVF
2013.04.10 22:47:04 2: CUL_0: unknown message LOVF
2013.04.10 22:47:04 2: CUL_0: unknown message LOVF
2013.04.10 22:47:04 2: CUL_0: unknown message LOVF
2013.04.10 23:05:22 2: CUL_0: unknown message LOVF
2013.04.10 23:05:22 2: CUL_0: unknown message LOVF
2013.04.10 23:06:16 2: CUL_0: unknown message LOVF
2013.04.10 23:06:16 2: CUL_0: unknown message LOVF
@Gunther:
2013.04.10 22:01:00 3: waitTime------------>0
2013.04.10 22:01:00 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.10 22:01:00 3: waitTime------------>120
2013.04.10 22:01:00 3: Puffergroesse: 0
2013.04.10 22:18:21 2: CUL_0: unknown message LOVF
2013.04.10 22:22:30 2: CUL_0: unknown message LOVF
2013.04.10 22:22:30 2: CUL_0: unknown message LOVF
2013.04.10 22:22:31 2: CUL_0: unknown message LOVF
ist das Protokoll vollständig?
zwischen 22:01 und 22:18 ist nichts passiert dann die LOVF.
HC ist jedenfalls nicht beteiligt, sonst würden wir passende Einträge im Log finden.
Gegen 22:01 Uhr hattest Du jedenfall noch ein credit in Höhe von 255
2013.04.10 22:01:00 3: credit10ms------------>255
Sehr merkwürdig. Die LOVF kommen ab 22:18 alle zwei Minunten - dann ist eine Lücke von ca. 15 Minuten.
Was verbraucht bei dir ab 22:15 Uhr die credits???
Bau mal bei Gelegenheit(morgen Abend) folgenden Befehl wieder ein:
define yy at +*00:01:00 get CUL_0 raw T02;; get CUL_0 raw X
Die Pufferung der FHT-Befehle hat jedenfalls funktioniert.
in fhem.cfg?
Habe es per Commandozeile wieder eingegeben...
Berichte nach den nächsten LOVFs...
Das Protokoll wird dadurch recht groß werden.
Ich hoffe, es ist ok, wenn ich das Protokoll hier poste. Vielleicht hilft es ja.
2013.04.11 03:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 622
2013.04.11 03:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 682
2013.04.11 03:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 661
2013.04.11 03:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 681
2013.04.11 03:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 709
2013.04.11 03:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 581
2013.04.11 03:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 641
2013.04.11 03:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 619
2013.04.11 03:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 631
2013.04.11 03:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 691
2013.04.11 03:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 751
2013.04.11 03:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 745
2013.04.11 03:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 764
2013.04.11 03:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 784
2013.04.11 03:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 779
2013.04.11 03:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 691
2013.04.11 03:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 751
2013.04.11 03:55:54 2: CUL_0: unknown message F40
2013.04.11 03:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 681
2013.04.11 03:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 708
2013.04.11 03:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 727
2013.04.11 03:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 722
2013.04.11 04:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 636
2013.04.11 04:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 680
2013.04.11 04:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 578
2013.04.11 04:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 573
2013.04.11 04:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 633
2013.04.11 04:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 693
2013.04.11 04:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 576
2013.04.11 04:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 636
2013.04.11 04:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 622
2013.04.11 04:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 666
2013.04.11 04:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 694
2013.04.11 04:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 688
2013.04.11 04:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 723
2013.04.11 04:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 733
2013.04.11 04:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 736
2013.04.11 04:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 732
2013.04.11 04:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 759
2013.04.11 04:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 723
2013.04.11 04:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 783
2013.04.11 04:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 778
2013.04.11 04:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 781
2013.04.11 04:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 776
2013.04.11 04:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 755
2013.04.11 04:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 727
2013.04.11 04:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 770
2013.04.11 04:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 765
2013.04.11 04:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 791
2013.04.11 04:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 770
2013.04.11 04:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 772
2013.04.11 04:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 832
2013.04.11 04:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 892
2013.04.11 04:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 04:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 857
2013.04.11 04:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 892
2013.04.11 04:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 845
2013.04.11 04:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 855
2013.04.11 04:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 881
2013.04.11 04:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 859
2013.04.11 04:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 04:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 793
2013.04.11 04:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 837
2013.04.11 04:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 775
2013.04.11 04:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 818
2013.04.11 04:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 707
2013.04.11 04:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 743
2013.04.11 04:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 762
2013.04.11 04:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 789
2013.04.11 04:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 776
2013.04.11 04:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 836
2013.04.11 04:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 872
2013.04.11 04:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 827
2013.04.11 04:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 805
2013.04.11 04:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 865
2013.04.11 04:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 04:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 846
2013.04.11 04:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 800
2013.04.11 04:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 796
2013.04.11 04:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 792
2013.04.11 04:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 835
2013.04.11 04:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 846
2013.04.11 05:00:00 3: necessaryCredit------------>150
2013.04.11 05:00:00 3: key------------>1:1365649200.02382:4
2013.04.11 05:00:00 3: name------------>eg_ku_Heizung: desired-temp 22.0
2013.04.11 05:00:00 3: buffer------------>N/A
2013.04.11 05:00:00 3: credit10ms------------>832
2013.04.11 05:00:00 3: waitTime------------>0
2013.04.11 05:00:00 2: FHT set eg_ku_Heizung desired-temp 22.0
2013.04.11 05:00:00 3: waitTime------------>120
2013.04.11 05:00:00 3: Puffergroesse: 0
2013.04.11 05:00:00 3: necessaryCredit------------>150
2013.04.11 05:00:00 3: key------------>1:1365649200.21549:5
2013.04.11 05:00:00 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.11 05:00:00 3: buffer------------>1A04:412C
2013.04.11 05:00:00 3: Puffergroesse: 1
2013.04.11 05:00:00 3: SOFTBUFFERTIMER------------>30
2013.04.11 05:00:08 3: CUL_0 raw => 1A04:412C
CUL_0 raw => 21 841
2013.04.11 05:00:30 3: necessaryCredit------------>150
2013.04.11 05:00:30 3: key------------>1:1365649200.21549:5
2013.04.11 05:00:30 3: name------------>eg_bz_Heizung: desired-temp 23.0
2013.04.11 05:00:30 3: buffer------------>N/A
2013.04.11 05:00:30 3: credit10ms------------>756
2013.04.11 05:00:30 3: waitTime------------>0
2013.04.11 05:00:30 2: FHT set eg_bz_Heizung desired-temp 23.0
2013.04.11 05:00:30 3: waitTime------------>120
2013.04.11 05:00:30 3: Puffergroesse: 0
2013.04.11 05:01:08 3: CUL_0 raw => 3157:412E
CUL_0 raw => 21 706
2013.04.11 05:02:08 3: CUL_0 raw => 3157:412E
CUL_0 raw => 21 742
2013.04.11 05:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 688
2013.04.11 05:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 691
2013.04.11 05:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 702
2013.04.11 05:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 622
2013.04.11 05:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 585
2013.04.11 05:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 496
2013.04.11 05:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 450
2013.04.11 05:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 510
2013.04.11 05:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 521
2013.04.11 05:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 556
2013.04.11 05:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 583
2013.04.11 05:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 643
2013.04.11 05:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 703
2013.04.11 05:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 657
2013.04.11 05:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 626
2013.04.11 05:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 581
2013.04.11 05:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 641
2013.04.11 05:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 636
2013.04.11 05:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 696
2013.04.11 05:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 585
2013.04.11 05:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 645
2013.04.11 05:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 607
2013.04.11 05:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 578
2013.04.11 05:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 574
2013.04.11 05:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 534
2013.04.11 05:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 529
2013.04.11 05:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 589
2013.04.11 05:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 649
2013.04.11 05:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 677
2013.04.11 05:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 721
2013.04.11 05:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 781
2013.04.11 05:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 825
2013.04.11 05:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 853
2013.04.11 05:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 839
2013.04.11 05:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 835
2013.04.11 05:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 764
2013.04.11 05:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 727
2013.04.11 05:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 721
2013.04.11 05:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 668
2013.04.11 05:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 679
2013.04.11 05:43:09 3: CUL_0 raw => N/A
CUL_0 raw => 21 674
2013.04.11 05:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 661
2013.04.11 05:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 656
2013.04.11 05:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 700
2013.04.11 05:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 663
2013.04.11 05:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 649
2013.04.11 05:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 643
2013.04.11 05:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 703
2013.04.11 05:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 747
2013.04.11 05:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 807
2013.04.11 05:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 811
2013.04.11 05:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 741
2013.04.11 05:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 735
2013.04.11 05:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 755
2013.04.11 05:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 733
2013.04.11 05:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 736
2013.04.11 05:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 731
2013.04.11 06:00:11 3: CUL_0 raw => N/A
CUL_0 raw => 21 670
2013.04.11 06:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 597
2013.04.11 06:02:08 3: CUL_0 raw => N/AT156000A65EEB
CUL_0 raw => 21 575
2013.04.11 06:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 635
2013.04.11 06:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 695
2013.04.11 06:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 698
2013.04.11 06:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 643
2013.04.11 06:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 630
2013.04.11 06:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 648
2013.04.11 06:08:10 3: FS20 set eg_ku_JalousieRechts on
2013.04.11 06:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 558
2013.04.11 06:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 562
2013.04.11 06:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 574
2013.04.11 06:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 617
2013.04.11 06:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 555
2013.04.11 06:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 615
2013.04.11 06:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 675
2013.04.11 06:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 628
2013.04.11 06:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 616
2013.04.11 06:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 569
2013.04.11 06:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 629
2013.04.11 06:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 673
2013.04.11 06:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 733
2013.04.11 06:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 662
2013.04.11 06:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 682
2013.04.11 06:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 678
2013.04.11 06:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 690
2013.04.11 06:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 586
2013.04.11 06:26:10 3: FS20 set eg_ku_JalousieLinks on
2013.04.11 06:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 561
2013.04.11 06:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 540
2013.04.11 06:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 486
2013.04.11 06:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 546
2013.04.11 06:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 590
2013.04.11 06:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 551
2013.04.11 06:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 504
2013.04.11 06:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 564
2013.04.11 06:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 591
2013.04.11 06:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 603
2013.04.11 06:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 597
2013.04.11 06:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 477
2013.04.11 06:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 488
2013.04.11 06:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 500
2013.04.11 06:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 501
2013.04.11 06:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 415
2013.04.11 06:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 345
2013.04.11 06:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 372
2013.04.11 06:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 432
2013.04.11 06:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 361
2013.04.11 06:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 372
2013.04.11 06:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 416
2013.04.11 06:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 476
2013.04.11 06:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 496
2013.04.11 06:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 475
2013.04.11 06:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 495
2013.04.11 06:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 490
2013.04.11 06:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 478
2013.04.11 06:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 538
2013.04.11 06:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 436
2013.04.11 06:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 479
2013.04.11 06:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 523
2013.04.11 06:58:46 3: FS20 set k_WW_Zirkulationspumpe on
2013.04.11 06:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 496
2013.04.11 07:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 361
2013.04.11 07:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 421
2013.04.11 07:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 407
2013.04.11 07:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 467
2013.04.11 07:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 487
2013.04.11 07:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 467
2013.04.11 07:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 404
2013.04.11 07:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 416
2013.04.11 07:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 307
2013.04.11 07:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 286
2013.04.11 07:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 346
2013.04.11 07:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 325
2013.04.11 07:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 369
2013.04.11 07:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 388
2013.04.11 07:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 448
2013.04.11 07:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 426
2013.04.11 07:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 404
2013.04.11 07:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 382
2013.04.11 07:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 442
2013.04.11 07:18:46 3: FS20 set k_WW_Zirkulationspumpe off
2013.04.11 07:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 456
2013.04.11 07:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 450
2013.04.11 07:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 364
2013.04.11 07:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 333
2013.04.11 07:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 377
2013.04.11 07:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 437
2013.04.11 07:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 367
2013.04.11 07:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 379
2013.04.11 07:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 349
2013.04.11 07:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 376
2013.04.11 07:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 337
2013.04.11 07:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 397
2013.04.11 07:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 441
2013.04.11 07:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 501
2013.04.11 07:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 496
2013.04.11 07:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 491
2013.04.11 07:35:01 3: FS20 set k_WW_Zirkulationspumpe on
2013.04.11 07:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 498
2013.04.11 07:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 493
2013.04.11 07:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 487
2013.04.11 07:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 515
2013.04.11 07:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 452
2013.04.11 07:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 422
2013.04.11 07:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 343
2013.04.11 07:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 403
2013.04.11 07:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 389
2013.04.11 07:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 359
2013.04.11 07:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 419
2013.04.11 07:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 414
2013.04.11 07:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 408
2013.04.11 07:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 403
2013.04.11 07:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 463
2013.04.11 07:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 459
2013.04.11 07:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 495
2013.04.11 07:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 457
2013.04.11 07:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 509
2013.04.11 07:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 431
2013.04.11 07:55:01 3: FS20 set k_WW_Zirkulationspumpe off
2013.04.11 07:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 346
2013.04.11 07:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 300
2013.04.11 07:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 262
2013.04.11 07:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 322
2013.04.11 07:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 317
2013.04.11 08:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 288
2013.04.11 08:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 300
2013.04.11 08:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 213
2013.04.11 08:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 249
2013.04.11 08:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 284
2013.04.11 08:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 278
2013.04.11 08:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 183
2013.04.11 08:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 194
2013.04.11 08:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 164
2013.04.11 08:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 77
2013.04.11 08:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 31
2013.04.11 08:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 59
2013.04.11 08:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 119
2013.04.11 08:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 106
2013.04.11 08:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 149
2013.04.11 08:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 144
2013.04.11 08:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 171
2013.04.11 08:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 167
2013.04.11 08:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 211
2013.04.11 08:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 230
2013.04.11 08:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 265
2013.04.11 08:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 235
2013.04.11 08:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 157
2013.04.11 08:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 185
2013.04.11 08:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 188
2013.04.11 08:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 117
2013.04.11 08:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 103
2013.04.11 08:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 34
2013.04.11 08:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 94
2013.04.11 08:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 97
2013.04.11 08:30:00 3: necessaryCredit------------>150
2013.04.11 08:30:00 3: key------------>1:1365661800.09996:6
2013.04.11 08:30:00 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.11 08:30:00 3: buffer------------>N/A
2013.04.11 08:30:00 3: credit10ms------------>148
2013.04.11 08:30:00 2: FHT_CUL_SendQueueHandler: Not enough credit! credit10ms is 148, but we need 150. Waiting 7 seconds.
2013.04.11 08:30:00 3: waitTime------------>7
2013.04.11 08:30:00 3: Puffergroesse: 1
2013.04.11 08:30:00 3: SOFTBUFFERTIMER------------>7
2013.04.11 08:30:00 3: necessaryCredit------------>150
2013.04.11 08:30:00 3: key------------>1:1365661800.28178:7
2013.04.11 08:30:00 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:30:00 3: key------------>1:1365661800.09996:6
2013.04.11 08:30:00 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.11 08:30:00 3: buffer------------>N/A
2013.04.11 08:30:00 3: credit10ms------------>149
2013.04.11 08:30:00 2: FHT_CUL_SendQueueHandler: Not enough credit! credit10ms is 149, but we need 150. Waiting 6 seconds.
2013.04.11 08:30:00 3: waitTime------------>6
2013.04.11 08:30:00 3: Puffergroesse: 2
2013.04.11 08:30:07 3: necessaryCredit------------>150
2013.04.11 08:30:07 3: key------------>1:1365661800.28178:7
2013.04.11 08:30:07 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:30:07 3: key------------>1:1365661800.09996:6
2013.04.11 08:30:07 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.11 08:30:07 3: buffer------------>N/A
2013.04.11 08:30:07 3: credit10ms------------>155
2013.04.11 08:30:07 3: waitTime------------>0
2013.04.11 08:30:07 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.11 08:30:07 3: waitTime------------>120
2013.04.11 08:30:07 3: Puffergroesse: 1
2013.04.11 08:30:07 3: SOFTBUFFERTIMER------------>120
2013.04.11 08:30:08 3: CUL_0 raw => 3157:4124
CUL_0 raw => 21 157
2013.04.11 08:31:08 3: CUL_0 raw => 3157:4124
CUL_0 raw => 21 134
2013.04.11 08:32:07 3: necessaryCredit------------>150
2013.04.11 08:32:07 3: key------------>1:1365661800.28178:7
2013.04.11 08:32:07 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:32:07 3: buffer------------>3157:4124
2013.04.11 08:32:07 3: Puffergroesse: 1
2013.04.11 08:32:07 3: SOFTBUFFERTIMER------------>30
2013.04.11 08:32:08 3: CUL_0 raw => 3157:4124
CUL_0 raw => 21 145
2013.04.11 08:32:37 3: necessaryCredit------------>150
2013.04.11 08:32:37 3: key------------>1:1365661800.28178:7
2013.04.11 08:32:37 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:32:37 3: buffer------------>3157:4124
2013.04.11 08:32:37 3: Puffergroesse: 1
2013.04.11 08:32:37 3: SOFTBUFFERTIMER------------>30
2013.04.11 08:33:07 3: necessaryCredit------------>150
2013.04.11 08:33:07 3: key------------>1:1365661800.28178:7
2013.04.11 08:33:07 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:33:07 3: buffer------------>3157:4124
2013.04.11 08:33:07 3: Puffergroesse: 1
2013.04.11 08:33:07 3: SOFTBUFFERTIMER------------>30
2013.04.11 08:33:08 3: CUL_0 raw => 3157:4124
CUL_0 raw => 21 205
2013.04.11 08:33:37 3: necessaryCredit------------>150
2013.04.11 08:33:37 3: key------------>1:1365661800.28178:7
2013.04.11 08:33:37 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:33:37 3: buffer------------>3157:4124
2013.04.11 08:33:37 3: Puffergroesse: 1
2013.04.11 08:33:37 3: SOFTBUFFERTIMER------------>30
2013.04.11 08:34:07 3: necessaryCredit------------>150
2013.04.11 08:34:07 3: key------------>1:1365661800.28178:7
2013.04.11 08:34:07 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:34:07 3: buffer------------>N/A
2013.04.11 08:34:07 3: credit10ms------------>149
2013.04.11 08:34:07 2: FHT_CUL_SendQueueHandler: Not enough credit! credit10ms is 149, but we need 150. Waiting 6 seconds.
2013.04.11 08:34:07 3: waitTime------------>6
2013.04.11 08:34:07 3: Puffergroesse: 1
2013.04.11 08:34:07 3: SOFTBUFFERTIMER------------>6
2013.04.11 08:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 151
2013.04.11 08:34:13 3: necessaryCredit------------>150
2013.04.11 08:34:13 3: key------------>1:1365661800.28178:7
2013.04.11 08:34:13 3: name------------>eg_ku_Heizung: desired-temp 15.0
2013.04.11 08:34:13 3: buffer------------>N/A
2013.04.11 08:34:13 3: credit10ms------------>155
2013.04.11 08:34:13 3: waitTime------------>0
2013.04.11 08:34:13 2: FHT set eg_ku_Heizung desired-temp 15.0
2013.04.11 08:34:13 3: waitTime------------>120
2013.04.11 08:34:13 3: Puffergroesse: 0
2013.04.11 08:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 171
2013.04.11 08:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 167
2013.04.11 08:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 179
2013.04.11 08:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 132
2013.04.11 08:38:40 2: CUL_0: unknown message LOVF
2013.04.11 08:38:40 2: CUL_0: unknown message LOVF
2013.04.11 08:38:40 2: CUL_0: unknown message LOVF
2013.04.11 08:38:41 2: CUL_0: unknown message LOVF
2013.04.11 08:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 29
2013.04.11 08:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 89
2013.04.11 08:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 44
2013.04.11 08:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 63
2013.04.11 08:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 107
2013.04.11 08:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 78
2013.04.11 08:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 138
2013.04.11 08:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 100
2013.04.11 08:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 128
2013.04.11 08:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 188
2013.04.11 08:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 183
2013.04.11 08:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 226
2013.04.11 08:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 286
2013.04.11 08:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 330
2013.04.11 08:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 390
2013.04.11 08:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 393
2013.04.11 08:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 289
2013.04.11 08:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 243
2013.04.11 08:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 255
2013.04.11 08:58:09 3: CUL_0 raw => N/A
CUL_0 raw => 21 307
2013.04.11 08:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 292
2013.04.11 09:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 269
2013.04.11 09:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 133
2013.04.11 09:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 193
2013.04.11 09:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 253
2013.04.11 09:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 313
2013.04.11 09:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 373
2013.04.11 09:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 157
2013.04.11 09:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 185
2013.04.11 09:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 229
2013.04.11 09:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 249
2013.04.11 09:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 276
2013.04.11 09:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 239
2013.04.11 09:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 179
2013.04.11 09:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 239
2013.04.11 09:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 299
2013.04.11 09:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 293
2013.04.11 09:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 305
2013.04.11 09:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 316
2013.04.11 09:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 294
2013.04.11 09:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 354
2013.04.11 09:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 414
2013.04.11 09:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 408
2013.04.11 09:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 402
2013.04.11 09:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 339
2013.04.11 09:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 334
2013.04.11 09:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 370
2013.04.11 09:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 332
2013.04.11 09:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 328
2013.04.11 09:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 314
2013.04.11 09:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 284
2013.04.11 09:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 344
2013.04.11 09:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 380
2013.04.11 09:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 424
2013.04.11 09:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 468
2013.04.11 09:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 528
2013.04.11 09:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 538
2013.04.11 09:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 565
2013.04.11 09:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 569
2013.04.11 09:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 604
2013.04.11 09:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 526
2013.04.11 09:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 562
2013.04.11 09:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 474
2013.04.11 09:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 451
2013.04.11 09:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 511
2013.04.11 09:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 530
2013.04.11 09:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 590
2013.04.11 09:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 536
2013.04.11 09:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 516
2013.04.11 09:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 576
2013.04.11 09:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 636
2013.04.11 09:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 696
2013.04.11 09:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 715
2013.04.11 09:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 653
2013.04.11 09:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 713
2013.04.11 09:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 690
2013.04.11 09:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 685
2013.04.11 09:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 613
2013.04.11 09:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 624
2013.04.11 09:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 667
2013.04.11 09:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 620
2013.04.11 10:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 591
2013.04.11 10:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 538
2013.04.11 10:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 598
2013.04.11 10:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 642
2013.04.11 10:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 637
2013.04.11 10:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 697
2013.04.11 10:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 568
2013.04.11 10:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 595
2013.04.11 10:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 573
2013.04.11 10:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 542
2013.04.11 10:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 537
2013.04.11 10:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 427
2013.04.11 10:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 487
2013.04.11 10:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 515
2013.04.11 10:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 575
2013.04.11 10:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 571
2013.04.11 10:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 524
2013.04.11 10:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 534
2013.04.11 10:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 594
2013.04.11 10:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 549
2013.04.11 10:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 609
2013.04.11 10:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 571
2013.04.11 10:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 458
2013.04.11 10:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 502
2013.04.11 10:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 546
2013.04.11 10:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 500
2013.04.11 10:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 478
2013.04.11 10:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 449
2013.04.11 10:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 444
2013.04.11 10:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 414
2013.04.11 10:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 458
2013.04.11 10:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 518
2013.04.11 10:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 546
2013.04.11 10:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 542
2013.04.11 10:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 602
2013.04.11 10:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 630
2013.04.11 10:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 642
2013.04.11 10:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 638
2013.04.11 10:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 549
2013.04.11 10:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 446
2013.04.11 10:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 441
2013.04.11 10:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 419
2013.04.11 10:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 479
2013.04.11 10:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 474
2013.04.11 10:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 501
2013.04.11 10:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 496
2013.04.11 10:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 499
2013.04.11 10:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 495
2013.04.11 10:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 489
2013.04.11 10:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 550
2013.04.11 10:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 586
2013.04.11 10:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 606
2013.04.11 10:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 626
2013.04.11 10:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 621
2013.04.11 10:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 517
2013.04.11 10:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 511
2013.04.11 10:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 522
2013.04.11 10:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 501
2013.04.11 10:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 496
2013.04.11 10:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 458
2013.04.11 11:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 485
2013.04.11 11:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 480
2013.04.11 11:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 474
2013.04.11 11:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 534
2013.04.11 11:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 594
2013.04.11 11:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 589
2013.04.11 11:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 543
2013.04.11 11:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 505
2013.04.11 11:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 565
2013.04.11 11:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 495
2013.04.11 11:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 555
2013.04.11 11:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 558
2013.04.11 11:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 602
2013.04.11 11:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 630
2013.04.11 11:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 690
2013.04.11 11:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 734
2013.04.11 11:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 705
2013.04.11 11:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 692
2013.04.11 11:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 752
2013.04.11 11:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 763
2013.04.11 11:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 823
2013.04.11 11:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 776
2013.04.11 11:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 665
2013.04.11 11:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 725
2013.04.11 11:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 736
2013.04.11 11:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 707
2013.04.11 11:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 693
2013.04.11 11:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 704
2013.04.11 11:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 681
2013.04.11 11:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 741
2013.04.11 11:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 736
2013.04.11 11:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 796
2013.04.11 11:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 840
2013.04.11 11:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 11:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 861
2013.04.11 11:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 11:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 846
2013.04.11 11:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 873
2013.04.11 11:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 835
2013.04.11 11:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 847
2013.04.11 11:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 792
2013.04.11 11:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 804
2013.04.11 11:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 757
2013.04.11 11:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 753
2013.04.11 11:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 747
2013.04.11 11:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 807
2013.04.11 11:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 801
2013.04.11 11:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 844
2013.04.11 11:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 888
2013.04.11 11:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 871
2013.04.11 11:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 11:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 828
2013.04.11 11:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 839
2013.04.11 11:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 899
2013.04.11 11:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 818
2013.04.11 11:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 878
2013.04.11 11:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 824
2013.04.11 11:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 826
2013.04.11 11:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 828
2013.04.11 11:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 839
2013.04.11 12:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 793
2013.04.11 12:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 714
2013.04.11 12:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 757
2013.04.11 12:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 792
2013.04.11 12:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 852
2013.04.11 12:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 867
2013.04.11 12:06:47 2: CUL_0: unknown message F40
2013.04.11 12:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 814
2013.04.11 12:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 874
2013.04.11 12:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 821
2013.04.11 12:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 832
2013.04.11 12:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 827
2013.04.11 12:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 871
2013.04.11 12:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 888
2013.04.11 12:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 874
2013.04.11 12:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 820
2013.04.11 12:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 815
2013.04.11 12:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 875
2013.04.11 12:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 874
2013.04.11 12:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 851
2013.04.11 12:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 837
2013.04.11 12:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 897
2013.04.11 12:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 837
2013.04.11 12:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 864
2013.04.11 12:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 809
2013.04.11 12:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 804
2013.04.11 12:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 823
2013.04.11 12:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 842
2013.04.11 12:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 822
2013.04.11 12:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 882
2013.04.11 12:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 831
2013.04.11 12:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 858
2013.04.11 12:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 853
2013.04.11 12:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 840
2013.04.11 12:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 785
2013.04.11 12:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 845
2013.04.11 12:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 849
2013.04.11 12:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 840
2013.04.11 12:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 851
2013.04.11 12:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 887
2013.04.11 12:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 810
2013.04.11 12:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 837
2013.04.11 12:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 857
2013.04.11 12:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 839
2013.04.11 12:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 899
2013.04.11 12:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 892
2013.04.11 12:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 12:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 767
2013.04.11 12:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 827
2013.04.11 12:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 815
2013.04.11 12:57:09 3: CUL_0 raw => N/A
CUL_0 raw => 21 775
2013.04.11 12:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 770
2013.04.11 12:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 798
2013.04.11 13:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 793
2013.04.11 13:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 796
2013.04.11 13:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 775
2013.04.11 13:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 835
2013.04.11 13:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 879
2013.04.11 13:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 13:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 862
2013.04.11 13:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 840
2013.04.11 13:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 747
2013.04.11 13:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 742
2013.04.11 13:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 632
2013.04.11 13:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 627
2013.04.11 13:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 671
2013.04.11 13:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 731
2013.04.11 13:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 791
2013.04.11 13:15:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 818
2013.04.11 13:16:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 813
2013.04.11 13:17:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 757
2013.04.11 13:18:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 752
2013.04.11 13:19:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 812
2013.04.11 13:20:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 872
2013.04.11 13:21:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 832
2013.04.11 13:22:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 803
2013.04.11 13:23:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 822
2013.04.11 13:24:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 752
2013.04.11 13:25:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 764
2013.04.11 13:26:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 726
2013.04.11 13:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 688
2013.04.11 13:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 682
2013.04.11 13:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 700
2013.04.11 13:30:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 760
2013.04.11 13:31:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 763
2013.04.11 13:32:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 823
2013.04.11 13:33:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 851
2013.04.11 13:34:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 13:35:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 874
2013.04.11 13:36:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 885
2013.04.11 13:37:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 880
2013.04.11 13:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 856
2013.04.11 13:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 875
2013.04.11 13:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 13:41:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 676
2013.04.11 13:42:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 736
2013.04.11 13:43:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 796
2013.04.11 13:44:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 724
2013.04.11 13:45:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 784
2013.04.11 13:46:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 796
2013.04.11 13:47:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 791
2013.04.11 13:48:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 851
2013.04.11 13:49:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 13:50:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 854
2013.04.11 13:51:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 13:52:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 900
2013.04.11 13:53:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 842
2013.04.11 13:54:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 837
2013.04.11 13:55:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 864
2013.04.11 13:56:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 810
2013.04.11 13:57:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 804
2013.04.11 13:58:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 799
2013.04.11 13:59:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 696
2013.04.11 14:00:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 740
2013.04.11 14:01:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 783
2013.04.11 14:02:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 762
2013.04.11 14:03:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 822
2013.04.11 14:04:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 752
2013.04.11 14:05:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 812
2013.04.11 14:06:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 758
2013.04.11 14:07:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 734
2013.04.11 14:08:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 754
2013.04.11 14:09:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 684
2013.04.11 14:10:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 704
2013.04.11 14:11:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 681
2013.04.11 14:12:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 741
2013.04.11 14:13:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 776
2013.04.11 14:14:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 836
Das Seltsame in Deinem Log ist, dass der Credit manchmal sinkt, obwohl (laut Log) überhaupt keine Befehle gesendet werden. Was macht(e) Deine Steuerung Deines Wissens nach denn z.B. "2013.04.11 08:20:08"? Hier sinkt der Credit, also wurde irgendetwas gesendet...
Hmm, ich weiß es nicht genau.
Meine Ideen:
1.) Ein FHT-Regler piept seit ein paar Tagen (Batterie).
2.) Ich habe 3 FS S300TH im Einsatz. Die sollen ja ähnlich wie die FHTs zu Funkproblemen führen.
3.) Also ich habe im Forum mal eine Art "Wecker" gefunden.
Den habe ich jetzt mal ausgebaut, da ich ihn nicht nutze:
# Wecker
# Weckzeit
#define Weckzeit dummy
#attr Weckzeit alias Stelle Weckzeit
#attr Weckzeit group Uhr wecken
#attr Weckzeit room Wecker
#attr Weckzeit setList #state:02:00:00,02:15:00,02:30:00,02:45:00,03:00:00,03:15:00,03:30:00,03:45:00,04:00:00,04:15:00,04:30:00,04:45:00,05:00:00,05:15:00,05:30:00,05:45:00,06:00:00,06:15:00,06:30:00,06:45:00,07:00:00,07:15.00,07:30:00,07:45:00,08:00:00,13:24:00
#attr Weckzeit webCmd state
#define Weckzimmer dummy
#attr Weckzimmer alias Stelle Weckzimmer
#attr Weckzimmer group Uhr wecken
#attr Weckzimmer room Wecker
#attr Weckzimmer setList state:eg_bz_Heizung,eg_ku_Heizung
#attr Weckzimmer webCmd state
#define Wecktemp dummy
#attr Wecktemp alias Stelle Temperatur
#attr Wecktemp group Uhr wecken
#attr Wecktemp room Wecker
#attr Wecktemp setList #state:15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0
#attr Wecktemp webCmd state
#define HeizWecker notify Weckzeit {\
#my $Weckz1 = ReadingsVal("Weckzeit", "state", undef);;\
#my $Weckzi1 = ReadingsVal("Weckzimmer", "state", undef);;\
#my $Wecktemp1 = ReadingsVal("Wecktemp", "state", undef);;\
#fhem ("define haus_heizungswecker at $Weckz1 set $Weckzi1 desired-temp $Wecktemp1");;\
Log 3 ,"eingestellte Weckzeit: $Weckz1 Zimmer: $Weckzi1 Temperatur: $Wecktemp1";;\
}
zwischen 8 und 9 Uhr hast du richtig viel Traffic wobei unklar ist wodurch er zustande kommt.
Befehle ans FHT sind es jedenfalls nicht.
Hier wird es eng - die Steuerung, die ich eingebaut habe funktioniert jedenfalls.
siehe Meldung: "2013.04.11 08:30:00 2: FHT_CUL_SendQueueHandler: Not enough credit! credit10ms is 148, but we need 150. Waiting 7 seconds."
CUL_0 raw => 21 103
2013.04.11 08:27:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 34
2013.04.11 08:28:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 94
2013.04.11 08:29:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 97
2013.04.11 08:30:00 3: necessaryCredit------------>150
2013.04.11 08:30:00 3: key------------>1:1365661800.09996:6
2013.04.11 08:30:00 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.11 08:30:00 3: buffer------------>N/A
2013.04.11 08:30:00 3: credit10ms------------>148
2013.04.11 08:30:00 2: FHT_CUL_SendQueueHandler: Not enough credit! credit10ms is 148, but we need 150. Waiting 7 seconds.
bzw. ... und dann sogar mit LOVF, die nicht durch FHT verursacht werden. Eventuell ist es incoming traffic:
CUL_0 raw => 21 179
2013.04.11 08:38:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 132
2013.04.11 08:38:40 2: CUL_0: unknown message LOVF
2013.04.11 08:38:40 2: CUL_0: unknown message LOVF
2013.04.11 08:38:40 2: CUL_0: unknown message LOVF
2013.04.11 08:38:41 2: CUL_0: unknown message LOVF
2013.04.11 08:39:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 29
2013.04.11 08:40:08 3: CUL_0 raw => N/A
CUL_0 raw => 21 89
Ich versuche mal herauszubekommen ob man den Verkehr des CUL Log bekommen kann.
Wenn ich etwas habe melde ich mich.
ZitatMeine Ideen:
1.) Ein FHT-Regler piept seit ein paar Tagen (Batterie).
könnte bei Empfangsproblemen zu Wiederholungen und LOVF führen!
Setze man den loglevel des cul_0 auf 3 dann bekommst du den native traffic ins Log geschrieben:
Sieht dann etwa so aus:
2013.04.11 19:42:00 3: CUL_0: T4C6000A600 -61.5
2013.04.11 19:41:32 3: CUL_0: T093841692B -38.5
2013.04.11 19:41:31 3: CUL_0: T093800A616 -38
2013.04.11 19:40:05 3: CUL_0: T4C6000A600 -61
2013.04.11 19:39:50 2: FHT set HeizungWohnen desired-temp 21.5
2013.04.11 19:39:50 3: SW: T0938412b
2013.04.11 19:39:50 3: SW: X
2013.04.11 19:39:50 3: SW: T02
2013.04.11 19:39:36 3: CUL_0: T093800A616 -38
2013.04.11 19:38:54 3: SW: Fe4e41100
2013.04.11 19:38:54 2: FS20 set Zirkulation off
2013.04.11 19:38:51 3: SW: Fe4e41111
Wenn dann LOVF kommen, müssen wir prüfen was den credit vorher heruntergezogen hat.
Prüf mal die RSSI-Werte deiner FHT:
(siehe Anhang / see attachement)
Bei Werten unter -85 soll es eng werden.
Der Wert steht für die Empfangsqualität - vermutlich in db.
> Der Wert steht für die Empfangsqualität - vermutlich in db.
Nein, es steht fuer die Signalstaerke (Received Signal Strength Idicator) in dB.
Starke Signale koennen zwar haeufig besser empfangen werden, aber nicht immer.
Vgl. "normale" Lautstaerke in einem stillen Raum vs. Disco.
Zitat von: Dietmar63 schrieb am Do, 11 April 2013 19:45Setze man den loglevel des cul_0 auf 3 dann bekommst du den native traffic ins Log geschrieben:
...
Wenn dann LOVF kommen, müssen wir prüfen was den credit vorher heruntergezogen hat.
Wie mache ich das? (loglevel auf 3 setzen)
Muss ich sonst noch etwas aktivieren?
attr CUL_0 loglevel 3
im Eingabefeld eingeben
oder in der Oberfläche fhem->unsorted->CUL_0
In der Detailansicht des CUL_0 unten hinter attr loglevel auswählen und im Feld dahinter 3 auswählen dann attr clicken.
Zitat von: Dietmar63 schrieb am Do, 11 April 2013 19:59Prüf mal die RSSI-Werte deiner FHT:
(siehe Anhang / see attachement)
Bei Werten unter -85 soll es eng werden.
Der Wert steht für die Empfangsqualität - vermutlich in db.
Hier die Werte der FHTs (Sind teilweise recht weit enfernt vom Cul.)
CUL_0_RSSI -89.5
CUL_0_RSSI -81
CUL_0_RSSI -84.5
CUL_0_RSSI -76.5
CUL_0_RSSI -86
CUL_0_RSSI -74
CUL_0_RSSI -61.5
CUL_0_RSSI -81
CUL_0_RSSI -56
-89 ist ziemlich schlecht:
http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT#Funklage_beobachten (//www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT#Funklage_beobachten)
so hier mal detaillierter:
2013.04.12 22:00:00 3: necessaryCredit------------>150
2013.04.12 22:00:00 3: key------------>1:1365796800.0191:4
2013.04.12 22:00:00 3: name------------>eg_bz_Heizung: desired-temp 18.0
2013.04.12 22:00:00 3: buffer------------>N/A
2013.04.12 22:00:00 3: credit10ms------------>460
2013.04.12 22:00:00 3: waitTime------------>0
2013.04.12 22:00:00 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.12 22:00:00 3: waitTime------------>120
2013.04.12 22:00:00 3: Puffergroesse: 0
2013.04.12 22:00:00 3: FS20 set eg_ku_JalousieLinks off
2013.04.12 22:01:00 3: FS20 set eg_ku_JalousieRechts off
2013.04.12 22:35:26 3: CUL_0: T0A0A00A6C1 -91
2013.04.12 22:35:35 3: CUL_0: T105700A600 -86.5
2013.04.12 22:35:45 3: CUL_0: T8CD71A02 -77.5
2013.04.12 22:35:45 3: CUL_0: T8CD71A82 -77
2013.04.12 22:35:50 3: CUL_0: T245400A600 -78
2013.04.12 22:36:01 3: CUL_0: T0C2200A600 -75
2013.04.12 22:36:15 3: CUL_0: T1A0400A600 -81
2013.04.12 22:36:21 3: CUL_0: T1560002636 -84.5
2013.04.12 22:36:52 3: CUL_0: TA805F102 -73
2013.04.12 22:36:52 3: CUL_0: TA805F182 -74
2013.04.12 22:36:55 3: CUL_0: T315700A601 -78.5
2013.04.12 22:36:56 3: CUL_0: T163500A600 -61.5
2013.04.12 22:37:03 3: CUL_0: T6AB18F02 -80.5
2013.04.12 22:37:03 3: CUL_0: T6AB18F82 -80
2013.04.12 22:37:07 3: CUL_0: T41FCD302 -86.5
2013.04.12 22:37:07 3: CUL_0: T031100B600 -56
2013.04.12 22:37:08 3: CUL_0: T987CB182 -89.5
2013.04.12 22:37:22 3: CUL_0: T0A0A00A6C1 -91.5
2013.04.12 22:37:34 3: CUL_0: T105700A600 -86
2013.04.12 22:37:47 3: CUL_0: T245400A600 -77.5
2013.04.12 22:37:47 3: CUL_0: T24544269A2 -77.5
2013.04.12 22:37:47 3: CUL_0: T2454436900 -77.5
2013.04.12 22:37:57 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:38:12 3: CUL_0: T1A0400A600 -81
2013.04.12 22:38:16 3: CUL_0: T156000A636 -84.5
2013.04.12 22:38:41 3: CUL_0: TF8E8B802 -86.5
2013.04.12 22:38:42 3: CUL_0: TF8E8B882 -86
2013.04.12 22:38:51 3: CUL_0: K21994089 -69.5
2013.04.12 22:38:54 3: CUL_0: T315700A601 -78.5
2013.04.12 22:38:54 3: CUL_0: T163500A600 -61.5
2013.04.12 22:38:55 3: CUL_0: T16354269CB -61.5
2013.04.12 22:38:55 3: CUL_0: T1635436900 -61
2013.04.12 22:38:55 3: CUL_0: T1635446900 -61.5
2013.04.12 22:39:02 3: CUL_0: T031100B600 -56
2013.04.12 22:39:10 3: CUL_0: T711C9402 -76.5
2013.04.12 22:39:11 3: CUL_0: T711C9482 -77
2013.04.12 22:39:18 3: CUL_0: T0A0A00A6C1 -91.5
2013.04.12 22:39:35 3: CUL_0: T10574269A5 -86
2013.04.12 22:39:35 3: CUL_0: T1057436900 -86
2013.04.12 22:39:43 3: CUL_0: T245400A600 -77
2013.04.12 22:39:44 3: CUL_0: T2454446900 -77
2013.04.12 22:39:53 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:39:53 3: CUL_0: T0C224269A5 -74.5
2013.04.12 22:39:54 3: CUL_0: T0C22436900 -74.5
2013.04.12 22:39:57 3: CUL_0: T8CD71A02 -77.5
2013.04.12 22:39:57 3: CUL_0: T8CD71A82 -77
2013.04.12 22:40:09 3: CUL_0: T1A0400A600 -81
2013.04.12 22:40:11 3: CUL_0: T156000A636 -85
2013.04.12 22:40:51 3: CUL_0: T1635002608 -61.5
2013.04.12 22:40:52 3: CUL_0: T315700A601 -78.5
2013.04.12 22:40:53 3: CUL_0: T31574269C4 -78
2013.04.12 22:40:53 3: CUL_0: T3157436900 -78
2013.04.12 22:40:53 3: CUL_0: T3157446900 -78
2013.04.12 22:40:58 3: CUL_0: T031100B600 -56
2013.04.12 22:41:05 3: CUL_0: T6AB18F82 -80.5
2013.04.12 22:41:06 3: CUL_0: TA805F102 -72
2013.04.12 22:41:06 3: CUL_0: TA805F182 -71.5
2013.04.12 22:41:14 3: CUL_0: T0A0A00A6C1 -92
2013.04.12 22:41:17 3: CUL_0: T41FCD302 -86.5
2013.04.12 22:41:17 3: CUL_0: T41FCD382 -86.5
2013.04.12 22:41:21 3: CUL_0: T987CB102 -88.5
2013.04.12 22:41:22 3: CUL_0: T987CB182 -88.5
2013.04.12 22:41:31 3: CUL_0: T105700A600 -85.5
2013.04.12 22:41:40 3: CUL_0: T245400A600 -77
2013.04.12 22:41:49 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:42:06 3: CUL_0: T156000A636 -84.5
2013.04.12 22:42:06 3: CUL_0: T1A0400A600 -81
2013.04.12 22:42:29 3: CUL_0: K01184238 -50
2013.04.12 22:42:49 3: CUL_0: T163500A608 -61.5
2013.04.12 22:42:53 3: CUL_0: T031100B600 -56
2013.04.12 22:42:58 3: CUL_0: TF8E8B882 -87
2013.04.12 22:43:02 3: CUL_0: T03114269AE -56
2013.04.12 22:43:03 3: CUL_0: T0311436900 -56.5
2013.04.12 22:43:03 3: CUL_0: T0311446900 -56
2013.04.12 22:43:10 3: CUL_0: T0A0A00A6C1 -92.5
2013.04.12 22:43:18 3: CUL_0: T711C9402 -76.5
2013.04.12 22:43:19 3: CUL_0: T711C9482 -77
2013.04.12 22:43:29 3: CUL_0: T105700A600 -86.5
2013.04.12 22:43:30 3: CUL_0: T10574269A5 -87
2013.04.12 22:43:30 3: CUL_0: T1057436900 -86.5
2013.04.12 22:43:31 3: CUL_0: T1057446900 -86.5
2013.04.12 22:43:37 3: CUL_0: T245400A600 -77
2013.04.12 22:43:45 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:44:01 3: CUL_0: T156000A636 -84.5
2013.04.12 22:44:03 3: CUL_0: T1A0400A600 -81
2013.04.12 22:44:09 3: CUL_0: T8CD71A02 -77.5
2013.04.12 22:44:09 3: CUL_0: T8CD71A82 -77
2013.04.12 22:44:46 3: CUL_0: T163500A608 -61.5
2013.04.12 22:44:49 3: CUL_0: T031100B600 -56
2013.04.12 22:45:07 3: CUL_0: T0A0A0026D7 -92.5
2013.04.12 22:45:07 3: CUL_0: T6AB18F02 -81
2013.04.12 22:45:08 3: CUL_0: T0A0A4269D4 -92.5
2013.04.12 22:45:20 3: CUL_0: TA805F102 -72.5
2013.04.12 22:45:20 3: CUL_0: TA805F182 -72
2013.04.12 22:45:26 3: CUL_0: K01189237 -50
2013.04.12 22:45:27 3: CUL_0: T41FCD382 -86.5
2013.04.12 22:45:28 3: CUL_0: T105700A600 -86.5
2013.04.12 22:45:34 3: CUL_0: T245400A600 -77
2013.04.12 22:45:36 3: CUL_0: T987CB182 -88.5
2013.04.12 22:45:41 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:45:41 3: CUL_0: T0C224269A5 -74.5
2013.04.12 22:45:42 3: CUL_0: T0C22436900 -74.5
2013.04.12 22:45:42 3: CUL_0: T0C22446900 -74.5
2013.04.12 22:45:56 3: CUL_0: T156000A636 -85
2013.04.12 22:46:00 3: CUL_0: T1A0400A600 -81
2013.04.12 22:46:44 3: CUL_0: T163500A608 -61.5
2013.04.12 22:46:48 3: CUL_0: T315700A601 -78
2013.04.12 22:47:02 3: CUL_0: T0A0A00A6D7 -91.5
2013.04.12 22:47:13 3: CUL_0: TF8E8B802 -86.5
2013.04.12 22:47:26 3: CUL_0: T105700A600 -86.5
2013.04.12 22:47:26 3: CUL_0: T711C9402 -76.5
2013.04.12 22:47:27 3: CUL_0: T711C9482 -76.5
2013.04.12 22:47:31 3: CUL_0: T245400A600 -77
2013.04.12 22:47:37 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:47:51 3: CUL_0: T156000A636 -84
2013.04.12 22:47:57 3: CUL_0: T1A0400A600 -81
2013.04.12 22:48:21 3: CUL_0: T8CD71A02 -77.5
2013.04.12 22:48:21 3: CUL_0: T8CD71A82 -77.5
2013.04.12 22:48:23 3: CUL_0: K01189237 -50
2013.04.12 22:48:40 3: CUL_0: T031100B600 -56
2013.04.12 22:48:41 3: CUL_0: T163500A608 -61.5
2013.04.12 22:48:46 3: CUL_0: T315700A601 -78
2013.04.12 22:48:58 3: CUL_0: T0A0A00A6D7 -91.5
2013.04.12 22:49:09 3: CUL_0: T6AB18F02 -81
2013.04.12 22:49:09 3: CUL_0: T6AB18F82 -81
2013.04.12 22:49:25 3: CUL_0: T105700A600 -86.5
2013.04.12 22:49:28 3: CUL_0: T245400A600 -77
2013.04.12 22:49:33 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:49:34 3: CUL_0: TA805F102 -73
2013.04.12 22:49:34 3: CUL_0: TA805F182 -73
2013.04.12 22:49:37 3: CUL_0: T41FCD302 -86.5
2013.04.12 22:49:46 3: CUL_0: T156000A636 -84.5
2013.04.12 22:49:46 3: CUL_0: T15604269A0 -85
2013.04.12 22:49:46 3: CUL_0: T1560436900 -85
2013.04.12 22:49:47 3: CUL_0: T1560446900 -85
2013.04.12 22:49:49 3: CUL_0: T987CB102 -89
2013.04.12 22:49:50 3: CUL_0: T987CB182 -88.5
2013.04.12 22:49:54 3: CUL_0: T1A0400A600 -81.5
2013.04.12 22:50:35 3: CUL_0: K21974089 -68.5
2013.04.12 22:50:35 3: CUL_0: T031100B600 -56
2013.04.12 22:50:39 3: CUL_0: T163500A608 -61.5
2013.04.12 22:50:45 3: CUL_0: T315700A601 -78
2013.04.12 22:50:54 3: CUL_0: T0A0A00A6D7 -92.5
2013.04.12 22:51:23 3: CUL_0: T105700A600 -86.5
2013.04.12 22:51:25 3: CUL_0: T245400A600 -77
2013.04.12 22:51:29 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:51:29 3: CUL_0: T0C224269A5 -74.5
2013.04.12 22:51:30 3: CUL_0: T0C22436900 -74.5
2013.04.12 22:51:30 3: CUL_0: T0C22446900 -74.5
2013.04.12 22:51:34 3: CUL_0: T711C9402 -76.5
2013.04.12 22:51:35 3: CUL_0: T711C9482 -76.5
2013.04.12 22:51:41 3: CUL_0: T156000A636 -84.5
2013.04.12 22:51:51 3: CUL_0: T1A0400A600 -81
2013.04.12 22:52:31 3: CUL_0: T031100B600 -56
2013.04.12 22:52:33 3: CUL_0: T8CD71A02 -77.5
2013.04.12 22:52:33 3: CUL_0: T8CD71A82 -77
2013.04.12 22:52:36 3: CUL_0: T1635002607 -61.5
2013.04.12 22:52:43 3: CUL_0: T315700A601 -78
2013.04.12 22:52:51 3: CUL_0: T0A0A00A6D7 -92
2013.04.12 22:53:11 3: CUL_0: T6AB18F02 -81
2013.04.12 22:53:11 3: CUL_0: T6AB18F82 -81
2013.04.12 22:53:22 3: CUL_0: T105700A600 -86.5
2013.04.12 22:53:22 3: CUL_0: T245400A600 -77
2013.04.12 22:53:23 3: CUL_0: T24544269A1 -77
2013.04.12 22:53:23 3: CUL_0: T2454436900 -77.5
2013.04.12 22:53:24 3: CUL_0: T2454446900 -77
2013.04.12 22:53:31 3: CUL_0: K21964089 -69
2013.04.12 22:53:36 3: CUL_0: T156000A636 -84.5
2013.04.12 22:53:47 3: CUL_0: T41FCD302 -86.5
2013.04.12 22:53:48 3: CUL_0: TA805F102 -73
2013.04.12 22:53:48 3: CUL_0: TA805F182 -73
2013.04.12 22:54:03 3: CUL_0: T987CB102 -88.5
2013.04.12 22:54:04 3: CUL_0: T987CB182 -89
2013.04.12 22:54:17 3: CUL_0: K01179237 -50
2013.04.12 22:54:26 3: CUL_0: T031100B600 -56
2013.04.12 22:54:34 3: CUL_0: T163500A607 -61.5
2013.04.12 22:54:35 3: CUL_0: T16354269CA -61
2013.04.12 22:54:35 3: CUL_0: T1635436900 -61.5
2013.04.12 22:54:35 3: CUL_0: T1635446900 -61.5
2013.04.12 22:54:42 3: CUL_0: T315700A601 -78
2013.04.12 22:54:46 3: CUL_0: T0A0A00A6D7 -92
2013.04.12 22:55:19 3: CUL_0: T245400A600 -77
2013.04.12 22:55:20 3: CUL_0: T105700A600 -86
2013.04.12 22:55:21 3: CUL_0: T0C2200A600 -74.5
2013.04.12 22:55:31 3: CUL_0: T156000A636 -84.5
2013.04.12 22:55:42 3: CUL_0: T711C9402 -76.5
2013.04.12 22:55:43 3: CUL_0: T711C9482 -76.5
2013.04.12 22:55:45 3: CUL_0: T1A0400A600 -81
2013.04.12 22:56:22 3: CUL_0: T031100B600 -56
2013.04.12 22:56:31 3: CUL_0: T163500A607 -61.5
2013.04.12 22:56:40 3: CUL_0: T315700A601 -78.5
2013.04.12 22:56:43 3: CUL_0: T0A0A00A6D7 -93
2013.04.12 22:56:45 3: CUL_0: T8CD71A02 -77.5
2013.04.12 22:56:45 3: CUL_0: T8CD71A82 -77
2013.04.12 22:57:13 3: CUL_0: T6AB18F02 -80
2013.04.12 22:57:13 3: CUL_0: T6AB18F82 -80
2013.04.12 22:57:14 3: CUL_0: K01174238 -50
2013.04.12 22:57:16 3: CUL_0: FD14B4200 -64
2013.04.12 22:57:17 2: IT set a2_eg_ez_Lampe on
2013.04.12 22:57:17 3: SW: is0000F0000F11
2013.04.12 22:57:17 3: CUL_0: FD14B4200 -66.5
2013.04.12 22:57:17 2: IT set a2_eg_ez_Lampe on
2013.04.12 22:57:17 3: SW: is0000F0000F11
2013.04.12 22:57:18 3: CUL_0: FD14B4000 -66.5
2013.04.12 22:57:18 2: IT set a1_eg_ki_Lampe off
2013.04.12 22:57:18 3: SW: is000000000F10
2013.04.12 22:57:19 3: CUL_0: T10574269A5 -85
2013.04.12 22:57:20 3: CUL_0: T1057436900 -85.5
2013.04.12 22:57:23 3: CUL_0: FD14B4200 -61
2013.04.12 22:57:23 2: IT set a2_eg_ez_Lampe on
2013.04.12 22:57:23 3: SW: is0000F0000F11
2013.04.12 22:57:42 3: CUL_0: T1A0400A600 -81
2013.04.12 22:57:57 3: CUL_0: T41FCD302 -86.5
2013.04.12 22:57:57 3: CUL_0: T41FCD382 -86.5
2013.04.12 22:58:02 3: CUL_0: TA805F102 -72
2013.04.12 22:58:02 3: CUL_0: TA805F182 -71.5
2013.04.12 22:58:17 3: CUL_0: T987CB102 -90.5
2013.04.12 22:58:17 3: CUL_0: T031100B600 -56
2013.04.12 22:58:29 3: CUL_0: T163500A607 -62
2013.04.12 22:58:39 3: CUL_0: T315700A601 -77.5
2013.04.12 22:58:39 3: CUL_0: T31574269C3 -77.5
2013.04.12 22:58:39 3: CUL_0: T3157436900 -77.5
2013.04.12 22:58:40 3: CUL_0: T3157446900 -77.5
2013.04.12 22:59:02 3: CUL_0: T03114269AE -56
2013.04.12 22:59:03 3: CUL_0: T0311436900 -56
2013.04.12 22:59:03 3: CUL_0: T0311446900 -56
2013.04.12 22:59:13 3: CUL_0: T0C2200A600 -72.5
2013.04.12 22:59:13 3: CUL_0: T245400A600 -76.5
2013.04.12 22:59:17 3: CUL_0: T105700A600 -86.5
2013.04.12 22:59:18 3: CUL_0: T10574269A5 -87.5
2013.04.12 22:59:18 3: CUL_0: T1057436900 -87.5
2013.04.12 22:59:19 3: CUL_0: T1057446900 -88
2013.04.12 22:59:21 3: CUL_0: T156000A636 -85.5
2013.04.12 22:59:39 3: CUL_0: T1A0400A600 -81.5
2013.04.12 22:59:50 3: CUL_0: T711C9402 -76
2013.04.12 22:59:51 3: CUL_0: T711C9482 -76
2013.04.12 23:00:00 3: necessaryCredit------------>150
2013.04.12 23:00:00 3: key------------>1:1365800400.01578:5
2013.04.12 23:00:00 3: name------------>eg_ki_Heizung: desired-temp 15.0
2013.04.12 23:00:00 3: SW: T02
2013.04.12 23:00:00 3: buffer------------>N/A
2013.04.12 23:00:00 3: SW: X
2013.04.12 23:00:00 3: credit10ms------------>559
2013.04.12 23:00:00 3: waitTime------------>0
2013.04.12 23:00:00 3: SW: T1635411e
2013.04.12 23:00:00 2: FHT set eg_ki_Heizung desired-temp 15.0
2013.04.12 23:00:00 3: waitTime------------>120
2013.04.12 23:00:00 3: Puffergroesse: 0
2013.04.12 23:00:01 3: CUL_0: TF8E8B802 -88.5
2013.04.12 23:00:02 3: CUL_0: TF8E8B882 -88
2013.04.12 23:00:11 3: CUL_0: K01174238 -50.5
2013.04.12 23:00:13 3: CUL_0: T031100B600 -55.5
2013.04.12 23:00:26 3: CUL_0: T163500A607 -62
2013.04.12 23:00:27 3: CUL_0: T163541691E -62
2013.04.12 23:00:37 3: CUL_0: T315700A601 -77.5
2013.04.12 23:00:57 3: CUL_0: T8CD71A02 -77
2013.04.12 23:01:09 3: CUL_0: T0C2200A600 -73
2013.04.12 23:01:10 3: CUL_0: T245400A600 -76
2013.04.12 23:01:15 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:01:15 3: CUL_0: T6AB18F82 -80
2013.04.12 23:01:16 3: CUL_0: T156000A636 -85.5
2013.04.12 23:01:16 3: CUL_0: T105700A600 -87.5
2013.04.12 23:01:16 3: CUL_0: T15604269A0 -85.5
2013.04.12 23:01:16 3: CUL_0: T1560436900 -85.5
2013.04.12 23:01:36 3: CUL_0: T1A0400A600 -81.5
2013.04.12 23:02:07 3: CUL_0: T41FCD302 -86
2013.04.12 23:02:07 3: CUL_0: T41FCD382 -86
2013.04.12 23:02:08 3: CUL_0: T031100B600 -56
2013.04.12 23:02:16 3: CUL_0: TA805F102 -71.5
2013.04.12 23:02:16 3: CUL_0: TA805F182 -71
2013.04.12 23:02:24 3: CUL_0: T1635002600 -62
2013.04.12 23:02:31 3: CUL_0: T987CB102 -89.5
2013.04.12 23:02:32 3: CUL_0: T987CB182 -90
2013.04.12 23:02:36 3: CUL_0: T315700A601 -77.5
2013.04.12 23:03:05 3: CUL_0: T0C2200A600 -74
2013.04.12 23:03:05 3: CUL_0: T0C224269A4 -74
2013.04.12 23:03:06 3: CUL_0: T0C22436900 -74
2013.04.12 23:03:06 3: CUL_0: T0C22446900 -74
2013.04.12 23:03:07 3: CUL_0: T245400A600 -74.5
2013.04.12 23:03:08 3: CUL_0: K01174238 -50
2013.04.12 23:03:11 3: CUL_0: T156000A636 -85.5
2013.04.12 23:03:11 3: CUL_0: T1560446900 -85.5
2013.04.12 23:03:14 3: CUL_0: T105700A600 -90
2013.04.12 23:03:26 3: CUL_0: K11618156 -74.5
2013.04.12 23:03:33 3: CUL_0: T1A0400A600 -81
2013.04.12 23:03:58 3: CUL_0: T711C9402 -75.5
2013.04.12 23:03:59 3: CUL_0: T711C9482 -75.5
2013.04.12 23:04:04 3: CUL_0: T031100B600 -56
2013.04.12 23:04:17 3: CUL_0: TF8E8B802 -91.5
2013.04.12 23:04:18 3: CUL_0: TF8E8B882 -91.5
2013.04.12 23:04:21 3: CUL_0: T163500A600 -62
2013.04.12 23:04:22 3: CUL_0: T163541691E -62
2013.04.12 23:04:34 3: CUL_0: T315700A601 -77.5
2013.04.12 23:05:01 3: CUL_0: T0C2200A600 -74
2013.04.12 23:05:01 3: CUL_0: T0C22446900 -74
2013.04.12 23:05:04 3: CUL_0: T245400A600 -74.5
2013.04.12 23:05:05 3: CUL_0: T24544269A0 -74.5
2013.04.12 23:05:05 3: CUL_0: T2454436900 -74.5
2013.04.12 23:05:06 3: CUL_0: T2454446900 -74.5
2013.04.12 23:05:09 3: CUL_0: T8CD71A02 -77.5
2013.04.12 23:05:09 3: CUL_0: T8CD71A82 -77
2013.04.12 23:05:13 3: CUL_0: T105700A600 -90
2013.04.12 23:05:17 3: CUL_0: T6AB18F02 -81
2013.04.12 23:05:17 3: CUL_0: T6AB18F82 -80.5
2013.04.12 23:05:30 3: CUL_0: T1A0400A600 -81.5
2013.04.12 23:05:31 3: CUL_0: T1A044269C4 -81.5
2013.04.12 23:05:31 3: CUL_0: T1A04436900 -81.5
2013.04.12 23:05:32 3: CUL_0: T1A04446900 -81.5
2013.04.12 23:05:59 3: CUL_0: T031100B600 -56
2013.04.12 23:06:05 3: CUL_0: K01164238 -50.5
2013.04.12 23:06:17 3: CUL_0: T41FCD302 -85
2013.04.12 23:06:17 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:06:19 3: CUL_0: T163500A600 -62
2013.04.12 23:06:23 3: CUL_0: K11618156 -75.5
2013.04.12 23:06:30 3: CUL_0: TA805F102 -72
2013.04.12 23:06:30 3: CUL_0: TA805F182 -71.5
2013.04.12 23:06:33 3: CUL_0: T315700A601 -77.5
2013.04.12 23:06:45 3: CUL_0: T987CB102 -91.5
2013.04.12 23:06:46 3: CUL_0: T987CB182 -92
2013.04.12 23:06:57 3: CUL_0: T0C2200A600 -74
2013.04.12 23:07:01 3: CUL_0: T156000A636 -85.5
2013.04.12 23:07:01 3: CUL_0: T245400A600 -74
2013.04.12 23:07:11 3: CUL_0: T105700A600 -90
2013.04.12 23:07:12 3: CUL_0: T1057446900 -89.5
2013.04.12 23:07:27 3: CUL_0: T1A0400A600 -81
2013.04.12 23:07:55 3: CUL_0: T031100B600 -56
2013.04.12 23:08:06 3: CUL_0: T711C9402 -75
2013.04.12 23:08:07 3: CUL_0: T711C9482 -75.5
2013.04.12 23:08:16 3: CUL_0: T163500A600 -62
2013.04.12 23:08:17 3: CUL_0: T16354269CA -61
2013.04.12 23:08:17 3: CUL_0: T1635436900 -62
2013.04.12 23:08:18 3: CUL_0: T1635446900 -62
2013.04.12 23:08:31 3: CUL_0: T315700A601 -77.5
2013.04.12 23:08:56 3: CUL_0: T156000A636 -85
2013.04.12 23:08:58 3: CUL_0: T245400A600 -75
2013.04.12 23:08:59 3: CUL_0: T2454446900 -75
2013.04.12 23:09:02 3: CUL_0: K01164238 -50
2013.04.12 23:09:10 3: CUL_0: T105700A600 -89.5
2013.04.12 23:09:10 3: CUL_0: T10574269A5 -88.5
2013.04.12 23:09:11 3: CUL_0: T1057436900 -88.5
2013.04.12 23:09:11 3: CUL_0: T1057446900 -88.5
2013.04.12 23:09:19 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:09:21 3: CUL_0: T8CD71A02 -77.5
2013.04.12 23:09:21 3: CUL_0: T8CD71A82 -77
2013.04.12 23:09:24 3: CUL_0: T1A0400A600 -80.5
2013.04.12 23:09:50 3: CUL_0: T031100B600 -56
2013.04.12 23:10:14 3: CUL_0: T163500A600 -62
2013.04.12 23:10:27 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:10:27 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:10:30 3: CUL_0: T315700A601 -77.5
2013.04.12 23:10:30 3: CUL_0: T31574269C3 -77.5
2013.04.12 23:10:30 3: CUL_0: T3157436900 -77.5
2013.04.12 23:10:31 3: CUL_0: T3157446900 -77.5
2013.04.12 23:10:44 3: CUL_0: TA805F102 -71
2013.04.12 23:10:44 3: CUL_0: TA805F182 -70.5
2013.04.12 23:10:49 3: CUL_0: T0C2200A600 -74.5
2013.04.12 23:10:51 3: CUL_0: T156000A636 -84.5
2013.04.12 23:10:56 3: CUL_0: T245400A600 -75
2013.04.12 23:10:59 3: CUL_0: T987CB102 -92.5
2013.04.12 23:11:00 3: CUL_0: T987CB182 -92.5
2013.04.12 23:11:08 3: CUL_0: T105700A600 -88.5
2013.04.12 23:11:21 3: CUL_0: T1A0400A600 -81
2013.04.12 23:11:46 3: CUL_0: T031100B600 -55.5
2013.04.12 23:11:59 3: CUL_0: K01164238 -50
2013.04.12 23:12:12 3: CUL_0: T163500A600 -62
2013.04.12 23:12:15 3: CUL_0: T711C9482 -75.5
2013.04.12 23:12:28 3: CUL_0: T315700A601 -77.5
2013.04.12 23:12:45 3: CUL_0: T0C2200A600 -75
2013.04.12 23:12:46 3: CUL_0: T156000A636 -84.5
2013.04.12 23:12:49 3: CUL_0: TF8E8B802 -92.5
2013.04.12 23:12:50 3: CUL_0: TF8E8B882 -92
2013.04.12 23:12:52 3: CUL_0: T245400A600 -75.5
2013.04.12 23:13:07 3: CUL_0: T105700A600 -86.5
2013.04.12 23:13:18 3: CUL_0: T1A0400A600 -81
2013.04.12 23:13:21 3: CUL_0: T6AB18F02 -81
2013.04.12 23:13:33 3: CUL_0: T8CD71A02 -77.5
2013.04.12 23:13:33 3: CUL_0: T8CD71A82 -77
2013.04.12 23:13:41 3: CUL_0: T031100B600 -56
2013.04.12 23:14:09 3: CUL_0: T163500A600 -62
2013.04.12 23:14:27 3: CUL_0: T315700A601 -77.5
2013.04.12 23:14:37 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:14:37 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:14:41 3: CUL_0: T156000A636 -84.5
2013.04.12 23:14:41 3: CUL_0: T0C2200A600 -75
2013.04.12 23:14:49 3: CUL_0: T245400A600 -75
2013.04.12 23:14:58 3: CUL_0: TA805F102 -70.5
2013.04.12 23:14:58 3: CUL_0: TA805F182 -70.5
2013.04.12 23:15:05 3: CUL_0: T105700A600 -89
2013.04.12 23:15:15 3: CUL_0: T1A0400A600 -81
2013.04.12 23:15:37 3: CUL_0: T031100B600 -56
2013.04.12 23:15:38 3: CUL_0: T03114269AE -56
2013.04.12 23:15:38 3: CUL_0: T0311436900 -56.5
2013.04.12 23:15:38 3: CUL_0: T0311446900 -56
2013.04.12 23:16:07 3: CUL_0: T163500A600 -61.5
2013.04.12 23:16:22 3: CUL_0: T711C9402 -75
2013.04.12 23:16:23 3: CUL_0: T711C9482 -75.5
2013.04.12 23:16:25 3: CUL_0: T315700A601 -77.5
2013.04.12 23:16:36 3: CUL_0: T156000A636 -85
2013.04.12 23:16:37 3: CUL_0: T0C2200A600 -75
2013.04.12 23:16:46 3: CUL_0: T245400A600 -75
2013.04.12 23:17:04 3: CUL_0: T105700A600 -90.5
2013.04.12 23:17:12 3: CUL_0: T1A0400A600 -81
2013.04.12 23:17:23 3: CUL_0: T6AB18F02 -81
2013.04.12 23:17:23 3: CUL_0: T6AB18F82 -80
2013.04.12 23:17:32 3: CUL_0: T031100B600 -56
2013.04.12 23:17:45 3: CUL_0: T8CD71A02 -77
2013.04.12 23:17:45 3: CUL_0: T8CD71A82 -77
2013.04.12 23:18:04 3: CUL_0: T163500A600 -62
2013.04.12 23:18:24 3: CUL_0: T315700A601 -77.5
2013.04.12 23:18:31 3: CUL_0: T156000A636 -84.5
2013.04.12 23:18:31 3: CUL_0: T15604269A0 -85.5
2013.04.12 23:18:31 3: CUL_0: T1560436900 -85
2013.04.12 23:18:32 3: CUL_0: T1560446900 -85
2013.04.12 23:18:33 3: CUL_0: T0C2200A600 -74.5
2013.04.12 23:18:43 3: CUL_0: T245400A600 -74.5
2013.04.12 23:18:47 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:18:47 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:18:56 3: CUL_0: T0C224269A4 -74.5
2013.04.12 23:18:56 3: CUL_0: T0C22436900 -74.5
2013.04.12 23:18:57 3: CUL_0: T0C22446900 -74.5
2013.04.12 23:19:02 3: CUL_0: T105700A600 -90
2013.04.12 23:19:09 3: CUL_0: T1A0400A600 -81
2013.04.12 23:19:12 3: CUL_0: TA805F102 -71
2013.04.12 23:19:12 3: CUL_0: TA805F182 -70.5
2013.04.12 23:19:27 3: CUL_0: T987CB102 -90
2013.04.12 23:19:28 3: CUL_0: T987CB182 -90.5
2013.04.12 23:19:28 3: CUL_0: T031100B600 -56
2013.04.12 23:19:55 3: CUL_0: K21943089 -69
2013.04.12 23:20:02 3: CUL_0: T163500A600 -62
2013.04.12 23:20:22 3: CUL_0: T315700A601 -77.5
2013.04.12 23:20:26 3: CUL_0: T156000A636 -84.5
2013.04.12 23:20:26 3: CUL_0: T1560446900 -84.5
2013.04.12 23:20:29 3: CUL_0: T0C2200A600 -74.5
2013.04.12 23:20:30 3: CUL_0: T711C9402 -75.5
2013.04.12 23:20:31 3: CUL_0: T711C9482 -75.5
2013.04.12 23:20:40 3: CUL_0: T245400A600 -74.5
2013.04.12 23:20:50 3: CUL_0: K01154238 -50
2013.04.12 23:21:01 3: CUL_0: T105700A600 -89.5
2013.04.12 23:21:03 3: CUL_0: T24544269A1 -75
2013.04.12 23:21:04 3: CUL_0: T2454436900 -75
2013.04.12 23:21:06 3: CUL_0: T1A0400A600 -80.5
2013.04.12 23:21:14 3: CUL_0: T1A044269C4 -80.5
2013.04.12 23:21:14 3: CUL_0: T1A04436900 -81
2013.04.12 23:21:15 3: CUL_0: T1A04446900 -81
2013.04.12 23:21:23 3: CUL_0: T031100B600 -56
2013.04.12 23:21:25 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:21:25 3: CUL_0: T6AB18F82 -80
2013.04.12 23:21:57 3: CUL_0: T8CD71A02 -77.5
2013.04.12 23:21:57 3: CUL_0: T8CD71A82 -77
2013.04.12 23:21:59 3: CUL_0: T163500A600 -62
2013.04.12 23:22:00 3: CUL_0: T16354269C9 -61.5
2013.04.12 23:22:00 3: CUL_0: T1635436900 -62
2013.04.12 23:22:01 3: CUL_0: T1635446900 -62
2013.04.12 23:22:25 3: CUL_0: T0C2200A600 -74.5
2013.04.12 23:22:37 3: CUL_0: T245400A600 -74.5
2013.04.12 23:22:38 3: CUL_0: T24544269A1 -74.5
2013.04.12 23:22:38 3: CUL_0: T2454436900 -75
2013.04.12 23:22:39 3: CUL_0: T2454446900 -74.5
2013.04.12 23:22:57 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:22:59 3: CUL_0: T105700A600 -90.5
2013.04.12 23:23:03 3: CUL_0: T1A0400A600 -81
2013.04.12 23:23:19 3: CUL_0: T031100B600 -56
2013.04.12 23:23:26 3: CUL_0: TA805F102 -68.5
2013.04.12 23:23:26 3: CUL_0: TA805F182 -68.5
2013.04.12 23:23:35 3: CUL_0: T10574269A5 -90
2013.04.12 23:23:35 3: CUL_0: T1057436900 -90
2013.04.12 23:23:36 3: CUL_0: T1057446900 -90.5
2013.04.12 23:23:41 3: CUL_0: T987CB102 -89.5
2013.04.12 23:23:47 3: CUL_0: K01154238 -50.5
2013.04.12 23:23:57 3: CUL_0: T163500A600 -62
2013.04.12 23:24:16 3: CUL_0: T156000A636 -85
2013.04.12 23:24:19 3: CUL_0: T315700A601 -77.5
2013.04.12 23:24:21 3: CUL_0: T0C2200A600 -74.5
2013.04.12 23:24:26 3: CUL_0: T31574269C2 -77.5
2013.04.12 23:24:26 3: CUL_0: T3157436900 -77.5
2013.04.12 23:24:35 3: CUL_0: T245400A600 -74.5
2013.04.12 23:24:38 3: CUL_0: T711C9402 -75.5
2013.04.12 23:24:39 3: CUL_0: T711C9482 -75
2013.04.12 23:24:58 3: CUL_0: T105700A600 -90
2013.04.12 23:25:00 3: CUL_0: T1A0400A600 -81
2013.04.12 23:25:14 3: CUL_0: T031100B600 -56
2013.04.12 23:25:27 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:25:27 3: CUL_0: T6AB18F82 -80
2013.04.12 23:25:37 3: CUL_0: TF8E8B802 -91.5
2013.04.12 23:25:38 3: CUL_0: TF8E8B882 -91
2013.04.12 23:25:54 3: CUL_0: T163500A600 -62
2013.04.12 23:26:09 3: CUL_0: T8CD71A02 -77
2013.04.12 23:26:09 3: CUL_0: T8CD71A82 -77
2013.04.12 23:26:11 3: CUL_0: T156000A636 -84.5
2013.04.12 23:26:17 3: CUL_0: T0C2200A600 -74
2013.04.12 23:26:19 3: CUL_0: T31574269C2 -77.5
2013.04.12 23:26:19 3: CUL_0: T3157436900 -77.5
2013.04.12 23:26:20 3: CUL_0: T3157446900 -77.5
2013.04.12 23:26:31 3: CUL_0: T245400A600 -75
2013.04.12 23:26:44 3: CUL_0: K01144238 -50
2013.04.12 23:26:56 3: CUL_0: T105700A600 -89
2013.04.12 23:26:57 3: CUL_0: T1A0400A600 -80.5
2013.04.12 23:27:07 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:27:07 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:27:10 3: CUL_0: T031100A600 -56
2013.04.12 23:27:11 3: CUL_0: T03114269AF -56
2013.04.12 23:27:11 3: CUL_0: T0311436900 -56
2013.04.12 23:27:11 3: CUL_0: T0311446900 -56
2013.04.12 23:27:40 3: CUL_0: TA805F102 -68.5
2013.04.12 23:27:40 3: CUL_0: TA805F182 -68.5
2013.04.12 23:27:52 3: CUL_0: T163500A600 -61.5
2013.04.12 23:27:55 3: CUL_0: T987CB102 -90.5
2013.04.12 23:27:56 3: CUL_0: T987CB182 -91
2013.04.12 23:28:06 3: CUL_0: T156000A636 -85
2013.04.12 23:28:13 3: CUL_0: T0C2200A600 -74
2013.04.12 23:28:16 3: CUL_0: T315700A601 -77.5
2013.04.12 23:28:29 3: CUL_0: T245400A600 -75
2013.04.12 23:28:46 3: CUL_0: T711C9402 -75.5
2013.04.12 23:28:47 3: CUL_0: T711C9482 -75.5
2013.04.12 23:28:54 3: CUL_0: T1A0400A600 -81
2013.04.12 23:28:55 3: CUL_0: T105700A600 -89.5
2013.04.12 23:29:05 3: CUL_0: T031100A600 -56
2013.04.12 23:29:06 3: CUL_0: T0311446900 -56
2013.04.12 23:29:29 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:29:29 3: CUL_0: T6AB18F82 -80
2013.04.12 23:29:41 3: CUL_0: K01144238 -50
2013.04.12 23:29:49 3: CUL_0: T163500A600 -62
2013.04.12 23:30:01 3: CUL_0: T156000A636 -85
2013.04.12 23:30:09 3: CUL_0: T0C2200A600 -74
2013.04.12 23:30:15 3: CUL_0: T315700A601 -78
2013.04.12 23:30:21 3: CUL_0: T8CD71A02 -77
2013.04.12 23:30:21 3: CUL_0: T8CD71A82 -77
2013.04.12 23:30:25 3: CUL_0: T245400A600 -74.5
2013.04.12 23:30:51 3: CUL_0: T1A0400A600 -81
2013.04.12 23:30:53 3: CUL_0: T105700A600 -90
2013.04.12 23:31:01 3: CUL_0: T031100A600 -56.5
2013.04.12 23:31:17 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:31:17 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:31:47 3: CUL_0: T163500A600 -62
2013.04.12 23:31:54 3: CUL_0: TA805F102 -69
2013.04.12 23:31:54 3: CUL_0: TA805F182 -69
2013.04.12 23:31:56 3: CUL_0: T156000A636 -85
2013.04.12 23:32:05 3: CUL_0: T0C2200A600 -74.5
2013.04.12 23:32:09 3: CUL_0: T987CB102 -91.5
2013.04.12 23:32:10 3: CUL_0: T987CB182 -91.5
2013.04.12 23:32:13 3: CUL_0: T315700A601 -77.5
2013.04.12 23:32:22 3: CUL_0: T245400A600 -74.5
2013.04.12 23:32:38 3: CUL_0: K01144238 -50
2013.04.12 23:32:48 3: CUL_0: T1A0400A600 -81
2013.04.12 23:32:51 3: CUL_0: K11608156 -74.5
2013.04.12 23:32:52 3: CUL_0: T105700A600 -90
2013.04.12 23:32:54 3: CUL_0: T711C9402 -75.5
2013.04.12 23:32:55 3: CUL_0: T711C9482 -75
2013.04.12 23:32:56 3: CUL_0: T031100A600 -56
2013.04.12 23:33:31 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:33:31 3: CUL_0: T6AB18F82 -80
2013.04.12 23:33:44 3: CUL_0: T163500A600 -62
2013.04.12 23:33:51 3: CUL_0: T156000A636 -85
2013.04.12 23:33:51 3: CUL_0: T15604269A0 -85.5
2013.04.12 23:33:51 3: CUL_0: T1560436900 -85
2013.04.12 23:33:52 3: CUL_0: T1560446900 -85
2013.04.12 23:34:01 3: CUL_0: T0C2200A600 -74
2013.04.12 23:34:09 3: CUL_0: TF8E8B802 -92
2013.04.12 23:34:10 3: CUL_0: TF8E8B882 -91.5
2013.04.12 23:34:12 3: CUL_0: T315700A601 -77.5
2013.04.12 23:34:19 3: CUL_0: T245400A600 -74.5
2013.04.12 23:34:33 3: CUL_0: T8CD71A02 -77.5
2013.04.12 23:34:33 3: CUL_0: T8CD71A82 -77
2013.04.12 23:34:45 3: CUL_0: T1A0400A600 -80.5
2013.04.12 23:34:50 3: CUL_0: T105700A600 -90.5
2013.04.12 23:34:52 3: CUL_0: T031100A600 -56
2013.04.12 23:34:56 3: CUL_0: T0C224269A4 -74
2013.04.12 23:35:27 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:35:27 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:35:35 3: CUL_0: K01144238 -50
2013.04.12 23:35:42 3: CUL_0: T163500A600 -62
2013.04.12 23:35:46 3: CUL_0: T156000A636 -85.5
2013.04.12 23:35:48 3: CUL_0: K11608156 -74.5
2013.04.12 23:35:57 3: CUL_0: T0C2200A600 -74
2013.04.12 23:36:08 3: CUL_0: TA805F102 -71.5
2013.04.12 23:36:08 3: CUL_0: TA805F182 -71
2013.04.12 23:36:10 3: CUL_0: T315700A601 -78
2013.04.12 23:36:17 3: CUL_0: T245400A600 -75
2013.04.12 23:36:23 3: CUL_0: T987CB102 -91
2013.04.12 23:36:42 3: CUL_0: T1A0400A600 -81
2013.04.12 23:36:47 3: CUL_0: T031100A600 -56
2013.04.12 23:36:49 3: CUL_0: T105700A600 -90.5
2013.04.12 23:37:02 3: CUL_0: T711C9402 -75
2013.04.12 23:37:03 3: CUL_0: T711C9482 -75.5
2013.04.12 23:37:33 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:37:33 3: CUL_0: T6AB18F82 -80
2013.04.12 23:37:39 3: CUL_0: T163500A600 -62
2013.04.12 23:37:41 3: CUL_0: T156000A636 -85.5
2013.04.12 23:37:49 3: CUL_0: T16354269C8 -62
2013.04.12 23:37:49 3: CUL_0: T1635436900 -62
2013.04.12 23:37:50 3: CUL_0: T1635446900 -62
2013.04.12 23:37:53 3: CUL_0: T0C2200A600 -74
2013.04.12 23:38:09 3: CUL_0: T3157002600 -78
2013.04.12 23:38:13 3: CUL_0: T245400A600 -75
2013.04.12 23:38:14 3: CUL_0: T24544269A0 -75
2013.04.12 23:38:14 3: CUL_0: T2454436900 -75
2013.04.12 23:38:15 3: CUL_0: T2454446900 -75
2013.04.12 23:38:26 3: CUL_0: TF8E8B882 -92
2013.04.12 23:38:32 3: CUL_0: K01134238 -50
2013.04.12 23:38:39 3: CUL_0: T1A0400A600 -81
2013.04.12 23:38:40 3: CUL_0: T1A044269C4 -80.5
2013.04.12 23:38:40 3: CUL_0: T1A04436900 -81
2013.04.12 23:38:43 3: CUL_0: T031100A600 -56.5
2013.04.12 23:38:45 3: CUL_0: T8CD71A02 -77
2013.04.12 23:38:45 3: CUL_0: T8CD71A82 -77
2013.04.12 23:38:47 3: CUL_0: T105700A600 -91
2013.04.12 23:39:36 3: CUL_0: T156000A636 -85
2013.04.12 23:39:37 3: CUL_0: T163500A600 -62
2013.04.12 23:39:37 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:40:07 3: CUL_0: T315700A600 -78
2013.04.12 23:40:10 3: CUL_0: T245400A600 -75
2013.04.12 23:40:22 3: CUL_0: TA805F102 -71.5
2013.04.12 23:40:22 3: CUL_0: TA805F182 -71
2013.04.12 23:40:25 3: CUL_0: T31574269C2 -77.5
2013.04.12 23:40:26 3: CUL_0: T3157436900 -77.5
2013.04.12 23:40:26 3: CUL_0: T3157446900 -77.5
2013.04.12 23:40:36 3: CUL_0: T1A04002610 -81
2013.04.12 23:40:37 3: CUL_0: T1A04446900 -81
2013.04.12 23:40:38 3: CUL_0: T031100A600 -56.5
2013.04.12 23:40:46 3: CUL_0: T105700A600 -90.5
2013.04.12 23:40:46 3: CUL_0: T10574269A5 -91
2013.04.12 23:40:47 3: CUL_0: T1057436900 -90.5
2013.04.12 23:40:47 3: CUL_0: T1057446900 -91
2013.04.12 23:41:10 3: CUL_0: T711C9402 -75
2013.04.12 23:41:11 3: CUL_0: T711C9482 -75.5
2013.04.12 23:41:29 3: CUL_0: K01134238 -50
2013.04.12 23:41:31 3: CUL_0: T156000A636 -85.5
2013.04.12 23:41:34 3: CUL_0: T163500A600 -62
2013.04.12 23:41:35 3: CUL_0: T6AB18F02 -80.5
2013.04.12 23:41:35 3: CUL_0: T6AB18F82 -80
2013.04.12 23:41:45 3: CUL_0: T0C2200A600 -74
2013.04.12 23:41:46 3: CUL_0: T0C224269A4 -74.5
2013.04.12 23:41:46 3: CUL_0: T0C22436900 -74.5
2013.04.12 23:42:06 3: CUL_0: T315700A600 -78
2013.04.12 23:42:07 3: CUL_0: T245400A600 -75
2013.04.12 23:42:33 3: CUL_0: T1A0400A610 -81
2013.04.12 23:42:34 3: CUL_0: T031100A600 -56.5
2013.04.12 23:42:41 3: CUL_0: TF8E8B802 -91
2013.04.12 23:42:42 3: CUL_0: TF8E8B882 -90.5
2013.04.12 23:42:44 3: CUL_0: T105700A600 -90.5
2013.04.12 23:42:57 3: CUL_0: T8CD71A02 -77
2013.04.12 23:42:57 3: CUL_0: T8CD71A82 -77
2013.04.12 23:43:02 3: CUL_0: T03114269AF -56.5
2013.04.12 23:43:03 3: CUL_0: T0311436900 -56.5
2013.04.12 23:43:03 3: CUL_0: T0311446900 -56
2013.04.12 23:43:23 3: CUL_0: K21923089 -69
2013.04.12 23:43:32 3: CUL_0: T163500A600 -62
2013.04.12 23:43:41 3: CUL_0: T0C2200A600 -74
2013.04.12 23:43:47 3: CUL_0: T41FCD302 -85.5
2013.04.12 23:43:47 3: CUL_0: T41FCD382 -85.5
2013.04.12 23:44:04 3: CUL_0: T315700A600 -78
2013.04.12 23:44:04 3: CUL_0: T245400A600 -75
2013.04.12 23:44:26 3: CUL_0: K01134238 -50
2013.04.12 23:44:30 3: CUL_0: T031100A600 -56.5
2013.04.12 23:44:30 3: CUL_0: T1A0400A610 -81
Bitte parallel das
Define yy... Angeben
kannst du für die folgenden fht
41FC
6AB1
711C
8CD7
987C
A805
F8E8
das loglevel auch auf 3 setzen. Sie schicken merkwürdige Nachrichten.
Kannst du lange Protokolle als Datei anhängen. Der Thread wird sonst so unübersichtlich.
Hallo Dietmar,
folgende Erweiterung wäre für mich noch sinnvoll,
damit man einfach über die definierten Heating-controls iterieren kann.
(siehe Anhang / see attachement)
John
@john:
ich habe es so(116) gemacht: (etwas später, weil hash->{NAME} in Zeile 89 noch nicht versorgt war).
(siehe Anhang / see attachement)
und habe noch herausgefunden, dass man in undef auch noch etwas(245) machen sollte:
(siehe Anhang / see attachement)
Siehst du das genauso.
Wie kann ich das testen.
Hast du einen Vorschlag.
wie wärs damit :
...
foreach my $aaa ( sort keys %{$modules{Heating_Control}{defptr}} )
{
my $strHCName=$modules{Heating_Control}{defptr}{$aaa}{NAME};
Log 3,"$strHCName ";
}
...
ich habe es eingecheckt - tests waren ok.
prüf mal, ob es funzt.
Hallo Dietmar,
funktioniert perfekt.
Vielen Dank
John
ich habe in HC auf folgende Anforderung hin
Link (http://forum.fhem.de/index.php?topic=12583.msg75684#msg75684)
folgende Erweiterung vorgenommen:
Link (http://forum.fhem.de/index.php?topic=12583.msg75719#msg75719)
Es gibt nun eine allgemeine Funktion Heating_Control_SetAllTemps(), um für alle definierten HC die Temperatur setzen zu lassen. Beispielsweise um aus Ausnahmesituationen oder beim Wechsel von Bedingungen in einen anderen Modus zu wechseln.
Hallo Dietmar,
anscheinend bin ich auf einen Bug im Parsen von Wochentagen gestossen. Der Sonntag wird als Switchingtime 7 erzeugt (und nur bei Helpers angezeigt).
Minimales Beispiel:
fhem> define Heizung_Test dummy
fhem> define HS_Test Heating_Control Heizung_Test Mo-Su|06:00|16.00
fhem> list HS_Test
Internals:
CFGFN
DEF Heizung_Test Mo-Su|06:00|16.00
DEVICE Heizung_Test
NAME HS_Test
NR 241
NTFY_TRIGGERTIME 2013-06-03 10:37:16
PROFILE 1: Monday 06:00 16.00,
PROFILE 2: Tuesday 06:00 16.00,
PROFILE 3: Wednesday 06:00 16.00,
PROFILE 4: Thursday 06:00 16.00,
PROFILE 5: Friday 06:00 16.00,
PROFILE 6: Saturday 06:00 16.00,
STATE waiting...
TYPE Heating_Control
Readings:
2013-06-03 10:37:16 nextUpdate Heute, 10:37:46
2013-06-03 10:37:16 nextValue ???
2013-06-03 10:37:16 state waiting...
Helper:
DESIRED_TEMP_READING desired-temp
SWITCHINGTIMES Mo-Su|06:00|16.00
UNIT °C
Switchingtime:
0:
1:
06:00 16.00
2:
06:00 16.00
3:
06:00 16.00
4:
06:00 16.00
5:
06:00 16.00
6:
06:00 16.00
7:
06:00 16.00
Attributes:
Definiere ich das gleiche aber mit Tagesnummern anstatt Kurznamen, funktioniert es:
fhem> define HS_Test Heating_Control Heizung_Test 1234567|06:00|16.00
fhem> list HS_Test
Internals:
CFGFN
DEF Heizung_Test 1234567|06:00|16.00
DEVICE Heizung_Test
NAME HS_Test
NR 244
NTFY_TRIGGERTIME 2013-06-03 10:39:30
PROFILE 0: Sonntag 06:00 16.00,
PROFILE 1: Montag 06:00 16.00,
PROFILE 2: Dienstag 06:00 16.00,
PROFILE 3: Mittwoch 06:00 16.00,
PROFILE 4: Donnerstag 06:00 16.00,
PROFILE 5: Freitag 06:00 16.00,
PROFILE 6: Samstag 06:00 16.00,
STATE waiting...
TYPE Heating_Control
Readings:
2013-06-03 10:39:30 nextUpdate Heute, 10:40:00
2013-06-03 10:39:30 nextValue ???
2013-06-03 10:39:30 state waiting...
Helper:
DESIRED_TEMP_READING desired-temp
SWITCHINGTIMES 1234567|06:00|16.00
UNIT °C
Switchingtime:
0:
06:00 16.00
1:
06:00 16.00
2:
06:00 16.00
3:
06:00 16.00
4:
06:00 16.00
5:
06:00 16.00
6:
06:00 16.00
Attributes:
Ich nehme an, dass die if-Abfrage in Zeile 173, bzw. genauer die else-Behandlung in Zeile 176 dafür verantwortlich ist, da hier der Sonntag als Tag 7 definiert wird.
if ($low <= $high) {
@subDays = ($low .. $high);
} else {
@subDays = (1 .. $high, $low .. 7);
}
Müsste das nicht folgendermaßen aussehen?
@subDays = (0 .. $high, $low .. 6);
Danke & Gruß
Michael
mit welcher Codeversion hast du verglichen?
Wann hast du zuletzt aktualisiert?
Die interne Darstellung von Wochentagen war von Tobias ürsürünglich von 1-7(Mo-So) eingeführt worden.
Ich habe aus Vereinfachungsgründen auf die interne Perlcodierung 0-6(So-Sa, wie $wday) umgestellt - dann entfallen viele Sonderlocken und alles wird einfacher.
Vielleicht habe ich etwas übersehen.
Hallo Dietmar,
Zitat von: Dietmar63 schrieb am Mo, 03 Juni 2013 16:10mit welcher Codeversion hast du verglichen?
Wann hast du zuletzt aktualisiert?
Die von mir eingesetzte Version entspricht der im SVN trunk, habe vor dem Posting ein Fhem-Update gemacht und danach die Datei gegen einen SVN-checkout gedifft.
ZitatDie interne Darstellung von Wochentagen war von Tobias ürsürünglich von 1-7(Mo-So) eingeführt worden.
Ich habe aus Vereinfachungsgründen auf die interne Perlcodierung 0-6(So-Sa, wie $wday) umgestellt - dann entfallen viele Sonderlocken und alles wird einfacher.
Vielleicht habe ich etwas übersehen.
Ja, ich denke das ist an der Stelle passiert. Da ist noch die Logik mit So = 7 drin.
Danke & Gruß
Michael
Du hast recht.
Die Stelle ist mir durchgerutscht - ich ändere den Code und lade das Modul wieder hoch.
schon geschafft:
Internals:
CFGFN
DEF HeizungKueche Mo-Su|06:00|16.00
DEVICE HeizungKueche
NAME HS_Test
NR 2304
NTFY_TRIGGERTIME 2013-06-03 19:25:47
PROFILE 0: Sunday 06:00 16.00,
PROFILE 1: Monday 06:00 16.00,
PROFILE 2: Tuesday 06:00 16.00,
PROFILE 3: Wednesday 06:00 16.00,
PROFILE 4: Thursday 06:00 16.00,
PROFILE 5: Friday 06:00 16.00,
PROFILE 6: Saturday 06:00 16.00,
STATE waiting...
TYPE Heating_Control
Readings:
2013-06-03 19:25:47 nextUpdate Heute, 19:26:17
2013-06-03 19:25:47 nextValue ???
2013-06-03 19:25:47 state waiting...
Helper:
DESIRED_TEMP_READING desired-temp
SWITCHINGTIMES Mo-Su|06:00|16.00
Switchingtime:
0:
06:00 16.00
1:
06:00 16.00
2:
06:00 16.00
3:
06:00 16.00
4:
06:00 16.00
5:
06:00 16.00
6:
06:00 16.00
Attributes:
Hi Dietmar,
super, Danke für die schnelle Behebung des Problems :-)
Gruß
Michael
schon hochgeladen - prüf bitte, ob es lüppt.
ich habe noch ein wenig mehr geändert.
Hi Dietmar,
Scheint zu tun, zumindest passen die im "list" angezeigten Profile zu meiner Konfiguration (die jetzt wieder lesbarer ist, ich hatte gestern auf die Schnelle das ganze auf Tagesnummern umgestellt).
Also Danke nochmal :-)
Gruß
Michael
Ich hänge mich mal hinten dran.
Kann es sein, das durch das Modul, die Heating_Control desired-temp jetzt dreifach die FHT gesendet wird?
Zitat2013-06-16_20:01:24 FHT_0c23 desired-temp 17.0
2013-06-16_20:01:24 FHT_0c23 desired-temp 21.0
2013-06-16_20:01:24 FHT_0c23 desired-temp 17.0
2013-06-16_20:02:24 FHT_0c23 actuator: 0%
2013-06-16_20:04:20 FHT_0c23 actuator: 0%
2013-06-16_20:05:22 FHT_0c23 desired-temp 17.0
2013-06-16_20:05:22 FHT_0c23 desired-temp 17.0
2013-06-16_20:05:22 FHT_0c23 desired-temp 21.0
2013-06-16_20:06:17 FHT_0c23 actuator: 0%
2013-06-16_20:07:11 FHT_0c23 desired-temp 21.0
2013-06-16_20:07:11 FHT_0c23 desired-temp 17.0
2013-06-16_20:07:11 FHT_0c23 desired-temp 17.0
Ich habe folgendes für das Modul eingegeben:
Zitat## Heizplan ##
### Wohnzimmer ###
define FHT_WZ_modofr Heating_Control FHT_0c23 145|06:00|21 145|22:00|17
attr FHT_WZ_modofr room Wohnzimmer
define FHT_WZ_dimi Heating_Control FHT_0c23 23|06:00|21 23|07:00|17 23|14:00|21 23|22:00|17
attr FHT_WZ_dimi room Wohnzimmer
define FHT_WZ_we Heating_Control FHT_0c23 67|07:00|21 67|23:00|17
attr FHT_WZ_we room Wohnzimmer
###
Ja das kann sein.
Du hast drei Definitionen ohne weitere Bedingung erstellt.
Sie funktionieren unabhängig voneinander!
Zitat von: Dietmar63 schrieb am Mo, 17 Juni 2013 18:55Ja das kann sein.
Du hast drei Definitionen ohne weitere Bedingung erstellt.
Sie funktionieren unabhängig voneinander!
Verstehe ich jetzt nicht.
Was für "Bedingungen" sollte ich denn noch einfügen?
Mach bitte mal ein Muster, von dem wie du das meinst.
jetzt habe ich gesehen, dass du Tagesangaben gemacht hast.
vielleicht hast du eine alte Version geladen - wir hatten einmal Probleme.
Was hast du installiert fhem 5.4?
Kannst du ein update durchführen?
Zitat von: Dietmar63 schrieb am Mo, 17 Juni 2013 23:11jetzt habe ich gesehen, dass du Tagesangaben gemacht hast.
vielleicht hast du eine alte Version geladen - wir hatten einmal Probleme.
Was hast du installiert fhem 5.4?
Kannst du ein update durchführen?
Ich hab mal ein update gemacht.
Jetzt scheint es zu gehen.
thx
Du könntest zum Beispiel alle Zeitpunkte in einem HC zusammenfassen.
Die Angabe der Tage kann per Sa, So, Sa-Fr erfolgen.
Hallo Dietmar,
ich hatte in diesem Beitrag
Link (http://forum.fhem.de/index.php?topic=10011.msg70888#msg70888)
das Thema time_offset angesprochen.
Du meintest Sommer wäre eine gute Zeit für dich darüber nachzudenken.
Hast du darüber nachgedacht ?
Ich kanns aber auch verstehen wenn du der Badhose den Vorzug gibts.
John
Hallo, ich habe das Module Heating Control für mich jetzt entdeckt und schon einiges für meine FHT´s definiert. Nun meine Frage dazu. Da bei mir wochenweise die Zeit anders ist wann ich aufstehe bzw. auch nach Hause komme wäre es toll, wenn ich dem Module Heating Control sagen könnte, ob ich in eine ungerade bzw. geraden Woche bin um für die jeweilige Woche ein eigenes Heizprofil zu erstellen.
Gruß
cerberus
I do not speak german so forgive me to speak english. I am french and I wanted to be able to translate this module in french. I looked at the code and I think it could be adapted this way.
Could you check please and integrate in the SVN if it is correct ?
Thanks a lot
Olivier
# diff -up 98_Heating_Control.pm.bak 98_Heating_Control.pm
--- 98_Heating_Control.pm.bak 2013-10-07 20:32:03.000000000 +0200
+++ 98_Heating_Control.pm 2013-10-07 20:52:05.000000000 +0200
@@ -80,6 +80,7 @@ Heating_Control_Define($$)
my @Wochentage_de = ("Sonntag","Montag","Dienstag","Mittwoch", "Donnerstag","Freitag","Samstag" );
my @Wochentage_en = ("Sunday", "Monday","Tuesday", "Wednesday","Thursday", "Friday", "Saturday");
+ my @Wochentage_fr = ("Dimanche", "Lundi","Mardi", "Mercredi","Jeudi", "Vendredi", "Samedi");
return "invalid Device, given Device <$device> not found" if(!$defs{$device});
@@ -91,6 +92,7 @@ Heating_Control_Define($$)
for (my $w=0; $w<@Wochentage_de; $w++) {
delete($hash->{"PROFILE ".($w).": ".$Wochentage_de[$w]}) if($hash->{"PROFILE ".($w).": ".$Wochentage_de[$w]});
delete($hash->{"PROFILE ".($w).": ".$Wochentage_en[$w]}) if($hash->{"PROFILE ".($w).": ".$Wochentage_en[$w]});
+ delete($hash->{"PROFILE ".($w).": ".$Wochentage_fr[$w]}) if($hash->{"PROFILE ".($w).": ".$Wochentage_fr[$w]});
}
for(my $i=0; $i<@a; $i++) {
@@ -116,8 +118,9 @@ Heating_Control_Define($$)
$hash->{helper}{COMMAND} = $conditionOrCommand;
}
- my $daysRegExp = "(mo|di|mi|do|fr|sa|so|tu|we|th|su)";
+ my $daysRegExp = "(mo|di|mi|do|fr|sa|so|tu|we|th|su|lu|ma|me|je|ve)";
my $daysRegExp_en = "(tu|we|th|su)";
+ my $daysRegExp_fr = "(lu|ma|me|je|ve)";
my %dayNumber=();
my $idx = 0;
@@ -128,8 +131,12 @@ Heating_Control_Define($$)
foreach my $day ("su","mo","tu","we","th","fr","sa") {
$dayNumber{$day} = $idx; $idx++;
}
+ $idx = 0;
+ foreach my $day ("di","lu","ma","me","je","ve","sa") {
+ $dayNumber{$day} = $idx; $idx++;
+ }
- my (@st, @days, $daylist, $time, $para, $englisch);
+ my (@st, @days, $daylist, $time, $para, $englisch, $french);
for(my $i=0; $i<@switchingtimes; $i++) {
@st = split(/\|/, $switchingtimes[$i]);
@@ -160,6 +167,7 @@ Heating_Control_Define($$)
my $day = substr($daylist,0,2,"");
my $del = substr($daylist,0,1,"");
$englisch = ($day =~ m/^($daysRegExp_en)$/g);
+ $french = ($day =~ m/^($daysRegExp_fr)$/g);
my @subDays;
if ($oldDel eq "-" ){
# von bis Angabe: Mo-Di
@@ -203,6 +211,8 @@ Heating_Control_Define($$)
my $rWochentage;
if ($englisch) {
$rWochentage = \@Wochentage_en;
+ } elsif ($french) {
+ $rWochentage = \@Wochentage_fr;
} else {
$rWochentage = \@Wochentage_de;
}
Hallo,
wie kann die HC neu starten, sodass die Werte neu abgeglichen werden.
Habe folgende Code
define HC_WZ Heating_Control Heiz_WZ_ClimRT_tr 12345|06:00|22 67|06:30|22 12345|20:00|18 67|21:00|18 (ReadingsVal("Verreist", "state", "Ja") eq "Nein")
attr HC_WZ room Heizung
define HC_Verreist notify Verreist:Ja {fhem ("set Heiz_WZ_ClimRT_tr desired-temp 16;; set Heiz_AZ_ClimRT_tr desired-temp 16") }
Wenn der dummy Verreist wieder auf Nein gestellt wird, möchte ich die "normalen" Werte zum Ventil schicken.
Wie geht das?
Gruß Otto
Hallo,
ich habe es gefunden (http://forum.fhem.de/index.php?topic=12523.msg79237#msg79237):
define HeizStatus2 notify Heizung:.* {Heating_Control_SetAllTemps()}
Gruß Otto
Improvments to Heating_Control an WeekdayTimer:
- french language supported by autdetection
- param now supports a second parameter like on-for-timer:3456
- default switchparameter can be adjusted more elaborate
this may cause problems. If you want an other default behaviour - please contact me.
my %modifier = ("MAX" => "desiredTemperature",
"FHT" => "desired-temp",
"FS20" => "",
"HM-CC-VD" => "desired-temp",
"HM-CC-TC" => "desired-temp" );
Guten Abend!
Habe seit Heute Update diese Fehlermeldung:
2013.10.17 19:06:05 2: CUL_HM set WaschKeller desired-temp 22.0
Use of uninitialized value $n in hash element at fhem.pl line 3001.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_Heating_Control.pm line 318.
2013.10.17 19:08:08 3: set Wz_Heizung1 21.0 : Unknown argument 21.0, choose one of burstXmit clear:readings,register,rssi,msgEvents desired-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 getConfig getRegRaw getSerial pair peerBulk raw regBulk regSet reset sign:on,off statusRequest sysTime unpair
2013.10.17 19:08:08 3: Unknown argument 21.0, choose one of burstXmit clear:readings,register,rssi,msgEvents desired-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 getConfig getRegRaw getSerial pair peerBulk raw regBulk regSet reset sign:on,off statusRequest sysTime unpair
Er stellt auch bei keiner der "Heating_Control define" die Temp. am Regler um.
Mfg Steffen
Kannst du mir sagen, welcher TYPE in den Internals deines Geräts mit dem Namen Wz_Heizung1 angezeigt wird.
Ich vermute, dass du eventuell HM im Einsatz hast. Ich leider nicht, so kann ich diese Steuerungen leider nicht testen und war auf Vermutungen angewiesen und lag leider daneben.
Kommt dein TYPE in der folgenden Tabelle vor?
my %modifier = ("MAX" => "desiredTemperature",
"FHT" => "desired-temp",
"FS20" => "",
"HM-CC-VD" => "desired-temp",
"HM-CC-TC" => "desired-temp" );
Zitat von: Dietmar63 am 17 Oktober 2013, 21:11:14
Kannst du mir sagen, welcher TYPE in den Internals deines Geräts mit dem Namen Wz_Heizung1 angezeigt wird.
Ich vermute, dass du eventuell HM im Einsatz hast. Ich leider nicht, so kann ich diese Steuerungen leider nicht testen und war auf Vermutungen angewiesen und lag leider daneben.
Kommt dein TYPE in der folgenden Tabelle vor?
my %modifier = ("MAX" => "desiredTemperature",
"FHT" => "desired-temp",
"FS20" => "",
"HM-CC-VD" => "desired-temp",
"HM-CC-TC" => "desired-temp" );
Hallo!
"TYPE: CUL_HM", hoffe hilft dir weiter und danke für die schnelle Antwort!
Mfg Steffen
Probier es nochmals nach einem update - der Fehler sollte behoben sein.
Danke, Fehler ist behoben!
Gruß Otto
Hallo Dietmar,
hier noch einmal eine späte Huldigung.
Nachdem ich dich mit einigen Fragen zum Heating Control löchern musste läuft das Modul mit verschiedenen Profilen bei mir seit Monaten PERFEKT !!.
Genauso hatte ich mir das immer gewünscht um mit einem Parameter (Gäste Ja/Nein, Urlaub Ja/Nein) ohne viel Aufwand der ganzen FHT80 Umprogrammierung die Heizungsregler einfach zu kontrollieren.
Für den "Notfall" eines FHEM Gesamtabsturzes (z.B. Abrauchen der Fritzbox) habe ich dann noch Backupheizprofile in den FHTs, die nach Umstellung auf Automatik Modus den Zeitraum überbrücken können, bis FHEM wieder läuft.
Vielen Dank für dieses super Modul !!
Gruss
Holger
Hallo, ich finde das Module auch super und habe schon einiges damit umgesetzt.
@AnonymousHolger Mit den Schaltern für verschiedene Heizungsparameter finde ich eine gute Idee. Wie hast du das ganze umgesetzt? Wie machst du das mit z.B. zu Hause ja und Abwesend ja, setzt du zu Hause ja dann Abwesend automatisch auf nein bzw. oder auch andere Heizparameter?
Was ich noch umsetzten wollte ist zwischen Früh und Spätschicht zu unterscheiden. Da bei mir wochenweise Früh und Spätschicht wechselt wollte ich dafür auch je ein eigenes Heizprofil erstellen. Ich dachte daran auch hier einen Dummy zu definieren der z.B. Montags prüft ob der Dummy auf Früh oder Spät steht und dann entsprechend umschaltet.
Hier mein erster Code dazu. Ich weiß aber nicht ob das nicht eine Schleife ergibt. Hat jemand eine gute Idee wie ich abhängig vom vorherigen Status zu Beginn der Woche jeweils den Status wechsel?
define HP_Schicht dummy
attr HP_Schicht Schicht
attr HP_Schicht webCmd Fruehschicht:Spaetschicht
attr HP_Schicht room Heizung
attr HP_Schicht group Heizparameter
define nHP_Schicht_S notify HP_Schicht {\
if(( Value("HP_Schicht") eq "Fruehschicht") && ($wday == 1)) {\
fhem("set HP_Schicht mode Spaetschicht");;\
}\
}
define nHP_Schicht_F notify HP_Schicht {\
if(( Value("HP_Schicht") eq "Spaetschicht") && ($wday == 1)) {\
fhem("set HP_Schicht mode Fruehschicht");;\
}\
}
Gruß
cerberus
Ich habe drei Profile für jeden Raum.
Das Schalten funktioniert bei mir nicht automatisch, sondern per Hand. Dazu habe ich ein dummy definiert, das per Weboberfläche drei Zustände einnehmen kann:
Aus,An,Übergangszeit.
In der Bedingung am Ende der HC-Definitionen rufe ich eine Perlfunktion auf, die true oder false zurückliefert und u. a. den Inhalt des dummys auswertet.
So könntest du es auch erst einmal machen.
Wenn du dann noch eine Automatik Früh-/Spätschicht willst, kannst du das Calendermdoul verwenden, und damit das dummy ändern: früh/spät/nacht; dann sogar änderbar über das Handy oder PC.
Allgemein besteht der Wunsch, dass die Angaben für die Schaltzeiten flexibler gestaltet werden sollten.
Zur Zeit ist nur die Angabe in der Form HH:MM möglich.
In Kürze werde ich die beiden Module so erweitern/einchecken, dass es möglich ist eine beliebige Funktion u.a. auch sunrise_abs() für die Ermittlung der Schaltzeit zu nutzen. Die Funktion muss eine Zeit der Form HH:MM bzw. HH:MM:SS liefern. Die Schaltzeiten werden jede Nacht gegen 00:10 Uhr für den jeweiligen Tag neu ermittelt(damit z. Bsp. sunset richtig rechnet). Die Entwicklung habe ich abgeschlossen. Ich teste es noch ausgiebig.
Möglich wird dann beispielsweise folgendes sein:
define wdt1 WeekdayTimer Brunnen 123|{sunrise_abs()}|off 4567|{sunset_abs()}|on
define wdt1 Heating_Control Brunnen 123|{sunrise_abs()}|off 4567|{sunset_abs()}|on
define wdt1 WeekdayTimer Brunnen 123|{myFunction()}|off 4567|{myFunction()}|on
define wdt1 Heating_Control Brunnen 123|{myFunction()}|off 4567|{myFunction()}|on
Weitere Flexibilität ist gewünscht bei der Angabe der Tage an denen die Schaltzeit jeweils gelten soll.
Folgenden Vorschlag würde ich machen:
Ich führe die symbolischen Konstanten $we und !$we ein. $we umfasst die Tage Samstag, Sonntag und die Feiertage. !$we definert das Gegenteil, also Montag bis Freitag.
Dann sind folgende Definitionen für eine Schaltung möglich:
di-mi,$we|15:00|on-for-timer:20 # Dienstag, Mittwoch und am Wochenende+Feiertage
123,$we|{sunset_abs()}|on # Montag-Mittwoch und am Wochenende+Feiertage
!$we,$we|{sunrise_abs()}|on # Jeder Tag.
$we|15:00:05|13 # Am Wochenende und an Feiertagen
!$we|{sunrise("real","16:00","17:00")}|on-for-timer:20 # Montag-Freitag
Wie wäre das?
Hallo Dietmar, das mit dem !$we für das Gegenteil vom Wochenende irritiert mich und würde meiner Meinung nach zur Verwirrung führen.
Ein Frage noch dazu. Wo definiere ich welcher Tag dann ein Feiertag ist?
Gruß
cerberus
attr global holiday2we Niedersachsen
...\fhem\FHEM\Niedersachsen.holiday
Wenn !$we verwirrt kann ich es auch fort lassen.
Zitat von: Dietmar63 am 21 Oktober 2013, 21:46:16
Ich führe die symbolischen Konstanten $we und !$we ein. $we umfasst die Tage Samstag, Sonntag und die Feiertage. !$we definert das Gegenteil, also Montag bis Freitag.
Wozu bei we das Dollarzeichen, mo-so haben auch keins;)
Ich denke das Modul ist gerade für Nichtprogrammierer gedacht und die müssen nicht wissen, wie Variablen in Perl aussehen. Und die Frage nach dem Ausrufungszeichen hat auch nicht lange auf sich warten lassen - nicht jeder hat mal C programmieren gelernt.
Gruß
Damian
Hallo Dietmar,
ich finde die Idee super und denke mit einer Funktion und den Konstanten ist alles abgedeckt.
Gruß Otto
Hallo Dietmar,
wenn Du in $we Samstag, Sonntag, und Feiertage zusammenfassen willst, dann tut man sich bei Konfigurationen schwer, in denen der Samstag als normaler Werktag behandelt werden soll. Wie wäre es mit einem Attribut, auf welchen Tag ein Feiertag gemappt werden soll, z.B. wenn ein Feiertag wie ein Sonntag behandelt werden soll:
attr Heating_Control holidayMap So
Oder evtl. ein spezieller Feiertagname "Ft" oder "Hy" ?
Gruß
Helmut
Hallo Cerberus,
hier mal mein "Heating_Control.cfg" (eingebunden mit Include in die fhem.cfg).
Ist noch nicht komplett fertig, da z.B. der Paraeter Jahreszeit nicht ausgewertet wird, und es sicherlich auch noch einiges an Verbesserungspotential gibt. Aber soweit hab ich es mit Dietmars Unterstützung erst einmal geschafft. Aufgrund des noch guten Wetters ist hier im Moment nicht so viel Optimierungsbedarf. Das ändert sich sicherlich sobald die Tage kälter werden.
Dann werde ich das sicherlich noch ein wenig überarbeiten ...
Sorry für die späte Antwort, war ein paar Tage offline.
Gruss
Holger
#manuelles aufrufen der Funktion im FHEM Fenster mit <trigger FHT_To_Manual>
#damit werden dann alle FHTs auf Manual Status umgestellt
define FHT_To_Manual notify FHT_To_Manual { \
my @@fhts=devspec2array("TYPE=FHT");; \
foreach(@@fhts) { \
fhem ("set ".$_." mode manual");; \
} \
}
attr FHT_To_Manual room 5_SYSTEM
define FHT_log_desired_temp notify FHT_log_desired_temp { \
my @@fhts=devspec2array("TYPE=FHT");; \
foreach(@@fhts) { \
addLog("$_","desired-temp");; \
} \
}
attr FHT_log_desired_temp room hidden
define addFHTlog_midnight1 at *23:59 trigger FHT_log_desired_temp
attr addFHTlog_midnight1 room hidden
define addFHTlog_midnight2 at *00:01 trigger FHT_log_desired_temp
attr addFHTlog_midnight2 room hidden
define addFHTlog_al2hours at +*02:00:00 trigger FHT_log_desired_temp
attr addFHTlog_al2hours room hidden
### Heizungsprofil(Jahreszeit(Sommer,Uebergang,Winter), WochenEnd_Feiertag(0,1), Gaeste(Ja,Nein), Homeoffice(Ja,Nein), zuHause (Ja,Nein), Abwesend (Ja,Nein)
############ Start OG GaesteZimmer & Bad Einstellung bei Nutzung (Gaeste = JA) oder nicht (Gaeste = Nein)
####### Gäste & nichtAbwesend = "G"
define FHT_OG_Bad_Control_G Heating_Control FHT_OG_Bad 07:00|21.00 10:30|18.0 18:00|21.0 22:30|18.0 (Heizungsprofil(undef, undef, "Ja", undef, undef, "Nein", "Profil_OG_Bad_Gaeste"))
attr FHT_OG_Bad_Control_G event-on-update-reading desired-temp
attr FHT_OG_Bad_Control_G group HEIZUNG_CONTROL
attr FHT_OG_Bad_Control_G room 1_HEIZUNG
define FHT_OG_SchlafZ_Control_G Heating_Control FHT_OG_SchlafZ 07:30|21.0 09:30|18.0 19:00|21.0 22:30|18.0 (Heizungsprofil(undef, undef, "Ja", undef, undef, "Nein", "Profil_OG_SchlafZ_Gaeste"))
attr FHT_OG_SchlafZ_Control_G event-on-update-reading desired-temp
attr FHT_OG_SchlafZ_Control_G group HEIZUNG_CONTROL
attr FHT_OG_SchlafZ_Control_G room 1_HEIZUNG
######## keineGäste & nichtAbwesend = "nG"
define FHT_OG_Bad_Control_nG Heating_Control FHT_OG_Bad 05:00|14.0 18:10|14.0 (Heizungsprofil(undef, undef, "Nein", undef, undef, "Nein", "Profil_OG_Bad_keineGaeste"))
attr FHT_OG_Bad_Control_nG event-on-update-reading desired-temp
attr FHT_OG_Bad_Control_nG group HEIZUNG_CONTROL
attr FHT_OG_Bad_Control_nG room 1_HEIZUNG
define FHT_OG_SchlafZ_Control_nG Heating_Control FHT_OG_SchlafZ 05:05|14.0 18:10|14.0 (Heizungsprofil(undef, undef, "Nein", undef, undef, "Nein", "Profil_OG_SchlafZ_keineGaeste"))
attr FHT_OG_SchlafZ_Control_nG event-on-update-reading desired-temp
attr FHT_OG_SchlafZ_Control_nG group HEIZUNG_CONTROL
attr FHT_OG_SchlafZ_Control_nG room 1_HEIZUNG
############# Ende OG GaesteZimmer & Bad
############ Start OG Arbeitszimmer mit und ohne Homeoffice Definition
####### Homeoffice & nichtAbwesend = "H"
define FHT_OG_AZ_Control_H Heating_Control FHT_OG_AZ 07:35|21.5 18:00|14.0 (Heizungsprofil(undef, undef, undef, "Ja", undef, "Nein", "Profil_OG_AZ_HomeOffice"))
attr FHT_OG_AZ_Control_H event-on-update-reading desired-temp
attr FHT_OG_AZ_Control_H group HEIZUNG_CONTROL
attr FHT_OG_AZ_Control_H room 1_HEIZUNG
####### kein Homeoffice & nichtAbwesend = "nH"
define FHT_OG_AZ_Control_nH Heating_Control FHT_OG_AZ 05:10|14.0 18:10|14.0 (Heizungsprofil(undef, undef, undef, "Nein", undef, "Nein", "Profil_OG_AZ_keinHomeOffice"))
attr FHT_OG_AZ_Control_nH event-on-update-reading desired-temp
attr FHT_OG_AZ_Control_nH group HEIZUNG_CONTROL
attr FHT_OG_AZ_Control_nH room 1_HEIZUNG
############# Ende OG GaesteZimmer & Bad
############ Start UG Definitionen
####### Badezimmer Wochentag & nichtAbwesend = WT
define FHT_UG_Bad_Control_WT Heating_Control FHT_UG_Bad 06:30|21.5 07:30|18.0 18:30|21.5 19:30|18.0 (Heizungsprofil(undef, 0, undef, undef, undef, "Nein", "Profil_UG_Bad_Wochentag"))
attr FHT_UG_Bad_Control_WT group HEIZUNG_CONTROL
attr FHT_UG_Bad_Control_WT room 1_HEIZUNG
####### Badezimmer Wochenend/Feiertag & nichtAbwesend = WE
define FHT_UG_Bad_Control_WE Heating_Control FHT_UG_Bad 07:30|21.5 08:30|18.0 19:30|21.5 20:30|18.0 (Heizungsprofil(undef, 1, undef, undef, undef, "Nein", "Profil_UG_Bad_Wochenend"))
attr FHT_UG_Bad_Control_WE group HEIZUNG_CONTROL
attr FHT_UG_Bad_Control_WE room 1_HEIZUNG
####### Kueche nichtAbwesend
define FHT_UG_Kueche_Control Heating_Control FHT_UG_Kueche 06:30|21.0 07:30|18.0 18:30|20.5 20:30|18.0 (Heizungsprofil(undef, undef, undef, undef, undef, "Nein", "Profil_UG_Kueche"))
attr FHT_UG_Kueche_Control group HEIZUNG_CONTROL
attr FHT_UG_Kueche_Control room 1_HEIZUNG
####### KiZi Wochentag & nichtAbwesend = WT
define FHT_UG_KiZi_Control_WT Heating_Control FHT_UG_KiZi 06:30|22.0 08:00|18.0 17:00|22.0 20:30|18.0 (Heizungsprofil(undef, 0, undef, undef, "Nein", "Nein", "Profil_UG_KiZi_Wochentag"))
attr FHT_UG_KiZi_Control_WT group HEIZUNG_CONTROL
attr FHT_UG_KiZi_Control_WT room 1_HEIZUNG
####### KiZi Wochentag + ZuHause & nichtAbwesend = WTH
define FHT_UG_KiZi_Control_WTH Heating_Control FHT_UG_KiZi 06:30|21.0 20:30|18.0 (Heizungsprofil(undef, 0, undef, undef, "Ja", "Nein", "Profil_UG_KiZi_WochentagZuHause"))
attr FHT_UG_KiZi_Control_WTH group HEIZUNG_CONTROL
attr FHT_UG_KiZi_Control_WTH room 1_HEIZUNG
####### KiZi WochenEnd/Feiertag & nichtAbwesend = WE
define FHT_UG_KiZi_Control_WE Heating_Control FHT_UG_KiZi 06:30|22.0 21:00|18.0 (Heizungsprofil(undef, 1, undef, undef, undef, "Nein","Profil_UG_KiZi_Wochenend"))
attr FHT_UG_KiZi_Control_WE group HEIZUNG_CONTROL
attr FHT_UG_KiZi_Control_WE room 1_HEIZUNG
####### SchlafZ & nichtAbwesend
define FHT_UG_SchlafZ_Control Heating_Control FHT_UG_SchlafZ 06:30|21.0 08:00|18.0 (Heizungsprofil(undef, undef, undef, undef, undef, "Nein","Profil_UG_SchlafZ"))
attr FHT_UG_SchlafZ_Control group HEIZUNG_CONTROL
attr FHT_UG_SchlafZ_Control room 1_HEIZUNG
####### WohnZ Wochentag & nichtAbwesend & nicht ZuHause= WT
define FHT_UG_WohnZ_Control_WT Heating_Control FHT_UG_WohnZ 06:30|23.0 07:00|23.0 08:30|23.0 16:30|23.0 22:30|18.0 (Heizungsprofil(undef, 0, undef, undef, "Nein", "Nein", "Profil_UG_WZ_Wochentag"))
attr FHT_UG_WohnZ_Control_WT group HEIZUNG_CONTROL
attr FHT_UG_WohnZ_Control_WT room 1_HEIZUNG
####### WohnZ Wochentag & nichtAbwesend & nicht ZuHause= WTH
define FHT_UG_WohnZ_Control_WTH Heating_Control FHT_UG_WohnZ 06:30|23.0 07:00|23.0 22:30|18.0 (Heizungsprofil(undef, 0, undef, undef, "Ja", "Nein", "Profil_UG_WZ_WochentagZuHause"))
attr FHT_UG_WohnZ_Control_WTH group HEIZUNG_CONTROL
attr FHT_UG_WohnZ_Control_WTH room 1_HEIZUNG
####### WohnZ Wochenend/Feiertag & nichtAbwesend = WE
define FHT_UG_WohnZ_Control_WE Heating_Control FHT_UG_WohnZ 06:30|23.0 07:00|23.0 22:30|18.0 (Heizungsprofil(undef, 1, undef, undef, undef, "Nein", "Profil_UG_WZ_Wochenend"))
attr FHT_UG_WohnZ_Control_WE group HEIZUNG_CONTROL
attr FHT_UG_WohnZ_Control_WE room 1_HEIZUNG
############ Start Abwesenheits Definition für alle Heizkörper
define FHT_OG_Bad_Control_OFF Heating_Control FHT_OG_Bad 00:01|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_OG_Bad_Abwesend"))
attr FHT_OG_Bad_Control_OFF group HEIZUNG_CONTROL
attr FHT_OG_Bad_Control_OFF room 1_HEIZUNG
define FHT_OG_SchlafZ_Control_OFF Heating_Control FHT_OG_SchlafZ 00:01|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_OG_SchlafZ_Abwesend"))
attr FHT_OG_SchlafZ_Control_OFF group HEIZUNG_CONTROL
attr FHT_OG_SchlafZ_Control_OFF room 1_HEIZUNG
define FHT_OG_AZ_Control_OFF Heating_Control FHT_OG_AZ 00:01|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_OG_AZ_Abwesend"))
attr FHT_OG_AZ_Control_OFF event-on-update-reading desired-temp
attr FHT_OG_AZ_Control_OFF group HEIZUNG_CONTROL
attr FHT_OG_AZ_Control_OFF room 1_HEIZUNG
define FHT_UG_Bad_Control_OFF Heating_Control FHT_UG_Bad 00:02|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_UG_Bad_Abwesend"))
attr FHT_UG_Bad_Control_OFF group HEIZUNG_CONTROL
attr FHT_UG_Bad_Control_OFF room 1_HEIZUNG
define FHT_UG_Kueche_Control_OFF Heating_Control FHT_UG_Kueche 00:02|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_UG_Kueche_Abwesend"))
attr FHT_UG_Kueche_Control_OFF group HEIZUNG_CONTROL
attr FHT_UG_Kueche_Control_OFF room 1_HEIZUNG
define FHT_UG_KiZi_Control_OFF Heating_Control FHT_UG_KiZi 00:02|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_UG_KiZi_Abwesend"))
attr FHT_UG_KiZi_Control_OFF group HEIZUNG_CONTROL
attr FHT_UG_KiZi_Control_OFF room 1_HEIZUNG
define FHT_UG_SchlafZ_Control_OFF Heating_Control FHT_UG_SchlafZ 00:03|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_UG_SchlafZ_Abwesend"))
attr FHT_UG_SchlafZ_Control_OFF group HEIZUNG_CONTROL
attr FHT_UG_SchlafZ_Control_OFF room 1_HEIZUNG
define FHT_UG_WohnZ_Control_OFF Heating_Control FHT_UG_WohnZ 00:03|14 (Heizungsprofil(undef, undef, undef, undef, undef, "Ja", "Profil_UG_WohnZ_Abwesend"))
attr FHT_UG_WohnZ_Control_OFF group HEIZUNG_CONTROL
attr FHT_UG_WohnZ_Control_OFF room 1_HEIZUNG
define ProfileTriggerJZ notify JahresZeit:.* {Heating_Control_SetAllTemps()}
attr ProfileTriggerJZ group HEIZUNG_CONTROL_TRIGGER
attr ProfileTriggerJZ room hidden
define ProfileTriggerG notify Gaeste:.* {Heating_Control_SetAllTemps()}
attr ProfileTriggerG group HEIZUNG_CONTROL_TRIGGER
attr ProfileTriggerG room hidden
define ProfileTriggerHO notify HomeOffice:.* {Heating_Control_SetAllTemps()}
attr ProfileTriggerHO group HEIZUNG_CONTROL_TRIGGER
attr ProfileTriggerHO room hidden
define ProfileTriggerZH notify ZuHause:.* {Heating_Control_SetAllTemps()}
attr ProfileTriggerZH group HEIZUNG_CONTROL_TRIGGER
attr ProfileTriggerZH room hidden
define ProfileTriggerAW notify Abwesend:.* {Heating_Control_SetAllTemps()}
attr ProfileTriggerAW group HEIZUNG_CONTROL_TRIGGER
attr ProfileTriggerAW room hidden
define JahresZeit dummy
attr JahresZeit group HEIZUNGPARAMETER
attr JahresZeit icon icoTermHaus
attr JahresZeit room 1_HEIZUNG
attr JahresZeit webCmd Sommer:Uebergang:Winter
#attr JahresZeit sortby 04
define Gaeste dummy
attr Gaeste group HEIZUNGPARAMETER
attr Gaeste icon icoTermHaus
attr Gaeste room 1_HEIZUNG
attr Gaeste webCmd Ja:Nein
#attr Gaeste sortby 03
define HomeOffice dummy
attr HomeOffice group HEIZUNGPARAMETER
attr HomeOffice icon icoTermHaus
attr HomeOffice room 1_HEIZUNG
attr HomeOffice webCmd Ja:Nein
#attr HomeOffice sortby 02
define ZuHause dummy
attr ZuHause group HEIZUNGPARAMETER
attr ZuHause icon icoTermHaus
attr ZuHause room 1_HEIZUNG
attr ZuHause webCmd Ja:Nein
#attr ZuHause sortby B01
define Abwesend dummy
attr Abwesend group HEIZUNGPARAMETER
attr Abwesend icon icoTermHaus
attr Abwesend room 1_HEIZUNG
attr Abwesend webCmd Ja:Nein
#attr Abwesend sortby B05
Ich Gegensatz zu dir bin ich der Meinung, dass es fast unmöglich ist fhem sinnvoll ohne Perlkenntnisse zu betreiben.
Jeder der es nutzt muss sich irgendwann damit auseinandersetzen - wenn ich nur an die vielen notify direkt in der fhem.cfg denke mit den Schrägstrichen an Ende der Zeilen. Wer Readings auswerten will muss ReadingsVal aufrufen ...
Meine Überlegung ging dahin, dass nahezu jeder die Variable $we kennen müsste - ich kann mich aber täuschen. Ich wollte deshalb die gleiche Logik für diese Neuerung verwenden. Es sollte alles gleich aussehen und auch gleich funktionieren.
Mit Fe habe ich noch ein Problem: HC und WD sind bald mehrsprachig(de,fr,en): dann müßte ich für jede Sprache den Wert Fe ergänzen. - Deshalbe $we - auch wenn es da Überschneidungen mit Sa, So ... geben würde.
Ich aber offen für weitere Anregungen.
Wenn man an dieser Stelle, wo $we steht, eine beliebige globale Variable einsetzen könnte, dann gebe ich dir gerne Recht - im anderen Fall könnte es eher verwirrend sein, einen Pseudo-Variablennamen zu verwenden.
Gruß
Damian
Hallo zusammen,
Heating_Control ändert die Temperatur wie programmiert - aber auch, wenn ein Fenster geöffnet ist. Kann man Heating_Control so parametrieren, dass die Temperatur erst geändert wird, nachdem das Fenster wieder geschlossen ist?
Saludos,
Lutz
das kannst du doch den fht beibringen
Hallo Dietmar,
Zitatdas kannst du doch den fht beibringen
Ich habe die HM-CC-RT-DN verbaut und finde dort in den Readings u.a.
ZitatR-winOpnTemp 12 C
Ich hätte nun erwartet, dass der Thermostat nun auf 12° bleibt bis das Fenster geschlossen ist und nicht vorher auf die neue Temperatur von Heating-Control geht.
Leider reicht meine kurze Erfahrung mit FHEM nicht, es meinen Thermostaten selber beizubringen - falls dies bei den RTs überhaupt möglich ist?
Hallo Lutz
ZitatIch hätte nun erwartet, dass der Thermostat nun auf 12° bleibt bis das Fenster geschlossen ist und nicht vorher auf die neue Temperatur von Heating-Control geht.
Leider reicht meine kurze Erfahrung mit FHEM nicht, es meinen Thermostaten selber beizubringen - falls dies bei den RTs überhaupt möglich ist?
Ich habe dieselbe Erfahrung bei den Max-Thermostaten gemacht. Man kann bei "OpenWindow" tatsächlich den aktuellen Sollwert von "Open Window Temperature" mit einem neuen Sollwert überschreiben.
Da das HeatingControl nichts von Fensterkontakten weiss, macht es genau das, wenn die Sollwertänderung in den Zeitraum des offenen Fensters fällt.
Ich habe in den TemperaturScanner für MaxThermostate folgende Lösung implementiert:
- HeatingControl setzt niemals direkt einen Sollwert, sondern indirekt über eine spezielles Perl-Skript
- Das Skript entscheidet, ob der Wert sofort ausgegeben werden kann oder bei offenen Fenster gemerkt werden muss
- Ist letzteres der Fall, wartet es, bis das Fenster wieder geschlossen ist und führt dann den gemerkten Sollwert aus
@Dietmar
Ich nutze dein Modul sehr intensiv und läuft absolut zufriedenstellend. Besten Dank nochmal dafür.
HeatingControl wird vermutlich sehr häufig mit Heizungsthermostaten eingesetzt. (bei mir ist das so)
Fensterkontakte sind mittlerweile integraler Bestandteil der Systeme.
Für die einfache Anwendung wäre eine allgemeingültige Lösung (wie skizziert) integriert in HeatingControl von großem Nutzen.
John
Hallo John,
bzgl. der Fensterkontakte kann ich Dir nur zustimmen. Ich beobachte Heating Control jetzt auch seit Kurzem, konnte mich aber u.a. aus diesem Grund bisher nicht für einen Einsatz entscheiden. Meine Thermostate laufen deshalb noch auf AUTO mit nur manuellem Eingriff. Ich bin aber dran hier noch zu optimieren, bevor die Heizperiode richtig anfängt. Das wird wohl nicht mehr lange auf sich warten lassen.
Gruß
Veit
Ich habe keine Fensterkontakte im Einsatz, deshalb ist dieses Problem auch bisher nicht auf meinem Radarschirm gewesen.
Meinen FS20-FHT kann ich einen Fensterkontakt bekannt machen, dann berücksichtigt dieser selbständig den Zustand des Fensters.
Viel Energie kann man meiner Meinung nach nicht damit sparen, deshalb habe ich auch nicht einmal die Ambitionen gehabt meine zwei Fensterkontakte überhaupt anzuschließen. Wenn das Fenster offen ist, geht der größte Verlust an Energie mit dem Austausch der Luft einher - das kann man nicht verhindern, indem man den Heizkörper herunterfährt, meist ist er zwar heiß,er verliert aber sicherlich sehr langsam die Energie - Es sei denn ihr lüftet stundenlang.
Ich mag daneben liegen mit meiner Einschätzung, aber so sehe ich es nun einmal.
Was passiert bei Eurer Lösung wenn während einer längeren Heizperiode (6:30|21° 18:30|17°) das Fenster geöffnet wird? Wer schaltet dann? Ich habe es so verstanden, dass der Heizwert von HC nur dann nicht durchgereicht wird, wenn HC schalten soll und HC oder das Script feststellt, dass das Fenster geöffnet ist.
Ich würde folgendes machen - große Lösung:
Dein Script könnte man in ein Modul verwandeln, dass wie mein FHT(FS20) funktioniert. Es ist für die Kommunikation mit den HeizkörperThermostaten zuständig. Es müsste wie die FHT regelmäßig nachsehen, ob ein Fenster offen ist, und die Fensteroffentemperatur einstellen. HC kommuniziert dann nicht mehr direkt mit den HeizkörperThermostaten, sondern mit den virtuellen FHT.
Das Modul PID macht meiner Meinung nach so etwas ähnliches.
Threshold ist auch ein Kandidat für diese Aufgabe.
Diese Module könnten als Vorlage für das neue Modul dienen, wenn sie nicht sogar direkt verwendet werden können.
kleine Lösung:
Eine andere Möglichkeit könnte darin zu bestehen das Problem mit zwei notify zu lösen.
Mehrere notify lauschen auf Fenster offen:
define notify FensterKüche:offen { set HeizungKüche desired-temp 15 }
define notify FensterWohnen:offen { set HeizungWohnen desired-temp 15 }
ein notify schaltet wieder über HC die Solltemperatur ein:
define notify Fenster.*:geschlossen { {Heating_Control_SetAllTemps()} }
Ich habe diese zwei notify angelegt:
define f1 notify FensterWohnen:offen set HeizungWohnen desired-temp 15
define fa notify Fenster.*:geschlossen {Heating_Control_SetAllTemps()}
und mit trigger ... getestet, ob es funktioniert - und siehe da es klappt!
Ich müßt also nur die genaue Definition Eurer Fensterkontakte erfassen und hoffen, dass die Readings feuern.
Hallo Dietmar,
das wird so bei den modernen Thermostaten nicht funktionieren:
FesterkontaktDer ist direkt gepaart mit dem Thermostat. Das Thermostat wird ohne Zutun von FHEM auf die WindowOpen-Temperature gehen
und reagiert also direkt auf das Signal vom Fensterkontakt.
Wir haben nur dann ein Problem, wenn in dieser Phase das HeatingControl einen neuen Sollwert setzt.
Dann macht das Thermostat auf und wir blasen die Wärme zum Fenster raus.
Aufgabe wäre: den neuen Sollwert zum Setzen vormerken aber nicht wirklich setzen.
Temperatur wiederherstellen{Heating_Control_SetAllTemps()Das machen die modernen Thermostate auch selber, in Abhängigkeit vom Fensterkontakt.
Ausserdem würden wir damit alle Credits verbraten bei 8+x Thermostaten dauert das ewig.
Aufgabe wäre: den gemerkten Sollwert, nach Schliessen des Fensters nun verzögert ausführen und nur für das betroffene Thermostat.
ZitatDas Modul PID macht meiner Meinung nach so etwas ähnliches.
Der Regler ist ja schon komplett in den modernen Thermostaten integriert.
Ausserdem ist der PID derzeit eine Baustelle wie der "Berliner Flughafen". Er ist einfach noch nicht zu gebrauchen.
John
ZitatFesterkontakt
Der ist direkt gepaart mit dem Thermostat. Das Thermostat wird ohne Zutun von FHEM auf die WindowOpen-Temperature gehen
und reagiert also direkt auf das Signal vom Fensterkontakt.
Vielleicht hatte ich es noch nicht ganz verstanden. Wenn ich das lesen, dann funktioniert Fensterkontak + Thermostat eigentlich problemlos.
Wenn HC jetzt ins Spiel kommt, raffen die Thermostate nicht, dass sie eigentlich noch im Modus FensterOffen verharren müssten und schalten die von HC gelieferte Temperatur. HC soll dieses Fehlverhalten berücksichtigen?
{Heating_Control_SetAllTemps() ZitatAusserdem würden wir damit alle Credits verbraten bei 8+x Thermostaten dauert das ewig.
Das würde nicht passieren, weil HC nur dann eine neue Temperatur setzt, wenn desired-temp noch nicht mit dem Sollwert übereinstimmt. Und es wird bestimmt nicht in allen Räumen gleichzeitig gelüftet.
Lange Rede, kurzer Sinn. Habe ich es jetzt richtig wiedergegeben?
Wenn du Code oder ein Script hast, schick ihn mir mal, dann prüfe ich, ob ee leicht integrierbar ist.
Hallo Dietmar,
ZitatWenn HC jetzt ins Spiel kommt, raffen die Thermostate nicht, dass sie eigentlich noch im Modus FensterOffen verharren müssten und schalten die von HC gelieferte Temperatur. HC soll dieses Fehlverhalten berücksichtigen?
Ja, wäre aus meiner Sicht super, wenn Heating_Control genau dieses Verhalten berücksichtigen würde. Vielleicht durch einen zusätzlichen Parameter.
Off-Topic: Ich bin total begeistert, von FHEM und vor allem von dem Support und Einsatz all der ehrenamtlich Mitwirkenden. Mit welcher Geschwindigkeit auf "Kundenwünsche" eingegangen wird, ist für mich faszinierend. Würde mir wünschen, wenn dies im Alltag auch so selbstverständlich wäre. Ich beschäftige mich erst seit wenigen Wochen mit dem Thema Hausautomatisierung und habe Dank der Hilfe aus dem Forum schon verschiedene "Projekte" umgesetzt oder in Planung. Ich kann mir nicht vorstellen, dass ich OEM-Software nur annähernd auf meine persönlichen Anforderungen anpassen könnte. Deshalb möchte ich als Anwender an dieser Stelle allen Admins, Moderatoren, Entwicklern und Testern meinen Dank aussprechen.
Saludos,
Lutz
Hallo Dietmar,
ZitatWenn HC jetzt ins Spiel kommt, raffen die Thermostate nicht, dass sie eigentlich noch im Modus FensterOffen verharren müssten und schalten die von HC gelieferte Temperatur. HC soll dieses Fehlverhalten berücksichtigen?
Das kann man natürlich so sehen, oder aus Sicht vom Thermostat: "der da draussen wird schon wissen was er tut, er ist der Chef,
wenn ich bei offenem Fenster den Sollwert erhöhen soll, so mach ich das" und genauso ticken die Dinger.
Ich habe leider kein Skript für dich aber ein Rezept:
<device>:<reading>:<regexp> je für WindowIsOpen und WindowIsClosed
In das Notify via $hash->{NotifyFn} einklinken und die Ereignisse nach WindowIsOpen bzw. WindowIsClosed filtern.
Damit bekommst du allgemeingültig die Ereignisse der Kontakte mit und kannst entsprechen wie zuvor beschrieben reagieren.
ZitatDas würde nicht passieren, weil HC nur dann eine neue Temperatur setzt, wenn desired-temp noch nicht mit dem Sollwert übereinstimmt. Und es wird bestimmt nicht in allen Räumen gleichzeitig gelüftet.
Folgende Szene:
3 Fenster zum Lüften öffnen:
1. Fenster wird geschlossen, das Telefon klingelt
15 Minuten Gespräch
Die Ventile der Heizkörper mit offenen Fenster machen jedoch auf und blasen Wärme raus.
John
Hallo
Ich verwende gerade das Kalender Modul so, dass ich darin Devices eintragen kann.
Mit Beginn des Termins schaltet sie ein und mit Ende aus.
Nun habe ich mir gedacht, ich mache das gleiche mit meinen Heizkörper.
Ich Trage z.B. wz_Heizung|21.5 ku_Heizung|21.5 als Termin ein und dann werden zu Beginn des Termins alle eingetragen Ventile auf den festgelegten Sollwert eingestellt. Und wenn der Termin vorbei ist wieder auf Default Temp z.B. 18C eingestellt.
Hätte den Vorteil, dass meine Frau über den Google Kalender selber die Sollwerte verändern könnte bzw wenn ich unterwegs bin das auch ganz einfach ohne VPN etc machen könnte.
Was haltet ihr von der Idee?
Gruß
Hannes
Gesendet von Unterwegs mit Tapatalk 4
Die Idee mit dem Google Calendar kannst du jetzt schon umsetzen. Einfach ein notify auf die Ereignisse des Calendars und wenn das richtige kommt, dann in ein Set desired-temp xx verwandeln.
Gesendet von meinem HTC Desire S mit Tapatalk
Auch ich hadere noch mit dem Kalender.
Zumindest kann ich Ihn schon einmal ohne Fehlermeldung einbinden.
define HeizungsKalender Calendar ical url https://www.google.com/calendar/ical/"SNIP"/basic.ics 14400
attr HeizungsKalender room 7_CALENDAR
Das funktioniert gut, und wird auch in meinem "RAum" 7_CALENDAR als Initialized angezeigt.
Allerdings hab ich mit mehreren CodeSnippets, die ich hier im Forum gefunden habe immer noch nicht geschafft die Einträge auszuwerten :-( ... liegt wohl mal wieder an mir.
Dietmar hast du ein kurzes Stück Code für die Auswertung in deiner CFG und auch wie dein Termin (Betreff oder Inhalt - was ist entscheidend ?) aufgebaut ist ?
Gruss
Holger
tut mir leid, ich nutze keinen Calendar. Habe nur eine kleine Einweisung hier vom Erfinder des Moduls bekommen.
Wenn ich es verstanden habe, liest das Modul regelmäßig den Calender und erzeugt trigger, die mit notify abgefangen werden können.
so müsstest du es machen:
define SwitchActorOn notify MyCalendar:modeStarted.* { my $reading="%EVTPART0";; my $uid= "%EVTPART1";; my $actor= fhem("get MyCalendar summary $uid");; if(defined $actor) { fhem("set $actor on") } }
define SwitchActorOff notify MyCalendar:modeEnded.* { my $reading="%EVTPART0";; my $uid= "%EVTPART1";; my $actor= fhem("get MyCalendar summary $uid");; if(defined $actor) { fhem("set $actor off") } }
Wenn du unsicher bist was so ankommt dann logge erst einmal:
define SwitchActorOff notify MyCalendar:mode(Started|Ended).* {\
my $reading="%EVTPART0";;\
my $uid= "%EVTPART1";;\
my $actor= fhem("get MyCalendar summary $uid");;\
Log, 3, "%EVTPART0\n%EVTPART1\n $actor\n$reading";;\
}
aus dem Kopf geschrieben, deshalb keine Garantie.
[/code]
Die Auflösung der FS20 FHT bezüglich der Information window(open|closed) ist nicht besonders gut. Es erfolgt nur alle 15 Minuten eine Aktualisierung. Im Schnitt ist die Information, die ich mit HC auswerten würde 7-8 Minuten alt.
Ich werde das Gefühl nicht los, dass es sich nicht lohnt. In der Regel dauert das Lüften vielleicht 15 Minuten. Wenn ich das Signal bekomme, dass das Fenster offen ist, ist die Hälfte der Lüftungszeit schon verstrichen:
2013-10-24_17:01:57 HeizungKueche window: closed
2013-10-24_17:17:17 HeizungKueche window: closed
2013-10-24_17:32:57 HeizungKueche window: closed
2013-10-24_17:49:52 HeizungKueche window: closed
2013-10-24_18:01:22 HeizungKueche window: closed
2013-10-24_18:16:58 HeizungKueche window: closed
2013-10-24_18:33:57 HeizungKueche window: closed
2013-10-24_18:49:17 HeizungKueche window: closed
2013-10-24_19:00:57 HeizungKueche window: closed
2013-10-24_19:16:57 HeizungKueche window: closed
2013-10-24_19:33:22 HeizungKueche window: closed
2013-10-24_19:48:57 HeizungKueche window: closed
2013-10-24_20:00:57 HeizungKueche window: closed
2013-10-24_20:17:27 HeizungKueche window: closed
Das ist ja gruselig. Mein HM TC spricht auf den Fensterkontakte in rund 1-2 Sek an. Das Update der Ventile dauert dann noch etwas.
mein FHT weiß vielleicht früher davon. aber die Zentrale wird nur alle 15 Minuten informiert.
ZitatIch werde das Gefühl nicht los, dass es sich nicht lohnt. In der Regel dauert das Lüften vielleicht 15 Minuten. Wenn ich das Signal bekomme, dass das Fenster offen ist, ist die Hälfte der Lüftungszeit schon verstrichen:
Aus meiner Sicht würde sich die Fenster-Auf-Erkennung schon lohnen. Leider kann ich den Aufwand zur Umsetzung nicht abschätzen. Bei mir sind in einigen selten genutzen, aber beheizten Räumen die Fenster auch mal deutlich länger geöffnet. War einer der Gründe für mich, elektronische Thermostate und Fensterkontakte anzuschaffen.
Saludos,
Lutz
Aus meiner Sicht könnte man folgendes versuchen.
Dem HC ein Attribut spendieren: Fensterkontakte. Es enthält die zu einem HC relevanten Sensoren.
HC fragt bei bei einem Schaltereignis die Stati der Geräte in der Liste ab. Ist ein Kontakt offen, prüft HC 60 Sekunden später nochmal.
Gesendet von meinem HTC Desire S mit Tapatalk
Zitat von: Dietmar63 am 26 Oktober 2013, 02:04:25
Aus meiner Sicht könnte man folgendes versuchen.
Dem HC ein Attribut spendieren: Fensterkontakte. Es enthält die zu einem HC relevanten Sensoren.
HC fragt bei bei einem Schaltereignis die Stati der Geräte in der Liste ab. Ist ein Kontakt offen, prüft HC 60 Sekunden später nochmal.
Da es verschiedene Typen von Fensterkontakten gibt, muss ich zwangläufig, je nach Typ verschiedene Werte abfragen.
Bei meinem FS20-FK, Typ:CUL_FHTTK liefert das Reading "Window" "closed"/"open" als Status. Falls ihr andere FK-Typen habt, müßtet ihr mir den Typ des FK, den Namen des Readings und den Zustandstext für "open"/"close" mitteilen.
Dann baue ich es in HC ein.
Der Aufwand scheint nicht hoch zu sein.
Die fhem.cfg muss dann etwa folgendes enthalten:
define hc Heating_control fht 15:40|23 21:40|18
attr windowSensor terrassentuer FensterFK1 FensterFK2
Gute Nachricht.
Fenserkontakte können abgefragt werden. Das Feature wird mit dem nächsten Release eingecheckt:
Ich habe es nicht über notify gelöst, sondern habe vor dem eigentlichen Schaltvorgang folgenden Code eingefügt:
# Fenserkontakte abfragen - wenn einer im Status closed, dann Schaltung um 60 Sekunden verzögern
my $fensterKontakte = AttrVal($hash->{NAME}, "windowSensor", "nF");
Log 5, "$mod -> $fensterKontakte found.";
if ($fensterKontakte ne "nF" ) {
my @kontakte = split(/ /, $fensterKontakte);
foreach my $fk (@kontakte) {
if(!$defs{$fk}) {
Log 3, "$mod Window sensor <$fk> not found - check name.";
} else {
my $windowStatus = ReadingsVal($fk,"Window","nF");
Log 5, "$mod window sensor state $fk: $windowStatus";
if ($windowStatus ne "Closed") {
Log 3, "$mod switch of $hash->{DEVICE} delayed - window sensor state $fk: $windowStatus";
InternalTimer (time()+60, "$hash->{TYPE}_Update", $hash, 0);
return;
}
}
}
}
Die Definition in fhem.cfg sieht dann so aus:
define HeizungWohnen_we Heating_control fht 15:40|23 21:40|18
attr HeizungWohnen_we windowSensor Terrassentuer Fenster1 Fenster2
Dieser muss eventuell noch um eure Fensterkontakttypen ergänzt werden.
Das ganze funtioniert auch bei mir recht schnell. Die Information des FK steht nach ca. 60 Sekunden zur Verfügung.
2013.10.26 16:17:14 2: FHT set HeizungWohnen desired-temp 21.0
2013.10.26 16:17:14 3: [HeizungWohnen_we] Window sensor <Fenster2> not found - check name.
2013.10.26 16:17:14 3: [HeizungWohnen_we] Window sensor <Fenster1> not found - check name.
2013.10.26 16:16:14 3: [HeizungWohnen_we] switch of HeizungWohnen delayed - window sensor state Terrassentuer: Open
2013.10.26 16:15:14 3: [HeizungWohnen_we] switch of HeizungWohnen delayed - window sensor state Terrassentuer: Open
2013.10.26 16:14:14 3: [HeizungWohnen_we] switch of HeizungWohnen delayed - window sensor state Terrassentuer: Open
ZitatFensterkontakte können abgefragt werden. Das Feature wird mit dem nächsten Release eingecheckt
Hallo Dietmar,
Vielen Dank für die Integration der Fernsterkontakte. Ich freu mich schon auf die Bereitstellung des Updates.
Saludos,
Lutz
Danke für die Info mit dem Kalender und den Fensterkontakten.
Ich schau mir das mal an, wenn ich meinen KABEL-BW Hotline Horror hinter mich gebracht habe.
Seit Gestern habe ich ein neues Stück Modem/Router HArdware von KAbel-BW und nix geht mehr !!! (keine Port weiterschaltung, kein DynDNS, ....) .. das ist ein Scheiss ... never change a running system.
Frustgruss aus Stuttgart
HC und WD eingecheckt.
neue Features:
- Die Zeit kann nun als Perlfunktion angegeben werden: 123|{meineZeit()}|23. Die gelieferte Zeit muss das Format HH:MM:[SS] haben
- Dem Parameter kann ein zusätzlicher Parameter mitgegeben werden. Der Doppelpunkt ist das Trennzeichen: 123|{sunrise_abs()}|on-for-timer:20
- Für jedes HC kann ein windowSensor Attribut gepflegt werden. Es nimmt die Namen von Fensterkontakten auf, die nicht offen sein dürfen. Zurzeit werden Fensterkontakte des Typs CUL_FHTTK unterstützt. Wenn ein Fenster als offen erkannt wird, wird eine anstehende Schaltung verzögert.
Um weitere Fensterkontakttypen zu unterstützen benötige ich Eure Hilfe:
Sendet mir den Typ des Fensterkontakts, der in der Detailansicht des Device von FHEM angezeigt wird. Dazu benötige ich den Namen des Readings und den Inhalt des Readings, wenn der Kontakt offen ist.
HM-SEC-SC kann den State open oder closed haben.
HM-SEC-RHS kann den State open, tilted oder closed haben.
@ volschin, AnonymousHolger, DerMexikaner:
Ich habe Code für die Unterstützung der HM Fensterkontakte HM-SEC-SC und HM-SEC-RHS hinzugefügt.
Kann jemand diese Erweiterung testen. Ich habe kein HM!
Die Erweiterung ist eingecheckt!
Hallo Dietmar,
in einem Raum mit einem HM-CC-RT-DN und einem HM-SEC-SC funktioniert die Fenstererkennung und die programmierte gewünschte Temperatur wird erst nach dem Schließen des Fensters im RT eingestellt:
Zitat2013.10.27 23:45:57 3: [HCBuero] switch of HeizkoerperBuero_ClimRT_tr delayed - windowsensor 'FensterBuero' Reading 'state' is 'open'
2013.10.27 23:46:57 2: CUL_HM set HeizkoerperBuero_ClimRT_tr desired-temp 21.0
In einem weiteren Raum mit drei HM-CC-RT-DN (angesteuert von Heating_Control über eine Structure)
Zitatdefine HeizkoerperWohnbereichStructure structure room HeizkoerperWohnzimmerLinks_ClimRT_tr HeizkoerperWohnzimmerRechts_ClimRT_tr HeizkoerperEsszimmer_ClimRT_tr
wird die programmierte gewünschte Temperatur im RT eingestellt, obwohl einer von 3 Fensterkontakten (3 x HM-SEC-RHS für die Fenster, 1xHM-SEC-SC für die Terrassentür) noch geöffnet ist:
Zitat
2013-10-27_23:55:36 FensterWohnzimmerRechts tilted
2013-10-27_23:55:36 FensterWohnzimmerRechts contact: tilted (to HMLAN1)
2013-10-27_23:55:37 FensterWohnzimmerRechts tilted
2013-10-27_23:55:37 FensterWohnzimmerRechts contact: tilted (to HeizkoerperEsszimmer)
2013-10-27_23:55:38 FensterWohnzimmerRechts tilted
2013-10-27_23:55:38 FensterWohnzimmerRechts contact: tilted (to HeizkoerperWohnzimmerLinks)
2013-10-27_23:55:38 FensterWohnzimmerRechts tilted
2013-10-27_23:55:38 FensterWohnzimmerRechts contact: tilted (to HeizkoerperEsszimmer)
Zitat2013.10.28 00:00:01 2: CUL_HM set HeizkoerperEsszimmer_ClimRT_tr desired-temp 21.0
2013.10.28 00:00:01 2: CUL_HM set HeizkoerperWohnzimmerLinks_ClimRT_tr desired-temp 21.0
2013.10.28 00:00:01 2: CUL_HM set HeizkoerperWohnzimmerRechts_ClimRT_tr desired-temp 21.0
Saludos,
Lutz
Was bedeutet tilted?
Gesendet von meinem HTC Desire S mit Tapatalk
Tilted heisst gekippt.
Heute Abend kommt für HM
Tristate Sensoren eine neue Version heraus.
Gesendet von meinem HTC Desire S mit Tapatalk
Hallo,
ist das Verhalten normal? Erst hoch dann runter?
define Rollladen_AZ_down WeekdayTimer Rollo_AZ 1234567|{sunset_abs(-2700,"16:00","22:00")}|down (ReadingsVal("RolloAutomatik", "state", "Aus") eq "An")
attr Rollladen_AZ_down verbose 5
##
define Rollladen_AZ_up WeekdayTimer Rollo_AZ 12345|08:00|up 67|{sunrise_abs(0,"07:30","09:00")}|up (ReadingsVal("Verreist", "state", "Ja") eq "Nein")
attr Rollladen_AZ_up verbose 5
2013.10.28 14:51:34 5: [Rollladen_AZ_down] list of windowsenors found: 'nF'
2013.10.28 14:51:34 4: [Rollladen_AZ_down] 27.10.2013 16:54:12 ; aktParam: 0.0 ; newParam: down
2013.10.28 14:51:34 4: [Rollladen_AZ_down] 28.10.2013 16:54:12
2013.10.28 14:51:34 4: [Rollladen_AZ_down] command: { fhem("set Rollo_AZ down") if(ReadingsVal("RolloAutomatik", "state", "Aus") eq "An")}
2013.10.28 14:51:35 2: EnOcean set Rollo_AZ closed
2013.10.28 14:51:35 5: [Rollladen_AZ_up] list of windowsenors found: 'nF'
2013.10.28 14:51:35 4: [Rollladen_AZ_up] 28.10.2013 08:00:00 ; aktParam: 0.0 ; newParam: up
2013.10.28 14:51:35 4: [Rollladen_AZ_up] 29.10.2013 08:00:00
2013.10.28 14:51:35 4: [Rollladen_AZ_up] command: { fhem("set Rollo_AZ up") if(ReadingsVal("Verreist", "state", "Ja") eq "Nein")}
2013.10.28 14:51:36 2: EnOcean set Rollo_AZ open
Gruß Otto
jein - aber erklärbar.
Das Modul ist entstanden aus der Idee heraus eine Heizungssteuerung zu bauen: Heating_Control.
Bei einer HC ist das Verhalten sinnvoll beim Start von HC, die letzte Temp(auch wenn sie vorgestern definiert war) einzustellen und nicht nur die nächsten zu schalten.
Wenn heute morgen 9:00 Uhr 21° gewünscht war, dann soll die Temp auch eingestellt werden ich HC um 14:00 starte.
Dem WD wollte ich dieses Verhalten durch eine Negativliste der Geräte bei denen dieses Verhalten nicht sein soll abgewöhnen.
Die Liste besteht nur aus Geräten, die sich FS20 nennen. Ich werde die Liste in eine Positivliste verwandeln - dann sollte es wartungsarm funktionieren.
Bei der benutzung als Zeitschaltuhr was auch klappt tauchen aber fehler in der Konsole auf Funktioniert aber:
Use of uninitialized value $_ in numeric eq (==) at ./FHEM/98_Heating_Control.pm line 96, <> line 3.
Use of uninitialized value $_ in numeric eq (==) at ./FHEM/98_Heating_Control.pm line 96, <> line 3.
Use of uninitialized value $_ in numeric eq (==) at ./FHEM/98_Heating_Control.pm line 96, <> line 7.
sehe ich mir nochmals an!
Die Meldungen hab ich leider auch :
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 129.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 132.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 135.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 138.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 141.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 144.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 147.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 150.
Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 153.
Modul HC/WD eingecheckt - update durchführen.
- 'tilted' als zusätzlichen "open-Status" den HM devices hinzugefügt.
- fixed: Use of uninitialized value $_ in numeric eq (==) at C:/fhem-5.5/FHEM/98_Heating_
Control.pm line 96, <$fh> line 129.
noch offen - ist etwas komplizierter, vor allem, weil ich die hardware nicht habe.:
ZitatDem WD wollte ich dieses Verhalten durch eine Negativliste der Geräte bei denen dieses Verhalten nicht sein soll abgewöhnen.
Die Liste besteht nur aus Geräten, die sich FS20 nennen. Ich werde die Liste in eine Positivliste verwandeln - dann sollte es wartungsarm funktionieren.
Hallo Dietmar,
der Zustand "tilted" der Tri-State-Sensoren HM-SEC-RHS für gekippte Fenster wird von Heating_Control nun auch korrekt ausgewertet und die dort programmierte Temperatur im RT wie gewünscht erst nach dem Schließen des Fensters geändert:
Zitat
2013-10-28_23:17:35 FensterWohnzimmerRechts tilted
2013-10-28_23:17:35 FensterWohnzimmerRechts contact: tilted (to HMLAN1)
...
2013.10.28 23:40:16 3: [HCWohnbereich] switch of HeizkoerperWohnbereichStructure delayed - windowsensor 'FensterWohnzimmerRechts' Reading 'state' is 'tilted'
...
2013-10-28_23:41:05 FensterWohnzimmerRechts closed
2013-10-28_23:41:05 FensterWohnzimmerRechts contact: closed (to HMLAN1)
...
2013.10.28 23:41:16 2: CUL_HM set HeizkoerperEsszimmer_ClimRT_tr desired-temp 25.0
2013.10.28 23:41:16 2: CUL_HM set HeizkoerperWohnzimmerLinks_ClimRT_tr desired-temp 25.0
2013.10.28 23:41:16 2: CUL_HM set HeizkoerperWohnzimmerRechts_ClimRT_tr desired-temp 25.0
...
Vielen Dank für die schnelle und unkomplizierte Umsetzung!
Nach dem Update heute habe ich was neues in der Konsole stehen :)
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_C ontrol.pm line 425.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_C ontrol.pm line 425.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_C ontrol.pm line 425.
Zitat von: ChrisW am 29 Oktober 2013, 12:23:03
Nach dem Update heute habe ich was neues in der Konsole stehen :)
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_C ontrol.pm line 425.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_C ontrol.pm line 425.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Heating_C ontrol.pm line 425.
Sende mir mal bitte deine Definition, und zwar die Definition der Funksteckdose!
Welcher Typ ist das?
Du kannst übrigens jetzt auch WeekdayTimer benutzen.
Intertechno
So hab ich die Steckdosen hinzugefügt:
define steckdose_vorgarten1 IT A2
attr steckdose_vorgarten1 IODev CUL_0
attr steckdose_vorgarten1 loglevel 6
attr steckdose_vorgarten1 model itswitch
attr steckdose_vorgarten1 room Steckdosen,Lampen
Und das ist der code von Heating_control:
define vorgartenbeleuchtung Heating_Control steckdose_vorgarten1 06:00|on 06:01|on 09:00|off 09:01|off 17:00|on 17:01|on 23:58|off 23:59|off
Hallo Dietmar,
grundsätzlich finde ich die minütliche Abfrage des windowSensors gut. Im Logfile würde es aus meiner Sicht aber reichen, wenn das Event dort nur einmal auftaucht. Wäre das technisch realisierbar?
Habe halt Räume, in denen das Fenster länger geöffnet ist ;) und möchte mir nicht unbedingt das Logfile zuspammen.
Zitat
2013.10.30 00:04:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:05:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:06:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:07:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:08:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:09:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:10:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:11:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:12:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:13:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:14:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:15:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:16:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:17:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
2013.10.30 00:18:59 3: [HCGaesteWC] switch of HeizkoerperGaesteWC_ClimRT_tr delayed - windowsensor 'FensterGaesteWC' Reading 'state' is 'tilted'
Hallo Dietmar,
anscheinend ist mit dem Update auf Revision 4127 das Parsen der Profile kaputtgegangen:
fhem> define Test dummy
fhem> define Test_Steuerung Heating_Control Test Mo-Fr|06:00|21.0 Mo-Fr|08:30|16.0 Mo-Su|21:30|21.0 Mo-Su|00:45|16.0 Sa-Su|09:00|21.00 Sa-Su|12:00|16.00
fhem> list Test_Steuerung
Internals:
CFGFN
DEF Test Mo-Fr|06:00|21.0 Mo-Fr|08:30|16.0 Mo-Su|21:30|21.0 Mo-Su|00:45|16.0 Sa-Su|09:00|21.00 Sa-Su|12:00|16.00
DEVICE Test
LANGUAGE de
NAME Test_Steuerung
NR 1914
PROFILE 1: Montag 06:00 21.0, 08:30 16.0,
PROFILE 2: Dienstag 06:00 21.0, 08:30 16.0,
PROFILE 3: Mittwoch 06:00 21.0, 08:30 16.0,
PROFILE 4: Donnerstag 06:00 21.0, 08:30 16.0,
PROFILE 5: Freitag 06:00 21.0, 08:30 16.0,
STATE waiting...
TYPE Heating_Control
Readings:
2013-10-30 22:48:40 nextUpdate Heute, 22:49:10
2013-10-30 22:48:40 nextValue ???
2013-10-30 22:48:40 state waiting...
Helper:
SWITCHINGTIMES Mo-Fr|06:00|21.0 Mo-Fr|08:30|16.0 Mo-Su|21:30|21.0 Mo-Su|00:45|16.0 Sa-Su|09:00|21.00 Sa-Su|12:00|16.00
Switchingtime:
0:
1:
06:00:00 21.0
08:30:00 16.0
2:
06:00:00 21.0
08:30:00 16.0
3:
06:00:00 21.0
08:30:00 16.0
4:
06:00:00 21.0
08:30:00 16.0
5:
06:00:00 21.0
08:30:00 16.0
6:
Attributes:
Ich würde fast sagen, dass die Sprache falsch erkannt wird oder so...
Habe leider gerade überhaupt keine Zeit mir den Code anzuschauen und zu debuggen, Sorry :-(
Gruß
Michael
Jein, es wurde auf Wunsch hier im Forum Französisch ergänzt. Den Code, den ich bekommen habe musste ich überarbeiteten, und dabei musste ich von autodetection auf einen optionalen Sprachparameter umstellen. Sieh mal in die Dokumentation.
Eigentlich müsste Su bei language de abgelehnt werden. Das sehe ich mir gleich nochmals an.
Gesendet von meinem HTC Desire S mit Tapatalk
Zitat von: mgernoth am 30 Oktober 2013, 22:52:22
Hallo Dietmar,
anscheinend ist mit dem Update auf Revision 4127 das Parsen der Profile kaputtgegangen:
fhem> define Test dummy
fhem> define Test_Steuerung Heating_Control Test Mo-Fr|06:00|21.0 Mo-Fr|08:30|16.0 Mo-Su|21:30|21.0 Mo-Su|00:45|16.0 Sa-Su|09:00|21.00 Sa-Su|12:00|16.00
fhem> list Test_Steuerung
Internals:
CFGFN
DEF Test Mo-Fr|06:00|21.0 Mo-Fr|08:30|16.0 Mo-Su|21:30|21.0 Mo-Su|00:45|16.0 Sa-Su|09:00|21.00 Sa-Su|12:00|16.00
DEVICE Test
LANGUAGE de
NAME Test_Steuerung
NR 1914
PROFILE 1: Montag 06:00 21.0, 08:30 16.0,
PROFILE 2: Dienstag 06:00 21.0, 08:30 16.0,
PROFILE 3: Mittwoch 06:00 21.0, 08:30 16.0,
PROFILE 4: Donnerstag 06:00 21.0, 08:30 16.0,
PROFILE 5: Freitag 06:00 21.0, 08:30 16.0,
STATE waiting...
TYPE Heating_Control
Readings:
2013-10-30 22:48:40 nextUpdate Heute, 22:49:10
2013-10-30 22:48:40 nextValue ???
2013-10-30 22:48:40 state waiting...
Helper:
SWITCHINGTIMES Mo-Fr|06:00|21.0 Mo-Fr|08:30|16.0 Mo-Su|21:30|21.0 Mo-Su|00:45|16.0 Sa-Su|09:00|21.00 Sa-Su|12:00|16.00
Switchingtime:
0:
1:
06:00:00 21.0
08:30:00 16.0
2:
06:00:00 21.0
08:30:00 16.0
3:
06:00:00 21.0
08:30:00 16.0
4:
06:00:00 21.0
08:30:00 16.0
5:
06:00:00 21.0
08:30:00 16.0
6:
Attributes:
Ich würde fast sagen, dass die Sprache falsch erkannt wird oder so...
Habe leider gerade überhaupt keine Zeit mir den Code anzuschauen und zu debuggen, Sorry :-(
Gruß
Michael
Es waren doch noch einige Verbesserungen notwendig, damit die Fehler besser erkannt und ins Log geschrieben werden.
2013.10.31 21:02:55 2: FHT set HeizungWohnen desired-temp 22.0
2013.10.31 21:02:55 3: [HeizungWohnen_wt] delay of switch HeizungWohnen stopped.
2013.10.31 20:52:55 3: [HeizungWohnen_wt] switch of HeizungWohnen delayed - windowsensor 'Terrassentuer' Reading 'Window' is 'Open'
2013.10.31 20:18:43 3: [HeizungWohnen_wt] delay of switch HeizungWohnen stopped.
2013.10.31 20:15:43 3: [HeizungWohnen_wt] switch of HeizungWohnen delayed - windowsensor 'Terrassentuer' Reading 'Window' is 'Open'
2013.10.31 20:15:26 3: FS20 set Zirkulation off
2013.10.31 20:14:43 3: [HeizungWohnen_wt] switch of HeizungWohnen delayed - windowsensor 'Terrassentuer' Reading 'Window' is 'Open'
2013.10.31 20:11:20 2: FHT set HeizungWohnen desired-temp 22.0
2013.10.31 20:10:54 3: Mail sent to Dietmar.Ortmann@web.de
2013.10.31 20:10:50 2: FHT set HeizungKueche desired-temp 16.0
Das Protokoll konnte ich ebenfalls verkürzen.
Intertechnogeräte werden jetzt auch korrekt geschaltet.
Ich beobachte das Modul bei mir noch etwas, dann checke ich es ein.
Ich habe 9 Heating_Controls, und diese erzeugen beim Start von FHEM einmalig diese 9 Fehler in der Console :
C:\fhem-5.5>perl_5.18.1.1\perl\bin\perl fhem.pl fhem.cfg
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
Use of uninitialized value $n in hash element at fhem.pl line 3004.
versuche ich heute herauszufinden.
Hallo Dietmar,
Zitat von: Dietmar63 am 31 Oktober 2013, 18:25:19
Jein, es wurde auf Wunsch hier im Forum Französisch ergänzt. Den Code, den ich bekommen habe musste ich überarbeiteten, und dabei musste ich von autodetection auf einen optionalen Sprachparameter umstellen. Sieh mal in die Dokumentation.
Super, danke. Jetzt funktioniert es wieder :-)
Ich hatte nur geschaut, ob es ein passendes Attribut gibt, dass die Sprache auch im define stehen könnte, daran habe ich gar nicht gedacht..
Danke für das tolle Modul & Gruß
Michael
Hallo
Ich versuche gerade das Heating_Control Modul bei mir einzubinden und meine etwas komplexere Heizungsregelung damit zu ersetzten....
(Ich verwende 7 FHT's mit Fensterkontakten an einem CUNO)
Dazu zwei Fragen:
1) Zum Beisiel aus dem Command-Ref im Bezug auf condition:
define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
Die zu setzende Temperatur wird nur gesetzt, falls die Dummy Variable WeAreThere = "yes" ist.
Die Temeraturanhebungen im Profil wollte ich nur durchführen wenn jemand zu Hause ist, deswegen hatte ich untenstehendes probiert.
Scheinbar können die Bedingungen aber je define eingefügt werden. Dies führt wohl nun dazu dass ich alle Temperaturanhebungen in ein define sammeln muß.
Leider geht damit der Vorteil verloren alle Schaltpunkte in einer Detailansicht zusammen zu sehen.
define HC_DAVID Heating_Control DAVID_hzg de Mo-Fr|06:05|21.0 (Value("HOME_Status") == 0) Mo-Fr|08:05|16.0 Mo-Fr|12:05|21.0 (Value("HOME_Status") == 0)Mo-Fr|18:05|16.0 Sa-So,Mo|07:05|20.0 (Value("HOME_Status") == 0)Sa-So,Mo|18:05|16.0
attr HC_DAVID room HEIZUNG
attr HC_DAVID windowSensor DAVID_fenster
2. Frage zur Verwendung von $we
Im Forum habe ich gelesen dass die Verwendung von $we für Wochenende und Feiertage möglich ist. Leider scheint es wie folgt aber nicht zu gehen...
Was mache ich hier falsch?
define HC_DAVID Heating_Control DAVID_hzg de Mo-Fr|06:05|21.0 Mo-Fr|08:05|16.0 Mo-Fr|12:05|21.0 Mo-Fr|18:05|16.0 we$|07:05|20.0 we$|18:05|16.0
attr HC_DAVID room HEIZUNG
attr HC_DAVID windowSensor DAVID_fenster
Danke für eure Rückmeldung
Manuel
wenn dann nur so:
define HC_DAVID Heating_Control DAVID_hzg de Mo-Fr|06:05|21.0 Mo-Fr|08:05|16.0 Mo-Fr|12:05|21.0 Mo-Fr|18:05|16.0 Sa-So,Mo|07:05|20.0 Sa-So,Mo|18:05|16.0 (Value("HOME_Status") == 0)
oder so:
define HC_DAVID Heating_Control DAVID_hzg de define HC_DAVID Heating_Control DAVID_hzg de 06:05|21.0 08:05|16.0 12:05|21.0 18:05|16.0 07:05|20.0 18:05|16.0 ($we)
oder so:
define HC_DAVID Heating_Control DAVID_hzg de 06:05|21.0 08:05|16.0 12:05|21.0 18:05|16.0 07:05|20.0 18:05|16.0 (!$we)
oder so:
define HC_DAVID Heating_Control DAVID_hzg de 06:05|21.0 08:05|16.0 12:05|21.0 18:05|16.0 07:05|20.0 18:05|16.0 (meineEigeneFunktion(@,%) )
meineEigeneFunktion($$) muss dann in die 99_utils.
oder so:
define HC_DAVID Heating_Control DAVID_hzg de 06:05|21.0 08:05|16.0 12:05|21.0 18:05|16.0 07:05|20.0 18:05|16.0 {fhem("set @ desired %")}
Es gibt viele Möglichkeiten Bedingungen zu formulieren. Das liegt daran, dass die Möglichkeit eine Condition oder Perlfunktion zu nutzen am Anfang stand. Auf vielfachen Wunsch hin wurde die Möglichkeit geschaffen die Tage vor die Schaltzeit zu schreiben. Inzwischen kann mandie Schaltzeiten auch per sunrise_abs() ermitteln:
define hc1 Heating_Control Brunnen de so-sa|{sunrise_abs()}|off so-sa|{sunset_abs()}|on ; attr hc1 verbose 5;
Mit verbose kannst du detailiert sehen welcher Befehl erzeugt und gesendet wird!
Hallo,
ich wollte den WeekdayTimer für das Steuern meiner Zirkulationspumpe nutzen.
Definiert habe ich es wie folgt:
HWR_Zirkulation Mo-Fr|05:00|on-for-timer:3600 Mo-Fr|14:30|on-for-timer:3600 Mo-Fr|20:00|on-for-timer:1800 Sa-So|08:00|on-for-timer:3600 Sa-So|14:30|on-for-timer:3600 Sa-So|19:00|on-for-timer:3600 (Value("abwesend") eq "nein")
Aber im Log kommt folgende Fehlermeldung:
set HWR_Zirkulation desired-temp on-for-timer 3600 : Unknown argument desired-temp
Wie bekomme ich es hin, dass nur der Befehl "set HWR_Zirkulation on-for-timer 3600" ausführt?
Gruß
Christian
define xx WeekdayTimer HWR_Zirkulation Mo-Fr|05:00|on-for-timer:3600 Mo-Fr|14:30|on-for-timer:3600 Mo-Fr|20:00|on-for-timer:1800 Sa-So|08:00|on-for-timer:3600 Sa-So|14:30|on-for-timer:3600 Sa-So|19:00|on-for-timer:3600 { fhem("set @ %") if (Value("abwesend") eq "nein") }
Anstelle von Value musst du bestimmt ReadingsVal(...) nutzen!
Mit verbose 5 kannst du immer sehen was gesendet wird.
Ich verbessere das Modul gerade, so dass es besser den Standardmodifier (desiredTemp ...) erkennt.
In deinem Fall sollte dann "" zwischen @ und % eingefügt werden.
Hallo Dietmar
danke für deine schnelle Antwort.
Entsprechend deiner Rückmeldung habe ich mein Wochenprogramm für Wochenende und Wochentag aufgesplittet und gleichzeitig noch eine weitere Bedingung "verundet".
Aus irgendeinem Grund werden aber beide Profile als inaktiv angezeigt. Erwartet hatte ich dass die Wochenend/Feiertag (Bayern!) aktiv angezeigt wird.
Die Bedingung habe ich in einer If Anweisung in der Kommandozeile getestet {if($we && (Value("HOME_Status") == 1)){"wahr"} else {"falsch"}}
Da erhalte ich das erwartete Ergebnis.
Mache ich hier was falsch?
Gruß Manuel
define HC_DAVID_WE Heating_Control DAVID_hzg de 07:05|20.0 18:05|16.0 ($we && (Value("HOME_Status") == 1))
attr HC_DAVID_WE room HEIZUNG
attr HC_DAVID_WE windowSensor DAVID_fenster
attr HC_DAVID_WE group Wochenende
define HC_DAVID_WT Heating_Control DAVID_hzg de 06:05|21.0 08:05|16.0 12:05|21.0 18:05|16.0 (!$we && (Value("HOME_Status") == 1))
attr HC_DAVID_WT room HEIZUNG
attr HC_DAVID_WT windowSensor DAVID_fenster
attr HC_DAVID_WT group Wochentag
ReadingsVal statt Value!
ist home_status ein dummy?
Hallo Dietmar,
ich denke, das war mein Fehler. Ich habe versucht ein Kommando und eine Bedingung zu setzen. Dies war wohl so nicht gewollt. Man kann natürlich einfach die Bedingung in das Perlkommando packen und schon funktioniert es:
HWR_Zirkulation Mo-Fr|05:00|on-for-timer:3600 Mo-Fr|14:30|on-for-timer:3600 Mo-Fr|20:00|on-for-timer:1800 Sa-So|08:00|on-for-timer:3600 Sa-So|14:30|on-for-timer:3600 Sa-So|19:00|on-for-timer:3600 {if(Value("abwesend") eq "nein") {fhem("set @ %")}}
Kann ich für Sa-So auch $we benutzen, damit ich auch Feiertage mit abdecke?
Gruß
Christian
Das funktioniert noch nicht. Der Wunsch besteht hier im Forum. Ich würde $we nehmen, aber wir haben uns hier noch nicht geeinigt.
Gesendet von meinem HTC Desire S mit Tapatalk
Hallo Dietmar,
ja ein dummy...
define HOME_Status dummy
In der Kommantozeile ergibt {Value("HOME_Status")} eine 1 als Ausgabe..
Sollte also soweit passen.
Hast du noch eine Idee?
Gruß Manuel
Ich glaube man muss auch dummys mit ReadingsVal auslesen. Warum du bei deinem Test scheinbar ein richtiges Ergebniss bekommen hast, verstehe ich nicht
Gesendet von meinem HTC Desire S mit Tapatalk
Hallo Dietmar,
ich habe es auch mit ((ReadingsVal("HOME_Status", "state", "na")==1) && $we) probiert.
Die obige Anweisung für sich funktioniert ebenso wie das Value(...) dennoch bleibt das Heating Control inaktiv.
Ob man Value oder ReadingVal verwenden kann sieht man wenn hier z.B. list HOME_Status in der Kommandozeile eingibt.
Mit Value() list man den Wert der nach STATE steht...
Mit ReadingsVal() kann man alle Werte lesen die nach Readings aufgeführt sind. Hier also "state"
Internals:
CFGFN /share/Public/fhem-5.4/FHEM/00_Home_Status.cfg
NAME HOME_Status
NR 269
STATE 1
TYPE dummy
Readings:
2013-11-01 15:29:32 state 1
folgendes funktionert...
... (Value("HOME_Status") == 1)
... ($we)
... (Value("HOME_Status") == 1 && 1)
folgendes geht nicht (führt zu inaktiv)
... ($we && 1)
... (($we) && 1)
Damit bleibe ich etwas ratlos zurück
Gruß Manuel
ich habe mal Value("Heizung") in der Oberfläche eingeben. Überraschenderweise kommt tatsächlich das richtge Ergebnis heraus.
ein Blick in die CommandRef:
Zitat
Value(<devicename>)
returns the state of the device (the string you see in paranthesis in the output of the list command).
OldValue(<devicename>)
OldTimestamp(<devicename>)
returns the old value/timestamp of the device.
ReadingsVal(<devicename>,<reading>,<defaultvalue>)
Return the reading (the value in the Readings section of "list device")
AttrVal(<devicename>,<attribute>,<defaultvalue>)
Return the attribute of the device
{ Value("wz") }
{ OldValue("wz") }
{ time_str2num(OldTimestamp("wz")) }
{ ReadingsVal("wz", "measured-temp", "20")+0 }
{ ReadingsTimestamp("wz", "measured-temp", 0)}
{ AttrVal("wz", "room", "none") }
Du hast also recht - es müßte funktonieren.
Value() ist eine normale Funktion in fhem.pl, so wie ReadingsVal auch:
sub
Value($)
{
my ($d) = @_;
if(defined($defs{$d}) &&
defined($defs{$d}{STATE})) {
return $defs{$d}{STATE};
}
return "";
}
Es muss also so funktionieren wie du es dir gedacht hast, aber warum es nicht geht - ???
ich befürchte das liegt an meinem Code in HC.
In der Zeile 312(Anhang) ist $we nicht definiert. Eine Fehlermeldung wird nicht erzeugt.
Der eigentliche Code der Form
{ fhem("set HeizungKueche desired-temp 22.0") if(heizungAnAus("An", 0))}
wird mit
my $ret = AnalyzeCommandChain(undef, $command);
ausgeführt. in A..C..C wird $we tief im Innern definiert, so dass die Bedingung korrekt ausgefürht wird, aber active / inactive nicht richtig angezeigt wird - muss ich wohl nochmal nachbessern, wenn mir was besseres einfällt.
Schalte mal mit verbose 5 die debug-Infos ein. Dann wird bestimmt deutlich, dass doch alles funktioniert.
Das Problem bei der Anzeige active/inactive war, dass ich die Bedingung, die von außen mitgegeben wird nicht isoliert auswerten kann, insbesondere dann wenn komplexer Perlcode geliefert wird. Ich habe in meiner Funktion heizunganAus $we selbst neu ausgerechnet.
ich werde mal probieren, AnalyzeCommandChain(...) anstelle des eval zu nutzen.
Hallo Dietmar,
bei den "Inereien" deines Moduls überfordern meine bescheidenen FHEM/Perl Kenntnisse.
Ich werde jetzt die aktiv / inaktiv Anzeige ignorieren und mal sehen ob es trotzdem fuktioniert.
Danke für deine Hilfe !
Gruß Manuel
Schalte ruhig mal Verbose 5 für die HCs ein. Dann bekommst du etwas Output.
Gesendet von meinem HTC Desire S mit Tapatalk
eingecheckt
Hallo Dietmar,
bin zwischenzeitlich recht glücklich mit deinem Modul!
Ich habe das ganze zwischenzeitlich auf die {perl} Variante umgestellt... um das alles inkativ Problem zu umschiffen.
Vielleicht ist dies ja durch deine letze Version behoben.
so schhaut es jetzt bei mir aus....
fhem.cfg
define HC_KUECHE_WE Heating_Control KUECHE_hzg de 07:05|21 09:35|16 16:05|21 18:00|16 {if ($we){&SET_FHT("@",%)}}
attr HC_KUECHE_WE windowSensor KUECHE_fenster
attr HC_KUECHE_WE group Wochenende
define HC_KUECHE_WT Heating_Control KUECHE_hzg de 06:05|21.0 07:35|18.0 16:05|21.0 18:00|16.0 {if (!$we){&SET_FHT("@",%)}}
attr HC_KUECHE_WT windowSensor KUECHE_fenster
attr HC_KUECHE_WT group Wochentag
99_myUtils.pm
sub SET_FHT {
my ($fht , $desired_temp) = @_;
if (Value("HOME_Status") == 1) {fhem("set $fht desired-temp $desired_temp");}
else {fhem("set $fht desired_temp 16");}
}
sub SET_FHT_alloff {
fhem("set BAD_hzg desired-temp 16");
......
fhem("set KUECHE_hzg desired-temp 16");}
Nun noch ein paar Fragen:
1)
Ändert sich der HOME_Status auf Null werden alle Heizkörper heruntergefahren.
Nun fehlt mir aber eine elegante Möglichkeit um alle Heizkörper wieder auf die Wunschtemperatur zu fahren wenn jeman Heim kommt. (HOME_Status == 1).
Es geht mit einem rereadcfg was mir aber nicht sonderlich gefällt. Gibt es eine möglichkeit die Heating_Control zu triggern?
2)
Könnte diese Fehlermeldung von Heating Control verursacht werden? (Hatte ich vorher nicht)
Use of uninitialized value $n in hash element at /opt/bin/fhem.pl line 3004.
3)
Was für die Wunschliste
a)
Die Unterstützung der Wochenendfunktion wäre an dieser Stelle sehr praktisch und intuitiv anwendbar.
define HC_KUECHE_WT Heating_Control KUECHE_hzg de $we|06:05|21.0 07:35|18.0 16:05|21.0 18:00|16.0
b)
define HC_KUECHE_WT Heating_Control KUECHE_hzg de 06:05|21.0 07:35|18.0 16:05|21.0 18:00|night-temp
Schön wäre auch wenn man statt einer konkreten Temperatur die in der Steuereinheit hinterlegbaren Temperaturen (day-temp / night-temp) aufrufen könnte.
Vorteil: die Temperaturen sind dann ohne Programmänderung an jeder Steuereinheit auf die personlichen Bedürfnisse anpassbar.
Schönen Abend
Gruß Manuel
Zitat von: Petrosilius Zwackelmann am 02 November 2013, 22:59:42
Hallo Dietmar,
bin zwischenzeitlich recht glücklich mit deinem Modul!
1)
Ändert sich der HOME_Status auf Null werden alle Heizkörper heruntergefahren.
Nun fehlt mir aber eine elegante Möglichkeit um alle Heizkörper wieder auf die Wunschtemperatur zu fahren wenn jeman Heim kommt. (HOME_Status == 1).
Es geht mit einem rereadcfg was mir aber nicht sonderlich gefällt. Gibt es eine möglichkeit die Heating_Control zu triggern?
2)
Könnte diese Fehlermeldung von Heating Control verursacht werden? (Hatte ich vorher nicht)
Use of uninitialized value $n in hash element at /opt/bin/fhem.pl line 3004.
3)
Was für die Wunschliste
a)
Die Unterstützung der Wochenendfunktion wäre an dieser Stelle sehr praktisch und intuitiv anwendbar.
define HC_KUECHE_WT Heating_Control KUECHE_hzg de $we|06:05|21.0 07:35|18.0 16:05|21.0 18:00|16.0
b)
define HC_KUECHE_WT Heating_Control KUECHE_hzg de 06:05|21.0 07:35|18.0 16:05|21.0 18:00|night-temp
Schön wäre auch wenn man statt einer konkreten Temperatur die in der Steuereinheit hinterlegbaren Temperaturen (day-temp / night-temp) aufrufen könnte.
Vorteil: die Temperaturen sind dann ohne Programmänderung an jeder Steuereinheit auf die personlichen Bedürfnisse anpassbar.
Schönen Abend
Gruß Manuel
Zu 1): geht:
define HeizStatus2 notify Heizung:.* {Heating_Control_SetAllTemps()}sucht alle definierten HC und führt die Fuktion
Heating_Control_Update($hash); aus. Deine Automatik reagiert also jedesmal wenn das dummy
Heizung geändert wird.
Zu 2):
ja, neues Modul ist eingecheckt - bei ihr besteht das Problem nicht mehr.
Zu 3a):
kommt, ob genau so, kann ich noch nicht sagen.
Zu 3b):
geht, ist genau so möglich. Wenn irgend etwas nicht klappt,
verbose 5 und du bekommst Details angezeigt. Dann kannst du meist selbst erkennen was du ändern mußt.
...
Du kannst auch so etwas machen:
define hc1 Heating_Control ZentralHeizung de so-sa|{sunrise_abs()}|on so-sa|{sunset_abs()}|off ; attr hc1 verbose 5;und damit eine Funksteckdose, an bzw. ausschalten. Was zwischen @ und % automatisch gesetzt wird, wird jetzt hoffentlich besser im
autodetectionmodus erkannt. Bei deiner Perlvariante bist du selbst für das Zwischendrin zuständig. Anstelle von sunrise_abs() kannst du auch selbst erstellte Fuktionen verwenden. Sie müssen die Zeit im Format
HH:MM oder
HH:MM:SS zurückgeben. Das ist auch der Grund warum
sunrise()/sunset() nicht funktioniert. Sie lieferen manchmal 30:23:10 also größer 24:00:00.
sunrise_abs()/sunset_abs() können verwendet werden.
oder dies geht auch:
define wd1 WeekdayTimer Brunnen de so-sa|{sunrise_abs()}|on-for-timer:1800 so-sa|{sunset_abs()}|on-for-timer:1800; attr hc1 verbose 5;Dann wird der Doppelpunkt als Trenner eines weiteren Parameters eliminiert.
Du kannst auch Rollos damit schalten. Dann vielleicht besser
WeekdayTimer nehmen - funktioniert identisch.
Weiterhin kannst du eine Liste mit Fensterkontakten angeben. Wenn bei einem von ihnen der Zustand
open oder
tilted erkannt wird, wird das Schalten der Heizung verzögert.
define Terrassentuer CUL_FHTTK 64b840
attr HeizungWohnen_wt windowSensor Terrassentuer FensterWohnen1 FensterWohnen2;
Bei HM sieht die Definition natürlich anders aus.
Das Protokoll sieht dann so aus:
2013.11.02 21:57:26 3: [HeizungWohnen_we] delay of switching HeizungWohnen stopped.
...
2013.11.02 21:55:26 3: [HeizungWohnen_we] switch of HeizungWohnen delayed - windowsensor 'Terrassentuer' Reading 'Window' is 'Open'
2013.11.02 21:37:48 3: [Befehl] Befehl HC done
Weiterhin viel Spass damit.
Moin, Dietmar,
Du rätst immer zu verbose=6; im Web-Interface wird aber nur Verbose 0...5 angeboten, die sechste Stufe müsste also 5 heißen, oder?
Herzliche Grüße
Christian
Zitat von: cwagner am 03 November 2013, 08:39:59
Moin, Dietmar,
Du rätst immer zu verbose=6; im Web-Interface wird aber nur Verbose 0...5 angeboten, die sechste Stufe müsste also 5 heißen, oder?
Herzliche Grüße
Christian
ZitatZu 3b):
geht, ist genau so möglich. Wenn irgend etwas nicht klappt, verbose 5 und du bekommst Details angezeigt. Dann kannst du meist selbst erkennen was du ändern mußt.
da steht auch 5!!!
sorry, ich kauf mir ne Brille!
Hallo Dietmar,
danke für deine ausführliche Rückmeldung die ich nun Schritt für Schritt verarbeiten werde.
Zunächst rufe ich bei jeder Änderung von meinem Dummy HOME_Status die Funktion {Heating_Control_SetAllTemps()} auf.
Im Logfile erscheinen dann auch folgende Einträge...
2013.11.03 19:53:40 3: Heating_Control_Update() for HC_WZ_WT done!
2013.11.03 19:53:40 4: [HC_BAD_WE] Next switch 03.11.2013 22:00:00
2013.11.03 19:53:40 4: [HC_BAD_WE] 03.11.2013 18:30:00 ; aktParam: 21.0 ; newParam: 21.0
2013.11.03 19:53:40 5: [HC_BAD_WE] windowsensor 'BAD_fenster' Reading 'Window' is 'Closed'
2013.11.03 19:53:40 5: [HC_BAD_WE] list of windowsenors found: 'BAD_fenster'
Scheinbar wird aber nicht die Temperatur entsprechend der Perl-Anweisung ausgeführt (Diese senkt ab falls HOME_Status == 0 ist, sondern "nur" die Temperatur entsprechend des Profils.
Damit komme ich nicht zum gewünschten Ergebnis. Kannst du das Verhalten so bestätigen?
Gruß Manuel
fhem.cfg
define HC_BAD_WE Heating_Control BAD_hzg de 06:30|21.0 08:30|18.0 18:30|21.0 22:00|18.0 {if ($we){&SET_FHT("@","%")}}
attr HC_BAD_WE group Wochenende
attr HC_BAD_WE room HEIZUNG
attr HC_BAD_WE verbose 5
attr HC_BAD_WE windowSensor BAD_fenster
99_myUtils.pm
sub SET_FHT {
my ($fht , $DESIRED_temp) = @_;
my $NIGHT_temp = ReadingsVal($fht, "night-temp", "17.0");
if (Value("HOME_Status") == 1) {fhem("set $fht desired-temp $DESIRED_temp");}
else {fhem("set $fht desired-temp $NIGHT_temp");}
}
versuch es mal mit der neuesten Version nach einem Update.
Hallo Dietmar,
zu.....
ZitatScheinbar wird aber nicht die Temperatur entsprechend der Perl-Anweisung ausgeführt (Diese senkt ab falls HOME_Status == 0 ist, sondern "nur" die Temperatur entsprechend des Profils.
Damit komme ich nicht zum gewünschten Ergebnis. Kannst du das Verhalten so bestätigen?
Mit der Version von gestern ist das Problem behoben.
Vielen Dank
Gruß Manuel
Um credit zu sparen wurde die Temperatur nur dann verstellt wenn sie nicht schon dem gewünschten Wert entsprach.
Wenn die Kontrolle komplett auf eine Perlfunktion verlagert werden soll, ist dieses Vorgehen, wie in deinem Fall nicht sinvoll, weil deine Funktion die Kontrolle erst gar nicht bekommen hat.
Hallo Dietmar,
Zitat3b) Was für die Wunschliste
define HC_KUECHE_WT Heating_Control KUECHE_hzg de 06:05|21.0 07:35|18.0 16:05|21.0 18:00|night-temp
Schön wäre auch wenn man statt einer konkreten Temperatur die in der Steuereinheit hinterlegbaren Temperaturen (day-temp / night-temp) aufrufen könnte.
Vorteil: die Temperaturen sind dann ohne Programmänderung an jeder Steuereinheit auf die personlichen Bedürfnisse anpassbar.
ZitatZu 3b): geht, ist genau so möglich. Wenn irgend etwas nicht klappt, verbose 5 und du bekommst Details angezeigt. Dann kannst du meist selbst erkennen was du ändern mußt.
Das klappt bei mir leider noch nicht so recht....
fhem.cfgdefine HC_WC_WT Heating_Control WC_hzg de 06:05|day-temp 18:05|night-temp {if (!$we){&SET_FHT("@","%")}}sub SET_FHT {
my ($fht, $DESIRED_temp) = @_;
my $NIGHT_temp = ReadingsVal($fht, "night-temp", "17.0");
if (Value("HOME_Status") == 1) {
fhem("set $fht desired-temp $DESIRED_temp");
}
elsif (Value("HOME_Status") == 0) {
fhem("set $fht desired-temp $NIGHT_temp");
}
}logfile2013.11.04 23:00:30 3: Invalid temperature night-temp, choose one of on off 6.0 6.5 7.0 7.5 8.0 8.5 9.0 ...... 23.5 24.0 24.5 25.0 25.5 26.0 26.5 27.0 27.5 28.0 28.5 29.0 29.5 30.0
2013.11.04 23:00:30 3: set WC_hzg desired-temp night-temp : Invalid temperature night-temp, choose one of on off 6.0 6.5 7.0 7.5 8.0 8.5 9.0 9.5 10.0 10.5 11.0 11.5 .....
Problem:
Variante A)
Den Befehl "Set FHT-device desired-temp night-temp" gibt es nicht. Dein Modul müsste vorher ein ReadingsVal($fht, "night-temp", "kein wert") ausführen und dann diesen Rückgabewert verarbeiten.
Variante B) liegt an mir und meiner Funktion.
Die Werte night-temp und day-temp sind jedenfalls bei dem device gesetzt...
Gruß Manuel
B) !!!
wenn du eine eigene Funktion in HC angegeben hast, bekommt die Funktion die volle Kontrolle.
HC sendet keine eigene Befehle, nur &SET_FHT(...).
Du musst dann mit eigenem Code desired-temp ergänzen oder nicht - kannst du gut über einen hash ermitteln.
Etwa so:
my %modifier = ("MAX"=>"desiredTemperature","FHT"=>"desired-temp","CUL_HM"=>"desired-temp");
my $commandMod = $modifier{$defs{$hash->{DEVICE}}{TYPE}};
$commandMod = "" if (!defined($commandMod));
fhem("set $fht $commandMod $DESIRED_temp");
Die zu realisierenden Varianten(HM, FHT, MAX, ...) wären einfach zu komplex, um sie alle in HC zu implementieren.
Zitat3) Was für die Wunschliste
b)
define HC_KUECHE_WT Heating_Control KUECHE_hzg de 06:05|21.0 07:35|18.0 16:05|21.0 18:00|night-temp
Schön wäre auch wenn man statt einer konkreten Temperatur die in der Steuereinheit hinterlegbaren Temperaturen (day-temp / night-temp) aufrufen könnte.
Vorteil: die Temperaturen sind dann ohne Programmänderung an jeder Steuereinheit auf die personlichen Bedürfnisse anpassbar.
Zitat
Zu 3b):
geht, ist genau so möglich. Wenn irgend etwas nicht klappt, verbose 5 und du bekommst Details angezeigt. Dann kannst du meist selbst erkennen was du ändern mußt
Wegen obiger Rückmeldung hatte ich angenommen dein Modul verarbeitet night-temp und day-temp und übergibt sie der Perl Funktion als %.
Dies scheint zumindest bei Verwendung von eigenen Funktionen noch(?) nicht implementiert zu sein.
Null Problemo - das Modul arbeitet prima.
Danke
Gruß Manuel
Hallo,
ich habe einen HM-LC-Bl1PBU-FM für ein Rollo und möchte es mit WeekdayTimer steuern. Nur wird er als Heizkörper erkannt!
2013.11.10 08:22:04 5: [Rollladen_Kue_up] list of windowsenors found: ''
2013.11.10 08:22:04 4: [Rollladen_Kue_up] Jetzt:10.11.2013 08:22:09 -> Next: 10.11.2013 08:22:00 -> Param: on -9
2013.11.10 08:22:04 4: [Rollladen_Kue_up] 10.11.2013 08:22:00 ; aktParam: 0.0 ; newParam: on
2013.11.10 08:22:04 4: [Rollladen_Kue_up] command: { fhem("set Rollo_Kue desired-temp on") if(ReadingsVal("Verreist", "state", "Ja") eq "Nein")}
2013.11.10 08:22:04 3: set Rollo_Kue desired-temp on : Unknown argument desired-temp, choose one of clear:readings,register,rssi,msgEvents down getConfig getRegRaw getSerial inhibit:on,off off on pair pct:slider,0,1,100 peerBulk press raw regBulk regSet reset sign:on,off statusRequest stop toggle unpair up
2013.11.10 08:22:04 3: Unknown argument desired-temp, choose one of clear:readings,register,rssi,msgEvents down getConfig getRegRaw getSerial inhibit:on,off off on pair pct:slider,0,1,100 peerBulk press raw regBulk regSet reset sign:on,off statusRequest stop toggle unpair up
define Rollladen_Kue_up WeekdayTimer Rollo_Kue 12345|07:00|on 67|08:22|on (ReadingsVal("Verreist", "state", "Ja") eq "Nein")
Wo Wie kann ich das ändern?
Gruß Otto
Schick mir die Details deines Geräts mit list - dann verbessere ich die autodetection. Ich muss wissen, welches model dahinter steckt.
Hallo Dietmar,
hier die Details:
Internals:
CFGFN /opt/fhem/rollo.cfg
DEF 20xxxxx
EVENTS 1
HMLAN1_MSGCNT 2
HMLAN1_RAWMSG xxxxx
HMLAN1_RSSI -69
HMLAN1_TIME 2013-11-10 09:07:51
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 2
NAME Rollo_Kue
NR 249
STATE Auf
TYPE CUL_HM
lastMsg xxxxx
protLastRcv 2013-11-10 09:07:51
protSnd 2 last_at:2013-11-10 09:07:50
protState CMDs_done
rssi_HMLAN1 avg:-71 min:-71 max:-71 lst:-71 cnt:1
rssi_at_HMLAN1 avg:-69 min:-69 max:-69 lst:-69 cnt:2
Readings:
2013-11-10 08:38:35 CommandAccepted yes
2013-10-23 18:14:37 PairedTo xxx
2013-10-23 17:57:06 R-driveDown 20 s
2013-10-23 17:53:53 R-driveTurn 0.5 s
2013-10-23 17:56:28 R-driveUp 20 s
2013-10-23 18:14:37 R-intKeyVisib invisib
2013-10-23 18:14:37 R-localResDis off
2013-10-23 18:14:37 R-pairCentral xxx
2013-10-23 18:14:38 R-refRunCounter 0
2013-10-23 18:14:38 R-sign off
2013-10-23 17:53:53 R-statusInfoMinDly 3 s
2013-10-23 17:53:53 R-statusInfoRandom 0 s
2013-10-23 18:14:38 R-transmitTryMax 6
2013-10-23 18:14:37 RegL_00: 02:01 0A:A1 0B:B2 0C:3C 15:FF 18:00 00:00
2013-10-23 18:14:38 RegL_01: 08:00 09:00 0A:00 0B:00 0C:C8 0D:00 0E:C8 0F:05 10:00 30:06 57:06 00:00
2013-11-10 09:07:50 deviceMsg on (to HMLAN1)
2013-11-10 09:07:50 level 100 %
2013-11-10 09:07:50 motor stop:on
2013-11-10 09:07:50 pct 100
2013-10-29 07:09:32 running -
2013-11-10 09:07:50 state on
2013-11-10 09:07:50 timedOn off
Helper:
mId 006A
rxType 1
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
Hmlan1:
avg -71
cnt 1
lst -71
max -71
min -71
At_hmlan1:
avg -69
cnt 2
lst -69
max -69
min -69
Attributes:
alias Jalousie Kueche
autoReadReg 4_reqStatus
devStateIcon Auf:shutter_1 Ab:shutter_closed .*:shutter_4
eventMap on:Auf off:Ab stop:Stop
expert 2_full
firmware 2.2
fp_Erdgeschoss 490,705,2,Rollo
group Jalousie
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room 02_Jalousie,10_Erdgeschoss
serialNr xxxx
subType blindActuator
webCmd Auf:Ab:Stop
Gruß Otto
Ich kann das model nicht erkennen. Wie sieht die Definition aus?
Hallo,
weiss nicht genau was du (noch) brauchst.
Ich habe ein Homematic Model HM-LC-Bl1PBU-FM, TYPE CUL_HM, SubType blindActuator
define Rollo_Kue CUL_HM xxxxxx
attr Rollo_Kue .devInfo 010100
attr Rollo_Kue .stc 30
attr Rollo_Kue alias Jalousie Kueche
attr Rollo_Kue autoReadReg 4_reqStatus
attr Rollo_Kue devStateIcon Auf:shutter_1 Ab:shutter_closed .*:shutter_4
attr Rollo_Kue eventMap on:Auf off:Ab stop:Stop
attr Rollo_Kue expert 2_full
attr Rollo_Kue firmware 2.2
attr Rollo_Kue fp_Erdgeschoss 490,705,2,Rollo
attr Rollo_Kue group Jalousie
attr Rollo_Kue model HM-LC-Bl1PBU-FM
attr Rollo_Kue peerIDs 00000000,
attr Rollo_Kue room 02_Jalousie,10_Erdgeschoss
attr Rollo_Kue serialNr xxxx
attr Rollo_Kue subType blindActuator
attr Rollo_Kue webCmd Auf:Ab:Stop
Wo genau ist die autodetection definiert, dann kann ich vielleicht helfen....
Gruß Otto
attr Rollo_Kue model HM-LC-Bl1PBU-FM
Dies ist das model. HM kennt nur den TYPE CUL_HM. Der Subtyp des Geräte wird über das model abgebildet.
Ich muss also bei autotetection erst den TYPE und je nach TYPE das model oder den type(MAX) berücksichtigen.
Dann kann ich erst bestimmen, ob es sich um eine Heizung handelt oder nicht. Bei Geräten von HM fehlten mit noch Details.
Es gibt eine solche Logik schon - ich muss sie noch ein wenig verändern.
Wenn es fertig, ist checke ist das Modul ein.
Welches Kommando versteht deine Rollo?
set Rollo_Kue on
Hallo,
Kommandos:
on und off = fährt vollständig hoch und runter
up und down = Tippbetrieb
Ich nutze
set Rollo_Kue on
set Rollo_Kue off
Gruß Otto
Ich glaube ich habe es geschafft.
Das Modul habe ich aber noch aus einem anderem Grund verändert. Das muss ich nochmals genau testen, bevor ich es freigebe. Vielleicht ist es morgen früh schon aktiv.
@ Otto
Die zweite Änderung macht noch Ärger.
Heute Abend folgt ein erneuter Test.
Jetzt sollte autodetection für HM funktionieren
Hallo,
habe einen Fehler in Version 4210
2013.11.13 18:11:42 1: reload: Error:Modul 98_Heating_Control deactivated:
Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
Gruß Otto
bitte nochmals updaten
Oha wohl nach Update heute geht nix mehr :
2013.11.13 20:55:12 1: reload: Error:Modul 98_Heating_Control deactivated:
Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
2013.11.13 20:55:12 0: Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
2013.11.13 20:55:12 1: Including ./FHEM/aquarien.cfg
2013.11.13 20:55:12 1: reload: Error:Modul 98_Heating_Control deactivated:
Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
2013.11.13 20:55:12 0: Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
2013.11.13 20:55:12 1: reload: Error:Modul 98_Heating_Control deactivated:
Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
2013.11.13 20:55:12 0: Missing right curly or square bracket at ./FHEM/98_Heating_Control.pm line 769, at end of line
syntax error at ./FHEM/98_Heating_Control.pm line 769, at EOF
Ist im SVN repariert.
Auf die Schnelle selber die fehlende Klammer setzen.
}
return $setModifier;
} # <---- Diese Klammer in Zeile 510 einfügen
}
################################################################################
sub Heating_Control_SetAllTemps() { # {Heating_Control_SetAllTemps()}
Danke ich weiss mir ja zu helfen und hab Backup eingespielt ;D
Wird ja dann morgen dabei sein.
Danke
ich habe gestern abend zu später Stunde noch Teststatements heraus genommen, dabei ist eine } zuviel mit verschwunden. War doch wohl schon zu spät.
Im SVN schon repariert.
Hallo Dietmar,
Nachdem heute früh am Feiertag die Garage automatisch aufging! wurde mir klar dass ich nach dem Einsatz deines Weekdaytimer Moduls noch keine Abfrage für Feiertage eingebaut habe. Da stieß ich auf den Post hier. Die Angabe !$we würde die Sache perfekt lösen, bringt aber eine Fehlermeldung ins LOG. Gibt es da Pläne?
ja, es wird irgendwann eine Erweiterung geben, aber bisher bin ich noch nicht dazu gekommen.
fein, wenn Du es in den nächsten 4 Wochen schaffst, kommt Weihnachten die Testphase.
Hallo,
ich hab heute einen Neustart von FHEM gemacht. Seitdem lädt das Heating Control Modul nicht mehr. Im Log erscheint Folgendes:
2013.12.15 11:55:07 1: reload: Error:Modul 98_Heating_Control deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:07 0: Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:07 3: Please define HC.BadTemp first
2013.12.15 11:55:08 1: reload: Error:Modul 98_Heating_Control deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 0: Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 3: Please define HC.SchlafTemp first
2013.12.15 11:55:08 1: reload: Error:Modul 98_Heating_Control deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 0: Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 3: Please define HC.KuecheTemp first
2013.12.15 11:55:08 1: reload: Error:Modul 98_Heating_Control deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 0: Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 3: Please define HC.WZ1_Temp first
2013.12.15 11:55:08 1: reload: Error:Modul 98_Heating_Control deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 0: Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 3: Please define HC.B_G_Temp first
2013.12.15 11:55:08 1: reload: Error:Modul 98_Heating_Control deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 0: Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_Heating_Control.pm line 118, near "})"
2013.12.15 11:55:08 3: Please define HC.B_K_Temp first
2013.12.15 11:55:10 1: configfile: MaxCounterAT already defined, delete it first
Cannot load module Heating_Control
Please define HC.BadTemp first
Cannot load module Heating_Control
Please define HC.SchlafTemp first
Cannot load module Heating_Control
Please define HC.KuecheTemp first
Cannot load module Heating_Control
Please define HC.WZ1_Temp first
Cannot load module Heating_Control
Please define HC.B_G_Temp first
Cannot load module Heating_Control
Please define HC.B_K_Temp first
2013.12.15 11:55:10 1: Including ./log/fhem.save
2013.12.15 11:55:11 1: statefile: Please define HC.B_G_Temp first
Please define HC.B_G_Temp first
Please define HC.B_G_Temp first
Please define HC.B_G_Temp first
Please define HC.B_K_Temp first
Please define HC.B_K_Temp first
Please define HC.B_K_Temp first
Please define HC.B_K_Temp first
Please define HC.BadTemp first
Please define HC.BadTemp first
Please define HC.BadTemp first
Please define HC.BadTemp first
Please define HC.KuecheTemp first
Kann mir jemand weiterhelfen?
Danke Charles
Hallo,
hab erstmal überprüft, obs neue Dateien gibt und werde erstmal updaten!
Charles
Wenn du weiterhin Probleme hast, veröffentlichte deinen Code, dann kann ich auch helfen.
Hallo Dietmar,
nach dem Update kommen keine Fehlermeldungen mehr. Hatte eine alte Version.
Danke
Charles
Hallo,
habe da mal eine Frage zu HC, weil ich grad am Testen bin...
Ich habe ein HC angelegt mit folgenden Parametern.
define HC_AZO_FHT80B Heating_Control AZO_FHT80B 12345|09:00|21.0 (ReadingsVal("Feiertag", "state", "no") eq "yes")
Wenn ich aber zum Test, den Schaltzeitpunkt auf z.B. 11 Uhr ändere (so geschehen um 10:54 Uhr (siehe unten)...
define HC_AZO_FHT80B Heating_Control AZO_FHT80B 12345|11:00|21.5 (ReadingsVal("Feiertag", "state", "no") eq "yes")
...schaltet HC den FHT nicht erst um 11 Uhr auf 21°C, sondern sofort (siehe unten stehendem Log...) Zusätzlich dazu, macht HC das dann um 11 Uhr aber nochmals. Kann mir einer erklären warum dies so ist?
2014.01.06 10:54:18.562 5: [HC_AZO_FHT80B] Switchingtime: 12345|11:00|21.5 : mo,di,mi,do,fr -> 11:00:00 -> 21.5
2014.01.06 10:54:19.576 5: [HC_AZO_FHT80B] list of windowsenors found: ''
2014.01.06 10:54:19.583 4: [HC_AZO_FHT80B] 03.01.2014 11:00:00 ; aktParam: 21.0 ; newParam: 21.5
2014.01.06 10:54:19.584 4: [HC_AZO_FHT80B] is not disabled
2014.01.06 10:54:19.586 4: [HC_AZO_FHT80B] command: { fhem("set AZO_FHT80B desired-temp 21.5") if(ReadingsVal("Feiertag", "state", "no") eq "yes")} executed
2014.01.06 10:54:19.606 2: FHT set AZO_FHT80B desired-temp 21.5
2014.01.06 10:54:19.837 4: [HC_AZO_FHT80B] Next switch 06.01.2014 11:00:00
2014.01.06 11:00:00.580 5: [HC_AZO_FHT80B] list of windowsenors found: ''
2014.01.06 11:00:00.584 4: [HC_AZO_FHT80B] Jetzt:06.01.2014 11:00:05 -> Next: 06.01.2014 11:00:00 -> Param: 21.5 -5
2014.01.06 11:00:00.589 4: [HC_AZO_FHT80B] 06.01.2014 11:00:00 ; aktParam: 21.5 ; newParam: 21.5
2014.01.06 11:00:00.590 4: [HC_AZO_FHT80B] is not disabled
2014.01.06 11:00:00.592 4: [HC_AZO_FHT80B] Next switch 07.01.2014 11:00:00
Gruß
Thomas
Hallo,
Was bedeutet:
no switch in the yesterdays because of the devices type
nach einem Heating_Control_SetAllTemps()?
Device-Types: PID20 und Dummy.
Beide werden im normalen Ablauf einwandfrei geschaltet, nur läuft Heating_Control_SetAllTemps() ins Leere.
Gruß
Hans
Hallo,
dem Heating_Control-Modul fehlt die Unterstützung für den neuen Homematic Raumthermostat:
Index: 98_Heating_Control.pm
===================================================================
--- 98_Heating_Control.pm (revision 4997)
+++ 98_Heating_Control.pm (working copy)
@@ -486,6 +486,7 @@
"WallMountedThermostat" => 1 },
"CUL_HM" => { "mode" => "model","setModifier" => "desired-temp",
"HM-CC-TC" => 1,
+ "HM-TC-IT-WM-W-EU" => 1,
"HM-CC-RT-DN" => 1 } );
my $dHash = $defs{$hash->{DEVICE}};
Wäre Klasse, wenn diese Änderung ihren Weg ins Repository finden würde.
Danke & Gruß
Michael
kann ich machen!
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.
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).
ich habe von HM keine Ahnung.
@kubuntufan
klar, kann ich einbauen
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.
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
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");
}
}
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?
Hallo,
seit einiger Zeit scheint bei mir Heating_Control fhem zum Absturz zu bringen, wenn Heating_Control_SetAllTemps() aufgerufen wird:
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:
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
So ist es richtig!
Das Problem ist mir noch nicht aufgefallen.
Danke! Ich werde es reparieren und einchecken.
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.
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
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...
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.
Zitat(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.
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.
Zitat von: Dietmar63 am 16 Mai 2014, 19:57:22
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
Zitat
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.
Zitat
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
ich habe eine Version von WD und HC fertiggestellt, die folgende Erweiterung beinhaltet:
mit
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.
sowohl Heating_Control als auch WeekdayTimer um ein
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!
Zitat von: Dietmar63 am 23 Mai 2014, 20:00:44
probiert es mal aus!
Hallo Dietmar,
prima - mach ich gerne. Allerdings erst ab Montag - ich geb dann Feedback. Das wird den Enable/Disable Button auf jeden Fall deutlich vereinfachen.
Gruss
Tobias
Zitat von: Dietmar63 am 23 Mai 2014, 20:00:44
sowohl Heating_Control als auch WeekdayTimer um ein
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!
Hallo Dietmar,
hmm - das funktioniert bei mir noch nicht. Nach dem Update habe ich im Frontend die Kommandos
set wd enable/disable ???
und
set wd refreshAuf der Kommandozeile hat ein
set wd disablekeinerlei Auswirkung, d.h. ich sehe weder das Attribut disable gesetzt noch ein Reading "disabled".
Mache ich was falsch?
Gruss
Tobias
Kannst du prüfen welche Version des Moduls du hast - erste Zeile im Sourcecode
version sagt:
# $Id: 98_WeekdayTimer.pm 5946 2014-05-23 17:41:49Z dietmar63 $
So stehts auch im File. Nach dem Update natürlich ein Restart von FHEM gemacht.
Gruss
Tobias
ich muss wohl noch ein wenig nachbessern, habe aber noch Probleme und komme erst am Sonntag dazu mich wieder darum zu kümmern.
Hallo Dietmar,
es hat ein wenig gedauert, bis ich die Anpassungen (set <wd> enable/disable und das neue Reading disabled) testen konnte, weil ich meinen FHEM Server umgezogen habe.
Besten Dank für die Änderungen, die per se einwandfrei funktionieren. Dennoch habe ich noch einen kleinen Modifikationswunsch, da es mir nicht gelungen ist, das Reading "disabled" in einer readingsGroup mit den Attributen commands und valueIcon vernünftig auszuwerten. Die numerischen Werte 0 und 1 für "disabled" machen hier Schwierigkeiten.
Funktioniert nicht: Edit: Funktioniert doch!
commands { 'disabled.0' => 'set $DEVICE disable', 'disabled.1' => 'set $DEVICE enable' }
valueIcon { 'disabled.0' => 'Restart', 'disabled.1' => 'Shutdown' }
Liefert das Reading "disabled" jedoch stattdessen z.B. die Strings yes und no, funktionieren die readingsGroup Attribute einwandfrei:
commands { 'disabled.no' => 'set $DEVICE disable', 'disabled.yes' => 'set $DEVICE enable' }
valueIcon { 'disabled.no' => 'Restart', 'disabled.yes' => 'Shutdown' }
Hierzu habe ich folgende kleine Änderung im WeekdayTimer Modul vorgenommen:
[s]# /var/tmp/busybox diff -u 98_WeekdayTimer.pm 98_WeekdayTimer.pm.orig
--- 98_WeekdayTimer.pm
+++ 98_WeekdayTimer.pm.orig
@@ -97,8 +97,7 @@
if( $attrName eq "disable" ) {
my $hash = $defs{$name};
- my $value = ( $attrVal eq '1') ? "yes" : "no";
- readingsSingleUpdate ($hash, "disabled", $value, 1);
+ readingsSingleUpdate ($hash, "disabled", $attrVal, 1);
}
return undef;
}
[/s]
Könntest Du die Modifikation bitte so in WeekdayTimer (und ggf. Heating_Control etc) übernehmen? Edit: Nicht nötig.
Danke & Gruss
Tobias
Ja, könnte ich. Aber ist das nicht eher ein Problem von Readings group und der dortigen Implementierung? Id wenn schon ein allgemeines Modul existiert, muss es auch mit allem was es so gibt, fertig werden.
Hallo Dietmar,
ich werde gerne bei Andre nachfragen, ob readingsGroup da wirklich eine Einschränkung hat. Dann wäre es natürlich sinnvoller, es dort zu fixen. Vielleicht mache ja auch ich etwas falsch.
Ich dachte nur, da Du die Änderung mit dem disabled reading auf meinen Wunsch eingearbeitet hast, wäre es so einfacher.
Gruss
Tobias
Mal schauen was bei der Recherche heraus kommt.
Wenn es nicht anders möglich ist, kann ich natürlich ändern.
Jetzt steh ich dumm da.
Andre konnte das Problem nicht nachvollziehen - siehe http://forum.fhem.de/index.php/topic,14425.msg175735.html#msg175735 (http://forum.fhem.de/index.php/topic,14425.msg175735.html#msg175735)
Heute vormittag habe gefühlt stundenlang an der readingsGroup rumgeschraubt - und es nicht zum Laufen gebracht. Erst als ich o.g. Änderungen beim WD Modul eingeführt habe.
Jetzt habe ich noch einmal von scratch mit zwei dummy Timern eine Test readingsGroup definiert. Und es funktioniert auf Anhieb auch mit "disabled" = [0|1] !!
Mittlerweile habe ich auch meine eigentliche readingsGroup mit den zwei Bewässerungs-Timern wieder rückgebaut - und es klappt auch....
Ich kann es mir nur so erklären, dass ich irgendwo einen kleinen Typo (z.B. disable statt disabled o.ä.) drin hatte.
Alles gut. Danke & Gruss
Tobias
Na, super. Manchmal ist das so.
Gibt es eine Möglichkeit die (Perl basierten) Schaltzeiten beim WeekdayTimer per Kommando zu aktualisieren? Ich habs mit:
WeekdayTimer_SetAllParms ()
probiert, aber da ändert sich nichts an den Schaltzeiten.
Der Hintergrund dazu ist, dass ich 2 WeekdayTimer im Betrieb habe, welche Lichter in 2 Räumen schalten. Dabei habe ich die Ausschaltzeit des 1. and die Anschaltzeit des 2. WDT gekoppelt. Das habe ich realisiert, indem ich mit:
my $datetime = ReadingsVal($weektimer,"nextUpdate","20.12.2014 $fallback");
die nächste Schaltzeit des 2. WDT auslese. Ist nicht sehr robust, aber ich habe keine andere Möglichkeit gefunden und es funktioniert erstmal. Bin aber offen für bessere Vorschläge dies zu lösen.
Ein Problem besteht mit dieser Methode allerdings. Wenn ich z.B. die FHEM Konfig neu einlese, hat der 2. WDT noch keine echte Anschaltzeiten und das NextUpdate ist innerhalb von einer Minute oder so, was sich der 1. WDT dann als Auschaltzeit annimmt.
Das ist problematisch, wenn der 1. WDT noch gar nicht an ist, da er kann es sein, dass die Lampe des 1.WDT bis zum nächsten Tag durchläuft.
Daher möchte ich sobald der 1.WDT anschaltet, die Schaltzeiten auffrischen, damit der 1. WDT eine richtige Ausschaltzeit für den Tag gesetzt bekommt.
Die automatische Aktualisierung um Mitternacht reicht nicht aus, da dass in den meisten Fällen schon zu spät ist.
Vielen Dank für eure Hilfe.
Gruß,
Sebastian
Hallo,
ist es sinnvoll, um ggf mehr Möglichkeiten zu haben, die neue Funktion set wd enable/disable zu nutzen.
Habe zur Zeit viele Profile die ich mit einer Funktion auf inactive setze, so was wie
define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
Klingt gut... :)
Hallo,
ich benutze den WeekDayTimer derzeit, um den State von RESIDENTS/HOMEMATE zeitabhängig zu setzten, da ich bisher keine automatische Presents-Funktionalität habe (soll später kommen). Was ich noch nicht hinbekommen habe, ist den Parameter $we bzw. !$we als Wochentag zu verwenden, um nicht nur die Wochenenden, sondern auch die Feier- und Urlaubstage berücksichtigen zu können. IMO einer der Hauptvorteile einer Fhem/WeekDayTimer-basierten Steuerung gegenüber den eingebauten Homematik Zeitprofilen. Könnte jemand mal ein Beispiel zeigen, bei dem es funktioniert? Oder ist das vielleicht noch nicht implementiert?
Hallo,
Ich denke du benötigst holiday2we. Siehe Commandref unter global.
Gruß
Hans
holiday2we habe ich schon eingerichtet, d.h., als Bedingung kann ich we und !we verwenden. Allerdings funktioniert es irgendwie nicht, wenn ich $we als Wochentag angebe. Also z.B.:
rgr_Bewohner !$we|06:45|awoken $we|09:00|awoken 1234567|24:00|asleep
statt
rgr_Bewohner 12345|06:45|awoken 67|09:00|awoken 1234567|24:00|asleep
Das geht auch nicht!
Es gibt aber eine andere Möglichkeit. Poste ich gleich vom PC.
Macht es so:
Erstellt eine Funktion anOderAus() in 99_myUtils und ruft sie als Bedingung in HC auF.
Der Funktion anOderAus() geben wir einen Schalter mit, ob sie am WE gelten soll oder nicht:
define Heizung Heating_Control Wandthermostat_Wohnzimmer 12345|05:30|20.5 12345|07:30|17 12345|16:30|21 12345|22:00|15 (anOderAus(0))
define Heizung_WE Heating_Control Wandthermostat_Wohnzimmer 1234567|07:45|19 1234567|08:30|20.5 1234567|11:00|18 1234567|16:00|21 1234567|22:30|15 (anOderAus(1))
anOderAus() in 99_myUtils.pm(mit Logging - kann später auskommentiert/gelöscht werden). In anOderAus() steht $we nicht zur Verfügung. Deshalb müssen wir es selbst errechnen. Im dummy HCAutomatik kann die Heizung komplet an oder ausgeschaltet werden:
sub anOderAus($) {
my ($testWe) = @_;
#we ermitteln
my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime;
my $we = (($wday==0 || $wday==6) ? 1 : 0);
if(!$we) {
my $h2we = $attr{global}{holiday2we};
$we = 1 if($h2we && $value{$h2we} && $value{$h2we} ne "none");
}
$testWe = $we if (!defined($testWe));
Log 3, "testWe------------>$testWe";
Log 3, "we------------>$we";
my $state = ReadingsVal("HCAutomatik", "state", "");
Log 3, "state------------>$state";
my $ret = ($state eq "on" && $testWe == $we);
Log 3, "ret------------>$ret";
return $ret;
}
Zitat von: Basti am 21 Dezember 2014, 18:51:25
Gibt es eine Möglichkeit die (Perl basierten) Schaltzeiten beim WeekdayTimer per Kommando zu aktualisieren? Ich habs mit:
WeekdayTimer_SetAllParms ()
probiert, aber da ändert sich nichts an den Schaltzeiten.
Der Hintergrund dazu ist, dass ich 2 WeekdayTimer im Betrieb habe, welche Lichter in 2 Räumen schalten. Dabei habe ich die Ausschaltzeit des 1. and die Anschaltzeit des 2. WDT gekoppelt. Das habe ich realisiert, indem ich mit:
my $datetime = ReadingsVal($weektimer,"nextUpdate","20.12.2014 $fallback");
die nächste Schaltzeit des 2. WDT auslese. Ist nicht sehr robust, aber ich habe keine andere Möglichkeit gefunden und es funktioniert erstmal. Bin aber offen für bessere Vorschläge dies zu lösen.
Ein Problem besteht mit dieser Methode allerdings. Wenn ich z.B. die FHEM Konfig neu einlese, hat der 2. WDT noch keine echte Anschaltzeiten und das NextUpdate ist innerhalb von einer Minute oder so, was sich der 1. WDT dann als Auschaltzeit annimmt.
Das ist problematisch, wenn der 1. WDT noch gar nicht an ist, da er kann es sein, dass die Lampe des 1.WDT bis zum nächsten Tag durchläuft.
Daher möchte ich sobald der 1.WDT anschaltet, die Schaltzeiten auffrischen, damit der 1. WDT eine richtige Ausschaltzeit für den Tag gesetzt bekommt.
Die automatische Aktualisierung um Mitternacht reicht nicht aus, da dass in den meisten Fällen schon zu spät ist.
Vielen Dank für eure Hilfe.
Gruß,
Sebastian
Du könntest es folgendermaßen machen:
Du definiert nur einen WD
define xxx WeekdayTimer 16:00|an1 17:00|an2 18:00:aus {meineFunktion("@", "%")} Dann bekommst du in meineFunktion() das device und den Value {an1, an2, aus } übermittelt und kannst selbst schalten mit:
fhem ("set lampe1 an")
fhem ("set lampe1 aus;; set lampe2 an")
fhem ("set lampe2 aus)
Zitat
Erstellt eine Funktion anOderAus() in 99_myUtils und ruft sie als Bedingung in HC auF.
Der Funktion anOderAus() geben wir einen Schalter mit, ob sie am WE gelten soll oder nicht:
Danke für das Beispiel. Demnach kann $we auch nicht in der Condition direkt verwendet werden? Hatte bisher angenommen, dass das ginge, da es relativ am Anfang auch als Beispie genannt wurde, habe aber immer nur die Verwendung von $we als Tag versucht, da man damit nur einen Timer benötigen würde. Ich probiere es dann mit der Hilfsfunktion und zwei Timern...
Doch das funktioniert meines Wissens, weil dem Ausdruck der in WD ausgeführt wird, im Gegensatz zu den Funktionen in 99_myUtils.pm der Zeitkontext($we, $wday, $hash, $mday...) bereitstellt wird.
Ich überlege mal, wie man das ändern kann, es führt nämlich immer wieder zu Missverständnissen.
Irgendetwas ist aber anders: Bei zwei Timern, einer mit der Condition ($we) und einer mit der Condition (!$we), stehen beide nach einem WeekdayTimer_setAllParams() auf "inactive". Einer sollte aber aktiv sein.
@chriss:
Veröffentliche mal die genauen Definitionen
Schalte mal verbose 5 ein. Ggf Logging einbauen.
Zitat von: Dietmar63 am 03 Januar 2015, 20:42:10
Du könntest es folgendermaßen machen:
Du definiert nur einen WD
define xxx WeekdayTimer 16:00|an1 17:00|an2 18:00:aus {meineFunktion("@", "%")}
Das schaut nach einer wunderbaren Lösung aus, danke!
Ich habe, wie gesagt, zwei Timer definiert:
define ResidentsStateTimer_Free WeekdayTimer rgr_Bewohner 09:00|awoken 11:00|home 20:10|absent 24:00|asleep ($we)
define ResidentsStateTimer_Work WeekdayTimer rgr_Bewohner 06:45|awoken 07:15|home 08:00|absent 15:00|home 20:10|absent 24:00|asleep (!$we)
Grundsätzlich scheint das Schalten auch zu gehen. Heute um 20:10 hat der *_Free geschaltet, der *_Work aber nicht:
2015.01.04 20:10:00 4: [ResidentsStateTimer_Work] Jetzt:04.01.2015 20:10:05 -> Next: 04.01.2015 20:10:00 -> Param: absent -5.00384211540222
2015.01.04 20:10:00 5: [ResidentsStateTimer_Work] list of senors found: 'ResidentsStateTimer_Work'
2015.01.04 20:10:00 4: [ResidentsStateTimer_Work] 04.01.2015 20:10:00 ; aktParam: 0 ; newParam: absent
2015.01.04 20:10:00 4: [ResidentsStateTimer_Work] is not disabled
2015.01.04 20:10:00 4: [ResidentsStateTimer_Work] command: { fhem("set rgr_Bewohner absent") if(!$we)} executed
2015.01.04 20:10:00 4: [ResidentsStateTimer_Work] Next switch 05.01.2015 00:00:00
2015.01.04 20:10:00 5: [ResidentsStateTimer_Work] removing Timer: ResidentsStateTimer_Work_Update
2015.01.04 20:10:00 5: [ResidentsStateTimer_Work] setting Timer: ResidentsStateTimer_Work_Update 05.01.2015 00:00:00
2015.01.04 20:10:00 4: [ResidentsStateTimer_Free] Jetzt:04.01.2015 20:10:05 -> Next: 04.01.2015 20:10:00 -> Param: absent -5.01038002967834
2015.01.04 20:10:00 5: [ResidentsStateTimer_Free] list of senors found: 'ResidentsStateTimer_Free'
2015.01.04 20:10:00 4: [ResidentsStateTimer_Free] 04.01.2015 20:10:00 ; aktParam: 0 ; newParam: absent
2015.01.04 20:10:00 4: [ResidentsStateTimer_Free] is not disabled
2015.01.04 20:10:00 4: [ResidentsStateTimer_Free] command: { fhem("set rgr_Bewohner absent") if($we)} executed
2015.01.04 20:10:00 2: RESIDENTS set rgr_Bewohner absent
2015.01.04 20:10:00 4: [ResidentsStateTimer_Free] Next switch 05.01.2015 00:00:00
2015.01.04 20:10:00 5: [ResidentsStateTimer_Free] removing Timer: ResidentsStateTimer_Free_Update
2015.01.04 20:10:00 5: [ResidentsStateTimer_Free] setting Timer: ResidentsStateTimer_Free_Update 05.01.2015 00:00:00
Wenn ich aber {WeekdayTimer_SetAllParms()} aufrufe (in diesem Fall kurz danach, der *_Free sollte also auf "absent" stehen), dann gehen beide auf inactive:
2015.01.04 20:18:29 5: Cmd: >{WeekdayTimer_SetAllParms ()}<
2015.01.04 20:18:29 5: Triggering ResidentsStateTimer_Free (1 changes)
2015.01.04 20:18:29 5: Notify loop for ResidentsStateTimer_Free inactive
2015.01.04 20:18:29 5: statistics Verbraucher1_Statistics: Notify.260 Notification of 'ResidentsStateTimer_Free' received. Device not monitored.
2015.01.04 20:18:29 5: ResidentsStateController: not on any display, ignoring notify
2015.01.04 20:18:29 4: eventTypes: WeekdayTimer ResidentsStateTimer_Free inactive -> inactive
2015.01.04 20:18:29 4: eventTypes: WeekdayTimer ResidentsStateTimer_Free state: inactive -> state: inactive
2015.01.04 20:18:29 5: rg_battery: not on any display, ignoring notify
2015.01.04 20:18:29 5: Triggering ResidentsStateTimer_Work (1 changes)
2015.01.04 20:18:29 5: Notify loop for ResidentsStateTimer_Work inactive
2015.01.04 20:18:29 5: statistics Verbraucher1_Statistics: Notify.260 Notification of 'ResidentsStateTimer_Work' received. Device not monitored.
2015.01.04 20:18:29 5: ResidentsStateController: not on any display, ignoring notify
2015.01.04 20:18:29 4: eventTypes: WeekdayTimer ResidentsStateTimer_Work inactive -> inactive
2015.01.04 20:18:29 4: eventTypes: WeekdayTimer ResidentsStateTimer_Work state: inactive -> state: inactive
2015.01.04 20:18:29 5: rg_battery: not on any display, ignoring notify
2015.01.04 20:18:29 3: WeekdayTimer_SetAllParms() done!
Noch eine Ergänzung: Wenn ich z.B. die Condition im *_Free Timer von "($we)" auf "(1)" ändere, dann klappt auch das WeekdayTimer_SetAllParms ():
2015.01.04 21:41:23 5: Cmd: >{WeekdayTimer_SetAllParms ()}<
2015.01.04 21:41:23 5: [ResidentsStateTimer_Free] list of senors found: 'ResidentsStateTimer_Free'
2015.01.04 21:41:23 4: [ResidentsStateTimer_Free] 04.01.2015 20:10:00 ; aktParam: 0 ; newParam: absent
2015.01.04 21:41:23 4: [ResidentsStateTimer_Free] is not disabled
2015.01.04 21:41:23 4: [ResidentsStateTimer_Free] command: { fhem("set rgr_Bewohner absent") if(1)} executed
2015.01.04 21:41:23 5: Cmd: >{ fhem("set rgr_Bewohner absent") if(1)}<
2015.01.04 21:41:23 5: Cmd: >set rgr_Bewohner absent<
2015.01.04 21:41:23 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2015.01.04 21:41:23 2: RESIDENTS set rgr_Bewohner absent
Any ideas?
98_Heating_Control, 98_WeekdayTimer:
big refactoring update with some minor improvements.
from now it is possible to define $we or !$we in daylist to easily allow weekend an holiday. $we !$we are coded as 7 8, when using a numeric daylist.
Some examples:
define hc WeekdayTimer HeizungKueche de 7|23:35|25 34|23:30|22 23:30|16 23:15|22 8|23:45|16
define hc WeekdayTimer HeizungKueche de fr,$we|23:35|25 34|23:30|22 23:30|16 23:15|22 12|23:45|16
define hc WeekdayTimer HeizungKueche de 20:35|25 34|14:30|22 21:30|16 21:15|22 12|23:00|16
define hw WeekdayTimer HeizungKuech de mo-so,$we|{sunrise_abs_dat($date)}|18 mo-so,$we|{sunset_abs_dat($date)}|22 ;
define ht WeekdayTimer HeizungKuech de mo-so,!$we|{sunrise_abs_dat($date)}|18 mo-so,!$we|{sunset_abs_dat($date)}|22 ;
define hh WeekdayTimer HeizungKuech de {sunrise_abs_dat($date)}|19 {sunset_abs_dat($date)}|21 ;
define hx WeekdayTimer HeizungKueche de 22:35|25 23:00|16
The daylist can be given globaly for the whole WD, HC:
define HeizungWohnen_an_wt Heating_Control HeizungWohnen de !$we 09:00|19 (heizungAnAus("Ein"))
define HeizungWohnen_an_we Heating_Control HeizungWohnen de $we 09:00|19 (heizungAnAus("Ein"))
define HeizungWohnen_an_we Heating_Control HeizungWohnen de 78 09:00|19 (heizungAnAus("Ein"))
define HeizungWohnen_an_we Heating_Control HeizungWohnen de 57 09:00|19 (heizungAnAus("Ein"))
define HeizungWohnen_an_we Heating_Control HeizungWohnen de fr,$we 09:00|19 (heizungAnAus("Ein"))
Hallo,
seit dem Update erhalte ich bei jedem Vorgang von Heating_Control folgende Meldungen im Log.
2015.03.29 15:00:00 3: eval: {( 1 && ($wday ~~ [0,1,2,3,4,5,6]))}
2015.03.29 15:00:00 1: PERL WARNING: Smartmatch is experimental at (eval 1014) line 1.
2015.03.29 15:00:00 3: eval: {( 1 && ($wday ~~ [1]))}
2015.03.29 15:00:00 1: PERL WARNING: Smartmatch is experimental at (eval 1012) line 1.
Diese haben wahrscheinlich nichts schlimmes zu bedeuten. Kann man diese dann bitte unterdrücken.
Besten Dank
Dirk
Kannst du erst mal ignorieren. Muß ich umbauen, wird aber dauern.
@ Dietmar63
Einmal zur Info!
Seit dem Update funktioniert Heating_Control_SetAllTemps() nicht mehr.
Auszug aus dem Logfile: {Heating_Control_SetAllTemps()}: Undefined subroutine &main::Heating_Control_SetTimer called at ./FHEM/98_Heating_Control.pm line 110.
Gruß Zicki
Ja, diesen Fehler hab ich auch :-\
Heute morgen haben die Heating_Controls noch hochgeregelt, aber dann war der Status "inactive" :o
Ich habe seit gestern oder vorgestern das hier im Log stehen:
[KZ_Heizungsregelung] "7" in daylist now means $we(weekend) - see dokumentation!!!
Steht die Wochentagsnummer 7 jetzt nicht mehr für Sonntag, sondern global für WE und damit auch für Samstag?!
Außerdem massenhaft
PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159
Bin mir aber nicht sicher ob die vom Heatingcontrol kommen, hat jemand ähnliche Beobachtungen?
Danke :)
[Edit] Ach ja, gerade noch gesehen, dass heute früh bei mir auch zwar alle Heatings hochgeregelt haben, jetzt aber ausnahmslos auf inactive stehen...
hallo dietmar,
im logProxy gibt es die möglichkeit wochenprofile in einem plot darzustellen. das funktioniert für max, homematic und mit der alten WeekdayTimer und Heating_Control version. für WeeldayTimer habe ich bis dazu bis jetzt {helper}{SWITCHINGTIME} ausgewertet weil das schon aufbereitet und sprachunabhängig war.
seit dem letzten update hat sich intern aber einiges geändert so das das so nicht mehr funktioniert.
hast du einen vorschlag wie ich (oder auch andere frontend module) an die aufbereiteten schaltzeiten komme?
ideal wäre eine datenstruktur die für jeden tag die zeiten und den zu schaltenden wert enthält so wie es mit SWITCHINGTIME der fall war.
ein weiterer anwendungsfall wäre auch die grafische konfiguration über widgets wie die hier vorgestellten: http://forum.fhem.de/index.php/topic,32660.0.html (http://forum.fhem.de/index.php/topic,32660.0.html).
gruss
andre
Hatte nach dem Update auch nur noch Fehler :'(
Hab dann alle Definitionen geändert (wegen 7 für WE), danach waren zumindest die Fehler/Meldungen im Log fast Weg.
Aber das wirkliche Problem, alle HC Definitionen gingen auf "inactive" und das wars dann.
Bin wieder auf die alte version zurück.
Bin gerade nicht in der Lage schnell zu helfen. Ab Ostermontag können wir uns kurzschliessen.
Bin auch erst mal wieder zurück auf die Dez.-Version. Insofern bei mir erstmal Entspannung ;)
Versteh ich das richtig, das ein Update im Moment nicht angeraten ist, weil das Heizprogramm dann nicht mehr richtig funktioniert?
Ich kümmere mich gleich darum. Morgen ist eine neue Version verfügbar.
Zitat von: Dietmar63 am 06 April 2015, 19:05:44
Ich kümmere mich gleich darum. Morgen ist eine neue Version verfügbar.
War nicht böse gemeint und will auch keine Hektik verbreiten, wollte nur kurz nachfragen, da ich es hier gelesen hatte. ;)
eingecheckt:
folgende Probleme sind behoben:
http://forum.fhem.de/index.php/topic,34711.0.html (http://forum.fhem.de/index.php/topic,34711.0.html)
http://forum.fhem.de/index.php/topic,35792.0.html (http://forum.fhem.de/index.php/topic,35792.0.html)
http://forum.fhem.de/index.php/topic,10011.msg279507.html#msg279507 (http://forum.fhem.de/index.php/topic,10011.msg279507.html#msg279507)
Zitat
Ich habe seit gestern oder vorgestern das hier im Log stehen:
[KZ_Heizungsregelung] "7" in daylist now means $we(weekend) - see dokumentation!!!
Steht die Wochentagsnummer 7 jetzt nicht mehr für Sonntag, sondern global für WE und damit auch
ja, das ist so.
Ich habe mich aus verschiedenen Gründen entschieden die Tagesangabe wie in DOIF zu ändern.
0 Sonntag
1 Montag
2 Dienstag
3 Mittwoch
4 ...
7 Wochenende ($we)
8 Wochentag (!$we)
Definitionen bitte verändern(commandRef muss ich noch anpassen, sollte aber selbsterklärend sein) Beispiele:
http://forum.fhem.de/index.php/topic,10011.msg278781.html#msg278781 (http://forum.fhem.de/index.php/topic,10011.msg278781.html#msg278781)
noch offen:
- LogProxy
- manchmal wird
inactive angezeigt. Verbesserung noch in Arbeit.
Die HC und WD laufen aber. Ihr könnt das überprüfen, indem ihr verbose auf 4 oder 5 setzt.
Ich bekomme immer noch folgenden Fehler
notify_Heating return value: Undefined subroutine &main::Heating_Control_SetTimer called at ./FHEM/98_Heating_Control.pm line 110.
Das klingt super, aber ich habe noch eine Verständnisschwierigkeit...
Prüft WeekdayTimer an einem Tag, ob gleichzeitig Wochenende bzw. Feiertag ist?
Konkretes Beispiel:
Ich habe "Weckzeiten" für die normale Woche, den Samstag, den Sonntag.
Jetzt möchte ich eigentlich nur, dass ich an einem Feiertag nicht wie an einem normalen Wochentag geweckt werde.
Meine aktuelle Anpassung der WeekdayTimer-Definition an die jetzige Änderung sieht so aus:
HomeStatus Mo-Fr|05:45|home Sa|07:30|home So,$we|08:00|home (ReadingsVal("Bewohner","state","") eq "anwesend")
Dementsprechend werden auch die Profile ausgegeben:
Profil 0: Sonntag 08:00:00 home
Profil 1: Montag 05:45:00 home
Profil 2: Dienstag 05:45:00 home
Profil 3: Mittwoch 05:45:00 home
Profil 4: Donnerstag 05:45:00 home
Profil 5: Freitag 05:45:00 home
Profil 6: Samstag 07:30:00 home
Profil 7: Wochenende 08:00:00 home
Zurück zur Frage...
- wird nun an einem Samstag, der ja gleichzeitig auch WE ist, um 7:30 oder um 8:00 Uhr geschaltet?
- wird an einem Feiertag-Montag, wie jetzt Ostermontag gewesen wäre, um 5:45 oder um 8:00 Uhr geschaltet?
- wie müsste ich es korrekt definieren, um "nur" einen Feiertag wie einen Sonntag zu behandeln?
Bitte keine Antwort "warte es doch ab und lass Dich überraschen"; es geht um das Verständnis und die richtige Konfiguration. :-[
Gruß,
Hollo
Hallo!
Nach dem Update von gestern habe ich trotzdem noch mehrere "Heating_Control define" als inactive!
Gab es nicht mit dem Update ein fix?
Nutze dieses Modul schon eine ganze Weile und bis jetzt noch nie Probleme damit gehabt.
Mfg Steffen
In meinem letzten Post habe ich geschrieben, dass es genau damit und mit log Proxy noch nicht behobene Probleme gibt. Die Lösungen sind in Arbeit.
Die timer laufen aber. Das kannst du mit verbose 4 auf den HC, WD prüfen.
Zitat
noch offen:
- LogProxy
- manchmal wird inactive angezeigt.
mit der heute eingecheckten Version sind diese Probleme auch behoben.
HC und WD stehen damit wieder wie zuvor zur Verfügung.
hier noch einige Hinweise:
http://forum.fhem.de/index.php/topic,10011.msg283379.html#msg283379
(http://forum.fhem.de/index.php/topic,10011.msg283379.html#msg283379)
Hallo!
Leider funkt es immer noch nicht, siehe Anhang...
Habe aber heute beim Update auch nur das Update für WeekdayTimer bekommen, nicht für Heating_Control!
Mfg Steffen
was funktioniert denn deine Meinung nach nicht?
bekommst du noch Fehlermeldungen im log?
Wie sehen die Definitionen der timer aus, die nicht funktionieren?
@Steffen:
hast du es jetzt allein geschafft?
Hallo,
Entshuldige bitte, hatte vergessen zu antworten!
Nach einem Restart habe ich zwar immer noch das "inactiv" immer unterschiedlich bei den einzelnen define,
aber die Timer funktionieren in der Tat korrekt.
Ich werde morgen mal ein log hier posten.
Mfg Steffen
Dann liegt es an der Reihenfolge wann sie beim Start definiert werden. Wichtig ist, dass Twilight früher definiert sein muss!!!
Vielleicht kannst du doch mal die Definitionen posten.
Hatte seit Deinen Modulupdates auch massive Probleme mit Fehlermeldungen, die letztlich auf falsche Reihenfolge aufeinander aufbauender Variablendefinitionen bei voneinander abhängigen Modulen herrührten.
Hab da heute mal wieder massiv in fhem.cfg rumgedoktert, was man ja nach Aussagen von Spezialisten hier im Forum nicht machen sollte und völlig unnötig wäre.
Meine Frage dazu - wie bekomme ich bestimmte Definitionen an den Beginn der fhem.cfg gepinnt? Bitte nicht durch löschen und neu anlegen - ist bei weekdaytimern und HC nicht zielführend, weil zu aufwändig.
Blöde Frage, wie ist denn der genau Syntax für windowSensor, wenn ich mehrere Fenster habe?
attr windowSensor Fenster1,Fenster2,Fenster3
oder
attr windowSensor Fenster1 Fenster 2 Fenster3
Wenn ich Variante zwei mache, meldet mit das Modul kein waiting... und die Fenster sind "nur" Text
Wenn ich Variante eins mache, sind die Fenster Links
Zitat von: det. am 12 April 2015, 22:30:07
Hatte seit Deinen Modulupdates auch massive Probleme mit Fehlermeldungen, die letztlich auf falsche Reihenfolge aufeinander aufbauender Variablendefinitionen bei voneinander abhängigen Modulen herrührten.
Hab da heute mal wieder massiv in fhem.cfg rumgedoktert, was man ja nach Aussagen von Spezialisten hier im Forum nicht machen sollte und völlig unnötig wäre.
Meine Frage dazu - wie bekomme ich bestimmte Definitionen an den Beginn der fhem.cfg gepinnt? Bitte nicht durch löschen und neu anlegen - ist bei weekdaytimern und HC nicht zielführend, weil zu aufwändig.
Keine Ahnung - ich editiere immer direkt in der fhem.cfg egal was die selbsternannten Spezialisten so sagen
Zitat von: det. am 12 April 2015, 22:30:07
Hatte seit Deinen Modulupdates auch massive Probleme mit Fehlermeldungen, die letztlich auf falsche Reihenfolge aufeinander aufbauender Variablendefinitionen bei voneinander abhängigen Modulen herrührten.
Hab da heute mal wieder massiv in fhem.cfg rumgedoktert, was man ja nach Aussagen von Spezialisten hier im Forum nicht machen sollte und völlig unnötig wäre.
Meine Frage dazu - wie bekomme ich bestimmte Definitionen an den Beginn der fhem.cfg gepinnt? Bitte nicht durch löschen und neu anlegen - ist bei weekdaytimern und HC nicht zielführend, weil zu aufwändig.
Ich bin auch kein Fan von "in der cfg editieren", aber die Reihenfolge der Devices lassen sich nur so verändern.
Ich kopiere immer die cfg in einen "vernüftigen" Editor und arbeite da. Danach kopiere ich alles zurück.
Ich würde (und habe es so gemacht) alle Heatig_Control Devices ganz ans Ende der cfg setzten. Seit dem habe ich beim Start keine Fehler mehr.
@Dietmar: kannst Du kurz mal wegen den Fenster schauen? Danke!
Zitat von: Mitch am 13 April 2015, 16:38:07
Blöde Frage, wie ist denn der genau Syntax für windowSensor, wenn ich mehrere Fenster habe?
attr windowSensor Fenster1,Fenster2,Fenster3
oder
attr windowSensor Fenster1 Fenster 2 Fenster3
Wenn ich Variante zwei mache, meldet mit das Modul kein waiting... und die Fenster sind "nur" Text
Wenn ich Variante eins mache, sind die Fenster Links
lt. Code sollte die Leerzeichenvariante die richtige sein.
Ich prüfe nachher mal ob es einen Grund gibt, warum es nicht funktioniert.
ZitatReihenfolge der Devices Heating_Control Weekdaytimer
eventuell kann ich das Problem dadurch entschärfen, dass im Code etwas verändere.
Gestern habe ich gesehen dass das Setzen der InternalTimer() nicht direkt aus der Funktion *_Define() heraus erfolgen darf, wenn beispielsweise $we abgefragt wird.
Die timer dürfen erst dann gesetzt werden, wenn holiday initialisiert ist. Eventuell löst diese Umstellung auch das Problem der Reihenfolge in der Initphase der Geräte.
Ich würde eine Funktionserweiterung deines Modules benötigen um mit einem "Heating_Control_SetAllTemps" nur gezielt ein Device zu aktualisieren.
Heating_Control_SetAllTemps(DeviceName) wäre sinnvoll.
Ich habe nämlich das Problem das ich meine Heizungen in einem Scene zusammengefasst habe.
Wenn ich das Scene nun wechsle werden alle Heizungen mehrmals aktualisiert, da mehrmals ein "Heating_Control_SetAllTemps" ausgeführt wird.
Was meinst du? Lässt sich das integrieren?
Ja, dass lässt sich integrieren.
eingecheckt:
Zitat
98_WeekdayTimer, 98_Heating_Control: some improvements to set Parameter/Temperature of a past switch when starting/defining a WD or HC.
Improvements to corectly set state to active/<temp>/<Param>
new funktions:
WeekdayTimer_SetParm("<devicename>")
Heating_Control_SetTemp("<devicename>")
Hallo Dietmar,
seit einem FHEM-Update heute morgen stehen zwei meiner Heating_Control Devices auf state inactive.
Hier die Ausgabe von einem list:
Internals:
COMMAND {}
DEF DG.SZ.MAX.Room Mo-So|09:30|18.0 Mo-So|16:00|16.0 {}
DEVICE DG.SZ.MAX.Room
GlobalDaylistSpec
LANGUAGE de
NAME DG.SZ.MAX.HCB
NR 354
Profil 0: Sonntag 09:30:00 18.0, 16:00:00 16.0
Profil 1: Montag 09:30:00 18.0, 16:00:00 16.0
Profil 2: Dienstag 09:30:00 18.0, 16:00:00 16.0
Profil 3: Mittwoch 09:30:00 18.0, 16:00:00 16.0
Profil 4: Donnerstag 09:30:00 18.0, 16:00:00 16.0
Profil 5: Freitag 09:30:00 18.0, 16:00:00 16.0
Profil 6: Samstag 09:30:00 18.0, 16:00:00 16.0
STATE inactive
TYPE Heating_Control
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1429518809.10066
VALUE inactive
Readings:
2015-04-20 09:30:00 nextUpdate 16:00:00
2015-04-20 09:30:00 nextValue 16.0
2015-04-20 10:33:29 state inactive
SWITCHINGTIMES:
Mo-So|09:30|18.0
Mo-So|16:00|16.0
Timer:
Dg.sz.max.hcb_16:00:00:
HASH DG.SZ.MAX.HCB
MODIFIER 16:00:00
NAME DG.SZ.MAX.HCB_16:00:00
Dg.sz.max.hcb_settimerofday:
HASH DG.SZ.MAX.HCB
MODIFIER SetTimerOfDay
NAME DG.SZ.MAX.HCB_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
DESIRED_TEMP_READING
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:30:00 18.0
16:00:00 16.0
1:
09:30:00 18.0
16:00:00 16.0
2:
09:30:00 18.0
16:00:00 16.0
3:
09:30:00 18.0
16:00:00 16.0
4:
09:30:00 18.0
16:00:00 16.0
5:
09:30:00 18.0
16:00:00 16.0
6:
09:30:00 18.0
16:00:00 16.0
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
09:30:00:
NEXTPARA 16.0
NEXTSWITCH 16:00:00
PARA 18.0
TIM 1429515000
TAGE:
0
1
2
3
4
5
6
16:00:00:
NEXTPARA 18.0
NEXTSWITCH 09:30:00
PARA 16.0
TIM 1429538400
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
room 2.00_Heizung
Nachdem ich einen neuen Schaltzeitpunkt zum Testen hinzugefügt habe, wurde auch geschaltet und der korrekte State (Temperatur) wurde angezeigt. Aber nach Löschen von diesem Schaltzeitpunkt ging das Device zurück auf inactive. Ich bin mir nicht sicher, was du mit dem state inactive anzeigen möchtest. Aber ich benötige für meine Module, die Möglichkeit den aktuellen Wert des Heating_Control Devices abzufragen. Entweder sollte der aktuelle Werte in state stehen, oder ich bräuchte eine andere Möglichkeit (z.B. ein zusätzliches Reading).
Gruß,
Gero
Super Sache Dietmar, ich teste es gleich mal. Danke!
Zitat von: gero am 20 April 2015, 11:38:32
Hallo Dietmar,
seit einem FHEM-Update heute morgen stehen zwei meiner Heating_Control Devices auf state inactive.
Hier die Ausgabe von einem list:
Internals:
COMMAND {}
DEF DG.SZ.MAX.Room Mo-So|09:30|18.0 Mo-So|16:00|16.0 {}
DEVICE DG.SZ.MAX.Room
GlobalDaylistSpec
LANGUAGE de
NAME DG.SZ.MAX.HCB
NR 354
Profil 0: Sonntag 09:30:00 18.0, 16:00:00 16.0
Profil 1: Montag 09:30:00 18.0, 16:00:00 16.0
Profil 2: Dienstag 09:30:00 18.0, 16:00:00 16.0
Profil 3: Mittwoch 09:30:00 18.0, 16:00:00 16.0
Profil 4: Donnerstag 09:30:00 18.0, 16:00:00 16.0
Profil 5: Freitag 09:30:00 18.0, 16:00:00 16.0
Profil 6: Samstag 09:30:00 18.0, 16:00:00 16.0
STATE inactive
TYPE Heating_Control
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1429518809.10066
VALUE inactive
Readings:
2015-04-20 09:30:00 nextUpdate 16:00:00
2015-04-20 09:30:00 nextValue 16.0
2015-04-20 10:33:29 state inactive
SWITCHINGTIMES:
Mo-So|09:30|18.0
Mo-So|16:00|16.0
Timer:
Dg.sz.max.hcb_16:00:00:
HASH DG.SZ.MAX.HCB
MODIFIER 16:00:00
NAME DG.SZ.MAX.HCB_16:00:00
Dg.sz.max.hcb_settimerofday:
HASH DG.SZ.MAX.HCB
MODIFIER SetTimerOfDay
NAME DG.SZ.MAX.HCB_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
DESIRED_TEMP_READING
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:30:00 18.0
16:00:00 16.0
1:
09:30:00 18.0
16:00:00 16.0
2:
09:30:00 18.0
16:00:00 16.0
3:
09:30:00 18.0
16:00:00 16.0
4:
09:30:00 18.0
16:00:00 16.0
5:
09:30:00 18.0
16:00:00 16.0
6:
09:30:00 18.0
16:00:00 16.0
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
09:30:00:
NEXTPARA 16.0
NEXTSWITCH 16:00:00
PARA 18.0
TIM 1429515000
TAGE:
0
1
2
3
4
5
6
16:00:00:
NEXTPARA 18.0
NEXTSWITCH 09:30:00
PARA 16.0
TIM 1429538400
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
room 2.00_Heizung
Nachdem ich einen neuen Schaltzeitpunkt zum Testen hinzugefügt habe, wurde auch geschaltet und der korrekte State (Temperatur) wurde angezeigt. Aber nach Löschen von diesem Schaltzeitpunkt ging das Device zurück auf inactive. Ich bin mir nicht sicher, was du mit dem state inactive anzeigen möchtest. Aber ich benötige für meine Module, die Möglichkeit den aktuellen Wert des Heating_Control Devices abzufragen. Entweder sollte der aktuelle Werte in state stehen, oder ich bräuchte eine andere Möglichkeit (z.B. ein zusätzliches Reading).
Gruß,
Gero
Hey,
das Phänomen hatte ich auch. Das kommt dann vor, wenn deine Geräte in den FHEM Config nach deiner Heating Control definiert sind. Somit findet das Modul die Geräte noch nicht. Erst wenn es die Geräte einmal erfolgreich geschaltet hat, ändert sich der State.
Das er, nachdem du den Schaltzeitpunkt wieder gelöscht hast, wieder auf inaktive zurück ging, passt da ja auch, da das Modul ja nun wieder, seit dem FHEM Neustart das Gerät noch nicht geschaltet hat (da ja der gelöschte Zeitpunkt nun nicht mehr zählt).
So habe ich es mir zumindest erklärt.
Abhilfe soll es schaffen, wenn die Gerätedefnition ganz ans Ende der COnfig geschoben werden. Ich selbst habe es nicht getan, das es bei mir auch so läuft und der kurze Zeitraum des Inactive mich nicht stört.
VG
AScos
@gero
Die Antwort von Ascos kann das Problem richtig beschreiben.
Wenn du deine Definition veröffentlichst, kann ich den Sachverhalt aber nochmals untersuchen.
Erklärung:
state nimmt immer den letzten Schaltbefehl des HC/WD auf.
Wenn die Bedingungen so sind, dass "scheinbar" nicht geschaltet werden kann geht der state auf inactive.
Dies ist leider immer nur eine Vermutung.
HC/WD bekommt gar nicht selbst gar mit, ob geschaltet wird, weil HC/WD nur einen String mit den Bedingungen und dem Schaltparameter wie
{my $days={};; map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}
{my $days={1,2,3,4};;map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}
generiert und an fhem übergibt. Der Befehl wird dann durch die allgemeine Kommandoschleife in fhem ausgeführt, wie es beispielsweise auch der at-Befehl macht. Dadurch ist es möglich umfangreiche fhem-Befehlssequenzen(set xx on-for-timer), {PerlCode} oder ´unix Befehle´ zu übergeben.
Ob dann wirklich geschaltet wird, kann man nicht feststellen.
Der Zustand inactive in state ist immer nur eine Vermutung.
Am liebsten würde ich diesen Zustand durch etwas anderes ersetzen(), weil es immer wieder zu Problemen führt, zumal ich ja jetzt eine stark überarbeitete Version freigeschaltet habe, die intern anders arbeitet.
Inactive bedeutet nicht, dass der Timer nicht läuft. Inactive bedeutet nur, dass bisher scheinbar nicht geschaltet wurde.
Wenn du deine Definition veröffentlichst, kann ich nach der Ursache suchent und ggf. Abhilfe schaffen.
Zitat von: Dietmar63 am 20 April 2015, 21:21:22
@gero
Die Antwort von Ascos kann das Problem richtig beschreiben.
Wenn du deine Definition veröffentlichst, kann ich den Sachverhalt aber nochmals untersuchen.
Erklärung:
state nimmt immer den letzten Schaltbefehl des HC/WD auf.
Wenn die Bedingungen so sind, dass "scheinbar" nicht geschaltet werden kann geht der state auf inactive.
Dies ist leider immer nur eine Vermutung.
HC/WD bekommt gar nicht selbst gar mit, ob geschaltet wird, weil HC/WD nur einen String mit den Bedingungen und dem Schaltparameter wie
{my $days={};; map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}
{my $days={1,2,3,4};;map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}
generiert und an fhem übergibt. Der Befehl wird dann durch die allgemeine Kommandoschleife in fhem ausgeführt, wie es beispielsweise auch der at-Befehl macht. Dadurch ist es möglich umfangreiche fhem-Befehlssequenzen(set xx on-for-timer), {PerlCode} oder ´unix Befehle´ zu übergeben.
Ob dann wirklich geschaltet wird, kann man nicht feststellen.
Der Zustand inactive in state ist immer nur eine Vermutung.
Am liebsten würde ich diesen Zustand durch etwas anderes ersetzen(), weil es immer wieder zu Problemen führt, zumal ich ja jetzt eine stark überarbeitete Version freigeschaltet habe, die intern anders arbeitet.
Inactive bedeutet nicht, dass der Timer nicht läuft. Inactive bedeutet nur, dass bisher scheinbar nicht geschaltet wurde.
Wenn du deine Definition veröffentlichst, kann ich nach der Ursache suchent und ggf. Abhilfe schaffen.
Hallo Dietmar,
Danke für deine Antwort.
Die Veröffentlichung der Definition meines Devices wird leider nicht viel bringen, da es sich um ein selbst geschriebenes Modul handelt.
Das Modul fasst alle MAX-Devices ein PID20 Regler und ein HCB Device für einen Raum zusammen. Im Endeffekt ist es ein erweiterter resingsProxy für mehrere Devices mit einer entsprechenden Schaltlogik.
Hier trotzdem das define:
DEF DG.SZ.TF,EG.GA.TF,DG.SZ.MAX.FK,,DG.SZ.MAX.HT,DG.SZ.MAX.HCB,DG.SZ.MAX.HT.pidDas Device steht VOR dem HCB Device in der fhem.cfg. Allerdings wird das Device nicht durch das Heating_Control Device direkt gesteuert (siehe list Ausgabe von oben), sondern reagiert in der Notify Funktion auf Änderungen des states vom Heating_Control.
Ich werde wohl selbst noch etwas debuggen müssen, um das Verhalten zu verstehen. Ich melde mich nochmal, wenn ich mehr herausgefunden habe.
Gruß,
Gero
Ich würde eigentlich erwarten, dass im 'state' eben genau der Wert steht, der im Profile als Parameter übergeben wird: (lt. Doku)
profile
Define the weekly profile. All timings are separated by space. A switchingtime is defined by the following example:
[<weekdays>|]<time>|<parameter>
Ich habe bei mir die verschiedenen WeekdayTimer im Einsatz und die sind in der fhem.cfg als letztes definiert, dennoch steht der Status nach einem restart immer auf 'inactive'.
Die Timer schalten weitestgehend richtig. Allerdings hatte ich gestern die Situation, dass ein Timer auf 'inactive' stand und nicht geschaltet hat. Heute morgen hat er wieder geschaltet.... Das untersuche ich zur Zeit noch.
Bei mir treten die Problem mit dem Weekdaytimer seit meinem Update vom 17.April auf, vorher liefen die Timer monatelang störungsfrei.
Veröffentliche bitte deine Definition
Hier ein Teil meiner Definitionen:
# Dummy device nothing...
define nothing dummy
# Heizung 'normal'
define wdt_normal WeekdayTimer nothing Mo-Fr|06:00|19.9 Di,Do|08:45|19 Di,Do|12:00|19.9 Mo-Do,So|22:00|16 Fr|22:30|16 So,Sa|07:30|19.9 Sa|22:30|16 {fhemWithLog("set WDTModus=normal desired %")}
attr wdt_normal alias normal
attr wdt_normal disable 0
attr wdt_normal group Heizung
attr wdt_normal room Zeitpläne
# Heizung 'abgesenkt'
define wdt_abgesenkt WeekdayTimer nothing Mo-Fr|06:00|19 Mo-Do|22:00|16 Fr|22:30|16 So,Sa|08:00|19 So,Sa|19:47|16 {fhemWithLog("set WDTModus=abgesenkt desired %")}
attr wdt_abgesenkt alias abgesenkt
attr wdt_abgesenkt group Heizung
attr wdt_abgesenkt room Zeitpläne
# Aussenlichter
define wdt_outdoorlights WeekdayTimer nothing Mo-Fr|06:15|on Mo-Fr|08:15|off Mo-Fr|16:30|on Mo-Fr|22:15|off Sa-So|16:30|on Sa-So|22:30|off {fhemWithLog("set WDTModus=Aussenlichtuhr %")}
attr wdt_outdoorlights alias Aussenlichter
attr wdt_outdoorlights disable 0
attr wdt_outdoorlights group Lichter
attr wdt_outdoorlights room Zeitpläne
Die Funktion fhemWithLog() ist die Funktion fhem() mit einem Log-Befehl...
Es gibt ein Device THRESHOLD mit einem Reading 'WDTModus'. Wenn das auf 'normal' steht, wird die Temperatur für 'normal' gesetzt usw...
Das Problem scheint aufzutreten, wenn das Device, dass in der Definition steht nicht in der Funktion WeekdayTimer_isHeizung gelistet ist.
Wenn ich bei mir statt meinem eigenen Device z.B. einen PID20 Regler nehme, funktioniert alles.
Wenn ich in der Funktion WeekdayTimer_SetTimer die Variable $grenzSeconds unabhängig von der Funktion WeekdayTimer_isHeizung setze, scheint der Fehler behoben zu sein:
Zitatsub WeekdayTimer_SetTimer($) {
my $hash = shift;
my $name = $hash->{NAME};
my $now = time();
my $switchedInThePast = 0;
my $isHeating = WeekdayTimer_isHeizung($hash);
# my $grenzSeconds = $isHeating ? -24*3600 : -5;
my $grenzSeconds = -24*3600 ;
@Dietmar: Vielleicht hilft dir das bei der Problemlösung weiter.
Gruß,
Gero
Das kann ich nur bestätigen.
Wenn ich als Device bei mir z.b. ein FHT angebe, springt der Status des WDT sofort auf den aktuellen Wert und alles ist gut.
Hab jetzt also ein Dummy FHT definiert.
Aus meiner Sicht brauchte der WeekdayTimer eigentlich gar kein Device, weil ich ausschließlich mit Befehlen arbeite, die zum entsprechenden Zeitpunkt ausgeführt werden.
Vielleicht könnte man den WeekdayTimer gegenüber dem Heating_Control dahingehend entsprechend abspecken...
Hat leider auch nix gebracht. Heute nachmittag steht das Device wieder auf inactive und hat auch nicht geschaltet :(
@uwe.barth
Setze mal verbose 5 für den WD. Dann bekommst du debugging Info.
Zitat von: uwe.bart am 22 April 2015, 09:18:50
Hier ein Teil meiner Definitionen:
# Dummy device nothing...
define nothing dummy
# Heizung 'normal'
define wdt_normal WeekdayTimer nothing Mo-Fr|06:00|19.9 Di,Do|08:45|19 Di,Do|12:00|19.9 Mo-Do,So|22:00|16 Fr|22:30|16 So,Sa|07:30|19.9 Sa|22:30|16 {fhemWithLog("set WDTModus=normal desired %")}
attr wdt_normal alias normal
attr wdt_normal disable 0
attr wdt_normal group Heizung
attr wdt_normal room Zeitpläne
# Heizung 'abgesenkt'
define wdt_abgesenkt WeekdayTimer nothing Mo-Fr|06:00|19 Mo-Do|22:00|16 Fr|22:30|16 So,Sa|08:00|19 So,Sa|19:47|16 {fhemWithLog("set WDTModus=abgesenkt desired %")}
attr wdt_abgesenkt alias abgesenkt
attr wdt_abgesenkt group Heizung
attr wdt_abgesenkt room Zeitpläne
# Aussenlichter
define wdt_outdoorlights WeekdayTimer nothing Mo-Fr|06:15|on Mo-Fr|08:15|off Mo-Fr|16:30|on Mo-Fr|22:15|off Sa-So|16:30|on Sa-So|22:30|off {fhemWithLog("set WDTModus=Aussenlichtuhr %")}
attr wdt_outdoorlights alias Aussenlichter
attr wdt_outdoorlights disable 0
attr wdt_outdoorlights group Lichter
attr wdt_outdoorlights room Zeitpläne
Die Funktion fhemWithLog() ist die Funktion fhem() mit einem Log-Befehl...
Es gibt ein Device THRESHOLD mit einem Reading 'WDTModus'. Wenn das auf 'normal' steht, wird die Temperatur für 'normal' gesetzt usw...
ich habe deinen Timer(WD) mal bei mir eingegeben, verbose auf 4 gesetzt und ein wenig an den Zeiten gedreht und siehe da er funktioniert. die FM "Undefined ..." ist der Beweis dafür:
2015.04.22 20:43:00 3: Undefined subroutine &main::fhemWithLog called at (eval 8301) line 1.
2015.04.22 20:43:00 3: eval: {my $days={};map{$days->{$_}=1}(0,1,2,3,4); if ( 1 && (defined $days->{$wday})) {fhemWithLog("set WDTModus=normal desired 16")}}
2015.04.22 20:43:00 1: PERL ERROR: Undefined subroutine &main::fhemWithLog called at (eval 8301) line 1.
2015.04.22 20:43:00 4: [wdt_normal] command: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4);; if ( 1 && (defined $days->{$wday})) {fhemWithLog("set WDTModus=normal desired 16")}} executed
2015.04.22 20:43:00 4: [wdt_normal] timer seems to be active today: 01234|20:43:00|16
2015.04.22 20:42:04 4: [wdt_normal] 07:30:00 19.9, 22:30:00 16 (Profil 6: Samstag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 22:30:00 16 (Profil 5: Freitag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 08:45:00 19, 12:00:00 19.9, 20:43:00 16 (Profil 4: Donnerstag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 20:43:00 16 (Profil 3: Mittwoch)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 08:45:00 19, 12:00:00 19.9, 20:43:00 16 (Profil 2: Dienstag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 20:43:00 16 (Profil 1: Montag)
2015.04.22 20:42:04 4: [wdt_normal] 07:30:00 19.9, 20:43:00 16 (Profil 0: Sonntag)
2015.04.22 20:42:04 4: [wdt_normal] 05:29:46 21:06:50 Mittwoch
@uwe:
Zitat
Ich habe bei mir die verschiedenen WeekdayTimer im Einsatz und die sind in der fhem.cfg als letztes definiert, dennoch steht der Status nach einem restart immer auf 'inactive'.
@gero:
Zitat von: gero am 22 April 2015, 09:56:47
Das Problem scheint aufzutreten, wenn das Device, dass in der Definition steht nicht in der Funktion WeekdayTimer_isHeizung gelistet ist.
Wenn ich bei mir statt meinem eigenen Device z.B. einen PID20 Regler nehme, funktioniert alles.
Wenn ich in der Funktion WeekdayTimer_SetTimer die Variable $grenzSeconds unabhängig von der Funktion WeekdayTimer_isHeizung setze, scheint der Fehler behoben zu sein:
@Dietmar: Vielleicht hilft dir das bei der Problemlösung weiter.
Gruß,
Gero
Das ist richtig, nicht wirklich verwunderlich, ja sogar Absicht.:
Geschichte:
WD und HC basieren auf dem gleichen Code. Ursprüngliche wollte ich damit eine Heizung(FHT) steuern.
Wenn man eine Heizungssteuerung definiert, dann wollte ich, dass zum Zeitpunkt der Definition oder eines Neustarts von fhem der zuletzt gültige Temperaturwert an die Heizung übergeben wird, egal wann am Tag der Zeitpunkt für die Schaltung war:
define wdt_normal WeekdayTimer nothing Mo-Fr|06:00|19.9 Mo-Fr|16:00|16Wenn dieser Timer mittags gegen 12 definiert wird oder ein restart erfogt, wollte ich bewirken, dass der Heizung 19.9° gesendet wird.
Deshalb die Funktion isHeizung(). Immer wenn HC/WD erkennt, dass eine Heizung gesteuert wird, erfolgt auch ein Schalten in der Vergangenheit.
Bei Lichtsteuerungen ist dies aus meiner Sicht nicht wünschenswert. Wenn ich im Tagesverlauf gegen 12:00 Uhr eine Definition wie oben erstelle und das Gerät "nothing" eine Lampe ist, will ich nicht, dass die Lampe geschaltet wird.
Weil dein(uwe) dummy und dein(gero) "eigenes device" in isHeizung() nicht erkannt werden, werden sie wie Lichtschalter behandelt und erst zum nächsten Zeitpunkt geschaltet. Leider scheint es auch so zu sein, dass erst mit der ersten echten Schaltung der Wert inactive auf <16> wechselt. Das sehe ich mir nochmals an.
Für solche Sonderfälle könnte ich ein Attribut aufnehmen, dass das Schalten in der "Vergangenheit" erzwingt.
attr wdt_normal switchInThePast 1
Zitat
Aus meiner Sicht brauchte der WeekdayTimer eigentlich gar kein Device, weil ich ausschließlich mit Befehlen arbeite, die zum entsprechenden Zeitpunkt ausgeführt werden.
Vielleicht könnte man den WeekdayTimer gegenüber dem Heating_Control dahingehend entsprechend abspecken...
Das mag für dich so sein. Andere werden sich vielleicht nicht darüber freuen wenn ich das ausbauen würde.
@uwe:
nach einer Änderung meinerseits wird "nothing" jetzt(aus den oben beschriebenen Gründen) nicht geschaltet, aber nicht mehr der Wert inactive, sondern active gesetzt. Das sollte die damit verbundene Unsicherheit beseitigen.
@dietmar: Einen neues Attribut für Schalten in der Vergangenheit wäre eine gute und einfache Lösung.
Wäre schön, wenn du es einbauen würdest.
Danke,
Gero
Hallo zusammen,
ich muss zugeben dass ich die letzten Beiträge noch nicht tiefgründig gelesen und demnach noch nicht abgeleitet habe, ob die Antworten meine Thematik lösen... Wollte trotzdem fix loswerden, dass ich auch das inactive-Problem habe; kurz nach dem Heating_Control-Update ich glaube vor Ostern bin ich wieder auf die Dezember-Version zurück, jetzt habe ich upgedatet und die Wochenprofile abgeändert (Sonntag ist jetzt 0). Ich steuere 6 FHT´s, jetzt stehen 4 HC´s auf inactive, 2 auf der Temperatur aus dem Profil. Meistens scheint das Schalten trotz inactive zu klappen, vorhin allerdings ging in einem HC Punkt 19 Uhr kein desired-temp raus obwohl im Profil definiert. Warum 4 so und 2 so stehen, habe ich noch nicht rausgefunden.
ZitatWarum 4 so und 2 so stehen, habe ich noch nicht rausgefunden.
Schick mir bitte mal die Definitionen, bei denen inactive steht.
anbei... die oberste Def ist die von dem HC, welches heute 19 Uhr nicht geschaltet hat wie es hätte sollen.
bitte als Text liefern, ich will sie nicht abtippen!
Wie ist KZ_Raumregler definiert?
Achso, ja, sorry...
Inzwischen ist einer der 4 inactiv-HCs auf die Temperatur gewechselt, Effekt ist also womöglich nur noch bei dreien, nämlich diesen hier:
define AR_Heizungsregelung Heating_Control AR_Raumregler 12345|05:00|20 12345|08:00|17 12345|17:00|20 12345|19:00|17 60|06:00|20 60|10:00|17 60|16:00|20 60|19:00|17 (ReadingsVal("SindImUrlaub", "state", "Ja") eq "Nein")
attr AR_Heizungsregelung group Heizung
attr AR_Heizungsregelung icon sani_heating_temp
attr AR_Heizungsregelung room Abstellraum
define KZ_Heizungsregelung Heating_Control KZ_Raumregler 12345|05:30|21 12345|07:30|17 12345|17:00|21 12345|19:00|16 60|07:00|21 60|10:00|17 60|15:00|21 60|19:00|16 (ReadingsVal("SindImUrlaub", "state", "Ja") eq "Nein")
attr KZ_Heizungsregelung group Heizung
attr KZ_Heizungsregelung icon sani_heating_temp
attr KZ_Heizungsregelung room Kinderzimmer
define SZ_Heizungsregelung Heating_Control SZ_Raumregler 12345|09:00|15 12345|09:10|10 60|09:00|15 60|09:10|10 (ReadingsVal("SindImUrlaub", "state", "Ja") eq "Nein")
attr SZ_Heizungsregelung group Heizung
attr SZ_Heizungsregelung icon sani_heating_temp
attr SZ_Heizungsregelung room Schlafzimmer
Dieser HC war bis 23:00 auf inactiv (seit gestern früh nach dem Update), beim 23:00-Schaltpunkt hat er aber scheinbar korrekt auf Temperaturanzeige gewechselt:
define BA_Heizungsregelung Heating_Control BA_Raumregler 1234|04:30|22 1234|08:00|17 1234|17:00|22 1234|23:00|17 60|06:00|22 60|09:00|17 60|18:00|22 60|23:30|17 5|04:30|22 5|08:00|17 5|17:00|22 5|23:30|17 (ReadingsVal("SindImUrlaub", "state", "Ja") eq "Nein")
attr BA_Heizungsregelung group Heizung
attr BA_Heizungsregelung icon sani_heating_temp
attr BA_Heizungsregelung room Bad
Und diese beiden gingen auf Anhieb korrekt
define WZ_Heizungsregelung Heating_Control WZ_Raumregler 12345|04:00|22 12345|08:00|17 12345|16:00|22 12340|23:00|17 60|05:00|22 56|23:30|17 (ReadingsVal("SindImUrlaub", "state", "Ja") eq "Nein")
attr WZ_Heizungsregelung group Heizung
attr WZ_Heizungsregelung icon sani_heating_temp
attr WZ_Heizungsregelung room Wohnzimmer
define KU_Heizungsregelung Heating_Control KU_Raumregler 12345|04:00|22 12345|08:00|18 12345|16:00|22 1234560|20:00|18 60|05:00|22 (ReadingsVal("SindImUrlaub", "state", "Ja") eq "Nein")
attr KU_Heizungsregelung group Heizung
attr KU_Heizungsregelung icon sani_heating_temp
attr KU_Heizungsregelung room Kueche
dann fehlt nur noch die Definition von
AR_Raumregler
KZ_Raumregler
SZ_Raumregler
Ach ja, klar... siehe unten - heute früh stehen allerdings alle 6 HCs auf inactive, auch die beiden die gestern den ganzen Tag die desired-temp angezeigt hatten...
define AR_Raumregler FHT 534f
attr AR_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr AR_Raumregler IODev CUL1.868
attr AR_Raumregler group Heizung
attr AR_Raumregler icon temp_control
attr AR_Raumregler lazy 1
attr AR_Raumregler lightSceneParamsToSave desired-temp
attr AR_Raumregler retrycount 1
attr AR_Raumregler room Abstellraum
define FileLog_AR_Raumregler FileLog ./log/AR_Raumregler-%Y.log AR_Raumregler
attr FileLog_AR_Raumregler logtype fht:Temp/Act,text
attr FileLog_AR_Raumregler room Logfiles
define SVG_AR_Raumregler SVG FileLog_AR_Raumregler:fht:CURRENT
attr SVG_AR_Raumregler group Heizung.Verlauf
attr SVG_AR_Raumregler label "AR_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_AR_Raumregler room Abstellraum
define WZ_Raumregler FHT 2506
attr WZ_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr WZ_Raumregler IODev CUL1.868
attr WZ_Raumregler group Heizung
attr WZ_Raumregler icon temp_control
attr WZ_Raumregler lazy 1
attr WZ_Raumregler lightSceneParamsToSave desired-temp
attr WZ_Raumregler retrycount 1
attr WZ_Raumregler room Wohnzimmer
define FileLog_WZ_Raumregler FileLog ./log/WZ_Raumregler-%Y.log WZ_Raumregler
attr FileLog_WZ_Raumregler logtype fht:Temp/Act,text
attr FileLog_WZ_Raumregler room Logfiles
define SVG_WZ_Raumregler SVG FileLog_WZ_Raumregler:fht:CURRENT
attr SVG_WZ_Raumregler group Heizung.Verlauf
attr SVG_WZ_Raumregler label "WZ_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_WZ_Raumregler room Wohnzimmer
define KU_Raumregler FHT 3f52
attr KU_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr KU_Raumregler IODev CUL1.868
attr KU_Raumregler group Heizung
attr KU_Raumregler icon temp_control
attr KU_Raumregler lazy 1
attr KU_Raumregler lightSceneParamsToSave desired-temp
attr KU_Raumregler retrycount 1
attr KU_Raumregler room Kueche
define FileLog_KU_Raumregler FileLog ./log/KU_Raumregler-%Y.log KU_Raumregler
attr FileLog_KU_Raumregler logtype fht:Temp/Act,text
attr FileLog_KU_Raumregler room Logfiles
define SVG_KU_Raumregler SVG FileLog_KU_Raumregler:fht:CURRENT
attr SVG_KU_Raumregler group Heizung.Verlauf
attr SVG_KU_Raumregler label "KU_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_KU_Raumregler room Kueche
define BA_Raumregler FHT 0f15
attr BA_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr BA_Raumregler IODev CUL1.868
attr BA_Raumregler group Heizung
attr BA_Raumregler icon temp_control
attr BA_Raumregler lazy 1
attr BA_Raumregler lightSceneParamsToSave desired-temp
attr BA_Raumregler retrycount 1
attr BA_Raumregler room Bad
define FileLog_BA_Raumregler FileLog ./log/BA_Raumregler-%Y.log BA_Raumregler
attr FileLog_BA_Raumregler logtype fht:Temp/Act,text
attr FileLog_BA_Raumregler room Logfiles
define SVG_BA_Raumregler SVG FileLog_BA_Raumregler:fht:CURRENT
attr SVG_BA_Raumregler group Heizung.Verlauf
attr SVG_BA_Raumregler label "BA_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_BA_Raumregler room Bad
define KZ_Raumregler FHT 4a29
attr KZ_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr KZ_Raumregler IODev CUL1.868
attr KZ_Raumregler group Heizung
attr KZ_Raumregler icon temp_control
attr KZ_Raumregler lazy 1
attr KZ_Raumregler lightSceneParamsToSave desired-temp
attr KZ_Raumregler retrycount 1
attr KZ_Raumregler room Kinderzimmer
define FileLog_KZ_Raumregler FileLog ./log/KZ_Raumregler-%Y.log KZ_Raumregler
attr FileLog_KZ_Raumregler logtype fht:Temp/Act,text
attr FileLog_KZ_Raumregler room Logfiles
define SVG_KZ_Raumregler SVG FileLog_KZ_Raumregler:fht:CURRENT
attr SVG_KZ_Raumregler group Heizung.Verlauf
attr SVG_KZ_Raumregler label "KZ_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_KZ_Raumregler room Kinderzimmer
define SZ_Raumregler FHT 4707
attr SZ_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr SZ_Raumregler IODev CUL1.868
attr SZ_Raumregler group Heizung
attr SZ_Raumregler icon temp_control
attr SZ_Raumregler lazy 1
attr SZ_Raumregler lightSceneParamsToSave desired-temp
attr SZ_Raumregler room Schlafzimmer
define FileLog_SZ_Raumregler FileLog ./log/SZ_Raumregler-%Y.log SZ_Raumregler
attr FileLog_SZ_Raumregler logtype fht:Temp/Act,text
attr FileLog_SZ_Raumregler room Logfiles
define SVG_SZ_Raumregler SVG FileLog_SZ_Raumregler:fht:CURRENT
attr SVG_SZ_Raumregler group Heizung.Verlauf
attr SVG_SZ_Raumregler label "SZ_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_SZ_Raumregler room Schlafzimmer
define FL_Raumregler FHT 5b57
attr FL_Raumregler IODev CUL1.868
attr FL_Raumregler group Heizung
attr FL_Raumregler icon temp_control
attr FL_Raumregler lazy 1
attr FL_Raumregler room Flur
define FileLog_FL_Raumregler FileLog ./log/FL_Raumregler-%Y.log FL_Raumregler
attr FileLog_FL_Raumregler logtype fht:Temp/Act,text
attr FileLog_FL_Raumregler room Logfiles
define SVG_FL_Raumregler SVG FileLog_FL_Raumregler:fht:CURRENT
attr SVG_FL_Raumregler group Heizung.Verlauf
attr SVG_FL_Raumregler label "FL_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_FL_Raumregler room Flur
EDIT 08:02 Uhr: jetzt nachdem alle HCs bis auf SZ_Heizungsregelung einen Schaltpunkt um 07:30 bzw. 08:00 hatten, zeigen sie auch wieder die desired-temp an - bis auf eben SZ_Heizungsregelung und BA_Heizungsregelung, obwohl BA_Heizungsregelung auch einen 08:00-Schaltpunkt hatte und auch korrekt geschaltet hat, State aber trotzdem inactive.
Hallo,
nach der Inbetriebnahme meiner Gartenpumpe nach der Winterpause, habe ich auch Probleme mit dem WeekdayTimer-Status "inactive" festgestellt.
Mein Schaltprogramm für die Gartenpumpe kann ich auf Fhem-Web interaktiv festlegen. Es wird dann ein WeekdayTimer generiert. Dieser Weekdaytimer ist jetzt initial immer im Status "inactive". Erst beim nächsten Schaltvorgang, wie schon in diesem Thread beschrieben, ändert sich der Status auf "active". Im Status "inactive" ist das Reading nextTime nicht vorhanden, mit der Folge, dass in meiner Bedienoberfläche der nächste Ausführungszeitpunkt im Status "inactive" nicht angezeigt werden kann.
Weiterhin ist mir aufgefallen, dass das Ausgabeformat vom Reading nextTime sich von "mm.dd.yyyy hh:mm:ss" auf " hh:mm:ss" geändert hat. Ich kann jetzt nicht mehr das nächste Ausführungsdatum feststellen.
Der Timer ist aktiv und schaltet zum nächsten Zeitpunkt korrekt. Aus meiner Sicht muss deshalb der Status nach einer sauberen Definition im Status "active" sein und nicht erst nach dem ersten Schaltvorgang. Das Reading nextTime muss auch das Datum anzeigen.
Wie zu Beginn erwähnt, hatte ich dieses Verhalten vor der Winterpause nicht.
Die Fhem-Version ist bei mir auf den aktuellen Stand.
Viele Grüße
Romoker
Hallo Dietmar,
ich hätte ein kleinen Feature-Wunsch ;D
Könnte man für das Attribut windowSensor die Unterstützung für Dummy einrichten?
Zum Hintergrund, ich würde gerne virtuelle Fenster einrichten (Dummy), wenn diese auf Open stehen, soll Heacting_Control nicht schalten, sondern den Schaltvorgang verzögern.
So wie es im Moment mit einem echten Fenster funktioniert.
Vielen Dank!
Zitat von: Mitch am 23 April 2015, 16:11:13
Hallo Dietmar,
ich hätte ein kleinen Feature-Wunsch ;D
Könnte man für das Attribut windowSensor die Unterstützung für Dummy einrichten?
Zum Hintergrund, ich würde gerne virtuelle Fenster einrichten (Dummy), wenn diese auf Open stehen, soll Heacting_Control nicht schalten, sondern den Schaltvorgang verzögern.
So wie es im Moment mit einem echten Fenster funktioniert.
Vielen Dank!
http://forum.fhem.de/index.php/topic,24653.msg179730.html#msg179730 (http://forum.fhem.de/index.php/topic,24653.msg179730.html#msg179730)
in
delayedExecutionCond solltest du auch ein dummy abfragen können.
Nach dem großen update habe ich das noch nicht wieder ausprobiert
okay, Danke, hatte ich übersehenen.
Habe es aber mittlerweile selber eingebaut, war ja nur eine Zeile.
Zitat von: carzl am 23 April 2015, 07:13:33
Ach ja, klar... siehe unten - heute früh stehen allerdings alle 6 HCs auf inactive, auch die beiden die gestern den ganzen Tag die desired-temp angezeigt hatten...
define AR_Raumregler FHT 534f
attr AR_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr AR_Raumregler IODev CUL1.868
attr AR_Raumregler group Heizung
attr AR_Raumregler icon temp_control
attr AR_Raumregler lazy 1
attr AR_Raumregler lightSceneParamsToSave desired-temp
attr AR_Raumregler retrycount 1
attr AR_Raumregler room Abstellraum
define FileLog_AR_Raumregler FileLog ./log/AR_Raumregler-%Y.log AR_Raumregler
attr FileLog_AR_Raumregler logtype fht:Temp/Act,text
attr FileLog_AR_Raumregler room Logfiles
define SVG_AR_Raumregler SVG FileLog_AR_Raumregler:fht:CURRENT
attr SVG_AR_Raumregler group Heizung.Verlauf
attr SVG_AR_Raumregler label "AR_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_AR_Raumregler room Abstellraum
define WZ_Raumregler FHT 2506
attr WZ_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr WZ_Raumregler IODev CUL1.868
attr WZ_Raumregler group Heizung
attr WZ_Raumregler icon temp_control
attr WZ_Raumregler lazy 1
attr WZ_Raumregler lightSceneParamsToSave desired-temp
attr WZ_Raumregler retrycount 1
attr WZ_Raumregler room Wohnzimmer
define FileLog_WZ_Raumregler FileLog ./log/WZ_Raumregler-%Y.log WZ_Raumregler
attr FileLog_WZ_Raumregler logtype fht:Temp/Act,text
attr FileLog_WZ_Raumregler room Logfiles
define SVG_WZ_Raumregler SVG FileLog_WZ_Raumregler:fht:CURRENT
attr SVG_WZ_Raumregler group Heizung.Verlauf
attr SVG_WZ_Raumregler label "WZ_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_WZ_Raumregler room Wohnzimmer
define KU_Raumregler FHT 3f52
attr KU_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr KU_Raumregler IODev CUL1.868
attr KU_Raumregler group Heizung
attr KU_Raumregler icon temp_control
attr KU_Raumregler lazy 1
attr KU_Raumregler lightSceneParamsToSave desired-temp
attr KU_Raumregler retrycount 1
attr KU_Raumregler room Kueche
define FileLog_KU_Raumregler FileLog ./log/KU_Raumregler-%Y.log KU_Raumregler
attr FileLog_KU_Raumregler logtype fht:Temp/Act,text
attr FileLog_KU_Raumregler room Logfiles
define SVG_KU_Raumregler SVG FileLog_KU_Raumregler:fht:CURRENT
attr SVG_KU_Raumregler group Heizung.Verlauf
attr SVG_KU_Raumregler label "KU_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_KU_Raumregler room Kueche
define BA_Raumregler FHT 0f15
attr BA_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr BA_Raumregler IODev CUL1.868
attr BA_Raumregler group Heizung
attr BA_Raumregler icon temp_control
attr BA_Raumregler lazy 1
attr BA_Raumregler lightSceneParamsToSave desired-temp
attr BA_Raumregler retrycount 1
attr BA_Raumregler room Bad
define FileLog_BA_Raumregler FileLog ./log/BA_Raumregler-%Y.log BA_Raumregler
attr FileLog_BA_Raumregler logtype fht:Temp/Act,text
attr FileLog_BA_Raumregler room Logfiles
define SVG_BA_Raumregler SVG FileLog_BA_Raumregler:fht:CURRENT
attr SVG_BA_Raumregler group Heizung.Verlauf
attr SVG_BA_Raumregler label "BA_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_BA_Raumregler room Bad
define KZ_Raumregler FHT 4a29
attr KZ_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr KZ_Raumregler IODev CUL1.868
attr KZ_Raumregler group Heizung
attr KZ_Raumregler icon temp_control
attr KZ_Raumregler lazy 1
attr KZ_Raumregler lightSceneParamsToSave desired-temp
attr KZ_Raumregler retrycount 1
attr KZ_Raumregler room Kinderzimmer
define FileLog_KZ_Raumregler FileLog ./log/KZ_Raumregler-%Y.log KZ_Raumregler
attr FileLog_KZ_Raumregler logtype fht:Temp/Act,text
attr FileLog_KZ_Raumregler room Logfiles
define SVG_KZ_Raumregler SVG FileLog_KZ_Raumregler:fht:CURRENT
attr SVG_KZ_Raumregler group Heizung.Verlauf
attr SVG_KZ_Raumregler label "KZ_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_KZ_Raumregler room Kinderzimmer
define SZ_Raumregler FHT 4707
attr SZ_Raumregler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr SZ_Raumregler IODev CUL1.868
attr SZ_Raumregler group Heizung
attr SZ_Raumregler icon temp_control
attr SZ_Raumregler lazy 1
attr SZ_Raumregler lightSceneParamsToSave desired-temp
attr SZ_Raumregler room Schlafzimmer
define FileLog_SZ_Raumregler FileLog ./log/SZ_Raumregler-%Y.log SZ_Raumregler
attr FileLog_SZ_Raumregler logtype fht:Temp/Act,text
attr FileLog_SZ_Raumregler room Logfiles
define SVG_SZ_Raumregler SVG FileLog_SZ_Raumregler:fht:CURRENT
attr SVG_SZ_Raumregler group Heizung.Verlauf
attr SVG_SZ_Raumregler label "SZ_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_SZ_Raumregler room Schlafzimmer
define FL_Raumregler FHT 5b57
attr FL_Raumregler IODev CUL1.868
attr FL_Raumregler group Heizung
attr FL_Raumregler icon temp_control
attr FL_Raumregler lazy 1
attr FL_Raumregler room Flur
define FileLog_FL_Raumregler FileLog ./log/FL_Raumregler-%Y.log FL_Raumregler
attr FileLog_FL_Raumregler logtype fht:Temp/Act,text
attr FileLog_FL_Raumregler room Logfiles
define SVG_FL_Raumregler SVG FileLog_FL_Raumregler:fht:CURRENT
attr SVG_FL_Raumregler group Heizung.Verlauf
attr SVG_FL_Raumregler label "FL_Raumregler Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_FL_Raumregler room Flur
EDIT 08:02 Uhr: jetzt nachdem alle HCs bis auf SZ_Heizungsregelung einen Schaltpunkt um 07:30 bzw. 08:00 hatten, zeigen sie auch wieder die desired-temp an - bis auf eben SZ_Heizungsregelung und BA_Heizungsregelung, obwohl BA_Heizungsregelung auch einen 08:00-Schaltpunkt hatte und auch korrekt geschaltet hat, State aber trotzdem inactive.
Nochmal ne kleine Ergänzung hierzu, könnte es sein dass es eine Rolle spielt ob zum Schaltzeitpunkt des HC´s ein Fenster offen ist oder nicht? Mein HC "KZ_Heizungsregelung" ist 17:00 auf 21° gegangen. Dann habe ich das Fenster aufgemacht, woraufhin der FHT auf 12° runterging. Während dieser Zeit kam 19:00 die desired-temp 16° vom HC. Als ich gerade das Fenster wieder geschlossen habe, ging der FHT aber nicht auf auf die jetzt eigentlich gültigen 16°, sondern auf die 21° des 17:00-Schaltpunktes. Im Log steht 19:00 auch kein desired-temp drin. Was ich daran aber nicht verstehe - der Fensterkontakt sagt dem FHT doch direkt dass er absenken soll, die Fenster-offen-Absenkung wird bei mir nicht von Fhem realisiert. Muss sonst morgen nochmal sehen was passiert, wenn das Fenster 19:00 geschlossen ist...
Zitat von: carzl am 22 April 2015, 21:54:48
Hallo zusammen,
ich muss zugeben dass ich die letzten Beiträge noch nicht tiefgründig gelesen und demnach noch nicht abgeleitet habe, ob die Antworten meine Thematik lösen... Wollte trotzdem fix loswerden, dass ich auch das inactive-Problem habe; kurz nach dem Heating_Control-Update ich glaube vor Ostern bin ich wieder auf die Dezember-Version zurück, jetzt habe ich upgedatet und die Wochenprofile abgeändert (Sonntag ist jetzt 0). Ich steuere 6 FHT´s, jetzt stehen 4 HC´s auf inactive, 2 auf der Temperatur aus dem Profil. Meistens scheint das Schalten trotz inactive zu klappen, vorhin allerdings ging in einem HC Punkt 19 Uhr kein desired-temp raus obwohl im Profil definiert. Warum 4 so und 2 so stehen, habe ich noch nicht rausgefunden.
Ich habe mit deinen Definitionen herumgespielt und festgestellt, dass sie an sich funktionieren, wenn man sie in der Reihenfolge
dummy, FHT, HC
eingibt.
Es könnte sein, dass bei einem Neustart deines Systems das dummy nach den HC definiert ist, dann evaluieren die Bedingungen zu false und die HC schalten nicht. Ich habe Meldungen ins Log aufgenommen um dies prüfen zu können.
Das Problem ist, dass dazu verbose auf 4 gesetzt werden muss. Das kann aber erst nach der Definition machen. Dann ist es aber schon zu spät. Deshalb werde ich verbose 4 bei HC/WD automatisch setzen, die mit tst beginnen.
Wenn ich die Tests abgeschlossen habe, werde ich sie freigeben.
Oha, interessant! Mein "SindImUrlaub"-Dummy steht in der cfg tatsächlich weiter hinten - FHT, HC, dummy. Na da klimper ich den einfach mal weiter vorne rein und beobachte den morgigen Tag.
Danke erstmal für Deine Mühe!
Hallo,
ich in gestern über das Modul gestolpert und war so begeistert, dass ich heute Nacht erst einmal alle Thermostate umgestellt habe.
(Testphasen werden eigentlich überbewertet :o)
Zwei Thermostaten ärgern mich derzeit noch mit einem "State inactive".
Heute Nacht konnte ich kurz beobachten, dass ein HC anscheinend auf inactive wechselt, wenn der erste Zeitraum um 00:00 beginnt.
Eine Modifikation auf 00:01 korrigierte das Verhalten. Ich kann es aktuell nicht mehr nachstellen - vermutlich weil die dazwischenliegenden Zeitfenster derzeit ausgewertet werden. Ich schau mir das beim nächsten mal Schlafwandeln noch genauer an.
Aktuell ärgert mich diese Definition hier:
define bz_HeatingControl Heating_Control bz_HM_CC_TC_Climate Mo-Fr|00:03|19.0 Mo-Fr|04:30|20 Mo-Fr|05:00|21.5 Mo-Fr|07:30|20 Mo-Fr|16:00|20.5 Mo-Fr|21:30|19 Sa,So|00:03|19.0 Sa,So|06:30|20 Sa,So|07:00|20.5 Sa,So|07:30|21.5 Sa,So|12:01|22.5 Sa,So|20:00|20 (ReadingsVal("HCAutomatik", "state", "") eq "on")
attr bz_HeatingControl disable 0
attr bz_HeatingControl icon edit_settings
attr bz_HeatingControl room Heizung
attr bz_HeatingControl verbose 5
attr bz_HeatingControl windowSensor bz_SEC_RHS
Die Zeiten werden anscheinend korrekt in die Profile interpretiert, allerdings machen mich die Readings stutzig
Die Werte für NExtUpdate und NExtValue gehören eindeutig zu dem Samstagsprofil.
Entferne ich das Samstagsprofil aus der Definition werden die erwarteten Werte angezeigt und der Status inactive verschwindet auch :(
Nach 12:01 verschwindet der mysteriöse Eintrag wieder. Setzte ich den Eintrag auf 12:10 taucht er wieder auf.
Version: # $Id: 98_Heating_Control.pm 8394 2015-04-07 17:48:30Z dietmar63 $
disabled 0 2015-04-24 08:04:55
nextUpdate 12:01:00 2015-04-24 08:06:07
nextValue 22.5 2015-04-24 08:06:07
state inactive 2015-04-24 08:06:07
2015.04.24 08:06:07.019 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_21:30:00
2015.04.24 08:06:07.019 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_20:00:00
2015.04.24 08:06:07.019 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_12:01:00
2015.04.24 08:06:07.019 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_05:00:00
2015.04.24 08:06:07.020 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_07:00:00
2015.04.24 08:06:07.020 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_07:30:00
2015.04.24 08:06:07.020 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_06:30:00
2015.04.24 08:06:07.020 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_16:00:00
2015.04.24 08:06:07.028 4: [bz_HeatingControl] 05:31:15 21:16:02 Freitag
2015.04.24 08:06:07.028 4: [bz_HeatingControl] 00:03:00 19.0, 06:30:00 20, 07:00:00 20.5, 07:30:00 21.5, 12:01:00 22.5, 20:00:00 20 (Profil 0: Sonntag)
2015.04.24 08:06:07.029 4: [bz_HeatingControl] 00:03:00 19.0, 04:30:00 20, 05:00:00 21.5, 07:30:00 20, 16:00:00 20.5, 21:30:00 19 (Profil 1: Montag)
2015.04.24 08:06:07.029 4: [bz_HeatingControl] 00:03:00 19.0, 04:30:00 20, 05:00:00 21.5, 07:30:00 20, 16:00:00 20.5, 21:30:00 19 (Profil 2: Dienstag)
2015.04.24 08:06:07.029 4: [bz_HeatingControl] 00:03:00 19.0, 04:30:00 20, 05:00:00 21.5, 07:30:00 20, 16:00:00 20.5, 21:30:00 19 (Profil 3: Mittwoch)
2015.04.24 08:06:07.029 4: [bz_HeatingControl] 00:03:00 19.0, 04:30:00 20, 05:00:00 21.5, 07:30:00 20, 16:00:00 20.5, 21:30:00 19 (Profil 4: Donnerstag)
2015.04.24 08:06:07.029 4: [bz_HeatingControl] 00:03:00 19.0, 04:30:00 20, 05:00:00 21.5, 07:30:00 20, 16:00:00 20.5, 21:30:00 19 (Profil 5: Freitag)
2015.04.24 08:06:07.029 4: [bz_HeatingControl] 00:03:00 19.0, 06:30:00 20, 07:00:00 20.5, 07:30:00 21.5, 12:01:00 22.5, 20:00:00 20 (Profil 6: Samstag)
2015.04.24 08:06:07.031 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_21:30:00 24.04.2015 21:30:00
2015.04.24 08:06:07.032 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_20:00:00 24.04.2015 20:00:00
2015.04.24 08:06:07.032 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_16:00:00 24.04.2015 16:00:00
2015.04.24 08:06:07.033 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_12:01:00 24.04.2015 12:01:00
2015.04.24 08:06:07.034 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_07:30:00 24.04.2015 07:30:00
2015.04.24 08:06:07.035 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_07:00:00 24.04.2015 07:00:00
2015.04.24 08:06:07.036 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_06:30:00 24.04.2015 06:30:00
2015.04.24 08:06:07.037 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_05:00:00 24.04.2015 05:00:00
2015.04.24 08:06:07.039 5: [bz_HeatingControl] removing Timer: bz_HeatingControl_SetTimerOfDay
2015.04.24 08:06:07.039 5: [bz_HeatingControl] setting Timer: bz_HeatingControl_SetTimerOfDay 25.04.2015 00:00:05
2015.04.24 08:06:07.044 5: [bz_HeatingControl] list of window sensors found: 'bz_SEC_RHS bz_HeatingControl'
2015.04.24 08:06:07.044 5: [bz_HeatingControl] sensor 'bz_SEC_RHS' Reading/Attribute 'state' is 'closed'
2015.04.24 08:06:07.045 4: [bz_HeatingControl] timer seems to be active today: 12345|05:00:00|21.5
2015.04.24 08:06:07.045 5: [bz_HeatingControl] aktParam:21.5 newParam:21.5 - is not disabled
2015.04.24 08:06:07.048 5: [bz_HeatingControl] list of window sensors found: 'bz_SEC_RHS bz_HeatingControl'
2015.04.24 08:06:07.048 5: [bz_HeatingControl] sensor 'bz_SEC_RHS' Reading/Attribute 'state' is 'closed'
2015.04.24 08:06:07.049 5: [bz_HeatingControl] aktParam:21.5 newParam:20.0 - is not disabled
2015.04.24 08:06:07.049 4: [bz_HeatingControl] command: {my%days=map{$_=>1}(0,6);; if ( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days{$wday})) { fhem("set bz_HM_CC_TC_Climate desired-temp 20.0") }} executed
2015.04.24 08:06:07.052 5: [bz_HeatingControl] list of window sensors found: 'bz_SEC_RHS bz_HeatingControl'
2015.04.24 08:06:07.053 5: [bz_HeatingControl] sensor 'bz_SEC_RHS' Reading/Attribute 'state' is 'closed'
2015.04.24 08:06:07.053 5: [bz_HeatingControl] aktParam:21.5 newParam:20.5 - is not disabled
2015.04.24 08:06:07.054 4: [bz_HeatingControl] command: {my%days=map{$_=>1}(0,6);; if ( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days{$wday})) { fhem("set bz_HM_CC_TC_Climate desired-temp 20.5") }} executed
2015.04.24 08:06:07.057 5: [bz_HeatingControl] list of window sensors found: 'bz_SEC_RHS bz_HeatingControl'
2015.04.24 08:06:07.057 5: [bz_HeatingControl] sensor 'bz_SEC_RHS' Reading/Attribute 'state' is 'closed'
2015.04.24 08:06:07.058 5: [bz_HeatingControl] aktParam:21.5 newParam:21.5 - is not disabled
Zitat von: carzl am 23 April 2015, 21:43:43
Oha, interessant! Mein "SindImUrlaub"-Dummy steht in der cfg tatsächlich weiter hinten - FHT, HC, dummy. Na da klimper ich den einfach mal weiter vorne rein und beobachte den morgigen Tag.
Danke erstmal für Deine Mühe!
Habe gestern Abend die Position des Urlaubs-Dummys innerhalb der cfg nach vorne umgezogen, jetzt also Dummy-FHTs-HCs. Nach dem reboot war dann nur einer der 6 HCs auf inactiv. Heute früh aber wieder 4 von 6. Gerade wieder neugestartet, jetzt ist wieder 1 von 6 inactiv. Vielleicht hats also wirklich was mit der Position des Dummys zu tun, aber so wirklich gelöst ist es noch nicht...
Hallo Dietmar,
Könntest du es evtl. in Erwägung ziehen, das Datum im Reading nextUpdate wieder zu reaktivieren?
Es war schon sehr hilfreich.
siehe hier (http://forum.fhem.de/index.php/topic,31143.msg236531.html#msg236531)
Gruß
Hans
Zitat von: Hans Franz am 24 April 2015, 13:06:14
Hallo Dietmar,
Könntest du es evtl. in Erwägung ziehen, das Datum im Reading nextUpdate wieder zu reaktivieren?
Es war schon sehr hilfreich.
siehe hier (http://forum.fhem.de/index.php/topic,31143.msg236531.html#msg236531)
Gruß
Hans
ja - ist schon geändert, wird aber künfig im Format von FmtDateTime() geliefert werden
Zitat von: carzl am 24 April 2015, 10:52:12
Habe gestern Abend die Position des Urlaubs-Dummys innerhalb der cfg nach vorne umgezogen, jetzt also Dummy-FHTs-HCs. Nach dem reboot war dann nur einer der 6 HCs auf inactiv. Heute früh aber wieder 4 von 6. Gerade wieder neugestartet, jetzt ist wieder 1 von 6 inactiv. Vielleicht hats also wirklich was mit der Position des Dummys zu tun, aber so wirklich gelöst ist es noch nicht...
vielleicht wartest du man das nächste udpate ab. Dann wird einiges ander sein.
Hallo
Habe das selbe Problem seit dem letzten update stehen sämtliche WeekdayTimer auf "inactive".
Wann wurde eigentlich die Zuordnung der Wochentage, sprich WE = 7 und So = 0 geändert?
Ging voll an mir vorbei :-\.
Gruß,
Stefan
Zitat von: Haecksler am 25 April 2015, 08:26:09
Hallo
Habe das selbe Problem seit dem letzten update stehen sämtliche WeekdayTimer auf "inactive".
Wann wurde eigentlich die Zuordnung der Wochentage, sprich WE = 7 und So = 0 geändert?
Ging voll an mir vorbei :-\.
Gruß,
Stefan
Kurz vor Ostern
Am Problem mit dem actice/inaktive arbeite ich bereits. Aufgrund interner Änderungen ist das leider nicht ganz so einfach.
Die Timer laufen aber fehlerfrei.
neue Version eingecheckt:
98_WeekdayTimer, 98_Heating_Control:
correction of some bugs with inactive/active state
nextValue has now Format 2015-04-25 18:15:00 as before
added better logging and attr switchInThePast
Hallo,
das mit dem inactive state schaut auf den ersten Blick sehr gut aus. :D
Die zufälligen Werte im nextUpdate und nextValue sind allerdings bei mir noch geblieben.
Ich erkenne da allerdings auch keinen logischen Zusammenhang.
Um die Werte besser auseinander halten zu können habe ich die Wochentage in den Schaltsekunden integriert.
Anbei ein Screenshot, der 46 Sekunden vor einem extra eingefügtem Testzeitpunkt 19:37:06 erstellt wurde.
nextUpdate zeigt hier eindeutig einen Schaltzeitpunkt aus der Montags(-Freitags) Definition.
Um 19:37:06 hat der State aber auf den korrekten Wert ( 22) gewechselt.
Anschließend wurde auch bei nextUpdate der nächste Schaltzeitpunkt um 20:00:00 angezeigt ( dieser ist der Sonntagswert statt dem Samstagswert)
Oder verstehe ich den Inhalt des Readings falsch? Ich meine irgendwo gelesen zu haben, dass dies der nächste Schaltzeitpunkt sein soll.
Gruß
Stefan
Hallo Dietmar,
das inactive-Problem ist bei mir noch nicht behoben. Ich steuere mit deinem Modul meine FBH-Relais über ein THRESHOLD-device (FBH_Buero).
Kannst du noch etwas zum neuen Attribut "switchInThePast" sagen? Dies wird bei mir nicht akzeptiert.
Wie bei Stefan scheint die Readings-Anzeige nicht aktualisiert zu werden:
Sa. 19:50 habe ich neu hinzugefügt. Der state bleibt inactive. Nächster Schaltzeitpunkt wird jedoch 23:00 im Reading angezeigt.
Um 19:50 wurde geschaltet und state steht erst jetzt auf 21
list HCBuero um 19:40 Uhr (nach Update + Neustart):
Internals:
COMMAND {fhem("set @ desired %") if (ReadingsVal("HCAutomatik", "state", "") eq "on")}
DEF FBH_Buero 23:00|19 Mo-Do|18:00|21 Fr|07:00|20 Sa,So|13:00|20 Sa,So|19:50|21 {fhem("set @ desired %") if (ReadingsVal("HCAutomatik", "state", "") eq "on")}
DEVICE FBH_Buero
GlobalDaylistSpec
LANGUAGE de
NAME HCBuero
NR 56
Profil 0: Sonntag 13:00:00 20, 19:50:00 21, 23:00:00 19
Profil 1: Montag 18:00:00 21, 23:00:00 19
Profil 2: Dienstag 18:00:00 21, 23:00:00 19
Profil 3: Mittwoch 18:00:00 21, 23:00:00 19
Profil 4: Donnerstag 18:00:00 21, 23:00:00 19
Profil 5: Freitag 07:00:00 20, 23:00:00 19
Profil 6: Samstag 13:00:00 20, 19:50:00 21, 23:00:00 19
STATE inactive
TYPE Heating_Control
Readings:
2015-04-25 19:34:53 disabled 0
2015-04-25 19:40:00 nextUpdate 23:00:00
2015-04-25 19:40:00 nextValue 19
2015-04-25 19:40:53 state inactive
SWITCHINGTIMES:
23:00|19
Mo-Do|18:00|21
Fr|07:00|20
Sa,So|13:00|20
Sa,So|19:50|21
Timer:
Hcbuero_19:50:00:
HASH HCBuero
MODIFIER 19:50:00
NAME HCBuero_19:50:00
Hcbuero_23:00:00:
HASH HCBuero
MODIFIER 23:00:00
NAME HCBuero_23:00:00
Hcbuero_settimerofday:
HASH HCBuero
MODIFIER SetTimerOfDay
NAME HCBuero_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
DESIRED_TEMP_READING
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
13:00:00 20
19:50:00 21
23:00:00 19
1:
18:00:00 21
23:00:00 19
2:
18:00:00 21
23:00:00 19
3:
18:00:00 21
23:00:00 19
4:
18:00:00 21
23:00:00 19
5:
07:00:00 20
23:00:00 19
6:
13:00:00 20
19:50:00 21
23:00:00 19
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
07:00:00:
NEXTPARA 20
NEXTSWITCH 13:00:00
PARA 20
TIM 1429938000
TAGE:
5
13:00:00:
NEXTPARA 21
NEXTSWITCH 18:00:00
PARA 20
TIM 1429959600
TAGE:
0
6
18:00:00:
NEXTPARA 21
NEXTSWITCH 19:50:00
PARA 21
TIM 1429977600
TAGE:
1
2
3
4
19:50:00:
NEXTPARA 19
NEXTSWITCH 23:00:00
PARA 21
TIM 1429984200
TAGE:
0
6
23:00:00:
NEXTPARA 20
NEXTSWITCH 07:00:00
PARA 19
TIM 1429995600
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
group Heizplan
room Heizung
verbose 4
Gruß
Karlheinz
Zitat von: stefanpf am 25 April 2015, 19:52:53
Die zufälligen Werte im nextUpdate und nextValue sind allerdings bei mir noch geblieben.
Ich erkenne da allerdings auch keinen logischen Zusammenhang.
Um die Werte besser auseinander halten zu können habe ich die Wochentage in den Schaltsekunden integriert.
Anbei ein Screenshot, der 46 Sekunden vor einem extra eingefügtem Testzeitpunkt 19:37:06 erstellt wurde.
nextUpdate zeigt hier eindeutig einen Schaltzeitpunkt aus der Montags(-Freitags) Definition.
Um 19:37:06 hat der State aber auf den korrekten Wert ( 22) gewechselt.
Anschließend wurde auch bei nextUpdate der nächste Schaltzeitpunkt um 20:00:00 angezeigt ( dieser ist der Sonntagswert statt dem Samstagswert)
Oder verstehe ich den Inhalt des Readings falsch? Ich meine irgendwo gelesen zu haben, dass dies der nächste Schaltzeitpunkt sein soll.
Gruß
Stefan
da muss ich noch einmal nachbessern
"switchInThePast"
sollte in der Liste der Attribute auftauchen - eventuell einmal durchstarten.
Zitat von: Dietmar63 am 25 April 2015, 20:33:24
da muss ich noch einmal nachbessern
Das ist nett - danke.
Solange es wie gewünscht schaltet ist ja eigentlich schon alles in Butter.
Ich gehe jetzt über das Wochenende einmal live mit HC.
Am WE habe ich eine Chance einzugreifen wenn das Bad morgens kalt bleibt ( am Freitag Morgen ist der WAF doch glatt um 10% gesunken ;D)
Hallo Dietmar,
habe gerade einen Update gemacht.
Nun steht im state immer active.
Kann man da wieder die aktuelle Temperatur stehen haben?
ich schalte mit dem Wert aus state ein anderes Gerät.
Sende bitte mal die Definition, dann versuche ich mein bestes zu geben.
Hier bitte:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF FHT_Kellerflur 1234|12:00|17.5 056|09:00|17.5 19:00|14 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE FHT_Kellerflur
GlobalDaylistSpec
LANGUAGE de
NAME HCKF
NR 693
Profil 0: Sonntag 09:00:00 17.5, 19:00:00 14
Profil 1: Montag 12:00:00 17.5, 19:00:00 14
Profil 2: Dienstag 12:00:00 17.5, 19:00:00 14
Profil 3: Mittwoch 12:00:00 17.5, 19:00:00 14
Profil 4: Donnerstag 12:00:00 17.5, 19:00:00 14
Profil 5: Freitag 09:00:00 17.5, 19:00:00 14
Profil 6: Samstag 09:00:00 17.5, 19:00:00 14
STATE active
TYPE Heating_Control
VERZOEGRUNG 1
Readings:
2015-04-26 14:31:16 disabled 0
2015-04-26 14:31:24 nextUpdate 2015-04-26 09:00:00
2015-04-26 14:31:24 nextValue 17.5
2015-04-26 14:31:24 state active
SWITCHINGTIMES:
1234|12:00|17.5
056|09:00|17.5
19:00|14
Timer:
Hckf_09:00:00:
HASH HCKF
MODIFIER 09:00:00
NAME HCKF_09:00:00
Hckf_19:00:00:
HASH HCKF
MODIFIER 19:00:00
NAME HCKF_19:00:00
Hckf_settimerofday:
HASH HCKF
MODIFIER SetTimerOfDay
NAME HCKF_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:00:00 17.5
19:00:00 14
1:
12:00:00 17.5
19:00:00 14
2:
12:00:00 17.5
19:00:00 14
3:
12:00:00 17.5
19:00:00 14
4:
12:00:00 17.5
19:00:00 14
5:
09:00:00 17.5
19:00:00 14
6:
09:00:00 17.5
19:00:00 14
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
09:00:00:
NEXTPARA 17.5
NEXTSWITCH 12:00:00
PARA 17.5
TIM 1430031600
TAGE:
0
5
6
12:00:00:
NEXTPARA 14
NEXTSWITCH 19:00:00
PARA 17.5
TIM 1430042400
TAGE:
1
2
3
4
19:00:00:
NEXTPARA 17.5
NEXTSWITCH 09:00:00
PARA 14
TIM 1430067600
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Keller Flur
disable 0
group Heizplan
room Heizung
windowSensor CUL_FHTTK_Kellerflur d_ECOMode
Hallo Dietmar,
habe gerade nach mehreren Versuchen mit Deinen geänderten Versionen, den Stand vom 8.12.2014 von Heating_Control und WeekdayTimer wieder eingespielt. Die funktionieren einwandfrei mit PID20, Dummy und THRESHOLD zusammen. Hab da bisher nichts vermisst, was für meinen Fall Änderungen erforderlich gemacht hätte.
Zitat von: det. am 26 April 2015, 16:25:52
Hallo Dietmar,
habe gerade nach mehreren Versuchen mit Deinen geänderten Versionen, den Stand vom 8.12.2014 von Heating_Control und WeekdayTimer wieder eingespielt. Die funktionieren einwandfrei mit PID20, Dummy und THRESHOLD zusammen. Hab da bisher nichts vermisst, was für meinen Fall Änderungen erforderlich gemacht hätte.
Du gibst aber schnell auf!
Wenn mir niemand Testdaten mit
PID20, Dummy und THRESHOLD wird es vielleicht nie funktionieren.
Zitat von: Mitch am 26 April 2015, 15:49:40
Hier bitte:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF FHT_Kellerflur 1234|12:00|17.5 056|09:00|17.5 19:00|14 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE FHT_Kellerflur
GlobalDaylistSpec
LANGUAGE de
NAME HCKF
NR 693
Profil 0: Sonntag 09:00:00 17.5, 19:00:00 14
Profil 1: Montag 12:00:00 17.5, 19:00:00 14
Profil 2: Dienstag 12:00:00 17.5, 19:00:00 14
Profil 3: Mittwoch 12:00:00 17.5, 19:00:00 14
Profil 4: Donnerstag 12:00:00 17.5, 19:00:00 14
Profil 5: Freitag 09:00:00 17.5, 19:00:00 14
Profil 6: Samstag 09:00:00 17.5, 19:00:00 14
STATE active
TYPE Heating_Control
VERZOEGRUNG 1
Readings:
2015-04-26 14:31:16 disabled 0
2015-04-26 14:31:24 nextUpdate 2015-04-26 09:00:00
2015-04-26 14:31:24 nextValue 17.5
2015-04-26 14:31:24 state active
SWITCHINGTIMES:
1234|12:00|17.5
056|09:00|17.5
19:00|14
Timer:
Hckf_09:00:00:
HASH HCKF
MODIFIER 09:00:00
NAME HCKF_09:00:00
Hckf_19:00:00:
HASH HCKF
MODIFIER 19:00:00
NAME HCKF_19:00:00
Hckf_settimerofday:
HASH HCKF
MODIFIER SetTimerOfDay
NAME HCKF_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:00:00 17.5
19:00:00 14
1:
12:00:00 17.5
19:00:00 14
2:
12:00:00 17.5
19:00:00 14
3:
12:00:00 17.5
19:00:00 14
4:
12:00:00 17.5
19:00:00 14
5:
09:00:00 17.5
19:00:00 14
6:
09:00:00 17.5
19:00:00 14
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
09:00:00:
NEXTPARA 17.5
NEXTSWITCH 12:00:00
PARA 17.5
TIM 1430031600
TAGE:
0
5
6
12:00:00:
NEXTPARA 14
NEXTSWITCH 19:00:00
PARA 17.5
TIM 1430042400
TAGE:
1
2
3
4
19:00:00:
NEXTPARA 17.5
NEXTSWITCH 09:00:00
PARA 14
TIM 1430067600
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Keller Flur
disable 0
group Heizplan
room Heizung
windowSensor CUL_FHTTK_Kellerflur d_ECOMode
wie hast du FHT_Kellerflur definiert?
Ich habe heute früh upgedatet, erst mal alle inactives weg :) Dann vor etwa drei Stunden mal nachgeguckt, 3 von 6 HCs inactive :-[ Jetzt grade nochmal reingeguckt, 1 von 6 FHTs inactive. Kein Fhem-Neustart heute gemacht. Also irgend ne "Watze" scheint noch drin zu sein...
Zitat von: Dietmar63 am 26 April 2015, 19:50:21
Du gibst aber schnell auf!
Wenn mir niemand Testdaten mit PID20, Dummy und THRESHOLD wird es vielleicht nie funktionieren.
überzeugt, Du hast 2 Mails mit den Teilen der fhem.cfg für o.g. Problemfälle. Trotzdem leuchet mir der Modulumbau nicht wirklich ein, da die alten Versionen perfekt funktionieren.
Zitat
überzeugt, Du hast 2 Mails mit den Teilen der fhem.cfg für o.g. Problemfälle. Trotzdem leuchet mir der Modulumbau nicht wirklich ein, da die alten Versionen perfekt funktionieren.
ja, ich weiß und es hat lange gedauert, bis dass ich im letzten Herbst angefangen habe das Modul von Grund auf neu zu strukturieren.
Nach drei Jahren kennt man Perl nun viel besser und wollte es einerseits besser strukturieren und zweitens die Möglichkeit schaffen bei den Tagesangaben $we und !$we ermöglichen.
Als etwas schwierig hat sich nun eigentlich nur die Umstellung auf neue tägliche InternalTimer() herausgestellt, bzw. die Anzeige des "state", "nextValue", "nextParameter", weil die für den Betrieb eingentlich nicht mehr notwendig sind, ich sie aus kompatibilitätsgründen doch wieder liefern muss.
Hallo,
Ich hatte zwar noch keine Muße, das Update einem wirklichen Stresstest zu unterziehen, aber bis jetzt läuft's ausgesprochen gut. Durch switchInThePast steht immer der aktuelle Wert im state,top.
Und danke für das Wiederbereitstellen des Datums in nextUpdate.
Das mit {sunrise_abs_dat($date)} muss ich mir noch näher anschauen.
Die Module bieten bei den ständig sich ändernden Schulzeiten meiner Kids die m.M.n. einfachste Möglichkeit zu reagieren. :)
Gruß
Hans
Hallo,
bei mir scheint jetzt auch alles zu funktionieren.
Ich verwende Heating_Control in Zusammenhang mit einem eigenen Modul und mit den neuen Attribut switchInThePast, verhält es sich jetzt wie erwartet.
Danke,
Gero
Hallo,
ich habe gestern nach einer gefühlten Ewigkeit mal wieder ein Update gefahren. Leider muss ich nach Forenrecherche feststellen, dass doch so einiges am HC-Modul geändert worden ist. Das mit der Änderung der Tages-Nummernzuordnung (und ich meine da den Sonntag) finde ich, und jetzt entschuldigt bitte, wenn ich das so sage, einfach unmöglich. Es wäre nicht schlimm gewesen, das so zu ändern, daß vorhandene Installationen weiter funktionieren und trotzdem we und !we eingeführt werden.
Dietmar63 hat in einem Post in diesem Thread es mal so ausgedrückt:
ja, das ist so.
Ich habe mich aus verschiedenen Gründen entschieden die Tagesangabe wie in DOIF zu ändern.
0 Sonntag
1 Montag
2 Dienstag
3 Mittwoch
4 ...
7 Wochenende ($we)
8 Wochentag (!$we)
Definitionen bitte verändern(commandRef muss ich noch anpassen, sollte aber selbsterklärend sein)
Solange da nichts in der Commandref steht, ist da leider gar nichts selbsterklärend. Es ist einfach nur eine Umstellung die FHEM dazu veranlasst anders zu reagieren. Ich kann nicht bei all meinen genutzten Modulen jeden Thread nach Änderungen durchsuchen, die Zeit habe ich nicht. Wenigstens wird im Log auf die Umstellung hingewiesen,
"7" in daylist now means $we(weekend) - see dokumentation!!!
aber : Die Änderung ist schon Wochen aktiv und es steht immernoch nichts dazu in der Commandref.
Es tut mir leid, wenn sich da jemand auf den Schlips getreten fühlt. So ist nun mal meine Meinung.
Für mich ist FHEM produktiv und nicht irgendeine Bastelgeschichte, wo ich jeden Tag im Forum nach Änderungen oder umgestellten Desinitionen suche. Versteht mich nicht falsch, aber ich möchte ein funktionierenes System. Und ich hoffe nicht, daß jetzt einige Leute sagen: "Dann bist Du hier falsch!". Das wäre in meinen Augen nicht der richtige Ansatz.
@DerTom
Solange du dich nicht selbst der Mühe unterziehst ein, in diesem Falle sogar zwei, Module zu schreiben, warten und supporten, solltest du vielleicht deine Ansprüche überdenken.
Der Grund der Anpassung bzgl. einer Vereinheitlichung der Benennungen liegt doch auf der Hand.
Gruß
Hans
Zitat"7" in daylist now means $we(weekend) - see dokumentation!!!
Ich habe die Entscheidung so zu verfahren nicht einfach so getroffen, sondern lange überdacht - am Ende(und immer noch) dann für richtig befunden.
@DerTom
Ich verstehe zwar dass Du ein wenig unzufrieden bist - ich selbst laboriere nun auch schon etliche Tage mit dem neuen HC herum und war auch nicht happy als es von heute auf morgen nicht mehr so lief wie bisher. Trotzdem - wenn Fhem-Fans sich ein Modul bauen und das dann netterweise allen zur Verfügung stellen und so jeder in den Genuss der (kostenfreien) Nutzung und auch des Supports kommt, sollte man Kritik schon mit Augenmaß anbringen. Klar ist für die meisten Fhem mehr als Spielerei und läuft produktiv, aber trotzdem reden wir hier nicht von gekaufter Software mit gekauften Modulen, 24/7-Support und zugesicherten Wiederherstellungszeiten.
Wie gesagt - ich teile Deine Unzufriedenheit; aber trotzdem bin ich in allererster Linie dankbar dass ich dank Dietmar63 eine solide und bisher klaglos funktionierende Heizungssteuerung umsetzen konnte, mir persönlich fehlt dazu nämlich das Knowhow und ich bin auf solche Profi-User angewiesen, um selbst mit Fhem weiterzukommen und Schritt für Schritt dazuzulernen.
Also, als allererstes: Ja, ich bin dankbar, und zwar ALLEN Entwicklern hier im Forum! Das will ich hier mal vollends klarstellen.
Aber, und das muss ich leider auch sagen, muss das ganze auch dokumentiert sein, wenn so eine Umstellung hier, und das ist leider so, in einem 35 seitigen Thread komplett untergeht und auch nicht vorher angekündigt wird. Sorry, aber wer erklärt bitte meiner Frau, daß die Butze kalt ist? Das muss ich machen... ::)
Es geht auch nicht darum, daß die Butze kalt bleibt. Es geht mir ums Prinzip.
Kann man denn nicht irgendwo im Forum oder anderweitig sehen, was ein Entwickler eines Modules für Änderungen eingestellt hat? Daß es Änderungen gibt, habe ich mittlerweile im Entwicklerthread gefunden, das ist aber mehr oder weniger nur rudimentär beschrieben.
@ Hans Franz: Das würde ich nicht können, da ich nicht den Hintergrund habe und das habe ich auch nicht damit gemeint. Dokumentation ist wichtig. Das ist das A und O. Das habe auch ich mittlerweile erkannt. Das war bei mir auch früher nicht so. FHEM ist mittlerweile so derart vielschichtig, dass man niemals alles vorher checken kann, schon gar nicht, wenn man hunderte Seiten Posts durchackern muss um alle von einem genutzte Module auf Änderungen abzuprüfen.
@ Dietmar63: Also nochmals hier und nur für Dich: DANKE für dieses Modul, ich nutze es gern und sehr ausgiebig und es hat bisher super Dienste geleistet. Aber ich hoffe Du kannst nachvollziehen, warum ich so einen Frust schiebe. Du musst nicht begründen, warum Du etwas machst. Du bist der Entwickler und Du bestimmst die Richtung. Aber bitte vorher ankündigen.
@carzl: Ich denke, meine Kritik habe ich mit gutem Augenmaß vorgebracht. Sorry, wenn ich jemanden verärgert habe!
Zitat von: DerTom am 28 April 2015, 20:15:36
Kann man denn nicht irgendwo im Forum oder anderweitig sehen, was ein Entwickler eines Modules für Änderungen eingestellt hat?
Doch,kann man:hier (http://sourceforge.net/p/fhem/code/commit_browser)
Gruß
Hans
Hallo,
das ist das gleiche wie http://forum.fhem.de/index.php/board,57.0.html (http://forum.fhem.de/index.php/board,57.0.html) . Da wurde aber für das entsprechende Update nur die Beschreibung: 98_Heating_Control, 98_WeekdayTimer, 59_Twilight: big refactoring update with some minor improvements hinterlegt und beschreibt nicht, was eigentlich gemacht wurde. Dafür ist nun mal in meinen Augen die Commandref da.
Aber nun gut des Themas. Ich will nicht irgendwelchen Unfrieden stiften, sondern nur Kritik anbringen.
Hallo Dietmar,
ich habe bei der aktuellen Version das Problem, dass Fenstersensoren ignoriert werden.
Z.B. wird ein Fenster geöffnet und das HM Thermostat geht auf 8 Grad (meine WinopenTemp). Kommt jetzt eine neuer "Schaltpunkt" von HC, wird dieser auch ausgeführt und das HM Theromostat entsprechend verstellt.
Es sollte doch gewartet werden, bis Fenster wieder zu.
Gesendet von iPhone mit Tapatalk
Nochmal ich.
Mir ist gerade noch aufgefallen, das state, nextUpdate und nextValue auch teilweise falsche Werte anzeigt und auch ein zwei Thermostate falsch geschalten werden.
Wie kommt man denn an die alten Versionen ran?
Gesendet von iPhone mit Tapatalk
Hallo,
Kann ich leider bestätigen: Heute ist Donnerstag, aber nextUpdate hat den Wert von Di mit heutigem Datum:Internals:
DEF test_Weekday en 13:48|20 mo|22:33:30|olln Di|06:00|se Mo-Fr|{sunrise_abs_dat(time()+70*86400)}|pur
DEVICE test_Weekday
GlobalDaylistSpec
LANGUAGE en
NAME heatingBath
NR 90
Profil 0: Sunday 13:48:00 20
Profil 1: Monday 04:41:47 pur
, 13:48:00 20, 22:33:30 olln
Profil 2: Tuesday 04:41:47 pur
, 13:48:00 20
Profil 3: Wednesday 04:41:47 pur
, 13:48:00 20
Profil 4: Thursday 04:41:47 pur
, 13:48:00 20
Profil 5: Friday 04:41:47 pur
, 13:48:00 20
Profil 6: Saturday 13:48:00 20
STATE pur
TYPE WeekdayTimer
Readings:
2015-04-30 09:16:51 disabled 0
2015-04-30 09:17:11 nextUpdate 2015-04-30 06:00:00
2015-04-30 09:17:11 nextValue se
2015-04-30 09:17:11 state pur
SWITCHINGTIMES:
13:48|20
mo|22:33:30|olln
Di|06:00|se
Mo-Fr|{sunrise_abs_dat(time()+70*86400)}|pur
Timer:
Heatingbath_04:41:47:
HASH heatingBath
MODIFIER 04:41:47
NAME heatingBath_04:41:47
Heatingbath_13:48:00:
HASH heatingBath
MODIFIER 13:48:00
NAME heatingBath_13:48:00
Heatingbath_22:33:30:
HASH heatingBath
MODIFIER 22:33:30
NAME heatingBath_22:33:30
Heatingbath_settimerofday:
HASH heatingBath
MODIFIER SetTimerOfDay
NAME heatingBath_SetTimerOfDay
Daynumber:
!$we 8
$we 7
fr 5
mo 1
sa 6
su 0
th 4
tu 2
we 3
Helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
Switchingtime:
0:
13:48:00 20
1:
04:41:47 pur
13:48:00 20
22:33:30 olln
2:
04:41:47 pur
13:48:00 20
3:
04:41:47 pur
13:48:00 20
4:
04:41:47 pur
13:48:00 20
5:
04:41:47 pur
13:48:00 20
6:
13:48:00 20
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
04:41:47:
NEXTPARA se
NEXTSWITCH 06:00:00
PARA pur
TIM 1430361707
TAGE:
1
2
3
4
5
06:00:00:
NEXTPARA 20
NEXTSWITCH 13:48:00
PARA se
TIM 1430366400
TAGE:
13:48:00:
NEXTPARA olln
NEXTSWITCH 22:33:30
PARA 20
TIM 1430394480
TAGE:
0
1
2
3
4
5
6
22:33:30:
NEXTPARA pur
NEXTSWITCH 04:41:47
PARA olln
TIM 1430426010
TAGE:
1
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
room test
switchInThePast 1
verbose 4
Gruß
Hans
Hier von mir auch nochmal ein list von zwei Devices, die im Moment gar nicht stimmen:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Leoni_Clima 12345|12:00|21.5 06|09:30|21.5 20:30|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Leoni_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCL
NR 687
Profil 0: Sonntag 09:30:00 21.5, 20:30:00 16
Profil 1: Montag 12:00:00 21.5, 20:30:00 16
Profil 2: Dienstag 12:00:00 21.5, 20:30:00 16
Profil 3: Mittwoch 12:00:00 21.5, 20:30:00 16
Profil 4: Donnerstag 12:00:00 21.5, 20:30:00 16
Profil 5: Freitag 12:00:00 21.5, 20:30:00 16
Profil 6: Samstag 09:30:00 21.5, 20:30:00 16
STATE 21.5
TYPE Heating_Control
Readings:
2015-04-30 08:46:51 disabled 0
2015-04-30 09:30:00 nextUpdate 2015-04-30 12:00:00
2015-04-30 09:30:00 nextValue 21.5
2015-04-30 09:30:00 state 21.5
SWITCHINGTIMES:
12345|12:00|21.5
06|09:30|21.5
20:30|16
Timer:
Hcl_09:30:00:
HASH HCL
MODIFIER 09:30:00
NAME HCL_09:30:00
Hcl_12:00:00:
HASH HCL
MODIFIER 12:00:00
NAME HCL_12:00:00
Hcl_20:30:00:
HASH HCL
MODIFIER 20:30:00
NAME HCL_20:30:00
Hcl_settimerofday:
HASH HCL
MODIFIER SetTimerOfDay
NAME HCL_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:30:00 21.5
20:30:00 16
1:
12:00:00 21.5
20:30:00 16
2:
12:00:00 21.5
20:30:00 16
3:
12:00:00 21.5
20:30:00 16
4:
12:00:00 21.5
20:30:00 16
5:
12:00:00 21.5
20:30:00 16
6:
09:30:00 21.5
20:30:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
09:30:00:
PARA 21.5
TIM 1430379000
TAGE:
0
6
12:00:00:
PARA 21.5
TIM 1430388000
TAGE:
1
2
3
4
5
20:30:00:
PARA 16
TIM 1430418600
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Leoni
group Heizplan
room Heizung
windowSensor Fenster_Leoni d_ECOMode
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Buero_Clima 1234|12:00|21.5 5|08:00|21.5 06|09:00|21.5 19:00|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Buero_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCO
NR 684
Profil 0: Sonntag 09:00:00 21.5, 19:00:00 16
Profil 1: Montag 12:00:00 21.5, 19:00:00 16
Profil 2: Dienstag 12:00:00 21.5, 19:00:00 16
Profil 3: Mittwoch 12:00:00 21.5, 19:00:00 16
Profil 4: Donnerstag 12:00:00 21.5, 19:00:00 16
Profil 5: Freitag 08:00:00 21.5, 19:00:00 16
Profil 6: Samstag 09:00:00 21.5, 19:00:00 16
STATE 21.5
TYPE Heating_Control
Readings:
2015-04-30 08:46:51 disabled 0
2015-04-30 09:00:00 nextUpdate 2015-04-30 12:00:00
2015-04-30 09:00:00 nextValue 21.5
2015-04-30 09:00:00 state 21.5
SWITCHINGTIMES:
1234|12:00|21.5
5|08:00|21.5
06|09:00|21.5
19:00|16
Timer:
Hco_09:00:00:
HASH HCO
MODIFIER 09:00:00
NAME HCO_09:00:00
Hco_12:00:00:
HASH HCO
MODIFIER 12:00:00
NAME HCO_12:00:00
Hco_19:00:00:
HASH HCO
MODIFIER 19:00:00
NAME HCO_19:00:00
Hco_settimerofday:
HASH HCO
MODIFIER SetTimerOfDay
NAME HCO_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:00:00 21.5
19:00:00 16
1:
12:00:00 21.5
19:00:00 16
2:
12:00:00 21.5
19:00:00 16
3:
12:00:00 21.5
19:00:00 16
4:
12:00:00 21.5
19:00:00 16
5:
08:00:00 21.5
19:00:00 16
6:
09:00:00 21.5
19:00:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
08:00:00:
PARA 21.5
TIM 1430373600
TAGE:
5
09:00:00:
PARA 21.5
TIM 1430377200
TAGE:
0
6
12:00:00:
PARA 21.5
TIM 1430388000
TAGE:
1
2
3
4
19:00:00:
PARA 16
TIM 1430413200
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Büro
group Heizplan
room Heizung
windowSensor Fenster_Buero d_ECOMode
Ich kann mir das leider erst morgen Abend ansehen.
verhält sich dieses Modul bei allen Heizkörper-Reglern gleich?
Wenn ich es richtig verstanden habe lautet das Format im Modul: Tag|Uhrzeit|Temperatur die an diesem Tag zu dieser Uhrzeit eingestellt werden soll
Bei HomeMatic schaut das etwas anders aus: Uhrzeit|Temperatur die bis zu dieser Uhrzeit gültig ist
Beistpiel: 06:00 16.0 12:30 19.0 13:30 16.0 23:00 19.0 24:00 16.0
Von 0:00 bis 06:00 Absenktemperatur auf 16 °C, danach von 06:00 bis 12:30 Komforttemperatur auf 19 °C, von 12:30 bis 13:30 Absenktemperatur auf 16 °C und dann bis 23:00 Komforttemperatur auf 19 °C. Ab 23:00 bis 24:00 erneut Absenktemperatur auf 16 °C.
d.h., beim Heating_Control ist es ein "ab-Zeitpunkt", bei HomeMatik ein "bis-Zeitpunkt".
Einen schönen Abend!
Zitat von: DerFrickler am 30 April 2015, 20:57:13
d.h., beim Heating_Control ist es ein "ab-Zeitpunkt", bei HomeMatik ein "bis-Zeitpunkt".
Einen schönen Abend!
korrekt
soweit so gut, nur stellt sich hier die Frage ob diesbezüglich alle Heizungsregler identisch sind und (falls nicht) ob Heating_Control einen möglicherweise unterschiedlichen Syntax für die unterschiedlichen Regler berücksichtigt.
Gruß!
Also ich steuer FHT und HM damit an und alle nach gleicher Logik.
Der Syntax der Thermostate spielt ja gar keine Rolle, nur die Art, was geschickt wird.
Bei FHT und HM ist es desired-temp, nur bei Max ist es wohl etwas anderes.
HC hat grundsätzlich nichts mit dem internen Program der Thermostate zu tun.
Hallo Dietmar,
kurze Frage:
Zitatnew funktions:
WeekdayTimer_SetParm("<devicename>")
Heating_Control_SetTemp("<devicename>")
Ist mit "devicename" der Name des zu schaltenden Devices oder der Name des Weekdaytimers- oder HeatingControl-Elements gemeint? Wie kann ich z.B. mehrere Devices ansteuern? Innerhalb ("xxx;yyy") mit Trenner oder muss ich dann meherere WeekdayTimer_SetParm("<devicename>") absetzen?
Gruß
Tom
Zitat von: DerTom am 01 Mai 2015, 11:43:07
Hallo Dietmar,
kurze Frage:
Ist mit "devicename" der Name des zu schaltenden Devices oder der Name des Weekdaytimers- oder HeatingControl-Elements gemeint? Wie kann ich z.B. mehrere Devices ansteuern? Innerhalb ("xxx;yyy") mit Trenner oder muss ich dann meherere WeekdayTimer_SetParm("<devicename>") absetzen?
Gruß
Tom
HC oder WD, mehrere
Zitat von: Mitch am 30 April 2015, 11:28:29
Hier von mir auch nochmal ein list von zwei Devices, die im Moment gar nicht stimmen:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Leoni_Clima 12345|12:00|21.5 06|09:30|21.5 20:30|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Leoni_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCL
NR 687
Profil 0: Sonntag 09:30:00 21.5, 20:30:00 16
Profil 1: Montag 12:00:00 21.5, 20:30:00 16
Profil 2: Dienstag 12:00:00 21.5, 20:30:00 16
Profil 3: Mittwoch 12:00:00 21.5, 20:30:00 16
Profil 4: Donnerstag 12:00:00 21.5, 20:30:00 16
Profil 5: Freitag 12:00:00 21.5, 20:30:00 16
Profil 6: Samstag 09:30:00 21.5, 20:30:00 16
STATE 21.5
TYPE Heating_Control
Readings:
2015-04-30 08:46:51 disabled 0
2015-04-30 09:30:00 nextUpdate 2015-04-30 12:00:00
2015-04-30 09:30:00 nextValue 21.5
2015-04-30 09:30:00 state 21.5
SWITCHINGTIMES:
12345|12:00|21.5
06|09:30|21.5
20:30|16
Timer:
Hcl_09:30:00:
HASH HCL
MODIFIER 09:30:00
NAME HCL_09:30:00
Hcl_12:00:00:
HASH HCL
MODIFIER 12:00:00
NAME HCL_12:00:00
Hcl_20:30:00:
HASH HCL
MODIFIER 20:30:00
NAME HCL_20:30:00
Hcl_settimerofday:
HASH HCL
MODIFIER SetTimerOfDay
NAME HCL_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:30:00 21.5
20:30:00 16
1:
12:00:00 21.5
20:30:00 16
2:
12:00:00 21.5
20:30:00 16
3:
12:00:00 21.5
20:30:00 16
4:
12:00:00 21.5
20:30:00 16
5:
12:00:00 21.5
20:30:00 16
6:
09:30:00 21.5
20:30:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
09:30:00:
PARA 21.5
TIM 1430379000
TAGE:
0
6
12:00:00:
PARA 21.5
TIM 1430388000
TAGE:
1
2
3
4
5
20:30:00:
PARA 16
TIM 1430418600
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Leoni
group Heizplan
room Heizung
windowSensor Fenster_Leoni d_ECOMode
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Buero_Clima 1234|12:00|21.5 5|08:00|21.5 06|09:00|21.5 19:00|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Buero_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCO
NR 684
Profil 0: Sonntag 09:00:00 21.5, 19:00:00 16
Profil 1: Montag 12:00:00 21.5, 19:00:00 16
Profil 2: Dienstag 12:00:00 21.5, 19:00:00 16
Profil 3: Mittwoch 12:00:00 21.5, 19:00:00 16
Profil 4: Donnerstag 12:00:00 21.5, 19:00:00 16
Profil 5: Freitag 08:00:00 21.5, 19:00:00 16
Profil 6: Samstag 09:00:00 21.5, 19:00:00 16
STATE 21.5
TYPE Heating_Control
Readings:
2015-04-30 08:46:51 disabled 0
2015-04-30 09:00:00 nextUpdate 2015-04-30 12:00:00
2015-04-30 09:00:00 nextValue 21.5
2015-04-30 09:00:00 state 21.5
SWITCHINGTIMES:
1234|12:00|21.5
5|08:00|21.5
06|09:00|21.5
19:00|16
Timer:
Hco_09:00:00:
HASH HCO
MODIFIER 09:00:00
NAME HCO_09:00:00
Hco_12:00:00:
HASH HCO
MODIFIER 12:00:00
NAME HCO_12:00:00
Hco_19:00:00:
HASH HCO
MODIFIER 19:00:00
NAME HCO_19:00:00
Hco_settimerofday:
HASH HCO
MODIFIER SetTimerOfDay
NAME HCO_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:00:00 21.5
19:00:00 16
1:
12:00:00 21.5
19:00:00 16
2:
12:00:00 21.5
19:00:00 16
3:
12:00:00 21.5
19:00:00 16
4:
12:00:00 21.5
19:00:00 16
5:
08:00:00 21.5
19:00:00 16
6:
09:00:00 21.5
19:00:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
08:00:00:
PARA 21.5
TIM 1430373600
TAGE:
5
09:00:00:
PARA 21.5
TIM 1430377200
TAGE:
0
6
12:00:00:
PARA 21.5
TIM 1430388000
TAGE:
1
2
3
4
19:00:00:
PARA 16
TIM 1430413200
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Büro
group Heizplan
room Heizung
windowSensor Fenster_Buero d_ECOMode
Ich habe den Timer 1 mit leicht anderen Schaltzeitpunkten nachgestellt und kann keinen Fehler feststellen - siehe Bildschirm-Foto
Zitat von: Hans Franz am 30 April 2015, 09:23:08
Hallo,
Kann ich leider bestätigen: Heute ist Donnerstag, aber nextUpdate hat den Wert von Di mit heutigem Datum:Internals:
DEF test_Weekday en 13:48|20 mo|22:33:30|olln Di|06:00|se Mo-Fr|{sunrise_abs_dat(time()+70*86400)}|pur
DEVICE test_Weekday
GlobalDaylistSpec
LANGUAGE en
NAME heatingBath
NR 90
Profil 0: Sunday 13:48:00 20
Profil 1: Monday 04:41:47 pur
, 13:48:00 20, 22:33:30 olln
Profil 2: Tuesday 04:41:47 pur
, 13:48:00 20
Profil 3: Wednesday 04:41:47 pur
, 13:48:00 20
Profil 4: Thursday 04:41:47 pur
, 13:48:00 20
Profil 5: Friday 04:41:47 pur
, 13:48:00 20
Profil 6: Saturday 13:48:00 20
STATE pur
TYPE WeekdayTimer
Readings:
2015-04-30 09:16:51 disabled 0
2015-04-30 09:17:11 nextUpdate 2015-04-30 06:00:00
2015-04-30 09:17:11 nextValue se
2015-04-30 09:17:11 state pur
SWITCHINGTIMES:
13:48|20
mo|22:33:30|olln
Di|06:00|se
Mo-Fr|{sunrise_abs_dat(time()+70*86400)}|pur
Timer:
Heatingbath_04:41:47:
HASH heatingBath
MODIFIER 04:41:47
NAME heatingBath_04:41:47
Heatingbath_13:48:00:
HASH heatingBath
MODIFIER 13:48:00
NAME heatingBath_13:48:00
Heatingbath_22:33:30:
HASH heatingBath
MODIFIER 22:33:30
NAME heatingBath_22:33:30
Heatingbath_settimerofday:
HASH heatingBath
MODIFIER SetTimerOfDay
NAME heatingBath_SetTimerOfDay
Daynumber:
!$we 8
$we 7
fr 5
mo 1
sa 6
su 0
th 4
tu 2
we 3
Helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
Switchingtime:
0:
13:48:00 20
1:
04:41:47 pur
13:48:00 20
22:33:30 olln
2:
04:41:47 pur
13:48:00 20
3:
04:41:47 pur
13:48:00 20
4:
04:41:47 pur
13:48:00 20
5:
04:41:47 pur
13:48:00 20
6:
13:48:00 20
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
04:41:47:
NEXTPARA se
NEXTSWITCH 06:00:00
PARA pur
TIM 1430361707
TAGE:
1
2
3
4
5
06:00:00:
NEXTPARA 20
NEXTSWITCH 13:48:00
PARA se
TIM 1430366400
TAGE:
13:48:00:
NEXTPARA olln
NEXTSWITCH 22:33:30
PARA 20
TIM 1430394480
TAGE:
0
1
2
3
4
5
6
22:33:30:
NEXTPARA pur
NEXTSWITCH 04:41:47
PARA olln
TIM 1430426010
TAGE:
1
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
room test
switchInThePast 1
verbose 4
Gruß
Hans
Du müsstest bei der Definition Fehler im Log bekommen haben:
2015.05.01 19:20:40 4: [tstWD] 05:09:34 21:24:14 Friday
2015.05.01 19:20:40 1: [tstWD] invalid daylist in tstWD <Di> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2015.05.01 19:20:40 1: [tstWD] invalid daylist in tstWD <Di> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2015.05.01 19:20:40 3: [tstWD] invalid device, <test_Weekday> not found
Hallo,
Sorry, stimmt natürlich. Ich sollte nicht so hastig sein... :)
Darf ich dennoch eine andere Modifikation schicken?
Internals:
DEF testdummy de Mi|01:30|on
DEVICE testdummy
GlobalDaylistSpec
LANGUAGE de
NAME Temp_WDT
NR 121
Profil 3: Mittwoch 01:30:00 on
STATE inactive
TYPE WeekdayTimer
Readings:
2015-05-02 01:10:10 disabled 0
2015-05-02 01:13:27 nextUpdate 2015-05-02 01:30:00
2015-05-02 01:13:27 nextValue on
2015-05-02 01:13:27 state inactive
SWITCHINGTIMES:
Mi|01:30|on
Timer:
Temp_wdt_01:30:00:
HASH Temp_WDT
MODIFIER 01:30:00
NAME Temp_WDT_01:30:00
Temp_wdt_settimerofday:
HASH Temp_WDT
MODIFIER SetTimerOfDay
NAME Temp_WDT_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
3:
01:30:00 on
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
01:30:00:
NEXTPARA on
NEXTSWITCH 01:30:00
PARA on
TIM 1430523000
TAGE:
3
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
switchInThePast 1
verbose 5 Log:
2015.05.02 01:13:27 5: [Temp_WDT] removing Timer: Temp_WDT_01:30:00
2015.05.02 01:13:27 4: [Temp_WDT] 05:24:39 21:21:26 Samstag
2015.05.02 01:13:27 4: [Temp_WDT] 01:30:00 on (Profil 3: Mittwoch)
2015.05.02 01:13:27 5: [Temp_WDT] removing Timer: Temp_WDT_SetTimerOfDay
2015.05.02 01:13:27 5: [Temp_WDT] setting Timer: Temp_WDT_SetTimerOfDay 03.05.2015 00:00:05
2015.05.02 01:13:27 4: [Temp_WDT] device type dummy: recognized, setModifier:
2015.05.02 01:13:27 5: [Temp_WDT] setting Timer: Temp_WDT_01:30:00 02.05.2015 01:30:00
Version:
Zitat# $Id: 98_WeekdayTimer.pm 8480 2015-04-25 20:24:29Z dietmar63 $
Ich werde weiter versuchen eine Systematik zu entdecken.
Gruß
Hans
Zitat von: Hans Franz am 02 Mai 2015, 01:23:30
Hallo,
Sorry, stimmt natürlich. Ich sollte nicht so hastig sein... :)
Darf ich dennoch eine andere Modifikation schicken?
Internals:
DEF testdummy de Mi|01:30|on
DEVICE testdummy
GlobalDaylistSpec
LANGUAGE de
NAME Temp_WDT
NR 121
Profil 3: Mittwoch 01:30:00 on
STATE inactive
TYPE WeekdayTimer
Readings:
2015-05-02 01:10:10 disabled 0
2015-05-02 01:13:27 nextUpdate 2015-05-02 01:30:00
2015-05-02 01:13:27 nextValue on
2015-05-02 01:13:27 state inactive
SWITCHINGTIMES:
Mi|01:30|on
Timer:
Temp_wdt_01:30:00:
HASH Temp_WDT
MODIFIER 01:30:00
NAME Temp_WDT_01:30:00
Temp_wdt_settimerofday:
HASH Temp_WDT
MODIFIER SetTimerOfDay
NAME Temp_WDT_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
3:
01:30:00 on
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
01:30:00:
NEXTPARA on
NEXTSWITCH 01:30:00
PARA on
TIM 1430523000
TAGE:
3
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
switchInThePast 1
verbose 5
Log:
2015.05.02 01:13:27 5: [Temp_WDT] removing Timer: Temp_WDT_01:30:00
2015.05.02 01:13:27 4: [Temp_WDT] 05:24:39 21:21:26 Samstag
2015.05.02 01:13:27 4: [Temp_WDT] 01:30:00 on (Profil 3: Mittwoch)
2015.05.02 01:13:27 5: [Temp_WDT] removing Timer: Temp_WDT_SetTimerOfDay
2015.05.02 01:13:27 5: [Temp_WDT] setting Timer: Temp_WDT_SetTimerOfDay 03.05.2015 00:00:05
2015.05.02 01:13:27 4: [Temp_WDT] device type dummy: recognized, setModifier:
2015.05.02 01:13:27 5: [Temp_WDT] setting Timer: Temp_WDT_01:30:00 02.05.2015 01:30:00
Version:
Ich werde weiter versuchen eine Systematik zu entdecken.
Gruß
Hans
Ich kann keinen Fehler entdecken. Vielleicht erwartest du etwas, was so nicht Eintritt.
Hallo,
Das hätte ich erwähnen können:
ZitatnextUpdate 2015-05-02 01:30:00
Generell steht bei mir nur noch das heutige Datum in
nextUpdate. Gemäß obiger Definition sollte doch der 6.Mai dort stehen.
Gruß
Hans
Hallo,
Alles zurück :).
Irgendetwas ist bei den Updates schiefgelaufen. Habe gerade die Version vom 27.4. geladen und nextUpdate stimmt. Sorry, my mistake.
Ich teste weiter.
Gruß
Hans
Zitat von: Dietmar63 am 01 Mai 2015, 18:02:47
Ich habe den Timer 1 mit leicht anderen Schaltzeitpunkten nachgestellt und kann keinen Fehler feststellen - siehe Bildschirm-Foto
Der Fehler, im state sollte zu diesem Zeitpunkt 16 stehen.
Zitat von: Mitch am 02 Mai 2015, 12:01:09
Der Fehler, im state sollte zu diesem Zeitpunkt 16 stehen.
Und wenn du dir den von mir exakt nachgebauten timer ansiehst(Foto), dann steht im state 16 drin.
Fehler nicht nachstellbar.
@ Hans Franz, @ Mitch:
ich habe einige Test mit dem state und nextValue durchgeführt.
Ich kann keine Fehler wie ihr sie beschreibt mehr feststellen.
Die Definition:
define tstWD2 WeekdayTimer testdummy de Mi|01:30|on
Führt zu folgenden Anzeigen - siehe Foto.
Spätestestens morgen werde ich noch ein weiteres update einchecken, bei dem es um Problembehebungen geht, die crasl und det. gemeldet haben, die tatsächlich Korrekturen bedurften.
Dann wird auch die Doku auf einen neueren Stand gebracht.
neue Version eingecheckt - aus meiner Sicht keine offenen Probleme vorhanden.
probiert die Version bei Gelegenheit aus.
So, habe gerade einen Update gemacht.
Was mir direkt aufgefallen ist, nach dem Neustart wurden zwei Heizungen trotz offenen Fenstern direkt geschalten.
Auch zeigt der state die Temperatur an, bei der alten Version ($Id: 98_Heating_Control.pm 6918 2014-11-08 16:47:09Z dietmar63 $) stand im state dann immer waiting. Auch wurde immer im Log immer z.B. [HCS] switch of HZ_Schlafzimmer_Clima delayed - sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'open' gemeldet, das fehlt mir auch.
Werde jetzt mal beobachten, ob es mit den Fenstern nun funktioniert.
Zitat von: Dietmar63 am 02 Mai 2015, 22:18:16
neue Version eingecheckt - aus meiner Sicht keine offenen Probleme vorhanden.
probiert die Version bei Gelegenheit aus.
Danke,
PID20 und Dummy mit THRESHOLD schalten einwandfrei mit der neuen Version
Zitat
Was mir direkt aufgefallen ist, nach dem Neustart wurden zwei Heizungen trotz offenen Fenstern direkt geschalten.
Beim Neustart könnte es daran liegen, dass der define von den Fensterkontakten keine Ahnung hat, weil sie ihm ja erst mit attr danach bekannt gegeben werden. Leider lassen sich Attribute nur auf vorhandene devices anlegen.
Ich habe die Hinweise auf eine Verzögerung wg. Eines Fensterkontakts definitiv bei mir gesehen.
Setze mal
verbose auf 5,
Dann sollte folgende Meldung ins log laufen:
Log3 $hash, 5, "[$name] list of window sensors found: '$fensterKontakte'";und auch mehr ins log geschrieben werden
Ja so etwas in die Richtung vermute ich auch, wobei bei mir die HC Devices die letzten in der cfg sind.
Gerade mal ein Fenster zu gemacht, aber die Temperatur wurde nicht verstellt.
Wie gesagt, werde ich mal heute beobachten.
Also irgendwie läuft das bei mir nicht rund.
Hab jetzt mal ein Fenster zum testen geöffnet (Küche) und schau auf die Oberfläche und da sind alle HCs auf inactive, nur der eine, wo das Fenster schon seit gestern offen ist (Schlafzimmer), zweigt state 16, statt waiting
Siehe Anhang
EDIT:: gerade wieder die alte Version eingespielt und schon geht wieder alles richtig
Siehe zweiter Anhang
Zitat von: Mitch am 03 Mai 2015, 12:39:22
Also irgendwie läuft das bei mir nicht rund.
Hab jetzt mal ein Fenster zum testen geöffnet (Küche) und schau auf die Oberfläche und da sind alle HCs auf inactive, nur der eine, wo das Fenster schon seit gestern offen ist (Schlafzimmer), zweigt state 16, statt waiting
Siehe Anhang
EDIT:: gerade wieder die alte Version eingespielt und schon geht wieder alles richtig
Siehe zweiter Anhang
was ist das für eine Anzeige(hardcopy)?
Ja, einfach ein Bildschirmfoto
dann lass dein HC(Leoni) mal mit tst beginnen, und sende mir das Protokoll
Hier der Log.
Habe erst den _Leoni angelegt, dann _Schalfzimmer und dann das Fenster zu gemacht (war offen).
Leider wurde das Fenster wieder nicht erkannt.
2015.05.03 19:18:28 3: [HCS] set HCS disable
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer] aktParam:19.0 newParam:19.0 - is not disabled
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer] next: 2015-05-03 21:00:00(so) -->> 16
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer] akt: 2015-05-03 18:00:00(so) -->> 19
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer]:setTimer - timer seems to be active today: 0123456|21:00|16
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer] Heating recognized - switch in the past activated
2015.05.03 19:17:58 4: [tstWZ_Schafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 6: Samstag)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 5: Freitag)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 4: Donnerstag)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 3: Mittwoch)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 2: Dienstag)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 1: Montag)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 18:00:00 19, 21:00:00 16 (Profil 0: Sonntag)
2015.05.03 19:17:57 4: [tstWZ_Schafzimmer] 05:17:48 21:05:05 Sonntag
2015.05.03 19:16:09 4: [tstWZ_Leoni] aktParam:21.5 newParam:21.5 - is not disabled
2015.05.03 19:16:09 4: [tstWZ_Leoni] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.03 19:16:09 4: [tstWZ_Leoni] next: 2015-05-03 20:30:00(so) -->> 16
2015.05.03 19:16:09 4: [tstWZ_Leoni] akt: 2015-05-03 09:30:00(so) -->> 21.5
2015.05.03 19:16:09 4: [tstWZ_Leoni]:setTimer - timer seems to be active today: 0123456|20:30|16
2015.05.03 19:16:09 4: [tstWZ_Leoni] Heating recognized - switch in the past activated
2015.05.03 19:16:09 4: [tstWZ_Leoni] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.03 19:16:08 4: [tstWZ_Leoni] 09:30:00 21.5, 20:30:00 16 (Profil 6: Samstag)
2015.05.03 19:16:08 4: [tstWZ_Leoni] 12:00:00 21.5, 20:30:00 16 (Profil 5: Freitag)
2015.05.03 19:16:08 4: [tstWZ_Leoni] 12:00:00 21.5, 20:30:00 16 (Profil 4: Donnerstag)
2015.05.03 19:16:08 4: [tstWZ_Leoni] 12:00:00 21.5, 20:30:00 16 (Profil 3: Mittwoch)
2015.05.03 19:16:08 4: [tstWZ_Leoni] 12:00:00 21.5, 20:30:00 16 (Profil 2: Dienstag)
2015.05.03 19:16:08 4: [tstWZ_Leoni] 12:00:00 21.5, 20:30:00 16 (Profil 1: Montag)
2015.05.03 19:16:08 4: [tstWZ_Leoni] 09:30:00 21.5, 20:30:00 16 (Profil 0: Sonntag)
so, habe jetzt nochmal ein Device angelegt, dann ein Fenster geöffnet und leider wurde nichts erkannt:
2015.05.03 19:27:04 4: [tstWZ_Wohzi] aktParam:22.0 newParam:22.0 - is not disabled
2015.05.03 19:27:04 4: [tstWZ_Wohzi] device type CUL_HM:HM-TC-IT-WM-W-EU recognized, setModifier:desired-temp
2015.05.03 19:27:04 4: [tstWZ_Wohzi] next: 2015-05-03 22:30:00(so) -->> 16
2015.05.03 19:27:04 4: [tstWZ_Wohzi] akt: 2015-05-03 19:00:00(so) -->> 22
2015.05.03 19:27:04 4: [tstWZ_Wohzi]:setTimer - timer seems to be active today: 0123456|22:30|16
2015.05.03 19:27:04 4: [tstWZ_Wohzi] Heating recognized - switch in the past activated
2015.05.03 19:27:04 4: [tstWZ_Wohzi] device type CUL_HM:HM-TC-IT-WM-W-EU recognized, setModifier:desired-temp
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 08:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 6: Samstag)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 06:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 5: Freitag)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 06:00:00 21.5, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 4: Donnerstag)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 06:00:00 21.5, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 3: Mittwoch)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 06:00:00 21.5, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 2: Dienstag)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 06:00:00 21.5, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 1: Montag)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 08:00:00 21.5, 19:00:00 22, 22:30:00 16 (Profil 0: Sonntag)
2015.05.03 19:27:04 4: [tstWZ_Wohzi] 05:17:48 21:05:05 Sonntag
Dabei ist mir aufgefallen, dass wieder ein Device ohne ersichtlichen Grund auf inactive gegangen ist??
wir sollten jetzt nicht immer hin und her springen.
zu Fensterkontakt. ich habe folgendes geloggt:
2015.05.03 21:18:30 2: FHT set HeizungWohnen desired-temp 16.0
2015.05.03 21:18:00 4: [HeizungWohnen_uz___] next: 2015-05-03 22:00:00(so) -->> 16
2015.05.03 21:18:00 4: [HeizungWohnen_uz___] akt: 2015-05-03 21:15:00(so) -->> 16
2015.05.03 21:18:00 4: [HeizungWohnen_uz___] command: {my $days={};;map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem('set HeizungWohnen desired-temp 16.0') }} executed
2015.05.03 21:18:00 4: [HeizungWohnen_uz___] aktParam:23.0 newParam:16.0 - is not disabled
2015.05.03 21:18:00 4: [HeizungWohnen_uz___] device type FHT: recognized, setModifier:desired-temp
2015.05.03 21:18:00 4: [HeizungWohnen_uz___]:Update - timer seems to be active today: 78|2|16
2015.05.03 21:18:00 3: [HeizungWohnen_uz___] delay of switching HeizungWohnen stopped.
2015.05.03 21:18:00 5: [HeizungWohnen_uz___] sensor 'Terrassentuer' Reading/Attribute 'Window' is 'Closed'
2015.05.03 21:18:00 5: [HeizungWohnen_uz___] list of window sensors found: 'Terrassentuer HeizungWohnen_uz___'
2015.05.03 21:17:00 5: [HeizungWohnen_uz___] setting Timer: HeizungWohnen_uz____2 03.05.2015 21:18:00
2015.05.03 21:17:00 5: [HeizungWohnen_uz___] sensor 'Terrassentuer' Reading/Attribute 'Window' is 'Open'
2015.05.03 21:17:00 5: [HeizungWohnen_uz___] list of window sensors found: 'Terrassentuer HeizungWohnen_uz___'
2015.05.03 21:16:00 5: [HeizungWohnen_uz___] setting Timer: HeizungWohnen_uz____2 03.05.2015 21:17:00
2015.05.03 21:16:00 5: [HeizungWohnen_uz___] sensor 'Terrassentuer' Reading/Attribute 'Window' is 'Open'
2015.05.03 21:16:00 5: [HeizungWohnen_uz___] list of window sensors found: 'Terrassentuer HeizungWohnen_uz___'
2015.05.03 21:15:00 5: [HeizungWohnen_uz___] setting Timer: HeizungWohnen_uz____2 03.05.2015 21:16:00
2015.05.03 21:15:00 3: [HeizungWohnen_uz___] switch of HeizungWohnen delayed - sensor 'Terrassentuer' Reading/Attribute 'Window' is 'Open'
2015.05.03 21:15:00 5: [HeizungWohnen_uz___] sensor 'Terrassentuer' Reading/Attribute 'Window' is 'Open'
2015.05.03 21:15:00 5: [HeizungWohnen_uz___] list of window sensors found: 'Terrassentuer HeizungWohnen_uz___'
So ist es richtig - den output benötigen wir für einen timer dessen FK auf offen steht. Die FK senden immer mit Verspätung, dass das Fenster offen ist.
Bitte bei dir verbose auf 5 setzen(geht nicht bei HC/WD die mit tst beginnen).
Um state inactive kümmern wir uns jetzt erst einmal nicht - das Problem kommt als nächstes dran.
state inactive bedeutet nur, dass HC glaubt, dass heute kein switch notwendig ist - der timer läuft.
So, hat ein bisschen gedauert.
Hier mal der Log vom Schlafzimmer.
Es wurde geschalten, obwohl das Fenster offen war.
2015.05.06 15:58:47 3: Heating_Control_SetTimer() for HCS done!
2015.05.06 15:58:47 3: CUL_HM set HZ_Schlafzimmer_Clima desired-temp 16.0
2015.05.06 15:58:47 4: [HCS] command: {my $days={};;map{$days->{$_}=1}();; if ( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday} || $we || !$we)) { fhem('set HZ_Schlafzimmer_Clima desired-temp 16.0') }} executed
2015.05.06 15:58:47 4: [HCS] aktParam:8.0 newParam:16.0 - is not disabled
2015.05.06 15:58:47 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.06 15:58:47 4: [HCS] next: 2015-05-06 18:00:00(mi) -->> 19
2015.05.06 15:58:47 4: [HCS] akt: 2015-05-05 21:00:00(di) -->> 16
2015.05.06 15:58:47 5: [HCS] setting Timer: HCS_2 06.05.2015 21:00:00
2015.05.06 15:58:47 4: [HCS]:setTimer - timer seems to be active today: 0123456|21:00|16
2015.05.06 15:58:47 5: [HCS] setting Timer: HCS_1 06.05.2015 18:00:00
2015.05.06 15:58:47 4: [HCS]:setTimer - timer seems to be active today: 0123456|18:00|19
2015.05.06 15:58:47 4: [HCS] Heating recognized - switch in the past activated
2015.05.06 15:58:47 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.06 15:58:47 5: [HCS] removing Timer: HCS_2
2015.05.06 15:58:47 5: [HCS] removing Timer: HCS_1
Hier noch der list vom Device:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Schlafzimmer_Clima 18:00|19 21:00|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Schlafzimmer_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCS
NR 689
Profil 0: Sonntag 18:00:00 19, 21:00:00 16
Profil 1: Montag 18:00:00 19, 21:00:00 16
Profil 2: Dienstag 18:00:00 19, 21:00:00 16
Profil 3: Mittwoch 18:00:00 19, 21:00:00 16
Profil 4: Donnerstag 18:00:00 19, 21:00:00 16
Profil 5: Freitag 18:00:00 19, 21:00:00 16
Profil 6: Samstag 18:00:00 19, 21:00:00 16
STATE 16
TYPE Heating_Control
Readings:
2015-05-05 21:24:33 disabled 0
2015-05-06 15:58:47 nextUpdate 2015-05-06 18:00:00
2015-05-06 15:58:47 nextValue 19
2015-05-06 15:58:47 state 16
SWITCHINGTIMES:
18:00|19
21:00|16
Timer:
Hcs_1:
HASH HCS
MODIFIER 1
NAME HCS_1
Hcs_2:
HASH HCS
MODIFIER 2
NAME HCS_2
Hcs_settimerofday:
HASH HCS
MODIFIER SetTimerOfDay
NAME HCS_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
18:00:00 19
21:00:00 16
1:
18:00:00 19
21:00:00 16
2:
18:00:00 19
21:00:00 16
3:
18:00:00 19
21:00:00 16
4:
18:00:00 19
21:00:00 16
5:
18:00:00 19
21:00:00 16
6:
18:00:00 19
21:00:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1430928000
PARA 19
TIME 18:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1430938800
PARA 16
TIME 21:00
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Schlafzimmer
disable 0
group Heizplan
room Heizung
verbose 5
windowSensor Fenster_Schlafzimmer
EDIT: gerade nochmal einen Update gemacht. Die 98_Week... wurde upgedatet, also Neustart.
Wieder wurde Schlafzimmer geschalten, obwohl Fenster offen ist:
2015.05.06 18:03:39 3: CUL_HM set HZ_Schlafzimmer_Clima desired-temp 19.0
2015.05.06 18:03:39 4: [HCS] command: {my $days={};;map{$days->{$_}=1}();; if ( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday} || $we || !$we)) { fhem('set HZ_Schlafzimmer_Clima desired-temp 19.0') }} executed
2015.05.06 18:03:39 4: [HCS] aktParam:8.0 newParam:19.0 - is not disabled
2015.05.06 18:03:39 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.06 18:03:39 4: [HCS] next: 2015-05-06 21:00:00(mi) -->> 16
2015.05.06 18:03:39 4: [HCS] akt: 2015-05-06 18:00:00(mi) -->> 19
2015.05.06 18:03:39 5: [HCS] setting Timer: HCS_2 06.05.2015 21:00:00
2015.05.06 18:03:39 4: [HCS]:setTimer - timer seems to be active today: 0123456|21:00|16
2015.05.06 18:03:39 4: [HCS] Heating recognized - switch in the past activated
2015.05.06 18:03:39 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
EDIT 2: gerade die Version $Id: 98_Heating_Control.pm 6918 2014-11-08 16:47:09Z dietmar63 eingespielt und neu gestartet. Schalfzimmer Fenster wird erkannt und es wird nicht geschalten. im state steht waiting...
2015.05.06 18:14:18 5: [HCS] setting Timer: HCS_Update 06.05.2015 18:15:18
2015.05.06 18:14:18 5: [HCS] removing Timer: HCS_Update
2015.05.06 18:14:18 3: [HCS] switch of HZ_Schlafzimmer_Clima delayed - sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'open'
2015.05.06 18:14:18 5: [HCS] sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'open'
2015.05.06 18:14:18 5: [HCS] list of senors found: 'Fenster_Schlafzimmer HCS'
Zitat von: Mitch am 06 Mai 2015, 17:54:31
So, hat ein bisschen gedauert.
Hier mal der Log vom Schlafzimmer.
Es wurde geschalten, obwohl das Fenster offen war.
2015.05.06 15:58:47 3: Heating_Control_SetTimer() for HCS done!
2015.05.06 15:58:47 3: CUL_HM set HZ_Schlafzimmer_Clima desired-temp 16.0
2015.05.06 15:58:47 4: [HCS] command: {my $days={};;map{$days->{$_}=1}();; if ( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday} || $we || !$we)) { fhem('set HZ_Schlafzimmer_Clima desired-temp 16.0') }} executed
2015.05.06 15:58:47 4: [HCS] aktParam:8.0 newParam:16.0 - is not disabled
2015.05.06 15:58:47 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.06 15:58:47 4: [HCS] next: 2015-05-06 18:00:00(mi) -->> 19
2015.05.06 15:58:47 4: [HCS] akt: 2015-05-05 21:00:00(di) -->> 16
2015.05.06 15:58:47 5: [HCS] setting Timer: HCS_2 06.05.2015 21:00:00
2015.05.06 15:58:47 4: [HCS]:setTimer - timer seems to be active today: 0123456|21:00|16
2015.05.06 15:58:47 5: [HCS] setting Timer: HCS_1 06.05.2015 18:00:00
2015.05.06 15:58:47 4: [HCS]:setTimer - timer seems to be active today: 0123456|18:00|19
2015.05.06 15:58:47 4: [HCS] Heating recognized - switch in the past activated
2015.05.06 15:58:47 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.06 15:58:47 5: [HCS] removing Timer: HCS_2
2015.05.06 15:58:47 5: [HCS] removing Timer: HCS_1
Hier noch der list vom Device:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Schlafzimmer_Clima 18:00|19 21:00|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Schlafzimmer_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCS
NR 689
Profil 0: Sonntag 18:00:00 19, 21:00:00 16
Profil 1: Montag 18:00:00 19, 21:00:00 16
Profil 2: Dienstag 18:00:00 19, 21:00:00 16
Profil 3: Mittwoch 18:00:00 19, 21:00:00 16
Profil 4: Donnerstag 18:00:00 19, 21:00:00 16
Profil 5: Freitag 18:00:00 19, 21:00:00 16
Profil 6: Samstag 18:00:00 19, 21:00:00 16
STATE 16
TYPE Heating_Control
Readings:
2015-05-05 21:24:33 disabled 0
2015-05-06 15:58:47 nextUpdate 2015-05-06 18:00:00
2015-05-06 15:58:47 nextValue 19
2015-05-06 15:58:47 state 16
SWITCHINGTIMES:
18:00|19
21:00|16
Timer:
Hcs_1:
HASH HCS
MODIFIER 1
NAME HCS_1
Hcs_2:
HASH HCS
MODIFIER 2
NAME HCS_2
Hcs_settimerofday:
HASH HCS
MODIFIER SetTimerOfDay
NAME HCS_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
18:00:00 19
21:00:00 16
1:
18:00:00 19
21:00:00 16
2:
18:00:00 19
21:00:00 16
3:
18:00:00 19
21:00:00 16
4:
18:00:00 19
21:00:00 16
5:
18:00:00 19
21:00:00 16
6:
18:00:00 19
21:00:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1430928000
PARA 19
TIME 18:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1430938800
PARA 16
TIME 21:00
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Schlafzimmer
disable 0
group Heizplan
room Heizung
verbose 5
windowSensor Fenster_Schlafzimmer
EDIT: gerade nochmal einen Update gemacht. Die 98_Week... wurde upgedatet, also Neustart.
Wieder wurde Schlafzimmer geschalten, obwohl Fenster offen ist:
2015.05.06 18:03:39 3: CUL_HM set HZ_Schlafzimmer_Clima desired-temp 19.0
2015.05.06 18:03:39 4: [HCS] command: {my $days={};;map{$days->{$_}=1}();; if ( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday} || $we || !$we)) { fhem('set HZ_Schlafzimmer_Clima desired-temp 19.0') }} executed
2015.05.06 18:03:39 4: [HCS] aktParam:8.0 newParam:19.0 - is not disabled
2015.05.06 18:03:39 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.05.06 18:03:39 4: [HCS] next: 2015-05-06 21:00:00(mi) -->> 16
2015.05.06 18:03:39 4: [HCS] akt: 2015-05-06 18:00:00(mi) -->> 19
2015.05.06 18:03:39 5: [HCS] setting Timer: HCS_2 06.05.2015 21:00:00
2015.05.06 18:03:39 4: [HCS]:setTimer - timer seems to be active today: 0123456|21:00|16
2015.05.06 18:03:39 4: [HCS] Heating recognized - switch in the past activated
2015.05.06 18:03:39 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
EDIT 2: gerade die Version $Id: 98_Heating_Control.pm 6918 2014-11-08 16:47:09Z dietmar63 eingespielt und neu gestartet. Schalfzimmer Fenster wird erkannt und es wird nicht geschalten. im state steht waiting...
2015.05.06 18:14:18 5: [HCS] setting Timer: HCS_Update 06.05.2015 18:15:18
2015.05.06 18:14:18 5: [HCS] removing Timer: HCS_Update
2015.05.06 18:14:18 3: [HCS] switch of HZ_Schlafzimmer_Clima delayed - sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'open'
2015.05.06 18:14:18 5: [HCS] sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'open'
2015.05.06 18:14:18 5: [HCS] list of senors found: 'Fenster_Schlafzimmer HCS'
Damit kann ich jetzt etwas anfangen.
Es ist so, dass in der Startphase eines HC/WD mit dem rückwärtigem Schalten die Fensterkontakte nicht ausgewertet werden. Das werde ich ändern und dann freigeben.
Hast du Fensterkontakte außerhalb der Startphase ausprobiert?
Zitat
Damit kann ich jetzt etwas anfangen.
Es ist so, dass in der Startphase eines HC/WD mit dem rückwärtigem Schalten die Fensterkontakte nicht ausgewertet werden. Das werde ich ändern und dann freigeben.
Hast du Fensterkontakte außerhalb der Startphase ausprobiert?
eingecheckt
Guten Morgen,
also das mit den Fenstern geht jetzt, allerdings habe ich noch ein Problem.
Folgendes Szenario:
HC ist so eingestellt, dass jeden Tag ab 12 Uhr auf 21.5 Grad gestellt wird und um 20 Uhr auf 16 Grad.
Jetzt ist es 16 Uhr und das Fenster wird geöffnet.
HC erkennt dies und speichert im Hintergrund die 21.5 Grad.
Jetzt wird das Fenster am nächsten Tag um 9 Uhr geschlossen.
Jetzt sollte eigentlich laut Zeitplan 16 Grad eingestellt werden, allerdings hat HC noch die 21.5 Grad gespeichert und stellt dies auch ein.
2015.05.11 09:00:01 3: CUL_HM set HZ_Leoni_Clima desired-temp 21.5
2015.05.11 09:00:00 3: [HCL] delay of switching HZ_Leoni_Clima stopped.
Hallo Dietmar,
ich habe leider nach wie vor dieses Problem (gerade heute wieder beobachtet).
Mitch, welches Problem hast du noch?
Aus deiner Beschreibung kann ich nicht erkennen, welche Probleme noch offen sind.
LLösen kann ich sie nur, wenn du die genauen Definitionen lieferst und deine Beobachtung hinzugefügst
Naja, wie gesagt:
HC ist so eingestellt, dass jeden Tag ab 12 Uhr auf 21.5 Grad gestellt wird und um 20 Uhr auf 16 Grad.
Angenommen, jetzt ist es 16 Uhr und das Fenster wird geöffnet.
HC erkennt dies und speichert im Hintergrund die 21.5 Grad.
Jetzt wird das Fenster am nächsten Tag um 9 Uhr geschlossen.
Jetzt sollte eigentlich laut Zeitplan 16 Grad eingestellt werden, allerdings hat HC noch die 21.5 Grad gespeichert und stellt dies auch ein
Log:
2015.05.11 09:00:01 3: CUL_HM set HZ_Leoni_Clima desired-temp 21.5
2015.05.11 09:00:00 3: [HCL] delay of switching HZ_Leoni_Clima stopped.
List HC:
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEF HZ_Leoni_Clima 12345|12:00|21.5 06|09:30|21.5 20:30|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
DEVICE HZ_Leoni_Clima
GlobalDaylistSpec
LANGUAGE de
NAME HCL
NR 722
Profil 0: Sonntag 09:30:00 21.5, 20:30:00 16
Profil 1: Montag 12:00:00 21.5, 20:30:00 16
Profil 2: Dienstag 12:00:00 21.5, 20:30:00 16
Profil 3: Mittwoch 12:00:00 21.5, 20:30:00 16
Profil 4: Donnerstag 12:00:00 21.5, 20:30:00 16
Profil 5: Freitag 12:00:00 21.5, 20:30:00 16
Profil 6: Samstag 09:30:00 21.5, 20:30:00 16
STATE 21.5
TYPE Heating_Control
Readings:
2015-05-15 13:50:58 nextUpdate 2015-05-15 20:30:00
2015-05-15 13:50:58 nextValue 16
2015-05-15 13:50:58 state 21.5
SWITCHINGTIMES:
12345|12:00|21.5
06|09:30|21.5
20:30|16
Timer:
Hcl_3:
HASH HCL
MODIFIER 3
NAME HCL_3
Hcl_settimerofday:
HASH HCL
MODIFIER SetTimerOfDay
NAME HCL_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:30:00 21.5
20:30:00 16
1:
12:00:00 21.5
20:30:00 16
2:
12:00:00 21.5
20:30:00 16
3:
12:00:00 21.5
20:30:00 16
4:
12:00:00 21.5
20:30:00 16
5:
12:00:00 21.5
20:30:00 16
6:
09:30:00 21.5
20:30:00 16
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1431684000
PARA 21.5
TIME 12:00
TAGE:
1
2
3
4
5
2:
EPOCH 1431675000
PARA 21.5
TIME 09:30
TAGE:
0
6
3:
EPOCH 1431714600
PARA 16
TIME 20:30
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Leoni
group Heizplan
room Heizung
verbose 3
windowSensor Fenster_Leoni
Guten Morgen,
ich verwende auch Heating_Control zur Steuerung all meiner MAX! Thermostate. Funktioniert soweit auch ganz gut, außer im Badezimmer. Dort habe ich 3 Thermostate zu einer structure zusammengeschaltet und möchte damit dann mit einem Heating_Control alle drei Thermostate steuern. Scheinbar ist das aber nicht möglich. Es kommt immer die Fehlermeldung "Invalid device OG_Bad_T"
define OG_Bad_T structure MAX OG_Bad_Klo_T OG_Bad_Waschb_T OG_Bad_Badew_T
attr OG_Bad_T room Badezimmer
define OG_Bad_Klo_T MAX HeatingThermostat 0784a4
attr OG_Bad_Klo_T userattr MAX MAX_map structexclude
attr OG_Bad_Klo_T IODev cm
attr OG_Bad_Klo_T MAX OG_Bad_T
attr OG_Bad_Klo_T group Heizung
attr OG_Bad_Klo_T icon temp_control
attr OG_Bad_Klo_T room Badezimmer,Heizung,MAX
OG_Bad_Waschb_T und OG_Bad_Badew_T sind entsprechend OG_Bad_Klo_T
define HC_Bad_Min Heating_Control OG_Bad_T mo-fr|05:15|22.5 mo-fr|07:15|15 $we|08:00|22 $we|19:00|15 (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal")
Mit dem Dummy HC_Bad_Off_Profile mache ich eine Profilumschaltung zwischen 4 Heating_Controls. Darum ist auch der Wunsch, dass ich die structure mit Heating_Control steuern kann. Ansonsten hab ich nämlich 4 Profile je Thermostat = 12 Profile für einen Raum.
Ich prüfe nachher was die Ursache sein könnte.
Zitat von: persching am 19 Mai 2015, 06:40:02
Guten Morgen,
ich verwende auch Heating_Control zur Steuerung all meiner MAX! Thermostate. Funktioniert soweit auch ganz gut, außer im Badezimmer. Dort habe ich 3 Thermostate zu einer structure zusammengeschaltet und möchte damit dann mit einem Heating_Control alle drei Thermostate steuern. Scheinbar ist das aber nicht möglich. Es kommt immer die Fehlermeldung "Invalid device OG_Bad_T"
define OG_Bad_T structure MAX OG_Bad_Klo_T OG_Bad_Waschb_T OG_Bad_Badew_T
attr OG_Bad_T room Badezimmer
define OG_Bad_Klo_T MAX HeatingThermostat 0784a4
attr OG_Bad_Klo_T userattr MAX MAX_map structexclude
attr OG_Bad_Klo_T IODev cm
attr OG_Bad_Klo_T MAX OG_Bad_T
attr OG_Bad_Klo_T group Heizung
attr OG_Bad_Klo_T icon temp_control
attr OG_Bad_Klo_T room Badezimmer,Heizung,MAX
OG_Bad_Waschb_T und OG_Bad_Badew_T sind entsprechend OG_Bad_Klo_T
define HC_Bad_Min Heating_Control OG_Bad_T mo-fr|05:15|22.5 mo-fr|07:15|15 $we|08:00|22 $we|19:00|15 (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal")
Mit dem Dummy HC_Bad_Off_Profile mache ich eine Profilumschaltung zwischen 4 Heating_Controls. Darum ist auch der Wunsch, dass ich die structure mit Heating_Control steuern kann. Ansonsten hab ich nämlich 4 Profile je Thermostat = 12 Profile für einen Raum.
Kannst du bitte einmal die Originalfehlermeldung aus dem Log posten.
Vorher bitte verbose 5 setzen.
Ich hab jetzt folgendes gemacht:
Die Uhrzeit hab ich auf 17:07 gestellt, damit ein Ereignis provoziert wird. Als desiredTemperature hab ich 20 Grad eingestellt, 15 Grad war die aktuelle Temperatur. Um 17.08 Uhr hab ich dann zum Raum "Badezimmer" gewechselt und dort gesehen, dass in der Übersicht immer noch 15 Grad eingestellt sind. Also hab ich dann nochmal explizit einen Thermostat angeklickt und dort auf desiredTemperature geguckt.
2015.05.19 17:07:00 5: [HC_Bad_Min] list of window sensors found: 'HC_Bad_Min'
2015.05.19 17:07:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(0,1,2,3,4,5,6);;( (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal") && (defined $days->{$wday}))}<
2015.05.19 17:07:00 4: [HC_Bad_Min]:Update - timer seems to be active today: 0123456|17:07|20
2015.05.19 17:07:00 4: [HC_Bad_Min] device type structure: recognized, setModifier:
2015.05.19 17:07:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(0,1,2,3,4,5,6);;( (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal") && (defined $days->{$wday}))}<
2015.05.19 17:07:00 4: [HC_Bad_Min] aktParam: newParam:20 - is not disabled
2015.05.19 17:07:00 4: [HC_Bad_Min] command: set OG_Bad_T 20 executed
2015.05.19 17:07:00 5: Cmd: >set OG_Bad_T 20<
2015.05.19 17:07:00 5: SET: Unknown argument 20, choose one of wakeUp factoryReset groupid associate:EG_WoZi_T,OG_Bad_Klo_T,EG_Bad_Fensterkontakt,OG_KiZi_Lara_T,OG_KiZi_Lara_Fensterkontakt,EG_WoZi_Fensterkontakt,EG_Bad_T,OG_KiZi_Lara_DF_Fensterkontakt,OG_Bad_Waschb_T,EG_Kueche_T,OG_Schlafz_Fensterkontakt,OG_KiZi_Lena_T,Umwaelzpumpe,OG_Schlafz_T,OG_KiZi_Lena_Fensterkontakt,OG_Bad_Fensterkontakt,fakeWallThermostat,fakeShutterContact deassociate:EG_WoZi_T,OG_Bad_Klo_T,EG_Bad_Fensterkontakt,OG_KiZi_Lara_T,OG_KiZi_Lara_Fensterkontakt,EG_WoZi_Fensterkontakt,EG_Bad_T,OG_KiZi_Lara_DF_Fensterkontakt,OG_Bad_Waschb_T,EG_Kueche_T,OG_Schlafz_Fensterkontakt,OG_KiZi_Lena_T,Umwaelzpumpe,OG_Schlafz_T,OG_KiZi_Lena_Fensterkontakt,OG_Bad_Fensterkontakt,fakeWallThermostat,fakeShutterContact desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on ecoTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on comfortTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 maximumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on minimumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on windowOpenTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on windowOpenDuration boostDuration:15,20,5,60,25,0,10,30 boostValveposition decalcification maxValveSetting valveOffset weekProfile
Unknown argument 20, choose one of wakeUp factoryReset groupid associate:EG_WoZi_T,OG_Bad_Badew_T,EG_Bad_Fensterkontakt,OG_KiZi_Lara_T,OG_KiZi_Lara_Fensterkontakt,EG_WoZi_Fensterkontakt,EG_Bad_T,OG_KiZi_Lara_DF_Fensterkontakt,OG_Bad_Waschb_T,EG_Kueche_T,OG_Schlafz_Fensterkontakt,OG_KiZi_Lena_T,Umwaelzpumpe,OG_Schlafz_T,OG_KiZi_Lena_Fensterkontakt,OG_Bad_Fensterkontakt,fakeWallThermostat,fakeShutterContact deassociate:EG_WoZi_T,OG_Bad_Badew_T,EG_Bad_Fensterkontakt,OG_KiZi_Lara_T,OG_KiZi_Lara_Fensterkontakt,EG_WoZi_Fensterkontakt,EG_Bad_T,OG_KiZi_Lara_DF_Fensterkontakt,OG_Bad_Waschb_T,EG_Kueche_T,OG_Schlafz_Fensterkontakt,OG_KiZi_Lena_T,Umwaelzpumpe,OG_Schlafz_T,OG_KiZi_Lena_Fensterkontakt,OG_Bad_Fensterkontakt,fakeWallThermostat,fakeShutterContact desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on ecoTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on comfortTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 maximumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on minimumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on windowOpenTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on windowOpenDuration boostDuration:15,20,5,60,25,0,10,30 boostValveposition decalcification maxValveSetting valveOffset weekProfile
Unknown argument 20, choose one of wakeUp factoryReset groupid associate:EG_WoZi_T,OG_Bad_Klo_T,OG_Bad_Badew_T,EG_Bad_Fensterkontakt,OG_KiZi_Lara_T,OG_KiZi_Lara_Fensterkontakt,EG_WoZi_Fensterkontakt,EG_Bad_T,OG_KiZi_Lara_DF_Fensterkontakt,EG_Kueche_T,OG_Schlafz_Fensterkontakt,OG_KiZi_Lena_T,Umwaelzpumpe,OG_Schlafz_T,OG_KiZi_Lena_Fensterkontakt,OG_Bad_Fensterkontakt,fakeWallThermostat,fakeShutterContact deassociate:EG_WoZi_T,OG_Bad_Klo_T,OG_Bad_Badew_T,EG_Bad_Fensterkontakt,OG_KiZi_Lara_T,OG_KiZi_Lara_Fensterkontakt,EG_WoZi_Fensterkontakt,EG_Bad_T,OG_KiZi_Lara_DF_Fensterkontakt,EG_Kueche_T,OG_Schlafz_Fensterkontakt,OG_KiZi_Lena_T,Umwaelzpumpe,OG_Schlafz_T,OG_KiZi_Lena_Fensterkontakt,OG_Bad_Fensterkontakt,fakeWallThermostat,fakeShutterContact desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on ecoTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on comfortTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 maximumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on minimumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on windowOpenTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on windowOpenDuration boostDuration:15,20,5,60,25,0,10,30 boostValveposition decalcification maxValveSetting valveOffset weekProfile
2015.05.19 17:07:00 5: Triggering OG_Bad_T (1 changes)
2015.05.19 17:07:00 5: Notify loop for OG_Bad_T 20
2015.05.19 17:07:00 5: battStatus: not on any display, ignoring notify
2015.05.19 17:07:00 5: valvStatus: not on any display, ignoring notify
2015.05.19 17:07:00 4: [HC_Bad_Min] akt: 2015-05-19 17:07:00(di) -->> 20
2015.05.19 17:07:00 4: [HC_Bad_Min] next: 2015-05-20 05:15:00(mi) -->> 22.5
2015.05.19 17:07:00 5: Triggering HC_Bad_Min (3 changes)
2015.05.19 17:07:00 5: Notify loop for HC_Bad_Min nextUpdate: 2015-05-20 05:15:00
2015.05.19 17:07:00 5: battStatus: not on any display, ignoring notify
2015.05.19 17:07:17 4: Closing inactive connection FHEMWEB:192.168.2.25:52937
2015.05.19 17:07:17 4: Closing inactive connection FHEMWEB:192.168.2.25:52941
2015.05.19 17:07:17 4: Closing inactive connection FHEMWEB:192.168.2.25:52933
2015.05.19 17:07:17 4: Closing inactive connection FHEMWEB:192.168.2.25:52935
2015.05.19 17:07:17 4: Closing inactive connection FHEMWEB:192.168.2.25:52936
2015.05.19 17:07:29 4: Connection accepted from FHEMWEB:192.168.2.25:52953
2015.05.19 17:07:29 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2015-05.log
2015.05.19 17:07:34 4: Connection closed for FHEMWEB:192.168.2.25:52943: Connection reset by peer
2015.05.19 17:07:34 4: Connection accepted from FHEMWEB:192.168.2.25:52955
2015.05.19 17:07:34 4: Connection accepted from FHEMWEB:192.168.2.25:52956
2015.05.19 17:07:34 4: Connection accepted from FHEMWEB:192.168.2.25:52957
2015.05.19 17:07:34 4: Connection accepted from FHEMWEB:192.168.2.25:52958
2015.05.19 17:07:34 4: Connection accepted from FHEMWEB:192.168.2.25:52959
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/pgm2/style.css
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/jquery-ui.min.css
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52956 GET /fhem/pgm2/jquery.min.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52959 GET /fhem/pgm2/fhemweb_knob.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52959 GET /fhem/pgm2/fhemweb_sortable.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/fhemweb_uzsu.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/pgm2/jquery-ui.min.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52958 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/images/default/icoEverything.png
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/darkCommon.css
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/dashboard_darkstyle.css
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52956 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.05.19 17:07:34 4: HTTP FHEMWEB:192.168.2.25:52956 GET /fhem/images/default/fhemicon_dark.png
2015.05.19 17:07:38 4: HTTP FHEMWEB:192.168.2.25:52956 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1432048048;fmt=JSON×tamp=1432048060495
2015.05.19 17:08:18 5: CUL/RAW: /Z0B2D00021234560C22AB000000
Z0B2D06300C22AB1234560010ED
2015.05.19 17:08:18 4: CUL_Parse: CUL_0 Z0B2D00021234560C22AB000000 -74
2015.05.19 17:08:18 5: CUL_0 dispatch Z0B2D00021234560C22AB0000
2015.05.19 17:08:18 5: CUL_MAX_Parse: len 11, msgcnt 2D, msgflag 00, msgTypeRaw Ack, src 123456, dst 0c22ab, groupid 0, payload 00
2015.05.19 17:08:18 4: CUL_Parse: CUL_0 Z0B2D06300C22AB1234560010ED -83.5
2015.05.19 17:08:18 5: CUL_0 dispatch Z0B2D06300C22AB1234560010
2015.05.19 17:08:18 5: CUL_MAX_Parse: len 11, msgcnt 2D, msgflag 06, msgTypeRaw ShutterContactState, src 0c22ab, dst 123456, groupid 0, payload 10
2015.05.19 17:08:18 5: CUL_MAX_Parse: rssi: -83.5
2015.05.19 17:08:18 5: cm dispatch MAX,1,ShutterContactState,0c22ab,10
2015.05.19 17:08:18 5: MAX_Parse MAX,1,ShutterContactState,0c22ab,10
2015.05.19 17:08:18 5: ShutterContact isopen 0, rferror 0, battery 0, unkbits 0
2015.05.19 17:08:18 5: Triggering OG_KiZi_Lara_Fensterkontakt (3 changes)
2015.05.19 17:08:18 5: Notify loop for OG_KiZi_Lara_Fensterkontakt battery: ok
2015.05.19 17:08:18 5: HourCounter OG_KiZi_Lara_Fensterkontakt_HC Run.577 value:0 changedTimestamp:2015-05-19 17:01:57
2015.05.19 17:08:18 5: Triggering OG_KiZi_Lara_Fensterkontakt_HC (13 changes)
2015.05.19 17:08:18 5: Notify loop for OG_KiZi_Lara_Fensterkontakt_HC countsPerDay: 0
2015.05.19 17:08:18 5: Laufzeitvisu: not on any display, ignoring notify
2015.05.19 17:08:18 5: battStatus: not on any display, ignoring notify
2015.05.19 17:08:18 4: HourCounter OG_KiZi_Lara_Fensterkontakt_HC ExecQueue.130 cnt: -1
2015.05.19 17:08:18 5: HourCounter OG_KiZi_Lara_Fensterkontakt_HC Run.801 nextCall:3102 changedTimestamp:2015-05-19 17:08:18
2015.05.19 17:08:18 5: battStatus: not on any display, ignoring notify
2015.05.19 17:08:19 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem?room=Badezimmer
2015.05.19 17:08:19 4: 26343:FHEMWEB:192.168.2.25:52955: /fhem?room=Badezimmer / RL:8850 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.05.19 17:08:20 4: Connection closed for FHEMWEB:192.168.2.25:52956: Connection reset by peer
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/style.css
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/pgm2/jquery.min.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52959 GET /fhem/pgm2/jquery-ui.min.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52958 GET /fhem/pgm2/jquery-ui.min.css
2015.05.19 17:08:21 4: Connection accepted from FHEMWEB:192.168.2.25:52964
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/pgm2/fhemweb_knob.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52959 GET /fhem/pgm2/fhemweb_sortable.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/pgm2/fhemweb_uzsu.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/pgm2/svg.js
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/images/default/Shutdown.png
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/images/default/Zoom-in.png
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52959 GET /fhem/images/default/Zoom-out.png
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/images/default/icoEverything.png
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/images/default/Prev.png
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/pgm2/darkCommon.css
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/pgm2/dashboard_darkstyle.css
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/images/default/fhemicon_dark.png
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/SVG_showLog?dev=OG_Bad_Waschb_T_weblink&logdev=FileLog_OG_Bad_Waschb_T&gplotfile=max_temp&logfile=CURRENT&pos=
2015.05.19 17:08:21 5: plotcommand: get FileLog_OG_Bad_Waschb_T CURRENT INT 2015-05-19_00:00:00 2015-05-20_00:00:01 4:desiredTemperature:0: 4:temperature:0: 4:valveposition:0:
2015.05.19 17:08:21 5: Cmd: >get FileLog_OG_Bad_Waschb_T CURRENT INT 2015-05-19_00:00:00 2015-05-20_00:00:01 4:desiredTemperature:0: 4:temperature:0: 4:valveposition:0:<
2015.05.19 17:08:21 4: FileLog_OG_Bad_Waschb_T get: Input file /usr/local/FHEM/var/log/OG_Bad_Waschb_T-2015.log, from:2015-05-19_00:00:00 to:2015-05-20_00:00:01
2015.05.19 17:08:21 4: FileLog_OG_Bad_Waschb_T get: line 1, regexp:desiredTemperature, col:3, output lines:13
2015.05.19 17:08:21 4: FileLog_OG_Bad_Waschb_T get: line 2, regexp:temperature, col:3, output lines:6
2015.05.19 17:08:21 4: FileLog_OG_Bad_Waschb_T get: line 3, regexp:valveposition, col:3, output lines:11
2015.05.19 17:08:21 5: Cmd: >{ "OG_Bad_Waschb_T-2015.log" }<
2015.05.19 17:08:21 5: Cmd: >{ "Waschbecken Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}" }<
2015.05.19 17:08:21 4: 26343:FHEMWEB:192.168.2.25:52953: /fhem/SVG_showLog?dev=OG_Bad_Waschb_T_weblink&logdev=FileLog_OG_Bad_Waschb_T&gplotfile=max_temp&logfile=CURRENT&pos= / RL:2430 / image/svg+xml / Content-Encoding: gzip
/
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/SVG_showLog?dev=wl_Wetter_Temp&logdev=FileLog_Wetter&gplotfile=myYahooWeather&logfile=CURRENT&pos=
2015.05.19 17:08:21 5: plotcommand: get FileLog_Wetter CURRENT INT 2015-05-19_00:00:00 2015-05-20_00:00:01 4:temperature\x3a:: 4:wind_chill\x3a:: 4:humidity\x3a::
2015.05.19 17:08:21 5: Cmd: >get FileLog_Wetter CURRENT INT 2015-05-19_00:00:00 2015-05-20_00:00:01 4:temperature\x3a:: 4:wind_chill\x3a:: 4:humidity\x3a::<
2015.05.19 17:08:21 4: FileLog_Wetter get: Input file /usr/local/FHEM/var/log/Wetter-2015.log, from:2015-05-19_00:00:00 to:2015-05-20_00:00:01
2015.05.19 17:08:21 4: FileLog_Wetter get: line 1, regexp:temperature\x3a, col:3, output lines:103
2015.05.19 17:08:21 4: FileLog_Wetter get: line 2, regexp:wind_chill\x3a, col:3, output lines:103
2015.05.19 17:08:21 4: FileLog_Wetter get: line 3, regexp:humidity\x3a, col:3, output lines:103
2015.05.19 17:08:21 5: Cmd: >{ "Wetter-2015.log" }<
2015.05.19 17:08:21 4: 26343:FHEMWEB:192.168.2.25:52955: /fhem/SVG_showLog?dev=wl_Wetter_Temp&logdev=FileLog_Wetter&gplotfile=myYahooWeather&logfile=CURRENT&pos= / RL:2837 / image/svg+xml / Content-Encoding: gzip
/
2015.05.19 17:08:21 4: HTTP FHEMWEB:192.168.2.25:52959 GET /fhem?XHR=1&inform=type=status;filter=room=Badezimmer;since=1432048098;fmt=JSON×tamp=1432048103196
2015.05.19 17:08:33 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem?detail=OG_Bad_Waschb_T
2015.05.19 17:08:33 4: 26343:FHEMWEB:192.168.2.25:52955: /fhem?detail=OG_Bad_Waschb_T / RL:3637 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.05.19 17:08:35 4: Connection closed for FHEMWEB:192.168.2.25:52959: Connection reset by peer
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/style.css
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/pgm2/jquery-ui.min.css
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/pgm2/jquery.min.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/pgm2/jquery-ui.min.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52958 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/pgm2/fhemweb_knob.js
2015.05.19 17:08:36 4: Connection accepted from FHEMWEB:192.168.2.25:52966
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52955 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52953 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52966 GET /fhem/pgm2/fhemweb_uzsu.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem/pgm2/fhemweb_sortable.js
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/images/default/icoEverything.png
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/pgm2/darkCommon.css
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/pgm2/dashboard_darkstyle.css
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem/images/default/fhemicon_dark.png
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem?cmd={ReadingsVal(%22OG_Bad_Waschb_T%22,%22associate%22,%22%22)}&XHR=1
2015.05.19 17:08:36 5: Cmd: >{ReadingsVal("OG_Bad_Waschb_T","associate","")}<
2015.05.19 17:08:36 4: 26343:FHEMWEB:192.168.2.25:52964: /fhem?cmd={ReadingsVal(%22OG_Bad_Waschb_T%22,%22associate%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem?cmd={AttrVal(%22OG_Bad_Waschb_T%22,%22room%22,%22%22)}&XHR=1
2015.05.19 17:08:36 5: Cmd: >{AttrVal("OG_Bad_Waschb_T","room","")}<
2015.05.19 17:08:36 4: 26343:FHEMWEB:192.168.2.25:52957: /fhem?cmd={AttrVal(%22OG_Bad_Waschb_T%22,%22room%22,%22%22)}&XHR=1 / RL:43 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.05.19 17:08:36 4: HTTP FHEMWEB:192.168.2.25:52964 GET /fhem?XHR=1&inform=type=status;filter=OG_Bad_Waschb_T;since=1432048112;fmt=JSON×tamp=1432048118119
2015.05.19 17:08:42 4: Connection closed for FHEMWEB:192.168.2.25:52964: Connection reset by peer
2015.05.19 17:08:42 4: HTTP FHEMWEB:192.168.2.25:52957 GET /fhem?XHR=1&inform=type=status;filter=room=Badezimmer;since=1432048098;fmt=JSON×tamp=1432048124286
2015.05.19 17:08:47 4: HTTP FHEMWEB:192.168.2.25:52966 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2015-05.log
Zwar kommt jetzt kein "Invalid device" mehr, aber ich hab heute auch ein bisschen rumprobiert und hab die Thermostate mit Komma getrennt aufgeführt bzw. mit | oder auch einmal mit "and"... hat alles nichts gebracht.
Da ist aber z.B. eine Fundstelle im Log, die ich meinte... Aber leider halt mit verbose=3.
2015.05.17 10:14:08 3: [HC_Bad_Normal] invalid device, <OG_Bad_T> not found
2015.05.17 10:14:08 3: [HC_Bad_KeinArbeitstag] invalid device, <OG_Bad_T> not found
2015.05.17 10:14:08 3: [HC_Bad_Off] invalid device, <OG_Bad_T> not found
2015.05.17 10:14:08 3: [HC_Bad_Min] invalid device, <OG_Bad_T> not found
Ich denke dein Problem ist lösbar!
2015.05.17 10:14:08 3: [HC_Bad_Normal] invalid device, <OG_Bad_T> not found
kommt immer dann wenn das benannte Gerät in fhem noch nicht bekannt ist. Ursache: Reihenfolgenproblem in der Definitionsdatei.
Ist aber nicht weiter schlimm, weil es sich nur um einen Hinweis handelt.
Das Problem entsteht durch folgenden Code, der von structure an die MAX Thermostate weitergegeben, aber nicht verstanden werden:
2015.05.19 17:07:00 5: Cmd: >set OG_Bad_T 20<
Structures werden von HC nicht direkt als Heizungen erkannt - wie auch.
Du must HC helfen den richtigen Befehl zu generieren:
Versuch bitte mal:
define HC_Bad_Min Heating_Control OG_Bad_T mo-fr|05:15|22.5 mo-fr|07:15|15 $we|08:00|22 $we|19:00|15 { fhem("set @ desiredTemperature %") if (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal")}
Dann wird
set OG_Bad_T desiredTemperature 20
als Code erzeugt und verarbeitet. Das sollte dann jeweils an die MAX-Thermostate weitergereicht und verstanden werden.
Du musst übrigens nicht komplett durchstarten und verbose global setzen. Es reicht wenn du verbose auf einzelne devices setzt. Es ist auch möglich in den details das HC einfach neu zu definieren, dann wird ebenfalls geschaltet .
Jetzt funktioniert es. Da wäre ich als Neuling nie drauf gekommen. Wäre das nicht was fürs Wiki?
Danke!
in den Beispielen in der commandref steht das eigentlich so drin.
Und wie wäre der Code wenn ich zwei ReadingsVal Und-Verknüpfen will? Hab folgendes versucht, aber das klappt nicht:
define HC_Bad_KeinArbeitstag Heating_Control OG_Bad_T mo-so|07:45|22 mo-so|19:00|20 { fhem("set @ desiredTemperature %") if ((ReadingsVal("HCWeekprofile", "state", "") eq "off") and (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Auto"))}
and durch && ersetzen
Wenn es zu kompliziert wird es in einer Zeile auszudrücken, dann eine Funktion in 99_utils aufnehmen und von HC aufrufen
Ich schon wieder :(
Ich hab bei einem Heating_Control einen Fensterkontakt eingefügt und einen Schaltpunkt provoziert. Dabei wird erkannt, dass das Fenster offen ist, aber trotzdem wird die Temperatur wieder hoch gesetzt - das kann doch nicht sein, oder?
Logfile sagt folgendes:
2015.05.22 15:37:00 5: [HC_Gaesteklo_Min] list of window sensors found: 'EG_Bad_Fensterkontakt HC_Gaesteklo_Min' 2015.05.22 15:37:00 5: [HC_Gaesteklo_Min] sensor 'EG_Bad_Fensterkontakt' Reading/Attribute 'state' is 'opened' 2015.05.22 15:37:00 4: [HC_Gaesteklo_Min]:Update - timer seems to be active today: 0123456|15:37|20 2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] device type MAX:HeatingThermostat recognized, setModifier:desiredTemperature 2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] aktParam:12.0 newParam:20.0 - is not disabled 2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] command: set EG_Bad_T desiredTemperature 20.0 executed 2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] akt: 2015-05-22 15:37:00(fr) -->> 20 2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] next: 2015-05-23 08:00:00(sa) -->> 18
Das liegt wahrscheinlich daran, dass dein Fensterkontakttyp nicht automatisch erkannt wird.
Siehe Anhang!!!
Je nach Typ findet das Modul im state oder sonstwo einen Text, der einen bestimmten Inhalt haben muss.
Mit dem state opened ist mir kein Fensterkontakt bekannt.
2015.05.22 15:37:00 5: [HC_Gaesteklo_Min] list of window sensors found: 'EG_Bad_Fensterkontakt HC_Gaesteklo_Min'
2015.05.22 15:37:00 5: [HC_Gaesteklo_Min] sensor 'EG_Bad_Fensterkontakt' Reading/Attribute 'state' is 'opened'
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min]:Update - timer seems to be active today: 0123456|15:37|20
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] device type MAX:HeatingThermostat recognized, setModifier:desiredTemperature
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] aktParam:12.0 newParam:20.0 - is not disabled
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] command: set EG_Bad_T desiredTemperature 20.0 executed
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] akt:
2015-05-22 15:37:00(fr) -->> 20
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] next:
2015-05-23 08:00:00(sa) -->> 18
Um was handelt es sich bei EG_Bad_Fensterkontakt denn?
Es kann natürlich auch noch sein, dass nach der großen Umstellung vor Ostern das eine oder andere nicht vollständig funktioniert.
Das sind die MAX Fensterkontakte.
Hier die Internals:
DEF ShutterContact 024d71
IODev cm
LASTInputDev cm
MSGCNT 56
NAME EG_Bad_Fensterkontakt
NR 51
RSSI -49
STATE closed
TYPE MAX
addr 024d71
backend cm
cm_MSGCNT 56
cm_TIME 2015-05-22 19:32:03
rferror 0
type ShutterContact
Kannst du dir beim posten bitte Mühe geben und Code, Auszüge aus Logs und Readings mit den Formatierern bearbeiten.
Für sämtliche ehrenamtliche Entwicker hier ist es dann einfacher die Probleme zu erfassen und noch schneller zu helfen.
Ich nehme mal den Zustand opened für Fensterkontakte von MAX auf und gebe das Modul frei, wenn sonst nichts gegen die Freigabe spricht.
Ja ich werde mir mehr Mühe geben. Ich antworte derzeit meist mit dem Handy und Tapatalk, da gibt es keine Buttons für "Code" etc. Aber ich weiß, die kann man auch manuell einfügen, sorry!
Die Zustände sind "opened" und "closed".
habe es geändert - prüf bitte ob es funktkioniert.
Ich habe kein MAX und kann das auch nicht wirklich testen.
Funktioniert perfekt! Vielen Dank für deine Unterstützung!
Heute (Pfingstmontag) ist mal wieder Wochentag und Feiertag gleichzeitig.
Freundlicherweise ging mein Musikwecker daher um 05:45 Uhr an (Einstellung für Montag) und quasi nochmal um 08:00 Uhr (Einstellung für Wochenende/Feiertag). :(
Da ich hier http://forum.fhem.de/index.php/topic,10011.msg283580.html#msg283580 (http://forum.fhem.de/index.php/topic,10011.msg283580.html#msg283580) bisher keine Antwort bekommen habe, gehe ich nun davon aus, dass man (zumindest ohne zusätzliche Abfragen) nur entweder mit den Wochentagen oder $we / !$we arbeiten kann!?
Zitat
Zurück zur Frage...
- wird nun an einem Samstag, der ja gleichzeitig auch WE ist, um 7:30 oder um 8:00 Uhr geschaltet?
- wird an einem Feiertag-Montag, wie jetzt Ostermontag gewesen wäre, um 5:45 oder um 8:00 Uhr geschaltet?
- wie müsste ich es korrekt definieren, um "nur" einen Feiertag wie einen Sonntag zu behandeln?
Bitte keine Antwort "warte es doch ab und lass Dich überraschen"; es geht um das Verständnis und die richtige Konfiguration. :-[
Gruß,
Hollo
Zitat
Bitte keine Antwort "warte es doch ab und lass Dich überraschen"; es geht um das Verständnis und die richtige Konfiguration. :-[
Bitte keine Antwort heißt ... keine Antwort
Bei den Angaben zum Tag handelt es sich immer im logische Oder - Verknüpfungen.
Zitat von: Dietmar63 am 25 Mai 2015, 23:01:06
Bitte keine Antwort heißt ... keine Antwort
Bitte keine Antwort "warte es doch ab und lass Dich überraschen" heisst... ich hätte gern einen konkreten Tipp/Hinweis gehabt. ;)
ZitatBei den Angaben zum Tag handelt es sich immer im logische Oder - Verknüpfungen.
Aha. Dementsprechend wird die "Bedingung" natürlich sowohl um 05:45 für Montag als auch um 08:00 für den Feiertag wahr.
Dann muss ich halt innerhalb der Woche immer zur selben Zeit starten, oder eine zusätzliche Abfrage auf $we einbauen, um die Doppelung zu filtern.
Hallo,
ich habe folgendes Problem. Ich möchte HeatingCOntrol deaktivieren, da ich es derzeit noch nicht benötige. Ich habe es mit set HC disable deaktiviert. In den Readings wird es auch so angezeigt. Im state bleibt jedoch immer die in den Zeiten angegebene Temperatur stehen (z.B state 5). Zu den angegebenen Schaltpunkten ändert sich dann gemäß der Definition die Temperatur. Dies führt teilweise dazu das die Heizung anspringt was ich nicht möchte.
Falls jemand einen Hinweis hat, wäre ich dankbar.
Danke
Ralph
Setze mal verbose 5 zu dem HC und poste dann den Inhalt des Logs.
Welche Version von HC verwendest du?
Hallo,
anbei die Version die ich nutze.
98_Heating_Control.pm 8517 2015-05-02 20:07:15Z dietmar63
Nachdem ich das verbose 5 gesetzt habe, habe noch einmal ein set disable abgesendet. Anbei der Eintrag im Log
[HC_Gae] set HC_Gae disable
Grüße
Ralph
Das ist ein wenig dünn.
wenn du verbose eingeschaltet hast, muss zu jedem definierten Schlatzeitpunkt folgendes geloggt werden.
Das Protokoll wird schon ein wenig umfangreicher sein:
2015.05.22 15:37:00 5: [HC_Gaesteklo_Min] list of window sensors found: 'EG_Bad_Fensterkontakt HC_Gaesteklo_Min'
2015.05.22 15:37:00 5: [HC_Gaesteklo_Min] sensor 'EG_Bad_Fensterkontakt' Reading/Attribute 'state' is 'opened'
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min]:Update - timer seems to be active today: 0123456|15:37|20
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] device type MAX:HeatingThermostat recognized, setModifier:desiredTemperature
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] aktParam:12.0 newParam:20.0 - is not disabled
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] command: set EG_Bad_T desiredTemperature 20.0 executed
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] akt:
wie sieht denn deine Defintion von [HC_Gae] aus?
Hallo Dietmar,
ich habe nun einen Schaltpunkt abgewartet.
Anbei nun der Auszug aus dem Logfile:
2015.09.25 20:00:00 5: [HC_Gae] list of window sensors found: 'HC_Gae'
2015.09.25 20:00:00 4: [HC_Gae] Update - timer seems to be active today: 0123456|20:00|5
2015.09.25 20:00:00 4: [HC_Gae] akt: 2015-09-25 20:00:00(fr) -->> 5
2015.09.25 20:00:00 4: [HC_Gae] next: 2015-09-26 10:00:00(sa) -->> 19
2015.09.25 20:00:00 4: [HC_Gae] device type THRESHOLD: recognized, setModifier:
2015.09.25 20:00:00 4: [HC_Gae] aktParam: newParam:5 - is disabled
Hier noch die DEF
DEF TH_Gae 0123456|10:00|19 0123456|20:00|5 set @ desired %
Ergänzend noch die DEF von TH_Gae
DEF TF_Gaeste:temperature:0.5 OR TH_aussen:state:off HZ_G_Fe_li|set @ desiredTemperature off|set @ desiredTemperature on
Grüße
Ralph
...
und damit wird dem Gerät [HC_Gae] kein Schaltbefehl gesendet, sonst wäre so etwas im log aufgetaucht:
2015.05.22 15:37:00 4: [HC_Gaesteklo_Min] command: set EG_Bad_T desired 5.0 executed
handelt es sich nachfolgend auch um ein HC?
Ergänzend noch die DEF von TH_Gae
DEF TF_Gaeste:temperature:0.5 OR TH_aussen:state:off HZ_G_Fe_li|set @ desiredTemperature off|set @ desiredTemperature on
Nein TH_Gae ist ein THRESHOLD.
Die beiden hängen aber voneinander ab. Ich schalte damit die Heizung bei einer Außentemperatur von unter 15° und einer Unterschreitung der durch HC vorgegebenen Temp.
Dann war vermutlich um 15:37 das disable Attribut nicht gesetzt.
Ausserdem steht im Log HC_Gaesteklo_Min und nicht HC_Gae
Danke Dir für Deine Hilfe.
Ich werde es weiter beobachten.
HC_Gaesteklo_Min stammt nicht aus meiner Konfig.
Grüße
Ralph
Hi,
kann man für ein Device nicht Wildcards verwenden ?
Also z.B. HK_HM_Wohnen_.*_Clima ?
Möchte 2 Thermostate gleichzeitig schalten.
Gruss
Joe
Hallo!
Ich hatte es schon mal wo anders diese Fehlermeldung gepostet aber hier scheint der richtige Ort zu sein:
2015.10.14 08:22:20 1: PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at /opt/fhem/FHEM/98_WeekdayTimer.pm line 602.
2015.10.14 08:22:20 3: stacktrace:
2015.10.14 08:22:20 3: main::__ANON__ called by /opt/fhem/FHEM/98_WeekdayTimer.pm (602)
2015.10.14 08:22:20 3: main::WeekdayTimer_Update called by /opt/fhem/FHEM/98_Heating_Control.pm (85)
2015.10.14 08:22:20 3: main::Heating_Control_Update called by fhem.pl (2699)
2015.10.14 08:22:20 3: main::HandleTimeout called by fhem.pl (583)
2015.10.14 08:22:20 1: PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at /opt/fhem/FHEM/98_WeekdayTimer.pm line 602.
2015.10.14 08:22:20 3: stacktrace:
2015.10.14 08:22:20 3: main::__ANON__ called by /opt/fhem/FHEM/98_WeekdayTimer.pm (602)
2015.10.14 08:22:20 3: main::WeekdayTimer_Update called by /opt/fhem/FHEM/98_Heating_Control.pm (85)
2015.10.14 08:22:20 3: main::Heating_Control_Update called by fhem.pl (2699)
2015.10.14 08:22:20 3: main::HandleTimeout called by fhem.pl (583)
2015.10.14 08:22:20 1: PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at /opt/fhem/FHEM/98_WeekdayTimer.pm line 602.
2015.10.14 08:22:20 3: stacktrace:
2015.10.14 08:22:20 3: main::__ANON__ called by /opt/fhem/FHEM/98_WeekdayTimer.pm (602)
2015.10.14 08:22:20 3: main::WeekdayTimer_Update called by /opt/fhem/FHEM/98_Heating_Control.pm (85)
2015.10.14 08:22:20 3: main::Heating_Control_Update called by fhem.pl (2699)
2015.10.14 08:22:20 3: main::HandleTimeout called by fhem.pl (583)
2015.10.14 08:22:20 1: PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at /opt/fhem/FHEM/98_WeekdayTimer.pm line 602.
2015.10.14 08:22:20 3: stacktrace:
2015.10.14 08:22:20 3: main::__ANON__ called by /opt/fhem/FHEM/98_WeekdayTimer.pm (602)
2015.10.14 08:22:20 3: main::WeekdayTimer_Update called by /opt/fhem/FHEM/98_Heating_Control.pm (85)
2015.10.14 08:22:20 3: main::Heating_Control_Update called by fhem.pl (2699)
2015.10.14 08:22:20 3: main::HandleTimeout called by fhem.pl (583)
2015.10.14 08:22:20 1: PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at /opt/fhem/FHEM/98_WeekdayTimer.pm line 602.
2015.10.14 08:22:20 3: stacktrace:
2015.10.14 08:22:20 3: main::__ANON__ called by /opt/fhem/FHEM/98_WeekdayTimer.pm (602)
2015.10.14 08:22:20 3: main::WeekdayTimer_Update called by /opt/fhem/FHEM/98_Heating_Control.pm (85)
2015.10.14 08:22:20 3: main::Heating_Control_Update called by fhem.pl (2699)
2015.10.14 08:22:20 3: main::HandleTimeout called by fhem.pl (583)
2015.10.14 08:22:20 1: PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at /opt/fhem/FHEM/98_WeekdayTimer.pm line 602.
Ich habe leider keinen Plan wo ich da ansetzten könnte, aber vielleicht könnte man zusammen die Ursache finden?!
Mfg Steffen
Ich untersuche das heute Abend mal.
Bitte mal die Definition des HC posten
Zitat von: cotecmania am 14 Oktober 2015, 19:07:11
Hi,
kann man für ein Device nicht Wildcards verwenden ?
Also z.B. HK_HM_Wohnen_.*_Clima ?
Möchte 2 Thermostate gleichzeitig schalten.
Gruss
Joe
Ggf ja.
Hc erzeugt intern einen fhem("set device desired-temp temp") Aufruf. Wenn der Aufruf als device Wildcards verwenden kann funktioniert das auch mit HC
Zitat von: Dietmar63 am 15 Oktober 2015, 07:49:49
Ich untersuche das heute Abend mal.
Bitte mal die Definition des HC posten
Danke!
Das ist nur eins habe aber insgesamt 5, brauchst du die anderen dann auch noch???
Internals:
DEF ArbeitszimmerKeller 12345|04:55|18.0 12345|06:02|16.0 12345|14:05|18.0 12345|21:05|16.0 60|12:00|18.0 60|18:05|16.0
DEVICE ArbeitszimmerKeller
GlobalDaylistSpec
LANGUAGE de
NAME BueroKeller
NR 145
Profil 0: Sonntag 12:00:00 18.0, 18:05:00 16.0
Profil 1: Montag 04:55:00 18.0, 06:02:00 16.0, 14:05:00 18.0, 21:05:00 16.0
Profil 2: Dienstag 04:55:00 18.0, 06:02:00 16.0, 14:05:00 18.0, 21:05:00 16.0
Profil 3: Mittwoch 04:55:00 18.0, 06:02:00 16.0, 14:05:00 18.0, 21:05:00 16.0
Profil 4: Donnerstag 04:55:00 18.0, 06:02:00 16.0, 14:05:00 18.0, 21:05:00 16.0
Profil 5: Freitag 04:55:00 18.0, 06:02:00 16.0, 14:05:00 18.0, 21:05:00 16.0
Profil 6: Samstag 12:00:00 18.0, 18:05:00 16.0
STATE 16.0
STILLDONETIME
TYPE Heating_Control
Readings:
2015-10-14 08:21:53 disabled 0
2015-10-15 06:02:00 nextUpdate 2015-10-15 14:05:00
2015-10-15 06:02:00 nextValue 18.0
2015-10-15 06:02:00 state 16.0
SWITCHINGTIMES:
12345|04:55|18.0
12345|06:02|16.0
12345|14:05|18.0
12345|21:05|16.0
60|12:00|18.0
60|18:05|16.0
Timer:
Buerokeller_1:
HASH BueroKeller
MODIFIER 1
NAME BueroKeller_1
Buerokeller_2:
HASH BueroKeller
MODIFIER 2
NAME BueroKeller_2
Buerokeller_3:
HASH BueroKeller
MODIFIER 3
NAME BueroKeller_3
Buerokeller_4:
HASH BueroKeller
MODIFIER 4
NAME BueroKeller_4
Buerokeller_5:
HASH BueroKeller
MODIFIER 5
NAME BueroKeller_5
Buerokeller_6:
HASH BueroKeller
MODIFIER 6
NAME BueroKeller_6
Buerokeller_settimerofday:
HASH BueroKeller
MODIFIER SetTimerOfDay
NAME BueroKeller_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
12:00:00 18.0
18:05:00 16.0
1:
04:55:00 18.0
06:02:00 16.0
14:05:00 18.0
21:05:00 16.0
2:
04:55:00 18.0
06:02:00 16.0
14:05:00 18.0
21:05:00 16.0
3:
04:55:00 18.0
06:02:00 16.0
14:05:00 18.0
21:05:00 16.0
4:
04:55:00 18.0
06:02:00 16.0
14:05:00 18.0
21:05:00 16.0
5:
04:55:00 18.0
06:02:00 16.0
14:05:00 18.0
21:05:00 16.0
6:
12:00:00 18.0
18:05:00 16.0
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1444877700
PARA 18.0
TIME 04:55
TAGE:
1
2
3
4
5
2:
EPOCH 1444881720
PARA 16.0
TIME 06:02
TAGE:
1
2
3
4
5
3:
EPOCH 1444910700
PARA 18.0
TIME 14:05
TAGE:
1
2
3
4
5
4:
EPOCH 1444935900
PARA 16.0
TIME 21:05
TAGE:
1
2
3
4
5
5:
EPOCH 1444903200
PARA 18.0
TIME 12:00
TAGE:
0
6
6:
EPOCH 1444925100
PARA 16.0
TIME 18:05
TAGE:
0
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
room Heizung_Steuerung
nein,
hast du den Fehler einmal gehabt, nach einem Start, oder kommt er immer wieder?
kannst du die Versions-ID der Module
WeekdayTimer
Heating_Control
posten.
Zitat von: Dietmar63 am 15 Oktober 2015, 20:48:13
nein,
hast du den Fehler einmal gehabt, nach einem Start, oder kommt er immer wieder?
kannst du die Versions-ID der Module
WeekdayTimer
Heating_Control
posten.
Also der Fehler kommt ca.1x in der Stunde!
$Id: 98_WeekdayTimer.pm 9401 2015-10-07 21:22:54Z dietmar63 $
$Id: 98_Heating_Control.pm 8517 2015-05-02 20:07:15Z dietmar63 $
Mfg Steffen
probier mal die jetzige Version
Hallo Dietmar,
bei mir war die gleiche Meldung im Log.
Mit # $Id: 98_WeekdayTimer.pm 9461 2015-10-15 22:12:05Z dietmar63 $
ist die Meldung weg.
Merci
FillyFairy
Jetzt wo wieder die Heizperiode ist, habe ich auch leider wieder Probleme mit dem Modul.
Manchmal wird gar nicht geschalten und machmal wird gleich zwei, drei oder sogar viermal direkt hinter einander geschalten.
Was mich auch stört, immer wieder geht state auf inactive, anstelle des richtige Wert. Das ist sehr blöd, weil ich anhand des states Werte setzte.
Hier z.B.:
Bad ist gerade inactive
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEF HZ_Bad_WT_Climate 12345|06:00|22 1234|07:00|16 5|07:00|20 7|08:30|21.5 7|10:00|20 1234|12:00|20 1234|19:30|21.5 57|20:30|21.5 22:00|16 (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEVICE HZ_Bad_WT_Climate
GlobalDaylistSpec
LANGUAGE de
NAME HCB
NR 668
Profil 0: Sonntag 08:30:00 21.5, 10:00:00 20, 20:30:00 21.5, 22:00:00 16
Profil 1: Montag 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 2: Dienstag 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 3: Mittwoch 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 4: Donnerstag 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 5: Freitag 06:00:00 22, 07:00:00 20, 20:30:00 21.5, 22:00:00 16
Profil 6: Samstag 08:30:00 21.5, 10:00:00 20, 20:30:00 21.5, 22:00:00 16
Profil 7: Wochenende 08:30:00 21.5, 10:00:00 20, 20:30:00 21.5
STATE inactive
STILLDONETIME
TYPE Heating_Control
Readings:
2015-10-12 19:10:48 disabled 0
2015-10-17 14:23:20 nextUpdate 2015-10-17 20:30:00
2015-10-17 14:23:20 nextValue 21.5
2015-10-17 14:23:20 state inactive
SWITCHINGTIMES:
12345|06:00|22
1234|07:00|16
5|07:00|20
7|08:30|21.5
7|10:00|20
1234|12:00|20
1234|19:30|21.5
57|20:30|21.5
22:00|16
Timer:
Hcb_2:
HASH HCB
MODIFIER 2
NAME HCB_2
Hcb_7:
HASH HCB
MODIFIER 7
NAME HCB_7
Hcb_8:
HASH HCB
MODIFIER 8
NAME HCB_8
Hcb_9:
HASH HCB
MODIFIER 9
NAME HCB_9
Hcb_settimerofday:
HASH HCB
MODIFIER SetTimerOfDay
NAME HCB_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
08:30:00 21.5
10:00:00 20
20:30:00 21.5
22:00:00 16
1:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
2:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
3:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
4:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
5:
06:00:00 22
07:00:00 20
20:30:00 21.5
22:00:00 16
6:
08:30:00 21.5
10:00:00 20
20:30:00 21.5
22:00:00 16
7:
08:30:00 21.5
10:00:00 20
20:30:00 21.5
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1445054400
PARA 22
TIME 06:00
TAGE:
1
2
3
4
5
2:
EPOCH 1445058000
PARA 16
TIME 07:00
TAGE:
1
2
3
4
3:
EPOCH 1445058000
PARA 20
TIME 07:00
TAGE:
5
4:
EPOCH 1445063400
PARA 21.5
TIME 08:30
TAGE:
7
5:
EPOCH 1445068800
PARA 20
TIME 10:00
TAGE:
7
6:
EPOCH 1445076000
PARA 20
TIME 12:00
TAGE:
1
2
3
4
7:
EPOCH 1445103000
PARA 21.5
TIME 19:30
TAGE:
1
2
3
4
8:
EPOCH 1445106600
PARA 21.5
TIME 20:30
TAGE:
5
7
9:
EPOCH 1445112000
PARA 16
TIME 22:00
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Bad
group Heizplan
room Heizung
verbose 3
windowSensor Fenster_Bad
Hallo,
Kann mich auch nur bedanken, denn bei mir sind die Fehlermeldungen mit der Aktuellen Version auch weg...
Danke...
Mfg Steffen
2015-10-17 14:23:20 nextUpdate 2015-10-17 20:30:00
2015-10-17 14:23:20 nextValue 21.5
2015-10-17 14:23:20 state inactive
irgendetwas hat bei deiner Installatin dafür gesorgt, dass die readings um 14:23:20 gesetzt wurden.
Was auch immer zu diesem Zeitpunkt geschehen ist, zu diesem Zeitpunkt war vermutlich
(ReadingsVal("HCAutomatik", "state", "off") eq "on") false.
Hast du eine Erklärung für diesen Zeitpunkt? Was ist um jene Zeit geschehen. Vielleicht ein
HC_SetAllTemps()?Änderst du mit irgendwelchen Logiken den Wert von "HCAutomatik"?
Dann prüf mal das Timing.
Setze bei dem HC mal verbose auf 4, dann prüf mal den output. Protokolliere vierlliecht parrallel per notify die Werte von HCAutomatik.
Beim Start von fhem muss
HCAutomatik vor allen HC definiert sein. Wenn das nicht der Fall ist, werden beim Start die Anfangswerte nicht richtig gesetzt - wie auch.
Zitat... habe ich auch leider wieder Probleme ...
Die Probleme sind leider durch eine umfangreiche Umstellung innerhalb des Moduls entstanden, die sich ergeben hat um $we bzw. !$we in der Definition zu ermöglichen.
Die letzen Probleme dieser Umstellung werden wir gemeinsam finden müssen, weil ich nicht die Zeit habe sämtliche Testfälle bei mir durchzuprobieren und ich leider kein automatisches Testtool zur Verfügung habe.
Falls dir das zu viel Arbeit ist, solltetst du auf Rudis
at's umstellen.
Hi,
Zitat von: Dietmar63 am 15 Oktober 2015, 07:54:02
Ggf ja.
Hc erzeugt intern einen fhem("set device desired-temp temp") Aufruf. Wenn der Aufruf als device Wildcards verwenden kann funktioniert das auch mit HC
anscheinend nicht.
es gibt 2 HM-Thermostate
- HK_HM_WOHNEN_E_Clima
- HK_HM_WOHNEN_W_Clima
Von Hand kann ich Beide setzen mit : set HK_HM_WOHNEN_(E|W)_Clima desired-temp 24 oder set HK_HM_WOHNEN_._Clima desired-temp 24
Mit HeatingControl kommt diese Fehlermeldung im LOG :
[HC.HK_WOHNEN2] invalid device, <HK_HM_WOHNEN_._Clima> not found
Selbiges bei einer Liste z.B. :
set HK_HM_WOHNEN_E_Clima,HK_HM_WOHNEN_W_Clima desired-temp 22 funktioniert, aber mit HC nicht
LOG:
[HC.HK_WOHNEN1] invalid device, <HK_HM_WOHNEN_E_Clima,HK_HM_WOHNEN_W_Clima> not found
Gruss
Zitat von: Dietmar63 am 17 Oktober 2015, 22:52:04
2015-10-17 14:23:20 nextUpdate 2015-10-17 20:30:00
2015-10-17 14:23:20 nextValue 21.5
2015-10-17 14:23:20 state inactive
irgendetwas hat bei deiner Installatin dafür gesorgt, dass die readings um 14:23:20 gesetzt wurden.
Was auch immer zu diesem Zeitpunkt geschehen ist, zu diesem Zeitpunkt war vermutlich
(ReadingsVal("HCAutomatik", "state", "off") eq "on")
false.
Hast du eine Erklärung für diesen Zeitpunkt? Was ist um jene Zeit geschehen. Vielleicht ein HC_SetAllTemps()?
Okay, da wurde ein Heating_Control_SetTimer() gemacht.
Aber trotzdem sollte doch der state auf der aktuellen Temperatur sein?
Zitat von: Dietmar63 am 17 Oktober 2015, 22:52:04
Änderst du mit irgendwelchen Logiken den Wert von "HCAutomatik"?
Dann prüf mal das Timing.
Nein, normalerweise wird die Automatik einmal im Herbs eingeschalten und im Frühling wieder aus.
Zitat von: Dietmar63 am 17 Oktober 2015, 22:52:04
Setze bei dem HC mal verbose auf 4, dann prüf mal den output. Protokolliere vierlliecht parrallel per notify die Werte von HCAutomatik.
Beim Start von fhem muss HCAutomatik vor allen HC definiert sein. Wenn das nicht der Fall ist, werden beim Start die Anfangswerte nicht richtig gesetzt - wie auch.
Die Probleme sind leider durch eine umfangreiche Umstellung innerhalb des Moduls entstanden, die sich ergeben hat um $we bzw. !$we in der Definition zu ermöglichen.
Die letzen Probleme dieser Umstellung werden wir gemeinsam finden müssen, weil ich nicht die Zeit habe sämtliche Testfälle bei mir durchzuprobieren und ich leider kein automatisches Testtool zur Verfügung habe.
Falls dir das zu viel Arbeit ist, solltetst du auf Rudis at's umstellen.
Okay, HCAutomatik werde ich mir gleich anschauen.
Ich teste gerne, wenn Du mir sagst was.
Gerade ist mir noch aufgefallen, das der open window Status auch nicht immer stimmt.
Wann wird denn open window gesetzte? Immer, wenn Fenster auf geht, oder nur wenn bei offenen Fenster geschalten werden soll?
Vielen Dank schonmal Dietmar!!
Gerade wieder nachgesehen, es wurde nichts an fhem geändert und es sind fast alle auf inactive??
Hallo,
Nur ein Verdacht:
Kann es sein, dass state inactive wird, wenn das Attribut disable einen Wert hat, also überhaupt vorhanden ist? Bei meinen Devices ohne dieses Attribut ist state korrekt.
Gruß
Hans
möglich.
Ich habe jetzt das Attribute bei allen gelöscht, mal sehen.
Zitat von: cotecmania am 18 Oktober 2015, 10:45:44
Hi,
anscheinend nicht.
es gibt 2 HM-Thermostate
- HK_HM_WOHNEN_E_Clima
- HK_HM_WOHNEN_W_Clima
Von Hand kann ich Beide setzen mit : set HK_HM_WOHNEN_(E|W)_Clima desired-temp 24 oder set HK_HM_WOHNEN_._Clima desired-temp 24
Mit HeatingControl kommt diese Fehlermeldung im LOG :
[HC.HK_WOHNEN2] invalid device, <HK_HM_WOHNEN_._Clima> not found
Selbiges bei einer Liste z.B. :
set HK_HM_WOHNEN_E_Clima,HK_HM_WOHNEN_W_Clima desired-temp 22 funktioniert, aber mit HC nicht
LOG:
[HC.HK_WOHNEN1] invalid device, <HK_HM_WOHNEN_E_Clima,HK_HM_WOHNEN_W_Clima> not found
Gruss
Invalid device ist nur ein Hinweis. Der HC sollte korrekt definiert sein. Prüf mal mit verbose 4 was im Protokoll erscheint.
Zitat von: cotecmania am 18 Oktober 2015, 10:45:44
Hi,
anscheinend nicht.
es gibt 2 HM-Thermostate
- HK_HM_WOHNEN_E_Clima
- HK_HM_WOHNEN_W_Clima
Von Hand kann ich Beide setzen mit : set HK_HM_WOHNEN_(E|W)_Clima desired-temp 24 oder set HK_HM_WOHNEN_._Clima desired-temp 24
Mit HeatingControl kommt diese Fehlermeldung im LOG :
[HC.HK_WOHNEN2] invalid device, <HK_HM_WOHNEN_._Clima> not found
Selbiges bei einer Liste z.B. :
set HK_HM_WOHNEN_E_Clima,HK_HM_WOHNEN_W_Clima desired-temp 22 funktioniert, aber mit HC nicht
LOG:
[HC.HK_WOHNEN1] invalid device, <HK_HM_WOHNEN_E_Clima,HK_HM_WOHNEN_W_Clima> not found
Gruss
Invalid device ist nur ein Hinweis. Der HC sollte korrekt definiert sein. Prüf mal mit verbose 4 was im Protokoll erscheint.
, oder nur wenn bei offenen Fenster geschalten werden soll?
Ja, HC wacht natürlich nur bei eigenen Ereignissen auf.
Okay, HCAutomatik werde ich mir gleich anschauen.
Ich teste gerne, wenn Du mir sagst was.
Was was um 14:23 Uhr los? Warum wurden die readings gesetzt?
Liefere Protokolle eines HC mit dem Inhalt HCAutomatik
Bin leider jetzt schlecht verfügbar - Kurzurlaub in Amsterdam
Zitat von: Dietmar63 am 18 Oktober 2015, 14:51:09
Okay, HCAutomatik werde ich mir gleich anschauen.
Ich teste gerne, wenn Du mir sagst was.
Was was um 14:23 Uhr los? Warum wurden die readings gesetzt?
Liefere Protokolle eines HC mit dem Inhalt HCAutomatik
Um 14:23 Uhr wurde ein
Heating_Control_SetAllTemps() gemacht.
Leider funktioniert aber, vermutlich aufgrund des inactive, ein Heating_Control_SetAllTemps() nicht.
Es werden nicht die aktuellen Temperaturen gesetzt.
Was war denn inactive?
Alle Definitionen warnen inactive.
Im Moment sind z.B. von 13, 4 inactive.
Ich kann leider keine Logik darin sehen. Mal ist es die, mal eine andere.
Sehr häufig ist es nur eine, die vom Bad.
Gerade um 22:30 Uhr war ein "Schaltpunkt" bei einer Definition. Es wurde zwar geschalten, aber es steht immer noch auf inactive.
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEF HZ_Wohnzimmer_WT_Climate 12345|06:00|22 1234|07:30|16 5|07:30|21.5 1234|12:00|21.5 7|08:00|21.5 19:00|22 22:30|16 (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEVICE HZ_Wohnzimmer_WT_Climate
GlobalDaylistSpec
LANGUAGE de
NAME HCW
NR 668
Profil 0: Sonntag 08:00:00 21.5, 19:00:00 22, 22:30:00 16
Profil 1: Montag 06:00:00 22, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16
Profil 2: Dienstag 06:00:00 22, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16
Profil 3: Mittwoch 06:00:00 22, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16
Profil 4: Donnerstag 06:00:00 22, 07:30:00 16, 12:00:00 21.5, 19:00:00 22, 22:30:00 16
Profil 5: Freitag 06:00:00 22, 07:30:00 21.5, 19:00:00 22, 22:30:00 16
Profil 6: Samstag 08:00:00 21.5, 19:00:00 22, 22:30:00 16
Profil 7: Wochenende 08:00:00 21.5
STATE inactive
STILLDONETIME
TYPE Heating_Control
Readings:
2015-10-18 14:07:50 disabled 0
2015-10-18 22:36:01 nextUpdate 2015-10-19 06:00:00
2015-10-18 22:36:01 nextValue 22
2015-10-18 22:36:01 state inactive
SWITCHINGTIMES:
12345|06:00|22
1234|07:30|16
5|07:30|21.5
1234|12:00|21.5
7|08:00|21.5
19:00|22
22:30|16
Timer:
Hcw_3:
HASH HCW
MODIFIER 3
NAME HCW_3
Hcw_7:
HASH HCW
MODIFIER 7
NAME HCW_7
Hcw_settimerofday:
HASH HCW
MODIFIER SetTimerOfDay
NAME HCW_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
08:00:00 21.5
19:00:00 22
22:30:00 16
1:
06:00:00 22
07:30:00 16
12:00:00 21.5
19:00:00 22
22:30:00 16
2:
06:00:00 22
07:30:00 16
12:00:00 21.5
19:00:00 22
22:30:00 16
3:
06:00:00 22
07:30:00 16
12:00:00 21.5
19:00:00 22
22:30:00 16
4:
06:00:00 22
07:30:00 16
12:00:00 21.5
19:00:00 22
22:30:00 16
5:
06:00:00 22
07:30:00 21.5
19:00:00 22
22:30:00 16
6:
08:00:00 21.5
19:00:00 22
22:30:00 16
7:
08:00:00 21.5
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1445140800
PARA 22
TIME 06:00
TAGE:
1
2
3
4
5
2:
EPOCH 1445146200
PARA 16
TIME 07:30
TAGE:
1
2
3
4
3:
EPOCH 1445146200
PARA 21.5
TIME 07:30
TAGE:
5
4:
EPOCH 1445162400
PARA 21.5
TIME 12:00
TAGE:
1
2
3
4
5:
EPOCH 1445148000
PARA 21.5
TIME 08:00
TAGE:
7
6:
EPOCH 1445187600
PARA 22
TIME 19:00
TAGE:
0
1
2
3
4
5
6
7:
EPOCH 1445200200
PARA 16
TIME 22:30
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Wohnzimmer/Küche
group Heizplan
room Heizung
verbose 3
windowSensor d_ECOMode Fenster_Kueche Fenster_Wohnzimmer_Ost Fenster_Terrasse
Bad wurde nicht geschalten und steht noch auf 21.5 Grad (hätte aber schon um 22 Uhr geschalten werden sollen
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEF HZ_Bad_WT_Climate 12345|06:00|22 1234|07:00|16 5|07:00|20 7|08:30|21.5 7|10:00|20 1234|12:00|20 1234|19:30|21.5 57|20:30|21.5 22:00|16 (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEVICE HZ_Bad_WT_Climate
GlobalDaylistSpec
LANGUAGE de
NAME HCB
NR 667
Profil 0: Sonntag 08:30:00 21.5, 10:00:00 20, 20:30:00 21.5, 22:00:00 16
Profil 1: Montag 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 2: Dienstag 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 3: Mittwoch 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 4: Donnerstag 06:00:00 22, 07:00:00 16, 12:00:00 20, 19:30:00 21.5, 22:00:00 16
Profil 5: Freitag 06:00:00 22, 07:00:00 20, 20:30:00 21.5, 22:00:00 16
Profil 6: Samstag 08:30:00 21.5, 10:00:00 20, 20:30:00 21.5, 22:00:00 16
Profil 7: Wochenende 08:30:00 21.5, 10:00:00 20, 20:30:00 21.5
STATE 21.5
STILLDONETIME
TYPE Heating_Control
Readings:
2015-10-18 14:07:49 disabled 0
2015-10-18 22:30:02 nextUpdate 2015-10-19 06:00:00
2015-10-18 22:30:02 nextValue 22
2015-10-18 22:30:02 state 21.5
SWITCHINGTIMES:
12345|06:00|22
1234|07:00|16
5|07:00|20
7|08:30|21.5
7|10:00|20
1234|12:00|20
1234|19:30|21.5
57|20:30|21.5
22:00|16
Timer:
Hcb_4:
HASH HCB
MODIFIER 4
NAME HCB_4
Hcb_settimerofday:
HASH HCB
MODIFIER SetTimerOfDay
NAME HCB_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
08:30:00 21.5
10:00:00 20
20:30:00 21.5
22:00:00 16
1:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
2:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
3:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
4:
06:00:00 22
07:00:00 16
12:00:00 20
19:30:00 21.5
22:00:00 16
5:
06:00:00 22
07:00:00 20
20:30:00 21.5
22:00:00 16
6:
08:30:00 21.5
10:00:00 20
20:30:00 21.5
22:00:00 16
7:
08:30:00 21.5
10:00:00 20
20:30:00 21.5
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1445140800
PARA 22
TIME 06:00
TAGE:
1
2
3
4
5
2:
EPOCH 1445144400
PARA 16
TIME 07:00
TAGE:
1
2
3
4
3:
EPOCH 1445144400
PARA 20
TIME 07:00
TAGE:
5
4:
EPOCH 1445149800
PARA 21.5
TIME 08:30
TAGE:
7
5:
EPOCH 1445155200
PARA 20
TIME 10:00
TAGE:
7
6:
EPOCH 1445162400
PARA 20
TIME 12:00
TAGE:
1
2
3
4
7:
EPOCH 1445189400
PARA 21.5
TIME 19:30
TAGE:
1
2
3
4
8:
EPOCH 1445193000
PARA 21.5
TIME 20:30
TAGE:
5
7
9:
EPOCH 1445198400
PARA 16
TIME 22:00
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Bad
group Heizplan
room Heizung
verbose 3
windowSensor Fenster_Bad
Dann habe ich gerade noch drei, die nicht geschalten wurde und der state noch auf dem falschen (hohen) Wert steht. Alle drei hätten um 20 Uhr auf 14 Grad geschalten werden.
Hier einer als Beispiel
Internals:
CONDITION (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEF FHT_Hobbyraum 1234|12:30|18 57|09:00|18 19:00|14 (ReadingsVal("HCAutomatik", "state", "off") eq "on")
DEVICE FHT_Hobbyraum
GlobalDaylistSpec
LANGUAGE de
NAME HCH
NR 675
Profil 0: Sonntag 09:00:00 18, 19:00:00 14
Profil 1: Montag 12:30:00 18, 19:00:00 14
Profil 2: Dienstag 12:30:00 18, 19:00:00 14
Profil 3: Mittwoch 12:30:00 18, 19:00:00 14
Profil 4: Donnerstag 12:30:00 18, 19:00:00 14
Profil 5: Freitag 09:00:00 18, 19:00:00 14
Profil 6: Samstag 09:00:00 18, 19:00:00 14
Profil 7: Wochenende 09:00:00 18
STATE 18
STILLDONETIME
TYPE Heating_Control
Readings:
2015-10-18 14:07:50 disabled 0
2015-10-18 22:30:01 nextUpdate 2015-10-19 12:30:00
2015-10-18 22:30:01 nextValue 18
2015-10-18 22:30:01 state 18
SWITCHINGTIMES:
1234|12:30|18
57|09:00|18
19:00|14
Timer:
Hch_2:
HASH HCH
MODIFIER 2
NAME HCH_2
Hch_settimerofday:
HASH HCH
MODIFIER SetTimerOfDay
NAME HCH_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
09:00:00 18
19:00:00 14
1:
12:30:00 18
19:00:00 14
2:
12:30:00 18
19:00:00 14
3:
12:30:00 18
19:00:00 14
4:
12:30:00 18
19:00:00 14
5:
09:00:00 18
19:00:00 14
6:
09:00:00 18
19:00:00 14
7:
09:00:00 18
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1445164200
PARA 18
TIME 12:30
TAGE:
1
2
3
4
2:
EPOCH 1445151600
PARA 18
TIME 09:00
TAGE:
5
7
3:
EPOCH 1445187600
PARA 14
TIME 19:00
TAGE:
0
1
2
3
4
5
6
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Hobbyraum
group Heizplan
room Heizung
verbose 3
windowSensor CUL_FHTTK_Hobbyraum_rechts CUL_FHTTK_Hobbyraum_links CUL_FHTTK_Hobbyraum_Ost
Hab gerade nochmal einen Test gemacht.
Bei dem Device HCWK sollte eigentlich jetzt state 14 sein, ist aber 18 (also die Tagestemperatur).
Wenn ich jetzt auf DEF und dann modify HCWK klicke, wird state ganz kurz 14, also richtig und schlatet dann wieder auf 18.
Habe das ganze dann nochmal mit verbose 5 gemacht (Log ist von unten nach oben zu lesen):
2015.10.18 23:02:32 2: FHT set FHT_Waschkeller desired-temp 18.0
2015.10.18 23:02:32 4: [HCWK] command: set FHT_Waschkeller desired-temp 18.0 executed
2015.10.18 23:02:32 4: [HCWK] aktParam:14.0 newParam:18.0 - is not disabled
2015.10.18 23:02:32 4: [HCWK] device type FHT: recognized, setModifier:desired-temp
2015.10.18 23:02:32 4: [HCWK] next: 2015-10-19 12:30:00(mo) -->> 18
2015.10.18 23:02:32 4: [HCWK] akt: 2015-10-18 19:00:00(so) -->> 14
2015.10.18 23:02:32 4: [HCWK] Update - timer seems to be active today: 57|09:00|18
2015.10.18 23:02:32 5: [HCWK] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.18 23:02:32 5: [HCWK] sensor 'CUL_FHTTK_Waschkeller' Reading/Attribute 'Window' is 'Closed'
2015.10.18 23:02:32 5: [HCWK] list of window sensors found: 'CUL_FHTTK_Waschkeller d_ECOMode HCWK'
2015.10.18 23:02:32 5: [HCWK] setting Timer: HCWK_2 2015-10-18 19:00:00
2015.10.18 23:02:32 5: [HCWK] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.18 23:02:32 5: [HCWK] sensor 'CUL_FHTTK_Waschkeller' Reading/Attribute 'Window' is 'Closed'
2015.10.18 23:02:32 5: [HCWK] list of window sensors found: 'CUL_FHTTK_Waschkeller d_ECOMode HCWK'
2015.10.18 23:02:32 4: [HCWK] next: 2015-10-19 12:30:00(mo) -->> 18
2015.10.18 23:02:32 4: [HCWK] akt: 2015-10-18 19:00:00(so) -->> 14
2015.10.18 23:02:32 4: [HCWK] Heating recognized - switch in the past activated
2015.10.18 23:02:32 4: [HCWK] device type FHT: recognized, setModifier:desired-temp
2015.10.18 23:02:31 5: [HCWK] setting Timer: HCWK_SetTimerOfDay 2015-10-19 00:00:05
2015.10.18 23:02:31 5: [HCWK] removing Timer: HCWK_SetTimerOfDay
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18 (Profil 7: Wochenende)
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18, 19:00:00 14 (Profil 6: Samstag)
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18, 19:00:00 14 (Profil 5: Freitag)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 4: Donnerstag)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 3: Mittwoch)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 2: Dienstag)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 1: Montag)
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18, 19:00:00 14 (Profil 0: Sonntag)
2015.10.18 23:02:31 4: [HCWK] 07:07:13 18:51:57 Sonntag
2015.10.18 23:02:31 3: [HCWK] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.10.18 23:02:31 3: [HCWK] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.10.18 23:02:31 5: [HCWK] removing Timer: HCWK_2
Ich kann mir das am Mittwoch mal ansehen. Habe hier nur ein paar Handy zur Verteidigung.
Das wäre super.
Vielen Dank schonmal!
Zitat von: Mitch am 18 Oktober 2015, 23:07:36
Hab gerade nochmal einen Test gemacht.
Bei dem Device HCWK sollte eigentlich jetzt state 14 sein, ist aber 18 (also die Tagestemperatur).
Wenn ich jetzt auf DEF und dann modify HCWK klicke, wird state ganz kurz 14, also richtig und schlatet dann wieder auf 18.
Habe das ganze dann nochmal mit verbose 5 gemacht (Log ist von unten nach oben zu lesen):
2015.10.18 23:02:32 2: FHT set FHT_Waschkeller desired-temp 18.0
2015.10.18 23:02:32 4: [HCWK] command: set FHT_Waschkeller desired-temp 18.0 executed
2015.10.18 23:02:32 4: [HCWK] aktParam:14.0 newParam:18.0 - is not disabled
2015.10.18 23:02:32 4: [HCWK] device type FHT: recognized, setModifier:desired-temp
2015.10.18 23:02:32 4: [HCWK] next: 2015-10-19 12:30:00(mo) -->> 18
2015.10.18 23:02:32 4: [HCWK] akt: 2015-10-18 19:00:00(so) -->> 14
2015.10.18 23:02:32 4: [HCWK] Update - timer seems to be active today: 57|09:00|18
2015.10.18 23:02:32 5: [HCWK] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.18 23:02:32 5: [HCWK] sensor 'CUL_FHTTK_Waschkeller' Reading/Attribute 'Window' is 'Closed'
2015.10.18 23:02:32 5: [HCWK] list of window sensors found: 'CUL_FHTTK_Waschkeller d_ECOMode HCWK'
2015.10.18 23:02:32 5: [HCWK] setting Timer: HCWK_2 2015-10-18 19:00:00
2015.10.18 23:02:32 5: [HCWK] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.18 23:02:32 5: [HCWK] sensor 'CUL_FHTTK_Waschkeller' Reading/Attribute 'Window' is 'Closed'
2015.10.18 23:02:32 5: [HCWK] list of window sensors found: 'CUL_FHTTK_Waschkeller d_ECOMode HCWK'
2015.10.18 23:02:32 4: [HCWK] next: 2015-10-19 12:30:00(mo) -->> 18
2015.10.18 23:02:32 4: [HCWK] akt: 2015-10-18 19:00:00(so) -->> 14
2015.10.18 23:02:32 4: [HCWK] Heating recognized - switch in the past activated
2015.10.18 23:02:32 4: [HCWK] device type FHT: recognized, setModifier:desired-temp
2015.10.18 23:02:31 5: [HCWK] setting Timer: HCWK_SetTimerOfDay 2015-10-19 00:00:05
2015.10.18 23:02:31 5: [HCWK] removing Timer: HCWK_SetTimerOfDay
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18 (Profil 7: Wochenende)
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18, 19:00:00 14 (Profil 6: Samstag)
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18, 19:00:00 14 (Profil 5: Freitag)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 4: Donnerstag)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 3: Mittwoch)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 2: Dienstag)
2015.10.18 23:02:31 4: [HCWK] 12:30:00 18, 19:00:00 14 (Profil 1: Montag)
2015.10.18 23:02:31 4: [HCWK] 09:00:00 18, 19:00:00 14 (Profil 0: Sonntag)
2015.10.18 23:02:31 4: [HCWK] 07:07:13 18:51:57 Sonntag
2015.10.18 23:02:31 3: [HCWK] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.10.18 23:02:31 3: [HCWK] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.10.18 23:02:31 5: [HCWK] removing Timer: HCWK_2
Ich benötige die Definition zu Waschkeller noch
Bitte sehr (aus der cfg):
define HCWK Heating_Control FHT_Waschkeller 1234|12:30|18 57|09:00|18 19:00|14 (ReadingsVal("HCAutomatik", "state", "off") eq "on")
attr HCWK alias Waschkeller
attr HCWK group Heizplan
attr HCWK room Heizung
attr HCWK verbose 3
attr HCWK windowSensor CUL_FHTTK_Waschkeller d_ECOMode
Hi,
hier der erste Test mit Verbose 4 und mehrern MAX-Thermostaten als Liste :
[HC.Test] invalid device, <HK_EILEEN,HK_TAMARA,HK_MARCEL> not found
2015.10.20 17:53:47 1: No Logdevice FileLog_HK_WOHNEN
2015.10.20 17:53:47 1: No Logdevice FileLog_HK_WOHNEN_E
2015.10.20 17:55:01 4: [HC.HK_Test] Update - timer seems to be active today: 0123456|17:55|21
2015.10.20 17:55:01 4: [HC.HK_Test] akt: 2015-10-20 17:55:00(di) -->> 21
2015.10.20 17:55:01 4: [HC.HK_Test] next: 2015-10-21 17:55:00(mi) -->> 21
2015.10.20 17:55:01 4: [HC.HK_Test] aktParam: newParam:21 - is not disabled
2015.10.20 17:55:01 4: [HC.HK_Test] command: set HK_EILEEN,HK_TAMARA,HK_MARCEL 21 executed
2015.10.20 17:55:01 3: Unknown argument 21, choose one of wakeUp factoryReset groupid associate:HK_KUECHE ...
Hier Test 2 mit HomeMatic und Wildcards
[HC_HK_Test2] invalid device, <HK_HM_WOHNEN_._Clima> not found
2015.10.20 19:30:00 4: [HC_HK_Test2] Update - timer seems to be active today: 12345|19:30|22
2015.10.20 19:30:00 4: [HC_HK_Test2] akt: 2015-10-20 19:30:00(di) -->> 22
2015.10.20 19:30:00 4: [HC_HK_Test2] next: 2015-10-21 19:30:00(mi) -->> 22
2015.10.20 19:30:00 4: [HC_HK_Test2] aktParam: newParam:22 - is not disabled
2015.10.20 19:30:00 4: [HC_HK_Test2] command: set HK_HM_WOHNEN_._Clima 22 executed
2015.10.20 19:30:00 3: Unknown argument 22, choose one of burstXmit clear:readings,t ...
Gruss
Zitat von: cotecmania am 20 Oktober 2015, 19:32:09
Hi,
hier der erste Test mit Verbose 4 und mehrern MAX-Thermostaten als Liste :
[HC.Test] invalid device, <HK_EILEEN,HK_TAMARA,HK_MARCEL> not found
2015.10.20 17:53:47 1: No Logdevice FileLog_HK_WOHNEN
2015.10.20 17:53:47 1: No Logdevice FileLog_HK_WOHNEN_E
2015.10.20 17:55:01 4: [HC.HK_Test] Update - timer seems to be active today: 0123456|17:55|21
2015.10.20 17:55:01 4: [HC.HK_Test] akt: 2015-10-20 17:55:00(di) -->> 21
2015.10.20 17:55:01 4: [HC.HK_Test] next: 2015-10-21 17:55:00(mi) -->> 21
2015.10.20 17:55:01 4: [HC.HK_Test] aktParam: newParam:21 - is not disabled
2015.10.20 17:55:01 4: [HC.HK_Test] command: set HK_EILEEN,HK_TAMARA,HK_MARCEL 21 executed
2015.10.20 17:55:01 3: Unknown argument 21, choose one of wakeUp factoryReset groupid associate:HK_KUECHE ...
Hier Test 2 mit HomeMatic und Wildcards
[HC_HK_Test2] invalid device, <HK_HM_WOHNEN_._Clima> not found
2015.10.20 19:30:00 4: [HC_HK_Test2] Update - timer seems to be active today: 12345|19:30|22
2015.10.20 19:30:00 4: [HC_HK_Test2] akt: 2015-10-20 19:30:00(di) -->> 22
2015.10.20 19:30:00 4: [HC_HK_Test2] next: 2015-10-21 19:30:00(mi) -->> 22
2015.10.20 19:30:00 4: [HC_HK_Test2] aktParam: newParam:22 - is not disabled
2015.10.20 19:30:00 4: [HC_HK_Test2] command: set HK_HM_WOHNEN_._Clima 22 executed
2015.10.20 19:30:00 3: Unknown argument 22, choose one of burstXmit clear:readings,t ...
Gruss
du musst mir deine Definition schicken.
Zitat von: Dietmar63 am 20 Oktober 2015, 19:59:32
du musst mir deine Definition schicken.
Meinst Du das ?
define HC.HK_Test Heating_Control HK_EILEEN,HK_TAMARA,HK_MARCEL Mo-So|17:55|21
attr HC.HK_Test verbose 4
define HC_HK_Test2 Heating_Control HK_HM_WOHNEN_._Clima Mo-Fr|19:30|22
attr HC_HK_Test2 verbose 4
Hie Dietmar,
kannst Du schon etwas zu meinen Problemen sagen?
Heute wurden wird ein paar nicht geschalten, weil der state inactive war.
Nein, ich war mehrere Tage nicht zu Hause.
Hast du Protokolle? So dass man erkennen kann warum bzw. Wie es dazu kommt, dass die HC auf inactive gehen?
Werden bei dir regelmäßig Heating_Control_SetAllTems() ausgeführt?
@ cotecmania
Die Lösung ist so:
define HC.HK_Test Heating_Control HK_EILEEN,HK_TAMARA,HK_MARCEL Mo-So|17:55|21 { fhem ("set @ desired-temp %") }
Hintergrund:
HC versucht anhand der Definition des devices herauszufinden, ob es sich um eine Heizung handeln könnte und mit welchem modifier (desired-temp, desired, desiredTemp) die Heizung verstellt werden muss. Wenn in der Angabe des devices ein regulärer Ausdruck angegeben ist, kann diese Logik nicht angewendet werden, so dass per Command {} der anzuwendende Befehl in Form von Perlcode mitgegeben werden muss.
Bei Dir:
{ fhem ("set @ desired-temp %") }
@ wird durch das device ersetzt
% wird durch den Parameter ersetzt.
Zitat von: Dietmar63 am 22 Oktober 2015, 18:01:15
Werden bei dir regelmäßig Heating_Control_SetAllTems() ausgeführt?
Ja, werde sie.
Ich nutze das, um bei Heimkehr wieder auf die Solltemp zu schalten.
Zitat von: Dietmar63 am 22 Oktober 2015, 18:41:18
@ cotecmania
Die Lösung ist so:
define HC.HK_Test Heating_Control HK_EILEEN,HK_TAMARA,HK_MARCEL Mo-So|17:55|21 { fhem ("set @ desired-temp %") }
Hintergrund:
HC versucht anhand der Definition des devices herauszufinden, ob es sich um eine Heizung handeln könnte und mit welchem modifier (desired-temp, desired, desiredTemp) die Heizung verstellt werden muss. Wenn in der Angabe des devices ein regulärer Ausdruck angegeben ist, kann diese Logik nicht angewendet werden, so dass per Command {} der anzuwendende Befehl in Form von Perlcode mitgegeben werden muss.
Bei Dir:
{ fhem ("set @ desired-temp %") }
@ wird durch das device ersetzt
% wird durch den Parameter ersetzt.
Hallo Dietmar,
wie muesste das dann bei folgender Definition umgesetzt werden, wenn hinten schon eine Bedingung ist ?:
HK_HM_WOHNEN_._Clima Mo-Fr|20:40|24 Mo-Fr|15:00|21 Mo-Fr|23:00|15 ( (Value("DS_Heizen") eq "on") && (Value("DS_HeizenUrlaubZuhause") eq "off") )Gruss
HK_HM_WOHNEN_._Clima Mo-Fr|20:40|24 Mo-Fr|15:00|21 Mo-Fr|23:00|15 { fhem ("set @ desired-temp %") if ( (Value("DS_Heizen") eq "on") && (Value("DS_HeizenUrlaubZuhause") eq "off") ) }
@Mitch:
ich habe einen Fehler gefunden - benötige aber noch Zeit bis ich weiß wie ich den löse.
leider wird sich die Reparatur verzögern.
Meine Fritzbox hat heute automatisch ein Update auf 6.30 ausgeführt, so dass mein FHEM nicht mehr läuft.
Jetzt muss ich mich erst einmal darum kümmern.
Danke Dietmar, und shit mit Deiner Box.
Fritzbox läuft wieder - kann mich aber trotzdem erst ab Sonntag Abend darum kümmern.
Ich habe jetzt eine Version von HC und WD, die das Problem nicht mehr hat.
Sie ist aber noch beta, und muss von mir getestet werden.
Hi Dietmar,
wenn Du noch einen Tester brauchst, sag mir bescheid.
Im Moment kann ich die aktuelle Version sowieso nicht nutzen, also könnte ich auch in einer echten Produktivumgebung testen.
Zitat von: Mitch am 26 Oktober 2015, 09:24:12
Hi Dietmar,
wenn Du noch einen Tester brauchst, sag mir bescheid.
Im Moment kann ich die aktuelle Version sowieso nicht nutzen, also könnte ich auch in einer echten Produktivumgebung testen.
ich könnte die die aktuelle Version per mail zukommen lassen. Wäre das ein Weg?
klar: bauer.markus @ gmail.com
Hi Dietmar,
ich benutze dein Moduk sehr ähnlich, wie Mitch.
Habe meine Heizung ja auch nach seiner Anleitung aufgebaut und habe nun das gleiche Problem, das bei Heating_Setalltemps() nicht alle korrekt geschaltet werden.
Wenn du möchtest, kann ich auch gerne mittesten, bin allerdings nicht so fit in Sachen FHEM, wie Mitch.
Email würde ich dir dann via PN schicken.
Viele Grüße
Tino
Zitat von: Ascos am 26 Oktober 2015, 19:02:44
Hi Dietmar,
ich benutze dein Moduk sehr ähnlich, wie Mitch.
Habe meine Heizung ja auch nach seiner Anleitung aufgebaut und habe nun das gleiche Problem, das bei Heating_Setalltemps() nicht alle korrekt geschaltet werden.
Wenn du möchtest, kann ich auch gerne mittesten, bin allerdings nicht so fit in Sachen FHEM, wie Mitch.
Email würde ich dir dann via PN schicken.
Viele Grüße
Tino
Sende mir deine Mail-Adresse, dann versorge ich dich mit dem Modul.
Weißt du, wie du es installieren kannst?
Dietmar
Hi Dietmar,
danke für Dein Mail.
Habe das Modul kopiert und neu geladen.
Danach ein {Heating_Control_SetAllTemps()} und alle HC's (bis auf einen, da ist das Fenster offen) sind auf inactive??
Log:
2015.10.26 20:35:42 5: [HCL] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:42 5: [HCL] sensor 'Fenster_Leoni' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:42 5: [HCL] list of window sensors found: 'Fenster_Leoni d_ECOMode HCL'
2015.10.26 20:35:42 5: [HCB] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:42 5: [HCB] sensor 'Fenster_Bad' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:42 5: [HCB] list of window sensors found: 'Fenster_Bad d_ECOMode HCB'
2015.10.26 20:35:41 5: [HCFU] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCFU] sensor 'd_Flur_unten.Fenster' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCFU] list of window sensors found: 'd_Flur_unten.Fenster d_ECOMode HCFU'
2015.10.26 20:35:41 5: [HCW] sensor 'Fenster_Terrasse' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] sensor 'Fenster_Wohnzimmer_Ost' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] sensor 'Fenster_Kueche' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] list of window sensors found: 'd_ECOMode Fenster_Kueche Fenster_Wohnzimmer_Ost Fenster_Terrasse HCW'
2015.10.26 20:35:41 5: [HCFO] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCFO] sensor 'Fenster_Flur_oben' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCFO] list of window sensors found: 'Fenster_Flur_oben d_ECOMode HCFO'
2015.10.26 20:35:41 5: [HCWK] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCWK] sensor 'CUL_FHTTK_Waschkeller' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:41 5: [HCWK] list of window sensors found: 'CUL_FHTTK_Waschkeller d_ECOMode HCWK'
2015.10.26 20:35:41 5: [HCH] sensor 'CUL_FHTTK_Hobbyraum_Ost' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:41 5: [HCH] sensor 'CUL_FHTTK_Hobbyraum_links' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:41 5: [HCH] sensor 'CUL_FHTTK_Hobbyraum_rechts' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:41 5: [HCH] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCH] list of window sensors found: 'd_ECOMode CUL_FHTTK_Hobbyraum_rechts CUL_FHTTK_Hobbyraum_links CUL_FHTTK_Hobbyraum_Ost HCH'
2015.10.26 20:35:41 5: [HCKF] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCKF] sensor 'CUL_FHTTK_Kellerflur' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:41 5: [HCKF] list of window sensors found: 'CUL_FHTTK_Kellerflur d_ECOMode HCKF'
2015.10.26 20:35:41 5: [HCD] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCD] list of window sensors found: 'd_ECOMode HCD'
2015.10.26 20:35:41 5: [HCO] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCO] sensor 'Fenster_Buero' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCO] list of window sensors found: 'Fenster_Buero d_ECOMode HCO'
2015.10.26 20:35:41 5: [HCS] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCS] sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCS] list of window sensors found: 'Fenster_Schlafzimmer d_ECOMode HCS'
2015.10.26 20:35:41 5: [HCKlo] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCKlo] sensor 'Fenster_Klo' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCKlo] list of window sensors found: 'Fenster_Klo d_ECOMode HCKlo'
2015.10.26 20:35:41 3: Heating_Control_SetAllTemps() done!
2015.10.26 20:35:41 3: Heating_Control_SetTimer() for HCWK done!
2015.10.26 20:35:41 5: [HCWK] setting Timer: HCWK_ 2015-10-26 19:00:00
2015.10.26 20:35:41 5: [HCWK] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCWK] sensor 'CUL_FHTTK_Waschkeller' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:41 5: [HCWK] list of window sensors found: 'CUL_FHTTK_Waschkeller d_ECOMode HCWK'
2015.10.26 20:35:41 4: [HCWK] Heating recognized - switch in the past activated
2015.10.26 20:35:41 4: [HCWK] device type FHT: recognized, setModifier:desired-temp
2015.10.26 20:35:41 5: [HCWK] removing Timer: HCWK_
2015.10.26 20:35:41 3: Heating_Control_SetTimer() for HCW done!
2015.10.26 20:35:41 5: [HCW] setting Timer: HCW_ 2015-10-26 19:00:00
2015.10.26 20:35:41 5: [HCW] sensor 'Fenster_Terrasse' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] sensor 'Fenster_Wohnzimmer_Ost' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] sensor 'Fenster_Kueche' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCW] list of window sensors found: 'd_ECOMode Fenster_Kueche Fenster_Wohnzimmer_Ost Fenster_Terrasse HCW'
2015.10.26 20:35:41 5: [HCW] setting Timer: HCW_7 2015-10-26 22:30:00
2015.10.26 20:35:41 4: [HCW] setTimer - timer seems to be active today: 0123456|22:30|16
2015.10.26 20:35:41 4: [HCW] Heating recognized - switch in the past activated
2015.10.26 20:35:41 4: [HCW] device type CUL_HM:HM-TC-IT-WM-W-EU recognized, setModifier:desired-temp
2015.10.26 20:35:41 5: [HCW] removing Timer: HCW_
2015.10.26 20:35:41 5: [HCW] removing Timer: HCW_7
2015.10.26 20:35:41 3: Heating_Control_SetTimer() for HCS done!
2015.10.26 20:35:41 5: [HCS] setting Timer: HCS_ 2015-10-26 18:00:00
2015.10.26 20:35:41 5: [HCS] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCS] sensor 'Fenster_Schlafzimmer' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCS] list of window sensors found: 'Fenster_Schlafzimmer d_ECOMode HCS'
2015.10.26 20:35:41 5: [HCS] setting Timer: HCS_2 2015-10-26 21:00:00
2015.10.26 20:35:41 4: [HCS] setTimer - timer seems to be active today: 0123456|21:00|16
2015.10.26 20:35:41 4: [HCS] Heating recognized - switch in the past activated
2015.10.26 20:35:41 4: [HCS] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:41 5: [HCS] removing Timer: HCS_2
2015.10.26 20:35:41 5: [HCS] removing Timer: HCS_
2015.10.26 20:35:41 3: Heating_Control_SetTimer() for HCO done!
2015.10.26 20:35:41 5: [HCO] setting Timer: HCO_ 2015-10-26 19:00:00
2015.10.26 20:35:41 5: [HCO] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCO] sensor 'Fenster_Buero' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCO] list of window sensors found: 'Fenster_Buero d_ECOMode HCO'
2015.10.26 20:35:41 4: [HCO] Heating recognized - switch in the past activated
2015.10.26 20:35:41 4: [HCO] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:41 5: [HCO] removing Timer: HCO_
2015.10.26 20:35:41 3: Heating_Control_SetTimer() for HCL done!
2015.10.26 20:35:41 5: [HCL] setting Timer: HCL_ 2015-10-26 20:30:00
2015.10.26 20:35:41 5: [HCL] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCL] sensor 'Fenster_Leoni' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:41 5: [HCL] list of window sensors found: 'Fenster_Leoni d_ECOMode HCL'
2015.10.26 20:35:40 4: [HCL] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCL] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCL] removing Timer: HCL_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCKlo done!
2015.10.26 20:35:40 5: [HCKlo] setting Timer: HCKlo_ 2015-10-26 12:00:00
2015.10.26 20:35:40 5: [HCKlo] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCKlo] sensor 'Fenster_Klo' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCKlo] list of window sensors found: 'Fenster_Klo d_ECOMode HCKlo'
2015.10.26 20:35:40 5: [HCKlo] setting Timer: HCKlo_5 2015-10-26 22:30:00
2015.10.26 20:35:40 4: [HCKlo] setTimer - timer seems to be active today: 0123456|22:30|16
2015.10.26 20:35:40 4: [HCKlo] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCKlo] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCKlo] removing Timer: HCKlo_5
2015.10.26 20:35:40 5: [HCKlo] removing Timer: HCKlo_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCKF done!
2015.10.26 20:35:40 5: [HCKF] setting Timer: HCKF_ 2015-10-26 19:00:00
2015.10.26 20:35:40 5: [HCKF] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCKF] sensor 'CUL_FHTTK_Kellerflur' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:40 5: [HCKF] list of window sensors found: 'CUL_FHTTK_Kellerflur d_ECOMode HCKF'
2015.10.26 20:35:40 4: [HCKF] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCKF] device type FHT: recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCKF] removing Timer: HCKF_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCH done!
2015.10.26 20:35:40 5: [HCH] setting Timer: HCH_ 2015-10-26 19:00:00
2015.10.26 20:35:40 5: [HCH] sensor 'CUL_FHTTK_Hobbyraum_Ost' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:40 5: [HCH] sensor 'CUL_FHTTK_Hobbyraum_links' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:40 5: [HCH] sensor 'CUL_FHTTK_Hobbyraum_rechts' Reading/Attribute 'Window' is 'Closed'
2015.10.26 20:35:40 5: [HCH] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCH] list of window sensors found: 'd_ECOMode CUL_FHTTK_Hobbyraum_rechts CUL_FHTTK_Hobbyraum_links CUL_FHTTK_Hobbyraum_Ost HCH'
2015.10.26 20:35:40 4: [HCH] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCH] device type FHT: recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCH] removing Timer: HCH_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCFU done!
2015.10.26 20:35:40 5: [HCFU] setting Timer: HCFU_ 2015-10-26 19:00:00
2015.10.26 20:35:40 5: [HCFU] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCFU] sensor 'd_Flur_unten.Fenster' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCFU] list of window sensors found: 'd_Flur_unten.Fenster d_ECOMode HCFU'
2015.10.26 20:35:40 4: [HCFU] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCFU] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCFU] removing Timer: HCFU_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCFO done!
2015.10.26 20:35:40 5: [HCFO] setting Timer: HCFO_ 2015-10-26 19:00:00
2015.10.26 20:35:40 5: [HCFO] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCFO] sensor 'Fenster_Flur_oben' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCFO] list of window sensors found: 'Fenster_Flur_oben d_ECOMode HCFO'
2015.10.26 20:35:40 4: [HCFO] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCFO] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCFO] removing Timer: HCFO_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCD done!
2015.10.26 20:35:40 5: [HCD] setting Timer: HCD_ 2015-10-26 19:00:00
2015.10.26 20:35:40 5: [HCD] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCD] list of window sensors found: 'd_ECOMode HCD'
2015.10.26 20:35:40 4: [HCD] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCD] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCD] removing Timer: HCD_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCC done!
2015.10.26 20:35:40 5: [HCC] setting Timer: HCC_ 2015-10-26 20:36:39
2015.10.26 20:35:40 5: [HCC] sensor 'Fenster_Carlotta' Reading/Attribute 'state' is 'open'
2015.10.26 20:35:40 5: [HCC] list of window sensors found: 'Fenster_Carlotta d_ECOMode HCC'
2015.10.26 20:35:40 4: [HCC] Heating recognized - switch in the past activated
2015.10.26 20:35:40 4: [HCC] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.10.26 20:35:40 5: [HCC] removing Timer: HCC_
2015.10.26 20:35:40 3: Heating_Control_SetTimer() for HCB done!
2015.10.26 20:35:40 5: [HCB] setting Timer: HCB_ 2015-10-26 19:30:00
2015.10.26 20:35:40 5: [HCB] sensor 'd_ECOMode' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCB] sensor 'Fenster_Bad' Reading/Attribute 'state' is 'closed'
2015.10.26 20:35:40 5: [HCB] list of window sensors found: 'Fenster_Bad d_ECOMode HCB'
2015.10.26 20:35:40 5: [HCB] setting Timer: HCB_9 2015-10-26 22:00:00
2015.10.26 20:35:40 4: [HCB] setTimer - timer seems to be active today: 0123456|22:00|16
2015.10.26 20:35:39 1: PERL WARNING: Use of uninitialized value $timToSwitch in subtraction (-) at ./FHEM/98_WeekdayTimer.pm line 497.
2015.10.26 20:35:39 4: [HCB] Heating recognized - switch in the past activated
2015.10.26 20:35:39 4: [HCB] device type CUL_HM:HM-TC-IT-WM-W-EU recognized, setModifier:desired-temp
2015.10.26 20:35:39 5: [HCB] removing Timer: HCB_9
2015.10.26 20:35:39 5: [HCB] removing Timer: HCB_
Habe jetzt jeder einzelne Definition neu geladen, jetzt stimmt der state.
Werde spätestens Morgen berichten, ob es jetzt geht.
Hallo Dietmar,
auch danke für deine Mail, nach einem reload des neuen Test Modul bekomme ich diese Meldungen im log:
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Initialize redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 36.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_InitHelper redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 55.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Set redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 66.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Get redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 85.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Undef redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 102.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Define redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 113.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Profile redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 177.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_SwitchingTime redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 244.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_daylistAsArray redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 280.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_EchteZeit redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 330.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_zeitErmitteln redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 362.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_gatherSwitchingTimes redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 373.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Language redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 396.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_GlobalDaylistSpec redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 417.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_SetTimerForMidnightUpdate redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 434.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_SetTimerOfDay redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 450.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_SetTimer redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 467.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_searchAktNext redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 534.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_DeleteTimer redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 578.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Update redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 583.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_isAnActiveTimer redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 640.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_isHeizung redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 654.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_FensterOffen redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 702.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Device_Schalten redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 788.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_tageAsHash redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 825.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Condition redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 834.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_TageAsCondition redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 846.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_Attr redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 863.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_SetParm redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 879.
2015.10.26 21:11:10 1: PERL WARNING: Subroutine WeekdayTimer_SetAllParms redefined at /opt/fhem/FHEM/98_WeekdayTimer.pm line 890.
Das ist normal, die Routinen wurden neu geladen, passt so.
Zitat von: Dietmar63 am 26 Oktober 2015, 19:55:37
Sende mir deine Mail-Adresse, dann versorge ich dich mit dem Modul.
Weißt du, wie du es installieren kannst?
Dietmar
Du hast Post.
Wie würde ich die einzelnen Definitionen "neu" laden, wenn es bei mir auch soweit wäre?
Das Laden der Definition(modify oder restart fhem) ist wichtig, weil dadurch intern zusätzliche Informationen erzeugt werden, die für HC_setAllTemps() wichtig sind.
Guten Morgen!
Nach neustart waren erst alle Active jetzt kurz nach einem Schalt vorgang gleich wieder inactive:
Internals:
DEF Heiz_Bad_Ankleide 04:00|21.0 07:00|18 60|06:05|20.0 60|07:00|18
DEVICE Heiz_Bad_Ankleide
GlobalDaylistSpec
LANGUAGE de
NAME T_BAD_ANKLEIDE
NR 135
Profil 0: Sonntag 04:00:00 21.0, 06:05:00 20.0, 07:00:00 18
Profil 1: Montag 04:00:00 21.0, 07:00:00 18
Profil 2: Dienstag 04:00:00 21.0, 07:00:00 18
Profil 3: Mittwoch 04:00:00 21.0, 07:00:00 18
Profil 4: Donnerstag 04:00:00 21.0, 07:00:00 18
Profil 5: Freitag 04:00:00 21.0, 07:00:00 18
Profil 6: Samstag 04:00:00 21.0, 06:05:00 20.0, 07:00:00 18
STATE inactive
TYPE Heating_Control
Readings:
2015-10-27 06:28:48 disabled 0
2015-10-27 07:00:00 nextUpdate 2015-10-28 04:00:00
2015-10-27 07:00:00 nextValue 21.0
2015-10-27 07:00:00 state inactive
SWITCHINGTIMES:
04:00|21.0
07:00|18
60|06:05|20.0
60|07:00|18
Timer:
T_bad_ankleide_1:
HASH T_BAD_ANKLEIDE
MODIFIER 1
NAME T_BAD_ANKLEIDE_1
T_bad_ankleide_2:
HASH T_BAD_ANKLEIDE
MODIFIER 2
NAME T_BAD_ANKLEIDE_2
T_bad_ankleide_4:
HASH T_BAD_ANKLEIDE
MODIFIER 4
NAME T_BAD_ANKLEIDE_4
T_bad_ankleide_settimerofday:
HASH T_BAD_ANKLEIDE
MODIFIER SetTimerOfDay
NAME T_BAD_ANKLEIDE_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
04:00:00 21.0
06:05:00 20.0
07:00:00 18
1:
04:00:00 21.0
07:00:00 18
2:
04:00:00 21.0
07:00:00 18
3:
04:00:00 21.0
07:00:00 18
4:
04:00:00 21.0
07:00:00 18
5:
04:00:00 21.0
07:00:00 18
6:
04:00:00 21.0
06:05:00 20.0
07:00:00 18
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1445914800
PARA 21.0
TIME 04:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1445925600
PARA 18
TIME 07:00
TAGE:
0
1
2
3
4
5
6
3:
EPOCH 1445922300
PARA 20.0
TIME 06:05
TAGE:
0
6
4:
EPOCH 1445925600
PARA 18
TIME 07:00
TAGE:
0
6
Profile_idx:
0:
04:00:00 1
06:05:00 3
07:00:00 4
1:
04:00:00 1
07:00:00 2
2:
04:00:00 1
07:00:00 2
3:
04:00:00 1
07:00:00 2
4:
04:00:00 1
07:00:00 2
5:
04:00:00 1
07:00:00 2
6:
04:00:00 1
06:05:00 3
07:00:00 4
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
room Heizung_Steuerung
hast du auch Protokolleinträge?
Bis jetzt läuft es ohne Probleme.
Es wurde richtig geschalten und keine Definition ist inactive.
Danke!
Zitat von: Dietmar63 am 27 Oktober 2015, 08:06:34
hast du auch Protokolleinträge?
Kann ich heute Abend hier posten, hatte gerade wieder 2 inactive!
Mfg Steffen
Zitat von: Steffen am 27 Oktober 2015, 13:18:53
Kann ich heute Abend hier posten, hatte gerade wieder 2 inactive!
Mfg Steffen
Hast du die neue Version des Moduls per Mail eingespielt?
Zitat von: Steffen am 27 Oktober 2015, 07:12:46
Guten Morgen!
Nach neustart waren erst alle Active jetzt kurz nach einem Schalt vorgang gleich wieder inactive:
Internals:
DEF Heiz_Bad_Ankleide 04:00|21.0 07:00|18 60|06:05|20.0 60|07:00|18
DEVICE Heiz_Bad_Ankleide
GlobalDaylistSpec
LANGUAGE de
NAME T_BAD_ANKLEIDE
NR 135
Profil 0: Sonntag 04:00:00 21.0, 06:05:00 20.0, 07:00:00 18
Profil 1: Montag 04:00:00 21.0, 07:00:00 18
Profil 2: Dienstag 04:00:00 21.0, 07:00:00 18
Profil 3: Mittwoch 04:00:00 21.0, 07:00:00 18
Profil 4: Donnerstag 04:00:00 21.0, 07:00:00 18
Profil 5: Freitag 04:00:00 21.0, 07:00:00 18
Profil 6: Samstag 04:00:00 21.0, 06:05:00 20.0, 07:00:00 18
STATE inactive
TYPE Heating_Control
Readings:
2015-10-27 06:28:48 disabled 0
2015-10-27 07:00:00 nextUpdate 2015-10-28 04:00:00
2015-10-27 07:00:00 nextValue 21.0
2015-10-27 07:00:00 state inactive
SWITCHINGTIMES:
04:00|21.0
07:00|18
60|06:05|20.0
60|07:00|18
Timer:
T_bad_ankleide_1:
HASH T_BAD_ANKLEIDE
MODIFIER 1
NAME T_BAD_ANKLEIDE_1
T_bad_ankleide_2:
HASH T_BAD_ANKLEIDE
MODIFIER 2
NAME T_BAD_ANKLEIDE_2
T_bad_ankleide_4:
HASH T_BAD_ANKLEIDE
MODIFIER 4
NAME T_BAD_ANKLEIDE_4
T_bad_ankleide_settimerofday:
HASH T_BAD_ANKLEIDE
MODIFIER SetTimerOfDay
NAME T_BAD_ANKLEIDE_SetTimerOfDay
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
04:00:00 21.0
06:05:00 20.0
07:00:00 18
1:
04:00:00 21.0
07:00:00 18
2:
04:00:00 21.0
07:00:00 18
3:
04:00:00 21.0
07:00:00 18
4:
04:00:00 21.0
07:00:00 18
5:
04:00:00 21.0
07:00:00 18
6:
04:00:00 21.0
06:05:00 20.0
07:00:00 18
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1445914800
PARA 21.0
TIME 04:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1445925600
PARA 18
TIME 07:00
TAGE:
0
1
2
3
4
5
6
3:
EPOCH 1445922300
PARA 20.0
TIME 06:05
TAGE:
0
6
4:
EPOCH 1445925600
PARA 18
TIME 07:00
TAGE:
0
6
Profile_idx:
0:
04:00:00 1
06:05:00 3
07:00:00 4
1:
04:00:00 1
07:00:00 2
2:
04:00:00 1
07:00:00 2
3:
04:00:00 1
07:00:00 2
4:
04:00:00 1
07:00:00 2
5:
04:00:00 1
07:00:00 2
6:
04:00:00 1
06:05:00 3
07:00:00 4
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
room Heizung_Steuerung
bei mir active - kein Problem
Save config ?
HeizungsKeller
Hifi
Kueche
Plots
Unsorted
Wohnzimmer
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
CFGFN
DEF Heiz_Bad_Ankleide 04:00|21.0 07:00|18 60|06:05|20.0 60|07:00|18
DEVICE Heiz_Bad_Ankleide
GlobalDaylistSpec
LANGUAGE de
NAME yy
NR 491
Profil 0: Sonntag 04:00:00 21.0, 06:05:00 20.0, 07:00:00 18
Profil 1: Montag 04:00:00 21.0, 07:00:00 18
Profil 2: Dienstag 04:00:00 21.0, 07:00:00 18
Profil 3: Mittwoch 04:00:00 21.0, 07:00:00 18
Profil 4: Donnerstag 04:00:00 21.0, 07:00:00 18
Profil 5: Freitag 04:00:00 21.0, 07:00:00 18
Profil 6: Samstag 04:00:00 21.0, 06:05:00 20.0, 07:00:00 18
STATE active
TYPE Heating_Control
Guten Morgen!
Also heute Morgen waren alle Active obwohl gestern Abend vor dem Schalt Timer zu heute früh noch 2 Inactive waren, vielleicht klappt es ja jetzt.
Ich habe heute morgen diese Fehler Meldung gefunden und kann die vielleicht was damit zu tun haben?
2015.10.28 05:46:30 1: PERL WARNING: Argument "13.538929M-bM-\0M-^N" isn't numeric in division (/) at /opt/fhem/FHEM/99_SUNRISE_EL.pm line 128.
2015.10.28 05:46:30 3: stacktrace:
2015.10.28 05:46:30 3: main::__ANON__ called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (128)
2015.10.28 05:46:30 3: main::_sr_alt called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (90)
2015.10.28 05:46:30 3: main::sr_alt called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (375)
2015.10.28 05:46:30 3: main::sunrise_abs called by /opt/fhem/FHEM/98_WeekdayTimer.pm (224)
2015.10.28 05:46:30 3: main::WeekdayTimer_Profile called by /opt/fhem/FHEM/98_WeekdayTimer.pm (169)
2015.10.28 05:46:30 3: main::WeekdayTimer_Define called by /opt/fhem/FHEM/98_Heating_Control.pm (74)
2015.10.28 05:46:30 3: main::Heating_Control_Define called by fhem.pl (3087)
2015.10.28 05:46:30 3: main::CallFn called by fhem.pl (1731)
2015.10.28 05:46:30 3: main::CommandModify called by fhem.pl (1053)
2015.10.28 05:46:30 3: main::AnalyzeCommand called by /opt/fhem/FHEM/01_FHEMWEB.pm (2100)
2015.10.28 05:46:30 3: main::FW_fC called by /opt/fhem/FHEM/01_FHEMWEB.pm (683)
2015.10.28 05:46:30 3: main::FW_answerCall called by /opt/fhem/FHEM/01_FHEMWEB.pm (438)
2015.10.28 05:46:30 3: main::FW_Read called by fhem.pl (3087)
2015.10.28 05:46:30 3: main::CallFn called by fhem.pl (652)
2015.10.28 05:46:30 1: PERL WARNING: Argument "13.538929M-bM-\0M-^N" isn't numeric in division (/) at /opt/fhem/FHEM/99_SUNRISE_EL.pm line 128.
2015.10.28 05:46:30 3: stacktrace:
2015.10.28 05:46:30 3: main::__ANON__ called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (128)
2015.10.28 05:46:30 3: main::_sr_alt called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (90)
2015.10.28 05:46:30 3: main::sr_alt called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (376)
2015.10.28 05:46:30 3: main::sunset_abs called by /opt/fhem/FHEM/98_WeekdayTimer.pm (224)
2015.10.28 05:46:30 3: main::WeekdayTimer_Profile called by /opt/fhem/FHEM/98_WeekdayTimer.pm (169)
2015.10.28 05:46:30 3: main::WeekdayTimer_Define called by /opt/fhem/FHEM/98_Heating_Control.pm (74)
2015.10.28 05:46:30 3: main::Heating_Control_Define called by fhem.pl (3087)
2015.10.28 05:46:30 3: main::CallFn called by fhem.pl (1731)
2015.10.28 05:46:30 3: main::CommandModify called by fhem.pl (1053)
2015.10.28 05:46:30 3: main::AnalyzeCommand called by /opt/fhem/FHEM/01_FHEMWEB.pm (2100)
2015.10.28 05:46:30 3: main::FW_fC called by /opt/fhem/FHEM/01_FHEMWEB.pm (683)
2015.10.28 05:46:30 3: main::FW_answerCall called by /opt/fhem/FHEM/01_FHEMWEB.pm (438)
2015.10.28 05:46:30 3: main::FW_Read called by fhem.pl (3087)
2015.10.28 05:46:30 3: main::CallFn called by fhem.pl (652)
danke nochmal für eure Hilfe und Geduld...
Mfg Steffen
@Steefen:
Ja. Damit hat es garantiert zu tun.
Hast du die zugehörigen Definitionen hier veröffentlicht?
So, lief erstmal alles ohne Probleme.
Heute Morgen wurde wie geplant Bad und WZ/Küche auf 22 Grad gestellt und um 7:30 alles auf 16 Grad. Passt.
Jetzt kam ich gerade ins Büro und schaue nach und siehe da, wieder einige inactive :'(
Leider nichts im Log, bin aber auch auf Level 3.
So, ohne das irgend jemand etwas getan hat, oder fhem etwas geschalten hat, sind jetzt alles bis auf zwei auf inactiv :'(
Gib mir mal die Definitionen der timer, die bei dir auf inactive gehen
@Mitch, Steffen:
active/inactive - Problematik:
Durch einen dummen Zufall habe ich soeben die Situation nachstellen können.
Versuche jetzt eine Lösung für dieses Problem zu finden.
Alles klar Dietmar, Danke.
Schalten tun sie korrekt.
Hallo!
Das konnte ich mit Verbose 5 rausfiltern ich weiss nicht ob das vielleicht auch noch weiter hilft?!
Beide waren genau um diese zeit Inactive!
2015.10.28 21:06:00 5: [WZ] list of window sensors found: 'WZ'
2015.10.28 21:06:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(0,6);;( 1 && (defined $days->{$wday}))}<
2015.10.28 21:06:00 5: Triggering WZ (3 changes)
2015.10.28 21:06:00 5: Notify loop for WZ nextUpdate: 2015-10-28 21:16:00
2015.10.28 21:06:00 5: statistics Statistik: Notify.261 Notification of 'WZ' received. Device not monitored.
2015.10.28 21:03:00 5: [Kinderzimmer] list of window sensors found: 'Kinderzimmer'
2015.10.28 21:03:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(0,6);;( 1 && (defined $days->{$wday}))}<
2015.10.28 21:03:00 5: Triggering Kinderzimmer (3 changes)
2015.10.28 21:03:00 5: Notify loop for Kinderzimmer nextUpdate: 2015-10-29 05:03:00
2015.10.28 21:03:00 5: statistics Statistik: Notify.261 Notification of 'Kinderzimmer' received. Device not monitored.
Mfg Steffen
Zitat von: Steffen am 28 Oktober 2015, 21:50:24
Hallo!
Das konnte ich mit Verbose 5 rausfiltern ich weiss nicht ob das vielleicht auch noch weiter hilft?!
Beide waren genau um diese zeit Inactive!
2015.10.28 21:06:00 5: [WZ] list of window sensors found: 'WZ'
2015.10.28 21:06:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(0,6);;( 1 && (defined $days->{$wday}))}<
2015.10.28 21:06:00 5: Triggering WZ (3 changes)
2015.10.28 21:06:00 5: Notify loop for WZ nextUpdate: 2015-10-28 21:16:00
2015.10.28 21:06:00 5: statistics Statistik: Notify.261 Notification of 'WZ' received. Device not monitored.
2015.10.28 21:03:00 5: [Kinderzimmer] list of window sensors found: 'Kinderzimmer'
2015.10.28 21:03:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(0,6);;( 1 && (defined $days->{$wday}))}<
2015.10.28 21:03:00 5: Triggering Kinderzimmer (3 changes)
2015.10.28 21:03:00 5: Notify loop for Kinderzimmer nextUpdate: 2015-10-29 05:03:00
2015.10.28 21:03:00 5: statistics Statistik: Notify.261 Notification of 'Kinderzimmer' received. Device not monitored.
Mfg Steffen
ich benötige von dir die Definition des HC zu diesem Fehler:
2015.10.28 05:46:30 1: PERL WARNING: Argument "13.538929M-bM-\0M-^N" isn't numeric in division (/) at /opt/fhem/FHEM/99_SUNRISE_EL.pm line 128.
2015.10.28 05:46:30 3: stacktrace:
2015.10.28 05:46:30 3: main::__ANON__ called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (128)
2015.10.28 05:46:30 3: main::_sr_alt called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (90)
2015.10.28 05:46:30 3: main::sr_alt called by /opt/fhem/FHEM/99_SUNRISE_EL.pm (376)
2015.10.28 05:46:30 3: main::sunset_abs called by /opt/fhem/FHEM/98_WeekdayTimer.pm (224)
es scheint mir, dass irgendwie sunset_abs() verwendet wird, und vielleicht mit falschen Parametern aufgerufen wird. Das könnte ich überprüfen, wenn du die Definiton liefern würdest.
neue Version eingecheckt -bitte mal prüfen.
active/inactive auch verbessert.
Guten Morgen,
also der Fehler war in der Global def. da hatte ich nochmal die Werte geändert und seit dem ist der Fehler weg von PERL WARNING: Argument "13.538929M-bM-\0M-^N" isn't numeric in division (/) at /opt/fhem/FHEM/99_SUNRISE_EL.pm line 128 !
Aber es bleibt trotzdem Inactive, ich werde mal gleich deine neue Version Testen!
Mfg Steffen
Glaub mir es wird viel besser werden
Zitat von: Dietmar63 am 29 Oktober 2015, 06:39:25
Glaub mir es wird viel besser werden
Ich glaube das ist es jetzt schon mit der neuesten Version...bis jetzt kein einziges Inactive und alles korrekt geschalten!
Mfg Steffen
Hi Dietmar, klasse Arbeit, tausend Dank!
Im Moment läuft alles top. Auch mein ECOscript geht endlich wieder (Temp wird bei Abwesenheit >2h um 2 Grad gesenkt und bei Rückkehr auf Soll gestellt).
nichts zu danken.
ich muss für eure Geduld danken!
Nicht wirklich, Du "opferst" hier Deine Freizeit für uns...deswegen vielen Dank ;D
Zitat von: Dietmar63 am 15 Oktober 2015, 20:48:13
nein,
hast du den Fehler einmal gehabt, nach einem Start, oder kommt er immer wieder?
kannst du die Versions-ID der Module
WeekdayTimer
Heating_Control
posten.
Hallo,
ich hatte die gleiche Warung:
nach dem Start von Fhem nach shutdown restart
# $Id: 98_WeekdayTimer.pm 9401 2015-10-07 21:22:54Z dietmar63 $
PERL WARNING: Use of uninitialized value $sollZeit in numeric le (<=) at ./FHEM/98_WeekdayTimer.pm line 602
Mit der neuen Version upd 98_WeekdayTimer.pm ist (bisher) die Warnung nach dem Neustart nicht mehr da.
Danke für das update !!
Jörg
Hallo,
mit dem Umstieg auf Featurelevel 5.7 in Commit 9893 geht WeekdayTimer kaputt, da es intern noch @ und % benutzt.
Habe das bei mir lokal so behoben:
Index: FHEM/98_WeekdayTimer.pm
===================================================================
--- FHEM/98_WeekdayTimer.pm (revision 9899)
+++ FHEM/98_WeekdayTimer.pm (working copy)
@@ -810,7 +810,7 @@
#modifier des Zieldevices auswaehlen
my $setModifier = WeekdayTimer_isHeizung($hash);
- $command = "set @ " . $setModifier . " %";
+ $command = "set \$NAME " . $setModifier . " \$EVENT";
$command = $hash->{COMMAND} if (defined $hash->{COMMAND});
my $activeTimer = 1;
Sollte am besten relativ Zeitnah auch im Repository behoben werden, bevor Rudi die 5.7 freigibt.
Viele Grüße
Michael
Hallo Dietmar,
habe heute Fensterkontakte zu Heating_Control hinzugefügt, bekomme aber folgende Fehlermeldung im Log:
2015.11.15 19:13:01 3: [HC_Schlaf] TYPE 'EnOcean' of FensterSchlaf not yet supported, FensterSchlaf ignored - inform maintainer
2015-11-15_15:14:33 FensterSchlaf open
2015-11-15_15:19:21 FensterSchlaf closed
Können die EnOcean Fensterkontakte auch unterstützt werden?
Gruß Thomas
ja, das lässt sich machen, bitte mal die Definition des Fenssterkontakts mit list schicken.
Internals:
CODE 64b840
CUL_0_MSGCNT 5736
CUL_0_RAWMSG T64B84082
CUL_0_RSSI -63
CUL_0_TIME 2015-11-15 21:32:57
DEF 64b840
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 5736
NAME Terrassentuer
NR 53
OPEN 0
PREVSTATE Closed
PREVTIMESTAMP 1447619320
STATE Closed
TYPE CUL_FHTTK
Prev:
STATE 02
TIMESTAMP 1447619577
Readings:
2015-11-15 21:32:57 Battery ok
2015-11-15 09:56:23 Previous Open
2015-11-15 21:32:57 Reliability ok
2015-11-15 21:32:57 Window Closed
2015-11-15 21:32:57 state Closed
Attributes:
IODev CUL_0
devStateIcon Closed:fts_window_1w@green Open:fts_window_1w_open@red
group Commands
room HeizungsKeller
Hallo Dietmar,
hier die Definition
Internals:
CHANGED
DEF xxxxxxxx
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 4
NAME FensterSchlaf
NR 90
NTFY_ORDER 50-FensterSchlaf
STATE open
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 4
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -76
TCM_ESP3_0_ReceivingQuality good
TCM_ESP3_0_RepeatingCounter 0
TCM_ESP3_0_SubTelNum 3
TCM_ESP3_0_TIME 2015-11-15 21:38:48
TYPE EnOcean
Readings:
2015-11-15 21:38:48 state open
Attributes:
IODev TCM_ESP3_0
devStateIcon open:fts_window_1w_open@red closed:fts_window_1w
event-on-change-reading *
icon fts_window_1w
manufID 7FF
room 04_Schlaf,EnOcean,Handbedienung
subType contact
Danke im Voraus
habe was eingebaut - gebe aber frühestens morgen frei, weil ich noch etwas mehr machen musste.
Bin eifrig den Threat am Mitlesen und konnte letzte Woche meine Hommatic Heizkörperthermostate und Fenster und Türen Kontakte in Betrieb nehmen.
Danach wollte ich mir mit diesem Modul eine entsprechende Heizsteuerung realisieren und habe gem. dem Threat und dem Wiki folgende Definition erstellt:
define Heizung_Schlafzimmer Heating_Control HM_Thermostat 12345|06:15|22 12345|06:30|19 67|09:00|22 67|09:30|19 18:00|21 22:00|19 (ReadingsVal("HCAutomatik", "state", "") eq "on")
attr Heizung_Schlafzimmer alias Schlafzimmer
attr Heizung_Schlafzimmer group Heizplan
attr Heizung_Schlafzimmer room Heizung
define HCAutomatik dummy
attr HCAutomatik alias Heizungsautomatik
attr HCAutomatik devStateIcon on:general_an off:general_aus
attr HCAutomatik group Automatik
attr HCAutomatik icon sani_heating_automatic
attr HCAutomatik room Heizung
attr HCAutomatik sortby 1
attr HCAutomatik webCmd on:off
Fensterkontakt in Verbindung mit Heating_Control:
define Fenster.Status.Schlafzimmer.Matthias DOIF ([Fensterkontakt2] eq "open") (set HCB disbale) DOELSE (set HCB enable)
hier mein Themrostat:
Internals:
DEF 3AFFE6
IODev hmusb
LASTInputDev hmusb
MSGCNT 87
NAME HM_Thermostat
NR 143
NTFY_ORDER 50-HM_Thermostat
STATE CMDs_done
STILLDONETIME 0
TYPE CUL_HM
channel_01 HM_Thermostat_Weather
channel_02 HM_Thermostat_Climate
channel_03 HM_Thermostat_WindowRec
channel_04 HM_Thermostat_Clima
channel_05 HM_Thermostat_ClimaTeam
channel_06 HM_Thermostat_remote
hmusb_MSGCNT 87
hmusb_RAWMSG E3AFFE6,0000,63BED036,FF,FFC5,8286103AFFE60000000AA0D40B0E40
hmusb_RSSI -59
hmusb_TIME 2015-11-16 20:37:51
lastMsg No:82 - t:10 s:3AFFE6 d:000000 0AA0D40B0E40
protLastRcv 2015-11-16 20:37:51
rssi_at_hmusb avg:-59.64 min:-64 max:-57 lst:-59 cnt:87
Readings:
2015-11-16 16:59:37 Activity alive
2015-11-14 13:19:48 CommandAccepted yes
2015-11-09 16:48:04 D-firmware 1.4
2015-11-09 16:48:04 D-serialNr MEQ0446891
2015-11-09 16:48:11 PairedTo 0x34F22A
2015-11-09 16:48:11 R-backOnTime 10 s
2015-11-09 16:48:11 R-burstRx on
2015-11-09 16:48:11 R-cyclicInfoMsg on
2015-11-09 16:48:11 R-cyclicInfoMsgDis 0
2015-11-09 16:48:11 R-pairCentral 0x34F22A
2015-11-09 16:48:11 RegL_00: 01:01 02:01 09:01 0A:34 0B:F2 0C:2A 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00 00:00
2015-11-09 20:32:42 RegL_07:
2015-11-16 20:37:51 actuator 14
2015-11-14 13:19:49 battery ok
2015-11-16 20:37:51 batteryLevel 2.6
2015-11-16 20:37:51 desired-temp 20.0
2015-11-16 20:37:51 measured-temp 21.2
2015-11-16 20:37:51 motorErr ok
2015-11-05 20:48:42 powerOn 2015-11-05 20:48:42
2015-11-05 20:48:42 recentStateType info
2015-11-16 08:06:02 state CMDs_done
2015-11-16 08:06:02 time-request -
Helper:
HM_CMDNR 130
mId 0095
rxType 140
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3AFFE6,00,00,00
nextSend 1447702671.45985
prefIO
rxt 2
vccu
p:
3AFFE6
00
00
00
Mrssi:
mNo 82
Io:
hmusb -57
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
At_hmusb:
avg -59.6436781609195
cnt 87
lst -59
max -57
min -64
Shregw:
07 04
Attributes:
IODev hmusb
actCycle 000:10
actStatus alive
alias Heizung Schlafzimmer
autoReadReg 4_reqStatus
expert 2_full
firmware 1.4
icon hc_wht_regler
model HM-CC-RT-DN
room Heizung
serialNr MEQ0446891
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
..und hier mein Fensterkontakt:
Internals:
DEF 3C8752
IODev hmusb
LASTInputDev hmusb
MSGCNT 10
NAME Fensterkontakt2
NR 153
NTFY_ORDER 50-Fensterkontakt2
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 10
hmusb_RAWMSG E3C8752,0000,639AFBD2,FF,FFC0,E0A6103C875234F22A06010000
hmusb_RSSI -64
hmusb_TIME 2015-11-16 19:58:43
lastMsg No:E0 - t:10 s:3C8752 d:34F22A 06010000
protLastRcv 2015-11-16 19:58:43
protResnd 1 last_at:2015-11-16 17:09:20
protSnd 11 last_at:2015-11-16 19:58:43
protState CMDs_done
rssi_at_hmusb avg:-62.4 min:-64 max:-62 lst:-64 cnt:10
Readings:
2015-11-16 19:59:37 Activity alive
2015-11-10 00:02:54 CommandAccepted no
2015-11-10 00:00:11 D-firmware 1.0
2015-11-10 00:00:11 D-serialNr MEQ0752267
2015-11-16 18:02:53 PairedTo 0x34F22A
2015-11-10 00:02:53 R-cyclicInfoMsg on
2015-11-16 18:02:54 R-eventDlyTime 0 s
2015-11-10 00:02:53 R-pairCentral 0x34F22A
2015-11-10 00:02:53 R-sabotageMsg on
2015-11-16 18:02:54 R-sign on
2015-11-16 18:02:53 RegL_00: 02:01 09:01 0A:34 0B:F2 0C:2A 10:01 14:06 00:00
2015-11-16 18:02:54 RegL_01: 08:01 20:9C 21:00 30:06 00:00
2015-11-10 00:00:12 aesCommToDev ok
2015-11-10 00:00:12 aesKeyNbr 00
2015-11-16 19:58:43 alive yes
2015-11-16 19:58:43 battery ok
2015-11-16 19:58:43 contact closed (to vccu)
2015-11-16 19:58:43 recentStateType info
2015-11-16 19:58:43 sabotageError off
2015-11-16 19:58:43 state closed
2015-11-09 23:57:12 trigDst_broadcast noConfig
2015-11-14 12:01:40 trigDst_vccu noConfig
2015-11-14 12:01:40 trigger_cnt 112
Helper:
HM_CMDNR 224
cSnd 0134F22A3C875201040000000001,0134F22A3C87520103
mId 00C7
peerIDsRaw ,00000000
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newCh 1
newChn +3C8752,00,00,00
nextSend 1447700323.30038
rxt 2
vccu vccu
p:
3C8752
00
00
00
prefIO:
hmusb
Mrssi:
mNo E0
Io:
hmusb -62
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO hmusb
flg A
ts 1447700323.22708
ack:
HASH(0x1804680)
E0800234F22A3C875200
Rssi:
At_hmusb:
avg -62.4
cnt 10
lst -64
max -62
min -64
Shadowreg:
Attributes:
IODev hmusb
IOgrp vccu:hmusb
actCycle 000:50
actStatus alive
alias Fensterkontakt Schlafzimmer
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
icon control_1
model HM-SEC-SCo
peerIDs 00000000,
room Homematic
serialNr MEQ0752267
subType threeStateSensor
..aber irgendwie schaltet meinem Homematic Heizkörperthermostat nicht; d. h. zu den entsprechenden Uhrzeiten erfolgt Temperatureinstellung bzw es wird auch in Verbindung des Fensterkontaktes kein "disable" Funktion ausgelöst.
Fensterkonakt und Thermostat lassen sich "manuell" über FHEM jedoch ansteuern bzw. ablesen.
Kann jemand anhand meiner Daten ersehen wo ich einen Fehler gemacht habe ?
Bin für Tipps dankbar :)
Hallo,
was ist HCB bzw. wo ist die Definition davon ? Was wird da enabled oder disabled ?
Wenn es "nur" darum geht, ein Wochenprogramm ablaufen zu lassen und auf Fenster open zu reagieren, dann kann man das mit peering (Thermostat mit Fenster) und die Temperaturen im Thermostat hinterlegen. Das Modul ist - so wie ich es verstehe - gemacht um eine Therme zu steuern.
Ich nutze z.B. HCS um die Therme abzuschalten wenn alle Thermostate fast zu sind.
Gruß Christoph
Zitat von: thi69 am 15 November 2015, 21:47:56
Hallo Dietmar,
hier die Definition
Internals:
CHANGED
DEF xxxxxxxx
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 4
NAME FensterSchlaf
NR 90
NTFY_ORDER 50-FensterSchlaf
STATE open
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 4
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -76
TCM_ESP3_0_ReceivingQuality good
TCM_ESP3_0_RepeatingCounter 0
TCM_ESP3_0_SubTelNum 3
TCM_ESP3_0_TIME 2015-11-15 21:38:48
TYPE EnOcean
Readings:
2015-11-15 21:38:48 state open
Attributes:
IODev TCM_ESP3_0
devStateIcon open:fts_window_1w_open@red closed:fts_window_1w
event-on-change-reading *
icon fts_window_1w
manufID 7FF
room 04_Schlaf,EnOcean,Handbedienung
subType contact
Danke im Voraus
ENOCEAN sollte funktionieren
HCB ist natürlich beim mir falsch. Das ist noch ein Restbestandteil aus dem original Code.
Ich habe diesen bei mir in FHEM ersetzt durch "Heizung_Schlafzimmer"
So wie ich das lese ist das Modul jedoch nicht nur für die Heizungsanlage sondern auch für das Steuern von Heizungsthermostaten möglich.
Was mich eben verwundert ist, dass das Modul überhaupt nicht mit meinem Homematic Heizungsthermostat läuft. Es senkt bzw. hebt die Temperatur nicht und bei "Fenster auf und zu" gibt es auch keine Veränderung.
Ich bin echt ratlos :-\
SetzeSetze bitte mal für dein HC verbose 5
ok mache ich heute Abend und bereichte dann, danke :)
Hallo,
na ja - die Temperatur steht bei HM nicht am Gerät sondern im Kanal Clima. Also müsstest Du die Temperaturen nicht an HM_Thermostat sondern an HM_Thermostat_Clima senden.
Wie schon gesagt - das macht für mich nicht wirklich Sinn. Das kann das Thermostat zusammen mit dem Fensterkontakt eigenständig abarbeiten. Dadurch wir Rechnen- und Funkzeit von fhem reduziert. Zudem läuft das dann auch, wenn fhem ausfällt.
Gruß Christoph
Hallo Dietmar,
eine Frage. Muss in Bezug auf die Anpassung für Version 5.7 von Dir noch etwas angepasst werden, oder ist dies in die gestrige Anpassung eingeflossen?
Danke für Deine super Arbeit und das tolle Modul.
Grüße
Ralph
Habe eben ein Update gemacht, aber das Heating_Control Modul war nicht dabei.
Dafür läuft das Wetter Modul 59_Weather nicht mehr. :(
Hallo thi69,
versuche mit attr global featurelevel 5.6 den Featurelevel umzustellen. Dann sollte es wieder funktionieren. So habe ich es in einem anderen Beitrag gelesen.
Grüße
Ralph
Hallo,
das wird aber nicht viel helfen. Morgen wird in fheminfo der featurelevel fix auf 5.7 gesetzt (laut Rudi). Die Lösung ist - suchen .. es gibt mittlerweile zig Meldungen wegen dem Wettermodul. Da muss ein Perl Modul nachinstalliert werden - zumindest um auch in der Zukunft auf der sicheren Seite zu sein.
Gruß Christoph
Edit: nach einem Hinweis vom ph1959de
ZitatChristoph, ich denke (und hoffe), das hast Du falsch verstanden. Der "release" wird fix auf 5.7 gesetzt. Der ursprüngliche / zwischenzeitliche (Patch-)Vorschlag von betateilchen, "release" auf einen eventuell eingestellten "featurelevel" zu setzen ist vermutlich der Grund für Deine Annahme.
Wenn mit jetzt noch jemand erklärt, wo der Unterschied liegt - Rudi sprach in einigen Mitteilungen auch von Featurelevel und nicht von Release.
Okay,
dass wusste ich nicht. Dachte das dies noch die Umgehungslösung ist. Wohl nur noch bis morgen.
Ich werde dann wohl noch bis zum Wochenende mit dem Update auf 5.7 warten. Unter der Woche habe ich leider nicht soviel Zeit um Probleme zu beheben. Da es nun kalt werden soll muss die Heizungssteuerung funktionieren. Sonst droht Ärger mit der Regierung :-)
Grüße
Ralph
Vielen Dank für die Info, nach der Nachinstallation des nötigen Modules auf dem RPi (Danke an JoWiemann im anderen Beitrag) läuft das Wetter wieder. :)
Zitat von: thi69 am 17 November 2015, 21:08:37
Habe eben ein Update gemacht, aber das Heating_Control Modul war nicht dabei.
Dafür läuft das Wetter Modul 59_Weather nicht mehr. :(
Aber WeekdayTimer war bestimmt dabei. Und HC ruft viel von WeekdayTimer auf
Hallo Dietmar,
dann gehts noch nicht, im Log steht immer noch:
2015.11.17 22:30:00 3: [HC_Schlaf] TYPE 'EnOcean' of FensterSchlaf not yet supported, FensterSchlaf ignored - inform maintainer
Bitte noch einmal probieren.
Ich hatte EnOcean nicht richtig geschrieben.
Zitat von: Bennemannc am 17 November 2015, 21:19:18
das wird aber nicht viel helfen. Morgen wird in fheminfo der featurelevel fix auf 5.7 gesetzt (laut Rudi).
Christoph, ich denke (und hoffe), das hast Du falsch verstanden. Der "release" wird fix auf 5.7 gesetzt. Der ursprüngliche / zwischenzeitliche (Patch-)Vorschlag von betateilchen, "release" auf einen eventuell eingestellten "featurelevel" zu setzen ist vermutlich der Grund für Deine Annahme.
Nachtrag: falls Du meinen Schlussfolgerungen zustimmst, wäre es vielleicht gut, Du änderst Deinen Beitrag, damit die falsche Information nicht die Runde macht.
Peter
Hallo Dietmar,
nein geht leider noch nicht. Ich war mal so frei in Dein Modul 98_WeekdayTimer.pm mit nano zu schauen.
Bin zwar nicht der Spezialist wie Du, aber müsste der EnOcean Fensterkontakt in dieser Liste auftauchen?
my %contacts = ( "CUL_FHTTK" => { "READING" => "Window", "STATUS" => "(Open)", "MODEL" => "r" },
"CUL_HM" => { "READING" => "state", "STATUS" => "(open|tilted)", "MODEL" => "r" },
"MAX" => { "READING" => "state", "STATUS" => "(open.*)", "MODEL" => "r" },
"WeekdayTimer" => { "READING" => "delayedExecution","STATUS" => "^1\$", "MODEL" => "a" },
"Heating_Control" => { "READING" => "delayedExecution","STATUS" => "^1\$", "MODEL" => "a" }
);
Gruß Thomas :D
Ja, korrekt
Dort habe ich ihn auch aufgenommen.
Ich schau nachher warum er nicht angekommen ist.
Hallo Dietmar,
das steht im Kopf vom Modul, das ich eben upgedatet habe.
# $Id: 98_WeekdayTimer.pm 9925 2015-11-17 23:15:20Z dietmar63 $
Hallo,
habe jetzt mal ein Tag mit Verbose 5 meine Berichte gesammelt. Das ist dabei rausgekommen (sagt mir als Laie leider nicht viel:/):
2015.11.17 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.17 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.17 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.17 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.17 18:00:00 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.17 18:00:00 4: [Heizung_Schlafzimmer] Update - timer seems to be active today: 0123456|18:00|21
2015.11.17 18:00:00 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.17 18:00:00 4: [Heizung_Schlafzimmer] aktParam:21.0 newParam:21.0 - is not disabled
2015.11.17 22:00:00 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.17 22:00:00 4: [Heizung_Schlafzimmer] Update - timer seems to be active today: 0123456|22:00|19
2015.11.17 22:00:00 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.17 22:00:00 4: [Heizung_Schlafzimmer] aktParam:21.0 newParam:19.0 - is not disabled
2015.11.17 22:00:00 4: [Heizung_Schlafzimmer] command: set @ desired-temp % executed
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_6
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_4
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_1
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_3
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_2
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_5
2015.11.18 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 00:00:05 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 07:06:37 17:14:54 Mittwoch
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 09:00:00 22, 09:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 0: Sonntag)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 06:15:00 22, 06:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 1: Montag)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 06:15:00 22, 06:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 2: Dienstag)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 06:15:00 22, 06:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 3: Mittwoch)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 06:15:00 22, 06:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 4: Donnerstag)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 06:15:00 22, 06:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 5: Freitag)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 09:00:00 22, 09:30:00 19, 18:00:00 21, 22:00:00 19 (Profil 6: Samstag)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] 09:00:00 22, 09:30:00 19 (Profil 7: Wochenende)
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] Heating recognized - switch in the past activated
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] setTimer - timer seems to be active today: 12345|06:15|22
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_1 2015-11-18 06:15:00
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] setTimer - timer seems to be active today: 12345|06:30|19
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_2 2015-11-18 06:30:00
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_3 2015-11-18 09:00:00
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_4 2015-11-18 09:30:00
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] setTimer - timer seems to be active today: 0123456|18:00|21
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_5 2015-11-18 18:00:00
2015.11.18 00:00:05 4: [Heizung_Schlafzimmer] setTimer - timer seems to be active today: 0123456|22:00|19
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_6 2015-11-18 22:00:00
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] removing Timer: Heizung_Schlafzimmer_SetTimerOfDay
2015.11.18 00:00:05 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_SetTimerOfDay 2015-11-19 00:00:05
2015.11.18 06:15:00 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.18 06:15:00 4: [Heizung_Schlafzimmer] Update - timer seems to be active today: 12345|06:15|22
2015.11.18 06:15:00 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.18 06:15:00 4: [Heizung_Schlafzimmer] aktParam:21.0 newParam:22.0 - is not disabled
2015.11.18 06:15:00 4: [Heizung_Schlafzimmer] command: set @ desired-temp % executed
2015.11.18 06:30:00 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.18 06:30:00 4: [Heizung_Schlafzimmer] Update - timer seems to be active today: 12345|06:30|19
2015.11.18 06:30:00 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.18 06:30:00 4: [Heizung_Schlafzimmer] aktParam:21.0 newParam:19.0 - is not disabled
2015.11.18 06:30:00 4: [Heizung_Schlafzimmer] command: set @ desired-temp % executed
2015.11.18 18:00:00 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.18 18:00:00 4: [Heizung_Schlafzimmer] Update - timer seems to be active today: 0123456|18:00|21
2015.11.18 18:00:00 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.18 18:00:00 4: [Heizung_Schlafzimmer] aktParam:21.0 newParam:21.0 - is not disabled
2015.11.18 19:49:42 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 19:49:42 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 19:49:42 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 19:49:42 3: [Heizung_Schlafzimmer] "7" in daylist now means $we(weekend) - see dokumentation!!!
2015.11.18 19:49:51 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.18 19:49:51 4: [Heizung_Schlafzimmer] Heating recognized - switch in the past activated
2015.11.18 19:49:51 4: [Heizung_Schlafzimmer] setTimer - timer seems to be active today: 0123456|22:00|19
2015.11.18 19:49:51 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_6 2015-11-18 22:00:00
2015.11.18 19:49:51 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.18 19:49:51 5: [Heizung_Schlafzimmer] setting Timer: Heizung_Schlafzimmer_5 2015-11-18 18:00:00
2015.11.18 19:49:51 5: [Heizung_Schlafzimmer] list of window sensors found: 'Heizung_Schlafzimmer'
2015.11.18 19:49:51 4: [Heizung_Schlafzimmer] Update - timer seems to be active today: 0123456|18:00|21
2015.11.18 19:49:51 4: [Heizung_Schlafzimmer] device type CUL_HM:HM-CC-RT-DN recognized, setModifier:desired-temp
2015.11.18 19:49:51 4: [Heizung_Schlafzimmer] aktParam:21.0 newParam:21.0 - is not disabled
Ich sehe, dass meine Wocheneinstellung im Homematic Thermostat auch aufgenommen worden sind, jedoch schlatet das Thermostat nicht danach; ebensowenig registriert es offene Fenster mittels meines Fenster/Tür Kontaktes. Liegt es vielleicht daran, dass ich das Thermostat noch auf Automatik stehen habe ? Muss ich das auf "Manuell" umstellen ? Konnte hierüber nichts im Wiki erlesen. Hier mal mein Logfile des HM_Thermostat_Clima meines Thermostates:
CommandAccepted
yes
2015-11-14 13:19:49
R-boostPos
80 %
2015-11-09 16:48:19
R-btnNoBckLight
off
2015-11-09 16:48:19
R-dayTemp
21 C
2015-11-09 16:48:19
R-daylightSaveTime
on
2015-11-09 16:48:19
R-modePrioManu
all
2015-11-09 16:48:19
R-modePrioParty
all
2015-11-09 16:48:19
R-nightTemp
17 C
2015-11-09 16:48:19
R-noMinMax4Manu
off
2015-11-09 16:48:19
R-regAdaptive
on
2015-11-09 16:48:19
R-showInfo
time
2015-11-09 16:48:19
R-sign
off
2015-11-09 16:48:15
R-tempOffset
0.0K
2015-11-09 16:48:19
R-valveOffsetRt
0 %
2015-11-09 16:48:19
R-winOpnBoost
off
2015-11-09 16:48:19
R_0_tempListSat
06:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_1_tempListSun
06:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_2_tempListMon
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_3_tempListTue
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_4_tempListWed
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_5_tempListThu
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_6_tempListFri
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2015-11-09 17:01:09
R_tempList_State
verified
2015-11-09 17:01:09
RegL_01:
08:00 00:00
2015-11-09 17:01:05
RegL_07:
01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2015-11-09 17:01:09
ValvePosition
24
2015-11-18 21:29:06
boostTime
-
2015-11-18 21:29:06
controlMode
auto
2015-11-18 21:29:06
desired-temp
21.0
2015-11-18 21:29:06
measured-temp
22.8
2015-11-18 21:29:06
partyEnd
-
2015-11-18 21:29:06
partyStart
-
2015-11-18 21:29:06
partyTemp
-
2015-11-18 21:29:06
recentStateType
ack
2015-11-14 13:19:49
state
T: 22.8 desired: 21.0 valve: 24
2015-11-18 21:29:06
Bin über eine Hilfestellung echt dankbar :D
Zitat...
dass ich das Thermostat noch auf Automatik stehen habe ? Muss ich das auf "Manuell" umstellen ? Konnte hierüber nichts im Wiki erlesen. Hier mal mein Logfile des HM_Thermostat_Clima meines Thermostates:
das kann sein bei meine FS20 Geräten ist das genau so.
Hm, auf Automatik stellen hat irgendwie auch nicht funktioniert.
Hat jemand von Euch ein Homematicthermostat im Einsatz und kann berichten wie er die Einstellungen vorgenommen hat damit es funktioniert ?
Hallo Dietmar,
die EnOcean Fensterkontakte funktionieren jetzt mit dem HC Modul.
Nochmal vielen Dank für Deine SUPER Leistung bei der Umsetzung der Module. :)
Gruß Thomas
Die ganze Zeit funktionierte der Aufruf für ein HeatingControl eines structure mit folgendem Befehl:
OG_Bad_T mo-fr|05:05|22 mo-fr|06:30|20 mo-fr|19:30|19.5 $we|08:00|21 $we|19:00|20 $we|21:00|19 { fhem("set @ desiredTemperature %") if ((ReadingsVal("KAT","state","")==0)&&(ReadingsVal("HC_Bad_Off_Profile","state","") eq "Auto"))}
OG_Bad_T = structure
Seit einem update vor 4 Tagen geht das nicht mehr. Ich hab schon gesucht, aber ich finde nichts wie ich den Aufruf ändern müsste.
@ und % sind als Variablen nicht mehr erlaubt. Ich habe das jeweils in den Befehlen so geändert:
@ zu $NAME
% zu $EVENT
Damit funktioniert das bei mir. Wurde aber auch für FHEM 5.7 angekündigt. So habe ich das vor dem Update zunächst geändert und getestet (funktioniert ja auch schon länger). Und dann erst habe ich das Update ohne Probleme laufen lassen.
BG
Dirk
Danke, so funktioniert es!
Hallo Dietmar,
ich habe seit einigen Tagen folgende Meldungen im log:
2015.11.22 23:35:30 3: Heating_Control_SetTimer() for HC_WZ_WT done!
2015.11.22 23:35:30 3: Heating_Control_SetTimer() for HC_WZ_WE done!
Scheinbar werden einige Thermostate auch nicht mehr gestellt.. nur z.B. 2 von 7
Meine cfg sieht so aus:
define HC_WZ_WE Heating_Control WZ_hzg de 08:05|20.0 21:05|16.0 {if ($we){&SET_FHT("$NAME","$EVENT")}}
attr HC_WZ_WE group Wochenende
attr HC_WZ_WE room HEIZUNG
attr HC_WZ_WE windowSensor Terrrassentuer_LINKS_ThreeStateSensor Terrrassentuer_RECHTS_ThreeStateSensor WZ_FENSTER_SUED_ThreeStateSensor WZ_FENSTER_WEST_ThreeStateSensor
define HC_WZ_WT Heating_Control WZ_hzg de 06:05|20.0 21:05|16.0 {if (!$we){&SET_FHT("$NAME","$EVENT")}}
attr HC_WZ_WT group Wochentag
attr HC_WZ_WT room HEIZUNG
attr HC_WZ_WT windowSensor Terrrassentuer_LINKS_ThreeStateSensor Terrrassentuer_RECHTS_ThreeStateSensor WZ_FENSTER_SUED_ThreeStateSensor WZ_FENSTER_WEST_ThreeStateSensor
in 99_myUtils.pm gibt es noch folgendes Unterprogramm...
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");
}
}
Kannst du dier hier einen Reim darauf machen?
Gruß
Manuel
Kannst du mal ein list des device erstellen und mir zusenden
habe folgedes definiert - heute ist ein Feiertag - kann keinen Fehler erkennen:
define HC_WZ_WE Heating_Control WZ_hzg de 08:05|20.0 21:05|16.0 {if ($we){&SET_FHT("$NAME","$EVENT")}} ;
attr HC_WZ_WE room HeizungsKeller ;
attr HC_WZ_WE verbose 5 ;
define HC_WZ_WT Heating_Control WZ_hzg de 06:05|20.0 21:05|16.0 {if (!$we){&SET_FHT("$NAME","$EVENT")}} ;
attr HC_WZ_WT room HeizungsKeller ;
attr HC_WZ_WT verbose 5 ;
015.11.23 21:05:00 4: [HC_WZ_WE] command: {if ($we){&SET_FHT("$NAME","$EVENT")}} executed
2015.11.23 21:05:00 4: [HC_WZ_WE] aktParam: newParam:16.0 - is not disabled
2015.11.23 21:05:00 4: [HC_WZ_WE] Update - timer seems to be active today: 0123456|21:05|16.0
2015.11.23 21:05:00 3: ret---condition--------->1
2015.11.23 21:05:00 5: [HC_WZ_WE] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:05:00 5: [HC_WZ_WE] list of window sensors found: 'HC_WZ_WE'
2015.11.23 21:05:00 3: set WZ_hzg desired-temp 16.0
2015.11.23 21:05:00 4: [HC_WZ_WT] command: {if (!$we){&SET_FHT("$NAME","$EVENT")}} executed
2015.11.23 21:05:00 4: [HC_WZ_WT] aktParam: newParam:16.0 - is not disabled
2015.11.23 21:05:00 4: [HC_WZ_WT] Update - timer seems to be active today: 0123456|21:05|16.0
2015.11.23 21:05:00 3: ret---condition--------->1
2015.11.23 21:05:00 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:05:00 5: [HC_WZ_WT] list of window sensors found: 'HC_WZ_WT'
2015.11.23 21:00:00 3: FS20 set MusikWlan on
2015.11.23 21:00:00 3: FS20 set Musik on
2015.11.23 21:00:00 3: [NAS] waking NAS with MAC 00:24:A5:A6:10:E0 IP 192.168.2.196
2015.11.23 21:00:00 3: Auto off for NAS at Next: 01:00:00
2015.11.23 21:00:00 3: [NAS] set NAS on
2015.11.23 20:26:04 5: [HC_WZ_WT] setting Timer: HC_WZ_WT_2 2015-11-23 21:05:00
2015.11.23 20:26:04 4: [HC_WZ_WT] setTimer - timer seems to be active today: 0123456|21:05|16.0
2015.11.23 20:26:04 3: ret---condition--------->1
2015.11.23 20:26:04 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 20:26:04 3: ret---condition--------->1
2015.11.23 20:26:04 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 20:26:04 4: [HC_WZ_WT] no switch in the yesterdays because of the devices type(WZ_hzg is not recognized as heating) - use attr switchInThePast
2015.11.23 20:26:04 5: [HC_WZ_WT] setting Timer: HC_WZ_WT_SetTimerOfDay 2015-11-24 00:00:05
2015.11.23 20:26:04 5: [HC_WZ_WT] removing Timer: HC_WZ_WT_SetTimerOfDay
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 6: Samstag)
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 5: Freitag)
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 4: Donnerstag)
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 3: Mittwoch)
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 2: Dienstag)
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 1: Montag)
2015.11.23 20:26:04 4: [HC_WZ_WT] 06:05:00 20.0, 21:05:00 16.0 (Profil 0: Sonntag)
2015.11.23 20:26:04 4: [HC_WZ_WT] 07:16:24 16:56:13 Montag
2015.11.23 20:26:04 3: [HC_WZ_WT] device <WZ_hzg> in fhem not defined, but accepted
2015.11.23 20:26:04 5: [HC_WZ_WT] removing Timer: HC_WZ_WT_2
jetzt so - heute kein Feiertag - glauge auch dass es korrekt läuft - gebe die Version frei, damit mit verbose 5 ein besseres Log erstellt werden kann:
define HC_WZ_WE Heating_Control WZ_hzg de 21:28|20.0 21:29|16.0 {if ($we){&SET_FHT("$NAME","$EVENT")}} ;
attr HC_WZ_WE room HeizungsKeller ;
attr HC_WZ_WE verbose 5 ;
define HC_WZ_WT Heating_Control WZ_hzg de 21:28|20.0 21:29|16.0 {if (!$we){&SET_FHT("$NAME","$EVENT")}} ;
attr HC_WZ_WT room HeizungsKeller ;
attr HC_WZ_WT verbose 5 ;
2015.11.23 21:29:00 3: set WZ_hzg desired-temp 16.0
2015.11.23 21:29:00 4: [HC_WZ_WT] command: {if (!$we){&SET_FHT("$NAME","$EVENT")}} executed
2015.11.23 21:29:00 4: [HC_WZ_WT] aktParam: newParam:16.0 - is not disabled
2015.11.23 21:29:00 4: [HC_WZ_WT] Update - timer seems to be active today: 0123456|21:29|16.0
2015.11.23 21:29:00 3: ret---condition--------->1
2015.11.23 21:29:00 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:29:00 5: [HC_WZ_WT] list of window sensors found: 'HC_WZ_WT'
2015.11.23 21:29:00 4: [HC_WZ_WE] command: {if ($we){&SET_FHT("$NAME","$EVENT")}} executed
2015.11.23 21:29:00 4: [HC_WZ_WE] aktParam: newParam:16.0 - is not disabled
2015.11.23 21:29:00 4: [HC_WZ_WE] Update - timer seems to be active today: 0123456|21:29|16.0
2015.11.23 21:29:00 3: ret---condition--------->1
2015.11.23 21:29:00 5: [HC_WZ_WE] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:29:00 5: [HC_WZ_WE] list of window sensors found: 'HC_WZ_WE'
2015.11.23 21:28:00 3: set WZ_hzg desired-temp 20.0
2015.11.23 21:28:00 4: [HC_WZ_WT] command: {if (!$we){&SET_FHT("$NAME","$EVENT")}} executed
2015.11.23 21:28:00 4: [HC_WZ_WT] aktParam: newParam:20.0 - is not disabled
2015.11.23 21:28:00 4: [HC_WZ_WT] Update - timer seems to be active today: 0123456|21:28|20.0
2015.11.23 21:28:00 3: ret---condition--------->1
2015.11.23 21:28:00 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:28:00 5: [HC_WZ_WT] list of window sensors found: 'HC_WZ_WT'
2015.11.23 21:28:00 4: [HC_WZ_WE] command: {if ($we){&SET_FHT("$NAME","$EVENT")}} executed
2015.11.23 21:28:00 4: [HC_WZ_WE] aktParam: newParam:20.0 - is not disabled
2015.11.23 21:28:00 4: [HC_WZ_WE] Update - timer seems to be active today: 0123456|21:28|20.0
2015.11.23 21:28:00 3: ret---condition--------->1
2015.11.23 21:28:00 5: [HC_WZ_WE] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:28:00 5: [HC_WZ_WE] list of window sensors found: 'HC_WZ_WE'
2015.11.23 21:27:49 5: [HC_WZ_WT] setting Timer: HC_WZ_WT_2 2015-11-23 21:29:00
2015.11.23 21:27:49 4: [HC_WZ_WT] setTimer - timer seems to be active today: 0123456|21:29|16.0
2015.11.23 21:27:49 3: ret---condition--------->1
2015.11.23 21:27:49 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:27:49 5: [HC_WZ_WT] setting Timer: HC_WZ_WT_1 2015-11-23 21:28:00
2015.11.23 21:27:49 4: [HC_WZ_WT] setTimer - timer seems to be active today: 0123456|21:28|20.0
2015.11.23 21:27:49 3: ret---condition--------->1
2015.11.23 21:27:49 5: [HC_WZ_WT] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:27:49 4: [HC_WZ_WT] no switch in the yesterdays because of the devices type(WZ_hzg is not recognized as heating) - use attr switchInThePast
2015.11.23 21:27:49 5: [HC_WZ_WT] setting Timer: HC_WZ_WT_SetTimerOfDay 2015-11-24 00:00:05
2015.11.23 21:27:49 5: [HC_WZ_WT] removing Timer: HC_WZ_WT_SetTimerOfDay
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 6: Samstag)
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 5: Freitag)
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 4: Donnerstag)
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 3: Mittwoch)
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 2: Dienstag)
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 1: Montag)
2015.11.23 21:27:49 4: [HC_WZ_WT] 21:28:00 20.0, 21:29:00 16.0 (Profil 0: Sonntag)
2015.11.23 21:27:49 4: [HC_WZ_WT] 07:16:24 16:56:13 Montag
2015.11.23 21:27:49 3: [HC_WZ_WT] device <WZ_hzg> in fhem not defined, but accepted
2015.11.23 21:27:49 5: [HC_WZ_WT] removing Timer: HC_WZ_WT_2
2015.11.23 21:27:15 5: [HC_WZ_WE] setting Timer: HC_WZ_WE_2 2015-11-23 21:29:00
2015.11.23 21:27:15 4: [HC_WZ_WE] setTimer - timer seems to be active today: 0123456|21:29|16.0
2015.11.23 21:27:15 3: ret---condition--------->1
2015.11.23 21:27:15 5: [HC_WZ_WE] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:27:15 5: [HC_WZ_WE] setting Timer: HC_WZ_WE_1 2015-11-23 21:28:00
2015.11.23 21:27:15 4: [HC_WZ_WE] setTimer - timer seems to be active today: 0123456|21:28|20.0
2015.11.23 21:27:15 3: ret---condition--------->1
2015.11.23 21:27:15 5: [HC_WZ_WE] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( 1 && (defined $days->{$wday}))}
2015.11.23 21:27:15 4: [HC_WZ_WE] no switch in the yesterdays because of the devices type(WZ_hzg is not recognized as heating) - use attr switchInThePast
2015.11.23 21:27:15 5: [HC_WZ_WE] setting Timer: HC_WZ_WE_SetTimerOfDay 2015-11-24 00:00:05
2015.11.23 21:27:15 5: [HC_WZ_WE] removing Timer: HC_WZ_WE_SetTimerOfDay
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 6: Samstag)
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 5: Freitag)
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 4: Donnerstag)
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 3: Mittwoch)
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 2: Dienstag)
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 1: Montag)
2015.11.23 21:27:15 4: [HC_WZ_WE] 21:28:00 20.0, 21:29:00 16.0 (Profil 0: Sonntag)
2015.11.23 21:27:15 4: [HC_WZ_WE] 07:16:24 16:56:13 Montag
2015.11.23 21:27:15 3: [HC_WZ_WE] device <WZ_hzg> in fhem not defined, but accepted
2015.11.23 21:27:15 5: [HC_WZ_WE] removing Timer: HC_WZ_WE_2
Hallo Dietmar,
danke für die Tests - vielleicht helfen folgende Daten:
Ich habe 8 Räume mit HC gesteuert - 7 davon sind FHT's - 1 Raum (WZ) ist Homematic.
Ich habe 3 Räume auf Verbose5 gesetzt und den Output bei Wechsel des HOME_Status in zwei txt Files gespeichert.
(Über ein notify werden bei Änderungen von HOME_Status das SUB Heating_Control_SetAllTemps() aufgerufen)
Wenn ich das alles richtig interpretiere wird jeweils nur ein Raum korrekt angesteuert.
Welcher dies ist ist zufällig unabhänig ob FHT oder Homematic...
Du hattest noch ein List benötigt...
Diese sind auch im Anhang.
Gruß Manuel
Zitat von: Petrosilius Zwackelmann am 23 November 2015, 23:43:45
Hallo Dietmar,
danke für die Tests - vielleicht helfen folgende Daten:
Ich habe 8 Räume mit HC gesteuert - 7 davon sind FHT's - 1 Raum (WZ) ist Homematic.
Ich habe 3 Räume auf Verbose5 gesetzt und den Output bei Wechsel des HOME_Status in zwei txt Files gespeichert.
(Über ein notify werden bei Änderungen von HOME_Status das SUB Heating_Control_SetAllTemps() aufgerufen)
Wenn ich das alles richtig interpretiere wird jeweils nur ein Raum korrekt angesteuert.
Welcher dies ist ist zufällig unabhänig ob FHT oder Homematic...
Du hattest noch ein List benötigt...
Diese sind auch im Anhang.
Gruß Manuel
Ich habe das Logging verbessert - kannst du damit Logs erstellen. Am besten von konkreten nicht Schalten Situationen.
Hallo Dietmar, im trunk sehe ich nur ein Update bei 98_WeekdayTimer.pm...Kommt das dann noch für 98_Heating_Control.pm?
HC nutzt fast sämtliche Funktionen von WD
Hallo Dietmar,
im Anhang nochmals ein Wechsel des HOME_Status .... nur eine Heizung wir hochgestellt.
Verwendet wurden Weekday Timer und Heating Control in der letzten Version.
Das normale Wochenprogramm funktioniert.
Siehst du einen Fehler?
Gruß Manuel
Welcher HD/WD ist denn falsch, deiner Meinung nach?
Ich habe 2 Sekunden dein Protokoll angesehen und keinen Fehler festgestellt.
Hallo Dietmar,
es wird nur klar wenn man beide Files (Aktionen bei HOME_Status = 0 (Erwartung alle Heizungen werden auf 17°C gestellt.)
HOME_Status = 1 --> Heizung wird auf das normale Wochenprogramm gestellt.
In folgendem File sieht man nur eine Heizung (Homematic) wird auf 17°C gestellt...
2015.11.25 00:18:32 3: CUL_HM set WZ_hzg desired-temp 17
Gruß Manuel
Hallo Dietmar,
ich hatte ja vor ein paar Wochen schon geschrieben, dass mit mehreren HeatingControl je Thermostat es nicht funktioniert, wenn man setallTemps() verwendet. Jetzt habe ich alternativ dazu in der 99_myUtils die ganze Logik nachprogrammiert, so dass immer nur ein HeatingControl aufgerufen wird also z.B. Heating_Control_SetTemp("HC_Bad_Normal").
Das funktioniert bei allen Räumen, außer bei meinem Bad, weil es dort nicht ein einziges Thermostat ist, sondern ein structure mit 3 Thermostaten. Im normalen Ablauf ist der Aufruf mit dem structure (OG_Bad_T ist der Name mit den Thermostaten OG_Bad_Badew_T, OG_Bad_Klo_T, OG_Bad_Waschb_T) absolut kein Problem, aber beim SetTemp reagieren die Thermostate nicht, obwohl im Log steht, dass alles ausgeführt wurde:
2015.12.06 15:31:29 5: Cmd: >{ ResetHeatingControl }<
2015.12.06 15:31:29 1: HC_Bad_Off_Profile Auto
2015.12.06 15:31:29 5: [HC_Bad_Normal] removing Timer: HC_Bad_Normal_6
2015.12.06 15:31:29 5: [HC_Bad_Normal] removing Timer: HC_Bad_Normal_4
2015.12.06 15:31:29 5: [HC_Bad_Normal] removing Timer: HC_Bad_Normal_3
2015.12.06 15:31:29 5: [HC_Bad_Normal] removing Timer: HC_Bad_Normal_7
2015.12.06 15:31:29 4: [HC_Bad_Normal] device type structure: recognized, setModifier:
2015.12.06 15:31:29 4: [HC_Bad_Normal] no switch in the yesterdays because of the devices type(OG_Bad_T is not recognized as heating) - use attr switchInThePast
2015.12.06 15:31:29 5: Triggering HC_Bad_Normal (1 changes)
2015.12.06 15:31:29 5: Notify loop for HC_Bad_Normal inactive
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: battStatus: not on any display, ignoring notify
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}(1,2,3,4,5);;;;( 1 && (defined $days->{$wday}))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}(1,2,3,4,5);;( 1 && (defined $days->{$wday}))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}(1,2,3,4,5);;;;( 1 && (defined $days->{$wday}))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}(1,2,3,4,5);;( 1 && (defined $days->{$wday}))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}(1,2,3,4,5);;;;( 1 && (defined $days->{$wday}))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}(1,2,3,4,5);;( 1 && (defined $days->{$wday}))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:
2015.12.06 15:31:29 4: [HC_Bad_Normal] setTimer - timer seems to be NOT active today: 12345|19:30|20
2015.12.06 15:31:29 5: [HC_Bad_Normal] setting Timer: HC_Bad_Normal_3 2015-12-06 19:30:00
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}(1,2,3,4,5);;;;( 1 && (defined $days->{$wday}))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}(1,2,3,4,5);;( 1 && (defined $days->{$wday}))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:
2015.12.06 15:31:29 4: [HC_Bad_Normal] setTimer - timer seems to be NOT active today: 12345|21:30|19.5
2015.12.06 15:31:29 5: [HC_Bad_Normal] setting Timer: HC_Bad_Normal_4 2015-12-06 21:30:00
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}();;( 1 && (defined $days->{$wday} || $we))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:1
2015.12.06 15:31:29 5: Triggering HC_Bad_Normal (1 changes)
2015.12.06 15:31:29 5: Notify loop for HC_Bad_Normal active
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: battStatus: not on any display, ignoring notify
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}();;( 1 && (defined $days->{$wday} || $we))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:1
2015.12.06 15:31:29 5: Triggering HC_Bad_Normal (1 changes)
2015.12.06 15:31:29 5: Notify loop for HC_Bad_Normal active
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: battStatus: not on any display, ignoring notify
2015.12.06 15:31:29 4: [HC_Bad_Normal] setTimer - timer seems to be active today: 7|19:00|20
2015.12.06 15:31:29 5: [HC_Bad_Normal] setting Timer: HC_Bad_Normal_6 2015-12-06 19:00:00
2015.12.06 15:31:29 5: [HC_Bad_Normal] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2015.12.06 15:31:29 5: Cmd: >{my $days={};map{$days->{$_}=1}();;( 1 && (defined $days->{$wday} || $we))}<
2015.12.06 15:31:29 5: [HC_Bad_Normal] result of condition:1
2015.12.06 15:31:29 5: Triggering HC_Bad_Normal (1 changes)
2015.12.06 15:31:29 5: Notify loop for HC_Bad_Normal active
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: battStatus: not on any display, ignoring notify
2015.12.06 15:31:29 4: [HC_Bad_Normal] setTimer - timer seems to be active today: 7|22:00|19.5
2015.12.06 15:31:29 5: [HC_Bad_Normal] setting Timer: HC_Bad_Normal_7 2015-12-06 22:00:00
2015.12.06 15:31:29 5: Triggering HC_Bad_Normal (1 changes)
2015.12.06 15:31:29 5: Notify loop for HC_Bad_Normal nextUpdate: 2015-12-06 19:00:00
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: battStatus: not on any display, ignoring notify
2015.12.06 15:31:29 5: Triggering HC_Bad_Normal (1 changes)
2015.12.06 15:31:29 5: Notify loop for HC_Bad_Normal nextValue: 20
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:29 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:30 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:30 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:30 5: Notify from Device: HC_Bad_Normal recieved
2015.12.06 15:31:30 5: battStatus: not on any display, ignoring notify
2015.12.06 15:31:30 3: Heating_Control_SetTimer() for HC_Bad_Normal done!
Kann ich da was tun, damit das auch funktioniert?
Gruß persching
Ohne die zugehörige DefinitionDefinition kann ich nix machen.
Welchen Typ haben die Thermostate in der strukture?
Definition des HeatingContol:
define HC_Bad_Normal Heating_Control OG_Bad_T mo-fr|05:05|22 mo-fr|06:30|20 mo-fr|19:30|20 mo-fr|21:30|19.5 $we|08:00|21 $we|19:00|20 $we|22:00|19.5 { fhem("set $NAME desiredTemperature $EVENT") if ((ReadingsVal("KAT","state","")==0)&&(ReadingsVal("HC_Bad_Off_Profile","state","") eq "Auto"))}
attr HC_Bad_Normal group Profile
attr HC_Bad_Normal room R02 Badezimmer
attr HC_Bad_Normal windowSensor OG_Bad_Fensterkontakt
Definition des structure:
define OG_Bad_T structure MAX OG_Bad_Klo_T OG_Bad_Waschb_T OG_Bad_Badew_T
attr OG_Bad_T room R02 Badezimmer
Alle Thermostate sind vom Typ MAX.
HC kann in structures nicht "hineinsehen", erkennt also nicht, dass es sich um Heizungen handelt.
Heizungen sollen aber immer auch den vergangenen Zustand schalten.
Dies kannst du mit dem Attribut switchInThePast erreichen.
Super, funktioniert perfekt! Danke für die schnelle Hilfe!
Hallo,
ich setze das Modul nun auch bereits seit einigen Tagen ein und es funktioniert soweit. Einziges Problem ist, dass ich die Verzögerungsfunktion nicht wirklich zum Laufen bekomme... :-\
So habe ich im jeweiligen HC folgendes definiert:
define hc.eg.wz.WE Heating_Control dm.eg.wz.Heizwert de Mo-So|10:00|20 Mo-So|18:00|22 Mo-So|20:00|17 {\
if ((iswe() && (Value("dmHeizmodus") eq "Automatisch"))) {\
fhem("set $NAME $EVENT");;\
}\
}
attr hc.eg.wz.WE delayedExecutionCond isDelayed("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
attr hc.eg.wz.WE switchInThePast 1
Die Funktion "isDelayed" habe ich mal probehalber aus der Doku entnommen und ein wenig ergänzt:
sub isDelayed($$$$$) {
my($hc, $wdt, $tim, $nam, $event ) = @_;
my $delay=0;
if ($nam eq "dm.eg.wz.Heizwert") {
fhem("set dmTest $tim");
if ($tim eq "22:00") {
if ((Value("eg.wz.Hauptbeleuchtung") eq "on") || (Value("eg.wz.Esstisch") eq "on") || (Value("div.Schalter1") eq "on"))
{
$delay=1;
}
}
}
return $delay;
}
Idee ist erst einmal, dass die Heizung solange eingeschaltet bleibt, wie irgendein Licht eingeschaltet ist. Um zu prüfen, ob die Schleife auch durchlaufen wird, setze ich einen Dummy "dmTest" mit der Variablen $tim, welche wiederum weiter oben im Attribut %Time übergeben wird.
Problem ist nun, dass offenbar der Ausdruck "%Time" nicht mit der jeweiligen Uhrzeit ersetzt wird, d.h., im Dummy landet tatsächlich "%TIME" als Text. Wo ist mein Denkfehler?
Viele Grüße
Michael
%TIME wird von delayedExecutionCond nicht unterstützt.
Was soll deiner Meinung nach darin jeweils von HC zur Verfügung gestellt werden?
War wohl noch nie so. In der Doku ist %TIME allerdings erwähnt.
habe es mal ergänzt - %TIME oder $TIME liefert die definierte Wunschzeit - wahrscheinlich im Format: 23:45:00 - probier es mal aus.
Hallo Dietmar,
ja, ich bin bisher davon ausgegangen, dass da die Schaltzeit abgelegt wird.
Kann ich die Ergänzung schon mal irgendwie testen?
Viele Grüße
Michael
nach einem update steht die Änderung zur Verfügung
OK, jetzt mal getestet. ;) Nun enthält die Variable eine Ziffer (aktuelle "2"). Bedeutet dies, dass die zweite Zeitscheibe aktiv ist? Und was muss ich in meinem Fall abfragen, um eine Verzögerung vor Eintritt in die dritte Zeitscheibe zu erreichen?
Beispiel:
... Mo-So|10:00|20 Mo-So|18:00|22 Mo-So|20:00|17 ...
Wenn ich nun erreichen wollte, dass die Einstellung ab 20:00 Uhr verzögert wird, würde die Variable $time dann um 20:00 Uhr den Wert "3" erhalten und ich müsste dies in meine Abfrage einbauen?
Viele Grüße
Michael
Hallo,
ich habe nun mal ein wenig getestet. Es scheint, als würde unter $Time wirklich die "Nummer" des Timers abgelegt. Besteht hier Hoffnung, dass man auch die Uhrzeit ausgeben kann? Denn die Timernummer ist wenig praktikabel, wenn man bestimmte Abhängigkeiten hat und man im Zweifel noch einen Timer einfügen muss.
Und dann habe ich noch eine Frage: Wie lange wird der Schaltvorgang maximal verzögert, wenn die Bedingung im Attribut "delayedExecutionCond" wahr ist? Ich hatte jetzt die Situation, dass nach einer Verzögerung von >2,5 Stunden kein Schaltvorgang mehr ausgeführt wird.
Viele Grüße
Michael
Zitatich habe nun mal ein wenig getestet. Es scheint, als würde unter $Time wirklich die "Nummer" des Timers abgelegt. Besteht hier Hoffnung, dass man auch die Uhrzeit ausgeben kann? Denn die Timernummer ist wenig praktikabel, wenn man bestimmte Abhängigkeiten hat und man im Zweifel noch einen Timer einfügen muss.
hast recht - ändere ich
ZitatUnd dann habe ich noch eine Frage: Wie lange wird der Schaltvorgang maximal verzögert, wenn die Bedingung im Attribut "delayedExecutionCond" wahr ist? Ich hatte jetzt die Situation, dass nach einer Verzögerung von >2,5 Stunden kein Schaltvorgang mehr ausgeführt wird.
An sich sollte das fast bis in alle Ewigkeit so weitergehen. Allerdings könnte man der Meinung sein, dass ein nachfolgender Timer den alten überschreiben sollte. Nur leider haben verschiedene Versuche das zu implementieren nicht gefruchtet, bzw. sind schief gegangen.
Es kann kompliziert werden, zu definieren was aufeinanderfolgende timer sind.
Ein Grenze ist auf jeden Fall Mitternacht. Dann werden die timer des neuen Tages gesetzt und laufende gelöscht.
Wieso bei dir nach 2,5 Stunden Schluss war, vermag ich nicht zu sagen.
Vielleicht kannst du ja eine Lücke in
WeekdayTimer_FensterOffen() finden.
Hi,
habe jetzt mal ausgiebig getestet... ;) Funktioniert mittlerweile prima und auch die Zeiten werden sauber übergeben. Einzig beim Tagwechsel kommt es dann zu Problemen, wenn die Verzögerung gerade aktiv ist. Fällt dann die Verzögerung (am Folgetag) weg, so wird dies auch entsprechend protokolliert, der state des moduls verbleibt aber trotzdem beim alten Wert und ändert sich nicht.
Viele Grüße
Michael
Gesendet von meinem SM-G900F mit Tapatalk
Moin zusammen,
kann es sein, das an dem Modul etwas verändert wurde.
Seit dem letzten update kommen keine Befehle mehr an meinen FHTs an.
Manuele Kommunikation mit den FHT funktioniert aber.
Mich wundert auch folgende Zeile im log 2016.01.23 10:48:41 3: WARNING: unsupported character in reading FHZ:measured-temp (not A-Za-z/\d_\.-), notify the FHT module maintainer.
2016.01.23 10:48:41 3: WARNING: unsupported character in reading FHZ:start-xmit (not A-Za-z/\d_\.-), notify the FHT module maintainer.
2016.01.23 10:48:41 3: WARNING: unsupported character in reading FHZ:warnings (not A-Za-z/\d_\.-), notify the FHT module maintainer.
Sind jetzt "_" nicht mehr erlaubt?
Zitat von: cornelius fillmore am 23 Januar 2016, 10:42:20
Sind jetzt "_" nicht mehr erlaubt?
Hmm, die Unterstriche werden in der Fehlermeldung allerdings nicht bemängelt...
Thema gelöst:
update force gemacht und alles läuft wieder
Hallo Dietmar
auch ich nutze dein Modul (FETTES THX für deine Arbeit), allerdings mit z-wave Komponenten.
Kriegst du denn auch ein z-wave Fenstersensor dran?
Grüße Tom
Zitat von: tomspatz am 26 Januar 2016, 19:20:11
Hallo Dietmar
auch ich nutze dein Modul (FETTES THX für deine Arbeit), allerdings mit z-wave Komponenten.
Kriegst du denn auch ein z-wave Fenstersensor dran?
Grüße Tom
Hi,
bei der Nutzung des Moduls sollte es ziemlich egal sein, welches System genutzt wird. Im Zweifel muss eine kleine Funktion erstellt werden, die den isDelayed-Wert triggert (siehe Doku).
Gruß
Michael
hmmmm
im Log finde ich aber:
Zitat2016.01.27 06:30:00 3: [HeizungssteuerungBad] TYPE 'ZWave' of FensterBad not yet supported, FensterBad ignored - inform maintainer
Erstellt bitte ein list des Zwave Fensterkontakten, dann kann prüfen, wie ich HC erweitere. Schaffe es aber frühestens am Sonntag - Urlaub
Moin Dietmar
hier das list:
Internals:
DEF c9cc092a 20
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 42
NAME BalkontuerWohnzimmer
NR 168
STATE geschlossen
TYPE ZWave
ZWDongle_0_MSGCNT 42
ZWDongle_0_RAWMSG 00040014028407
ZWDongle_0_TIME 2016-01-27 08:17:55
homeId c9cc092a
isWakeUp 1
lastMsgSent 1453879075.89379
nodeIdHex 14
Readings:
2016-01-09 17:14:09 CMD ZW_APPLICATION_UPDATE
2016-01-09 17:44:42 assocGroup_1 Max 5 Nodes ZWDongle_0
2016-01-09 17:44:42 assocGroup_2 Max 5 Nodes
2016-01-09 17:44:42 assocGroup_3 Max 1 Nodes ZWDongle_0
2016-01-09 17:44:42 assocGroups 3
2016-01-26 22:53:58 basicSet 00
2016-01-26 21:04:47 battery 93 %
2016-01-09 17:53:10 config_15 0
2016-01-09 17:14:09 mcCapability_02 SENSOR_MULTILEVEL
2016-01-09 17:12:38 model FIBARO System FGK101 Door Opening Sensor
2016-01-09 17:12:38 modelConfig fibaro/fgk001.xml
2016-01-09 17:12:38 modelId 010f-0700-1000
2016-01-26 22:53:58 reportedState closed
2016-01-26 22:53:58 state closed
2016-01-27 08:17:57 transmit OK
2016-01-27 08:17:55 wakeup notification
2016-01-11 07:41:47 wakeupReport interval 4000 target 1
Attributes:
IODev ZWDongle_0
alias Balkontür WZ
classes SENSOR_BINARY SENSOR_ALARM MULTI_CHANNEL ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC
devStateIcon .*offen:fts_door_open@red .*geschlossen:fts_door
eventMap open:offen closed:geschlossen
group Fenster und Türen
icon fts_door
room System Info,Wohnzimmer
Schönen Urlaub
Tom
98_Heating_Control, 98_WeekdayTimer: ZWave window sensor added for automatic recognition
Bitte teste mal ob es funktioniert.
Hallo,
Hab das Modul jetzt 1 Woche laufen und bin begeistert. Ich habe nur ein Problem mit dem setzen der desired temp bei meinen alten HM-CC-TC. Hier wird der Befehl oft nicht angenommen und es ist morgens angenehm kalt. Bei den neuen HM-CC-RT-DN kein Problem.
Wie kann ich in Modul Heating Control angeben das der desired temp Befehl, falls nicht erfolgreich, nochmal abgesetzt wird ?
Hermann
Das Modul sieht das nicht vor
Ok.
Gibt es trotzdem eine Möglichkeit das setzen der Temperaturen zuverlässiger zu gestalten im Modus manuell ?
Hermann
Alle HM Geräte sind über Handshake mir Rückmeldung angeschlossen. Ansich sollte der jeweilige Befehl sowieso wiederholt werden, wenn kein acknowlege kommt. Vielleicht hilft es die Empangsbedingungen irgendwie zu verbessern.
Versuch mal, ob dasdas Gerät mit einem at besser funktioniert.
Hallo Dietmar
danke für die Umsetzung der Fibaro FGK 101.
Ich habe noch nicht wirklich alles gecheckt, Infos liefere ich nach.
Ein Problem habe ich mit der Syntax bei zwei Fenstern die überwacht werden sollen.
attr HeizungssteuerungSchlafzimmer windowSensor FensterSchlafzimmerLinks,FensterSchlafzimmerRechts
Das gibt ein:
2016.02.11 07:30:00 3: [HeizungssteuerungSchlafzimmer] sensor <FensterSchlafzimmerLinks,FensterSchlafzimmerRechts> not found - check name.
Geht das überhaupt?
Moin.
Wieso werden beim Start von FHEM die aktuellen Temperaturen gestzt?
Kann man das irgendwie unterbinden?
Problem:
Habe gerade ein Update gemacht und FHEM neu gestartet. Dadurch hat HeatingControl natürlich die Temperaturen wieder gesetzt und meine Heizung im Schlafzimmer hat schön die Umwelt geheizt weil's Fenster noch auf war!
Kann man das implementieren oder gibt es schon eine Möglichkeit bei FHEM-Start die Temperaturen nicht zu setzen? Also die Ausführung bis zum nchsten wechsel zu unterbinden?
Grüße^^
@ Dietmar
Die Fibaros FGK 101 laufen super,vielen Dank für die Umsetzung.
Den Syntaxfehler mit zwei Fenstersensoren habe ich gefunden, ohne Komma auflisten funktioniert. ;)
Könnte man nicht noch etwas einbauen damit die Temperatur bei Fenster offen runter geregelt wird?
Zitat von: tomspatz am 29 Februar 2016, 20:52:05
@ Dietmar
Die Fibaros FGK 101 laufen super,vielen Dank für die Umsetzung.
Den Syntaxfehler mit zwei Fenstersensoren habe ich gefunden, ohne Komma auflisten funktioniert. ;)
Könnte man nicht noch etwas einbauen damit die Temperatur bei Fenster offen runter geregelt wird?
Diese Anforderung ist bei FS20-FHT und Homematik automatich durch die Kopplung tzwischen Thermostat und Fensterkontakt gegeben, deshalb bisher nicht umgesetzt.
Und leider lohnt es sicht nicht für für ein "Fibaros FGK 101" so etwas umzusetzen.
Zitat von: roman1528 am 25 Februar 2016, 14:57:42
Moin.
Wieso werden beim Start von FHEM die aktuellen Temperaturen gestzt?
Kann man das irgendwie unterbinden?
Problem:
Habe gerade ein Update gemacht und FHEM neu gestartet. Dadurch hat HeatingControl natürlich die Temperaturen wieder gesetzt und meine Heizung im Schlafzimmer hat schön die Umwelt geheizt weil's Fenster noch auf war!
Kann man das implementieren oder gibt es schon eine Möglichkeit bei FHEM-Start die Temperaturen nicht zu setzen? Also die Ausführung bis zum nchsten wechsel zu unterbinden?
Grüße^^
Das ist kein Fehler sondern ein Feature.
So nach dem Motto: Eine Heizung soll beim Start eines HC sofort auf den aktuell einzustellenden Wert umstellen.
Ich nehme an, du hast die Heizungen irgendwie ohne ein HC ausgestellt.
Vielleicht solltest du für so etwas separate Profile anlegen und über ein dummy zwischen den Profilen wechseln. Dann wird auch beim Start der Inhalt des dummys ausgewertet und korrekt geschaltet. Zugegeben - etwas aufwendiger auf funktioniert gut.
Es gibt weiterhin die Möglichkeit mit {Heating_Control_SetAllTemps()} dieses Verhalten jederzeit zu erzwingen.
Also irgendwie die An- oder Abwesenheit ermitteln und anschließend mit Heating_Control_SetAllTemps() die HC zu schalten.
Zitat von: Dietmar63 am 29 Februar 2016, 21:08:50
Das ist kein Fehler sondern ein Feature.
So nach dem Motto: Eine Heizung soll beim Start eines HC sofort auf den aktuell einzustellenden Wert umstellen.
Na gut. Das sehe ich ein und macht Sinn.
Zitat von: Dietmar63 am 29 Februar 2016, 21:08:50
Ich nehme an, du hast die Heizungen irgendwie ohne ein HC ausgestellt.
Ja selbstverständlich. Oder man muss ein Feature in Heating_Control implementieren welches die Temperatur bei Fenster auf (Kontakte werden ja schon überwacht) von sich aus runter regelt.
Für ein offenes Fenster ein extra Heating_Control bzw. Profil anzulegen finde ich irrsinnig! Aktuell mache ich das per notify.
Andere Frage:
Wenn man im Heating_Control-Device einen Fensterkontakt definiert hat... wird dieser auch beim Start (von FHEM) berücksichtigt? Oder wird da stumpf geschalten?
Ich werde da weiter testen und konfigurieren und mich ggf. nochmal melden wenn ich Probleme habe :)
Zitat von: Dietmar63 am 29 Februar 2016, 21:08:50
Es gibt weiterhin die Möglichkeit mit {Heating_Control_SetAllTemps()} dieses Verhalten jederzeit zu erzwingen.
Also irgendwie die An- oder Abwesenheit ermitteln und anschließend mit Heating_Control_SetAllTemps() die HC zu schalten.
Das nutze ich bereits für z.B. meinen "Eco-Taster". Der schöne Sache!
Grüße^^
ZitatDiese Anforderung ist bei FS20-FHT und Homematik automatich durch die Kopplung tzwischen Thermostat und Fensterkontakt gegeben, deshalb bisher nicht umgesetzt.
Ja das kenne ich.
ZitatUnd leider lohnt es sicht nicht für für ein "Fibaros FGK 101" so etwas umzusetzen.
Ist Verständlich.
Noch etwas zu mehreren HC Modulen du schriebst das du mehrere pro Raum hast.
Kann ich mir das so vorstellen:
define HeizungssteuerungBueroAnwesend Heating_Control HeizungBueroRegler So|09:30|20.00 Mo-Sa|07:30|20.00 22:30|19.00 (ReadingsVal("HeizungKontrolle", "state", "no") eq "anwesend")
define HeizungssteuerungBueroAbwesend Heating_Control HeizungBueroRegler Mo-So|06:00|19.00 (ReadingsVal("HeizungKontrolle", "state", "no") eq "abwesend")
define HeizungssteuerungBueroAUS Heating_Control HeizungBueroRegler Mo-So|06:00|12.00 (ReadingsVal("HeizungKontrolle", "state", "no") eq "aus")Dann mit einem dummy HeizungKontrolle den Status setzten auf anwesend,abwesend oder aus.
Sprich die laufen alle parallel, zum angegebenen Zeitpunkt wird der Status des dummy's ausgelesen und dann ggf. ausgeführt.
Bin ich auf dem richtigem Weg?
ZitatJa selbstverständlich. Oder man muss ein Feature in Heating_Control implementieren welches die Temperatur bei Fenster auf (Kontakte werden ja schon überwacht) von sich aus runter regelt.
Für ein offenes Fenster ein extra Heating_Control bzw. Profil anzulegen finde ich irrsinnig! Aktuell mache ich das per notify.
Sollte zwischen Thermostat und Fensterkontakt automatisch laufen - Es gäbe noch die Möglichkeit das Attribute
delayedExecutionCond zu nutzen.
ZitatAndere Frage:
Wenn man im Heating_Control-Device einen Fensterkontakt definiert hat... wird dieser auch beim Start (von FHEM) berücksichtigt? Oder wird da stumpf geschalten?
Auch dies obliegt der Verbindung zwischen Thermostat und Fensterkontakt.
ZitatNoch etwas zu mehreren HC Modulen du schriebst das du mehrere pro Raum hast.
Kann ich mir das so vorstellen:
Code: [Auswählen]
define HeizungssteuerungBueroAnwesend Heating_Control HeizungBueroRegler So|09:30|20.00 Mo-Sa|07:30|20.00 22:30|19.00 (ReadingsVal("HeizungKontrolle", "state", "no") eq "anwesend")
define HeizungssteuerungBueroAbwesend Heating_Control HeizungBueroRegler Mo-So|06:00|19.00 (ReadingsVal("HeizungKontrolle", "state", "no") eq "abwesend")
define HeizungssteuerungBueroAUS Heating_Control HeizungBueroRegler Mo-So|06:00|12.00 (ReadingsVal("HeizungKontrolle", "state", "no") eq "aus")
Dann mit einem dummy HeizungKontrolle den Status setzten auf anwesend,abwesend oder aus.
Sprich die laufen alle parallel, zum angegebenen Zeitpunkt wird der Status des dummy's ausgelesen und dann ggf. ausgeführt.
Bin ich auf dem richtigem Weg?
Völlig richtig - und wenn nach dem setzen des dummys die Temperatur sofort geschaltet werden soll dann
Heating_Control_SetAllTemps() aufrufen
Zitat von: Dietmar63 am 01 März 2016, 18:35:23
Sollte zwischen Thermostat und Fensterkontakt automatisch laufen - Es gäbe noch die Möglichkeit das Attribute delayedExecutionCond zu nutzen.
Auch dies obliegt der Verbindung zwischen Thermostat und Fensterkontakt.
Ok. schau ich mir an...
Genau das habe ich abgestellt! Keine Ferbindung mehr zwischen HT <-> SC <-> WT.
Aus einem einfachen Grund: Wenn schon FHEM warum dann nicht richtig FHEM?!? Alles kontrollieren...
Außerdem lief das instabil. Wenn ich ein Fenster auf gemacht habe ist das HT erst auf die WindowOpenTemperature gegangen... Aber kurz drauf (teilweise 10 sek.) wieder auf die Wochenprogramm-Temperatur. Ob da FHEM oder das WT reingepfuscht haben kann ich leider nicht sagen. Auf jeden Fall habe ich regelmäßig für die Luftwaffe geheizt, was mir persönlich nicht so gefällt.
Deswegen lasse ich Fensteröffnungen jetzt von FHEM kontrollieren.
Grüße^^
Bei mir hat der FK in Verbindung mit dem Thermostat bisher gut funktioniert. HC verzögert in solch einem Fall eine anstehende Schaltung
ZitatVöllig richtig - und wenn nach dem setzen des dummys die Temperatur sofort geschaltet werden soll dann Heating_Control_SetAllTemps() aufrufen
Also wenn die Bude auf Heizung "aus", ist greift das HC_aus Profil. Ich setzte mit den dummy Heizung "an", dann würde dieses HC_an Profil erstmals nach der NÄCHSTEN eingestellten Zeit die neuen Temperaturen setzen? OK so?
Und mit Heating_Control_SetAllTemps() wird das dann JETZT übernommen?? OK so ?
Wo kommt das denn rein? das verstehe ich noch nicht. :-\ SORRY
bei mir durch ein notify auf das dummy, bei mir Heizung:
define Heizung dummy ;
attr Heizung webCmd Aus:Ueb:Ein ;
...
define HeizStatus2 notify Heizung:.* {Heating_Control_SetAllTemps()} ;
Hallo Dietmar
ich habe scheinbar noch irgendwo einen Wurm drin, ich poste erst mal Code:
Das sind die drei Zustände pro Raum:
# Heizungsstereurung Büro
# anwesend
define HeizungssteuerungBueroAnwesend Heating_Control HeizungBueroRegler So|09:30|20.00 Mo-Sa|07:30|20.00 22:30|19.00 (ReadingsVal("Heizungssteuerung", "state", "no") eq "anwesend")
attr HeizungssteuerungBueroAnwesend alias Heizungssteuerung Büro anwesend
attr HeizungssteuerungBueroAnwesend devStateIcon active:Restart inactive:StandBy
attr HeizungssteuerungBueroAnwesend icon sani_heating_automatic
attr HeizungssteuerungBueroAnwesend room Heizungssteuerung
attr HeizungssteuerungBueroAnwesend windowSensor FensterBuero
# abwesend
define HeizungssteuerungBueroAbwesend Heating_Control HeizungBueroRegler 07:30|19.00 (ReadingsVal("Heizungssteuerung", "state", "no") eq "abwesend")
attr HeizungssteuerungBueroAbwesend alias Heizungssteuerung Büro abwesend
attr HeizungssteuerungBueroAbwesend devStateIcon active:Restart inactive:StandBy
attr HeizungssteuerungBueroAbwesend icon sani_heating_automatic
attr HeizungssteuerungBueroAbwesend room Heizungssteuerung
attr HeizungssteuerungBueroAbwesend windowSensor FensterBuero
# aus
define HeizungssteuerungBueroAus Heating_Control HeizungBueroRegler 11:30|4.00 Sa|11:15|28 (ReadingsVal("Heizungssteuerung", "state", "no") eq "aus")
attr HeizungssteuerungBueroAus alias Heizungssteuerung Büro aus
attr HeizungssteuerungBueroAus devStateIcon active:Restart inactive:StandBy
attr HeizungssteuerungBueroAus icon sani_heating_automatic
attr HeizungssteuerungBueroAus room Heizungssteuerung
attr HeizungssteuerungBueroAus windowSensor FensterBuero
Dann kommt der dummy zum umschalten:
define Heizungssteuerung dummy
attr Heizungssteuerung alias Heizungssteuerung
attr Heizungssteuerung devStateIcon .*anwesend:status_available .*abwesend:status_away_1 .*aus:status_standby
attr Heizungssteuerung group Heizung und Temperatur
attr Heizungssteuerung icon sani_heating
attr Heizungssteuerung room Heizungssteuerung,Verwaltung
attr Heizungssteuerung setList state:anwesend,abwesend,aus
attr Heizungssteuerung webCmd state
Und letztendlich das notyfy das darauf horcht:
define HeizungsteuerungAenderung notify Heizungssteuerung:.* {Heating_Control_SetAllTemps()}
So nachdem ich den dummy um 16:23 Uhr setze auf abwesend passiert folgendes:
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAbwesend inactive
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAbwesend active
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAbwesend nextUpdate: 2016-03-07 07:30:00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAbwesend nextValue: 19.00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAbwesend currValue: 19.00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAnwesend inactive
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAnwesend nextUpdate: 2016-03-06 22:30:00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAnwesend nextValue: 19.00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAnwesend currValue: 20.00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAus inactive
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAus nextUpdate: 2016-03-07 11:30:00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAus nextValue: 4.00
2016-03-06 16:23:34 Heating_Control HeizungssteuerungBueroAus currValue: 4.00
Parallel dazu finde ich im log:
2016.03.06 16:23:35 3: Heating_Control_SetAllTemps() done on: HeizungssteuerungBadAbwesend HeizungssteuerungBadAnwesend HeizungssteuerungBadAus HeizungssteuerungBueroAbwesend HeizungssteuerungBueroAnwesend HeizungssteuerungBueroAus HeizungssteuerungKuecheAbwesend HeizungssteuerungKuecheAnwesend HeizungssteuerungKuecheAus HeizungssteuerungSchlafzimmerAbwesend HeizungssteuerungSchlafzimmerAnwesend HeizungssteuerungSchlafzimmerAus HeizungssteuerungWohnzimmerAbwesend HeizungssteuerungWohnzimmerAnwesend HeizungssteuerungWohnzimmerAus
Doch sollte doch jetzt das HC die Temperatur sofort auf die 19 Grad setzten, macht es aber nicht.
Hoffe das das genug Futter ist.
LG
Tom
Wwelche Heizung hast du? fs20, homematic?
Das Setzen der Temperatur dauert ein wenig. Du könntest während der Testphase mal bei allen HC verbose auf 4 setzen. Dann gibt das Modul logging aus.
ZitatWwelche Heizung hast du? fs20, homematic?
Alles zwave.
Oder läuft das HC nur umgekehrt? Also wenn die aktuellen Temperaturen klein sind, wird "sofort" auf gross geschaltet.
Ich habe jetzt zum testen andersherum gemacht, vom anwesend mit höheren Temp. zu abwesend min niedrigeren Temp.
Vielleicht wird Zwave noch nicht als Heizung erkannt - setze bitte verbose 5
Ich bediene mit HC die devices gar nicht direkt sondern über einen dummy.
Das funktioniert sonst einwandfrei.
define HeizungBueroRegler dummy
attr HeizungBueroRegler alias Heizung Büro
attr HeizungBueroRegler group Heizung und Temperatur
attr HeizungBueroRegler icon sani_heating_manual
attr HeizungBueroRegler room Büro,System
attr HeizungBueroRegler setList state:4.00,4.50,5.00,5.50,6.00,6.50,7.00,7.50,8.00,8.50,9.00,9.50,10.00,10.50,11.00,11.50,12.00,12.50,13.00,13.50,14.00,14.50,15.00,15.50,16.00,16.50,17.00,17.50,18.00,18.50,19.00,19.50,20.00,20.50,21.00,21.50,22.00,22.50,23.00,23.50,24.00,24.50,25.00,25.50,26.00,26.50,27.00,27.50,28
attr HeizungBueroRegler stateFormat {sprintf(" %.1f °C",(ReadingsNum("HeizungBueroRegler","state",0)))}
attr HeizungBueroRegler webCmd state
define HeizungBueroReglerNotify notify HeizungBueroRegler:* {\
my $reglerwert =\
ReadingsVal("HeizungBueroRegler","state","on");;\
fhem ("set HeizungBuero thermostatSetpointSet $reglerwert");;\
}
Dann kann HC nicht erkennen, dass Heizungen gesteuert werden.
Nur bei Heizungen wird per Heating_Control_SetAllTemps() auch in der Vergangenheit geschaltet.
Es gibt noch den Parameter "switchInThePast" oder so ähnlich. Damit kann man das Schalten Vergangener Zeiten erzwingen. Müsste helfen.
aber warum funktioniert das dann einwandfrei mit den dummy?
Heating_Control_SetAllTemps() "bewegt" doch auch NUR die einzelnen HC oder?
switchInThePast gefunden
das muss dann in jedem HC auf 1 stehen.
Wann wird das denn gesetzt?
Nicht mit dem notyfy.
Als Attribut nach der Definition
ZitatAls Attribut nach der Definition
Ja das ist mir klar. Bei jedem HC als Attribut.
Dann schalte ich mit dem dummy die zustände:
define Heizungssteuerung dummy
attr Heizungssteuerung alias Heizungssteuerung
attr Heizungssteuerung devStateIcon .*anwesend:status_available .*abwesend:status_away_1 .*aus:status_standby
attr Heizungssteuerung group Heizung und Temperatur
attr Heizungssteuerung icon sani_heating
attr Heizungssteuerung room Heizungssteuerung,Verwaltung
attr Heizungssteuerung setList state:anwesend,abwesend,aus
attr Heizungssteuerung webCmd stateDie entsprechenden HC werden dann über den dummy active und setzen dann sofort die Temperatur die zum letzten Zeitpunkt definiert wurde.
Kein notify mehr ?
Das reicht dann so ?
Doch notify muss sein! Sonst kommt das Ergebnis, dass sich ein dummy geändert hat nicht bei den HC an
SORRY das schnalle ich jetzt nicht ....
Hast du mal ein Beispiel für ein solches notify?
Ich hab auch eine Verständnisfrage zum Attribut delayedExecutionCond. Ich hab einen dummy der 4 verschiedene Heating_Control je Heizkörper unterscheidet. Das habe ich direkt in der Definition mit if dahinter gehängt. Jetzt wollte ich noch delayedExecutionCond nutzen, wenn meine Umwälzpumpe aus ist brauche ich auch nicht die Heizung hoch schalten, denn dann kann es auch nicht warm werden. Ich hab dazu einen Fensterkontakt als digitalen Eingang genutzt. Somit ist das dann als ReadingsVal onoff erfasst. Leider schaltet das Heating_Control unabhängig von der delayedExecutionCond.
Internals:
COMMAND { fhem("set $NAME desiredTemperature $EVENT") if (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal")}
CONDITION
DEF OG_Bad_T mo-fr|05:05|23 mo-fr|06:30|18 mo-fr|19:10|17.5 $we|08:00|20 $we|19:00|18 { fhem("set $NAME desiredTemperature $EVENT") if (ReadingsVal("HC_Bad_Off_Profile", "state", "") eq "Minimal")}
DEVICE OG_Bad_T
GlobalDaylistSpec
LANGUAGE de
NAME HC_Bad_Min
NR 175
Profil 0: Sonntag 08:00:00 20, 19:00:00 18
Profil 1: Montag 05:05:00 23, 06:30:00 18, 19:10:00 17.5
Profil 2: Dienstag 05:05:00 23, 06:30:00 18, 19:10:00 17.5
Profil 3: Mittwoch 05:05:00 23, 06:30:00 18, 19:10:00 17.5
Profil 4: Donnerstag 05:05:00 23, 06:30:00 18, 19:10:00 17.5
Profil 5: Freitag 05:05:00 23, 06:30:00 18, 19:10:00 17.5
Profil 6: Samstag 08:00:00 20, 19:00:00 18
Profil 7: Wochenende 08:00:00 20, 19:00:00 18
STATE 17.5
STILLDONETIME 0
TYPE Heating_Control
Readings:
2016-06-03 19:10:01 currValue 17.5
2016-06-03 19:10:01 nextUpdate 2016-06-04 08:00:00
2016-06-03 19:10:01 nextValue 20
2016-06-03 19:10:01 state 17.5
SWITCHINGTIMES:
mo-fr|05:05|23
mo-fr|06:30|18
mo-fr|19:10|17.5
$we|08:00|20
$we|19:00|18
Timer:
Hc_bad_min_2:
HASH HC_Bad_Min
MODIFIER 2
NAME HC_Bad_Min_2
immerSchalten 1
Hc_bad_min_3:
HASH HC_Bad_Min
MODIFIER 3
NAME HC_Bad_Min_3
Hc_bad_min_settimerofday:
HASH HC_Bad_Min
MODIFIER SetTimerOfDay
NAME HC_Bad_Min_SetTimerOfDay
SETTIMERATMIDNIGHT 1
Hc_bad_min_delayed:
HASH HC_Bad_Min
MODIFIER delayed
NAME HC_Bad_Min_delayed
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
08:00:00 20
19:00:00 18
1:
05:05:00 23
06:30:00 18
19:10:00 17.5
2:
05:05:00 23
06:30:00 18
19:10:00 17.5
3:
05:05:00 23
06:30:00 18
19:10:00 17.5
4:
05:05:00 23
06:30:00 18
19:10:00 17.5
5:
05:05:00 23
06:30:00 18
19:10:00 17.5
6:
08:00:00 20
19:00:00 18
7:
08:00:00 20
19:00:00 18
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1464923100
PARA 23
TIME 05:05
TAGE:
1
2
3
4
5
2:
EPOCH 1464928200
PARA 18
TIME 06:30
TAGE:
1
2
3
4
5
3:
EPOCH 1464973800
PARA 17.5
TIME 19:10
TAGE:
1
2
3
4
5
4:
EPOCH 1464933600
PARA 20
TIME 08:00
TAGE:
7
5:
EPOCH 1464973200
PARA 18
TIME 19:00
TAGE:
7
Profile_idx:
0:
08:00:00 4
19:00:00 5
1:
05:05:00 1
06:30:00 2
19:10:00 3
2:
05:05:00 1
06:30:00 2
19:10:00 3
3:
05:05:00 1
06:30:00 2
19:10:00 3
4:
05:05:00 1
06:30:00 2
19:10:00 3
5:
05:05:00 1
06:30:00 2
19:10:00 3
6:
08:00:00 4
19:00:00 5
7:
08:00:00 4
19:00:00 5
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
delayedExecutionCond ( { if (ReadingsVal("Umwaelzpumpe", "onoff", "") == 0) } )
group Profile
room R02 Badezimmer
switchInThePast 1
windowSensor OG_Bad_Fensterkontakt
Moin,
habe mal eine grundlegende Frage zu der ich auch nach durchsuchen des kompletten Threads keine wirkliche Antwort gefunden habe:
Ich versuche HeatingControl mit einem command UND einer condition zu definieren was jedoch nicht klappt.
Ist es grundsätzlich möglich command UND condition zu definieren? Ich habe das Gefühl es geht nur eines von beiden.....
Falls es doch geht wäre bitte jemand so freundlich und würde mir den GENAUEN Syntax anhand eines Beispiels schreiben?
Ich versuche es seit ca. 1 Stunde und bekomme es nicht hin. Und ja, Commandref und Wiki habe ich gelesen, mehr als einmal, komme dennoch nicht klar....
Vielen Dank.
grtz
CmdA
mach mal ein Beispiel wie du dir das vorstellst
Zitat von: Dietmar63 am 23 August 2016, 12:43:25
mach mal ein Beispiel wie du dir das vorstellst
Mein Gedanke ging in diese Richtung:
define HC_Kueche Heating_Control eg_KUE_Clima 12345|6:00|day 12345|22:00|night {(subHC($NAME,$EVENT))}|(ReadingsVal("HCAutomatik", "state", "") eq "on")Ist nur ein Beispiel.
Ich dachte mir das so dass Heating_Control die Sub (command) nach Zeitplan ausführt wenn HCAutomatik wahr ist (condition).
Andernfalls nicht.
Wobei sich mir dann als nächstes die Frage stellt ob die sub ausgeführt wird wenn die condition erst innerhalb des Zeitplans wahr wird.
(Im Beispiel also z.B. um 7Uhr).
Für mich liest sich der Syntax
define <name> Heating_Control <device> [<language>] <wochentage;] <profile> <command>|<condition> grundsätzlich so als könne ich beides definieren.
Es steht auch nirgendwo geschrieben das nur eines von beiden geht. (command
oder condition).
Ist auch alles kein Problem für mich um das Modul zu nutzen, ich wollte nur grundsätzlich wissen ob das vorgesehen ist weil es in meinen Augen per Syntax möglich ist, ich es aber nicht hinbekomme.
Danke.
grtz
CmdA
{(subHC($NAME,$EVENT))}|(ReadingsVal("HCAutomatik", "state", "") eq "on")
so wie du es verstanden hast ist es nicht gemeint, man kann entweder einen
<command>
{fhem("set $NAME $EVENT") if(ReadingsVal("HCAutomatik", "state", "") eq "on")}
oder eine
<condition>
(ReadingsVal("HCAutomatik", "state", "") eq "on")
angeben.
Wenn du dich für <command> entscheidest musst du die Blaupause für den zu sendenden Befehl selbst angeben. $NAME $EVENT werden durch den Gerätenamen bzw. Parameter ersetzt.
Alles klar.
Vielen Dank für die Rückmeldung. Jetzt habe ich es verstanden.
Hallo zusammen,
erstmal vielen Dank für das tolle Modul, ich bin noch in der Anfängerphase habe aber Profianforderung :D...
Ich habe da eine Frage, ich habe keine Heizkörper da ich eine Elektrofußbodenheizung habe. Die einzelnen Heizkreise
habe ich an Homematic Aktoren angeschlossen die ich einzeln schalten kann. Einen weiteren Kreis habe ich an einen ZWave Schaltaktor angeschlossen.
Soweit so gut.
Die Temperatur nehme ich mit unterschiedlichen Sensoren auf. Erschwerend kommt hinzu das ich einen Kachelofen in Betrieb habe der die Hauptwärme
erzeugt, der Fußboden soll also nur "Fußwarm" werden...
1. Temperatur Sensor Boden
2. Verschiedene Temperatur Sensor für die Luft
Ich bräuchte also zum einen eine Abhängig von der Tageszeit und zum anderen von der Temperatur des Bodensensors.
Ist das möglich?
Vielen Dank für die Unterstützung und ein schönen Abend.
Grüße
Sven
Ich glaube eher nicht dass dieses Modul gut geeignet ist deine Anforderung umzusetzen.
Es geht grundsätzlich davon aus, dass einem Thermostat zu den verschiedenen Tageszeiten nur eine Solltemperatur vorgegeben wird und sich dann das Thermostat selbst um die Regelung kümmert.
Du benötigst eher ein Modul, das sich ständig mit Soll- Istvergleichen einem Soll nähert.
Ein Modul, das so etwas kann ist HCS, HCS kann als device ein Heating_Control schalten.
PID20 kommt vielleicht auch in Frage. Allerdings habe ich lange nichts hier im Forum mehr zum Modul gelesen.
ZitatAllerdings habe ich lange nichts hier im Forum mehr zum Modul gelesen.
Ich benutze PID20 seit drei Wintern zur Ansteuerung meiner Heizkörper mittels des Heating_Control-Moduls.
Obwohl PID-Regler, glaube ich, eigentlich optimal für schnellregelnde System sind (Motorsteuerung im PKW) wird bei meiner trägen Heizung eine Ist-Temperatur erreicht, die in der Regel maximal nur um ein halbes Grad Celsius vom Soll-Wert abweicht mit schönem, finde ich, Einschwingverhalten.
Heating_Control setzt den Sollwert in einen dummy (damit auch manuell eine abweichende Solltemperatur angeben werden kann). Ein notify auf den dummy setzt den Sollwert im PID20.
Weitere Optimierungen sollten hier im notify kein Problem sein.
Ich find's optimal!
Gruß
Hans
HCS kann als device ein Heating_Control schalten.
Es ist genau verdreht. Heating_Control kann HCS und pid20 steuern.
Hallo alle zusammen.
Ich komme hier nicht weiter evtl. hab ihr eine Lösung für mich oder aber sie ist eh einfach dann entschuldigt bitte bin noch ziemlich frisch in fhem.
Ich habe folgendes Script im Einsatz
#############Kontrolle der Gastherme ueber MAX-Schaltkontakt Beginn##################
#### Heizung: Winterbetrieb Sommerbetrieb
define HA_Heizung_Modus dummy
attr HA_Heizung_Modus alias Betriebsmodus
attr HA_Heizung_Modus group Betriebsmodus
attr HA_Heizung_Modus room System
attr HA_Heizung_Modus setList state:Winter,Sommer
attr HA_Heizung_Modus userReadings HCS_TEMP { if (ReadingsVal("HA_Heizung_Modus","state","Unbekannt") eq "Winter"){return 0} else {return 30};;}
attr HA_Heizung_Modus webCmd state
#Versuch mit HCS-Modul
define HCS_System HCS HA_Heizung_Schalter
attr HCS_System alias Heizungssteuerung
attr HCS_System deviceCmdOff desiredTemperature auto 17
attr HCS_System deviceCmdOn desiredTemperature auto 21
attr HCS_System event-on-change-reading state,devicestate,eco,overdrive
attr HCS_System exclude HA_Heizung_Schalter
attr HCS_System idleperiod 5
attr HCS_System interval 1
attr HCS_System mode valve
attr HCS_System room System
attr HCS_System sensor HA_Heizung_Modus
attr HCS_System sensorReading HCS_TEMP
attr HCS_System sensorThresholdOff 20
attr HCS_System sensorThresholdOn -1
attr HCS_System thermostatThresholdOff 0.5
attr HCS_System thermostatThresholdOn 0.5
attr HCS_System valveThresholdOff 10
attr HCS_System valveThresholdOn 40
#############Kontrolle der Gastherme ueber MAX-Schaltkontakt Ende####################
Funktioniert auch bestens nur reichen die Credits niee da ja HCS jede Minute den Status abfrägt.
Jetzte habe ich folgendes gefunden
https://forum.fhem.de/index.php/topic,37980.0.html
In diesem Fred hat jemand einen Dummy erstellt der die Credits schont :-)
define CV_Schakelaar dummy
attr CV_Schakelaar devStateIcon off:sani_heating@blue on:sani_heating@red
attr CV_Schakelaar setList state:on,off
attr CV_Schakelaar webCmd state
set CV_Schakelaar off
define CV_Schakelaar_Changed notify CV_Schakelaar {my $r1 = $value{"CV_Schakelaar"};; my $r2 = ReadingsVal("CV_Relais","desiredTemperature","off");; if ($r1 ne $r2) {fhem "set CV_Relais desiredTemperature $r1"}}
define CV_Relais Max HeatingThermostat 0d25b0
define CV_Controller HCS CV_Schakelaar
set CV_Controller interval 1
attr CV_Controller devStateIcon idle:sani_heating@blue demand:sani_heating@red
attr CV_Controller deviceCmdOn on
attr CV_Controller deviceCmdOff off
attr CV_Controller exclude CV_Relais
attr CV_Controller idleperiod 3
Nur ich habe leider keinen schimmer wie ich die beiden Scripte miteinander verbinde.
Es wäre der über drüber Hammer wenn mir hier wer helfen könnte.
Vielen Dank und lg
Chris
Vielleicht kann mir auch jmd helfen.
Habe diverese Weekdaytimer die auch richtig funktionieren.
Trotzdem bekomme ich bei allen mit Tag "7" einen LOG-Eintrag "in daylist now means $we(weekend) - see dokumentation!!!"
Wie bekomme ich das weg? Eine holiday-Datei ist beschrieben, die "Änderung" des WD ist bekannt, aber das Log schreibt mir da alle paar Stunden 10-12 mal die gleiche Zeile rein. Was mache ich falsch?
Du verwendest vermutlich als Codierung für den Tag eine 7.
Die 7 hat sich von der Bedeutung vor einiger Zeit geändert.
Du könntest auf Symbole So-Sa oder so umstellen. Ich könnte den Hinweis herausnehmen, sollte sich ja jetzt herumgesprochen haben
Ja genau nutze 7 und habe gedacht ich mache as falsch wegen dem Log-Eintrag :) Wenn das Standardmäßig kommt ist das ja dann kein Fehler. Rausnehmen wäre natürlich super. Habe gleich noch eine 2. Frage. Leider reagieren meine Somfy-Rolläden nicht immer direkt, manchmal muss der Befehl ein zweites Mal raus. Jetzt habe ich gelesen das ein repeat nicht vorgesehen ist, gibt es andere Möglichkeiten als den WD Timer einfach 2 min später nochmal zu setzen?
7 bedeutet wie 8 nicht Sonntag oder Samstag - siehe comnandref
WDT hat keine Repeat Funktion. Du solltest vielleicht die Empfangsbedingungen verbessern.
Ist das richtig das das so in die Eingabezeile eingegeben NICHT funktioniert?
set {Heating_Control_SetTemp("HeizungssteuerungSchlafzimmerAn")}
ja
{Heating_Control_SetTemp("HeizungssteuerungSchlafzimmerAn")}
Hallo Dietmar
in der Tat
{Heating_Control_SetTemp("HeizungssteuerungSchlafzimmerAn")}
So funktioniert das prima. Wobei dann unterhalb der Eingabezeile soetwas auftaucht:
HASH(0x2c0e190)
Das ganze wird allerdings ausgeführt und ist dann auch im Log zu finden.
Habe allerdings versucht das so in einem DOIF zu verwenden.
([FensterSchlafzimmerLinks] eq "closed" and [Heizungssteuerung] eq "an" and [SchlafzimmerLueftenStatus] eq "ja") (set SchlafzimmerLueftenStatus nein, {Heating_Control_SetTemp("HeizungssteuerungSchlafzimmerAn")})
in diesem Fall wird es komplett ausgelassen, wobei der dummy <SchlafzimmerLueftenStatus > gesetzt wird. Und ich bin nicht sicher wo der Fehler liegt.
Bin damit auch schon im DOIF Forum unterwegs, gibt es da irgendwelche Inkompatibilitäten zwischen den Modulen?
LG
Tom
An sich nicht.
Du mischt so wie du es gemacht hast fhem-Befehle und PerlCode.
Ob das in Doif als Parameter geht, kann ich nicht sagen.
Ja geht, mache ich auch mit deinem Modul
Dann vielleicht mal Logging in Doif einschalten
Ich habe seit ein paar Tagen ein Problem mit dem Modul HCS: nach einem Reboot ist es nicht mehr aktiv, das war es Anfang des Jahres aber noch.
Kann sowas durch ein Update gekommen sein?
Und wie kann ich das SO einstellen daß es automatisch läuft?
@ Dietmar63
Ich habe ein "komisches" Verhalten ztw. kann es allerdings nicht wirklich nachvollziehen.
Ist Zustand: Pro Raum drei HC's "an", "abwesend", "aus". Diese werden mit einem notify passend "active" "inactive" gesetzt.
Bei den "an" sowie "abwesend" HC's wird auch das attr windowSensor verwendet.
Jetzt passiert folgendes (ztw.) Im Moment ist ja Status "an", Fenster auf wird erkannt aber vom "falschen" ("abwesend") HC verzögert. Das selbe "falsche" erkennt dann ja auch Fenster zu.
Es passiert halt nur wenn während das Fenster auf und das HC eine andere Temperatur setzen soll.
Komischerweise kriege ich da kein Routine raus, Einen Morgen habe ich mehrere Fenster zum passenden Zeitpunkt extra geöffnet. Das haben alle "an" HC's die Verzögerung gesetzt.
Heute schon wieder mal ein "abwesend" HC.
Kannst du dir da einen Reim raus machen? Gibt es da ggf. einen Zusammenhang mit der alphabetischen Reihenfolge? Aber das nur Manchmal ????
LG
Tom
Das hört sich in der Tat sehr merkwürdig an.
Versuch mal bei einem oder zwei problematischen Timern mit verbose 5 im Protokoll nach Merkwürdigkeiten zu suchen.
Es wird eine Menge protokolliert
Maximal zwei damit du nicht durcheinander kommst.
Ich hab da mal eine Frage,
in dem Wiki steht
Zitat{Heating_Control_SetAllTemps()}
beim ECo Mode.
Wie komme ich an diese Funktion?
Ich würde auch gern alle Temperaturen dann setzen entsprechend der ECO Funktion.
Und im Wiki ist mir ein Fehler aufgefallen:
Beim define des ECO.Mode.Aktivator DOIF fehlt am ende die abschließende Klammer.
Verstehe ich noch nicht
Mit der obigen Funktion werden alle Temperaturen gesetzt, wenn beispielsweise auf die Inhaltsänderung eines dummys reagiert werden soll
... ECO.Mode.Aktivator DOIF
DOIF steht meines Wissens nicht in der Doku zu Heating_Control
Zitat von: Dietmar63 am 09 November 2016, 18:35:19
Verstehe ich noch nicht
Mit der obigen Funktion werden alle Temperaturen gesetzt, wenn beispielsweise auf die Inhaltsänderung eines dummys reagiert werden soll
... ECO.Mode.Aktivator DOIF
DOIF steht meines Wissens nicht in der Doku zu Heating_Control
ich hätte diese obige Funktion eben gern!
Und das zweite hab ich angehängt
Ich versuche mich grad durch die Doku und diesen Thread durchzuwurschteln, und würde gern wissen, wie ich mehrere Heizungsthermostaten mit der gleichen Definition steuern kann.
Bei
define HC_wohnzimmer Heating_Control Heizungsventil_wohnzimmer_.* <...>
kommt leider eine freundliche Meldung:
no switch in the yesterdays because of the devices type(Heizungsventil_wohnzimmer.* is not recognized as heating
Kann man so was noch einbauen? Durch alle passenden Devices iterieren?
Je tiefer man einsteigt, um so spannender wird es ;)
Problem: einfach ein Wochenprogramm, das eine Temperaturabsenkung hat (und z.B. per "set Temperaturabsenkung 2" dafür sorgt, dass alle Temperaturen um 2 Grad gesenkt werden).
Idee: benutze das "command" dieses Moduls:
define TemperaturAbsenkung dummy
attr TemperaturAbsenkung setList degree:0,1,2,3
attr TemperaturAbsenkung webCmd degree
set TemperaturAbsenkung 0
define n_TemperaturAbsenkung notify TemperaturAbsenkung:.* {{Heating_Control_SetAllTemps()}}
define HC_wohnzimmer Heating_Control Heizungsventil_wohnzimmer.Nord de Mo-Fr|05:00|22.0 Mo-Fr|06:30|20.0 Mo-Fr|15:00|21.0 So-Do|23:00|19.0 Sa-So|06:00|22.0 Fr-Sa|24:00|19.0 {\
my $degree = max($EVENT - ReadingsVal("TemperaturAbsenkung", "degree", "0"), 16);;\
Log(2, "set temp to " . $degree);;\
fhem("set $NAME desiredTemperature $degree");;\
}
attr HC_wohnzimmer room Wochenprogramme
Aber da gibt es eine Optimierung, die den ALTEN Wert vergleicht, und dann das Command nicht aufruft:
2016.11.16 17:58:15 4: Heizungsventil_wohnzimmer.Nord 2016-11-16 15:00:00 10695s
2016.11.16 17:58:15 4: [HC_wohnzimmer] time=15:00/1479304800 delay=10695, nextDelay=10740, nextRetry=1479315540
2016.11.16 17:58:15 4: [HC_wohnzimmer] delayedExecutionCond:0
2016.11.16 17:58:15 4: [HC_wohnzimmer] result of delayedExecutionCond:0
2016.11.16 17:58:15 4: [HC_wohnzimmer] list of window sensors found: 'HC_wohnzimmer'
2016.11.16 17:58:15 4: [HC_wohnzimmer] condition: - Tage:7,8
2016.11.16 17:58:15 4: [HC_wohnzimmer] condition: - Tage:1,2,3,4,5
2016.11.16 17:58:15 4: [HC_wohnzimmer] Update - past timer activated
2016.11.16 17:58:15 4: [HC_wohnzimmer] device type MAX:HeatingThermostat recognized, setModifier:desiredTemperature
2016.11.16 17:58:15 4: [HC_wohnzimmer] aktParam:22.0 newParam:22.0 - is not disable
Somit ist dieser Weg verbaut. Wie kann man das am klügsten einbauen (ich will nicht überall eine Funktion aufrufen)? Oder ganz anders realisieren? Wie macht ihr so was, erst mal ohne Abwesenheitserkennung...
Bin grad eine Woche bei FHEM, und man entdeckt praktisch jede Stunde neue Sachen...
(mein nächster Versuch, die Temperatur als Formel berechnen zu lassen, ist leider auch fehlgeschlagen:
define HC_wohnzimmer Heating_Control Heizungsventil_wohnzimmer.Nord de Mo-Fr|05:00|{HC_Temp(23)}
weil der Teil wörtlich an die Routine übergeben wird. Schade aber auch ;)
Zitat von: c2j2 am 16 November 2016, 18:06:52
Somit ist dieser Weg verbaut. Wie kann man das am klügsten einbauen (ich will nicht überall eine Funktion aufrufen)? Oder ganz anders realisieren? Wie macht ihr so was, erst mal ohne Abwesenheitserkennung...
([HZ.Absenkung] eq "on" and [HCWZ:currValue] <= [Heizungsthermostat_WZ_Clima:desired-temp])(set Heizungsthermostat_WZ_Clima desired-temp {([HCWZ:currValue] -2)})
DOELSEIF ([HZ.Absenkung] eq "off")(set Heizungsthermostat_WZ_Clima desired-temp [HCWZ:currValue])
OK, für die Akten: es geht. In die eigenen 99_myUtils.pm:
sub HC_Temp($)
{
my $Temp = @_[0];
my $degree = max($Temp - Value("TemperaturAbsenkung"), 16);
# Log(1, "DEGREE = ". $degree . " - " . Value("TemperaturAbsenkung"));
return $degree
}
sub HC_setTemp($$)
{
my ($Device, $Temp) = @_;
my $OldTemp = ReadingsVal($Device, "desiredTemperature", "0");
Log(2, "HC_setTemp(): set $Temp deg in $Device. Was: $OldTemp");
if ($Temp < $OldTemp || $Temp > $OldTemp) # no "!=" as it would compare strings
{
Log(2, "FHEM: set $Device desiredTemperature $Temp");
fhem("set $Device desiredTemperature $Temp");
return 1;
}
return 0;
}
und im FHEM:
define TemperaturAbsenkung dummy
attr TemperaturAbsenkung setList state:0,1,2,3,4,5
# attr TemperaturAbsenkung webCmd state
set TemperaturAbsenkung 0
define n_TemperaturAbsenkung notify TemperaturAbsenkung:.* {Heating_Control_SetAllTemps()}
define HC_wohnzimmer Heating_Control Heizungsventil_wohnzimmer.Nord de Mo-Fr|05:00|HC_Temp(23) <etc etc> {\
Log(2, "HC results in: set $NAME desiredTemperature @{[eval $EVENT]} (from $EVENT)");;\
HC_setTemp($NAME, eval $EVENT);;\
}
attr HC_wohnzimmer room Wochenprogramme
Ich bin aber gern für jede Schandtat zu haben, so sie besser ist ;)
Frage dazu: ich habe das HC_setTemp() gemacht, um überflüssige Packets über den Äther zu vermeiden. Ist das "set <device> desired Temperature <n>" von MAX optimiert, und ich brauche das nicht machen? Weß das jemand? Auf die "Schnelle" (PERL ist - ähem - nicht meine Stärke) kann ich es aus dem Modul-Code nicht ersehen.
define HC_wohnzimmer Heating_Control Heizungsventil_wohnzimmer.Nord de Mo-Fr|05:00|23 {HC_temp(%)}
Moin Dietmar
bekomme heute nach fhem update und Neustart folgendes:
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
2016.11.17 08:32:55 1: [RolloBalkontuerAutomatik] invalid time <31:59:28> HH:MM[:SS]
Die Definition ist:
defmod RolloBalkontuerAutomatik WeekdayTimer RolloBalkontuerWohnzimmer {sunrise("REAL",30)}|up {sunset("REAL",10920)}|down (ReadingsVal("Suedring111", "state", "no") ne "home")
attr RolloBalkontuerAutomatik alias Rollo Balkontür Automatik
attr RolloBalkontuerAutomatik devStateIcon active:Restart \d+.*:Restart .*:StandBy
attr RolloBalkontuerAutomatik group Rollo Einstellungen
attr RolloBalkontuerAutomatik icon fts_shutter_automatic
attr RolloBalkontuerAutomatik room Steuerung-Rollos
setstate RolloBalkontuerAutomatik inactive
setstate RolloBalkontuerAutomatik 2016-11-17 08:37:00 currValue up
setstate RolloBalkontuerAutomatik 2016-11-17 08:37:00 nextUpdate 2016-11-17 19:27:42
setstate RolloBalkontuerAutomatik 2016-11-17 08:37:00 nextValue down
setstate RolloBalkontuerAutomatik 2016-11-17 08:37:00 state inactive
Irgendwie schnallt es sunrise nicht, hat allerdings bislang so gelaufen. Die Anderen Rollos natürlich das selbe.
Hast du eine Idee?
LG
Tom
Habe es jetzt umgebaut, so scheint es OK zu sein:
defmod RolloBalkontuerAutomatik WeekdayTimer RolloBalkontuerWohnzimmer {sunrise_abs_dat($date,"REAL",30)}|up {sunset_abs_dat($date,"REAL",10920)}|down (ReadingsVal("Suedring111", "state", "no") ne "home")
@Dietmar63: das geht leider nicht.
- meinst Du HC_SetTemp()?
- es passiert nichts, die Log-Ausgabe im HC_SetTemp wird nicht aufgerufen. Weil die Temperatur gleich bleibt, und dann die Ausführung der Funktion von vornherein verhindert wird. Nur die Angabe bei jedem Zeitpunkt (die Zeichenkette ist ja anders) verhindert diese Optimierung, scheint mir. "aktParam:21.0 newParam:21.0 - is not disabled"
@tomspatz:
"invalid time <31:59:28>" ist normal, wenn berechnet nach Sonnenaufgang - da werden 24 Stunden addiert, wenn der nächstmögliche Sonnenaufgang erst wieder am nächsten Tag ist.
Zitat"sunrise / sunset geben die absolute Zeit des nächsten Sonnenauf- bzw. -untergangs zurück, wobei 24 Stunden addiert werden, sofern das entsprechende Ereignis am nächsten Tag stattfindet"
http://www.fhemwiki.de/wiki/SUNRISE_EL (http://www.fhemwiki.de/wiki/SUNRISE_EL)
Also mit "at" um 0:01 2 Dummy-Variablen berechnen lassen und gut ist.
so:
define HC_wohnzimmer Heating_Control Heizungsventil 19:20|23 {HC_temp($EVENT)};
Hallo Dietmar,
zunächst vielen Dank für dieses tolle Modul. Eine Frage allgemein zu den Conditions: Ist es richtig, dass in einem define immer nur eine Condition zulässig ist? Wenn ja, wäre es möglich, das Modul so zu optimieren, dass pro Schaltakt eine eigene Condition denkbar ist? So hätte man in einem Define alles definiert, was die Übersichtlichkeit und den WAF Faktor erhöht.
Danke und Gruß
Wolfgang
Moin Dietmar,
das geht eben nicht, würde ich sagen, da der Parameter gleich bleibt, und gemäß
my $aktParam = ReadingsVal($hash->{DEVICE}, $setModifier, "");
$aktParam = sprintf("%.1f", $aktParam) if ($isHeating && $aktParam =~ m/^[0-9]{1,3}$/i);
$newParam = sprintf("%.1f", $newParam) if ($isHeating && $newParam =~ m/^[0-9]{1,3}$/i);
...
#Kommando ausführen
if ($command && !$disabled && $activeTimer
&& $aktParam ne $newParam
...
das Kommando nur ausgeführt wird, wenn sich der Parameter (wenn er numerisch ist) ändert - was er bei einem festen Wert "23" nie tut.
Angenommen, die momentane Wunschtemp ist 23 ("desiredTemperature:23.0" vom Heizungsventil) , und im "define" der Heating_Control steht auch 23, dann wird das Kommando nie ausgeführt nach einem Absenkungswunsch, obwohl ich die Absenkung auf 21 Grad möchte. Weil "23.0" mit "23.0" verglichen wird, die Absenkung (auf 21.0) aber erst im $Command passiert, was aufgrund von $aktParam ne $newParam nicht ausgeführt wird.
Mein Trick verändert die Situation, $newParam ist "HC_Temp(23)", was nie "23.0" entspricht, somit wird immer das Kommando ausgeführt.
Eigentlich müßte man statt
my $aktParam = ReadingsVal($hash->{DEVICE}, $setModifier, "");
$aktParam = sprintf("%.1f", $aktParam) if ($isHeating && $aktParam =~ m/^[0-9]{1,3}$/i);
$newParam = sprintf("%.1f", $newParam) if ($isHeating && $newParam =~ m/^[0-9]{1,3}$/i);
doch so was wie
my $aktParam = ReadingsVal($hash->{DEVICE}, $setModifier, "");
$aktParam = cleanUpParam($aktParam);
$newParam = cleanUpParam($newParam);
mit
sub cleanupParam($) {
my ($param) =@_;
if ($param !~ m/^\d{1,3}$/)
$param = eval $param;
if ($param =~ m/^\d{1,3}$/)
return sprintf("%.1f", $aktParam);
return $param;
}
schreiben.
Wäre das eine Idee?
Das löst zwar das Problem nicht, wenn der Wert erst im Command verändert wird, aber man braucht dann das Command nicht mehr, da die BErechnung des aktuellen Werts in der Temp-Tabelle steht:
define HC_wohnzimmer Heating_Control Heizungsventil 19:20|HC_Temp(23)
und HC_Temp eine Berechnung durchführen kann, und trotzdem noch die Optimierung ($newParam eq $oldParam) funktioniert.
Bisher eben
define HC_wohnzimmer Heating_Control Heizungsventil 19:20|HC_Temp(23) { HC_setTemp($NAME, eval $EVENT);; }
Zitat von: FHEM_Starter am 21 November 2016, 08:51:12
Hallo Dietmar,
zunächst vielen Dank für dieses tolle Modul. Eine Frage allgemein zu den Conditions: Ist es richtig, dass in einem define immer nur eine Condition zulässig ist? Wenn ja, wäre es möglich, das Modul so zu optimieren, dass pro Schaltakt eine eigene Condition denkbar ist? So hätte man in einem Define alles definiert, was die Übersichtlichkeit und den WAF Faktor erhöht.
Danke und Gruß
Wolfgang
vorstellen kann ich mir das schon.
Mach mal einen Vorschlag, wie die Syntax aussehen soll. Dann kann ich mir besser vorstellen, was dir vorschwebt.
my $aktParam = ReadingsVal($hash->{DEVICE}, $setModifier, "");
$aktParam = sprintf("%.1f", $aktParam) if ($isHeating && $aktParam =~ m/^[0-9]{1,3}$/i);
$newParam = sprintf("%.1f", $newParam) if ($isHeating && $newParam =~ m/^[0-9]{1,3}$/i);
...
#Kommando ausführen
if ($command && !$disabled && $activeTimer
# && $aktParam ne $newParam
...
Man könnte die Zeile auch auskommentieren. Sogar mit einem Attriut abschalten.
Moin, Dietmar,
das tolle Modul Heating_Control benutze ich nach Abschaffung der Homematic-Raumthermostate nun sehr intensiv und dabei ist mir eine Unstimmigkeit aufgefallen, die in meinem Szenario blöde Folgen hat. Der Status des Moduls entspricht nicht immer (leider habe ich noch keine Regel gefunden) dem aktuell vom Modul geschalteten Wert. Von neun Heating_Controls habe ich heute morgen 2 "Blödmänner" gefunden. Einer davon:
Internals:
CFGFN
COMMAND
CONDITION
DEF RR_Wohnzimmer de so-sa|16:30|19 so-sa|18:00|22 $we|23:00|15 fr|23:00|15 mo-do|22:00|15
DEVICE RR_Wohnzimmer
GlobalDaylistSpec
LANGUAGE de
NAME CC.Wohnzimmer
NR 187
Profil 0: Sonntag 16:30:00 19, 18:00:00 22, 23:00:00 15
Profil 1: Montag 16:30:00 19, 18:00:00 22, 22:00:00 15
Profil 2: Dienstag 16:30:00 19, 18:00:00 22, 22:00:00 15
Profil 3: Mittwoch 16:30:00 19, 18:00:00 22, 22:00:00 15
Profil 4: Donnerstag 16:30:00 19, 18:00:00 22, 22:00:00 15
Profil 5: Freitag 16:30:00 19, 18:00:00 22, 23:00:00 15
Profil 6: Samstag 16:30:00 19, 18:00:00 22, 23:00:00 15
Profil 7: Wochenende 23:00:00 15
STATE 22
STILLDONETIME 0
TYPE Heating_Control
Readings:
2016-11-20 23:00:00 currValue 15
2016-11-20 15:09:53 disabled 0
2016-11-20 23:00:00 nextUpdate 2016-11-21 16:30:00
2016-11-20 23:00:00 nextValue 19
2016-11-20 18:00:01 state 22
SWITCHINGTIMES:
so-sa|16:30|19
so-sa|18:00|22
$we|23:00|15
fr|23:00|15
mo-do|22:00|15
Timer:
Cc.wohnzimmer_1:
HASH CC.Wohnzimmer
MODIFIER 1
NAME CC.Wohnzimmer_1
Cc.wohnzimmer_2:
HASH CC.Wohnzimmer
MODIFIER 2
NAME CC.Wohnzimmer_2
Cc.wohnzimmer_3:
HASH CC.Wohnzimmer
MODIFIER 3
NAME CC.Wohnzimmer_3
Cc.wohnzimmer_4:
HASH CC.Wohnzimmer
MODIFIER 4
NAME CC.Wohnzimmer_4
Cc.wohnzimmer_5:
HASH CC.Wohnzimmer
MODIFIER 5
NAME CC.Wohnzimmer_5
Cc.wohnzimmer_settimerofday:
HASH CC.Wohnzimmer
MODIFIER SetTimerOfDay
NAME CC.Wohnzimmer_SetTimerOfDay
SETTIMERATMIDNIGHT 1
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
16:30:00 19
18:00:00 22
23:00:00 15
1:
16:30:00 19
18:00:00 22
22:00:00 15
2:
16:30:00 19
18:00:00 22
22:00:00 15
3:
16:30:00 19
18:00:00 22
22:00:00 15
4:
16:30:00 19
18:00:00 22
22:00:00 15
5:
16:30:00 19
18:00:00 22
23:00:00 15
6:
16:30:00 19
18:00:00 22
23:00:00 15
7:
23:00:00 15
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1479742200
PARA 19
TIME 16:30
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1479747600
PARA 22
TIME 18:00
TAGE:
0
1
2
3
4
5
6
3:
EPOCH 1479765600
PARA 15
TIME 23:00
TAGE:
7
4:
EPOCH 1479765600
PARA 15
TIME 23:00
TAGE:
5
5:
EPOCH 1479762000
PARA 15
TIME 22:00
TAGE:
1
2
3
4
Profile_idx:
0:
16:30:00 1
18:00:00 2
23:00:00 3
1:
16:30:00 1
18:00:00 2
22:00:00 5
2:
16:30:00 1
18:00:00 2
22:00:00 5
3:
16:30:00 1
18:00:00 2
22:00:00 5
4:
16:30:00 1
18:00:00 2
22:00:00 5
5:
16:30:00 1
18:00:00 2
23:00:00 4
6:
16:30:00 1
18:00:00 2
23:00:00 3
7:
23:00:00 3
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
disable 0
group Heizung
switchInThePast 1
verbose 0
Natürlich ist es auch möglich, dass der "Blödmann" vor der Tastatur sitzt :-)
Und weil bald Weihnachten ist, hätte ich da noch einen Wusnchzettel:
* Ein Urlaubmodus wäre toll: disable bis 23.12.2016 16:00; danach wieder zurück ins laufende Programm
* Eine Variante wäre der Partymodus wäre auch toll: Anheizen für die nächsten X Stunden, dann wieder zurück ins laufende Programm
Vielen Dank für das tolle Modul
Christian
Hallo Dietmar,
ich hatte an folgende Möglichkeit gedacht:
define Timer_EG_KU_Rollo_Fenster WeekdayTimer EG_KU_Rollo_Fenster 12345|{sunrise(+40,"06:30:40","06:59:40")}|auf (ReadingsVal("Besuch_WZI", "state", "") ne "heute")) 12345|{sunset(+40,"22:00:40","23:00:40")}|ab 6|{sunrise(+40,"07:30:40","07:59:40")}|auf (ReadingsVal("Besuch_WZI", "state", "") ne "heute")) 6|{sunset(+40,"22:00:40","23:00:40")}|ab 0|{sunrise(+40,"08:30:40","08:59:40")}|auf (ReadingsVal("Besuch_WZI", "state", "") ne "heute")) 0|{sunset(+40,"22:00:40","23:00:40")}|ab
Gruß Wolfgang
Zitat von: Dietmar63 am 21 November 2016, 09:20:33
Man könnte die Zeile auch auskommentieren. Sogar mit einem Attriut abschalten.
Jepp. Und nach dem nächsten Update ist wieder alles weg. Daher frage ich, ob das, was ich geschrieben habe,
a) sinnvoll ist, und wenn ja
b) in den Trunk mit aufgenommen werden kann.
Zitat von: FHEM_Starter am 21 November 2016, 09:38:27
Hallo Dietmar,
ich hatte an folgende Möglichkeit gedacht:
define Timer_EG_KU_Rollo_Fenster WeekdayTimer EG_KU_Rollo_Fenster 12345|{sunrise(+40,"06:30:40","06:59:40")}|auf (ReadingsVal("Besuch_WZI", "state", "") ne "heute")) 12345|{sunset(+40,"22:00:40","23:00:40")}|ab 6|{sunrise(+40,"07:30:40","07:59:40")}|auf (ReadingsVal("Besuch_WZI", "state", "") ne "heute")) 6|{sunset(+40,"22:00:40","23:00:40")}|ab 0|{sunrise(+40,"08:30:40","08:59:40")}|auf (ReadingsVal("Besuch_WZI", "state", "") ne "heute")) 0|{sunset(+40,"22:00:40","23:00:40")}|ab
Gruß Wolfgang
sieht ziemlich unübersichtlich aus - dürfte auch recht aufwendig sein es zu implementieren.
Ich würde eher dem Vorschlag von c2j2 folgen wollen
sub cleanupParam($) {
my ($param) =@_;
if ($param !~ m/^{.*}$/) # Abfrage ob Perlausdruck ...
$param = eval $param;
if ($param =~ m/^\d{1,3}$/)
return sprintf("%.1f", $aktParam);
return $param;
}
Das ließe sich leichter umseten.
ZitatDer Status des Moduls entspricht nicht immer ...
ja, das ist blöd und nicht wirklich machbar, weil das Modul immer Perlcode erzeut und nicht weiß was der Perlcode dann wirlich tut.
Ich wüde den Status am liebsten abschaffen.
Zitat
Und weil bald Weihnachten ist, hätte ich da noch einen Wusnchzettel:
* Ein Urlaubmodus wäre toll: disable bis 23.12.2016 16:00; danach wieder zurück ins laufende Programm
* Eine Variante wäre der Partymodus wäre auch toll: Anheizen für die nächsten X Stunden, dann wieder zurück ins laufende Programm
wünschen ist erlaubt, aber Wünsche gehen nicht immer in Erfüllung und schon gar nicht so zeitnah.
Das Problem Urlaubsmodus und weitere Dinge habe ich mir durch die Definition zweier HC und das Attribut
disabledCond gelöst.
Der Partymodus ist nicht realisert, weil er für mich zu selten vorkommt und es bei mir reicht wenn ich die Thermostate von Hand nachstelle.
Zu aufwendigen Änderungen werde ich in nächster Zeit nicht kommen, weil ich anderweitig beschäftigt bin.
Vielen Dank für die rasche und ehrliche Antwort. Und da ich schon groß bin, erfülle ich mir manchmal die Wünsche einfach selbst. Werde also mal Deine Anregung aufgreifen und mir da was selbst stricken.
Herzliche Grüße
Christian
Ich habe es so gelöst, dass ich einen Betriebsmodus "Automatik" habe, in dem ich eine Absenkung (in Grad) fest vorgeben kann (wenn ich wegfahre, kann ich den Modus einstellen, und ein paar Stunden, bevor ich zurückkomme, wieder auf "nein" gehen) oder per Anwesenheitserkennung automatisch betreiben kann.
Oder ich stelle auf "manuell", dann kann ich die Thermostaten eben manuell einstellen, das HC ist unwirksam.
define Var_Regelungsmodus dummy
attr Var_Regelungsmodus setList state:automatisch,voll_manuell
attr Var_Regelungsmodus webCmd state
attr Var_Regelungsmodus alias Betriebsmodus
attr Var_Regelungsmodus sortby 1
attr Var_Regelungsmodus room Wochenprogramme,Übersicht
# set Var_Regelungsmodus automatisch
define n_Var_Regelungsmodus notify Var_Regelungsmodus:.* {Heating_Control_SetAllTemps()}
define Var_TemperaturAbsenkung dummy
attr Var_TemperaturAbsenkung setList state:nein,1(Anwesenheit),2(Anwesenheit),3(Anwesenheit),4(Anwesenheit),5(Anwesenheit),1(fest),2(fest),3(fest),4(fest),5(fest)
attr Var_TemperaturAbsenkung webCmd state
attr Var_TemperaturAbsenkung alias Temperaturabsenkung
attr Var_TemperaturAbsenkung sortby 2
attr Var_TemperaturAbsenkung room Wochenprogramme,Übersicht
# set Var_TemperaturAbsenkung 2(auto)
define n_Var_TemperaturAbsenkung notify Var_TemperaturAbsenkung:.* {Heating_Control_SetAllTemps()}
define HC_Woche_wohnzimmer Heating_Control Thermostat_wohnzimmer de Mo-Fr|05:00|HC_Temp(22) Mo-Fr|06:30|HC_Temp(21) Mo-Fr|15:00|HC_Temp(22) So-Do|22:00|HC_Temp(20) Sa-So|06:00|HC_Temp(22) Fr-Sa|24:00|HC_Temp(19) {\
HC_setTemp($NAME, eval $EVENT);;\
}
und die PL-Skripte:
sub HC_Temp($)
{
my $degree = $_[0];
my $value = Value("Var_TemperaturAbsenkung");
Log(2, "Var_TemperaturAbsenkung = $value");
if ($value =~ /^\d+/)
{
if ($value =~ /Anwesenheit/)
{
Log(2, " auto: " . Value("Var_JemandAnwesend"));
if (Value("Var_JemandAnwesend") == 0)
{
Log(1, "DEGREE = ". $degree . " - " . $value);
return max($degree - $value, 16);
}
}
else
{
return max($degree - $value, 16);
}
}
return($degree);
}
sub HC_setTemp($$)
{
my ($Device, $degree) = @_;
my $OldTemp = ReadingsVal($Device, "desiredTemperature", "0");
Log(2, "********************HC_setTemp(): set $degree deg in $Device. Was: $OldTemp");
if ($degree < $OldTemp || $degree > $OldTemp) # no "!=" as it would compare strings
{
if (Value("Var_Regelungsmodus") eq "automatisch")
{
Log(1, "FHEM/Heating_Control: set $Device desiredTemperature $degree");
fhem("set $Device desiredTemperature $degree");
return 1;
}
Log(2, "FHEM/Heating_Control disabled by 'Var_Regelungsmodus'!='automatisch'");
}
return 0;
}
Damit bin ich vorerst glücklich, und ein Datum vorgeben ist komplizierter, als es "von Hand" zu machen.
Zitat von: Christian72D am 25 Oktober 2016, 16:49:59
Ich habe seit ein paar Tagen ein Problem mit dem Modul HCS: nach einem Reboot ist es nicht mehr aktiv, das war es Anfang des Jahres aber noch.
Kann sowas durch ein Update gekommen sein?
Und wie kann ich das SO einstellen daß es automatisch läuft?
KEINER eine Idee?
Du musst schon ein wenig mehr erklären, wie du mit dem Modul was machst.
Versuch mal die betroffenen Geräte auf verbose 5 zu stellen
Hallo Dietmar,
kannst Du mit bitte einen Tipp geben, warum eine Definition mit on-till nicht klappt?
Mit der Def:
define shutter WeekdayTimer UG_AZ_Licht_Schrank FR-SA|11:32|on-till:11:33:00 FR-SA|11:02|off
erhalte ich im LogFile
on-till requires parameter: -time-
Ich steh auf dem Schlauch ...
Gruß Wolfgang
Liefere bitte mal den output des Logs wenn du verbose 5 eingeschaltet hast
Hallo Dietmar,
das ist das Ergebnis der Definition aus dem Logfile.
Gruß Wolfgang
2016.12.03 12:54:21 5: Cmd: >define shutter WeekdayTimer UG_AZ_Licht_Schrank FR-SA|12:55|on-till:12:56:00 FR-SA|12:57|off<
2016.12.03 12:54:21 5: [shutter] FR-SA|12:55|on-till:12:56:00 - trying to accept as a switchtime
2016.12.03 12:54:21 4: [shutter] FR-SA|12:55|on-till:12:56:00 - accepted
2016.12.03 12:54:21 5: [shutter] FR-SA|12:57|off - trying to accept as a switchtime
2016.12.03 12:54:21 4: [shutter] FR-SA|12:57|off - accepted
2016.12.03 12:54:21 5: Compute sunrise/sunset for latitude 49.9142 , longitude 8.2133
2016.12.03 12:54:21 5: Compute sunrise/sunset for latitude 49.9142 , longitude 8.2133
2016.12.03 12:54:21 4: [shutter] 07:30:45 17:04:55 Samstag
2016.12.03 12:54:21 4: [shutter] 12:55:00 on-till:12:56:00, 12:57:00 off (Profil 5: Freitag)
2016.12.03 12:54:21 4: [shutter] 12:55:00 on-till:12:56:00, 12:57:00 off (Profil 6: Samstag)
2016.12.03 12:54:21 5: [shutter] setting Timer: shutter_SetTimerOfDay 2016-12-04 00:00:05
2016.12.03 12:54:21 5: Triggering global (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for global, first event DEFINED shutter
2016.12.03 12:54:21 4: [shutter] device type CUL_HM:HM-LC-SW1-FM recognized, setModifier:
2016.12.03 12:54:21 4: [shutter] no switch in the yesterdays because of the devices type(UG_AZ_Licht_Schrank is not recognized as heating) - use attr switchInThePast
2016.12.03 12:54:21 5: Triggering shutter (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for shutter, first event inactive
2016.12.03 12:54:21 4: [shutter] condition: - Tage:5,6
2016.12.03 12:54:21 5: [shutter] condition: {my $days={};;map{$days->{$_}=1}(5,6);;;;( 1 && (defined $days->{$wday}))}
2016.12.03 12:54:21 5: Cmd: >{my $days={};map{$days->{$_}=1}(5,6);;( 1 && (defined $days->{$wday}))}<
2016.12.03 12:54:21 5: [shutter] result of condition:1
2016.12.03 12:54:21 5: Triggering shutter (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for shutter, first event active
2016.12.03 12:54:21 4: [shutter] setTimer - timer seems to be active today: 56|12:55|on-till:12:56:00
2016.12.03 12:54:21 5: [shutter] setting Timer: shutter_1 2016-12-03 12:55:00
2016.12.03 12:54:21 4: [shutter] condition: - Tage:5,6
2016.12.03 12:54:21 5: [shutter] condition: {my $days={};;map{$days->{$_}=1}(5,6);;;;( 1 && (defined $days->{$wday}))}
2016.12.03 12:54:21 5: Cmd: >{my $days={};map{$days->{$_}=1}(5,6);;( 1 && (defined $days->{$wday}))}<
2016.12.03 12:54:21 5: [shutter] result of condition:1
2016.12.03 12:54:21 5: Triggering shutter (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for shutter, first event active
2016.12.03 12:54:21 4: [shutter] setTimer - timer seems to be active today: 56|12:57|off
2016.12.03 12:54:21 5: [shutter] setting Timer: shutter_2 2016-12-03 12:57:00
2016.12.03 12:54:21 5: Triggering shutter (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for shutter, first event nextUpdate: 2016-12-03 12:55:00
2016.12.03 12:54:21 5: Triggering shutter (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for shutter, first event nextValue: on-till:12:56:00
2016.12.03 12:54:21 5: Triggering shutter (1 changes)
2016.12.03 12:54:21 5: Starting notify loop for shutter, first event currValue: off
2016.12.03 12:54:21 4: WEB_192.168.17.24_54871 GET /fhem?detail=shutter&fw_id=5073; BUFLEN:0
2016.12.03 12:54:21 4: name: /fhem?detail=shutter&fw_id=5073 / RL:3775 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.03 12:54:21 4: WEB_192.168.17.24_54871 GET /fhem?cmd={ReadingsVal(%22shutter%22,%22disable%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.03 12:54:21 5: Cmd: >{ReadingsVal("shutter","disable","")}<
Hast du auch den Teil des Protokolls verfügbar, in dem on-till dann nicht funktioniert hat: 12:56
Upps, das hatte ich übersehen.
Bitte sehr.
2016.12.03 12:55:00 4: [shutter] time=12:55/1480766100 delay=0, nextDelay=60, nextRetry=1480766160
2016.12.03 12:55:00 4: [shutter] delayedExecutionCond:0
2016.12.03 12:55:00 4: [shutter] result of delayedExecutionCond:0
2016.12.03 12:55:00 4: [shutter] list of window sensors found: 'shutter'
2016.12.03 12:55:00 4: [shutter] condition: - Tage:5,6
2016.12.03 12:55:00 5: [shutter] condition: {my $days={};;map{$days->{$_}=1}(5,6);;;;( 1 && (defined $days->{$wday}))}
2016.12.03 12:55:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(5,6);;( 1 && (defined $days->{$wday}))}<
2016.12.03 12:55:00 5: [shutter] result of condition:1
2016.12.03 12:55:00 4: [shutter] Update - timer seems to be active today: 56|12:55|on-till:12:56:00
2016.12.03 12:55:00 4: [shutter] device type CUL_HM:HM-LC-SW1-FM recognized, setModifier:
2016.12.03 12:55:00 4: [shutter] aktParam: newParam:on-till:12:56:00 - is not disabled
2016.12.03 12:55:00 4: [shutter] command: 'set $NAME $EVENT' executed with %NAME=>UG_AZ_Licht_Schrank,%EVENT=>on-till 12 56 00
2016.12.03 12:55:00 5: Cmd: >set $NAME $EVENT<
2016.12.03 12:55:00 3: on-till requires parameter: -time-
2016.12.03 12:55:00 5: Triggering shutter (4 changes)
2016.12.03 12:55:00 5: Starting notify loop for shutter, first event nextUpdate: 2016-12-03 12:57:00
Ich glaube ich kann da was machen, damit on-till funktioniert
Hallo Dietmar,
das wäre klasse. Gebe Bescheid, wenn ich was testen soll.
Gruß Wolfgang
eingecheckt:
98_Heating_Control, 98_WeekdayTimer:
- a bug fixed when starting a WDT or a HC an trying to switch in the past.
- now being able to use on-till:13:30:30 as a parameter
- the parameter can now be a Perlcode
Hallo Dietmar,
zunächst Danke für Deine Arbeit. Ich habe es getestet und es kam folgendes heraus: Einschalten geht doch das Ausschalten bleibt aus. Setze ich auf dem Device das attribut on-till manuell, klappt es. Anbei der Auszug aus dem Logfile. Hast Du dafür eine Erklärung?
Danke und Gruß
Wolfgang
Definition war:
define shutter WeekdayTimer UG_AZ_Licht_Schrank MO-DI|13:16|on-till:13:17 FR-SA|13:00|off
LogFile kam:
2016.12.05 13:15:06 5: Cmd: >define shutter WeekdayTimer UG_AZ_Licht_Schrank MO-DI|13:16|on-till:13:17 FR-SA|13:00|off<
2016.12.05 13:15:06 5: [shutter] MO-DI|13:16|on-till:13:17 - trying to accept as a switchtime
2016.12.05 13:15:06 4: [shutter] MO-DI|13:16|on-till:13:17 - accepted
2016.12.05 13:15:06 5: [shutter] FR-SA|13:00|off - trying to accept as a switchtime
2016.12.05 13:15:06 4: [shutter] FR-SA|13:00|off - accepted
2016.12.05 13:15:06 5: Compute sunrise/sunset for latitude 49.9142 , longitude 8.2133
2016.12.05 13:15:06 5: Compute sunrise/sunset for latitude 49.9142 , longitude 8.2133
2016.12.05 13:15:06 4: [shutter] 07:32:56 17:04:21 Montag
2016.12.05 13:15:06 4: [shutter] 13:16:00 on-till:13:17 (Profil 1: Montag)
2016.12.05 13:15:06 4: [shutter] 13:16:00 on-till:13:17 (Profil 2: Dienstag)
2016.12.05 13:15:06 4: [shutter] 13:00:00 off (Profil 5: Freitag)
2016.12.05 13:15:06 4: [shutter] 13:00:00 off (Profil 6: Samstag)
2016.12.05 13:15:06 5: [shutter] setting Timer: shutter_SetTimerOfDay 2016-12-06 00:00:05
2016.12.05 13:15:06 5: Triggering global (1 changes)
2016.12.05 13:15:06 5: Starting notify loop for global, first event DEFINED shutter
2016.12.05 13:15:06 4: [shutter] device type CUL_HM:HM-LC-SW1-FM recognized, setModifier:
2016.12.05 13:15:06 4: [shutter] no switch in the yesterdays because of the devices type(UG_AZ_Licht_Schrank is not recognized as heating) - use attr switchInThePast
2016.12.05 13:15:06 5: Triggering shutter (1 changes)
2016.12.05 13:15:06 5: Starting notify loop for shutter, first event inactive
2016.12.05 13:15:06 4: [shutter] condition: - Tage:1,2
2016.12.05 13:15:06 5: [shutter] condition: {my $days={};;map{$days->{$_}=1}(1,2);;;;( 1 && (defined $days->{$wday}))}
2016.12.05 13:15:06 5: Cmd: >{my $days={};map{$days->{$_}=1}(1,2);;( 1 && (defined $days->{$wday}))}<
2016.12.05 13:15:06 5: [shutter] result of condition:1
2016.12.05 13:15:06 5: Triggering shutter (1 changes)
2016.12.05 13:15:06 5: Starting notify loop for shutter, first event active
2016.12.05 13:15:06 4: [shutter] setTimer - timer seems to be active today: 12|13:16|on-till:13:17
2016.12.05 13:15:06 5: [shutter] setting Timer: shutter_1 2016-12-05 13:16:00
2016.12.05 13:15:06 4: [shutter] condition: - Tage:5,6
2016.12.05 13:15:06 5: [shutter] condition: {my $days={};;map{$days->{$_}=1}(5,6);;;;( 1 && (defined $days->{$wday}))}
2016.12.05 13:15:06 5: Cmd: >{my $days={};map{$days->{$_}=1}(5,6);;( 1 && (defined $days->{$wday}))}<
2016.12.05 13:15:06 5: [shutter] result of condition:
2016.12.05 13:15:06 5: Triggering shutter (1 changes)
2016.12.05 13:15:06 5: Starting notify loop for shutter, first event nextUpdate: 2016-12-05 13:16:00
2016.12.05 13:15:06 5: Triggering shutter (1 changes)
2016.12.05 13:15:06 5: Starting notify loop for shutter, first event nextValue: on-till:13:17
2016.12.05 13:15:06 5: Triggering shutter (1 changes)
2016.12.05 13:15:06 5: Starting notify loop for shutter, first event currValue: off
2016.12.05 13:15:06 4: WEB_192.168.17.24_52021 GET /fhem?cmd={ReadingsVal(%22shutter%22,%22disable%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.05 13:15:06 5: Cmd: >{ReadingsVal("shutter","disable","")}<
2016.12.05 13:15:06 4: name: /fhem?cmd={ReadingsVal(%22shutter%22,%22disable%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.05 13:15:06 4: WEB_192.168.17.24_52021 GET /fhem?cmd={AttrVal(%22shutter%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.05 13:15:06 5: Cmd: >{AttrVal("shutter","room","")}<
2016.12.05 13:15:06 4: name: /fhem?cmd={AttrVal(%22shutter%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.05 13:16:00 4: [shutter] time=13:16/1480940160 delay=0, nextDelay=60, nextRetry=1480940220
2016.12.05 13:16:00 4: [shutter] delayedExecutionCond:0
2016.12.05 13:16:00 4: [shutter] result of delayedExecutionCond:0
2016.12.05 13:16:00 4: [shutter] list of window sensors found: 'shutter'
2016.12.05 13:16:00 4: [shutter] condition: - Tage:1,2
2016.12.05 13:16:00 5: [shutter] condition: {my $days={};;map{$days->{$_}=1}(1,2);;;;( 1 && (defined $days->{$wday}))}
2016.12.05 13:16:00 5: Cmd: >{my $days={};map{$days->{$_}=1}(1,2);;( 1 && (defined $days->{$wday}))}<
2016.12.05 13:16:00 5: [shutter] result of condition:1
2016.12.05 13:16:00 4: [shutter] Update - timer seems to be active today: 12|13:16|on-till:13:17
2016.12.05 13:16:00 4: [shutter] device type CUL_HM:HM-LC-SW1-FM recognized, setModifier:
2016.12.05 13:16:00 4: [shutter] aktParam: newParam:on-till:13:17 - is not disabled
2016.12.05 13:16:00 4: [shutter] command: 'set $NAME $EVENT' executed with %NAME=>UG_AZ_Licht_Schrank,%EVENT=>on-till 13:17
Hallo Dietmar,
ein weiteres und viel größeres Problem ist aufgetreten: Es werden keine Bedingungen mehr richtig ausgeführt.
Beispiel:
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off (ReadingsVal("Grillen", "state", "") ne "heute")
oder auch
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off ([Grillen:state] ne "heute")
oder auch
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off ({ReadingsVal("Grillen", "state", "") ne "heute"})
werden nicht geschaltet.
Bitte um Hilfe.
Gruß Wolfgang
Bei allen dreien ist die Syntax falsch
ich sehe den Wald vor lauter Bäumen nicht mehr :-[
Wie soll denn die korrekte Syntax sein???
Merci Wolfgang
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off (ReadingsVal("Grillen", "state", "") ne "heute")
dies sollte klappen
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off ([Grillen:state] ne "heute")
Syntax aus DOIF funktioniert hier nicht
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off ({ReadingsVal("Grillen", "state", "") ne "heute"})
Bedingung mit {} funktionieren nicht
wie sieht denn der output mit verbose 5 aus
Hallo Dietmar,
danke für Deine Tipps, wenn ich auch keinen Unterschied zu Deinem und zu meinem ersten Eintrag sehen konnte. Aber egal ...
Was ich jedoch herausgefunden habe ist, dass sich zwischen dem Befehl (hier "on") und dem nächsten Schalt-Tag (hier "FR-SA") ein Leerzeichen zuviel eingeschlichen hat. Ein Fehler, der nur sehr schwer zu erkennen ist. Sichtbar wurde dieser im Logfile mit dem Eintrag "Unknown argument on ,". Das Leerzeichen hinter "on" brachte mich darauf.
Vielleicht kannst Du bei Gelegenheit Deinen Parser ein weiteres Stück Fehlertoleranz gönnen.
Nochmals Danke für Deine Benühungen,
Wolfgang
P.S. Das Problem mit dem nicht Ausschaltens des on-till hat sich damit auch erledigt. War die gleiche Ursache ...
Hallo zusammen,
ich habe gestern mal wieder ein Update durchgeführt. Und nun funktioniert meine Heizungssteuerung nicht mehr, da das Heating_Control jetzt Werte mit einer Nachkommastelle ausgibt. Da aber meine Thermostate (Z-Wave) nur ganze Gradzahlen verstehen, kommt es regelmäßig zu einem Fehler:
defmod hc.og.ba.WT Heating_Control dm.og.ba.Heizwert de Mo-Fr|{Value("dmBadStartHeizung")}|25 Mo-Fr|06:35|18 Mo-Fr|11:00|18 Mo-Fr|19:30|18 {\
if ((!iswe())) {\
HeizungStellen($NAME,$EVENT);;\
}\
}
setstate hc.og.ba.WT 18.0
setstate hc.og.ba.WT 2016-12-09 11:00:00 currValue 18
setstate hc.og.ba.WT 2016-12-09 11:00:00 nextUpdate 2016-12-09 19:30:00
setstate hc.og.ba.WT 2016-12-09 11:00:00 nextValue 18
setstate hc.og.ba.WT 2016-12-09 11:00:00 state 18.0
Kurios ist, dass in der Definition selbst keine Nachkommastelle angegeben ist, und auch in den Readings "currValue" bzw-. "nextValue" keine Nachkommastellen ausgegeben werden. M. E. sollte die Anzeige einheitlich sein. Kann man das noch mit nem Attribut einstellen (stateFormat ginge zur Not, allerdings müsste dann noch bei gemischten Inhalten umfangreichere Abfragen getätigt werden)? Auf welches Reading muss ich mich hierbei beziehen? Generell wäre es schön, wenn die Ausgabe 1:1 wie in der Definition angegeben erfolgen würde (mal vom Perl-Code abgesehen). ;)
Viele Grüße
Michael
Kannst du mal ein list von deinem zwave machen.
Bitte auch mal ein Log mit verbose 5 hier veröffentlichen.
Zitat
Code: [Auswählen]
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off (ReadingsVal("Grillen", "state", "") ne "heute")
dies sollte klappen
dies halte ich für richtig
Hi Liebe FHEM-Community,
ich nutzte seit ein paar Wochen HeatingControl, dabei kann ich mir die Schaltzeiten am Freitag (siehe Anhang) nicht erklären, ich dachte 6 und 7 gelten für Samstag und Sonntag. ???
Habe ich was falsch eingestellt ? :o
Mfg
Philipp
Bitte die Definition als Text hierher kopieren
@Dietmar63
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off (ReadingsVal("Grillen", "state", "") ne "heute")
Wofür stehen die beiden "" hinter state ?
In manchen Beispielen stehe dazwischen Werte o.ä.
LG
Tom
Zitat von: Dietmar63 am 20 Dezember 2016, 06:51:44
Bitte die Definition als Text hierher kopieren
Hier Bitteschön: ;D
#Heizungs-Steuerung
define HCB Heating_Control Heizung_Clima 12345|05:30|21 15|14:30|21 2|15:20|21 3|16:50|21 4|14:45|21 67|06:30|21 67|08:00|21 (ReadingsVal("HCAutomatik", "state", "") eq "on")
attr HCB icon hue_room_garage
define HCAutomatik dummy
attr HCAutomatik alias Heizungsautomatik
attr HCAutomatik devStateIcon on:general_an off:general_aus
attr HCAutomatik icon sani_heating_automatic
attr HCAutomatik webCmd on:off
Wp liegt der Fehler? :(
Zitat von: tomspatz am 20 Dezember 2016, 09:57:54
@Dietmar63
define shutter WeekdayTimer UG_AZ_Licht_Schrank MI|11:01|on FR-SA|13:00|off (ReadingsVal("Grillen", "state", "") ne "heute")
Wofür stehen die beiden "" hinter state ?
In manchen Beispielen stehe dazwischen Werte o.ä.
LG
Tom
Den Wert liefert die Funktion zurück wenn sie mit denvorherigen Parameter nichts findet
Zitat von: EnderPhilipp am 20 Dezember 2016, 17:37:25
Hier Bitteschön: ;D
#Heizungs-Steuerung
define HCB Heating_Control Heizung_Clima 12345|05:30|21 15|14:30|21 2|15:20|21 3|16:50|21 4|14:45|21 67|06:30|21 67|08:00|21 (ReadingsVal("HCAutomatik", "state", "") eq "on")
attr HCB icon hue_room_garage
define HCAutomatik dummy
attr HCAutomatik alias Heizungsautomatik
attr HCAutomatik devStateIcon on:general_an off:general_aus
attr HCAutomatik icon sani_heating_automatic
attr HCAutomatik webCmd on:off
Was ist denn jetzt falsch, dass er Freitags, die Samstags- und Sonntags-Schaltzeiten schaltet ??
ZitatDen Wert liefert die Funktion zurück wenn sie mit den vorherigen Parameter nichts findet
d.h. wenn zu der Schaltzeit "state" von "Grillen" nicht gefunden wird wird "" ausgeführt ?
In diesem Fall sich HC "aufhängt" oder den Befehl zur Schaltzeit nicht ausführt ?
Dann wäre nach meinem Verständnis dieser Wert eigentlich NUR einzusetzen wenn der Wert vom "Grillen" dynamisch erzeugt wird und schon mal fehlen könnte.
Zitat
.h. wenn zu der Schaltzeit "state" von "Grillen" nicht gefunden wird wird "" ausgeführt ?
Der Rückgabewert wird nur beim Vergleich mit on verwendet
Absturz kann eigentlich nicht stattfinden.
Zitat von: EnderPhilipp am 20 Dezember 2016, 06:19:34
Hi Liebe FHEM-Community,
ich nutzte seit ein paar Wochen HeatingControl, dabei kann ich mir die Schaltzeiten am Freitag (siehe Anhang) nicht erklären, ich dachte 6 und 7 gelten für Samstag und Sonntag. ???
Habe ich was falsch eingestellt ? :o
Mfg
Philipp
... if ($d==7); # sa,so ( $we)
... if ($d==8); # mo-fr (!$we)
ich hoffe das geht aus der Doku auch hervor.
Besser die symbolischen Konstanten nutzen : so,mo, ... $we !$we
Zitat von: Dietmar63 am 22 Dezember 2016, 19:02:43
... if ($d==7); # sa,so ( $we)
... if ($d==8); # mo-fr (!$we)
ich hoffe das geht aus der Doku auch hervor.
Besser die symbolischen Konstanten nutzen : so,mo, ... $we !$we
Danke, das hat geklappt ;D
ZitatDer Rückgabewert wird nur beim Vergleich mit on verwendet
Dann ist das in der Doku aber schräg??
define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
Die zu setzende Temperatur wird nur gesetzt, falls die Dummy Variable WeAreThere = "yes" ist.Wenn dann die Dummy Variable "Klaus, Bett, Grillen, ja, nein" sein sollte, ist diese Angabe doch überflüssig?
Hallo Leute,
ich habe ein Heating_Control device definiert, das mein Büro ("homeoffice") mit einem PID_20 und einem FHT Thermostaten zeitabhängig heizen soll:
defmod HC.Buero Heating_Control PID.Buero !$we|15:00|20 $we|10:00|21 0123456|21:00|17 set $NAME desired $EVENT
attr HC.Buero alias Buero
attr HC.Buero disable 0
attr HC.Buero group Heizplan
attr HC.Buero room Buero,Heizung
attr HC.Buero verbose 3
setstate HC.Buero 20.0
setstate HC.Buero 2017-01-04 19:35:50 currValue 20
setstate HC.Buero 2017-01-04 19:34:27 disabled 0
setstate HC.Buero 2017-01-04 19:35:50 nextUpdate 2017-01-04 21:00:00
setstate HC.Buero 2017-01-04 19:35:50 nextValue 17
setstate HC.Buero 2017-01-04 19:35:50 state 20.0
Jetzt hätte ich erwartet, dass das lezte regex um 21:00 mit 17 Grad auch für den nächsten Morgen gilt. Da heizt er aber auf 20 Grad auf.
Sobald ich aber in die Definition reingehe und ohne zu ändern abspeichere, springt es auf 17 Grad!??
Was ist da faul und wie kann ich das ändern?
Danke und Gruß
Ludwig
Zitat
Jetzt hätte ich erwartet, dass das lezte regex um 21:00 mit 17 Grad auch für den nächsten Morgen gilt. Da heizt er aber auf 20 Grad auf.
Sobald ich aber in die Definition reingehe und ohne zu ändern abspeichere, springt es auf 17 Grad!??
Ich kann dir noch nicht so ganz folgen:
Wenn ich die Definition bei mir eingebe kommen folgende Schaltzeiten:
Profil 0: Sonntag 10:00:00 21, 21:00:00 17
Profil 1: Montag 15:00:00 20, 21:00:00 17
Profil 2: Dienstag 15:00:00 20, 21:00:00 17
Profil 3: Mittwoch 15:00:00 20, 21:00:00 17
Profil 4: Donnerstag 15:00:00 20, 21:00:00 17
Profil 5: Freitag 15:00:00 20, 21:00:00 17
Profil 6: Samstag 10:00:00 21, 21:00:00 17
Profil 7: Wochenende 10:00:00 21
Profil 8: Werktags 15:00:00 20
am Mittwoch ist um 19:35 die Temperatur 20 um 21Uhr wird auf 17 gestellt und weil am Donnerstag auch kein Feiertag gilt wird um 15 Uhr wieder auf 20 Grad gestellt .
Hallo Dietmar,
erst einmal vielen Dank für die gute Arbeit an den Modulen, klappt wirklich super.
Allerdings habe ich ein kleines Problem mit dem Heating_Control.
Beim Start von FHEM wirft er folgenden Fehler im Log aus:
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <!$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <!$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <!$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <!$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
2017.01.17 11:48:06 1: [Heizplan_Wohnzimmer] invalid daylist in Heizplan_Wohnzimmer <$we> use one of 012345678 or (so|mo|di|mi|do|fr|sa|$we|!$we)
Hier meine Konfiguration:
define Heizplan_Wohnzimmer Heating_Control MAX_14ce9b \
!$we|00:00|16.5 !$we|00:05|5 !$we|05:30|16.5 !$we|14:00|23 !$we|16:00|21 !$we|22:00|16.5 \
$we|00:00|16.5 $we|00:05|16.5 $we|08:30|23 $we|12:00|21 $we|23:00|16.5
attr Heizplan_Wohnzimmer disable 0
attr Heizplan_Wohnzimmer group Heizplan
attr Heizplan_Wohnzimmer room Heizung
attr Heizplan_Wohnzimmer switchInThePast 0
Switchen tut er die Temperaturen korrekt, auch wenn für das Modul jeden Tag $we auf 1 steht (obwohl beim abrufen der FHEM Funktion der korrekte Wert geliefert wird).
Problematisch wird es allerdings bei einem Neustart mit disable 0 bzw. einer Automatisierung mit Anwesenheit, weil ich mit Heating_Control_SetAllTemps() grundsätzlich alle $we Werte auf die Thermostate gebügelt kriege.
Hast du vielleicht eine Idee, wie man das gelöst bekommt?
Viele Grüße,
dcent
EDIT:
Hab's mal auf verbose 5 laufen lassen, vielleicht hilft dir das eher weiter, beim Start von FHEM kommt Folgendes im Log:
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_6
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_4
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_11
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_5
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] device type heating recognized, setModifier:desiredTemperature
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] Heating recognized - switch in the past activated
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday}))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:7
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:0
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:7
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:0
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] setTimer - timer seems to be NOT active today: 7|23:00|16.5
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_11 2017-01-17 23:00:00
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:8
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || !$we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:1
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:8
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || !$we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:1
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:8
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || !$we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:1
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] setTimer - timer seems to be active today: 8|14:00|23
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_4 2017-01-17 14:00:00
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:8
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || !$we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:1
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] setTimer - timer seems to be active today: 8|16:00|21
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_5 2017-01-17 16:00:00
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:8
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || !$we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:1
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] setTimer - timer seems to be active today: 8|22:00|16.5
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_6 2017-01-17 22:00:00
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday}))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:7
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:0
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] condition: - Tage:7
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] result of condition:0
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] time=12:00/1484650800 delay=717, nextDelay=780, nextRetry=1484651580
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] delayedExecutionCond:0
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] result of delayedExecutionCond:0
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] list of window sensors found: 'Heizplan_Wohnzimmer'
2017.01.17 12:11:57 4: [Heizplan_Wohnzimmer] past timer on MAX_14ce9b at 2017-01-17 12:00:00 with 21 activated
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_delayed
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_delayed 2017-01-17 12:12:02
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_delayed
2017.01.17 12:11:57 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_delayed 2017-01-17 12:12:02
2017.01.17 12:12:02 4: MAX_14ce9b 2017-01-17 12:00:00 722s
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_10 2017-01-17 12:00:00
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] removing Timer: Heizplan_Wohnzimmer_10
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] setting Timer: Heizplan_Wohnzimmer_10 2017-01-17 12:00:00
2017.01.17 12:12:02 4: MAX_16f920 2017-01-17 12:00:00 722s
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] device type heating recognized, setModifier:desiredTemperature
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] time=12:00/1484650800 delay=722, nextDelay=780, nextRetry=1484651580
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] delayedExecutionCond:0
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] result of delayedExecutionCond:0
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] list of window sensors found: 'Heizplan_Wohnzimmer'
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] condition: - Tage:7,8
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we || !$we))}
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] result of condition:1
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] condition: - Tage:7
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] condition: {my $days={};;map{$days->{$_}=1}();;;;( 1 && (defined $days->{$wday} || $we))}
2017.01.17 12:12:02 5: [Heizplan_Wohnzimmer] result of condition:0
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] Update - past timer activated
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] device type heating recognized, setModifier:desiredTemperature
2017.01.17 12:12:02 4: [Heizplan_Wohnzimmer] aktParam:21.0 newParam:21.0 - is disabled
Ist es irgendwie möglich 2 gleiche Thermostate über einen Heizplan zu steuern?
Habe 2 Heizkörper in einem Raum die logischerweise gleich laufen sollen.
Jedenfalls finde ich das logisch :)
"SchlafzimmerThermostat1,SchlafzimmerThermostat2" als Device ist nicht möglich.
Warum nicht
Keine ahnung, habs probiert, geht nicht.
Die Temperaturen werden nicht umgeschaltet.
Beim anlegen steht auch im log was von, device nicht erkannt aber trotzdem angenommen.
2017.01.29 10:25:44 3: [SchlafzimmerHeizplan] device <SchlafzimmerThermostat1,SchlafzimmerThermostat2> in fhem not defined, but accepted
Schalte mal verbose 5 ein
Schaltbefehle werden abgesetzt, aber leider die falschen
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] removing Timer: SchlafzimmerHeizplan_2
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] 0123456|07:00|16 - trying to accept as a switchtime
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 0123456|07:00|16 - accepted
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] 0123456|21:00|18 - trying to accept as a switchtime
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 0123456|21:00|18 - accepted
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", - unbalanced brackets ():2
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", - unbalanced brackets ():2
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") - unbalanced brackets ():1
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq - unbalanced brackets ():1
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq "on") - trying to accept as a switchtime
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq "on") - NOT accepted, must be command or condition
2017.02.26 09:25:51 3: [SchlafzimmerHeizplan] device <SchlafzimmerThermostat1,SchlafzimmerThermostat2> in fhem not defined, but accepted
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 06:43:52 18:27:58 Sonntag
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 0: Sonntag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 1: Montag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 2: Dienstag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 3: Mittwoch)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 4: Donnerstag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 5: Freitag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 6: Samstag)
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] removing Timer: SchlafzimmerHeizplan_SetTimerOfDay
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] setting Timer: SchlafzimmerHeizplan_SetTimerOfDay 2017-02-27 00:00:05
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] no switch in the yesterdays because of the devices type(SchlafzimmerThermostat1,SchlafzimmerThermostat2 is not recognized as heating) - use attr switchInThePast
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] condition:(ReadingsVal("HCAutomatik", "state", "") eq "on") - Tage:0,1,2,3,4,5,6
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday}))}
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] result of condition:1
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] condition:(ReadingsVal("HCAutomatik", "state", "") eq "on") - Tage:0,1,2,3,4,5,6
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday}))}
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] result of condition:1
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] setTimer - timer seems to be active today: 0123456|21:00|18
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] setting Timer: SchlafzimmerHeizplan_2 2017-02-26 21:00:00
Also hab mal verbose 5 eingeschaltet.
Ich seh das Problem jetzt selbst leider nicht .. :(
Zitat von: lenn1 am 26 Februar 2017, 09:27:31
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] removing Timer: SchlafzimmerHeizplan_2
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] 0123456|07:00|16 - trying to accept as a switchtime
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 0123456|07:00|16 - accepted
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] 0123456|21:00|18 - trying to accept as a switchtime
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 0123456|21:00|18 - accepted
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", - unbalanced brackets ():2
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", - unbalanced brackets ():2
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") - unbalanced brackets ():1
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq - trying to accept as a switchtime
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq - unbalanced brackets ():1
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq "on") - trying to accept as a switchtime
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] (ReadingsVal("HCAutomatik", "state", "") eq "on") - NOT accepted, must be command or condition
2017.02.26 09:25:51 3: [SchlafzimmerHeizplan] device <SchlafzimmerThermostat1,SchlafzimmerThermostat2> in fhem not defined, but accepted
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 06:43:52 18:27:58 Sonntag
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 0: Sonntag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 1: Montag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 2: Dienstag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 3: Mittwoch)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 4: Donnerstag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 5: Freitag)
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] 07:00:00 16, 21:00:00 18 (Profil 6: Samstag)
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] removing Timer: SchlafzimmerHeizplan_SetTimerOfDay
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] setting Timer: SchlafzimmerHeizplan_SetTimerOfDay 2017-02-27 00:00:05
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] no switch in the yesterdays because of the devices type(SchlafzimmerThermostat1,SchlafzimmerThermostat2 is not recognized as heating) - use attr switchInThePast
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] condition:(ReadingsVal("HCAutomatik", "state", "") eq "on") - Tage:0,1,2,3,4,5,6
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday}))}
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] result of condition:1
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] condition:(ReadingsVal("HCAutomatik", "state", "") eq "on") - Tage:0,1,2,3,4,5,6
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("HCAutomatik", "state", "") eq "on") && (defined $days->{$wday}))}
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] result of condition:1
2017.02.26 09:25:51 4: [SchlafzimmerHeizplan] setTimer - timer seems to be active today: 0123456|21:00|18
2017.02.26 09:25:51 5: [SchlafzimmerHeizplan] setting Timer: SchlafzimmerHeizplan_2 2017-02-26 21:00:00
Also hab mal verbose 5 eingeschaltet.
Ich seh das Problem jetzt selbst leider nicht .. :(
Ok habs glaube ich hinbekommen.
Musste das command Template etwas ändern.
set $NAME desired-temp $EVENT
Ich werde die automatische Anlage des Template nochmals verbessern
Danke!
noch eine Frage:
Habe Fensterkontakte und ich lasse die Heizung herunterregeln bei öffnen auf 4°C. (ist das niedrigste bei meinen Thermostaten).
Zusätzlich eben wie im Wiki:
define Fenster.Status.Bad DOIF ([Fenster_Bad] eq "open") (set HCB disbale) DOELSE (set HCB enable)
Mein Problem ist jetzt, das wenn das Fenster wieder geschlossen wird nicht wieder die vorherige Temperatur des Heizplanes wieder aktiviert wird.
Kann man da irgendwas setzen?
Problem trat letzt auf als ich den Hund nachts rausgelassen habe. Die Temperatur im WZ war schön auf 17°C heruntergefahren und nachdem ich die Tür auf und zu gemacht habe wieder auf 20°C angehoben worden. (weil ich das eben im Notify so definier hab)
Ausserdem fiel mir auf, dass das en-und disablen jedesmal dafür sorgt, dass FHEM Änderungen speichern will.
Habe da jetzt ein "save" mit eingebaut. Finde das allerdings ein wenig unschön, wenn man an Fhem Änderungen macht und meine Leute hier dann in der Zeit die Fensterkontakte auslösen.
Grüße
Lennart
PS: Danke für das ansonsten tolle Modul ! :)
schau dir doch mal bitte das Commandref an:
ZitatdelayedExecutionCond
defines a delay Function. When returning true, the switching of the device is delayed until the function retruns a false value. The behavior is just like a windowsensor.
Example:
attr hc delayedExecutionCond isDelayed("%HEATING_CONTROL","%WEEKDAYTIMER","%TIME","%NAME","%EVENT")
the parameters %HEATING_CONTROL(timer name) %TIME %NAME(device name) %EVENT are replaced at runtime by the correct value.
Example of a function:
sub isDelayed($$$$$) {
my($hc, $wdt, $tim, $nam, $event ) = @_;
my $theSunIsStillshining = ...
return ($tim eq "16:30" && $theSunIsStillshining) ;
}
Das mit disable und enable war "damals" ein Workaround
Ok, danke für den Hinweis.
Das Wiki ist dann ja schon etwas veraltet.
Wenn das behavior just like a windowsensor ist, kann ich doch auch einfach bei windowsensor meinen hinzufügen oder?
kannst Du...lies dich doch bitte einfach ein: https://fhem.de/commandref.html#Heating_Control
Kann man dem heating control device auch mehrere geräte zuordnen?
Habe im wohnzimmer 2 Thermostate welche den gleichen Heizplan haben sollen...
man kann soweit ich weiß eine Gruppe definieren.
Dann wird die Gruppe aber nicht automatisch als Heizung erkannt.
Du kannst dann dass commandTemplate vorgeben:
attr HeizungKueche_an_wt commandTemplate set $NAME desired-temp $EVENT ;
und eventuell noch switchInThePast auf 1 setzen:
attr HeizungKueche_an_wt switchInThePast 1
Hallo zusammen,
ich habe ein Problem mit $we und Feiertagen. Heute am Karfreitag erkennt Heating_Control über $we, dass ein Feiertag ist und benutzt dann aber sowohl die Einstellungen für Freitag als auch die für das Wochenende. Ist das so gewollt?
Internals:
COMMAND { myHeatingControl($NAME,$EVENT) }
CONDITION
DEF E2.ez.HR.Heizung de Mo-Fr|06:00|comfort Mo-Fr|07:30|eco Mo-Fr|15:30|comfort Mo-Fr|00:30|eco $we|08:00|comfort $we|01:00|eco { myHeatingControl($NAME,$EVENT) }
DEVICE E2.ez.HR.Heizung
GlobalDaylistSpec
LANGUAGE de
NAME hc.01.E2.ez.HR.Heizung
NR 214
Profil 0: Sonntag 01:00:00 eco, 08:00:00 comfort
Profil 1: Montag 00:30:00 eco, 06:00:00 comfort, 07:30:00 eco, 15:30:00 comfort
Profil 2: Dienstag 00:30:00 eco, 06:00:00 comfort, 07:30:00 eco, 15:30:00 comfort
Profil 3: Mittwoch 00:30:00 eco, 06:00:00 comfort, 07:30:00 eco, 15:30:00 comfort
Profil 4: Donnerstag 00:30:00 eco, 06:00:00 comfort, 07:30:00 eco, 15:30:00 comfort
Profil 5: Freitag 00:30:00 eco, 01:00:00 eco, 06:00:00 comfort, 07:30:00 eco, 08:00:00 comfort, 15:30:00 comfort
Profil 6: Samstag 01:00:00 eco, 08:00:00 comfort
Profil 7: Wochenende 01:00:00 eco, 08:00:00 comfort
STATE nächste Schaltung: 2017-04-14 15:30:00 comfort ==> comfort
STILLDONETIME 0
TYPE Heating_Control
Readings:
2017-04-14 09:45:02 currValue comfort
2017-04-13 16:47:38 desired-temp 18.0
2017-04-13 17:02:02 disabled 0
2017-04-14 09:45:02 nextUpdate 2017-04-14 15:30:00
2017-04-14 09:45:02 nextValue comfort
2017-04-14 09:45:02 state comfort
SWITCHINGTIMES:
Mo-Fr|06:00|comfort
Mo-Fr|07:30|eco
Mo-Fr|15:30|comfort
Mo-Fr|00:30|eco
$we|08:00|comfort
$we|01:00|eco
Timer:
Hc.01.e2.ez.hr.heizung_3:
HASH hc.01.E2.ez.HR.Heizung
MODIFIER 3
NAME hc.01.E2.ez.HR.Heizung_3
Hc.01.e2.ez.hr.heizung_5:
HASH hc.01.E2.ez.HR.Heizung
MODIFIER 5
NAME hc.01.E2.ez.HR.Heizung_5
immerSchalten 1
Hc.01.e2.ez.hr.heizung_settimerofday:
HASH hc.01.E2.ez.HR.Heizung
MODIFIER SetTimerOfDay
NAME hc.01.E2.ez.HR.Heizung_SetTimerOfDay
SETTIMERATMIDNIGHT 1
Hc.01.e2.ez.hr.heizung_delayed:
HASH hc.01.E2.ez.HR.Heizung
MODIFIER delayed
NAME hc.01.E2.ez.HR.Heizung_delayed
Daynumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
Helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
Switchingtime:
0:
01:00:00 eco
08:00:00 comfort
1:
00:30:00 eco
06:00:00 comfort
07:30:00 eco
15:30:00 comfort
2:
00:30:00 eco
06:00:00 comfort
07:30:00 eco
15:30:00 comfort
3:
00:30:00 eco
06:00:00 comfort
07:30:00 eco
15:30:00 comfort
4:
00:30:00 eco
06:00:00 comfort
07:30:00 eco
15:30:00 comfort
5:
00:30:00 eco
01:00:00 eco
06:00:00 comfort
07:30:00 eco
08:00:00 comfort
15:30:00 comfort
6:
01:00:00 eco
08:00:00 comfort
7:
01:00:00 eco
08:00:00 comfort
Longdays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
Profil:
1:
EPOCH 1492142400
PARA comfort
TIME 06:00
TAGE:
1
2
3
4
5
2:
EPOCH 1492147800
PARA eco
TIME 07:30
TAGE:
1
2
3
4
5
3:
EPOCH 1492176600
PARA comfort
TIME 15:30
TAGE:
1
2
3
4
5
4:
EPOCH 1492122600
PARA eco
TIME 00:30
TAGE:
1
2
3
4
5
5:
EPOCH 1492149600
PARA comfort
TIME 08:00
TAGE:
7
6:
EPOCH 1492124400
PARA eco
TIME 01:00
TAGE:
7
Profile_idx:
0:
01:00:00 6
08:00:00 5
1:
00:30:00 4
06:00:00 1
07:30:00 2
15:30:00 3
2:
00:30:00 4
06:00:00 1
07:30:00 2
15:30:00 3
3:
00:30:00 4
06:00:00 1
07:30:00 2
15:30:00 3
4:
00:30:00 4
06:00:00 1
07:30:00 2
15:30:00 3
5:
00:30:00 4
01:00:00 6
06:00:00 1
07:30:00 2
08:00:00 5
15:30:00 3
6:
01:00:00 6
08:00:00 5
7:
01:00:00 6
08:00:00 5
Shortdays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Zeitschaltung
commandTemplate set $NAME desired-temp $EVENT
disable 0
group Heizungssteuerung
room Zentrale Steuerung
sortby 2
stateFormat nächste Schaltung: nextUpdate currValue ==> nextValue
Gruß
Torsten
Ich befürchte, dadurch dass du neben der Definition für Fr auch $we abgeben hast, wird beides geschaltet.
Intern überstehen we Angaben sonstige Angaben nicht
Hallo Dietmar,
klar gibt es Einträge für Freitag und für $we (siehe List im vorherigen Post). Ich habe erwartet, dass bei einem Feiertag, der auf einen Wochentag fällt (und damit ist ja $we gesetzt) die Wochenendeinstellungen die normalen Einstellungen überschreiben. Jetzt werden beide Einstellungen für den Freitag übernommen, was zu unsinnige Schaltungen führt.
Gruß
Torsten
Ja,
Und welche Wochentagsschaltung soll durch eine we-Angabe nicht ausgeführt werden?
Die erste, die zweite oder die dritte? Alle?
Ich habe deshalb we und !we voneinander getrennt.
Hallo Dietmar,
z.B. am Karfreitag darf m.E. keine der Wochentagsschaltungen ausgeführt werden, sondern nur alle vom "Wochenende=Feiertag".
Verstehe ich Dich aber richtig, dass man mit der Kombination von $we und !$we das von mir erwartete Verhalten erreichen kann?
Gruß
Torsten
Ich habe deshalb mehrere Profile definiert {we,!we}x{übergang, aus, ein}x{Küche, Wohnzimmer}
Zwischen denen automatisch oder per Dummy gewechselt wird.
Hallo Dietmar,
habe es jetzt mit der Kombination aus $we und !$we probiert. Das sieht für mich gut aus, der nächste Freitag wird seit heute Nacht wieder als Wochentag behandelt und der Ostermontag wird als Feiertag/Wochenende behandelt.
Beste Grüße
Torsten
BadezimmerFensterkontakt:doorWindow:.* {
if (ReadingsVal("HCAutomatik", "state", "") eq "on") {
if ((Value("BadezimmerFensterkontakt") eq "open")) {
fhem("define at_bad_fensteroffentimer at +00:02:00 set BadezimmerThermostat thermostatSetpointSet 4");
} else {
fhem("set BadezimmerThermostat thermostatSetpointSet 18");
fhem("delete at_bad_fensteroffentimer") if (defined($defs{'at_bad_fensteroffentimer'}));;;;
}
}
}
Also,
mein Problem liegt nun darin, dass die Temperatur sobald das Fenster wieder geschlossen wird, nicht auf die Heizplantemperatur gestellt wird, sondern auf eine von mir im notify definierte.
Den Fensterkontakt hab ich als Attribut drin und er meldet auch {"open","closed"}
Ich suche im Grunde eine Möglichkeit den Heizplan wieder zu starten, ähnlich wie wenn man ihn gerade definiert hat, damit die Temperaturen richtig eingestellt werden.
Grüße
Lennart
PS: Ich hab das commandref gelesen. (bevor wieder der Hinweis darauf kommt.. ::))
Hallo Toka, hallo Dietmar,
auch ich bin bisher davon ausgegangen, dass an einem Feiertag (ermittelt über eine holiday Datei) bei gesetzem $we immer die Zeiten des WeekdayTimers aus dem Wochenende ausgeführt werden.
@Dietmar: Ist es in Deinem Modul nicht möglich, die Variable $we höher zu behandeln als den $wday?
@Toka Kannst Du Deine Definition hier bitte posten?
Ich arbeite mit vielen WeekDayTimern und würde eine generische Lösung vor einem Workaround bevorzugen. Hier ein Beispiel mit dem Ergebnis, dass am Ostermontag um 06:xx Uhr geschaltet wurde.
define Timer_test WeekdayTimer UG_AZ_Licht_Schrank MO-FR|{sunrise(+40,"06:00:40","08:05:40")}|on SA|{sunrise(+40,"08:00:40","08:05:40")}|on SO|{sunrise(+40,"08:30:40","08:35:40")}|on (ReadingsVal("Besuch_WZI", "state", "") ne "heute")
Edit:
define Timer_test WeekdayTimer UG_AZ_Licht_Schrank !$we|{sunrise(+40,"06:00:40","08:05:40")}|on SA|{sunrise(+40,"08:00:40","08:05:40")}|on SO|{sunrise(+40,"08:30:40","08:35:40")}|on (ReadingsVal("Besuch_WZI", "state", "") ne "heute")
Mit der letzten Änderung bin ich einen Schritt weiter. Aber die Frage, wenn ein Feiertag auf einen Samstag fällt, ist damit immer noch nicht gelöst. Schön wäre z.B ein Konstrukt wie:
$we außer Samstag oder !$we außer Mittwoch etc.
Danke und weiterhin frohe Ostern.
Wolfgang
Hallo Wolfgang,
da ich nur zwischen Wochentagen und Wochenende unterscheide, klappt das bei mir mit $we und !$we.
E2.ez.HR.Heizung de !$we|06:00|comfort !$we|07:30|eco !$we|15:30|comfort !$we|00:30|eco $we|08:00|comfort $we|01:00|eco { myHeatingControl($NAME,$EVENT) }
Ich stimme Dir aber zu, dass eine generelle Lösung (höhere Priorisierung von $we gegenüber wday) aus Anwendersicht besser wäre, als mit mehreren HC od WDT zu arbeiten. Was für mich auch noch ginge, wäre wenn man im Ausführungsteil $we und den aktuellen Tag der Ausführung an eine eigene Funktion übergeben könnte.
Beste Grüße
Torsten
Ich denke mal über euren Wunsch nach, weiß aber nicht ob es einfach ist.
$we könnt ihr selbst ermitteln. Aus fhem.pl abkupfern.
Und wday ist noch einfacher.
Übergeben als Parameter geht auch, weil AnalyzeCommandChain angerufen wird und diese Funktion we und wday zur Verfügung stellt. - meine ich jedenfalls. Ausprobieren.
Ich mache das teilweise auch so.
ZitatIch denke mal über euren Wunsch nach, weiß aber nicht ob es einfach ist.
ich glaube ich habe einen Weg gefunden eine Vorrangregel so aufzubauen, dass $we eine Tagesdefinition komplett abschaltet, wenn Wochenende/Feiertrag gilt und dass !$we jede Tagesdefinition abschaltet, wenn ein Wochentag vorliegt.
Ich lasse mir die Idee noch ein wenig durch den Kopf gehen und versuche mich am Einbau.
Hallo Dietmar,
das wäre echt super, wenn Du das hinbekommen könntest. Die Übergabe funktioniert bei WDT leider nicht, da habe ich es nämlich schon ausprobiert:
2017.04.15 18:51:35.893 3: [KG.hz.ZS.Zirkulationspumpe.tim] Global symbol "$we" requires explicit package name at (eval 3191) line 1. >>>{ my $date=1492275095;{myWeekdayTimerTimeTable($we,"KG.hz.ZS.Zirkulationspumpe","on",1)}}<<<
Gruß
Torsten
Ich habe schon eine Version mit Vorrangregelung im Test.
Mal sehen ob es funktioniert.
Hi
Ich nutze HC zur Steuerung von meinen Fritz!300 / Comet DECT Thermostaten. Diese HC möchte ich mit Weekprofiles steuern können. Da diese Thermostate nicht direkt von HC unterstützt sind, habe ich folgende Routine und ein Notify entwickelt: https://forum.fhem.de/index.php/topic,63549.msg605214.html#msg605214
Das funktioniert, aber bringt manchmal komische Ergebnisse auf Grund "defmod". Und mit defmod sollte man dann einen Save anschliessen. Wenn ich auf einmal alle HC ändere und speichere, hat es mich auch mal zum Absturtz geführt.
Gibt es eine andere Möglichkeit, um die Profile eines HC zu ändern? Oder wäre es möglich es zu implementieren? Sowas wie den "set <weekprofile> profile_data <json data> ?
Gruß
Warum legst du nicht mehrere verschiedene Profile an und steuerst an/aus über Bedingungen.
Damit ich mehr Flexibilität bekomme. Mit meiner heutige Lösung kann ich direkt aus FTUI die Weekprofile bearbeiten, wie ich will.
Aber da die Weekprofile sich theoretisch "im laufenden Betrieb" nicht so oft ändern, wäre deine Lösung vielleicht doch nicht so schlecht: mehrere vordefinierte HC mit unterschiedliche Profile, und set active/inactive oder "conditions".
Ich war bisher noch in der "Einrichtungsphase", deswegen viele Änderungen.
Ich habe 2 HM-CC-TC für Küche und Wohnzimmer.
Mit einem Dummy schalte ich zwischen aus/ueb/an hin und her.
Zusätzlich wird noch zwischen Wochentag und Wochenende untschieden
Besser als disable funktioniert bei mir disableCond
Hallo Zusammen,
kann ich mit dem Modul auch eine DECT200 Steckdose die in FHEM eingebunden ist nach einem Wochenplan einschalten, und das basierend auf einem TX29DTH LaCrosse Funksensor der auch bereits in FHEM eingebunden ist?
Also eine Wochentag und Temperaturabhängige Schaltung eines Aktors?
Werde aus dem Commandref diesbezüglich nicht ganz schlau.
Danke Euch!
Hallo,
ich habe in der letzten Woche meine Heizungsventile von MAX auf HM umgerüstet und in diesem Zusammenhang das Modul Heating_Control eingesetzt. Dabei bin ich auf ein ähnliches oder gleiches Problem wie im Thread
https://forum.fhem.de/index.php/topic,79546.0.html (https://forum.fhem.de/index.php/topic,79546.0.html)
gestoßen.
Zum Sachverhalt:
Für jeden Raum habe ich jeweils zwei HC-Profile definiert:
hc.st.Schlafzimmer.Arbeit
DEF
struct.Heizung.st.Schlafzimmer 1234|16:30|day 5|14:00|day 60|07:00|day 1234560|02:30|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
und
hc.st.Schlafzimmer.Urlaub.zuhause
DEF
struct.Heizung.st.Schlafzimmer 1234560|07:00|day 1234560|02:30|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and (ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "on" or ReadingsVal("sc.Krank.zuhause", "state", "") eq "on"))
Zusätzlich ist noch folgendes Attribut jeweils definiert:
windowSensor
hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
Aktiv ist der Modus "Arbeit".
Nun wurde gestern Abend vor dem regulären Zeitschaltpunkt um 02:30 ein Fenster im Schlafzimmer über Nacht geöffnet, der Status des HC-Profils wechselte auch korrekt auf "open window":
2017.11.20 02:30:01 3: [hc.st.Schlafzimmer.Urlaub.zuhause] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2017.11.20 02:30:01 3: [hc.st.Schlafzimmer.Arbeit] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
Zum nächsten geplanten Zeitschaltpunkt um 07:00 steht im LOG:
2017.11.20 07:00:00 3: [hc.st.Schlafzimmer.Arbeit] timer at 02:30 skiped by new timer at 07:00
2017.11.20 07:00:00 3: [hc.st.Schlafzimmer.Urlaub.zuhause] timer at 02:30 skiped by new timer at 07:00
Um 07:06 wurde das Fenster geschlossen:
2017.11.20 07:06:56 3: CUL_HM set stat.eg.Flur_Dis displayEP GESCHLOSSEN,none:0000-00-0,none:07.06,ok off 3 0 off
Um 07:07 wurde der Wartezustand aufgehoben:
2017.11.20 07:07:00 3: [hc.st.Schlafzimmer.Urlaub.zuhause] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2017.11.20 07:07:00 3: [hc.st.Schlafzimmer.Arbeit] delay of switching struct.Heizung.st.Schlafzimmer stopped.
Jetzt hätte doch eigentlich das aktuelle Profil abgearbeitet werden müssen, passiert jedoch nicht.
Die Heizung bleibt im "day"-Modus (war vor Öffnen des Fensters gestern Abend aktiv).
Der Status bleibt im Modus "open window":
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEF struct.Heizung.st.Schlafzimmer 1234|16:30|day 5|14:00|day 60|07:00|day 1234560|02:30|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEVICE struct.Heizung.st.Schlafzimmer
GlobalDaylistSpec
LANGUAGE de
NAME hc.st.Schlafzimmer.Arbeit
NR 1456
Profil 0: Sonntag 02:30:00 night, 07:00:00 day
Profil 1: Montag 02:30:00 night, 16:30:00 day
Profil 2: Dienstag 02:30:00 night, 16:30:00 day
Profil 3: Mittwoch 02:30:00 night, 16:30:00 day
Profil 4: Donnerstag 02:30:00 night, 16:30:00 day
Profil 5: Freitag 02:30:00 night, 14:00:00 day
Profil 6: Samstag 02:30:00 night, 07:00:00 day
STATE open window
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2017-11-20 07:07:00 currValue night
2017-11-20 07:07:00 nextUpdate 2017-11-20 16:30:00
2017-11-20 07:07:00 nextValue day
2017-11-20 07:06:00 state open window
SWITCHINGTIMES:
1234|16:30|day
5|14:00|day
60|07:00|day
1234560|02:30|night
TIMER:
hc.st.Schlafzimmer.Arbeit_1:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 1
NAME hc.st.Schlafzimmer.Arbeit_1
hc.st.Schlafzimmer.Arbeit_2:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 2
NAME hc.st.Schlafzimmer.Arbeit_2
hc.st.Schlafzimmer.Arbeit_3:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 3
NAME hc.st.Schlafzimmer.Arbeit_3
hc.st.Schlafzimmer.Arbeit_SetTimerOfDay:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER SetTimerOfDay
NAME hc.st.Schlafzimmer.Arbeit_SetTimerOfDay
SETTIMERATMIDNIGHT 1
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
02:30:00 night
07:00:00 day
1:
02:30:00 night
16:30:00 day
2:
02:30:00 night
16:30:00 day
3:
02:30:00 night
16:30:00 day
4:
02:30:00 night
16:30:00 day
5:
02:30:00 night
14:00:00 day
6:
02:30:00 night
07:00:00 day
Die Profile für alle anderen Räume sind genauso aufgebaut und scheinen problemlos zu funktionieren (zumindest hat das Badezimmer-Profil heute morgen wie erwartet reagiert). Dort war zum Schaltzeitpunkt kein Fenster geöffnet.
Habe ich in Bezug auf Fenster-Sensoren etwas vergessen zu beachten, oder ist das ein Fehler im Modul?
ZitatnextUpdate 2017-11-20 16:30:00
Dann wird state neu kalkuliert.
ZitatDann wird state neu kalkuliert.
Ich hatte nur erwartet, dass das verpasste Switching morgens um 07:07 nachgeholt wird, wenn das Fenster geschlossen wird.
Der Status wird zwar mit "night" angegeben:
2017-11-20 07:07:00 currValue night der Heizungsregler stand jedoch auf "day", es wurde kein "set ... night" ausgeführt.
Nun habe ich explizit das Attribut
switchInThePast 1gesetzt und werde das Szenario noch einmal durchspielen.
Auch mit dem neu gesetzten Attribut
switchInThePast 1
bleibt der Fehler bestehen, der Status bleibt bei "open window" stehen und die Heizung wird nicht auf "night" gestellt, obwohl im Log wieder auftaucht:
2017.11.21 07:01:00 3: [hc.st.Schlafzimmer.Arbeit] timer at 02:31:00 skiped by new timer at 07:01:00
2017.11.21 07:01:00 3: [hc.st.Schlafzimmer.Urlaub.zuhause] timer at 02:31:00 skiped by new timer at 07:01:00
...
2017.11.21 07:02:00 3: [hc.st.Schlafzimmer.Arbeit] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2017.11.21 07:02:00 3: [hc.st.Schlafzimmer.Urlaub.zuhause] delay of switching struct.Heizung.st.Schlafzimmer stopped.
Ich werde jetzt mal das Attribut "windowSensor" löschen und schauen, was passiert.
Zeig bitte folgende lists:
list hc.st.Schlafzimmer.Arbeit
list hc.st.Schlafzimmer.Urlaub.zuhause
list sc.Heizung.Auto
list sc.Urlaub.zuhause
list sc.Urlaub.auswaerts
list sc.Krank.zuhause
list hm.fk.st.Schlafzimmer.links
list hm.fk.st.Schlafzimmer.rechts
hc.st.Schlafzimmer.Arbeit:
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEF struct.Heizung.st.Schlafzimmer 1234|16:31:00|day 5|14:01:00|day 60|07:01:00|day 1234560|02:31:00|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEVICE struct.Heizung.st.Schlafzimmer
GlobalDaylistSpec
LANGUAGE de
NAME hc.st.Schlafzimmer.Arbeit
NR 1450
Profil 0: Sonntag 02:31:00 night, 07:01:00 day
Profil 1: Montag 02:31:00 night, 16:31:00 day
Profil 2: Dienstag 02:31:00 night, 16:31:00 day
Profil 3: Mittwoch 02:31:00 night, 16:31:00 day
Profil 4: Donnerstag 02:31:00 night, 16:31:00 day
Profil 5: Freitag 02:31:00 night, 14:01:00 day
Profil 6: Samstag 02:31:00 night, 07:01:00 day
STATE night
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2017-11-21 08:40:21 currValue night
2017-11-21 08:40:21 nextUpdate 2017-11-21 16:31:00
2017-11-21 08:40:21 nextValue day
2017-11-21 08:40:21 state night
SWITCHINGTIMES:
1234|16:31:00|day
5|14:01:00|day
60|07:01:00|day
1234560|02:31:00|night
TIMER:
hc.st.Schlafzimmer.Arbeit_1:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 1
NAME hc.st.Schlafzimmer.Arbeit_1
hc.st.Schlafzimmer.Arbeit_2:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 2
NAME hc.st.Schlafzimmer.Arbeit_2
hc.st.Schlafzimmer.Arbeit_4:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 4
NAME hc.st.Schlafzimmer.Arbeit_4
immerSchalten 1
hc.st.Schlafzimmer.Arbeit_SetTimerOfDay:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER SetTimerOfDay
NAME hc.st.Schlafzimmer.Arbeit_SetTimerOfDay
SETTIMERATMIDNIGHT 1
hc.st.Schlafzimmer.Arbeit_delayed:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER delayed
NAME hc.st.Schlafzimmer.Arbeit_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
02:31:00 night
07:01:00 day
1:
02:31:00 night
16:31:00 day
2:
02:31:00 night
16:31:00 day
3:
02:31:00 night
16:31:00 day
4:
02:31:00 night
16:31:00 day
5:
02:31:00 night
14:01:00 day
6:
02:31:00 night
07:01:00 day
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1511278260
PARA day
TIME 16:31:00
TAGE:
1
2
3
4
2:
EPOCH 1511269260
PARA day
TIME 14:01:00
TAGE:
5
3:
EPOCH 1511244060
PARA day
TIME 07:01:00
TAGE:
0
6
4:
EPOCH 1511227860
PARA night
TIME 02:31:00
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
02:31:00 4
07:01:00 3
1:
02:31:00 4
16:31:00 1
2:
02:31:00 4
16:31:00 1
3:
02:31:00 4
16:31:00 1
4:
02:31:00 4
16:31:00 1
5:
02:31:00 4
14:01:00 2
6:
02:31:00 4
07:01:00 3
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME controlMode $EVENT
room Heizung
switchInThePast 1
windowSensor hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
hc.st.Schlafzimmer.Urlaub.zuhause
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and (ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "on" or ReadingsVal("sc.Krank.zuhause", "state", "") eq "on"))
DEF struct.Heizung.st.Schlafzimmer 1234560|07:01:00|day 1234560|02:31:00|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and (ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "on" or ReadingsVal("sc.Krank.zuhause", "state", "") eq "on"))
DEVICE struct.Heizung.st.Schlafzimmer
GlobalDaylistSpec
LANGUAGE de
NAME hc.st.Schlafzimmer.Urlaub.zuhause
NR 1451
Profil 0: Sonntag 02:31:00 night, 07:01:00 day
Profil 1: Montag 02:31:00 night, 07:01:00 day
Profil 2: Dienstag 02:31:00 night, 07:01:00 day
Profil 3: Mittwoch 02:31:00 night, 07:01:00 day
Profil 4: Donnerstag 02:31:00 night, 07:01:00 day
Profil 5: Freitag 02:31:00 night, 07:01:00 day
Profil 6: Samstag 02:31:00 night, 07:01:00 day
STATE open window
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2017-11-21 07:02:00 currValue day
2017-11-21 07:02:00 nextUpdate 2017-11-22 02:31:00
2017-11-21 07:02:00 nextValue night
2017-11-21 07:01:00 state open window
SWITCHINGTIMES:
1234560|07:01:00|day
1234560|02:31:00|night
TIMER:
hc.st.Schlafzimmer.Urlaub.zuhause_1:
HASH hc.st.Schlafzimmer.Urlaub.zuhause
MODIFIER 1
NAME hc.st.Schlafzimmer.Urlaub.zuhause_1
hc.st.Schlafzimmer.Urlaub.zuhause_SetTimerOfDay:
HASH hc.st.Schlafzimmer.Urlaub.zuhause
MODIFIER SetTimerOfDay
NAME hc.st.Schlafzimmer.Urlaub.zuhause_SetTimerOfDay
SETTIMERATMIDNIGHT 1
hc.st.Schlafzimmer.Urlaub.zuhause_delayed:
HASH hc.st.Schlafzimmer.Urlaub.zuhause
MODIFIER delayed
NAME hc.st.Schlafzimmer.Urlaub.zuhause_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
02:31:00 night
07:01:00 day
1:
02:31:00 night
07:01:00 day
2:
02:31:00 night
07:01:00 day
3:
02:31:00 night
07:01:00 day
4:
02:31:00 night
07:01:00 day
5:
02:31:00 night
07:01:00 day
6:
02:31:00 night
07:01:00 day
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1511244060
PARA day
TIME 07:01:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1511227860
PARA night
TIME 02:31:00
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
02:31:00 2
07:01:00 1
1:
02:31:00 2
07:01:00 1
2:
02:31:00 2
07:01:00 1
3:
02:31:00 2
07:01:00 1
4:
02:31:00 2
07:01:00 1
5:
02:31:00 2
07:01:00 1
6:
02:31:00 2
07:01:00 1
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME controlMode $EVENT
room Heizung
switchInThePast 1
windowSensor hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
sc.Heizung.Auto
Internals:
NAME sc.Heizung.Auto
NR 1288
STATE on
TYPE dummy
READINGS:
2017-11-08 16:42:42 state on
Attributes:
alias Heizung Automatik
devStateIcon .*off:md_ios_off_32 .*on:md_ios_on_32
icon sani_heating
room Heizung
setList on off
sc.Urlaub.zuhause
Internals:
NAME sc.Urlaub.zuhause
NR 693
STATE off
TYPE dummy
READINGS:
2017-11-06 13:02:43 state off
Attributes:
alias Urlaub zuhause
devStateIcon .*off:md_ios_off_32 .*on:md_ios_on_32
fhem_widget_command {"allowed_values":["off","on"],"order":90}
group Szenen
icon scene_summerhouse
room Widget,dummy
setList on off
sc.Urlaub.auswaerts
Internals:
NAME sc.Urlaub.auswaerts
NR 782
STATE off
TYPE dummy
READINGS:
2017-11-05 18:58:41 state off
Attributes:
alias Urlaub auswärts
devStateIcon .*off:md_ios_off_32 .*on:md_ios_on_32
group Szenen
icon scene_visit_guests
room Widget,dummy
setList on off
sc.Krank.zuhause
Internals:
NAME sc.Krank.zuhause
NR 1040
STATE off
TYPE dummy
READINGS:
2017-11-05 18:31:30 state off
Attributes:
devStateIcon .*off:md_ios_off_32_krank .*on:md_ios_on_32_krank2
icon scene_sleeping_alternat
room dummy
setList on off
hm.fk.st.Schlafzimmer.links
Internals:
CHANGED
DEF 581FA5
IODev myHmLGW
LASTInputDev myHmLGW
MSGCNT 27
NAME hm.fk.st.Schlafzimmer.links
NOTIFYDEV global
NR 1418
NTFY_ORDER 50-hm.fk.st.Schlafzimmer.links
STATE closed
TYPE CUL_HM
lastMsg No:C7 - t:10 s:581FA5 d:120504 06010000
myHmLGW_MSGCNT 27
myHmLGW_RAWMSG 05010034C7A610581FA512050406010000
myHmLGW_RSSI -52
myHmLGW_TIME 2017-11-21 10:31:42
peerList hm.hr.st.Schlafzimmer_WindowRec,hm.wt.st.Schlafzimmer_WindowRec,
protLastRcv 2017-11-21 10:31:42
protSnd 23 last_at:2017-11-21 10:31:42
protState CMDs_done
rssi_at_myHmLGW min:-56 avg:-51.96 cnt:27 lst:-52 max:-49
READINGS:
2017-11-20 14:59:41 Activity alive
2017-11-18 21:52:28 CommandAccepted no
2017-11-18 21:53:52 D-firmware 1.0
2017-11-18 21:53:52 D-serialNr OEQ0419786
2017-11-18 21:53:53 PairedTo 0x120504
2017-11-18 09:14:38 R-cyclicInfoMsg on
2017-11-18 09:14:39 R-eventDlyTime 0 s
2017-11-18 21:53:55 R-hm.hr.st.Schlafzimmer_WindowRec-expectAES off
2017-11-18 21:53:55 R-hm.hr.st.Schlafzimmer_WindowRec-peerNeedsBurst on
2017-11-18 21:51:40 R-hm.wt.st.Schlafzimmer_WindowRec-expectAES off
2017-11-18 21:51:40 R-hm.wt.st.Schlafzimmer_WindowRec-peerNeedsBurst on
2017-11-18 09:14:39 R-msgScPosA open
2017-11-18 09:14:39 R-msgScPosB closed
2017-11-18 09:14:38 R-pairCentral 0x120504
2017-11-18 09:14:38 R-sabotageMsg on
2017-11-18 09:15:18 R-sign off
2017-11-18 09:14:38 R-transmDevTryMax 6
2017-11-18 09:14:39 R-transmitTryMax 6
2017-11-18 21:53:53 RegL_00. 02:01 09:01 0A:12 0B:05 0C:04 10:01 14:06 00:00
2017-11-18 21:53:54 RegL_01. 08:00 20:9C 21:00 30:06 00:00
2017-11-18 21:53:55 RegL_04.hm.hr.st.Schlafzimmer_WindowRec 01:01 00:00
2017-11-18 21:53:55 RegL_04.hm.wt.st.Schlafzimmer_WindowRec 01:01 00:00
2017-11-18 09:15:17 aesCommToDev ok
2017-11-18 09:15:17 aesKeyNbr 00
2017-11-21 10:31:42 alive yes
2017-11-21 10:31:42 battery ok
2017-11-21 10:31:42 contact closed (to VCCU)
2017-11-21 10:31:42 onoff 0
2017-11-20 14:59:41 peerList hm.hr.st.Schlafzimmer_WindowRec,hm.wt.st.Schlafzimmer_WindowRec,
2017-11-21 10:31:42 recentStateType info
2017-11-21 10:31:42 sabotageError off
2017-11-21 10:31:42 state closed
2017-11-18 21:53:41 trigDst_hm.hr.st.Schlafzimmer noConfig
2017-11-21 07:01:27 trigger_cnt 34
helper:
HM_CMDNR 199
mId 00C7
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 1
raw 1
tpl 0
io:
newChn +581FA5,00,00,00
nextSend 1511256702.66674
rxt 2
vccu VCCU
p:
581FA5
00
00
00
prefIO:
myHmLGW
mRssi:
mNo C7
io:
myHmLGW -50
prt:
bErr 0
sProc 0
sleeping 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmLGW
flg A
ts 1511256702.39674
ack:
HASH(0x4281618)
C78002120504581FA500
rssi:
at_myHmLGW:
avg -51.962962962963
cnt 27
lst -52
max -49
min -56
tmpl:
Attributes:
IODev myHmLGW
IOgrp VCCU:myHmLGW
actCycle 002:50
actStatus alive
alias fk.st.Schlafzimmer.links
autoReadReg 4_reqStatus
devStateIcon closed.*:fts_window_2w open.*:fts_window_2w_tilt_l@red
event-on-change-reading state,onoff,battery
expert 3_allReg+raw
firmware 1.0
icon md_hm_fensterkontakt@crimson
model HM-SEC-SCo
peerIDs 00000000,5F96FE03,61845303,
room CUL_HM
serialNr OEQ0419786
struct.state struct.fk.alle
struct.state_map .*closed.*:GESCHLOSSEN .*open.*:OFFEN
structexclude struct.fk.alle:userReadings
subType threeStateSensor
userReadings SwitchTime {(substr((ReadingsTimestamp("hm.fk.st.Schlafzimmer.links","trigger_cnt"," ")),11,2).'.'.(substr((ReadingsTimestamp("hm.fk.st.Schlafzimmer.links","trigger_cnt"," ")),14,2)))},onoff {((ReadingsVal("hm.fk.st.Schlafzimmer.links","state","open") eq "open")? "1":"0")}
userattr struct.state struct.state_map structexclude
hm.fk.st.Schlafzimmer.rechts
Internals:
CHANGED
DEF 581F89
IODev myHmLGW
LASTInputDev myHmLGW
MSGCNT 27
NAME hm.fk.st.Schlafzimmer.rechts
NOTIFYDEV global
NR 1416
NTFY_ORDER 50-hm.fk.st.Schlafzimmer.rechts
STATE closed
TYPE CUL_HM
lastMsg No:D7 - t:10 s:581F89 d:120504 06010000
myHmLGW_MSGCNT 27
myHmLGW_RAWMSG 05010037D7A610581F8912050406010000
myHmLGW_RSSI -55
myHmLGW_TIME 2017-11-21 10:41:19
peerList hm.hr.st.Schlafzimmer_WindowRec,hm.wt.st.Schlafzimmer_WindowRec,
protLastRcv 2017-11-21 10:41:19
protSnd 23 last_at:2017-11-21 10:41:19
protState CMDs_done
rssi_at_myHmLGW min:-59 avg:-53.18 cnt:27 lst:-55 max:-50
READINGS:
2017-11-20 14:59:41 Activity alive
2017-11-18 21:55:34 CommandAccepted yes
2017-11-18 22:12:18 D-firmware 1.0
2017-11-18 22:12:18 D-serialNr OEQ0419757
2017-11-18 21:55:34 PairedTo 0x120504
2017-11-18 09:09:00 R-cyclicInfoMsg on
2017-11-18 09:10:49 R-eventDlyTime 0 s
2017-11-18 21:55:36 R-hm.hr.st.Schlafzimmer_WindowRec-expectAES off
2017-11-18 21:55:36 R-hm.hr.st.Schlafzimmer_WindowRec-peerNeedsBurst on
2017-11-18 21:54:44 R-hm.wt.st.Schlafzimmer_WindowRec-expectAES off
2017-11-18 21:54:44 R-hm.wt.st.Schlafzimmer_WindowRec-peerNeedsBurst on
2017-11-18 09:10:49 R-msgScPosA open
2017-11-18 09:10:49 R-msgScPosB closed
2017-11-18 09:09:00 R-pairCentral 0x120504
2017-11-18 09:09:00 R-sabotageMsg on
2017-11-18 09:11:29 R-sign off
2017-11-18 09:09:00 R-transmDevTryMax 6
2017-11-18 09:10:49 R-transmitTryMax 6
2017-11-18 21:55:34 RegL_00. 02:01 09:01 0A:12 0B:05 0C:04 10:01 14:06 00:00
2017-11-18 21:55:35 RegL_01. 08:00 20:9C 21:00 30:06 00:00
2017-11-18 21:55:36 RegL_04.hm.hr.st.Schlafzimmer_WindowRec 01:01 00:00
2017-11-18 21:55:36 RegL_04.hm.wt.st.Schlafzimmer_WindowRec 01:01 00:00
2017-11-18 09:11:28 aesCommToDev ok
2017-11-18 09:11:28 aesKeyNbr 00
2017-11-21 10:41:19 alive yes
2017-11-21 10:41:19 battery ok
2017-11-21 10:41:19 contact closed (to VCCU)
2017-11-21 10:41:19 onoff 0
2017-11-20 14:59:41 peerList hm.hr.st.Schlafzimmer_WindowRec,hm.wt.st.Schlafzimmer_WindowRec,
2017-11-21 10:41:19 recentStateType info
2017-11-21 10:41:19 sabotageError off
2017-11-21 10:41:19 state closed
2017-11-21 07:01:26 trigger_cnt 46
helper:
HM_CMDNR 215
mId 00C7
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 1
raw 1
tpl 0
io:
newChn +581F89,00,00,00
nextSend 1511257279.46498
rxt 2
vccu VCCU
p:
581F89
00
00
00
prefIO:
myHmLGW
mRssi:
mNo D7
io:
myHmLGW -53
prt:
bErr 0
sProc 0
sleeping 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmLGW
flg A
ts 1511257279.18281
ack:
HASH(0x4280f40)
D78002120504581F8900
rssi:
at_myHmLGW:
avg -53.1851851851852
cnt 27
lst -55
max -50
min -59
tmpl:
Attributes:
IODev myHmLGW
IOgrp VCCU:myHmLGW
actCycle 002:50
actStatus alive
alias fk.st.Schlafzimmer.rechts
autoReadReg 4_reqStatus
devStateIcon closed.*:fts_window_2w open.*:fts_window_2w_tilt_r@red
event-on-change-reading state,onoff,battery
expert 3_allReg+raw
firmware 1.0
icon md_hm_fensterkontakt@crimson
model HM-SEC-SCo
peerIDs 00000000,5F96FE03,61845303,
room CUL_HM
serialNr OEQ0419757
struct.state struct.fk.alle
struct.state_map .*closed.*:GESCHLOSSEN .*open.*:OFFEN
subType threeStateSensor
userReadings onoff {((ReadingsVal("hm.fk.st.Schlafzimmer.rechts","state","open") eq "open")? "1":"0")}
userattr struct.state struct.state_map structexclude
Hmm... ich bin ein bisschen verwirrt, vielleicht weil ich die Reihenfolge von deinen letzten Massnahme nicht kenne.
hc.st.Schlafzimmer.Urlaub.zuhause ist auf Grund der Condition schon lange inaktiv. Das die Heizung nicht geschaltet wird scheint normal zu sein. Das hc.st.Schlafzimmer.Urlaub.zuhause selbst auf "open window" bleibt könnte auch normal sein, wenn das Modul inaktiv ist. Die Timestamps vonden Readings sind aber komisch: wenn die Condition das Modul verhindert, werden currValue usw. immer noch kalkuliert, aber "state" sollte sich nicht ändern.
hc.st.Schlafzimmer.Arbeit hat auf night geschaltet, was richtig ist. Aber vielleicht weil Du etwas anderes inzwischen geschaltet hast.
Was interessant wäre, wäre diese "list" von hc.st.Schlafzimmer.Arbeit zu sehen, wenn er in eine "falschem" Zustand sich befindet.
Danke, dass du dich meines Problems annimmst.
Ich versuche mal etwas Klarheit zu schaffen:
hc.st.Schlafzimmer.Urlaub.zuhause können wir z.Zt. vernachlässigen, Bedingung trifft nicht zu.
Im folgenden die Chronologie der Abläufe:
23:58:35 hm.fk.st.Schlafzimmer.links wird geöffnet. Zu diesem Zeitpunkt war der Modus von hc.st.Schlafzimmer.Arbeit auf "day". Durch den Fensterkontakt sprang der Heizungsregler auf 5.5°.
00:12:15 wurde der Wandtaster "Nachtmodus" gedrückt, dabei wird an alle Heizkörper der Befehl "set ... night" geschickt, der Regler im Schlafzimmer war im Fenster-Offen-Modus und reagierte deshalb wahrscheinlich nicht (habe ich noch nicht ausgetestet).
02:31:00 soll über hc.st.Schlafzimmer.Arbeit der Heizungsregler abermals "set ... night" erhalten. Wegen des offenen Fensters wurde "delayed" protokolliert.
06:36:32 wurde zusätzlich hm.fk.st.Schlafzimmer.rechts geöffnet.
07:01:00 wurde die Meldung über den verpassten Timer um 02:31:00 protokolliert, seltsamerweise ist 07:01:00 als Zeitpunkt nur in hc.st.Schlafzimmer.Urlaub.zuhause definiert (ist ja eigentlich inaktiv).
07:01:26 wurde hm.fk.st.Schlafzimmer.rechts geschlossen.
07:01:27 wurde hm.fk.st.Schlafzimmer.links geschlossen.
07:02:00 wurde die Meldung über "delay of switching stopped" protokolliert, weil beide Fenster geschlossen sind. Mehr passierte nicht...
08:40:21 habe ich durch "modify" von hc.st.Schlafzimmer.Arbeit die Umschaltung von "open window" auf "night" erzwungen.
Danach wurde erst das "List" von hc.st.Schlafzimmer.Arbeit erstellt...
Ist das halbwegs verständlich?
@amenomade
So, hier ist einmal das fragliche List im Zustand "beide Fenster auf":
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEF struct.Heizung.st.Schlafzimmer 1234|16:31:00|day 5|14:01:00|day 60|07:01:00|day 1234560|02:31:00|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEVICE struct.Heizung.st.Schlafzimmer
GlobalDaylistSpec
LANGUAGE de
NAME hc.st.Schlafzimmer.Arbeit
NR 1450
Profil 0: Sonntag 02:31:00 night, 07:01:00 day
Profil 1: Montag 02:31:00 night, 16:31:00 day
Profil 2: Dienstag 02:31:00 night, 16:31:00 day
Profil 3: Mittwoch 02:31:00 night, 16:31:00 day
Profil 4: Donnerstag 02:31:00 night, 16:31:00 day
Profil 5: Freitag 02:31:00 night, 14:01:00 day
Profil 6: Samstag 02:31:00 night, 07:01:00 day
STATE open window
STILLDONETIME 0
TYPE Heating_Control
VERZOEGRUNG 1
VERZOEGRUNG_IDX 3
READINGS:
2017-11-21 16:31:00 currValue day
2017-11-21 16:31:00 nextUpdate 2017-11-22 02:31:00
2017-11-21 16:31:00 nextValue night
2017-11-22 08:47:00 state open window
SWITCHINGTIMES:
1234|16:31:00|day
5|14:01:00|day
60|07:01:00|day
1234560|02:31:00|night
TIMER:
hc.st.Schlafzimmer.Arbeit_1:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 1
NAME hc.st.Schlafzimmer.Arbeit_1
hc.st.Schlafzimmer.Arbeit_2:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 2
NAME hc.st.Schlafzimmer.Arbeit_2
hc.st.Schlafzimmer.Arbeit_3:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 3
NAME hc.st.Schlafzimmer.Arbeit_3
hc.st.Schlafzimmer.Arbeit_SetTimerOfDay:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER SetTimerOfDay
NAME hc.st.Schlafzimmer.Arbeit_SetTimerOfDay
SETTIMERATMIDNIGHT 1
hc.st.Schlafzimmer.Arbeit_delayed:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER delayed
NAME hc.st.Schlafzimmer.Arbeit_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
02:31:00 night
07:01:00 day
1:
02:31:00 night
16:31:00 day
2:
02:31:00 night
16:31:00 day
3:
02:31:00 night
16:31:00 day
4:
02:31:00 night
16:31:00 day
5:
02:31:00 night
14:01:00 day
6:
02:31:00 night
07:01:00 day
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1511364660
PARA day
TIME 16:31:00
TAGE:
1
2
3
4
2:
EPOCH 1511355660
PARA day
TIME 14:01:00
TAGE:
5
3:
EPOCH 1511330460
PARA day
TIME 07:01:00
TAGE:
0
6
4:
EPOCH 1511314260
PARA night
TIME 02:31:00
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
02:31:00 4
07:01:00 3
1:
02:31:00 4
16:31:00 1
2:
02:31:00 4
16:31:00 1
3:
02:31:00 4
16:31:00 1
4:
02:31:00 4
16:31:00 1
5:
02:31:00 4
14:01:00 2
6:
02:31:00 4
07:01:00 3
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME controlMode $EVENT
room Heizung
switchInThePast 1
windowSensor hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
Dann wurden beide Fenster geschlossen:
2017.11.22 08:51:00 3: [hc.st.Schlafzimmer.Urlaub.zuhause] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2017.11.22 08:51:00 3: [hc.st.Schlafzimmer.Arbeit] delay of switching struct.Heizung.st.Schlafzimmer stopped.
und hier das List nach Schließen beider Fenster:
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEF struct.Heizung.st.Schlafzimmer 1234|16:31:00|day 5|14:01:00|day 60|07:01:00|day 1234560|02:31:00|night (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
DEVICE struct.Heizung.st.Schlafzimmer
GlobalDaylistSpec
LANGUAGE de
NAME hc.st.Schlafzimmer.Arbeit
NR 1450
Profil 0: Sonntag 02:31:00 night, 07:01:00 day
Profil 1: Montag 02:31:00 night, 16:31:00 day
Profil 2: Dienstag 02:31:00 night, 16:31:00 day
Profil 3: Mittwoch 02:31:00 night, 16:31:00 day
Profil 4: Donnerstag 02:31:00 night, 16:31:00 day
Profil 5: Freitag 02:31:00 night, 14:01:00 day
Profil 6: Samstag 02:31:00 night, 07:01:00 day
STATE open window
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2017-11-22 08:51:00 currValue night
2017-11-22 08:51:00 nextUpdate 2017-11-22 16:31:00
2017-11-22 08:51:00 nextValue day
2017-11-22 08:50:00 state open window
SWITCHINGTIMES:
1234|16:31:00|day
5|14:01:00|day
60|07:01:00|day
1234560|02:31:00|night
TIMER:
hc.st.Schlafzimmer.Arbeit_1:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 1
NAME hc.st.Schlafzimmer.Arbeit_1
hc.st.Schlafzimmer.Arbeit_2:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 2
NAME hc.st.Schlafzimmer.Arbeit_2
hc.st.Schlafzimmer.Arbeit_3:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER 3
NAME hc.st.Schlafzimmer.Arbeit_3
hc.st.Schlafzimmer.Arbeit_SetTimerOfDay:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER SetTimerOfDay
NAME hc.st.Schlafzimmer.Arbeit_SetTimerOfDay
SETTIMERATMIDNIGHT 1
hc.st.Schlafzimmer.Arbeit_delayed:
HASH hc.st.Schlafzimmer.Arbeit
MODIFIER delayed
NAME hc.st.Schlafzimmer.Arbeit_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
02:31:00 night
07:01:00 day
1:
02:31:00 night
16:31:00 day
2:
02:31:00 night
16:31:00 day
3:
02:31:00 night
16:31:00 day
4:
02:31:00 night
16:31:00 day
5:
02:31:00 night
14:01:00 day
6:
02:31:00 night
07:01:00 day
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1511364660
PARA day
TIME 16:31:00
TAGE:
1
2
3
4
2:
EPOCH 1511355660
PARA day
TIME 14:01:00
TAGE:
5
3:
EPOCH 1511330460
PARA day
TIME 07:01:00
TAGE:
0
6
4:
EPOCH 1511314260
PARA night
TIME 02:31:00
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
02:31:00 4
07:01:00 3
1:
02:31:00 4
16:31:00 1
2:
02:31:00 4
16:31:00 1
3:
02:31:00 4
16:31:00 1
4:
02:31:00 4
16:31:00 1
5:
02:31:00 4
14:01:00 2
6:
02:31:00 4
07:01:00 3
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME controlMode $EVENT
room Heizung
switchInThePast 1
windowSensor hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
Zur Zeit steht im Frontend:
DeviceOverview
hc.st.Schlafzimmer.Arbeit open window
obwohl im List currValue auf "night" steht.
Der Heizkörper hat immer noch die "day"-Temperatur, es wurde kein "set ... night" abgesetzt.
So weit ich das Modul verstanden habe, setzt er immer noch alle Timer, und ändert die unabhängig von der Kondition. Nur wenn diese Kondition nicht wahr ist wenn die Schaltzeit erreicht ist, wird der Befehl nicht ausgeführt.
Die Fenstersensoren verzögern die Schalttimer bis die Fenster wieder "zu" sind. Dann sollten alle verpasste Timer schalten.
Jetzt fehlen mir aber immer noch Informationen, um das Verhalten zu verstehen. Es wäre hilfreich, die gesamte Log von allen relevanten Events und deren Reihenfolge zu sehen. Kannst Du evtl. eine eigene Filelog mit allen Devices erstellen?
Im Moment kann ich mir nur vorstellen, dass die Timers nicht diejenige sind, die wir uns vorstellen. Dafür sollte man andere Meldung in der Log (mit verbose 5) sehen, wie z.B. "setTimer - timer seems to be active today:", oder "past timer on DEVICE at <time> activated", oder "result of condition". Die wären auch wichtig, um das ganze zu verstehen.
Ich habe gestern und heute wenig Zeit gehabt, aber ich werde versuchen das ganze zu simulieren, um selbst zu sehen. Deine Logs wären aber schon hilfreich.
Hier eine Simulation bei mir:
Zeitprofil: 00:08 day 00:10:00 night, 00:12:00 day, 00:14:00 night, 00:16:00 day, 00:18:00 night, 00:20:00 day, 00:22:00 night, 00:24:00 day, 00:26:00 night
Am Anfang sind die Fenster zu, sc.Heizung.Auto ist "on", und beide sc.Urlaub.* sind "off" (=> Condition = wahr)
Log:
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:08/1511478480 delay=0, nextDelay=60, nextRetry=1511478540
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:08:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'closed'
2017.11.24 00:08:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.rechts' Reading/Attribute 'state' is 'closed'
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,1,2,3,4,5,6
2017.11.24 00:08:00 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.24 00:08:00 5: [hc.st.Schlafzimmer.Arbeit] result of condition:1
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] Update - timer seems to be active today: 0123456|00:08|day
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] aktParam: newParam:day - is not disabled
2017.11.24 00:08:00 4: [hc.st.Schlafzimmer.Arbeit] command: 'set $NAME controlMode $EVENT' executed with %EVENT=>day,%NAME=>struct.Heizung.st.Schlafzimmer
2017.11.24 00:10:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:10/1511478600 delay=0, nextDelay=60, nextRetry=1511478660
2017.11.24 00:10:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:10:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:10:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:10:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2017.11.24 00:10:00 3: [hc.st.Schlafzimmer.Arbeit] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2017.11.24 00:10:00 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_2
2017.11.24 00:10:00 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_2 2017-11-24 00:11:00
2017.11.24 00:11:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:10/1511478600 delay=60, nextDelay=120, nextRetry=1511478720
2017.11.24 00:11:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:11:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:11:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:11:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2017.11.24 00:11:00 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_2
2017.11.24 00:11:00 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_2 2017-11-24 00:12:00
2017.11.24 00:12:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:12/1511478720 delay=0, nextDelay=60, nextRetry=1511478780
2017.11.24 00:12:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:12:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:12:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:12:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2017.11.24 00:12:00 3: [hc.st.Schlafzimmer.Arbeit] timer at 00:10 skiped by new timer at 00:12
2017.11.24 00:12:00 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_2
2017.11.24 00:12:00 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_3
2017.11.24 00:12:00 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_3 2017-11-24 00:13:00
2017.11.24 00:13:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:12/1511478720 delay=60, nextDelay=120, nextRetry=1511478840
2017.11.24 00:13:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:13:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:13:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:13:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2017.11.24 00:13:00 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_3
2017.11.24 00:13:00 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_3 2017-11-24 00:14:00
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:12/1511478720 delay=119, nextDelay=180, nextRetry=1511478900
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'closed'
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.rechts' Reading/Attribute 'state' is 'closed'
2017.11.24 00:14:00 3: [hc.st.Schlafzimmer.Arbeit] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,1,2,3,4,5,6
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] result of condition:1
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] Update - timer seems to be active today: 0123456|00:12|day
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] aktParam: newParam:day - is not disabled
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] command: 'set $NAME controlMode $EVENT' executed with %NAME=>struct.Heizung.st.Schlafzimmer,%EVENT=>day
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] time=00:14/1511478840 delay=0, nextDelay=60, nextRetry=1511478900
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'closed'
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.rechts' Reading/Attribute 'state' is 'closed'
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,1,2,3,4,5,6
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.24 00:14:00 5: [hc.st.Schlafzimmer.Arbeit] result of condition:1
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] Update - timer seems to be active today: 0123456|00:14|night
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] aktParam: newParam:night - is not disabled
2017.11.24 00:14:00 4: [hc.st.Schlafzimmer.Arbeit] command: 'set $NAME controlMode $EVENT' executed with %NAME=>struct.Heizung.st.Schlafzimmer,%EVENT=>night
Fazit: es funktioniert wie erwartet:
- um 00:08 => set controlMode day
>> hier werden die Fenster geöffnet. Keine Änderung im HC
- um 00:10 springt er auf "open window" => Verzögerung
- um 00:11 prüft er die Verzögerung. Da die Fenster immer noch auf sind => weitere Verzögerung
- um 00:12 neue Schaltzeit => timer skiped by new timer. Fenster immer noch auf => Verzögerung
- um 00:13 prüft er die Verzögerung. Da die Fenster immer noch auf sind => weitere Verzügerung
>> hier werden die Fenster geschlossen
- um 00:14 delay of switching stopped => Verzögerte Befehl von 00:12 wird ausgeführt => er springt auf day. Dann wird der Befehl von 00:14 ausgeführt => er spring auf night
- um 00:16 day
usw
Wie gesagt: mir fehlen bei dir diese Log Auszüge mit allen Meldungen.
Versionen ("version" im Kommandofeld eingeben):
fhem.pl 15294 2017-10-20 06:40:24Z rudolfkoenig
98_Heating_Control.pm 13374 2017-02-09 20:00:35Z orti-otto
98_WeekdayTimer.pm 13374 2017-02-09 20:00:35Z orti-otto
Ich muss aber noch was anderes testen, da beim Lesen des Moduls mir etwas aufgefallen ist. Aber nicht heute.
Fhem wird von mir regelmäßig aktualisiert. Hier die Versionen:
fhem.pl 15466 2017-11-20 22:22:19Z rudolfkoenig
98_Heating_Control.pm 13374 2017-02-09 20:00:35Z orti-otto
98_WeekdayTimer.pm 13374 2017-02-09 20:00:35Z orti-otto
Gestern nachmittag habe ich versuchsweise den Schaltzeitpunkt von 02:31:00 auf 21:31:00 vorverlegt. In den Readings wurden die Werte für "nextUpdate" und "nextValue" korrekt gesetzt, zum angebenen Zeitpunkt passierte nichts. Kein Eintrag im Log. In der Zeit zwischen Änderung und geplantem Schaltzeitpunkt wurde kein Fenster geöffnet.
Ich werde jetzt den verbose-Level raufsetzen und am WE einige Tests vornehmen und die Logs präsentieren.
Am WE habe ich versuchsweise die vorgesehene Schaltzeit von 02:31:00 auf 21:31:00 vorgezogen, mit dem Ergebnis, dass es seitdem funktioniert. Am Tag der Änderung funktionierte es noch nicht, jedoch ab dem nächsten Tag, ohne weitere Änderung, problemlos. Verstehe ich nicht.
Hier die entsprechenden Logs:
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] time=21:31:00/1511728260 delay=0, nextDelay=60, nextRetry=1511728320
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.26 21:31:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'closed'
2017.11.26 21:31:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.rechts' Reading/Attribute 'state' is 'closed'
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,1,2,3,4,5,6
2017.11.26 21:31:00 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.26 21:31:00 5: [hc.st.Schlafzimmer.Arbeit] result of condition:1
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] Update - timer seems to be active today: 0123456|21:31:00|night
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] device type heating recognized, setModifier:desired-temp
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] aktParam:19.0 newParam:night - is not disabled
2017.11.26 21:31:00 4: [hc.st.Schlafzimmer.Arbeit] command: 'set $NAME controlMode $EVENT' executed with %NAME=>struct.Heizung.st.Schlafzimmer,%EVENT=>night
...
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_1
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_4
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_2
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_3
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 07:29:50 17:06:54 Montag
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 07:01:00 day, 21:31:00 night (Profil 0: Sonntag)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 16:01:00 day, 21:31:00 night (Profil 1: Montag)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 16:01:00 day, 21:31:00 night (Profil 2: Dienstag)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 16:01:00 day, 21:31:00 night (Profil 3: Mittwoch)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 16:01:00 day, 21:31:00 night (Profil 4: Donnerstag)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 13:31:00 day, 21:31:00 night (Profil 5: Freitag)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] 07:01:00 day, 21:31:00 night (Profil 6: Samstag)
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] device type heating recognized, setModifier:desired-temp
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] Heating recognized - switch in the past activated
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:1,2,3,4
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(1,2,3,4);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] result of condition:1
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] setTimer - timer seems to be active today: 1234|16:01:00|day
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_1 2017-11-27 16:01:00
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:5
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(5);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] result of condition:
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] setTimer - timer seems to be NOT active today: 5|13:31:00|day (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_2 2017-11-27 13:31:00
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,6
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] result of condition:
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] setTimer - timer seems to be NOT active today: 06|07:01:00|day (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off")
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_3 2017-11-27 07:01:00
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,1,2,3,4,5,6
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4,5,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] result of condition:1
2017.11.27 00:00:05 4: [hc.st.Schlafzimmer.Arbeit] setTimer - timer seems to be active today: 0123456|21:31:00|night
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_4 2017-11-27 21:31:00
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] removing Timer: hc.st.Schlafzimmer.Arbeit_SetTimerOfDay
2017.11.27 00:00:05 5: [hc.st.Schlafzimmer.Arbeit] setting Timer: hc.st.Schlafzimmer.Arbeit_SetTimerOfDay 2017-11-28 00:00:05
...
2017.11.27 07:01:00 4: [hc.st.Schlafzimmer.Arbeit] time=07:01:00/1511762460 delay=0, nextDelay=60, nextRetry=1511762520
2017.11.27 07:01:00 4: [hc.st.Schlafzimmer.Arbeit] delayedExecutionCond:0
2017.11.27 07:01:00 4: [hc.st.Schlafzimmer.Arbeit] result of delayedExecutionCond:0
2017.11.27 07:01:00 4: [hc.st.Schlafzimmer.Arbeit] list of window sensors found: 'hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts hc.st.Schlafzimmer.Arbeit'
2017.11.27 07:01:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'closed'
2017.11.27 07:01:00 5: [hc.st.Schlafzimmer.Arbeit] sensor 'hm.fk.st.Schlafzimmer.rechts' Reading/Attribute 'state' is 'closed'
2017.11.27 07:01:00 4: [hc.st.Schlafzimmer.Arbeit] condition:(ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") - Tage:0,6
2017.11.27 07:01:00 5: [hc.st.Schlafzimmer.Arbeit] condition: {my $days={};;map{$days->{$_}=1}(0,6);;;;( (ReadingsVal("sc.Heizung.Auto", "state", "") eq "on" and ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off") && (defined $days->{$wday}))}
2017.11.27 07:01:00 5: [hc.st.Schlafzimmer.Arbeit] result of condition:
Als nächstes werde ich das Verhalten mit verschiedenen Zuständen der Fensterkontakte austesten und danach den Zeitschaltpunkt wieder auf nach Mitternacht setzen.
Wenn ich das richtig verstanden habe, ist das Modul WeekdayTimer ähnlich aufgebaut wie Heating_Control. Damit habe ich ebenfalls am WE experimentiert und ein ähnliches Problem feststellen müssen. Ich habe für jeden Rolladen im Erdgeschoss versuchsweise WeekdayTimer angelegt.
Z.B.:
define wdt.duo.eg.Badezimmer.Arbeit dm.duo.eg.Badezimmer 1234560|{sunset_abs("Civil",ReadingsVal("dm.duo.eg.Badezimmer","state",0)*60)}|down 12345|06:00|up 60|09:00|up (ReadingsVal("sc.Urlaub.zuhause","state","") eq "off") or (ReadingsVal("sc.Arbeit.Micha","state","") eq "on")
und:
define wdt.duo.eg.Badezimmer.Urlaub.zuhause dm.duo.eg.Badezimmer 1234560|{sunset_abs("Civil",ReadingsVal("dm.duo.eg.Badezimmer","state",0)*60)}|down 1234560|09:00|up (ReadingsVal("sc.Urlaub.zuhause", "state", "") eq "on" or ReadingsVal("sc.Krank.zuhause", "state", "") eq "on")
Hintergrund ist, dass ich beim Öffnen des Badezimmerfensters das Rollo immer hochfahren (egal welcher Zustand vorlag) und nach dem Schließen in den laut Timer vorgesehenen Zustand ggf. herunterfahren lasse.
define di.fk.duo.eg.Badezimmer DOIF ([hm.fk.eg.Badezimmer:onoff] eq "1" ) (set duo.eg.Badezimmer manualMode on) (set duo.eg.Badezimmer up) DOELSEIF ([hm.fk.eg.Badezimmer:onoff] eq "0") (set duo.eg.Badezimmer manualMode off) (set duo.eg.Badezimmer [dm.duo.eg.Badezimmer:setpoint]) DOELSE
attr di.fk.duo.eg.Badezimmer wait 0,10:360,0
Dabei hat sich gestern das Problem ergeben, dass abends (ca. 20:00 Uhr )nach dem Duschen beim Öffnen des Fensters das Rollo erwartungsgemäß hochfuhr, nach Schließen des Fensters jedoch nicht herunterfuhr, obwohl die Schaltzeit (ca. 18:07 Uhr) längst vorbei war. Das verwendete Reading im Dummy dm.duo.eg.Badezimmer wurde nicht neu gesetzt.
Hier das List des WeekdayTimers von gestern abend:
Internals:
CFGFN
COMMAND
CONDITION (ReadingsVal("sc.Urlaub.zuhause","state","") eq "off") or (ReadingsVal("sc.Arbeit.Micha","state","") eq "on")
DEF dm.duo.eg.Badezimmer 1234560|{sunset_abs("Civil",ReadingsVal("dm.duo.eg.Badezimmer","state",0)*60)}|down 12345|06:00|up 60|09:00|up (ReadingsVal("sc.Urlaub.zuhause","state","") eq "off") or (ReadingsVal("sc.Arbeit.Micha","state","") eq "on")
DEVICE dm.duo.eg.Badezimmer
GlobalDaylistSpec
LANGUAGE de
NAME wdt.duo.eg.Badezimmer.Arbeit
NR 16855
Profil 0: Sonntag 09:00:00 up, 18:07:39 down
Profil 1: Montag 06:00:00 up, 18:07:39 down
Profil 2: Dienstag 06:00:00 up, 18:07:39 down
Profil 3: Mittwoch 06:00:00 up, 18:07:39 down
Profil 4: Donnerstag 06:00:00 up, 18:07:39 down
Profil 5: Freitag 06:00:00 up, 18:07:39 down
Profil 6: Samstag 09:00:00 up, 18:07:39 down
STATE up
STILLDONETIME 0
TYPE WeekdayTimer
READINGS:
2017-11-26 09:00:00 currValue up
2017-11-24 19:49:36 disabled 0
2017-11-26 09:00:00 nextUpdate 2017-11-26 18:07:39
2017-11-26 09:00:00 nextValue down
2017-11-26 09:00:00 state up
SWITCHINGTIMES:
1234560|{sunset_abs("Civil",ReadingsVal("dm.duo.eg.Badezimmer","state",0)*60)}|down
12345|06:00|up
60|09:00|up
TIMER:
wdt.duo.eg.Badezimmer.Arbeit_1:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER 1
NAME wdt.duo.eg.Badezimmer.Arbeit_1
immerSchalten 1
wdt.duo.eg.Badezimmer.Arbeit_2:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER 2
NAME wdt.duo.eg.Badezimmer.Arbeit_2
wdt.duo.eg.Badezimmer.Arbeit_3:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER 3
NAME wdt.duo.eg.Badezimmer.Arbeit_3
wdt.duo.eg.Badezimmer.Arbeit_SetTimerOfDay:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER SetTimerOfDay
NAME wdt.duo.eg.Badezimmer.Arbeit_SetTimerOfDay
SETTIMERATMIDNIGHT 1
wdt.duo.eg.Badezimmer.Arbeit_delayed:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER delayed
NAME wdt.duo.eg.Badezimmer.Arbeit_delayed
wdt.duo.eg.Badezimmer_1:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER 1
NAME wdt.duo.eg.Badezimmer_1
wdt.duo.eg.Badezimmer_SetTimerOfDay:
HASH wdt.duo.eg.Badezimmer.Arbeit
MODIFIER SetTimerOfDay
NAME wdt.duo.eg.Badezimmer_SetTimerOfDay
SETTIMERATMIDNIGHT 1
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
09:00:00 up
18:07:39 down
1:
06:00:00 up
18:07:39 down
2:
06:00:00 up
18:07:39 down
3:
06:00:00 up
18:07:39 down
4:
06:00:00 up
18:07:39 down
5:
06:00:00 up
18:07:39 down
6:
09:00:00 up
18:07:39 down
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1511716059
PARA down
TIME {sunset_abs("Civil",ReadingsVal("dm.duo.eg.Badezimmer","state",0)*60)}
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1511672400
PARA up
TIME 06:00
TAGE:
1
2
3
4
5
3:
EPOCH 1511683200
PARA up
TIME 09:00
TAGE:
0
6
profile_IDX:
0:
09:00:00 3
18:07:39 1
1:
06:00:00 2
18:07:39 1
2:
06:00:00 2
18:07:39 1
3:
06:00:00 2
18:07:39 1
4:
06:00:00 2
18:07:39 1
5:
06:00:00 2
18:07:39 1
6:
09:00:00 3
18:07:39 1
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate setreading $NAME setpoint $EVENT
disable 0
room Rollladen
switchInThePast 1
Auch hier wird offensichtlich nicht geschaltet, obwohl nextUpdate und nextValue korrekt erscheinen.
Ich werde auch hier den verbose-Level auf 5 setzen und weiter beobachten.
Moin, brauche mal eure syntax-Hilfe. Nutze bisher den WD-Timer erfolgreiche für simple on oder off-Befehle. Nun brauche ich aber die Ausführung des TextTo-Speech Befehls: set Tablet ttsMsg Hier kommt mein Text.
Ich weiss nun nicht wie ich das einbinden soll weil:
define WD_Bahn_Morgens WeekdayTimer Tablet 8|07:08|ttsMsg lala lala lala (Value("Automatikmodus") eq "Standard")
wird ja nicht funktionieren. Wie setze ich das ttsMsg lala lala lala um? DANKE
Hat hier noch jmd ein Tipp für mich?
Hallo,
Ich möchte mit einem HeatingControl 2 Arten von Thermostaten schalten (MAX + HM). Der eine braucht desired-temp, der andere desiredTemperature.
Gibt es dazu eine Möglichkeit, das in einem HC-Device zu vereinen ohne es explizit hinten als 2 Befehle anzugeben ?
So gehts nicht zumindest fuer das MAX-Device :
HK_HM_WOHNEN_._Clima,HK_WC_EG Mo-So|07:30|22 Mo-So|22:00|15 {if (Value("DS_Heizen") eq "on" )) {fhem("set $NAME desired-temp $EVENT")}}
Hallo,
Ich habe ein Problem mit Heating_Control. Ich benutze es zur Heizungssteuerung in drei Räumen (MAX! mit dem CUL), zwei davon mit Fenstersensoren (auch MAX!). Die Abwesenheitssteuerung habe ich über Homemode realisiert, das bei einer Änderung den Befehl {Heating_Control_SetAllTemps()} absetzt, die Heating_Controls schalten dann durch das Auslesen der Location Variable in Homemode.
Das ganze funktioniert auch in zwei Räumen immer, nur im Wohnzimmer verschluckt sich Heating_Control öfter am Morgen, wenn die Heizung wieder hochgeregelt werden soll. Der State bleibt dann auf Eco stehen, nextUpdate zeigt weiter die Zeit, zu der die Schaltung hätte stattfinden sollen.
Folgenden list habe ich heute um kurz nach 8 Uhr gezogen, also gut zwei Stunden nach dem eigentlichen Schaltzeitpunkt. Fenster waren keine geöffnet, ein {Heating_Control_SetAllTemps()} löst das Problem in diesen Fällen.
Internals:
COMMAND
CONDITION (ReadingsVal ("Wohnung", "location", 0) eq "home")
DEF hz_living 01:00|eco 06:00|comfort (ReadingsVal ("Wohnung", "location", 0) eq "home")
DEVICE hz_living
GlobalDaylistSpec
LANGUAGE de
NAME hc_living
NR 35
Profil 0: Sonntag 01:00:00 eco, 06:00:00 comfort
Profil 1: Montag 01:00:00 eco, 06:00:00 comfort
Profil 2: Dienstag 01:00:00 eco, 06:00:00 comfort
Profil 3: Mittwoch 01:00:00 eco, 06:00:00 comfort
Profil 4: Donnerstag 01:00:00 eco, 06:00:00 comfort
Profil 5: Freitag 01:00:00 eco, 06:00:00 comfort
Profil 6: Samstag 01:00:00 eco, 06:00:00 comfort
STATE eco
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2017-12-15 01:00:00 currValue eco
2017-12-08 02:15:07 disabled 0
2017-12-15 01:00:00 nextUpdate 2017-12-15 06:00:00
2017-12-15 01:00:00 nextValue comfort
2017-12-15 01:00:00 state eco
SWITCHINGTIMES:
01:00|eco
06:00|comfort
TIMER:
hc_living_1:
HASH hc_living
MODIFIER 1
NAME hc_living_1
hc_living_2:
HASH hc_living
MODIFIER 2
NAME hc_living_2
immerSchalten 1
hc_living_SetTimerOfDay:
HASH hc_living
MODIFIER SetTimerOfDay
NAME hc_living_SetTimerOfDay
SETTIMERATMIDNIGHT 1
hc_living_delayed:
HASH hc_living
MODIFIER delayed
NAME hc_living_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
01:00:00 eco
06:00:00 comfort
1:
01:00:00 eco
06:00:00 comfort
2:
01:00:00 eco
06:00:00 comfort
3:
01:00:00 eco
06:00:00 comfort
4:
01:00:00 eco
06:00:00 comfort
5:
01:00:00 eco
06:00:00 comfort
6:
01:00:00 eco
06:00:00 comfort
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1513296000
PARA eco
TIME 01:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1513314000
PARA comfort
TIME 06:00
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
01:00:00 1
06:00:00 2
1:
01:00:00 1
06:00:00 2
2:
01:00:00 1
06:00:00 2
3:
01:00:00 1
06:00:00 2
4:
01:00:00 1
06:00:00 2
5:
01:00:00 1
06:00:00 2
6:
01:00:00 1
06:00:00 2
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME desiredTemperature $EVENT
disable 0
room 13_Steuerung
switchInThePast 1
windowSensor fs_living_balcony fs_living_window
Das ganze funktionert in etwa 60-80% der Fälle reibungslos, nur ein bis zwei Mal in der Woche wird morgens nicht umgeschaltet (abends hatte ich das Problem bisher nie), immer im Wohnzimmer, die anderen Räume funktionieren immer. An der Abwesenheitsschaltung kann es nicht liegen, der Status stimmt grundsätzlich.
Die Unterschiede zu den anderen Räumen: Der Schaltpunkt zum Herunterregeln ist um 1 Uhr (bei den anderen: 0 Uhr) und die Steuerung läuft über ein Structure, um ein Wandthermostat und ein Heizthermostat zu regeln, aber daran sollte es eigentlich nicht liegen.
Bin da gerade geringfügig am Verzweifeln :)
Oliver.
Zur Analyse würde ich eine Filelog kreieren, die alle Ereignisse von involvierten Geräte zusammenfasst: hc_living, hz_living, Wohnung, fs_living_balcony und fs_living_window.
Damit wirst Du sehen, was sich ändert und wann.
ZitatAn der Abwesenheitsschaltung kann es nicht liegen, der Status stimmt grundsätzlich.
Sicher?
Zitat von: amenomade am 15 Dezember 2017, 13:22:51
Sicher?
Jupp, der Status für die Absent-HCs ist jeweils "Inactive", der für die Present-HCs zeigt den jeweils aktuellen Status (Eco oder Comfort, in dem Fall dann fälschlicherweise Eco).
Da muss ich mich dann mal mit Filelog beschäftigen.
Ist halt vor allem spannend, weil alle Heating_Controls quasi identisch sind. Hab einen erstellt und dann einfach kopiert und angepasst. Zwei davon funtktionieren einwandfrei, einer nur teilweise. Wenn es wenigstens immer auftreten würde, wäre die Analyse auch einfacher... :)
Zitat von: Andre0909 am 03 Dezember 2017, 16:30:29
Moin, brauche mal eure syntax-Hilfe. Nutze bisher den WD-Timer erfolgreiche für simple on oder off-Befehle. Nun brauche ich aber die Ausführung des TextTo-Speech Befehls: set Tablet ttsMsg Hier kommt mein Text.
Ich weiss nun nicht wie ich das einbinden soll weil:
define WD_Bahn_Morgens WeekdayTimer Tablet 8|07:08|ttsMsg lala lala lala (Value("Automatikmodus") eq "Standard")
wird ja nicht funktionieren. Wie setze ich das ttsMsg lala lala lala um? DANKE
Hat hier noch jmd ein Tipp für mich?
define WD_Bahn_Morgens WeekdayTimer Tablet 8|07:08|msg {fhem ("set Tablet ttsMsg lalalaal") if (Value("Automatikmodus") eq "Standard");}sollte gehen (nicht getestet)
Kurzes Update: Es scheint ein Problem mit der Schaltzeit zu sein. Hab die Zeit zum Herunterregeln zum Test mal, wie die anderen Thermostate, auf 00:00 gesetzt, seitdem hatte ich keine Probleme mehr. Sobald ich die Zeit finde, werde ich mal mit verschiedenen Zeiteinstellungen experimentieren.
Leider finde ich mich mit Filelog nicht wirklich zurecht, sonst würde ich da mit Logs arbeiten (würde mich über Links oder Erklärungen freuen - nach Studium der Dokumentation zu filelog hab ich ein großes "Bahnhof" auf der Stirn.... Bin halt so'n Hobby-C++'ler...)
Zitat von: ogruetzmann am 15 Dezember 2017, 08:57:22
Hallo,
Ich habe ein Problem mit Heating_Control. Ich benutze es zur Heizungssteuerung in drei Räumen (MAX! mit dem CUL), zwei davon mit Fenstersensoren (auch MAX!). Die Abwesenheitssteuerung habe ich über Homemode realisiert, das bei einer Änderung den Befehl {Heating_Control_SetAllTemps()} absetzt, die Heating_Controls schalten dann durch das Auslesen der Location Variable in Homemode.
Das ganze funktioniert auch in zwei Räumen immer, nur im Wohnzimmer verschluckt sich Heating_Control öfter am Morgen, wenn die Heizung wieder hochgeregelt werden soll. Der State bleibt dann auf Eco stehen, nextUpdate zeigt weiter die Zeit, zu der die Schaltung hätte stattfinden sollen.
Folgenden list habe ich heute um kurz nach 8 Uhr gezogen, also gut zwei Stunden nach dem eigentlichen Schaltzeitpunkt. Fenster waren keine geöffnet, ein {Heating_Control_SetAllTemps()} löst das Problem in diesen Fällen.
Internals:
COMMAND
CONDITION (ReadingsVal ("Wohnung", "location", 0) eq "home")
DEF hz_living 01:00|eco 06:00|comfort (ReadingsVal ("Wohnung", "location", 0) eq "home")
DEVICE hz_living
GlobalDaylistSpec
LANGUAGE de
NAME hc_living
NR 35
Profil 0: Sonntag 01:00:00 eco, 06:00:00 comfort
Profil 1: Montag 01:00:00 eco, 06:00:00 comfort
Profil 2: Dienstag 01:00:00 eco, 06:00:00 comfort
Profil 3: Mittwoch 01:00:00 eco, 06:00:00 comfort
Profil 4: Donnerstag 01:00:00 eco, 06:00:00 comfort
Profil 5: Freitag 01:00:00 eco, 06:00:00 comfort
Profil 6: Samstag 01:00:00 eco, 06:00:00 comfort
STATE eco
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2017-12-15 01:00:00 currValue eco
2017-12-08 02:15:07 disabled 0
2017-12-15 01:00:00 nextUpdate 2017-12-15 06:00:00
2017-12-15 01:00:00 nextValue comfort
2017-12-15 01:00:00 state eco
SWITCHINGTIMES:
01:00|eco
06:00|comfort
TIMER:
hc_living_1:
HASH hc_living
MODIFIER 1
NAME hc_living_1
hc_living_2:
HASH hc_living
MODIFIER 2
NAME hc_living_2
immerSchalten 1
hc_living_SetTimerOfDay:
HASH hc_living
MODIFIER SetTimerOfDay
NAME hc_living_SetTimerOfDay
SETTIMERATMIDNIGHT 1
hc_living_delayed:
HASH hc_living
MODIFIER delayed
NAME hc_living_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
01:00:00 eco
06:00:00 comfort
1:
01:00:00 eco
06:00:00 comfort
2:
01:00:00 eco
06:00:00 comfort
3:
01:00:00 eco
06:00:00 comfort
4:
01:00:00 eco
06:00:00 comfort
5:
01:00:00 eco
06:00:00 comfort
6:
01:00:00 eco
06:00:00 comfort
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1513296000
PARA eco
TIME 01:00
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1513314000
PARA comfort
TIME 06:00
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
01:00:00 1
06:00:00 2
1:
01:00:00 1
06:00:00 2
2:
01:00:00 1
06:00:00 2
3:
01:00:00 1
06:00:00 2
4:
01:00:00 1
06:00:00 2
5:
01:00:00 1
06:00:00 2
6:
01:00:00 1
06:00:00 2
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME desiredTemperature $EVENT
disable 0
room 13_Steuerung
switchInThePast 1
windowSensor fs_living_balcony fs_living_window
Das ganze funktionert in etwa 60-80% der Fälle reibungslos, nur ein bis zwei Mal in der Woche wird morgens nicht umgeschaltet (abends hatte ich das Problem bisher nie), immer im Wohnzimmer, die anderen Räume funktionieren immer. An der Abwesenheitsschaltung kann es nicht liegen, der Status stimmt grundsätzlich.
Die Unterschiede zu den anderen Räumen: Der Schaltpunkt zum Herunterregeln ist um 1 Uhr (bei den anderen: 0 Uhr) und die Steuerung läuft über ein Structure, um ein Wandthermostat und ein Heizthermostat zu regeln, aber daran sollte es eigentlich nicht liegen.
Bin da gerade geringfügig am Verzweifeln :)
Oliver.
Das Attribut "idleperiod" gibt doch die zeit in Minuten an, bevor das Modul schalten soll, oder?
Wäre es nicht schön wenn man die Werte fürs Ein- und Aus-Schalten getrennt angeben könnte?
Bei mir wird über eine Geolocation auch die Temperatur verändert. Sobald ich mich also der Wohnung nähere wird sie angehoben.
Dann würde HCS schalten... wartet aber erst noch.
Oder schaltet es sofort ein und verzögert aus?
Zitat von: Dietmar63 am 18 April 2017, 20:38:01
Ich habe schon eine Version mit Vorrangregelung im Test.
Mal sehen ob es funktioniert.
Hallo !
ich habe vor mit HC zu beginnen (in Anlehnung an Mitch's Beispielen). Bevor ich mich im Design total "verhaue" 3 Fragen:
- ist im HC nun der Vorrang $we vor Wochentag funktionsfähig eingebaut ?
- müssen die Heizkörperventile (ich habe HM) im "manual"-Mode (wie von Mitch für seine FHTs beschrieben) betrieben werden oder geht auch "automatik"-Mode ?
- ich habe teilweise Zimmer ohne separatem Thermostat (z.B.: WC) und teilweise mit Thermostat (z.B.: Bad), der jeweils mit dem Heizkörperventil peered ist. Wo schicke ich dei HC-Commands hin ? Zum Thermostat ? Zum Ventil oder zu beiden ? Nach meinem Verständnis zum Thermostat, der die desired-temp dann an den Ventil-Peer weiterschicken sollte. Oder ?
Gruß Josef
[/list]
Zitat von: statler am 30 Januar 2018, 18:41:04
Hallo !
ich habe vor mit HC zu beginnen (in Anlehnung an Mitch's Beispielen). Bevor ich mich im Design total "verhaue" 3 Fragen:
- ist im HC nun der Vorrang $we vor Wochentag funktionsfähig eingebaut ?
kann ich nicht sagen
Zitat von: statler am 30 Januar 2018, 18:41:04
- müssen die Heizkörperventile (ich habe HM) im "manual"-Mode (wie von Mitch für seine FHTs beschrieben) betrieben werden oder geht auch "automatik"-Mode ?
geht auch mit Auto, aber das Thermostat hat dann quasi Vorrang
Zitat von: statler am 30 Januar 2018, 18:41:04
- ich habe teilweise Zimmer ohne separatem Thermostat (z.B.: WC) und teilweise mit Thermostat (z.B.: Bad), der jeweils mit dem Heizkörperventil peered ist. Wo schicke ich dei HC-Commands hin ? Zum Thermostat ? Zum Ventil oder zu beiden ? Nach meinem Verständnis zum Thermostat, der die desired-temp dann an den Ventil-Peer weiterschicken sollte. Oder ?
[/list]
Ventil, wenn alleine und Thermostat, wenn vorhanden.
So ist das bei mir auch (habe mittlerweile auch fast nur HM)
Werden eigentlich Fritz Dect Steckdosen unterstützt? Betreibe eine Infrarot Heizung im Bad über eine Fritz Dect Steckdose. Die Dose hat auch einen internen Temp. Sensor.
Dieser wird via Reading "temperature" angezeigt und der wert wird wie folgt angezeigt bsp."20 C (messured)"
Lege Dir ein userReading an mit ReadingsNum
habs nicht so hinbekommen mit userreading und readingsnum. trotz commandref und foren beiträgen konnte ich kein zufriedenstellendes ergebnis erzielen. habe es nun über threshold,doif,weekdaytimer, ein paar dummys und notifys gelöst. 8)
hier mein beitrag
https://forum.fhem.de/index.php/topic,81813.msg778850.html#msg778850 (https://forum.fhem.de/index.php/topic,81813.msg778850.html#msg778850)
userReadings temperature_num:temperature.* { ReadingsNum ($name,'temperature',100) }
Ich brauche mal einen Anstupser.
Meine Heizungssteuerung funktioniert soweit, nun möchte ich aber die Temperaturvorgaben variabler gestalten. Bisher kommt die Temperatur zu jedem Device aus dem WeekdayTimer, da ist eine Änderung umständlich.
Lege ich da Dummys mit den Readings Kalt/Warm/ExtremWarm usw. an oder lieber userReadings in den einzelnen Devices?
Welcher Ansatz ist da der schönste?
defmod wtFBDECT_11795_0297488 WeekdayTimer wtDevice Mo-Fr|05:50|21.0\
Mo-Fr|08:00|20.0\
Sa|07:00|21.0\
So|07:00|21.0\
Mo-So|08:30|-1\
Mo-So|20:00|off
Falls das schon gefragt wurde, habe ich die Suche falsch benutzt.
ich habe mich jetzt für dummys mit Readings für 2 Temperaturen (eco und comfort) für jedes WeekdayTimer Device entschieden.
Das Ergebnis sieht so aus, ist nur gerade alles auf manuell.
Lediglich die unterschiedliche Breite der ReadingsGroups stört mich noch, da habe ich noch nix gefunden.
Edit: Huch, in welchem Thread bin ich hier — ich hab nur WeekdayTimer gelesen. Habe das mit WeekdayTimer und AT gemacht :-[
Sieht cool aus... Kannst Du bitte mal die Definition der Readingsgroup posten.
Gruß
Torsten
so sieht das zu Zeit aus
defmod rgPM readingsGroup <%sani_heating_manual>,<Onl.>,<Ein/Aus>,<°C Soll>,<°C Ist>,<Lock>,<Leistung>,<Mode> props=powerMeter,tempSensor,switch:present,state,currValue@wtFBDECT_11795_0297488,temperature,locked,power,mode
attr rgPM alias DECT 200
attr rgPM cellStyle { "r:1"=>'style="font-weight:bold;;font-size:16px"',\
"r:1,c:6"=>'style="font-weight:bold;;font-size:16px;;text-align:center"'\
}
attr rgPM commands { 'state.off'=>'set $DEVICE on',\
'state.on'=>'set $DEVICE off',\
}
attr rgPM group Heizung
attr rgPM room @home
attr rgPM valueColumns { 'Temperatur setzen'=>'colspan="2"'\
}
attr rgPM valueFormat { if(index($VALUE,'off')!=-1) {\
$VALUE = 'off';;\
} elsif($READING =~ /temperature/) {\
$VALUE = $NUM;;\
} elsif($VALUE =~ /-1/) {\
$VALUE = 'do_nothing';;\
} elsif($VALUE =~ /comfort/) {\
$VALUE = ReadingsVal($DEVICE,'comfort','').' (comfort)';;\
} elsif($VALUE =~ /eco/) {\
$VALUE = ReadingsVal($DEVICE,'eco','').' (eco)';;\
}\
}
attr rgPM valueIcon { 'present.yes' => 'it_wifi',\
'present.no' => 'it_wifi@red',\
'state.on' => 'ios-on-green',\
'state.off' => 'ios-off',\
'currValue.do_nothing' => 'time_manual_mode',\
'locked.yes' => 'secur_locked',\
'locked.no' => 'secur_open',\
'batterylow.0' => 'batterie',\
'batterylow.1' => 'batterie@red'\
}
attr rgPM valueStyle { ($READING =~ /present|state|temperature/) ? \
'style="text-align:center"'\
:\
''\
}
attr rgPM valueSuffix { #'temperature'=>'°;C','state'=>($VALUE eq "aus")?'':'°;C'\
}
defmod rgSH readingsGroup <%sani_heating_level_80>,<Onl.>,<°C Soll>,<°C Ist>,<Lock>,<Batt.>,<Temperatur setzen>\
props=actuator,tempSensor:present,state,temperature,locked,batterylow,!switchOFF,desired-temp
attr rgSH alias DECT 300 / Comet
attr rgSH cellStyle { "r:1"=>'style="font-weight:bold;;font-size:16px"',\
"r:1,c:7"=>'style="font-weight:bold;;font-size:16px;;text-align:center"',\
"c:2"=>'style="text-align:center"',\
"r:1,c:2"=>'style="font-weight:bold;;font-size:16px"',\
}
attr rgSH commands { 'desired-temp'=>'desired-temp:',\
'switchOFF'=>'set $DEVICE closed'\
}
attr rgSH group Heizung,
attr rgSH room @home
attr rgSH valueColumns { 'Temperatur setzen'=>'colspan="2"',\
'State '=>'style="font-weight:bold;;font-size:10px;;text-align:center" '\
}
attr rgSH valueFormat { 'state'=>(index($VALUE,'off')!=-1) ?\
'—'\
:\
$NUM,\
'temperature'=>$NUM\
}
attr rgSH valueIcon { 'present.yes' => 'it_wifi',\
'present.no' => 'it_wifi@red',\
'state.aus' => 'general_aus',\
'locked.yes' => 'secur_locked',\
'locked.no' => 'secur_open',\
'switchOFF' => 'control_standby',\
'batterylow.0' => 'batterie',\
'batterylow.1' => 'batterie@red'\
}
attr rgSH valueSuffix { #'temperature'=>'°;C','state'=>($VALUE eq "aus")?'':'°;C'\
}
defmod rgWPlan readingsGroup <%clock>,<Soll °C>,<Nächste Werte>,<Scheduler>,<Temperaturen °C>,<Disalble>\
<>,<>,<Uhrzeit / Temperatur>,<>,<Eco>,<Comfort>,<>\
wtFBDECT_08761_0123268:currValue,nextUpdate,nextValue,state@atFBDECT_08761_0123268,eco@wtDevice_08761_0123268,comfort@wtDevice_08761_0123268,?!disable@atFBDECT_08761_0123268\
wtFBDECT_11795_0288464:currValue,nextUpdate,nextValue,state@atFBDECT_11795_0288464,eco@wtDevice_11795_0288464,comfort@wtDevice_11795_0288464,?!disable@atFBDECT_11795_0288464\
wtFBDECT_11795_0297488:currValue,nextUpdate,nextValue,state@atFBDECT_11795_0297488,eco@wtDevice_11795_0297488,comfort@wtDevice_11795_0297488,?!disable@atFBDECT_11795_0297488\
wtFBDECT_11795_1004376:currValue,nextUpdate,nextValue,state@atFBDECT_11795_1004376,eco@wtDevice_11795_1004376,comfort@wtDevice_11795_1004376,?!disable@atFBDECT_11795_1004376\
wtFBDECT_11959_0102320:currValue,nextUpdate,nextValue,state@atFBDECT_11959_0102320,eco@wtDevice_11959_0102320,comfort@wtDevice_11959_0102320,?!disable@atFBDECT_11959_0102320
attr rgWPlan alias Wochenplan
attr rgWPlan cellStyle { "r:1"=>'style="font-weight:bold;;font-size:16px"',\
"r:1,c:6"=>'style="text-align:center;;font-weight:bold;;font-size:16px"',\
"c:1"=>'style="text-align:center"',\
"r:1,c:1"=>'style="font-weight:bold;;font-size:16px"',\
"c:2"=>'style="text-align:center"',\
"r:1,c:2"=>'style="font-weight:bold;;font-size:16px"',\
"c:3"=>'style="text-align:left"',\
"r:1,c:3"=>'style="font-weight:bold;;font-size:16px"',\
"r:2,c:5"=>'style="text-align:center"',\
"r:2,c:6"=>'style="text-align:center"',\
}
attr rgWPlan commands { 'disable' => 'disable:',\
'eco' => 'eco:',\
'comfort' => 'comfort:'\
}
attr rgWPlan group Heizung
attr rgWPlan icon time_manual_mode
attr rgWPlan room @home,Timer
attr rgWPlan valueColumns { 'Nächste Werte' => 'colspan="2"',\
'Temperaturen °C' => 'colspan="2"',\
'Uhrzeit / Temperatur' => 'colspan="2"'\
}
attr rgWPlan valueFormat { my $dev = 'wtDevice_'.substr($DEVICE,-13);;\
if($READING !~ /nextUpdate/ && $VALUE =~ /-1/) {\
$VALUE = 'do_nothing';;\
} elsif(index($VALUE,'off')!=-1) {\
'—'\
} elsif($READING =~ /nextUpdate/) {\
my ($date,$time) = split(' ',$VALUE);;\
$time =~ s/:..$//;;\
$VALUE = $time;;\
} elsif($VALUE =~ /comfort/) {\
$VALUE = ReadingsVal($dev,'comfort','').' (comfort)';;\
} elsif($VALUE =~ /eco/) {\
$VALUE = ReadingsVal($dev,'eco','').' (eco)';;\
}\
}
attr rgWPlan valueIcon { 'currValue.off' => 'general_aus',\
'currValue.do_nothing' => 'time_manual_mode',\
'nextValue.off' => 'general_aus',\
'nextValue.do_nothing' => 'time_manual_mode',\
}
Gibts eine Möglichkeit einen einzelnen Heizkörper aus der Steuerung herauszunehmen?
Ich würde gerne bei meinen Eltern im Nachbarhaus anfangen die ersten HM HKT zu setzen, allerdings dürfen die natürlich nicht MEINE Steuerung beeinflussen.
Ich habe ein Attribut "exclude" gefunden, kann ich DA den entsprechenden HKT angeben?
Wäre doof wenn das so NICHT gehen würde. :(
Hey,
leider scheint HC meine Heizung nicht zu mögen (oder eher das Thermostat :D).
Hat das schon jemand mit HomeMaticIP lauffähig hinbekommen ?
Danke Euch
Internals:
CFGFN
COMMAND ((ReadingsVal("**********"", "state", "") eq "open")|(ReadingsVal("**********", "state", "") eq "open")|(ReadingsVal("**********"", "state", "") eq "open")|(ReadingsVal("**********"", "state", "") eq "open")) {fhem ("set Heizung_Computer datapoint 1.SET_POINT_TEMPERATURE %")}
CONDITION
DEF Heizung_Computer de $we|00:00|17 $we|08:00|25 $we|12:00|20 $we|15:00|24 $we|20:00|22 ((ReadingsVal("**********"", "state", "") eq "open")|(ReadingsVal("**********"", "state", "") eq "open")|(ReadingsVal("**********"", "state", "") eq "open")|(ReadingsVal("**********"", "state", "") eq "open")) {fhem ("set Heizung_Computer datapoint 1.SET_POINT_TEMPERATURE %")}
DEVICE Heizung_Computer
GlobalDaylistSpec
LANGUAGE de
NAME Steuerung_Heizung_Computer_We
NR 512
Profil 0: Sonntag 00:00:00 17, 08:00:00 25, 12:00:00 20, 15:00:00 24, 20:00:00 22
Profil 6: Samstag 00:00:00 17, 08:00:00 25, 12:00:00 20, 15:00:00 24, 20:00:00 22
Profil 7: Wochenende 00:00:00 17, 08:00:00 25, 12:00:00 20, 15:00:00 24, 20:00:00 22
STATE active
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2018-06-23 23:43:33 currValue 22
2018-06-23 23:43:37 disabled 0
2018-06-23 23:43:33 nextUpdate 2018-06-24 00:00:00
2018-06-23 23:43:33 nextValue 17
2018-06-23 23:43:33 state active
SWITCHINGTIMES:
$we|00:00|17
$we|08:00|25
$we|12:00|20
$we|15:00|24
$we|20:00|22
TIMER:
Steuerung_Heizung_Computer_We_SetTimerOfDay:
HASH Steuerung_Heizung_Computer_We
MODIFIER SetTimerOfDay
NAME Steuerung_Heizung_Computer_We_SetTimerOfDay
SETTIMERATMIDNIGHT 1
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
00:00:00 17
08:00:00 25
12:00:00 20
15:00:00 24
20:00:00 22
1:
2:
3:
4:
5:
6:
00:00:00 17
08:00:00 25
12:00:00 20
15:00:00 24
20:00:00 22
7:
00:00:00 17
08:00:00 25
12:00:00 20
15:00:00 24
20:00:00 22
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1529704800
PARA 17
TIME 00:00
TAGE:
7
2:
EPOCH 1529733600
PARA 25
TIME 08:00
TAGE:
7
3:
EPOCH 1529748000
PARA 20
TIME 12:00
TAGE:
7
4:
EPOCH 1529758800
PARA 24
TIME 15:00
TAGE:
7
5:
EPOCH 1529776800
PARA 22
TIME 20:00
TAGE:
7
profile_IDX:
0:
00:00:00 1
08:00:00 2
12:00:00 3
15:00:00 4
20:00:00 5
6:
00:00:00 1
08:00:00 2
12:00:00 3
15:00:00 4
20:00:00 5
7:
00:00:00 1
08:00:00 2
12:00:00 3
15:00:00 4
20:00:00 5
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set Heizung_Computer datapoint 1.SET_POINT_TEMPERATURE $EVENT
disable 0
Ich hoffe, dass hier noch jemand mitliest.
Ich hatte folgendes Problem mit WeekdayTimer:
Wenn ich ich ein einen Profileintrag wie beispielsweise 08:00|28 definiere, wird als $EVENT immer "28.0" gesendet. Mein Thermostat akzeptiert aber nur ganze Zahlen, also gab's eine Fehlermeldung.
Ich habe das Problem mit einem Workaround gelöst, indem ich die ganze Zahl aus $EVENT heraushole.
Außerdem ist mir aufgefallen, dass das Attribut "commandTemplate" in der Commandref nicht auftaucht.
Hallo Zusammen,
ich haben folgenden Problem: ich würde gerne das "Heating_Control" Module wie folgt nutzen:
Das Ziel ist es einen Wochenplan per Web erstellen zu können, und für "Heating_Control" Wochenprofile zu hinterlegen.
Hierbei habe ich mit folgende Beispiel aus fhemwiki angelehnt:
https://wiki.fhem.de/wiki/ReadingsGroup#Heizungswerte.2C_Status.2C_Steuerung_und_Wochenprofil
Das Skripe erstellt dummys (d_climaControl_16) in den das Wochenprofil in den Readings hinterlegt wird, und diese habe ich mit stateformat in das format was der "Heating_Control" benötigt.
Der Statt von "d_climaControl_16" sieht wie folgt aus :
Mo-Fr|00:00|HC_Temp(16.0) Mo-Fr|12:00|HC_Temp(15.0) Mo-Fr|12:00|HC_Temp(16.0) Mo-Fr|24:00|HC_Temp(15.0) Sa|12:00|HC_Temp(16.0) Sa|12:00|HC_Temp(15.0) Sa|24:00|HC_Temp(16.0) Sa|24:00|HC_Temp(15.0) So|12:00|HC_Temp(16.0) So|12:00|HC_Temp(15.0) So|24:00|HC_Temp(16.0) So|24:00|HC_Temp(15.0)
Die state wird aus den in den dummy (d_climaControl_16) enthalten readings gebildet, siehe hier:
define d_climaControl_16 dummy
attr d_climaControl_16 room 1.6_Gast,HEIZUNG,zHomekit
attr d_climaControl_16 setList dayTemp:5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 nightTemp:5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 workday_period_1_start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 workday_period_1_stop:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 workday_period_2_start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 workday_period_2_stop:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 saturday_period_1_start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 saturday_period_1_stop:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 saturday_period_2_start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 saturday_period_2_stop:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 sunday_period_1_start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 sunday_period_1_stop:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 sunday_period_2_start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00 sunday_period_2_stop:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,24:00
attr d_climaControl_16 stateFormat Mo-Fr|workday_period_1_start|HC_Temp(dayTemp) Mo-Fr|workday_period_1_stop|HC_Temp(nightTemp) Mo-Fr|workday_period_2_start|HC_Temp(dayTemp) Mo-Fr|workday_period_2_stop|HC_Temp(nightTemp) Sa|saturday_period_1_start|HC_Temp(dayTemp) Sa|saturday_period_1_stop|HC_Temp(nightTemp) Sa|saturday_period_2_start|HC_Temp(dayTemp) Sa|saturday_period_2_stop|HC_Temp(nightTemp) So|sunday_period_1_start|HC_Temp(dayTemp) So|sunday_period_1_stop|HC_Temp(nightTemp) So|sunday_period_2_start|HC_Temp(dayTemp) So|sunday_period_2_stop|HC_Temp(nightTemp)
Das "Heating_Control" (HC_climaControl_16) Device, sieht wie folgt aus:
define HC_climaControl_16 Heating_Control Thermostat_Gast12_EQ3BT_Clima de d_climaControl_16:state {\
HC_setTemp($NAME, eval $EVENT);;\
}
attr HC_climaControl_16 commandTemplate set $NAME desiredTemperature $EVENT
attr HC_climaControl_16 icon sani_heating_calendar
attr HC_climaControl_16 room 1.6_Gast,HEIZUNG
Leider erkennt "Heating_Control" den State von (d_climaControl_16) nicht Inhalt für das Wochenprofil an.
Hat jemand nee Idee wie man das hinbekommt?
Alternativ könnte man auch die Reading auch direkt in den "Heating_Control" schreiben,
und die readings füttern den Wochenplan, leider ist das mit auch nicht gelungen!
Gruß Sascha
Hallo,
seit einiger Zeit schaltet einer meiner Heating-Control Timer nicht mehr zu den definierten Zeiten um. Komisch ist dabei das ich noch 7 weiter Teimer für andere Räume laufen habe, die alle gleich definiert sind die und zu den Zeiten auch die Sollwerte umschalten. Nur mein Bad Timer tut es nicht:
READINGS:
2018-11-18 05:00:02 currValue 20.5
2018-11-18 09:47:24 disabled 0
2018-11-18 05:00:02 nextUpdate 2018-11-18 07:00:00
2018-11-18 05:00:02 nextValue 19.5
2018-11-18 04:00:01 state 20.5
So sehen die readings am Sontag um ca 10 Uhr aus. Wie man sieht hätte schon um 7:00 der Sollwert auf 19.5 springen sollen. Aber state ist immernoch 20.5.
Ich habe keine delay condition definiert.
Hier mal das ganze List:
Internals:
COMMAND set $NAME desired-temp $EVENT
CONDITION
DEF FBHK_Bad de 12345|02:00|20.5 12345|05:00|19.5 60|04:00|20.5 60|07:00|19.5 set $NAME desired-temp $EVENT
DEVICE FBHK_Bad
GlobalDaylistSpec
LANGUAGE de
NAME Timer_FBH_Bad
NR 397
Profil 0: Sonntag 04:00:00 20.5, 07:00:00 19.5
Profil 1: Montag 02:00:00 20.5, 05:00:00 19.5
Profil 2: Dienstag 02:00:00 20.5, 05:00:00 19.5
Profil 3: Mittwoch 02:00:00 20.5, 05:00:00 19.5
Profil 4: Donnerstag 02:00:00 20.5, 05:00:00 19.5
Profil 5: Freitag 02:00:00 20.5, 05:00:00 19.5
Profil 6: Samstag 04:00:00 20.5, 07:00:00 19.5
STATE 20.5
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2018-11-18 05:00:02 currValue 20.5
2018-11-18 09:47:24 disabled 0
2018-11-18 05:00:02 nextUpdate 2018-11-18 07:00:00
2018-11-18 05:00:02 nextValue 19.5
2018-11-18 04:00:01 state 20.5
SWITCHINGTIMES:
12345|02:00|20.5
12345|05:00|19.5
60|04:00|20.5
60|07:00|19.5
TIMER:
Timer_FBH_Bad_1:
HASH Timer_FBH_Bad
MODIFIER 1
NAME Timer_FBH_Bad_1
Timer_FBH_Bad_2:
HASH Timer_FBH_Bad
MODIFIER 2
NAME Timer_FBH_Bad_2
Timer_FBH_Bad_3:
HASH Timer_FBH_Bad
MODIFIER 3
NAME Timer_FBH_Bad_3
Timer_FBH_Bad_4:
HASH Timer_FBH_Bad
MODIFIER 4
NAME Timer_FBH_Bad_4
immerSchalten 1
Timer_FBH_Bad_SetTimerOfDay:
HASH Timer_FBH_Bad
MODIFIER SetTimerOfDay
NAME Timer_FBH_Bad_SetTimerOfDay
SETTIMERATMIDNIGHT 1
Timer_FBH_Bad_delayed:
HASH Timer_FBH_Bad
MODIFIER delayed
NAME Timer_FBH_Bad_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
04:00:00 20.5
07:00:00 19.5
1:
02:00:00 20.5
05:00:00 19.5
2:
02:00:00 20.5
05:00:00 19.5
3:
02:00:00 20.5
05:00:00 19.5
4:
02:00:00 20.5
05:00:00 19.5
5:
02:00:00 20.5
05:00:00 19.5
6:
04:00:00 20.5
07:00:00 19.5
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1542502800
PARA 20.5
TIME 02:00
TAGE:
1
2
3
4
5
2:
EPOCH 1542513600
PARA 19.5
TIME 05:00
TAGE:
1
2
3
4
5
3:
EPOCH 1542510000
PARA 20.5
TIME 04:00
TAGE:
0
6
4:
EPOCH 1542520800
PARA 19.5
TIME 07:00
TAGE:
0
6
profile_IDX:
0:
04:00:00 3
07:00:00 4
1:
02:00:00 1
05:00:00 2
2:
02:00:00 1
05:00:00 2
3:
02:00:00 1
05:00:00 2
4:
02:00:00 1
05:00:00 2
5:
02:00:00 1
05:00:00 2
6:
04:00:00 3
07:00:00 4
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
commandTemplate set $NAME desired-temp $EVENT
disable 0
group Timer
room 7.0_Klima
switchInThePast 1
verbose 2
Kann jemand helfen ? Für mich völlig unlogisch.
Zumal ich auch nix daran geschraubt habe. Läuft schon seit Jahren so...
Es sieht so aus, als ob der Maintainer hier nicht mitliest.
Das kann er leider auch nicht mehr.
https://forum.fhem.de/index.php/topic,83149.msg753762.html#msg753762 (https://forum.fhem.de/index.php/topic,83149.msg753762.html#msg753762)
Ich weiß. Ich meinte auch nicht den Entwickler des Moduls "Dietmar63", sondern den Maintainer.
Laut MAINTAINER.txt ist das "igami".
Ich nochmal,
ich muß meine Aussage berichtigen das alles anderen 7 Timer funktionieren. Ich hab gerade festgestellt das alle die 2. Zeit des Tages nicht umschalten.
Die readings nextUpdate und nextValue stimmen immer, aber die currValue passt nicht.
Das ich echt blöd, so spiel meine komplette Fussbodenheizung verrückt und heizt länger als sie soll.
HILFEeeee !!!
Gibt's doch nicht das nur ich dieses Problem habe...
Also ich schmeiß die Heating_Control´s erstmal raus. Ich komme einfach nicht draus was da schief läuft. Und langsam nervt es tierisch das ich meine Solltemperaturen immer nachjustieren muss.
Warum kommt folgendes in deine Readings?
2018-11-18 09:47:24 disabled 0
Und setzt lieber dein Kommando set $NAME desired-temp $EVENT in dem Attribute commandTemplate, statt in der DEF. Also:
defmod Timer_FBH_Bad FBHK_Bad de 12345|02:00|20.5 12345|05:00|19.5 60|04:00|20.5 60|07:00|19.5
attr Timer_FBH_Bad commandTemplate set $NAME desired-temp $EVENT
Zitat von: amenomade am 20 November 2018, 20:28:15
Warum kommt folgendes in deine Readings?
2018-11-18 09:47:24 disabled 0
Weil ich per DOIF an Freien Tagen zwischen diesem und einem "Urlaubs" Timer per disable /enable umschalte.
Und setzt lieber dein Kommando set $NAME desired-temp $EVENT in dem Attribute commandTemplate, statt in der DEF. Also:
defmod Timer_FBH_Bad FBHK_Bad de 12345|02:00|20.5 12345|05:00|19.5 60|04:00|20.5 60|07:00|19.5
attr Timer_FBH_Bad commandTemplate set $NAME desired-temp $EVENT
Das Attribut gab es schon, ich habs jetzt mal testweise aus der def enfernt.
Dieses Attribut ist aber auch in der commandref nicht dokumentiert.
Das Kommando kann man laut ref doch in der def übergeben:
define <name> Heating_Control <device> [<language>] <wochentage;] <profile> [b]<command>[/b]|<condition> Egal, doppelt kann nicht gut sein. Allerdings läuft das schon seit Jahren so. Hat sich wohl über den Sommer im Modul was geändert !?
Ich teste....
ZitatWeil ich per DOIF an Freien Tagen zwischen diesem und einem "Urlaubs" Timer per disable /enable umschalte.
Das hat sich aber am Sonntag um 09:47 Uhr geändert. Wenn das vor 09:47 Uhr auf "disable 1" war, dann hat natürlich das DOIF um 7:00 Uhr nichts getan.
Nee, da hab ich nur nach dem Fehler gesucht und etwas rumgespielt. Ich wollte testen ob beim umschalten der starte wieder berichtigt wird.
Dann zeig bitte wirklich ein "list" des HCs, wenn er fehlerhaft nicht geschaltet hat. Und dazu die Log am theoretischen Zeitpunkt, mit verbose 5.
Da hast Du zu viel rumgespielt:
disable ist von 9:47 Uhr
currValue ist von Sonntag 05:00 Uhr, was gar nicht mit dem Zeitplan stimmt und state ist von 04:00 Uhr mit dem gleichen Wert.
usw...
Ich verstehe wirklich nicht was Du meinst,
Nur der Eintrag disable ist wegen mir auf 9:47. Die anderen Readings habe ich nicht beeinflusst, und das das nicht in den Zeitplan passt, ist ja das was ich nicht verstehe.
Nachdem ich Gestern un die def geändert habe, hat sich leider nix verbessert.
Aber gut, ich werde morgen mal in Ruhe einen Log mit Verbose 5 starten kurz vor einem Schaltpunkt. Dazu gibts dann auch eine zeitnahes List, ohne das ich irgenwie eingreife.
ZitatDie anderen Readings habe ich nicht beeinflusst
Mit disable schon, insbesondere mit switchinthepast.
ZitatAber gut, ich werde morgen mal in Ruhe einen Log mit Verbose 5 starten kurz vor einem Schaltpunkt. Dazu gibts dann auch eine zeitnahes List, ohne das ich irgenwie eingreife.
Sehr schön.
Hast Du vielleicht noch andere Devices (at, DOIF, weekdaytimer, notify, usw...), die dieses HC Device beinflüssen können? Oder irgenwas, was Heating_Control_SetAllTemps() aufruft?
Wenn Du
{ localtime() } im Befehlfeld von Fhem eingibst, ist es koherent mit deiner eigene Uhrzeit?
Ahja und auch bitte das Ergebnis von
version WeekdayTimer
version Heating_Controlzeigen
Ich hab nochmal selber rumgeforscht und den Fehler scheinbar gefunden.
In einem DOIF war ein eigentlich unnötiges do always drin das ich mal rausgenommen habe, und nun schalten die Timer wieder so wie sie sollen.
Ich würde nun nur noch gerne verstehen wie das zustande kam.
Frage also: Warum führt es zu dem beschriebenen Effektetn wenn jede Nacht um 1:00 Uhr folgende Zeile ausgeführt wird:
(set Timer_FBH_.* enable, set U_Timer_FBH.* disable,
{Heating_Control_SetAllTemps()})
So schalte ich zwischen den normalen Profilen und den (U_timer) Urlaubs Timer Zeiten um.
Heating_Control_SetAllTemp sendet an alle HC Devices ein Heating_Control_SetTemp
Heating_Control_SetTemp löscht alle Timer und setzt die wieder nach DEF
Um genau sagen zu können, was passiert ist, muss man in den Logs schauen (Log vom DOIF und vom Device, mit verbose 5)
Hallo zusammen !
Bezüglich Heating_Control_SetTemp, welches ich beim Heimkommen unterschiedlicher Familienmitglieder zur Ansteuerung unterschiedliche Thermostate/Heizkörper neuerdings verwende sehe ich im Log folgendes
2019.01.11 14:48:22 2: AMS292HomeState: {Heating_Control_SetTemp("HC_WC")}: HASH(0x44a5968)
2019.01.11 14:48:22 2: AMS292HomeState: {Heating_Control_SetTemp("HC_AK")}: HASH(0x5b9db40)
2019.01.11 14:48:22 2: AMS292HomeState: {Heating_Control_SetTemp("HC_VZ")}: HASH(0x5b781d8)
2019.01.11 14:48:22 2: AMS292HomeState: {Heating_Control_SetTemp("HC_EZ")}: HASH(0x5b6db10)
2019.01.11 15:02:17 2: ElternHomeState: {Heating_Control_SetTemp("HC_HR")}: HASH(0x450ff50)
Auch wenn ich das {Heating_Control_SetTemp("HC_AK")} in der Befehlszeile eingebe kommt eine Meldung HASH(0x......). Die Befehle scheinen richtig ausgeführt zu werden, doch das HASH(0x......) irritiert mich etwas. Was bedeutet es und wozu brauche ich es ?
Danke
Ich habe mit Heating_Control ein Profil (hc_buero) angelegt, damit ein Thermostat Eurotronic Spirit als device (TBuero) in Abhängigkeit des Tages und der Uhrzeit die entsprechende Temperatur setzt.
Das funktioniert auch zuverlässig.
Allerdings schaffe ich es nicht, dass ich mit Hilfe des widget wdtimer für FTUI die hinterlegten Werte des Profil zu verändern. Kann mir bitte jemand ein Beispiel geben, wie ich das umsetzen muss oder geht das in Kombination mit Heating_Control gar nicht?
Wenn ich statt Heating_Control ein Profil mit WeekdayTimer definieren klappt es problemlos.
Gruß
eurofinder
Das liegt daran das in der widget_wdtimer.js das setzten der neuen Parameter fest auf WeekdayTimer programmiert ist.
Ich habe mir so geholfen das ich folgende Zeile in der Datei geändert habe:
//Aktualisiertes define setzen
cmd = "defmod "+device+" Heating_Control "+arr_newconfig[2][1]+" "+arr_newconfig[2][2]+" ";
Schöner wäre natürlich wenn man das zu setzende Timer Device vielleicht per Attribut im Widget angeben könnte
Wink an den Schöpfer :-)
Nach dem ändern der Datei mußt Du noch per exclude_from_update dafür sorgen das das Widget beim nächsten Update nicht wieder überschriebe wird.
So geht es erstmal...
Danke, werde ich mal probieren.
Gruß
eurofinder
Hallo zusammen,
mir ist heute ein Problem mit meinen Heating_Controls aufgefallen. Immer dann wenn ich !$we verwende, wird dieser Eintrag bei der Berechnung der Schaltzeiten ignoriert. Nur die Werte mit $we funktionieren. Ich kann leider nicht sagen, seit wann / welchem Update von fhem das so ist.
Kann das jemand bestätigen?
Wäre super, wenn der Fehler bald korrigiert werden könnte, da meine Heizungssteuerung somit unter der Woche nicht funktioniert. Mit dem Workaround 12345 für die Wochentage geht es zwar, aber dann muss ich alles umbauen :(
Internals:
COMMAND { myHeatingControl($NAME,$EVENT) }
CONDITION
DEF E1_wz_THKV_Heizkoerper_Fenster de 12345|06:04|comfort !$we|07:34|eco:1 !$we|15:34|comfort !$we|22:49|eco:0 $we|08:04|comfort $we|23:59|eco:0 { myHeatingControl($NAME,$EVENT) }
DEVICE E1_wz_THKV_Heizkoerper_Fenster
FUUID 5c42dbd3-f33f-2e5f-c354-d64461a8993f395e
GlobalDaylistSpec
LANGUAGE de
NAME E1_wz_THKV_Heizkoerper_Fenster_hC_01
NR 153
Profil 0: Sonntag 08:04:00 comfort, 23:59:00 eco:0
Profil 1: Montag 06:04:00 comfort, 08:04:00 comfort, 23:59:00 eco:0
Profil 2: Dienstag 06:04:00 comfort, 08:04:00 comfort, 23:59:00 eco:0
Profil 3: Mittwoch 06:04:00 comfort, 08:04:00 comfort, 23:59:00 eco:0
Profil 4: Donnerstag 06:04:00 comfort, 08:04:00 comfort, 23:59:00 eco:0
Profil 5: Freitag 06:04:00 comfort, 08:04:00 comfort, 23:59:00 eco:0
Profil 6: Samstag 08:04:00 comfort, 23:59:00 eco:0
Profil 7: Wochenende 08:04:00 comfort, 23:59:00 eco:0
Profil 8: Werktags 07:34:00 eco:1, 15:34:00 comfort, 22:49:00 eco:0
STATE nächste Schaltung: 2019-03-20 23:59:00 comfort ==> eco
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2019-03-20 20:04:52 currValue comfort
2019-03-20 19:55:06 disabled 0
2019-03-20 20:04:52 nextUpdate 2019-03-20 23:59:00
2019-03-20 20:04:52 nextValue eco:0
2019-03-20 20:04:52 state comfort
SWITCHINGTIMES:
12345|06:04|comfort
!$we|07:34|eco:1
!$we|15:34|comfort
!$we|22:49|eco:0
$we|08:04|comfort
$we|23:59|eco:0
TIMER:
E1_wz_THKV_Heizkoerper_Fenster_hC_01_4:
HASH E1_wz_THKV_Heizkoerper_Fenster_hC_01
MODIFIER 4
NAME E1_wz_THKV_Heizkoerper_Fenster_hC_01_4
E1_wz_THKV_Heizkoerper_Fenster_hC_01_5:
HASH E1_wz_THKV_Heizkoerper_Fenster_hC_01
MODIFIER 5
NAME E1_wz_THKV_Heizkoerper_Fenster_hC_01_5
immerSchalten 1
E1_wz_THKV_Heizkoerper_Fenster_hC_01_6:
HASH E1_wz_THKV_Heizkoerper_Fenster_hC_01
MODIFIER 6
NAME E1_wz_THKV_Heizkoerper_Fenster_hC_01_6
E1_wz_THKV_Heizkoerper_Fenster_hC_01_SetTimerOfDay:
HASH E1_wz_THKV_Heizkoerper_Fenster_hC_01
MODIFIER SetTimerOfDay
NAME E1_wz_THKV_Heizkoerper_Fenster_hC_01_SetTimerOfDay
SETTIMERATMIDNIGHT 1
E1_wz_THKV_Heizkoerper_Fenster_hC_01_delayed:
HASH E1_wz_THKV_Heizkoerper_Fenster_hC_01
MODIFIER delayed
NAME E1_wz_THKV_Heizkoerper_Fenster_hC_01_delayed
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
08:04:00 comfort
23:59:00 eco:0
1:
06:04:00 comfort
08:04:00 comfort
23:59:00 eco:0
2:
06:04:00 comfort
08:04:00 comfort
23:59:00 eco:0
3:
06:04:00 comfort
08:04:00 comfort
23:59:00 eco:0
4:
06:04:00 comfort
08:04:00 comfort
23:59:00 eco:0
5:
06:04:00 comfort
08:04:00 comfort
23:59:00 eco:0
6:
08:04:00 comfort
23:59:00 eco:0
7:
08:04:00 comfort
23:59:00 eco:0
8:
07:34:00 eco:1
15:34:00 comfort
22:49:00 eco:0
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1553058240
PARA comfort
TIME 06:04
TAGE:
1
2
3
4
5
2:
EPOCH 1553063640
PARA eco:1
TIME 07:34
TAGE:
8
3:
EPOCH 1553092440
PARA comfort
TIME 15:34
TAGE:
8
4:
EPOCH 1553118540
PARA eco:0
TIME 22:49
TAGE:
8
5:
EPOCH 1553065440
PARA comfort
TIME 08:04
TAGE:
7
6:
EPOCH 1553122740
PARA eco:0
TIME 23:59
TAGE:
7
profile_IDX:
0:
08:04:00 5
23:59:00 6
1:
06:04:00 1
08:04:00 5
23:59:00 6
2:
06:04:00 1
08:04:00 5
23:59:00 6
3:
06:04:00 1
08:04:00 5
23:59:00 6
4:
06:04:00 1
08:04:00 5
23:59:00 6
5:
06:04:00 1
08:04:00 5
23:59:00 6
6:
08:04:00 5
23:59:00 6
7:
08:04:00 5
23:59:00 6
8:
07:34:00 2
15:34:00 3
22:49:00 4
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Wohnzimmer (Fenster)
commandTemplate set $NAME desired-temp $EVENT
disable 0
group Zeitsteuerung Heizung
room Heizungsraum
sortby 4
stateFormat {
my $cValue = ReadingsVal("E1_wz_THKV_Heizkoerper_Fenster_hC_01","currValue","");
my $idx = index($cValue,":");
if ($idx != -1) {
$cValue = substr($cValue,0,$idx);
}
my $nValue = ReadingsVal("E1_wz_THKV_Heizkoerper_Fenster_hC_01","nextValue","");
$idx = index($nValue,":");
if ($idx != -1) {
$nValue = substr($nValue,0,$idx);
}
return "nächste Schaltung: ".ReadingsVal("E1_wz_THKV_Heizkoerper_Fenster_hC_01","nextUpdate","")." ".$cValue." ==> ".$nValue
}
Beste Grüße
Torsten
Könnte eventuell mit dieser Disskusion
https://forum.fhem.de/index.php/topic,98583.0.html (https://forum.fhem.de/index.php/topic,98583.0.html)
zusammenhängen.
Das Problem mit $we ist bei mir behoben, ich hatte ein eigenes Holiday device verwendet und die Logik hat sich geändert.
Trotzdem funktionieren meine heating_control und weekdaytimer nicht richtig! Die berechneten Schaltzeiten stimmen nicht für die Wochentage und Wochenenden. Hier noch ein list eines weekdaytimer:
Internals:
COMMAND { myWeekdayTimer($NAME,$EVENT) }
CONDITION
DEF KG_hz_ZS_Zirkulationspumpe de !$we|04:30|on-for-timer !$we|16:30|on-for-timer $we|06:30|on-for-timer $we|18:30|on-for-timer { myWeekdayTimer($NAME,$EVENT) }
DEVICE KG_hz_ZS_Zirkulationspumpe
FUUID 5c42dbd1-f33f-2e5f-de1e-369a0a62fe6c8946
GlobalDaylistSpec
LANGUAGE de
NAME KG_hz_ZS_Zirkulationspumpe_wT_01
NR 83
Profil 0: Sonntag 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 1: Montag 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 2: Dienstag 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 3: Mittwoch 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 4: Donnerstag 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 5: Freitag 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 6: Samstag 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 7: Wochenende 06:30:00 on-for-timer, 18:30:00 on-for-timer
Profil 8: Werktags 04:30:00 on-for-timer, 16:30:00 on-for-timer
STATE nächste Schaltung: 2019-03-22 06:30:00 on-for-timer
STILLDONETIME 0
TYPE WeekdayTimer
READINGS:
2019-03-21 21:17:52 currValue on-for-timer
2019-03-21 21:17:52 nextUpdate 2019-03-22 06:30:00
2019-03-21 21:17:52 nextValue on-for-timer
2019-03-21 21:17:52 state active
SWITCHINGTIMES:
!$we|04:30|on-for-timer
!$we|16:30|on-for-timer
$we|06:30|on-for-timer
$we|18:30|on-for-timer
TIMER:
KG_hz_ZS_Zirkulationspumpe_wT_01_SetTimerOfDay:
HASH KG_hz_ZS_Zirkulationspumpe_wT_01
MODIFIER SetTimerOfDay
NAME KG_hz_ZS_Zirkulationspumpe_wT_01_SetTimerOfDay
SETTIMERATMIDNIGHT 1
dayNumber:
!$we 8
$we 7
di 2
do 4
fr 5
mi 3
mo 1
sa 6
so 0
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
06:30:00 on-for-timer
18:30:00 on-for-timer
1:
06:30:00 on-for-timer
18:30:00 on-for-timer
2:
06:30:00 on-for-timer
18:30:00 on-for-timer
3:
06:30:00 on-for-timer
18:30:00 on-for-timer
4:
06:30:00 on-for-timer
18:30:00 on-for-timer
5:
06:30:00 on-for-timer
18:30:00 on-for-timer
6:
06:30:00 on-for-timer
18:30:00 on-for-timer
7:
06:30:00 on-for-timer
18:30:00 on-for-timer
8:
04:30:00 on-for-timer
16:30:00 on-for-timer
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
profil:
1:
EPOCH 1553139000
PARA on-for-timer
TIME 04:30
TAGE:
8
2:
EPOCH 1553182200
PARA on-for-timer
TIME 16:30
TAGE:
8
3:
EPOCH 1553146200
PARA on-for-timer
TIME 06:30
TAGE:
7
4:
EPOCH 1553189400
PARA on-for-timer
TIME 18:30
TAGE:
7
profile_IDX:
0:
06:30:00 3
18:30:00 4
1:
06:30:00 3
18:30:00 4
2:
06:30:00 3
18:30:00 4
3:
06:30:00 3
18:30:00 4
4:
06:30:00 3
18:30:00 4
5:
06:30:00 3
18:30:00 4
6:
06:30:00 3
18:30:00 4
7:
06:30:00 3
18:30:00 4
8:
04:30:00 1
16:30:00 2
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
Attributes:
alias Zeitsteuerung Zirkulationspumpe
commandTemplate set $NAME $EVENT
group Zirkulationspumpe
icon sani_pump
room Heizungsraum,Zentrale Steuerung
stateFormat nächste Schaltung: nextUpdate nextValue
Fhem have ich zwischendurch auch neu gestartet und die Werte verändern sich nicht.
Beste Grüße
Torsten
Hallo Leute,
Beta-User und ich haben und der aktuellen Problematik mit dem Weekdaytimer und mehreren angegebenen holiday2we Devices unter global angenommen.
Wir haben einen fix fertig den wir gerne einchecken würden. Aber eventuell kann der ein oder andere noch einmal kurz testen.
Hat überhaupt außer ein User noch jemand Probleme mit dem Modul?
Grüße
Hallo,
ist dies eventuell auch ein Thema für Euch? Bei mir schaltet WT an Feiertagen falsch, da hier die Enstellungen des Wochentages vor den Einstellungen des Feiertages ziehen. Da unter FTUI leider !WE aktuell nicht definiert werden kann, war mein Vorschlag, dass Feiertagseinstellungen die Wochentagseinstellungen übersteuern, sofern beides definiert ist.
https://forum.fhem.de/index.php/topic,48106.msg932069.html#msg932069 (https://forum.fhem.de/index.php/topic,48106.msg932069.html#msg932069)
Viele Grüße
Jürgen
Zitat von: juemuc am 21 April 2019, 12:27:32
Hallo,
ist dies eventuell auch ein Thema für Euch? Bei mir schaltet WT an Feiertagen falsch, da hier die Enstellungen des Wochentages vor den Einstellungen des Feiertages ziehen. Da unter FTUI leider !WE aktuell nicht definiert werden kann, war mein Vorschlag, dass Feiertagseinstellungen die Wochentagseinstellungen übersteuern, sofern beides definiert ist.
https://forum.fhem.de/index.php/topic,48106.msg932069.html#msg932069 (https://forum.fhem.de/index.php/topic,48106.msg932069.html#msg932069)
Viele Grüße
Jürgen
Moin,
sorry für die etwas späte Antwort, und FTUI kenne ich nicht daher kann ich dazu nur zum Teil was sagen...
Also:
Grundsätzlich geht $we (korrekterweise eigentlich: eine ähnliche Abfrage wie IsWe() bzw. ein get auf holiday-Devices) bei WeekDaytimer der normalen Wochentagssteuerung vor.
Kann es sein, dass Feiertage bei dir in FHEM allgemein nicht erkannt werden?
Insbesondere: Der Hinweis, dass !WE aus FTUI nicht funktioniert, deutet darauf hin, dass eine Änderung in der holiday2we-Behandlung in fhem.pl noch nicht angekommen ist. Bisher reichte es, via stateFormat den STATE von einem in holiday2we eingetragenen Device zu manipulieren, jetzt muß das Reading "state" korrekt gesetzt sein, STATE wird ignoriert.
Wenn das zutrifft, sollte man das von der FTUI-Seite aus fixen, denn das ist (jetzt) das aktuelle Verhalten von fhem.pl allgemein.
Ansonsten:
In Abstimmung mit igami bin ich grade dabei, an den Modulen (eigentlich nur am WeekdayTimer) ein paar Dinge zu ändern, v.a. bei Gelegenheit die Doppelung der Module zu beenden. Heating_Control dürfte daher auf mittlere Sicht nach Contrib gehen.
Wäre nett, wenn sich jemand am Testen beteiligen würde, eine erste Vorversion von WeekdayTimer, die auch die Heating_Control-Funktionalität mit umfaßt, ist hier zu finden: https://forum.fhem.de/index.php/topic,100179.0.html.
Gruß, Beta-User
Zitat von: Dietmar63 am 07 April 2015, 20:07:12
ja, das ist so.
Ich habe mich aus verschiedenen Gründen entschieden die Tagesangabe wie in DOIF zu ändern.
0 Sonntag
1 Montag
2 Dienstag
3 Mittwoch
4 ...
7 Wochenende ($we)
8 Wochentag (!$we)
Sehe ich das richtig, dass die Änderung vier(!) Jahre alt ist?
Müsste doch inzwischen jeder mit bekommen haben oder nicht?
Vielleicht kann man diese Meldung im Log irgendwann mal abstellen?
Nur mal so ein Vorschlag *duckundweg*
Zitat von: JamBay am 30 Mai 2019, 19:47:31
Vielleicht kann man diese Meldung im Log irgendwann mal abstellen?
Irgendwann mal war eben, danke für den Hinweis :) .
Zur Info: bzgl. der neuen Optionen in holiday2we mit weekEnd und noWeekEnd gibt es hier eine Testversion:
https://forum.fhem.de/index.php/topic,101899.msg953932.html#msg953932
Bei der Gelegenheit auch die Bitte an alle ggf. noch mitlesenden Heating_Control-Nutzer:
Bisher gab es keine Klagen von denen, die auf WeekdayTimer umgestellt hatten.
Will HC irgendwann mal ausphasen...
Hallo,
seit gestern nach einem Update habe ich folgende Fehlermeldungen im LOG. Hat sich an der Sprache was geaendert ?
2020.01.29 00:00:06 1: [HC.HK_BUERO] invalid daylist in HC.HK_BUERO <Mo,Di> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_BUERO] invalid daylist in HC.HK_BUERO <Mo,Di> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_BUERO] invalid daylist in HC.HK_BUERO <Mo,Di> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_BUERO] invalid daylist in HC.HK_BUERO <Mo,Di> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS] invalid daylist in HC.HK_KIDS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS] invalid daylist in HC.HK_KIDS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS] invalid daylist in HC.HK_KIDS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS] invalid daylist in HC.HK_KIDS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_WOHNEN_ZUHAUSE] invalid daylist in HC.HK_WOHNEN_ZUHAUSE <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_WOHNEN_ZUHAUSE] invalid daylist in HC.HK_WOHNEN_ZUHAUSE <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_MORGENS] invalid daylist in HC.HK_MORGENS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_MORGENS] invalid daylist in HC.HK_MORGENS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_MORGENS] invalid daylist in HC.HK_MORGENS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_MORGENS] invalid daylist in HC.HK_MORGENS <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_SCHLAFEN] invalid daylist in HC.HK_SCHLAFEN <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_SCHLAFEN] invalid daylist in HC.HK_SCHLAFEN <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_SCHLAFEN] invalid daylist in HC.HK_SCHLAFEN <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_SCHLAFEN] invalid daylist in HC.HK_SCHLAFEN <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_SCHLAFEN] invalid daylist in HC.HK_SCHLAFEN <Sa,So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_SCHLAFEN] invalid daylist in HC.HK_SCHLAFEN <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS_URLAUB] invalid daylist in HC.HK_KIDS_URLAUB <Mo-So,$we> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS_URLAUB] invalid daylist in HC.HK_KIDS_URLAUB <Mo-So,$we> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS_URLAUB] invalid daylist in HC.HK_KIDS_URLAUB <Mo-So,$we> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.HK_KIDS_URLAUB] invalid daylist in HC.HK_KIDS_URLAUB <Mo-So,$we> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.Test] invalid daylist in HC.Test <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.Test] invalid daylist in HC.Test <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.Test] invalid daylist in HC.Test <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
2020.01.29 00:00:06 1: [HC.Test] invalid daylist in HC.Test <Mo-So> use one of 012345678 or (su|mo|tu|we|th|fr|sa|$we|!$we)
Internals:
CHANGED
COMMAND
CONDITION ((Value("DS_Heizen") eq "on") && ((Value("D_KW") % 2) == 0))
DEF HK_BUERO Mo,Di|06:00|21 Mo,Di|18:00|15 ((Value("DS_Heizen") eq "on") && ((Value("D_KW") % 2) == 0))
DEVICE HK_BUERO
FUUID 5c4a157f-f33f-623c-ac28-37390b5134fe0c9a
GlobalDaylistSpec
LANGUAGE en
NAME HC.HK_BUERO
NR 188
STATE inactive
STILLDONETIME 0
TYPE Heating_Control
READINGS:
2020-01-28 08:17:59 currValue 21
2020-01-28 08:24:03 nextUpdate 1970-01-01 01:00:00
2020-01-28 08:17:59 nextValue 15
2020-01-28 08:24:03 state inactive
SWITCHINGTIMES:
Mo,Di|06:00|21
Mo,Di|18:00|15
TIMER:
HC.HK_BUERO_SetTimerOfDay:
HASH HC.HK_BUERO
MODIFIER SetTimerOfDay
NAME HC.HK_BUERO_SetTimerOfDay
SETTIMERATMIDNIGHT 1
dayNumber:
!$we 8
$we 7
fr 5
mo 1
sa 6
su 0
th 4
tu 2
we 3
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
WEDAYS:
3 1
4 1
longDays:
de:
Sonntag
Montag
Dienstag
Mittwoch
Donnerstag
Freitag
Samstag
Wochenende
Werktags
en:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
weekend
weekdays
fr:
Dimanche
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
weekend
jours de la semaine
nl:
Zondag
Maandag
Dinsdag
Woensdag
Donderdag
Vrijdag
Zaterdag
weekend
werkdagen
profil:
1:
EPOCH 1580274000
PARA 21
TIME 06:00
WE_Override 0
TAGE:
2:
EPOCH 1580317200
PARA 15
TIME 18:00
WE_Override 0
TAGE:
shortDays:
de:
so
mo
di
mi
do
fr
sa
$we
!$we
en:
su
mo
tu
we
th
fr
sa
$we
!$we
fr:
di
lu
ma
me
je
ve
sa
$we
!$we
nl:
zo
ma
di
wo
do
vr
za
$we
!$we
Attributes:
commandTemplate set $NAME desiredTemperature $EVENT
room Heizung
Jein, geändert hat sich die Frage, wo der benutzte Standard herkommt. Den hat das Modul früher mal auf "de" gesetzt, heute kommt der aus "global". Würde also tippen, dass dort "EN" gesetzt ist...
Kannst du entweder zentral beheben (via global, dann nach save FHEM neu starten), oder du mußt bei jedem betroffenen WDT die Angabe ergänzen, dann paßt es auch wieder.
Hi,
in "global" war kein Attribut bzgl. Language gesetzt.
Habe dies nun erzeugt und auf DE gesetzt.
War das das, was Du meintest ?
Gruss
Zitat von: cotecmania am 29 Januar 2020, 11:34:21
War das das, was Du meintest ?
Ja.
Nach einem Neustart sollte dann auch wieder in den Internals (bei den WDT) "de" als LANGUAGE erscheinen.
Hallo.
Bemerke gerade das mein Relais (Brenneransteuerung) jetzt alle 30 sec. ein/aus schaltet.
Verstehe aber nicht warum. Das Modul läuft schon 7 Jahre, weiss leider nicht mehr die definition des Aktors.
Wenn ich den Aktor manuell schalte ,ok. Sobald aber HCS auf off geht schaltet er den Aktor auch ab. Habe aber HCS disabled, trotzdem arbeitet das Modul weiter.
Bin echt am rätseln.
Der WeekdayTimer ist es sehr sicher nicht, der im 30-Sek.-Rhythmus schaltet.