FHEM soll Thermostate nicht steuern

Begonnen von Widukind, 16 Februar 2015, 11:03:29

Vorheriges Thema - Nächstes Thema

Widukind

Moin zusammen,

ich habe vor ein paar Tagen die HeizkörperThermostate und WandThermostate eingebunden.
Auch habe ich die Wandthermostate wieder an die entsprechenden Heizkörper verbunden. (Da sind allerdings auch Fehlermeldungen gekommen)

Soweit so gut.

Nun beobachte ich, dass sich die eingestellten Temperaturen an den Heizkörperthermostaten selbstständig verändern. Sie verändern sich auch außerhalb der Schaltpunkte auf das Wochenprofil. Auch scheinen sich die Einstellungen selbstständig von Manuell auf Auto zu verstellen. Letzte Nacht hat sich der Thermostat selbstständig im Schlafzimmer auf 21° gestellt, obwohl er manuell auf off gestellt war.

Das will ich aber derzeit nicht.
Die Einstellungen an den Heizkörperthermostaten sollen Vorrang vor der fhem-Steuerung haben.
Die Steuerung hat bisher ohne fhem ganz gut funktioniert.

Ich möchte derzeit nur protokollieren und das Verhalten beobachten. Nur wenn ich explizit gezielt mit fhem einen Wert ändere, soll das passieren.

Wie kann ich es einstellen, dass die Thermostate wie bisher autonom funktionieren?
Wie kann ich die Automatik abschalten?

Viele Grüße
Widukind

stromer-12

Wenn du keine Befehle für das Setzen der Thermostate programmiert hast, sollte auch nichts durch FHEM verstellt werden.

Gesendet von meinem GT-I9295

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

willyk

Hallo Widukind,

Zitat von: Widukind am 16 Februar 2015, 11:03:29
... (Da sind allerdings auch Fehlermeldungen gekommen)

Wäre bestimmt gut zu wissen welche Fehler kamen, vielleicht ist das wichtig.


ZitatNun beobachte ich, dass sich die eingestellten Temperaturen an den Heizkörperthermostaten selbstständig verändern.

Kann ich mir nicht vorstellen. "Von alleine" passiert da gar nichts.

Wie hast Du die Wochenprogramme auf die HT / WT übertragen ? Bist Du sicher dass sie so stehen wie sie sollen?

Wenn scheinbar zufällig Einstellungen geändert werden, liegt das entweder an einer sehr schlechten Funkverbindung, oder daran dass die WT / HT untereinander falsche Definitionen haben. Z.B. Wenn der WT in der Küche mit dem HT im Bad gekoppelt ist  :)

Wie sind die Geräte angeschlossen, Cube / CUL ?  Bist Du sicher, dass die associate's richtig sind? Verwendest Du die groupid?

Gruss
willyk

NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Nekano

Ich musste mein FHEM heute auch erstmal auf stop setzen. Bei mir scheint es auch so, als würde das FHEM willkürlich meine Einstellungen der Thermostate ändern. Ich gehe direkt über den Cube und habe kein WT. Laut Wocbenplan sollten z.B. 21 Grad im Bad sein. Steht auch so im Reading vom Wochenprotokoll. Auf einmal steht er auf 22 Grad. Ein Anderer Fall war, dass mein Wohnzimmer plötzlich auf 17 Grad stand. Egal was ich versuchte, sobald ich den HT auf Auto gestellt hatte stand er wieder auf 17 Grad. Erst das stoppen von FHEM und neu einspielen des Wochenplan über die Originalsoftware behob den Fehler. Wenn einer einen Grund kennt wäre das super.
Danke.

elfrinjo

Hi,

wenn das Thermostat auf 17 Grad festhängt liegt das (wahrscheinlich) an einem über FHEM gesetzten,  defekten Wochenplan.

Im Wiki steht ein Absatz dazu. Quintessenz:
wenn du den Wochenplan über FHEM setzt, muss um 23:55 noch ein Schaltpunkt in den Plan.

Nekano

Das mit dem letzten Schaltpunkt um 23:55 hatte ich schon getestet. Brachte leider keine Veränderung.
Habe heute FHEM komplett neu installiert. Seit dem Funktioniert alles top.

MfG Nekano

fermoll

#6
Die willkürlichen Veränderungen der Thermostateinstellungen hatte ich gestern auch. Ich habe dann die Steuerung über FHEM gestoppt und heute den Cube mit Max!Buddy kontrolliert. Fazit ist, dass heute keine Veränderungen zu beobachten sind. Das heißt, der Cube und die Verbindung zu den Thermostaten sind  in Ordnung. Die Probleme sind also bei FHEM zu suchen.
Meine Einstellung:
Max!Cube + 10 HT's auf einer Fläche von ca. 150 qm auf zwei Ebenen verteilt, ohne Stahlbeton. Max!Buddy meldet keine Verbindungsabbrüche, die das System durcheinanderbringen könnten.
FHEM über MaxLAn verbunden mit  define MaxCube MAXLAN 192.168.178.26 90 ondemand
Das 90 ondemand dient dazu, den Cube auch für andere Programme zugänglich zu machen, z.B. für Max!Buddy oder die Originalsoftware.
FHEM läuft auf einer Synology NAS DS 212+. Es steuert zu dem Max!Cube noch einen einen 2. Cube mit vier HT's, HM-CFG-LAN LAN (Homematik) mit drei Rollos und einen CUNO mit 7 Temperaturfühlern. Auffällig war, dass FHEM vor allem beim Aufbau von Plots das NAS häufig in die Knie gezwungen hat (völlige Auslastung des Prozessors). Die weitere Planung sieht vor, noch zwei PasPi's über FHEM2FHEM einzubinden, um das NAS zu entlasten.

Bei mindestens vier HT's den Temperaturscanner eingebunden:
#attr MAX_008355 scanTemp 1
#attr MAX_008355 verbose 1

Mit dem Verbose habe ich herumprobiert mit max 3, meist jedoch mit 1, um die Credits des Cube zu entlasten. Irgendwann fing das System an zu spinnen, indem willkürliche Umschaltungen der HT's erfolgten, so dass ich den Cube resettet habe, da Max!Buddy meldete, dass 100% DutyCycle erreicht waren. Wenn ich das richtig sehe ist das das gleiche Verhalten, wie es Nekano beschrieben hat.
In meinem Fall war also der Cube überlastet, weil die Credits aufgebraucht waren.
Es wäre m.E. sinnvoll, dass ihr die Hardware- und Softwaresituation beschreibt, damit die Spezialisten helfen können.
Mein weiterer Plan ist, den Max!Cube in FHEM einzubinden ohne den TemperaturScanner. Wenn er stabil läuft, werde ich den Scanner schrittweise für die HT's einbinden. 
Für die Neulinge wäre m.E. wichtig, sich über die 1% Regel im Wiki zu informieren. http://www.fhemwiki.de/wiki/1%25_Regel.

Im Nachhinein scheint Widukinds Problem auch mit der 1% Regel zusammenzuhängen.
FHEM auf Synology Ds 1621+ in Docker, . 2x Max!Cube, Debmatic auf RPI 3  mit HM-MOD-RPI-PCB , CUNO mit 35cm Antene, 2x HM-LC-Bl1PBU-FM, HC-LC-Bl1-FM
22 HT u. HT+, Fensterkontakte, S300TH, EM 100-GZ(S).
Diverse Wemos mit ESPEasy. 2. RPI3+, 1 RPI 4 8GB