MAX Wandthermostat nicht mit MAX-Fensterkontakt assoziierbar?

Begonnen von fast-eddy, 02 Januar 2014, 00:29:33

Vorheriges Thema - Nächstes Thema

fast-eddy

Hallo zusammen,

zunächst Hut ab vor allen FHEM-Entwicklern und Forenmitgliedern - Das ist echt unglaublich was Ihr hier in Eurer Freizeit auf die Beine stellt!

Ich bin neu im FHEM-Umfeld und wollte eigentlich nur eine Gewächshaussteuerung mit FHEM realisieren, habe dann aber Blut geleckt und steuere
mittlerweile große Teile meiner Haustechnik über FHEM und diverse Automatisierungskomponenten.

Mit Hilfe der Infos im Forum und der FHEM-Doku bin ich schon recht weit gekommen, aber jetzt an einem Punkt angelangt wo ich Eure Hilfe benötige.

Hier meine Problemstellung:
Über die Feiertage habe ich versucht zwei MAX-Heizungsthermostate (HT), zwei MAX-Fensterkontakte (FK) und ein MAX-Wandthermostat (WT) in FHEM
einzubinden. Hat soweit auch alles funktioniert, nur leider habe ich keine Möglichkeit gefunden, die Fensterkontakte mit dem Wandthermostat zu
assoziieren. Mit den HT´s klappt es, nur reichen diese den "Fenster Offen Status" (FOS) nicht an den WT weiter. Daher weiss der WT nichts von
offenen Fenstern und überschreibt den FOS in den HT´s beim nächsten Broadcast mit der aktuellen Temperatur (Wochenprogramm oder desired-temp),
obwohl das Fenster noch offen steht. Gibt es eine Möglichkeit, Fensterkontakte mit dem MAX WT zu assozieren oder einen anderen Weg, dem WT
mitzuteilen, dass ein Fenster offen steht?

Ohne FHEM kann man die Fensterkontakte ja auch direkt am WT peeren und dann klappt es auch mit dem "Fenster Offen Status"
Irgendwelche Vorschläge oder Lösungsansätze?

Danke und Grüße, Ralf
Raspberry Pi | HMUART | HMLAN | JeeLink | HUE | Z-WAVE.ME | HM-LC-Bl1PBU-FM | HM-PB-2-WM55 HM-CC-RT-DN | HM-LC-SW4-SM | HM-WDS10-TH-O HM-WDS30-T-O | HM-LC-SW4-DR | HM-Sen-MDIR-O-2 | HM-SEC-SCo |  Technoline TX 29 DT-HT|

d0np3p3

Hallo Ralf,
bei mir funktioniert es, ich habe (glabe ich) einfach WT FK und HT untereinander Verbunden,
beim WT associate MAX_FK und MAX_HT
beim FK associate MAX_WT und MAX_HT
beim  HT associate MAX_WT und MAX_FK

siehe Wiki:
ZitatGeräte untereinander anlernen
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").
Wenn ich z.B.
set MAXFensterKontakt0 associate MaxHeizkörperthermostat3
ausführe, dann sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM) an das MaxHeizkörperthermostat3.
Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein set MaxHeizkörperthermostat3 associate MAXFensterKontakt0 erfolgen.
Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der AXFensterKontakt0 offen ist. Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz. Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)
Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal jemand ausprobieren und dann hier berichten.
FHEM: Raspberry Pi (COC) & Fritz 7270 (freetz FHEM2FHEM)
IT (Elro AB440 AB600D) - Max! (6*regler 1*Thermostat 5*Fenster) Hue Bridge mit Bulbs - 2*Living-white Adapter - Iris
XBMC (Zbox) 4*SqueezeRadios 3*squeezelite dbox
AndFhem (Nexus4)

Matthias Gehre

Hallo fast-eddy!

Ist dein Problem, dass
1. die WEB-Oberfläche das pairen von WT und FK nicht erlaubt
oder
2. dass die Befehle "set WT associate FK" und "set FK associate WT" nicht die gewünschte Wirkung bringen?

Falls es 1) ist, dann probiere bitte die Befehle unter 2) und melde dich dann nochmal.

fast-eddy

Hallo zusammen,

danke für die schnellen Antworten.

@Matthias:
<<< Falls es 1) ist, dann probiere bitte die Befehle unter 2) und melde dich dann nochmal.
Da hätte ich echt auch selbst drauf kommen können ;-) Danke für den Hinweis.
Habe die "set" Kommandos jetzt mal händisch abgesetzt und siehe da: "Fenster Offen" wird am WT signalisiert.
Hat hat nur etwas länger gedauert, da das  deassoziieren und neu assoziieren der betreffenden Komponenten in den Duty Cycle gelaufen ist (Ist das normal?)

