FK - WT - 2xHKT: wie assoziieren ?

Begonnen von Uef, 28 Dezember 2015, 15:15:08

Vorheriges Thema - Nächstes Thema

Uef

Hallo zusammen,

ich hoffe, Ihr habt Weihnachten gut überstanden.

Ich habe da mal eine Frage zum richtigen Assoziieren von MAX-Komponenten:
in einem Raum mit 2 Heizkörpern (und je einem HKT) habe ich noch einen Wandthermostat und einen Fensterkontakt.

Nach einigen zwischenzeitlichen Problemen bei der Kommunikation habe ich mittlerweile wieder alles gepairt und grundsätzlich fiunktioniert es auch (meistens) - inkl. der Fenster-Auf-Erkennung und dem Herunterregeln der Heizkörper.
Allerdings gibt es hin und wieder folgende Unregelmässigkeiten:

  • die Fenster-Auf-Temperatur am Heizkörper ist mal 'OFF', mal 5°C (der eine Wert ist im HKT hinterlegt, der andere im RT). Ob die HKTs dabei immer "gleich falsch" stehen, kann ich aktuell nicht mit Gewissheit sagen
  • nach dem Schließen des Fensters bleibt die Temperatur manchmal auf 'OFF', statt wieder auf den aktuellen Wert der Automatik zu wechseln

Mittlerweile habe ich den Verdacht, dass das daran liegen könnte, dass ich den FK sowohl mit den HKTs als auch mir dem RT assoziiert habe (und zusätzlich natürlich auch den RT mit den HKTs) und dass die Reihenfolge, in der die direkte Kommunikation zwischen den MAX-Komponenten aufgrund des Assoziierens erfolgt, mal so und mal so erfolgt. D.h. mal bekommt beim Fensteröffnen erst der HKT Bescheid und geht auf 'OFF und erst danach meldet sich der zwischenzeitlich ebenfalls informierte RT auch noch mal bei ihm und korrigiert die desiredTemp auf 5°C (wie im RT für FensterAuf hinterlegt). Manchmal geht es anders herum ....
Beim Schließen des Fenster läuft das dann entsprechend.

  • Kann jemand dieses Verhalten bestätigen ?
  • Und was wäre das richtige Assoziierungs-Schema für diese Konstellation: den FK nur mit dem RT assoziieren (reicht der das dann durch an die HKTs) ?
    Würde es dann ausreichen, FK und HKTs via FHEM zu de-assoziieren oder besser diesen Teil der Konfig löschen und inkl. Pairing neu hochziehen ?
  • Oder wäre da ein anderer Ansatz ohne Verwendung der Assoziiationen besser ?

Danke und Gruß
Uef
fhem auf Raspberry2 mit MAX! (via CUL f. Raumthermostat, Fensterkontakte und Heizungen) und HM (via LanAdapter für Raumthermostat, 6-fach Taster, 4-fach Hutschiene, Statusanzeige, Stecker m. Leistungsmessung); In Entwicklung: Heizungsüberwachung via Adapter & MQTT; Stromverbrauchsüberwachung (1wire)

syslog

Hallo,

ich hab bei mir einen Raum mit genau dem gleichen Setup (WT, 2xHT, FK).  Ich habe allerdings in allen drei Thermostaten die gleichen Parameter hinterlegt (Fenster-Auf-Temperatur).  Und ich habe alle vier Komponenten kreuzweise assoziiert.  Soweit funktioniert das bei mir ganz gut.  Die GroupIDs sind bei dir auch alle ident, nehme ich an?

lg,
syslog

Uef

Hallo syslog,

ja, die Group id ist bei allen gleich - allerdings auch 'nur' 0 (d.h. der Defaultwert), da ich den Wert nicht explizit gesetzt habe.

Das Problem ist auch nicht, dass die FensterAuf-Temperatur unterschiedlich ist.
Ich habe daran nur erkannt, dass das wohl mal so und mal so läuft.

