Max! über CUL - SET-Temperature wird nur sporadisch an HomeGear übertragen?

Deutsche Foren Hardware
#1

Ich verwende einen CUL und Max!-Komponenten. Sofern man das 1%-Limit einhalten kann, funktioniert es eigentlich ganz OK.

Jetzt ist mir aufgefallen, dass meine Thermostate, die meist im AUTO-Modus laufen, sehr unregelmäßig ihre aktuelle SET-Temperatur an HomeGear übertragen (zu den Schaltzeitpunkten ist da auch nix im Log zu finden). Schaltet man schnell z.B. auf MAN und dann wieder zurück, passt wieder alles, dann hat HomeGear die aktuellen Werte.

D.h. die Thermostate laufen eigentlich, wie erwartet, aber HomeGear weiß nicht, auf welcher Temperatur.

Mir ist durchaus bewußt, dass die “actual temperature” bei Max! nur unregelmäßig übertragen wird, aber bislang zumindest hatte ich das Gefühl, dass die anderen Parameter, gerade die “set temperature” zeitnah an die Basisstation gingen. Ich hatte in der letzten Heizperiode aber noch einen Cube, von daher kann ich keinen direkten Vergleich liefern.

Ist diese Beobachtung korrekt, und gibt es workarounds?

#2

:slight_smile:

Schlussendlich muss aber @sathya was dazu sagen.

#3

Ja, das ist ja die Problematik mit der “actual temperature”, die nur unter bestimmten Bedingungen übertragen wird. Das ist bei Max! systemimmanent.

Bei mir liegt das Problem aber bei der “set temperature”, die sich v.a. im AUTO-Modus häufig direkt am Thermostat ändert, und das bekommt HomeGear nur sporadisch mit. Ich finde auch keine Regelmäßigkeit, wann dem so ist und wann es funktioniert.

Reproduzierbar den korrekten Wert vom Thermostaten bekomme ich wieder, wenn ich kurz von AUTO auf MAN umschalte und zurück.

Ich nehme an, dass mir das nur bei der “set temperature” auffällt, und die anderen Werte wie “valve state” genauso wenig aktuell sind.

Ich habe überhaupt ein paar Auffälligkeiten in der Ansteuerung:

  • Alle Fensterkontakte blinken 3x bei Betätigung, was eigentlich ein Zeichen wäre, dass diese keinen Kontakt zu einer Basis haben, funktionieren aber trotzdem. Es gibt dazu auch Threads, aber keine Lösung. Im Prinzip funktioniert es aber ja.
  • Ein Wandthermostat zeigt auch dauernd den fehlenden Kontakt an, funktioniert aber trotzdem zuverlässiger als die Heizkörperthermostate.
  • Alle Heizkörperthermostate zeigen demhingegen an, dass sie eine Verbindung haben, übertragen aber trotzdem in 50% der Fälle keine lokale Änderung der “set temperature”.

Gibt es denn irgendwo in der Konfiguration noch Möglichkeiten, wo man rumspielen könnte? Z.B. der Wert “responseDelay” (40 bei Max!)? Setzt ein Raspberry USB-Geräte in einen Energiesparmodus, wodurch dieses nicht mehr alle Signale mitbekommt? Die Aufstellung des CUL habe ich schon variiert, allerdings ist einer der betroffenen Thermostate 2m in direktem Sichtkontakt zum CUL, insofern sollte es eigentlich nicht dieser Punkt sein. Gibt es eine Möglichkeit, den CUL zu testen? Kann es sein, dass die aculfw besser funktioniert?

Fragen über Fragen ;-). Danke schon mal für Ideen!

#4

Also, ich habe mal mit responseDelay rumprobiert. Bei niedrigen Werten (z.B. 10 oder weniger) blinken die Fensterkontakte reproduzierbar nur 1x. Bei den vorgeschlagenen 40 blinken sie 3x. Die “set temperature” am Thermostat wird dennoch nur extrem unzuverlässig übertragen. Ich habe mal mit “screen” direkt auf den CUL zugegriffen und auch da erfolgt meist keine Ausgabe, wenn man irgendwas direkt am Thermostat ändert.

