Temperatur-Scanner für MAX-Thermostate

[f.reddy]

Hallo John,

hoffe dir geht es gut. Ich hab mal wieder eine Kleinigkeit gefunden. Ich habe von der FritzBox auf einen Raspberry PI umstellt.
Danach hat MaxScan nicht mehr funktioniert (Config 1:1 übernommen).
Es kam immer im 5 Sekunden Abstand

Code Auswählen Erweitern

2013.06.22 12:56:16 2: MaxScan is called --------------------
2013.06.22 12:56:16 2: MaxScan check Max-Component:MAX_065d7c
2013.06.22 12:56:16 2: MaxScan MAX_065d7c is HeatingThermostat
2013.06.22 12:56:16 2: MaxScan MAX_065d7c attr scanTemp is ok
2013.06.22 12:56:16 2: MaxScan check Max-Component:MAX_065d92
2013.06.22 12:56:16 2: MaxScan MAX_065d92 is HeatingThermostat
2013.06.22 12:56:16 2: MaxScan MAX_065d92 attr scanTemp is ok
2013.06.22 12:56:16 2: MaxScan MAX_065d92 found 2 thermostats
2013.06.22 12:56:16 2: MaxScan optimal scan intervall:3
2013.06.22 12:56:16 2: MaxScanis finished --------------------


Das Problem hast du hier ja schonmal mit Marcel R durchgekaut. Es fehlte das Reading "WindowsOpenTemperature" Dort hast du erwähnt, dass das Script den Fehler ab da erkennen sollte.

Ich hab jetzt einfach einmal
set MAX_065d92 windowOpenTemperature 12
ausgeführt und siehe da, im Log kam folgende Info:

Code Auswählen Erweitern

2013.06.22 12:56:17 2: MAX: Invalid value  for READING comfortTemperature. Forcing to 21
2013.06.22 12:56:17 2: MAX: Invalid value  for READING ecoTemperature. Forcing to 17
2013.06.22 12:56:17 2: MAX: Invalid value  for READING maximumTemperature. Forcing to on
2013.06.22 12:56:17 2: MAX: Invalid value  for READING minimumTemperature. Forcing to off
2013.06.22 12:56:17 2: MAX: Invalid value  for READING windowOpenTemperature. Forcing to 12
2013.06.22 12:56:17 2: MAX: Invalid value  for READING windowOpenDuration. Forcing to 15
2013.06.22 12:56:17 2: MAX: Invalid value  for READING measurementOffset. Forcing to 0
2013.06.22 12:56:19 3: battery 0, rferror 0, panel 0, langateway 1, dstsetting 1, mode 1, valveposition 0 %, desiredTemperature 19, until , curTemp
2013.06.22 12:56:21 2: MaxScan is called --------------------
2013.06.22 12:56:21 2: MaxScan check Max-Component:MAX_065d7c
2013.06.22 12:56:21 2: MaxScan MAX_065d7c is HeatingThermostat
2013.06.22 12:56:21 2: MaxScan MAX_065d7c attr scanTemp is ok
2013.06.22 12:56:21 2: MaxScan check Max-Component:MAX_065d92
2013.06.22 12:56:21 2: MaxScan MAX_065d92 is HeatingThermostat
2013.06.22 12:56:21 2: MaxScan MAX_065d92 attr scanTemp is ok
2013.06.22 12:56:21 2: MaxScan MAX_065d92 found 2 thermostats
2013.06.22 12:56:21 2: MaxScan optimal scan intervall:3
2013.06.22 12:56:21 3: MaxScan.MAX_065d92 - create local hash NextScan:2013-06-22 12:57:09
2013.06.22 12:56:21 3: MaxScan next scan in seconds:48  next thermostat-scan : 1371898629 curTime:1371898581
2013.06.22 12:56:21 2: MaxScanis finished --------------------

Readings sind nun alle vorhanden und der Scan klappt nun auch. Beim 2. Thermostat das gleiche Spiel nochmal und schon erscheinen die Einträge im MAX_LOG.


VG
Stefan

[Harald]

Hallo zusammen,

habe jetzt beide Ergänzungen (Zeile 439 und 654) nochmals in 00_MAXLAN.pm eingefügt und keine Fehlermeldungen mehr.
Allerdings finde ich auch keine Readings "dutycycle". Übrigens benutze ich tatsächlich onDemand.

