HM-TC-IT-WM-W-EU controlManu vs controlMode

[holgerschlegel]

Hallo Zusammen,

irgendwie verstehe ich den Zusammenhang zwischen den beiden im Betreff genannten Readings noch nicht.
- controlManu kann dem GUI nach auf "on", "off", sowie Temperaturen in 0.5° Schritten gesetzt werden.
- controlMode kann dem GUI nach auf "auto", "boost", "day", "night" gesetzt werden.

Wenn ich über FHEM den "controlMode" eines solchen Devices auf "night" setze, wird zwar die "desired-temp" auf den Wert von "R-nightTemp" gesetzt (soweit gut), der angezeigte "controlMode" bleibt jedoch "auto". Daraus schließe ich, das die "desired-temp" beim nächsten Schaltpunkt in der eingestellten TempList wieder auf den dann gültigen Wert aus der TempList gesetzt wird. Das verhalten entspricht somit dem manuellen verstellen der Zieltemperatur über das Drehrad am Device.
Der Versuch zusätzlich "controlManu" auf "off" zu setzen, führt zwar zum "controlMode" manuell, aber auch zur "desired-temp" "off". Was im Winter ziemlich kalt ist.

Ich möchte gerne die Zieltemperatur des Device aus FHEM in Abhängigkeit von Uhrzeit und Feiertagen aus FHEM heraus steuern. Die aktuelle Idee dafür ist wie folgt:
- Die TempList des Device enthält das normale Wochenprogramm für Arbeitswochen. Das Device läuft standardmäßig im "auto"-Modus damit es auch dann noch funktioniert wenn FHEM (oder der RasPi auf dem es läuft) mal ausfällt oder aus anderen Gründen nicht aktiv ist.
- Ein DOIF erkennt mittels des Holiday-Moduls ob der Tag ein Feiertag oder Urlaub (mit Unterscheidung nach Anwesend und Abwesend) ist.
-- Bei "Urlaub Abwesend" soll das Device auf "manuell" und die "nightTemp" des Geräts (oder eine andere, noch kleinere Temperatur) gesetzt werden.
-- Bei Feiertag oder bei "Urlaub Anwesend" soll das Device auf "manuell" stehen, und eine Zeitsteuerung im DOIF steuert zwischen "nightTemp" und "dayTemp".

Die DEFinition des geplanten DOIF sieht aktuell beispielhaft wie folgt aus:

Code Auswählen Erweitern


([Feiertage] eq 'none')
() ## Automatik
DOELSEIF ([Feiertage] =~ '(abw)')
() ## Dauerhaft abwesend (absenken auf 15)
DOELSEIF  ([07:00-21:30])
() ## Heizen (auf R-dayTemp)
DOELSE
() ## Absenken (auf R-nightTemp)

Das Ding funktioniert wie gewünscht, enthält aber wie man sieht noch keine Steuerbefehle.

Allerdings stehe ich da gerade auf dem sprichwörtlichen Schlauch ... und mir ist nicht klar ob ich das nur über "controlMode" umsetzten kann, oder ob auch "controlManu" notwendig ist. Speziell wegen dem oben beschriebenen Wechsel auf "auto" mit anderer Zieltemperatur.
Oder anders gefragt: Welche Befehle an das HM-TC-IT-WM-W-EU Device (oder vermutlich an dessen Climate Kanal) müssen in die () geschrieben werden damit das ganze wie gewünscht funktioniert?

(Verdammt, mehr Text geworden als ich gedacht hatte...)
Grüße
Holger

[MadMax-FHEM]

set HM-TC-IT-WM-W-EU_Climate controlManu 15.0

bzw. lässt sich über ReadingsVal("HM-TC-IT-WM-W-EU_Climate", "R-nightTemp", 17.0) die Night-Temp auslesen und statt 15.0 beim set-Befehl einsetzen...

Gleiches geht mit der Tag-Temp...