Das eigentliche Problem ist halt, dass das Gesamtkjonstrukt nach Schließen des Fensters nicht immer wieder auf den Automatik-Wert zurück springt, sondern hin und wieder auch mal auf 'OFF' stehen bleibt und damit die Bude kalt (bzw. nicht wieder warm) wird.
Und da war/ist halt meine Befürchtung, dass sich bei der Konstellation unter bestimmten Umständen die gegenseitigen Benachrichtigungen verstolpern bzw. blockieren und nicht den Weg zurück zur programmierten Raumtemperatur schafft.

Sind bei Dir die HKTs mit einem 'eigenen' Wochenprogramm versehen oder macht das alleine der RT ?

FHEM zeigt bei meinen HKTs zumindest kein Programm an (ich hatte die wie gesagt zum Teil neu angelernt und noch keinen neuen Wochenplan wieder drauf gespielt). Es handelt sich übrigens um Plus-Modelle, die man ja nicht "lokal" programmieren kann. Ob das alte Programm aber beim Resetten wirklich gelöscht wurde, weiß ich nicht, denn teilweise unterhielten sich die HKTs trotz Reset sofort wieder mit FHEM.

Vielleicht ist manchmal einer der HKTs (statt des RTs) der Letzte, der die anderen über das Schließen des Fenster informieren will und braodcasted dann aufgrund des fehlenden Wochenprogramms eine falsche Temperatur, die die anderen dann übernehmen (quasi als neueste Änderung), obwohl sie kurz zuvor schon wieder auf der richtigen Fenster-Zu-Tempertur waren.

Uef
 
fhem auf Raspberry2 mit MAX! (via CUL f. Raumthermostat, Fensterkontakte und Heizungen) und HM (via LanAdapter für Raumthermostat, 6-fach Taster, 4-fach Hutschiene, Statusanzeige, Stecker m. Leistungsmessung); In Entwicklung: Heizungsüberwachung via Adapter & MQTT; Stromverbrauchsüberwachung (1wire)

syslog

Hi,

ja, bei mir haben sowohl das WT als auch die beiden HT das gleiche Wochenprogramm, und die groupID ist bei mir ungleich 0.

Ob die HTs ein Wochenprogramm haben, siehst du eh im FHEM auf der Seite des jeweiligen HT.  Hast du beim Assoziieren in beiden Richtungen gearbeitet?  (Also WT -> FK, FK -> WT, etc....)  So hab ich es jedenfalls gemacht.

lg,
syslog

Uef

Hi syslog,

Danke.

Ja, ich habe die Assoziationen jeweils in beide Richtungen vorgenommen - sie scheinen ja auch zu funktionieren.

Nur wenn ich jedes Device mit jedem assoziiere, sind da ja gewisse Redundanzen; zumindest bzgl. des Fensterkontaktes: die HKTs werden dann doch vermutlich sowohl vom FK als auch vom RT informiert; ggf. informieren sie sich sogar noch gegenseitig über ein geöffnetes Fenster bzw die deswegen geänderte Temperatur.

Naja, ich werde mal das mit der GroupId ändern und beobachten und Feedback geben (aktuell habe ich aber gerade nach einem heutigen FHEM-Update ein anderes Problem <Negative length at ./FHEM/92_FileLog.pm line 827, <GEN22> line 201.>, das ich erstmal lösen muss).

Bzgl. des Wochenprogramms auf den HKTs: nach meinem Kenntnisstand kannn FHEM das Wochenprogramm der HKTs nicht auslesen, d.h. wenn diese beim Pairen schon eines haben, kriegt FHEM das nicht unbedingt mit. Und ich hatte die HKTs zwischendurch mal komplett in FHEM gelöscht.
FHEM kennt und zeigt nur solche Wochenprogramme an, die von FHEM (in meinem Fall via CUL) an die HKTs geschickt wurden. Oder liege ich da falsch ?