Ich würde mich freuen, wenn mir jemand weiterhelfen könnte?

Viele Grüße

Harald

[John]

Hallo Harald,
zu deinem Beitrag

Wäre toll, wenn die Diagramme bald nicht mehr so konfus wären. Ich möchte nämlich aus Sicherheitsgründen
(Spannungsausfall) nicht auf die MAX-eigene Temperatursteuerung verzichten.

Nach dem derzeitigen Stand, musst du auf die Wochenprogramme in den Max-Ventilen selbst verzichten.
Dies wird als Voraussetzung angenommen, falls man den Scanner einsetzen will.

Wenn du darauf nicht verzichten kannst, ist der Scanner nicht geeignet.

John

[Harald]

Hallo John,

danke für die Klarstellung. Das hattest Du ja schonmal gesagt. Ich dachte, dass auf Grund der Infos von J. Isleib vielleicht weiter entwickelt wurde,
damit das auch mit dem Qube funktioniert. Ich bin dazu leider nicht in der Lage :-((

Trotzdem Hut ab vor Euren Leistungen und dafür, dass Ihr uns Anfänger wo möglich unterstützt und auf die Sprünge helft.

Einen schönen Sonntag noch

Harald

[Jürgen I.]

Ich arbeite aktuell an einem Scanner nach dem hier vorgeschlagenen Prinzip der Modusänderung integriert in das 10_MAX.pm Modul. Noch bin ich nicht so weit aber er macht Fortschritte.
Der Scanner ist für beide Arten gedacht, also Cube oder CUL. Den CUL kann ich nicht testen, da fehlen ein paar notwendige Codezeilen im CULMAX.pm Modul ( dutycycle als Wert von 0% bis 100% )
Funktionen:
- er schaltet nur den Modus hin und her
- erkennen von manuellen Modusänderungen (Handeingriff)
- beibehalten des internen Wochenprogrammes soll weiterhin möglich sein
- scanTemp erhält 3 Möglichkeiten
      0-> aus
      1-> Modusänderung nur nach Zeitintervall ( "auto" warten "manual" warten "auto" )          // noch nicht in arbeit
      2-> Modusänderung nach Zeitinterval und nach 1 Minuten wieder in den ursprünglichen Modus  // da arbeite ich primär dran
                                               ( "auto" warten "manual" 60sec. "auto" )
- Dutycycle wird bis ca. 70 % genutzt, Rest bleibt für manuelle Änderungen verfügbar.

Ich hoffe ich kann ihn bald mal publik machen.

[Harald]

Das ist ja richtig toll, was Du da vorhast! Das ist, glaube ich jedenfalls, genau das, was vielen MAX! Benutzern fehlt.

Ich bedanke mich schonmal im Voraus, dass Du Dir die Arbeit machst und wünsche Dir viel Erfolg.

Viele Grüße

Harald

[John]

Hallo J. Isleib

es wäre wirklich ein Gewinn für alle, die die Max-Thermostate über einen Cube fahren, wenn
der Temperaturscanner auch für diesen verfügbar wäre.

Wenn ich dich unterstützten kann, mach ich dies nach meinen Möglichkeiten.

Einige Bemerkungen zu deinem Vorhaben und Erfahrungen von meiner Seite, die dir vielleicht weiterhelfen.
(gilt alles nur bei Einsatz eines CULs, mit CUBE habe ich keine Erfahrungen)

Scann-Verfahren

2-> Modusänderung nach Zeitinterval und nach 1 Minuten wieder in den ursprünglichen Modus // da arbeite ich primär dran

Damit verwendest du das Grundprinzip das schon Jurij ein seinem ersten Ansatz
Link
verfolgt hat.

Das Zurückschalten Ursprungsmodus benötigt die doppelte Sendezeit.
Damit werden die möglichen Abtastpunkte/Stunde eines Thermostats halbiert.
Bei 8 Thermostaten ergibt dies eine Reduzierung von 4 auf 2 Tastpunkte pro Stunde.

Wochenprogramm im Thermostat beibehalten

Die Problematik habe ich hier
Link
beschrieben

c. während der Umschaltzeit zu Automatik tritt ein Schaltpunkt ein

Das Problem tritt einfach deshalb auf, weil der neue Sollwert nicht sofort, sondern mit einer Verzögerung von bis zu 3 Minuten
an FHEM gesendet wird. FHEM geht also für bis zu 3 Minuten von falschen Voraussetzungen aus.
Modus umschalten geht meines Wissens immer nur gleichzeitig mit "Sollwert setzen". Geschieht dies in dieser "unsicheren" Phase
überschreibst du den neuen Sollwert des Thermostaten, mit dem alten von FHEM.
Das gilt auch, wenn man manuell den Sollwert eines Thermostats ändert.

Auch der Fensterkontakt macht einem das "Leben" (und Programmieren) nicht leichter.

John

[Jürgen I.]

!!!BETA!!!
hier mal meine 2 Dateien.
noch fehlt die Überwachung des Türkontaktes.

nur mal zum Testen, beta.

ich kann eine weile nicht mehr dran arbeiten, würd mich aber freuen über Anregungen und Problemlösungen. THX John für die Infos

- einige Änderungen betreffen auch die Darstellung der RAWMSG

- CUL_Max benötigt ein Reading "dutycycle" von 0% bis 100% sowie ein   "Dispatch($hash, "MAX,0,scanTempCheck,$lastaddr,0", {});"
 genauso wie im MAXLAN, dabei ist $lastaddr einfach die Adresse des letzten Thermostaten. Wie das im CUL_MAX umgesetzt werden kann ?
 Vielleicht kann das jemand mit CUL programmieren und testen, einfach mal den Bereich im angehängten MAXLAN um Zeile 700 anschauen.

- Automatik der Thermostate sollte weitesgehend funktionieren. Bei Updates und "Shutdown restart" etc. können aber Fehler auftreten,
 hier also danach drauf achten das der gewünschte Modus wieder eingestellt wird.

klar das die Dateien nach einem Update dieser verloren gehen

Also wer Lust hat kann testen, vieleicht kann das ein oder andere auch in die orginalen Dateien von M. Gehre übernommen werden.
Erklärung zur Funktionsweise
scanTemp = 0 -> aus
scanTemp = 1 -> Modus umschalten nach berechnetem Wert ( John´s Prinzip)
scanTemp = 2 -> Modus nach berechnetem Wert umschalten und zurück nach Empfang einer neuen Temperatur oder nach spätestens 3 Minuten (Jurij´s Prinzip)

der Dutycycle wird bis 70% benutzt danach gibts kein Wechsel, Ausnahme der wieder zurück. Rest kann durch Handeingriffe genutzt werden.

!!!BETA!!!

PS. mir ist aufgefallen das Thermostate die am Wandthermostat hängen keine eigene IST Temperatur mehr haben, sie senden immer die
gleiche Temperatur die der Wandthermostat hat, zeitversetzt. Ist das sonst noch jemandem aufgefallen ? Ich hab den Wandthermostat dazu mal in Keller gelegt.

[Harald]

Hallo Jürgen,

besten Dank erstmal für Deine Arbeit. Ich habe gerade mal getestet.

Ich habe die beiden Dateien in's Verzeichnis "FHEM" übertragen und fhem neu gestartet. In fhem.log finde ich einige Fehlermeldungen:

Code Auswählen Erweitern

2013.06.30 15:47:17 1: MAX_Parse: scanTempCheck Start
2013.06.30 15:47:17 2: Max_ScanTemp: Wohnzimmer1 is Max-Component
2013.06.30 15:47:17 3: Max_ScanTemp: Wohnzimmer1 is HeatingThermostat
2013.06.30 15:47:17 2: Max_ScanTemp: Wohnzimmer1 attr scanTemp is ok
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xea5c40)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xe83a80)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xcf98c0)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xcf90b0)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xcf9360)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xcf9980)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xea6330)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xcff4a8)
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xf11238)
2013.06.30 15:47:17 2: Max_ScanTemp: Wohnzimmer2 is Max-Component
2013.06.30 15:47:17 3: Max_ScanTemp: Wohnzimmer2 is HeatingThermostat
2013.06.30 15:47:17 2: Max_ScanTemp: Wohnzimmer2 attr scanTemp is ok
2013.06.30 15:47:17 2: Max_ScanTemp: Computer is Max-Component
2013.06.30 15:47:17 3: Max_ScanTemp: Computer is HeatingThermostat
2013.06.30 15:47:17 2: Max_ScanTemp: Computer attr scanTemp is ok
2013.06.30 15:47:17 2: Max_ScanTemp: Bad is Max-Component
2013.06.30 15:47:17 3: Max_ScanTemp: Bad is HeatingThermostat
2013.06.30 15:47:17 2: Max_ScanTemp: Bad attr scanTemp is ok
2013.06.30 15:47:17 3: Max_ScanTemp: Invalid IODev  HASH(0xcf93a0)
2013.06.30 15:47:18 3: Max_ScanTemp: Invalid IODev  HASH(0xe5dda0)
2013.06.30 15:47:18 3: Max_ScanTemp: Invalid IODev  HASH(0xcf9040)
2013.06.30 15:47:18 2: Max_ScanTemp: Qube is Max-Component
2013.06.30 15:47:18 2: Max_ScanTemp: Qube is Cube
2013.06.30 15:47:18 1: Max_ScanTemp: Qube Dutycycle: Status: 12 %
und in telnet werden Fehler in Bezug auf 10_MAX.pm und 00_MAXLAN.pm angezeigt.