Allerdings habe ich jetzt das reziproge Problem: WT erkennt "Fenster Offen" reicht diesen Status aber nicht an die HT weiter? Langsam gehen mir die Ideen aus?
Hast Du noch einen Tip für mich?

Danke und Grüße,
Ralf
Raspberry Pi | HMUART | HMLAN | JeeLink | HUE | Z-WAVE.ME | HM-LC-Bl1PBU-FM | HM-PB-2-WM55 HM-CC-RT-DN | HM-LC-SW4-SM | HM-WDS10-TH-O HM-WDS30-T-O | HM-LC-SW4-DR | HM-Sen-MDIR-O-2 | HM-SEC-SCo |  Technoline TX 29 DT-HT|

fast-eddy

... so, habe es mittlerweile geschafft, dass meine WT und HT miteinander reden bzw. den "Fenster Offen Status" austauschen.

Folgende Lösungswege haben mich ans Ziel geführt:
1.) Auch wenn es im FHEM Webinterface nicht angezeigt wird muss man die FK via "set <WT> associate <FK>"  und umgekehrt manuell peeren.
2.) Im Gegensatz zu  einer reinen MAX-Raumlösung genügt es nicht, die FK mit dem WT zu peeren, da die WT in einer Hauslösung über FHEM den FO-Status NICHT an die HT durchreichen! D.h. auch ALLE HT mit ALLEN FK peeren.

Auch wenn es letztendlich funktioniert hat, haben mir folgende Probleme das Leben schwer gemacht:
a.) Das manuelle Peering ín beide Richtungen ist bei mehreren Komponenten umständlich und fehleranfällig. Kann man das nicht wie bei HomeMatic automatisieren d.h. in einem "set" abbilden?
b.) Im Zusammenhang mit a.) wäre es hilfreich, sehen zu können welche Komponenten bereits gepeert sind und ob das Peering erfolgreich war.
c.) Die größte Hürde war aber die Tatsache, dass selbst einfache Konfigurationen regelmäßig das Sendelimit (1%) überschritten und zu "LOVF" oder "Not enough credit!" geführt haben. Dadurch wurde die Konfig massiv verkomplizierte, da ständig Pakete verloren gingen oder verzögert zugestellt wurden. Bisher habe ich nur 2 FK 2 HT und 1WT an einem CUL im Einsatz (derzeit noch ohne Steuerung über FHEM), der Traffic sollte also mehr als überschaubar sein. Gibt es hier Tipps, wie man den Funkverkehr bei MAX schon bei der Konfig sinnvoll reduzieren kann ?

Nochmal Danke für die Hilfe und Grüße,
Ralf
Raspberry Pi | HMUART | HMLAN | JeeLink | HUE | Z-WAVE.ME | HM-LC-Bl1PBU-FM | HM-PB-2-WM55 HM-CC-RT-DN | HM-LC-SW4-SM | HM-WDS10-TH-O HM-WDS30-T-O | HM-LC-SW4-DR | HM-Sen-MDIR-O-2 | HM-SEC-SCo |  Technoline TX 29 DT-HT|

zwockel

Für alle die das Problem haben, daß das Drücken der Anlerntaste des MAX_Fensterkontaktes nicht angenommen wird und die Logdatei mit
There is a packet for ShutterContact *** in queue. Please push the button on the respective ShutterContact so the packet can be send.
überflutet wird hier die Lösung:
Fensterkontakt und CUL_MAX aus fhem.cfg rausnehmen und fhem.cfg speichern.
Batterien aus Fensterkontakt für min.60sec rausnehmen. Bei gedrückter Anlerntaste Baterie einlegen bis LED blinkt.
CUL_MAX wieder in fhem.cfg reinnehmen und Fensterkontakt anlernen.
Die Ursache lag bei mir wohl, daß der Fensterkontakt bevor ich den Heizkörperthermostat in FHEM angelernt habe schon mit diesen im "Standalone Betrieb" war.

Beste Grüße

Zwockel

Palm_Maniac

Hallo,

ich werde genau von dieser Meldung im Log gequällt und bekomme sie nicht weg. Ich bin genau nach Anweisung verfahren, mehrfach, ohne Änderung. Ich weiß nicht, was ich noch tun soll. Bei meinen ersten 2 Räumen hat alles wunderbar geklappt sie vom Cube abzugewöhnen und an den CUL zu bringen, der 3. macht Probleme. FHEM ist aktuell, habe wegen der Meldung unter anderem auch ein Update ausgeführt. Gibt es noch etwas was ich machen kann?