Wenn ich die HKTs jetzt mit dem gleichen Wochenprogramm wie den RT versorge, fällt das Fehlverhalten (falls es überhaupt eines ist) vermutlich gar nicht mehr auf, da nach dem Schließen des Fensters jedes Device für sich auf den im Wochenprogramm festgelegten Wert geht - auch wenn dieser anschließend zusätzlich nochmal von einem der anderen Devices rübergesendet wird.
Das ist also vermutlich die Lösung. Werde ich also ebenfalls ausprobieren und dafür gleich mal das neue Modul weekprofile testen.

Ich hatte allerdings im Hinterkopf, dass es reicht, den RT zu programmieren und der den HKTs schon sagt, welche Zieltemperatur sie (selbständig) einhalten sollen.
Oder liege ich da auch falsch ?

Gruß
Uef
fhem auf Raspberry2 mit MAX! (via CUL f. Raumthermostat, Fensterkontakte und Heizungen) und HM (via LanAdapter für Raumthermostat, 6-fach Taster, 4-fach Hutschiene, Statusanzeige, Stecker m. Leistungsmessung); In Entwicklung: Heizungsüberwachung via Adapter & MQTT; Stromverbrauchsüberwachung (1wire)

onurbi

#5
Hi Uef,

habe Deinen Beitrag eben erst entdeckt und meinen daher schon gepostet. Da geht es um ein sehr ähnliches Thema.

ZitatIch hatte allerdings im Hinterkopf, dass es reicht, den RT zu programmieren und der den HKTs schon sagt, welche Zieltemperatur sie (selbständig) einhalten sollen.
Oder liege ich da auch falsch ?

Davon bin ich auch ausgegangen. Mein Test hat aber ergeben, dass bei vollständiger Assoziierung von FK, RT, und allen HT das Wochenprogramm des HKTs verwendet wird. Um das zu Testen, habe ich den HKTs ein abweichendes Wochenprogramm verpaßt und siehe da, beim Schließen des FKs geht das doch tatsächlich auf seine eigene Temperatur und nicht auf die vom RT!

Dass alle Wochenprogramme und sonstigen Parameter für RT und HKTs gleich sein müssen, zeigt mir auch, dass die MAX-Software es auch so macht. Mit "list <HKT>" kann man ja Die Einstellungen auslesen. Nachdem ich mit der MAX-Software das Wochenprogramm neu gesetzt hatte, sehen alle Listen identisch aus (bis auf die Namen natürlich).

Finde ich schade, dass das System nicht logisch reagiert. Aber bei der Kombination MAX und FHEM muß man eh viel ausprobieren.

Gruß,

Onurbi

Uef

Hallo Onurbi,

habe Deinen anderen Thread eben gelesen.
Und das erklärt vermutlich auch mein Problem bzw. die Auffälligkeiten.

Ich werde mal das Wochenprogramm überall gleich malchen und dann weiter beobachten.

Ggf. finde ich ja auch mal Zeit, diese Erkenntnisse ins Wiki zu ergänzen, denn diese Testerei muss ja nicht jeder machen und gerade zu MAX scheint es ja doch viele Unklarheiten zu geben, wie man was richtig macht. Alleine zum korrekten Assoziieren habe ich letztens stundenlang gelesen und stand doch am Ende mit unterschiedlichen Tips dar. Es funktioniert zwar irgendwann, aber so genau warum, weiß man aufgrund der Vielzahl der getesteten Konfigurationen dann meist doch nicht ....

Gruß
Uef
fhem auf Raspberry2 mit MAX! (via CUL f. Raumthermostat, Fensterkontakte und Heizungen) und HM (via LanAdapter für Raumthermostat, 6-fach Taster, 4-fach Hutschiene, Statusanzeige, Stecker m. Leistungsmessung); In Entwicklung: Heizungsüberwachung via Adapter & MQTT; Stromverbrauchsüberwachung (1wire)

onurbi

#7
Hallo Uef,

gute Idee mit dem Wikieintrag!

Bitte berichte, wie sich bei Dir die Änderung auswirkt!


Gruß, Onurbi