Die Hardware ist ein RPi4 mit aktuellem Raspian.

Der CUL identifiziert sich folgendermaßen:

T: Bus=01 Lev=03 Prnt=03 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0403 ProdID=6001 Rev=06.00
S: Manufacturer=SHK
S: Product=NANO CUL
S: SerialNumber=868
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=90mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

#5

Hallo @Larx,

gerade die “set temperature” zeitnah an die Basisstation gingen.

ja, die wird bei Änderung übertragen. Wie sich das Senden der aktuellen Temperatur triggern lässt, weiß ich gerade nicht sicher (wenn das überhaupt geht, geht es vielleicht in Verbindung mit Wandthermostat?). Polling wäre vielleicht möglich, allerdings erzeugt das viel Funkverkehr und leert die Batterien. Daher wäre es schön, wenn die Geräte die Temperatur irgendwie von sich aus senden würden. Zeichne doch mal ein Log über 24 Stunden auf (Loglevel 4) und poste dieses hier (gerne mit Zeitpunkten von Auffälligkeiten). Dann schaue ich mal rein. Wenn am CUL allerdings nichts ankommt, können wir in Homegear auch nicht viel machen…

Viele Grüße

Sathya

#6

Wenn ich per serieller Konsole auf dem CUL bin, sollte ich ja live verfolgen können, ob überhaupt was ankommt, oder?

Was mich etwas irritiert, ist die Sache mit den responseDelay. Warum blinken meine Fensterkontakte 3x, wenn ich den Defaultwert 40 eingestellt habe? Eigentlich sollten sie bei korrekter Verbindung 1x blinken, aber dazu muss ich responseDelay deutlich kürzer setzen. Da ist doch irgendwas falsch getimed, oder?

#7

Ich bin inzwischen fast verzweifelt, weil das Problem gefühlt immer schlimmer wird. Die Kommunikation zwischen CUL und Max-Komponenten funktioniert einfach nicht richtig.
Das Setup hat mit dem MaxCube ohne jegliche erkennbare Duty-Cycle o.ä. Probleme funktionert, der Cube hat halt einfach ab und zu alles vergessen. Jetzt mit dem CUL ist das System kaum mehr vernünftig steuerbar.

  • Duty Cycle ist in kürzester Zeit voll (da reden wir von unter 10 aktiven Schaltvorgängen pro Stunde).
  • Die Thermostate übertragen in ca. 50% der Fälle ihre aktuellen Einstellungen nicht an den CUL, erst nach einer aktiven Ansteuerung (dann aber reproduzierbar). Gerade bei der “setTemperature”, die sich ja im Auto-Modus dauernd selber ändert, ist das enorm ärgerlich, da man einfach nicht weiß, wie die aktuelle Einstellung ist.
  • Aktive Steuervorgänge klappen aber immer, wenn nicht der DutyCycle dazwischen kommt.
  • Die Fensterkontakte blinken meist 3x (d.h. “keine Gegenstelle”), wenn sie betätigt werden, funktionieren aber trotzdem. In der Tat sind die Kontakte das verläßlichste am ganzen System.
  • Wenn ich das “responseDelay” auf z.B. 10 reduziere, blinken die Kontakte immerhin nur 1x, wie es sein sollte.

Ich habe schon von culfw auf aculfw umgestellt und diverse Positionen des CUL ausprobiert. Auch bei direkter Sichtlinie zum Thermostaten treten Probleme auf. Ein paar Thermostate wurden in der Zwischenzeit auch ausgetauscht, neu angelernt, etc. Keine Besserung.

