MAX!-Thermostate und Credits in FHEM

29. September 2022, Tags:

Ähnlich wie im Straßen- und Flugverkehr, gibt es auch im Funkverkehr Regeln. Diese besagen, dass über gewisse Frequenzen nur gewisse Mengen an Daten in einer gewissen Zeit übertragen werden dürfen. MAX!-Thermostate und Credits in FHEM tragen dem Ganzen hier Rechnung. Jede Sekunde wird ein Credit gut geschrieben und das Senden eines Befehls über das Frequenzband kostet eine gewisse Menge an Credits (typischerweise über 100). Somit wird das Frequenzband korrekt ausgelastet und der geneigte FHEM-Anwender langsam in den Wahnsinn getrieben 🤪.

In einem früheren Beitrag ging ich schon einmal auf die Credits ein. Ich verwende im Folgenden nur den Begriff der ‚Credits‘, wenngleich der MAX! Cube dafür den Begriff ‚dutycycle‘ benutzt. Mehr oder weniger ist es dasselbe, auch wenn der ‚dutycycle‘ genau andersherum funktioniert. Hier beschreibe ich nun, wie ich aktuell mit dieser Limitierung umgehe.

Bitte werft auch einen Blick auf meinen Blogpost Energiekosten durch smarte Thermostate sparen mit FHEM!

Credits finden

Das war lange Zeit schon die erste Herausforderung, an der ich gescheitert bin. Die Anzahl der zur Verfügung stehenden Credits findet sich im Reading „credit10ms“ im CUL-Device. Diese Zahl wird allerdings nur alle Jubelminuten aktualisiert. Mit dem Befehl get CUL_0 credit10ms  kann eine Aktualisierung erzwungen werden.

Der Eine oder die Andere schlägt vielleicht die Hände über dem Kopf zusammen, aber ich habe mir eine kleine at-Routine gebaut, um diesen Befehl alle 5 Sekunden auszuführen. Der at-Befehl bewirkt in FHEM die Ausführung eines Befehls zu einer bestimmten Zeit oder immer wieder mit einer vorgegebenen Pause. Für letzteres ist das ‚*‘-Zeichen zuständig. Das ‚+‘-Zeichen besagt, dass die folgende Zeit eine Zeitdifferenz und keine Uhrzeit ist:

Damit wird nun alle 5 Sekunden der oben genannte Befehl ausgeführt. Das Attribut event-on-change-reading bewirkt, dass keine weiteren Events alle 5 Sekunden ausgelöst werden. Das würde mir sonst das Logfile zu spammen.

MAX!-Thermostate und Credits in FHEM

Ein Befehl, der an ein MAX!-Thermostat gesendet wird, kostet eine bestimmte Anzahl an Credits. Wenn nicht genügend Credits vorhanden sind, dann kann der Befehl folglich nicht versandt werden. Er landet in einer Queue, die nacheinander abgearbeitet wird. Als Black Box kann diese Queue durchaus sehr nervend sein: Alles was man sieht ist, dass ein erwarteter Befehl schlicht nicht ausgeführt wird. Wann er endlich dran ist, dass blieb mir lange im Verborgenen.

Das CUL_MAX-Device hat hierfür eine Lösung parat: Der Internal-Wert ’sq‘ beinhaltet die Anzahl der Elemente in der Queue und der Befehl get CULMAX0 showSendQueue  zeigt die aktuellsten 10 Einträge der Queue an. Schlussendlich kann die Queue auch über set CULMAX0 deleteSendQueue  geleert werden. Das ist vor allem dann sinnvoll, wenn man sich beim Einrichten mal wieder vertan hat.

Komfortmodus

Weil es mich genervt hat, mir diese Infos immer aus kleinen Texten an verschiedenen Stellen zusammenzusuchen, habe ich mir ein kleines Widget dafür gebaut. Widgets in FHEM baut man mir einer readingsGroup. Mein Widget sieht wie folgt aus und zeigt mir per Click auf ‚List‘ die aktuelle Queue an:

Screenshot meines Widgets mit FHEM/MAX-Credits

Der Quellcode dafür sieht folgendermaßen aus:

In der ersten Zeile steht einiges, dass kurz erklärt werden soll:

  • CUL_0 ist das Device, auf dass sich alles bezieht.
  • In eckigen Klammern <> steht Text, der so angezeigt wird. Das %-Zeichen sagt, dass der Text ein Icon benennt.
  • ‚credit10ms‘ ist der aus dem Device CUL_0 auszulesende Wert.
  • Mit ‚+sq@CULMAX0′ wird auf das Internal ’sq‘ im Device ‚CULMAX0‘ zugegriffen. Das ‚+‘ verweist dabei auf ein Internal anstelle eines Readings.
  • Das ‚!List‘ ist der Text ‚List‘, dem in Zeile 3 ein Kommando zugewiesen wird.

Zusammenfassung

Dieses kleine Widget gibt mir den schnellen Überblick darüber, was da so an Funkverkehr im MAX!-Netzwerk los ist. Damit wird schnell ersichtlich, wenn es irgendwo klemmt. Das Reading ‚credit10ms‘ wird durch den ‚at‘-Befehl alle 5 Sekunden aktualisiert. Die Anzahl der Befehle aktualisieren sich nicht von allein, hier ist ein Reload nötig. Man könnte auch dafür einen ‚at‘-Befehl bauen und ’sq‘ alle paar Sekunden in ein Reading schreiben – Man kann aber auch einfach den Reload-Knopf drücken 🙃.

Keine Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.