Code Auswählen Erweitern

Missing argument in sprintf at ./FHEM/00_MAXLAN.pm line 443
dort steht $hash->{dutycycle} = sprintf("%3.0f %", $dutycycle);
nach Entfernen des 2. "%" ist diese Meldung weg.

Use of unitnitialized value in concatenation (.) or string at ./FHEM/10_MAX.pm line 671, 931, 934, 943, 966, 970
Use of unitnitialized value in concatenation (.) or string at ./FHEM/10_MAX.pm line 804
Diese beiden Meldungen haben mit Log 3 Ausgaben zu tun:
 
Zeile 671 + 804: Log 3, "Max: $shash->{NAME} neu:$measuredTemperature gespeichert:$var desTemp:$des istneu:$shash->{newTemp}";
wenn ich diese auskommentiere, bekome ich keine Fehlermeldungen mehr auch nicht bez. line 931-970
außer:
Argument "manuel" isn't numeric in multiplication (*) at ./FHEM/10_MAX.pm line 280
Use of unitnitialized value in numeric eq (==) or string at ./FHEM/10_MAX.pm line 969
Use of unitnitialized value in numeric lt (<) at fhem.pl line 2692
Use of unitnitialized value $def in hash element at fhem.pl line 2772
Use of unitnitialized value $found[0] in string eq at fhem.pl line 2648
Wenn ich die Original-Dateien wieder einfüge, gibt es keine Fehlermeldungen.