HILFE!!!!

Palm_Maniac

Die Fensterkontakte machen mich Wahnsinnig. Jetzt hatte ich es irgendwie geschafft mit dem FK aus dem 3. Raum, da macht jetzt der neu angelernte aus dem 4. Raum genau das gleiche. Wieso hat es die ersten beiden male ohne Probleme geklappt und nun nur noch dieses Log-Spaming mit diesen Meldungen? Er reagiert, übermittelt seine Infos an die HT und WTs welche ebenfalls reagieren. FHEM zeigt den richtigen Status an.... Was soll das nur? Mehr als Battrien raus, warten, Resetknopf drücken und Batterien rein geht doch nicht.

jos

Hallo zusammen,

habt ihr inzwischen eine Lösung für das Problem mit den Wandthermostaten gefunden? Ich habe auch einen gekauft, und habe exakt das gleiche Problem wie hier beschrieben, - WT und HT konnte ich prima assotiieren, aber der WT will partout nicht mit den Fensterkontakten reden, und damit ist der WT wertlos.

Eine weitere Frage noch in dem Zusammenhang: mein HT habe ich über FHEM programmiert, der Wochenplan entsprechend ausgeführt; wenn das WT dazukommt, wird auch das im Auto Modus seinen Wochenplan abarbeiten. Was ist da best practice? Einfach WT auf den gleichen Wochenplan wie den HT programmieren, oder den WT im manuellen Modus laufen lassen (wahrscheinlich würde er da den HT regelmäßig wieder überschreiben, oder?)?.

Danke schonmal!
VG, jos
-jos

Matthias Gehre

Ich habe keine Wandthermostate, bin daher auf Patches angewiesen.

tuxbox

#10
Hi,

vor dem Registrieren beim FHEM und dem Assoziieren untereinander sollte die jeweilige MAX-Hardware natürlich
unbedingt einen vollständigen Reset durchlaufen haben.
Danach alle Kompenenten erst mit CULMAX pairen, danach erst untereinander Assoziieren.
Wobei vorher (direkt nach dem CULMAX pairen) es meiner Meinung und Erfahrung nach es sehr sinnvoll ist,
die jeweiligen Geräte mit einer groupid (ungleich 0) für den jeweiligen Raum zu belegen (set mythermostat groupid 1 .. etc).

Das Assoziieren der der Gegenstellen
HT -> FK (set ht associate fk), FK -> HT (Tastendruck am FK nötig), WT -> FK, FK ->WT (Tastendruck),
HT -> WT, WT -> HT.
Meiner Sicht und Erfahrung nach ist es empfehlenswert, die "Kommando-Empfangsstelle" zuerst auf die Gegenstelle vorzubereiten.
Also erst "set myHT associate myFK", bevor die Gegenstelle myFK die Assoziation gesetzt bekommt. Ein Ping vom FK an HT
kann dann schon sofort beantwortet werden.
Ähnlich auch erst HT auf Kommunikation von WT vorbereiten und dann im WT dass associate auf HT setzen.

Wegen Wochenprogramm: Wochenprofil nur in das WT (aber an 23:55 Stützstelle denken) schreiben. Wenn HT und WT
in der gleichen GruppenId sind, weiß das WT, dass das Programm nicht für ihn "persönlich", sondern für den ganzen
Raum gedacht ist und teilt dem HT eben mit, dass er die Wochenprogrammsteuerung übernimmt
(sonst, wenn nur assoziiert, wird nur bei Progr.temp.wechsel die Temperatur ans HT nachgezogen, was z.B. bei einem
Fenster-zu-Telegramm zu Effekten führt, dass HT kurz erst auf sein internes Wochenprofil springt bis Temp.
vom WT nachgezogen wird).

Gruß,
Frank

jos

Vielen Dank für eure Antworten, endlich habe ich den Fehler gefunden - ich habe nie den CUL in den pairmode versetzt, was offensichtlich neben dem associate Befehl nötig ist. Ist auch irgendwie nicht wirklich logisch und könnte man daher vielleicht in der Oberfläche mit in den "set ... associate ..."  Befehl einbauen, damit der pairmode automatisch ausgeführt wird.

Viele Grüße, jos
-jos

Matthias Gehre

Schreib doch bitte eine Anleitung dafür auf die MAX Seite des FHEM Wiki.