groupid für Fensterkontakte nicht setzbar (CUL_MAX)

[zippo1000]

Hallo zusammen,

ich habe die beiden letzten Tage hier bereits mehrere Themen, die mein Problem vielleicht auch nur ansatzweise betreffen, durchforstet, bin aber leider zu keinem genauen Ergebnis gekommen. Deshalb eröffne ich nun mal ein eigenes Thema.

Kurz zur Ausgangslage:
Ich benutze seit etwa 2012 MAX-Heizkörperthermostate und -Fensterkontakte, die ich über einen MAX-Cube (Original-Software) mittels FHEM steuerte. Um es einfacher zu machen, beziehe ich mich auf das Schlafzimmer, in dem es genau 1 Thermostat und 1 Fensterkontakt gibt. Die beiden waren bisher gegenseitig assoziiert und die Fensteröffnung wurde erfolgreich ans Thermostat übermittelt. Das lief eigentlich von Anfang an ziemlich problemlos, allerdings ist mir dann irgendwann folgendes aufgefallen. Und zwar benutze ich das Thermostat stets im manuellen Modus, soll heißen, dass das gesamte Wochenprogramm von FHEM geregelt wird. Zu jeden Schaltzeitpunkt wird einfach die "desiredTemperature" zum Thermostat gefunkt. Ich weiß jetzt nicht, ob das best practice ist, es erlaubt mir aber z. B. auf die Anwesenheit von Personen zu reagieren und dann das Thermostat auszuschalten.

Jetzt zum eigentlichen Problem:
Das Fenster wird geöffnet, daraufhin geht das Thermostat auf die "windowOpenTemperature". Nun tritt während dieser Situation ein Schaltpunkt in meinem in FHEM hinterlegten Wochenprogramm ein und die "desiredTmeperature" wird auf sagen wir 20°C gestellt. Das ist schlecht, denn das Fenster steht ja noch offen. Der Heizkörper fängt also richtig an zu heizen, und zwar nach draußen.
Dieses Problem konnte ich dann durch Zufall lösen. Und zwar habe ich einfach mal alle readings der beiden MAX-Devices angeschaut. Dabei ist mir die "groupid" aufgefallen. Bei beiden stand sie auf 0. Ich hatte dann mal bei beiden eine 3 eingetragen und dies hatte dann den gewünschten Effekt.

Ich habe hier im Forum nicht wirklich viel über die groupid von Fensterkontakten erfahren können. In der Referenz steht sogar, dass sie nur für Thermostate vergebbar ist, was ich aber bezweifle.

Also ist das Problem doch eigentlich gelöst. Denkste. Ich kam nämlich auf die gute Idee, meinen originalen MAX-Cube zu eine CUN umzuflashen (finde ich übrigens super, dass das möglich ist und sich jemand die Arbeit gemacht hat). Die Motivation ergab sich daraus, dass ich MAX-Fensterkontakte zur Überwachung der Eingänge meines Hauses benutzen wollte und hier direkte Rückmeldung haben wollte (ohne Polling über MAXLAN). Das umflashen und neu anlernen funktionierte mit ein paar Schwierigkeiten eigentlich ganz gut, mir war nur nicht wirklich bewusst, dass der Fensterkontakt immer aus dem "Tiefschlaf" geweckt werden muss, damit er auch etwas empfängt. Klingt aber jetzt logisch für mich, denn es spart natürlich Batterie.
Ich habe also alles angelernt und untereinander assoziiert, also Thermostat->Fensterkontakt und Fensterkontakt->Thermostat und wollte dann die groupid setzen. Beim Thermostat kein Problem, aber beim Fensterkontakt bekomme ich es einfach nicht hin.
Schlussendlich tritt mein Problem von oben also jetzt wieder in Erscheinung und ich weiß nicht wie ich es sonst lösen soll.

Deshalb nun hier ein paar Fragen, deren Beantwortung mir vielleicht weiterhelfen würde:

• Hat sonst noch jemand festgestellt, dass das Setzen der selben groupid für Thermostat und Fensterkontakt verhindert, dass eine hohe Temperatur bei geöffnetem Fenster gesetzt werden kann?
• Gibt es vielleicht eine andere Möglichkeit, das Setzen der hohen Temperatur bei geöffnetem Fenster zu unterbinden (maxTemperature oder vielleicht Benutzung des AUTO-Modus)
• Was könnte das Problem sein, dass ich die groupid beim Fensterkontakt nicht setzen kann? Ich habe hier im Forum zwar gelesen, dass man den Fensterkontakt aufwecken muss, aber es will einfach nicht klappen, egal ob ich ihn betätige oder den Anlernknopf drücke.
• Ich bilde mir ein, dass ich mit der Original-FW des Cubes nie irgendwas am Fensterkontakt betätigen musste. Bilde ich mir das nur ein, oder könnte die Firmware das irgendwie anders geregelt haben?

So, ein langer Post. Ich hoffe, dass er nicht zu lange ist. Freue mich auf jeden Fall über Antworten und bin gespannt, was dabei rauskommt.

Vielen Dank an die Ersteller der grandiosen Software und des MAX-Moduls und viele Grüße,
Philip

[Wzut]

Ich bilde mir ein, dass ich mit der Original-FW des Cubes nie irgendwas am Fensterkontakt betätigen musste. Bilde ich mir das nur ein, oder könnte die Firmware das irgendwie anders geregelt haben?

Einbildung ist auch eine Bildung ( Spruch meiner Oma ...   ) aber im Ernst,  ich würde ein Monatsgehalt wetten das ich bei der Org MAX Software immer zuerst ein Fragezeichen im Raum für den neuen FK hatte und der Aufforderung ihn 1x zu betätigen da die Software den aktuellen Zustand nicht kennen würde.

[zippo1000]

Hallo Wzut,

also dass die Software vielleicht den aktuellen Zustand nicht aktiv abfragen kann, sondern auf eine Nachricht vom Fensterkontakt warten muss, das kann schon sein. Wie ich schon geschrieben habe, leuchtet es mir auch ein, dass der Fensterkontakt sich die meiste Zeit zum Stromsparen in einem Schlafzustand befindet und nur durch einen Interrupt, der durch den Reed-Kontakt ausgelöst wird, aufwacht und seinen Zustandswechsel kundtut. Ich konnte mich halt nur nicht daran erinnern, dass ich zum Pairing oder auch zum associate irgendwie tätig werden musste. Aber vielleicht hatte ich das auch nicht so genau beobachtet. Vom Cube über MAXLAN hat man ja sowieso keine direkt Antwort bekommen.

Ich habe mich gestern abend noch ein paar Stunden damit beschäftigt, wollte der Sache in wenig auf den Grund gehen. Nach einigen Versuchen habe ich es geschafft, dass das Senden des Befehls "set SZ_Fensterkontakt groupid 2" wirklich vom Fensterkontakt empfangen wird, woraufhin dieser dann eine Antwort sendet. Diese lautet aber leider "Invalid command/argument". Das ist also jetzt genau dasselbe Verhalten wie es in diesem Thread beschrieben ist: http://forum.fhem.de/index.php/topic,26168.0.html

Ich habe darauf hin mal das Debug-Log angeschaltet und wollte mir die gesendete Nachricht ansehen. Zum Vergleich habe ich auch mal die "groupid" des Thermostats gesetzt, was ja bei mir immer ohne Probleme funktioniert hat. Hier die beiden Nachrichten im Vergleich:

Code Auswählen Erweitern


2016.01.16 21:53:06 5: Cmd: >set SZ_Fensterkontakt groupid 2<
2016.01.16 21:53:06 5: CUL_MAX_Send: enqueuing 0b19002265432104e4710002

2016.01.16 22:25:33 5: Cmd: >set SZ_Thermostat groupid 2<
2016.01.16 22:25:33 5: CUL_MAX_Send: enqueuing 0b1c0022654321060da90002


Hier mal im Vergleich:

Code Auswählen Erweitern