Nach dem Setzen auf controlMode auto evtl. noch direkt die Temp korrigieren, sonst läuft es erst mal mit der aktuellen Temp bis zum nächsten Schaltpunkt weiter...

[sumsum]

Hallo Holger,

eigentlich musst man sich entscheiden ob man alles von FHEM steuert oder vom Thermostat. Bei Steuerung von FHEM sehe ich eigentlich nur den manuellen Mode sinnvoll. Man gibt immer alle Temperaturen an.
Bei Steuerung vom Thermostat (Auto Mode) hinterlegt man die Wochenprogramme (3 sind möglich) im Thermostat. Von FHEM kann man dann zwischen diesen wechseln.

Code Auswählen Erweitern

set UG.Wz.Wandthermostat.Climate regSet weekPrgSel prog1

Code Auswählen Erweitern

set UG.Wz.Wandthermostat.Climate regSet weekPrgSel prog2

Code Auswählen Erweitern

set UG.Wz.Wandthermostat.Climate regSet weekPrgSel prog3

Im Auto Mode wird, wie du schon gesagt hast, jede temporäre Änderung beim nächsten Schaltpunkt überschrieben.

Gruss

Ulf

[holgerschlegel]

Hallo Ulf,

das mit den 3 Wochenprogrammen und "regSet weekPrgSel progX" (mit passendem X) verwende ich aktuell.
Das gerade vergangene Osterwochenende hat mir aber mal wieder gezeigt, das diese Variante (zumindest bei mir) nicht zuverlässig funktioniert.

Morgens um 00:01 Uhr wird über ein AT eine Perl-Funktion ausgeführt, die zuerst ermittelt ob prog1, prog2 oder prog3 das richtige für den Tag ist, und dieses in ein Dummy setzt. An diesem Dummy hängt ein Notify welcher dann eine zweite Perl-Funktion ausführt, die das Zielprogramm in einer Schleife mittels regSet in alle fünf Thermostate setzt. Leider war es z.B. heute so, das gegen 6:00 Uhr lediglich 3 der 5 Thermostate den korrekten Zeitplan angezeigt haben. Die beiden anderen standen auch heute Abend (~ 18:00 Uhr) noch auf set_prog1 anstatt auf prog1 (über Ostern war prog2 aktiv). Ein ähnliches (Fehl-)Verhalten hatte ich bereits beim Übergang von prog1 auf prog2 vor Ostern beobachtet. Auch hier haben nicht alle Thermostate sauber umgeschaltet ohne das ich noch mal den Boost-Knopf gedrückt habe.


Daher bin ich auf der Suche nach einer alternativen Lösung mit Auto-Standard-Programm für normale Arbeitswochen, und manueller Steuerung durch FHEM für Ausnahmen (wie Feiertage und Urlaube).

Grüße
Holger

[martinp876]

Ohne logs kann ich einmal raten. Ich vermute du Sendest an alle tcs zeitgleich. Da es bursts sind ist vermute ich einen Bug in fhem. Es wird nicht gequeued sondern gleich mit dem senden begonnen. Da kommen nicht alle Kommandos durch. Das q-ing muss hier greifen.
Werde am Wochenende einmal sehen. Falls du deine Kommandos 1min verzögert setzt ist alles ok.

[chris1284]

ein Notify welcher dann eine zweite Perl-Funktion ausführt, die das Zielprogramm in einer Schleife mittels regSet in alle fünf Thermostate setzt. Leider war es z.B. heute so, das gegen 6:00 Uhr lediglich 3 der 5

warum der aufwand? wenn einfache programsets schon nicht funktionieren setze ich noch mehr?
ich würde einfach deinen aktuellen ansatz "das mit den 3 Wochenprogrammen und "regSet weekPrgSel progX" (mit passendem X)"zum laufen bringen.

ein at statt einem do if welches um 00:01 uhr das programm abhängig vom tag setzt
vorher die 3 programme im wandth. richtig eintragen
at ohne syntax