Ich bin ratlos.

  • @sathya: Was macht der “responseDelay”, macht es Sinn damit rumzuspielen?
  • Ich habe 6 Einzelthermostate sowie 4 mit einem Wandthermostat gruppierte Thermostate. Dazu eine ganze Reihe Fensterkontakte. Kann es sein, dass das System da schon unter Normallast so den DutyCycle auslastet, dass kaum mehr aktive Verwendung möglich ist?
  • Kann es sein, dass der CUL kaputt ist? Wenn ja, welche empfehlenswerten Bezugsquellen gibt es für sowas?
  • Kann es sein, dass “komplexere” Vorgänge, z.B. das erstmalige Setzen eines Wochenprogramms, das System für Stunden lahmlagen? Ich bekomme dann immer dauernd die 1%-Regelung. Am nächsten Morgen versuche ich dann wieder, etwas aktiv einzustellen, und renne dann wieder dauernd in den DutyCycle, als ob man damit bspw. die weitere Übertragung des am Vortag gescheiterten Wochenprogramms wieder angestossen hätte. Dann kommen auch noch überraschende Schaltvorgänge dazu, als ob ein “Rumprobieren” von vor längerer Zeit plötzlich aus der Pipeline kommen würde.
#8

hey Larx,

wenn du den CUL ausschließen möchtest, kannst du für den Raspberry auch ein CC1101 von @pmayer oder einen CUL von Busware verwenden. Ob das wirklich daran liegt, kann ich dir nicht sagen.
Ich selbst habe einen NanoCUL und Thermostate von homematic. Da scheint es so zu sein, dass eine neue Konfiguration erst übertragen wird, wenn sich das Themostat mit seinem aktuellen Status meldet (alle paar Minuten). So lange steht es in homegear auf config pending (sieht man auch in den Systemmeldungen der Admin-UI -> Glocke oben rechts). Sathya hatte ja bereits angeboten, das Log durchzusehen. Ohne ist das sonst ein Rätselraten. Möchtest du das nicht mal hier posten?

1 Like
#9

homegear.err (1,7 MB)
homegear2.log (1,5 MB)homegear-scriptengine.log (90,4 KB)

Diverse Logs von Homegear. Hilft aber wahrscheinlich wenig, weil ich natürlich in letzter Zeit auch verzweifelt versucht habe, irgendwie ein laufendes System zu bekommen, und daher ist sicher viel Müll in den Logs.

Interessant scheint mir zu sein:
25.02. gegen 6:35: Hier scheint gem. Log irgendwie begonnen zu werden, das Wochenprogramm an den Wandthermostat (29) zu übertragen. Das hatte ich aber schon am Vorabend eingestellt. Zu dem Zeitpunkt, an dem ich eigentlich das Wochenprogramm übertragen wollte, sieht man aber im error-log jede Mende “too short paket received” oder “duty cylce” Meldungen (24.02. ab 16 Uhr). Im normalen Log wird zu dieser Uhrzeit gar nichts vermerkt, dass was übertragen werden würde?!

Am 23.02. gibt es auch jede Menge an “duty cycle” Fehlermeldungen. An dem Tag war ich aber gar nicht zu Hause und habe definitiv gar nicht aktiv irgendwas am System geändert.

Zusammen mit dem Dreifach-Blinken der Fensterkontakte könnte ich mir halt vorstellen, dass die Max!-Geräte aus irgendeinem Grund den Eindruck haben, nicht mit einer Basisstation verbunden zu sein, und daher nicht immer ihre Signale senden (?!). Und da ich das Dreifachblinken der Fensterkontakte durch “responseDelay” verbessern kann, weiß ich nicht, ob da irgendwas mit dem Timing nicht stimmt.

Vielleicht irritiert mich aber auch einfach nur, dass mir das “Systemverständnis” fehlt, wie das seltsame Max!-System und Homegear zusammenspielen sollten ;-).

PS: Ein paarmal habe ich auch den NanoCUL abgesteckt, in der Hoffnung, den DutyCycle dadurch zu resetten. Sieht man in den Logs, hat aber auch nix gebracht.

PS2: Allerdings ist im Error-Log auch für den 25.02. 6:35 ein CUL-Disconnect, der gerade eben hätte sein müssen, aber so nicht stattgefunden hat?!?!