0b19 00 22 654321 04e471 00 02  // Fensterkontakt
0b1c 00 22 654321 060da9 00 02  // Thermostat


Also für mich ergibt sich hier kein wirklicher Unterschied. ich kenne zwar das genaue Protokoll nicht, aber es sieht ja bis auf den Empfänger ("04e471" und "060da9") weitestgehend identisch aus. Deshalb ist meiner Vermutung nach der Fehler nicht im Modul CUL_MAX zu suchen. Vielmehr vermute ich, dass der Fensterkontakt das Setzen der "groupid" aus einem mir unbekannten Grund nicht akzeptiert. Was das allerdings sein könnte, da kann ich jetzt nur raten. Vielleicht darf ich zuvor kein "associate" setzen oder das "associate" mus mit einem Gerät mit identischer "groupid" erfolgen.

Hat hier im Forum niemand die "groupid" für einen Fensterkontakt gesetzt? Was steckt eigentlich genau hinter dem Prinzip der "groupid"? Für mich sieht das so aus, als würde sie für sowas wie einen Multicast benutzt werden, schließlich wird sie in jeder Funknachricht mit angegeben.

Ich habe glücklicherweise in der letzten Woche 5 Fensterkontakte und einen weiteren Max-Cube bestellt. Sobald das hier eingetroffen ist, probiere ich alles nochmal unabhängig mit einer neuen FHEM-Installation oder sogar der Original-Software. Ist es u. U. mit dem CUL möglich, die Funktelegramme mitzulesen? Wäre ja interessant, was da anders gemacht wird, wenn es denn funktionieren sollte.

[zippo1000]

Hallo,

wollte mich noch kurz melden, weil ich heute die bestellten Fensterkontakte und den Cube bekommen habe.

Ich habe alles zusammengebaut und den Cube über MAXLAN in eine zweite FHEM-Installation, die mehr oder weniger unkonfiguriert ist, hinzugefügt. Daraufhin habe ich den Cube über MAXLAN in den "pairmode" gesetzt und am Fensterkontakt dann die "groupid" auf 2 gesetzt. Das verlief ohne Fehler und wurde einwandfrei gesetzt. Die "groupid = 2" steht auch richtigerweise in den Readings drin.

Jetzt kommt das aber:
Ich bin daraufhin in meiner echte FHEM-Installation gewechselt, habe das verbose auf 5 gesetzt und den neuen Fensterkontakt, der ja eigentlich am anderen Cube angemeldet ist, durch Drücken der Taste zum Re-Pairing aufgefordert. Das wurde vom CUL_MAX auch empfangen und protokolliert. Komisch ist nur, dass die dort übertragenen "groupid" auf 0 steht, also so, als wäre die 2 niemals im Fensterkontakt gesetzt worden sondern nur in FHEM.

Wie das ganze jetzt aber im Zusammenspiel mit den Thermostaten dazu führt, dass diese bei geöffnetem Fenster Temperatur-Änderungen (desiredTemperature) nicht annehmen oder zumindest trotzdem auf der "windowOpenTemperature" bleiben, das muss ich demnächst mal untersuchen.

Mich würde trotz allem mal noch interessieren, wie andere hier ihre Heizungsregelung mittels MAX realisiert haben und wie man ansonsten noch verhindern kann, dass bei geöffnetem Fenster eine hohe Temperatur für ein Thermostat gesetzt werden kann.

Viele Grüße und 'ne gute Nacht,
Philip

[Tom_S]

aus solchen Gründen habe ich mich noch nicht getraut, meinen Cube umzuflashen.
Wenn man das ganze mit der MAX! Software in Betrieb nimmt, erhält jeder Thermostat und jeder Fensterkontakt die Nummer des Raums in den er eingefügt wurde. Diese ist dann die groupid. Die Räume sind so wie sie angelegt wurden fortlaufend nummeriert. Ich habe keinen Cul um es nachzuvollziehen. Es kann aber sein, dass sich die groubid bei Fensterkontakten nur der Cube merkt.

LG
Tom_S