Code Auswählen Erweitern


at_heizung at *00:01:00 {
if (Feiertage eq 'none' ){ fhem("set UG.Wz.Wandthermostat.Climate regSet weekPrgSel prog1"}
elseif(Feiertage =~ 'abw') {in auto programm 2 schalten welches durchgängig 15° fährt }
else { in auto programm 3 schalten welches 07:00-21:30 21 und außerhalb der zeit 17° fährt }


spart die ganzen perl routinen und mindert so auch die fehlerquellen. schaltet jemand mal auf manu wird spätestens um mitternacht alles korrigiert. oder man lässt das at alle 12h / 6h  /x h laufen um so sicher zustellen das alles auf auto steht. auch eine prüfung ob bereits das zum tag passende prog läuft wäre denkbar

sprich
if feriertag eq none and prog1 -> do nothing
elseif feriertag eq none and not prog1 -> set prog1
elseif Feiertage =~ 'abw' and prog2  -> do nothing
elseif Feiertage =~ 'abw' and not prog2 -> set prog2
......

[holgerschlegel]

Hallo,

das mit der Verzögerung (1 Minute) zwischen den Kommandos werde ich mal ausprobieren. Jetzt wo du das sagst bzw. schreibt fällt mir ein, das ich hier im Forum mal etwas zu genau dem Thema gelesen hatte ...


Der Umweg über ein Dummy (welches bei mir Tagtyp heist) hat den Zweck das ich für besondere Fälle (z.B. arbeiten von zu Hause, was 1-2 Mal im Jahr passiert) manuell alle Thermostate an einer zentralen Stelle umstellen kann.
Durch die Schleife in der Perl-Funktion benötige ich außerdem nur einen Satz aus AT, Dummy, und Notify. Egal wie viele Thermostate damit gesteuert werden. Und nicht je Thermostat ein eigenes Dummy.

(Mal davon ab, das mir das die Gelegenheit gab, mich mal wieder zumindest etwas mit Perl zu beschäftigen...)


Grüße
Holger

[holgerschlegel]

Ich habe gerade noch mal in der aktuellen fhem.log Datei nachgeschaut, ob die letzte Umschaltung des Registers weekPrgSel evtl. zu Fehlermeldungen geführt hat und dabei die folgenden Zeilen gefunden:

Code Auswählen Erweitern


2016.03.29 00:01:00 1: set Tagtyp 1_Arbeit
2016.03.29 00:01:00 1: setHeatingWeekPrgFromDayType for 1_Arbeit
2016.03.29 00:01:00 3: CUL_HM set Az.Thermostat.Climate regSet weekPrgSel prog1
2016.03.29 00:01:00 3: CUL_HM set Ba.Thermostat.Climate regSet weekPrgSel prog1
2016.03.29 00:01:00 3: CUL_HM set Ku.Thermostat.Climate regSet weekPrgSel prog1
2016.03.29 00:01:00 3: CUL_HM set Sz.Thermostat.Climate regSet weekPrgSel prog1
2016.03.29 00:01:00 3: CUL_HM set Wz.Thermostat.Climate regSet weekPrgSel prog1
2016.03.29 00:01:04 3: CUL_HM set Az.Thermostat.Climate getConfig
2016.03.29 00:01:08 3: CUL_HM set Ba.Thermostat.Climate getConfig
2016.03.29 00:01:48 1: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2016.03.29 00:01:51 1: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2016.03.29 00:01:52 1: HMLAN_Parse: HMLAN1 new condition timeout
2016.03.29 00:01:52 1: localhost:1234 disconnected, waiting to reappear (HMLAN1)
2016.03.29 00:01:52 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.03.29 00:01:52 1: localhost:1234 reappeared (HMLAN1)
2016.03.29 00:01:52 1: HMLAN_Parse: HMLAN1 new condition init
2016.03.29 00:02:00 1: localhost:1234 disconnected, waiting to reappear (HMLAN1)
2016.03.29 00:02:00 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.03.29 00:02:00 1: localhost:1234 reappeared (HMLAN1)
2016.03.29 00:02:00 1: HMLAN_Parse: HMLAN1 new condition init
2016.03.29 00:02:01 1: localhost:1234 disconnected, waiting to reappear (HMLAN1)
2016.03.29 00:02:01 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.03.29 00:02:01 1: localhost:1234 reappeared (HMLAN1)
2016.03.29 00:02:01 1: HMLAN_Parse: HMLAN1 new condition init
2016.03.29 00:02:04 1: HMLAN_Parse: HMLAN1 new condition ok
2016.03.29 00:02:46 1: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2016.03.29 00:02:49 1: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2016.03.29 00:05:13 1: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2016.03.29 00:25:02 1: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2016.03.29 01:05:02 1: HMLAN_Parse: HMLAN1 new condition ok
2016.03.29 01:05:04 3: CUL_HM set Az.Thermostat.Climate getConfig
2016.03.29 01:05:20 3: CUL_HM set Ku.Thermostat.Climate getConfig
2016.03.29 01:05:36 3: CUL_HM set Sz.Thermostat.Climate getConfig
2016.03.29 01:05:52 3: CUL_HM set Wz.Thermostat.Climate getConfig


Die ersten beiden Log-Ausgaben hatte ich eingebaut um zu prüfen ob die Perl-Funktionen überhaupt ausgeführt werden.
Wie man sieht, wurde für alle 5 Thermostate um 00:01 das Register auf prog1 (war zuvor prog2) gesetzt.
Aufgrund der Device-Einstellung "autoReadReg" auf "5_readMissing" hat dies direkt zu entsprechenden getConfig's geführt. Soweit erwartet.

Ist es normal das bereits 2 getConfig auf den Thermostat.Climate Kanälen zu einem Overload (wegen der 1% Regel) führen?
Und obwohl gegen 01:05 dann alle getConfig's ausgeführt wurden, standen auch Stunden später 2 der Kanäle immer noch auf set_prog1.

Kann ein

Code Auswählen Erweitern

sleep(60) nach dem regSet für ein Device die Lage schon soweit entspannen, das alle Kommando zeitnah durchkommen? Inklusiv der danach notwendigen getConfig's?

Grüße und Danke für die Hilfe
Holger

[frank]

nutzt du vielleicht burst? welche fw hat der hmlan? wie hoch ist denn die load vom hmlan normalerweise?
die register des climate channel sind sicher sehr umfangreich, wenn in dem channel alle 3 listen verwaltet werden.

[holgerschlegel]

Das "hmlan" ist in Wirklichkeit ein "HM-USB" der über ein auf dem gleichen RaspPi laufendes hmland angesprochen wird.
Die HM-USB Firmware war zumindest vor etwa 2 Monaten noch aktuell. Hab' seitdem nicht mehr geprüft ob es eine neuere Version gibt.

Bezüglich burst habe ich in keinem Device irgendwelche Parameter verändert. Alles auf Standard.

Insgesamt sind 23 Geräte über das eine HM-USB angebunden - 5 Wandthermostate, 7 Heizkörperstellantriebe, 8 Fensterkontakte, 1 Außentemperatursensor, 1 Stromzählersensor und 1 Funkschalter.
Meiner Meinung nach sollte das nicht zu viel für ein IO Device sein. Oder irre ich mich da?

Wenn ich nachsehe ist der Load normalerweise 0. Der FHEM Server steuert aktiv nur den Funkschalter (Außenlampe über sunset/sunrise) und halt die Umschaltung der Heizprogramme. Zu der Uhrzeit (00:01) sollte der Load also eigendlich auch 0 sein, außer die Heizprogramme müssen umgeschaltet werden.

[frank]

dann mach doch mal ein getconfig auf einen climate channel beim tc und schau, wieviel load das benötigt.