Homematic Heizkrperthermostat schalten über ReadingsGroup schalten geht nicht

Begonnen von Saphora, 10 November 2017, 10:35:39

Vorheriges Thema - Nächstes Thema

Saphora

Hallo,
ich bastle aktuell an der Umsetzung der ReadingsGroup für Wandthermostat und Heizkörperthermostat (wie im Wiki beschrieben).
Ea klappt auch alles soweit, bis auf die Umschaltung des GlobalButtonLock.
Laut Wiki Code geht es wie folgt:


attr heatingInfo commands {
"R-globalBtnLock.on"=>"set %DEVICE regSet globalBtnLock off",

"R-globalBtnLock.off"=>"set %DEVICE regSet globalBtnLock on"}


Wird dann auf den Button gedrückt, wird auch etwas ausgelöst. Es werden CMDs erzeugt und im Reading globalBtnLock steht set_off. Das ist soweit mir bekannt auch richtig, um Register zu schalten. Jedoch steht das nun da, alle CMD sind abgearbeitet und es passiert nichts, ausser das globalBtnLock = set_off darsteht.
Muss noch etwas angepasst werden, dass das Heiszungsthermostat den Befehl umsetzt?
Dankeschön.

Viele Grüße

Beta-User

Wie lange hast du denn gewartet? Das dauert uU. 2,5 Min, bis der RT-DN mal wieder aufgewacht ist und die Anweisungen abholt.

An sich sieht das nämlich ok aus.

Kann auch sein, dass man erst mal ein update der Readings anstoßen muß, bis man es in FHEM sieht. Zeigt denn das LCD am RT-DN das zutreffende Ergebnis an?

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

eisman

Hi,

ich habe oder Hatte das Problem schon seit 1 Jahr,
wenn ich das setze kann ich alles auf Werkseinstellung setzen und
neu einrichten. habe daher meine Heizung auf Central umgestellt
und regel alles über FHEM. Das geht ohne Probleme.
Global_Lock am gerät eingestellt und
controlMode auf Central

gruss
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 7x ESP
1x FHEM Debian, Homematic,Z2M             / 1X Raspberry, ConBee / 6x ESP
1x FHEM Debian,MQTT2                             / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

Saphora

@Beta-User
Also bei mir müssen tatsächlich die Readings gelöscht und mit getConfig neu ei gelesen werden.
Das steht im Wiki nicht so. Dort scheint es ohne weitere Befehle zu gehen :(

Beta-User

Zitat von: Saphora am 10 November 2017, 12:17:37
@Beta-User
Also bei mir müssen tatsächlich die Readings gelöscht und mit getConfig neu ei gelesen werden.
Das steht im Wiki nicht so. Dort scheint es ohne weitere Befehle zu gehen :(
Die Antwort verstehe ich nicht ganz.
1. Warum readings löschen?
2. getConfig: dient ja nur dazu, abzusichern, dass etwas wirklich beim Empfänger angekommen ist; dadurch werden die readings aktualisiert (weil alle Register neu abgefragt werden).
3. Wichtig ist doch eigentlich, dass der Befehl am Geät abgearbeitet wird (=>Anzeige am LCD). So wie das klingt, passiert das ja, es wird (leider, aber dennoch eben) nur das reading nicht aktualisiert. Scheint eine Maßnahme zu sein, um das Funkbudget möglichst nicht zu belasten bzw. Batterie zu sparen.
Macht es Sinn, sich an diesem Schönheitsfehler (m.E.) aufzuhalten?

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Saphora

Readings löschen in FHEM, damit mit getConfig die tatsächlichen Readings angezeigt werden. Wenn ich nur getConfig mache, bleibt set_off stehen.
Klar kann man damit leben, aber für die Anzeige wäre ea halt in der ReadingsGroup von Nachteil, da der ButtonLock nicht ersichtlich ist.
Eine mögliche Lösung gibt es nicht?
Klar kann man dem set_off einfach dem Wert als gesetzt zuordnen. Aber falls das mal nicht geklappt hat, wird es nicht aus der Anzeige ersichtlich.

Beta-User

Nach getConfig muß man uU. erst mal den pair-Modus anstoßen, damit die Register übertragen werden. Das kommt mir alles komisch vor und ist sicher keine alltagstaugliche Vorgehensweise.

Ich müßte das erst mal zuhause nachstellen, und wenn, würde ich in jedem Fall mal annehmen, dass es sich nicht um ein readingsGroup-spezifisches Problem handelt.

Was hast du für eine Firmwareversion da drauf? Meine sind auf 1.4, das sollte die aktuellste sein (ausgeliefert mit 1.2).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Saphora

GetConfig holt sofort die Readings  :o
Also die Firmware 1.4 ist drauf

Saphora

Ich habe jetzt mal FHEM geupdatet. Jetzt machen alle Heizkörperthermostate das umschalten inklusive Reading nach spätestens ca. 10 Minuten. Das passt.
Aber alle drei Wandthermostate machen es weiterhin nicht. Prinzip sollte wie beim Heizkörperthermostat sein?
CMD sind alle auf done.
GetConfig aktualisiert das Reading GlobalButtonLock innerhalb weniger Sekunden.

Beta-User

Eigentlich sollte das ähnlich sein, aber manchmal gibt es abweichende Bezeichnungen (das scheint hier aber zu passen, sonst wäre es nach getConfig nicht da...).

Testen geht ggf. erst später, firmware ist aktuell?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Saphora

Firmware ist die aktuelle 1.3.
Habe. Jetzt 1h gewartet, aber das Reading aktualisiert nicht :-[