Ich hoffe, ich konnte Dir ein wenig helfen. Viele Grüße

Harald

[Harald]

Ich habe noch einige Beobachtungen zu berichten:

Auch wenn alle Thermostaten mittels des ECO-Tasters auf ECO (16°C) geschaltet sind, werden einige (immer unterschiedliche) während des Tages auf die
AUTO-desiredTemperatur geschaltet. Zur Zeit läuft scanTemp 1 (passiert auch bei scanTemp 2).

Die Temperaturkurven hinken machmal bis zu 3 Std. hinterher. Nach Neustart von fhem ist das meist behoben aber nicht immer.

Setzt man Temperaturen über die WEB-Oberfläche, dauert es oft sehr lange, bis man wieder Zugriff hat. Oft wird die neue Temperatur nicht übernommen.
Es erscheint die Meldung: MAX_LAN_Write:MAXLAN_SimpleWrite:Not connected.

Die MAX-Thermostate werden von andFHEM nicht mehr eingelesen. Es erscheint "Konnte 7 Gerät(e) nicht laden. Typen (MAX)!". Die werden natürlich
auch nicht angezeigt, die anderen Geräte wie ECO-Taster, Qube, CUL_WS, FS20 usw. sehr wohl.

Wäre toll, wenn meine Beobachtungen für die Weiterentwicklung hilfreich wären.

Nachtrag 13.7.13 18:32

Ich habe mal versucht, mit "#attr xxxxxxx scanTemp 1" scanTemp für alle Thermostate zu deaktivieren. Das hat aber nicht geklappt.
Die Funktion läuft munter weiter mit allen o.g. Erscheinungen.