1 Like
When Max/Homematic thermostat status update?
#10

Ich rede einmal wieder ein bisserl mit mir selber ;-), weil ich noch etwas rumprobiert habe.

Vorgeschichte:

  • Ich verwende alle Arten von Max-Thermostaten, von Basic über normal, + bis hin zu einem Wandthermostat. Das Problem tritt bei allen Thermostaten auf.
  • Bis vor einigen Monaten hatte ich einen Max!Cube und OpenHAB. Dann habe ich auf Homeassistant und einen nanoCUL umgestellt. Da das außerhalb der Heizperiode war, ist mir zu diesem Zeitpunkt noch kein Problem aufgefalle (außer dass der Cube halt immer wieder alles vergessen hat, wie üblich).

Beobachtete Verhaltens"auffälligkeiten" jetzt:

  • Alles Senden von HomeGear an die Max-Thermostate klappt problemlos, sofern nicht der Duty Cycle dazwischen kommt.
  • Änderungen, die direkt an den Thermostaten vorgenommen werden, kommen nur in (grob gesagt) 50% der Fälle bei Homegear an. Dabei ist es egal, ob man mit der Hand direkt am Thermostat rumstellt, ob der Thermostat durch eine Fensteröffnung verstellt wird, oder ob er sich quasi intern durch Automatikprogramm umstellt - die Info kommt nicht zuverlässig an Homegear durch.
  • Ändert man aber in Homegear z.B. den MODE eines derartig “verstellten” Thermostat, kommt in diesem Moment sofort wieder die korrekte Information an (und zwar immer, und nicht nur in 50% der Fälle).
  • Betätigung von Fensterkontakte wird, anders als die Thermostate, zuverlässig von Homegear registriert. Allerdings geben die Fensterkontakte mit dreimaligen Blinken zu verstehen, dass sie glauben, an nichts gekoppelt zu sein. Zumindestes dieses Problem kann man mit einer responseDelay von 10 korrigieren.
  • Wird ein Fenster geöffnet, erfolgt die “WINDOW OPEN” SET-Temperaturänderung am Thermostat sofort. In Homegear kann es von wenigen Sekunden bis zu 2-3 Minuten dauern, bis sie dort ankommt - oder eben gar nicht. M.E. war das bei meiner früheren Konstellation sofort der Fall.
  • Ich habe auch versucht, mit “screen” ein wenig direkt am CUL rumzupfuschen. Da ich aber viele Max-Komponenten habe und daher gefühlt ständig irgendwer in der Wohnung rumfunkt, kann ich daraus wenig weiterführende Infos gewinnen.
  • Koppeln aller Max-Komponenten an Homegear/CUL funktioniert sofort und ohne Probleme. Habe ich jetzt schon mehrfach exemplarisch durchgespielt.

Die Tatsache, dass die Fensterkontakte irgendwie alle glauben, trotz vorheriger problemloser Kopplung nicht mit einer Basis verbunden zu sein, dies aber durch eine Konfigurationsänderung beheben läßt, führt mich zu der möglichen Lösung, dass auch die Thermostate sich nicht so richtig gekoppelt fühlen und daher ihre aktuellen Werte nicht zuverlässig aussenden.

Dagegen spricht, dass weder Homegear noch die Thermostate selber durch eine Fehlermeldung erkennen lassen würden, dass sie sich “ungekoppelt” fühlen…

#11

Hallo @Larx,

ein bisschen etwas kann ich zu den Auffälligkeiten sagen:

Duty Cycle ist in kürzester Zeit voll (da reden wir von unter 10 aktiven Schaltvorgängen pro Stunde).

Der CUL betrachtet den Dutycycle in 15-Minuten-Blöcken (ich meine, es waren 15 Minuten…), statt wie definiert in Stundenblöcken. D. h., es können maximal 7 Wake-on-Radio-Pakete in 15 Minuten gesendet werden (statt 31 in einer Stunde). Das ist nicht viel. Bei MAX! sind die Anfragen Wake-on-Radio-Pakete. Das Setzen von Wochenprogrammen lastet damit das System zum Beispiel schon sehr aus.