Schreibe ich "attr xxxxxxx scanTemp 0", steht im Logfile für alle 7 Thermostate "Max_ScanTemp: xxxxxxxx scanTemp is inaktiv".
Danach stürzt FHEM ab mit einer Meldung in Telnet "Illegal devision by zero at ./FHEM/10_MAX.pm line 785". Im Logfile
steht dann natürlich nichts mehr.

Nachtrag 18.7.13

Habe gerade festgestellt, das ich bei der Angabe bez. Zeile 671 + 804: einen Fehler gemacht habe. Dort steht nicht das angegebene,
sondern:     Log 3, "Max_ScanTemp: Invalid IODev $shash->{NAME} $shash";
und die Fehlermeldungen bez. line 931-970 sind doch noch da.


Viele Grüße

Harald

Eine Frage noch: Die gemeldeten Werte von "dutycycle" sind das die verbrauchten oder die noch verfügbaren? Sie liegen bei mir bei ca. 12-36%.
Hat sich erledigt. Es sind die benutzten Credits. Letzte Nacht stieg dutycycle (warum auch immer) über längere Zeit (ca. 3Std.) auf 94% und es
wurden keine Temperaturkurven geschrieben. Dann sank der Wert plötzlich auf 0%, um dann langsam auf ca. 24% +- 6 (also normal) zu steigen.

[Harald]

Hallo zusammen,

da Jürgen, wie er ja schon schrieb, über längere Zeit verhindert ist, versuche ich mal mit Eurer Hilfe ein paar Ungereimtheiten aus seinem 10_MAX.pm zu korrigieren.

Code Auswählen Erweitern

in Zeile 968-971 steht

968   my $temp = $measuredTemperature;
969   if (($temp ne "" or $temp != 0) and ($shash->{newTemp} == 0 or ($temp != $var))) {
970   Log 3, "Max: $shash->{NAME} neu:$measuredTemperature gespeichert:$var desTemp:$des istneu:$shash->{newTemp}";
971   readingsBulkUpdate($shash, "temperature", sprintf("%2.1f",$measuredTemperature));
außerdem:
280   my $payload = sprintf("%02x", int($temperature*2.0) | ($ctrlmode << 6));
dazu gibt es in telnet folgende Fehlermeldungen:

Use of uninitialized numeric eq (==) at ./FHEM/10_MAX.pm line 969
Use of uninitialized value in concatenation (.) or string at ./FHEM/10_MAX.pm line 970

Argument "manual" isn't numeric in multiplication at (*) ./FHEM/10_FHEM.pm line 280

Außerdem gibt es noch eine Meldung: Use of uninitialized value in numeric lt (<) at fhem.pl line 2721.
Dort steht: for each my oidx (keys %duplicate){
if /duplicate {$oidx}{TIM} < $lim) {


Kann mir jemand sagen, was da falsch ist?

Besten Dank im Voraus und viele Grüße

Harald

PS: Ich glaube, ich hab' was gefunden! So müsste es richtig sein, oder?

Änderung:   Log 3, "Max: $shash->{NAME} neu: $measuredTemperature gespeichert: $var desTemp: $des istneu: ";#$shash->{newTemp}";
in Zeilen 931, 934, 943, 966 und 970 erzeugen keine Fehlermeldungen mehr.
Somit scheint es etwas mit $shash->{newTemp} zu tun zu haben, oder?

969   if ((($temp ne "") or ($temp != 0)) and (($shash->{newTemp} == 0) or ($temp != $var))) {
Fehlermeldung jetzt: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/10_MAX.pm line 969

[John]

Die Beitrage über die Fake-Fensterkontakte habe mich dazu gebracht das Faken selbst zu probieren.

Dabei habe ich folgendes gemacht:

a. 2 Thermostate mit identischer GroupID versehen

b. beide via

set HTXY associate fakeShutterContact

mit FHEM gepaart

c. die WindowOpenTemperatur um 0.5 Grad unterhalb der desiredTemperatur eingestellt


Wenn man den SC (Schuttercontact) via fake Befehl virtuell öffnet, schicken beide Thermostate brav nach
spätestens 2 Minuten Istwert und Valveposition. Dasselbe passiert beim virtuellen Schliessen des SCs.

Das bedeutet, man kann mit einem einzigen Befehle gleichzeitig mehrere HTs dazu bringen ihre Istwerte zu senden.
Freilich um den Preis, den Sollwert leicht verändern zu müssen.

Leider klappt das nicht, wenn die WindowOpenTemperatur identisch mit desiredTemperatur ist.

Natürlich stellt sich auch sofort die Frage, was wir mit den physischen Fensterkontakten machen, dazu später mehr.

Damit lässt sich das Scannen deutlich verbessern (schneller und gleichzeitig mehr Thermostate).

Das Umschalten von Mode (Wechsel Auto<->Manu) würde dann entfallen.

Zu bedenken ist auch, was das Thermostat verhält, wenn immer wieder der Sollwert verstellt wird.



John

[Harald]

Hallo zusammen,

in MAX!Buddy gibt es unter Übersicht/Haus ein Ausklappmenu, das auch einen Button "Automatik" enthält. Damit kann man alle Thermostate (Räume) mit einem Befehl auf Automatik
setzen. Ein Setzen auf "manuel" ist mit /Haus/Eco (o.ä.)/dauerhaft möglich.
Vielleicht hat ja jemand Kontakt zu dem Entwickler Sebastian. Dann könnte man evtl. erfahren, welche Befehle dazu nötig sind und damit verhindern,
dass es Zeitprobleme mit den Wochenprogrammen und Automatik/manuel-Umschaltung gibt.

Derzeit läuft bei mir Jürgens Lösung im Modus 1 eigentlich ganz gut. Es wird hin und wieder bei unterschiedlichen Ventilen entweder nicht ordnungsgemäß
wieder auf den richtigen Modus (Auto<->Manuel) geschaltet oder die Solltemperatur (Tag/Nacht) wird nicht richtig eingestellt.
Die Funktion "Automatik" von MAX!Buddy benutze ich immer dann, wenn in FHEM die Solltemperatur bzw. der Modus bei einzelnen Ventilen nicht so wie bei den anderen ist.

Im Übrigen finde ich John's Idee ganz prima. Könnte man diesen Effekt evtl. auch mit der Manipulation der Ventilöffnung erzielen,
oder ist das garnicht von FHEM zu beeinflussen bzw. hätte es nicht die gewünschte Wirkung?

Wäre schön, wenn dieser Weg dann auch mit dem Qube und den integrierten Wochenprogrammen funktionieren würde.

Viele Grüße

Harald

[Zwer2k]

Hallo John,

nutze seit längerem dein Script, allerdings hatte ich damals festgestellt, dass bei offenem Fenster die Temperatur des öfteren hochgestellt wird. Ich hatte damals bei mir den Fehler behoben gehabt und hatte zusätzlich eingebaut, dass die Thermostate in der OFF Stellung nicht geschaltet werden. Hatte alles ganz gut funktioniert, bis vor einigen Tagen beim Fhem-Update mein Fhem zerschossen wurde (zu wenig Plattenspeicher) und die die Änderungen verloren gegangen sind. Wollte die Änderungen damals nicht ungetestet hier rein stellen. Hast du eventuell Idee wie das schnell zu beheben ist? Sonst werde ich mich nächste Tage wieder damit beschäftigen.


Gruß
Jurij

[John]

Hallo Jurij,

anbei mein aktuelles Skript angelehnt an der letzten Veröffentlichung.

Folgende Änderungen:

Name des Skripts geändert zu 99_UtilsMaxScan
Damit ist es nun "Edit Files" sichtbar.

Attribut watchShutter als UserReading ausgeführt
Damit muss bei 10_MAX.pm nicht mehr nachgeführt werden.
Die Änderungen waren nach einem Update der Software stets verschwunden.
Beispiel für HeatingThermostat HT.JOHN mit ShutterContact SHUTTER.JOHN.

Code Auswählen Erweitern

attr HT.JOHN userReadings watchShutter { return "SHUTTER.JOHN";;}

Boost wird berücksichtigt
Wie bei geöffnetem Fenster, wird auch im Boost-Mode der Scanner inaktiv

Fixes:
notify MaxScan_Shutter_Notify nur erzeugen, wenn mindestens ein Shutter assoziiert wurde.

John