Die Thermostate übertragen in ca. 50% der Fälle ihre aktuellen Einstellungen nicht an den CUL, erst nach einer aktiven Ansteuerung (dann aber reproduzierbar). Gerade bei der “setTemperature”, die sich ja im Auto-Modus dauernd selber ändert, ist das enorm ärgerlich, da man einfach nicht weiß, wie die aktuelle Einstellung ist.

Das wird damit zusammenhängen, dass es sich um Broadcastpakete handelt (ich habe gerade kein Log, aber ich vermute es stark). Broadcastpakete erfordern kein ACK und damit werden nicht empfangene Pakete nicht erneut gesendet.

Aktive Steuervorgänge klappen aber immer, wenn nicht der DutyCycle dazwischen kommt.

Diese Pakete erfordern ein ACK. Das heißt, die Anfragen werden erneut gesendet, wenn sie nicht empfangen wurden.

Betätigung von Fensterkontakte wird, anders als die Thermostate, zuverlässig von Homegear registriert.

Diese Pakete erfordern ein ACK (keine Broadcast-Pakete). Daher auch das Blinken.

dieses Problem kann man mit einer responseDelay von 10 korrigieren.

Das Empfangszeitfenster für das ACK ist bei den Fensterkontakten sehr klein. Offenbar haben NanoCUL und CUL leicht unterschiedliche Timings.

Wird ein Fenster geöffnet, erfolgt die “WINDOW OPEN” SET-Temperaturänderung am Thermostat sofort. In Homegear kann es von wenigen Sekunden bis zu 2-3 Minuten dauern, bis sie dort ankommt - oder eben gar nicht. M.E. war das bei meiner früheren Konstellation sofort der Fall.

Da müsste ich ein Log sehen.

Ich habe auch versucht, mit “screen” ein wenig direkt am CUL rumzupfuschen. Da ich aber viele Max-Komponenten habe und daher gefühlt ständig irgendwer in der Wohnung rumfunkt, kann ich daraus wenig weiterführende Infos gewinnen.

Letztlich landen ja auch alle Pakete mehr oder weniger roh im Homegearlog.

führt mich zu der möglichen Lösung, dass auch die Thermostate sich nicht so richtig gekoppelt fühlen und daher ihre aktuellen Werte nicht zuverlässig aussenden.

Nein. Die Thermostate haben kein so enges Antwortfenster wie die Fensterkontakte. Die Fensterkontakte fühlen sich auch nicht “ungekoppelt”, sondern das ACK-Paket kommt einfach nicht zum richtigen Zeitpunkt. Die Fensterkontakte sind die einzigen mir bekannten MAX!-Geräte mit so engem Fenster.

Vielleicht hilft diese Info ja schon einmal…

Viele Grüße

Sathya

#12

… und dank des Logs hier (When Max/Homematic thermostat status update?) konnte ich tatsächlich einen Fehler beheben, welcher die Verarbeitung von Broadcastpaketen verhindert hat, wenn sich der Nachrichtenzähler nicht ändert. Der Fix ist im nächsten Nightly.

#13

Danke :-)! Bin gespannt.

#14

Hallo @sathya,

noch ist neue Nightly nicht installiert. Aber eine Frage schiebe ich gleich nach:

Wie ist die “best practice” beim responseDelay beim nanoCUL?

Reduzieren auf 10ms? Hätte das Nachteile?
Belassen auf 40ms? Im normalen Betrieb hat das bis auf das 3x Blinken der Fensterkontakte auch keinen offensichtlichen Nachteil? (Da bei Betätigung so oder gesendet wird)

Danke schon mal!

#15

Hallo @Larx,

die Fensterkontakte sind tatsächlich das entscheidende Gerät, weil die am empfindlichsten im Timing sind. Wenn es mit 10ms besser funktioniert, nimmst du 10ms und es hat keine Nachteile.

Viele Grüße

Sathya