Heizkörperthermostat Meldung INS abfangen

[CCU-Anfaenger]

Hallo an die Spezialisten des Forums,
ich bin ganz neu hier im Forum, obgleich ich schon lange immer wieder mitlese und viele gute Lösungsmöglichkeiten finden konnte. Dafür an dieser Stelle ein herzliches DANKESCHÖN!

Nun komme ich aber mit einem Problem nicht weiter: Öfters gehen mehreren meiner Heizkörperthermostate Typ HM-CC-RT-DN, ohne erkennbares Muster in den INS-Status und verschwenden währendessen unnötig Heizenergie, bis man die Adaptierfahrt manuell durchführt. Die Ventile an den Heizkörpern habe ich auf einen Hinweis aus einem anderen Forenbeitrag hin kontrolliert und diese sind normal leichtgängig. Aktuell ist ja auch Heizperiode und jeder Heizkörper wird sicher mehrmals täglich auf und zu geregelt. Problem kommt übrigens auch nach Wechsel der Batterien nach unbestimmter Zeit wieder vor. Insgesamt gefühlt 1-2 mal im Monat, aber auch schon 2x innerhalb einer Woche. Mit der wöchentlichen Entkalkungsfahrt gibt es keinen zeitlichen Zusammenhang.

Nun zu meiner Frage an die Profis hier:
Gerne würde ich den auftretenden INS-Zustand des Reglers per Script in meiner CCU-3 abfangen, welche mir dann z.B. eine einfache Mail schickt, welcher Regler gerade aktuel das Problem hat. Ich weiß jedoch nicht, ob es einen geeigneten Datenpunkt des Reglers gibt, den ich hierfür auswerten könnte. Per Script habe ich mal folgende Datenpunkte unten des HM-CC-RT-DN Reglers auslesen können, weiß jemand ob einer davon zu diesem Zweck zu gebrauchen ist, da nicht alle (zumindest für mich) selbsterklärend sind? Gerne sind auch andere Vorschläge willkommen. Ach übrigens: Wenn der INS-Zustand auftritt zeigt die Ventilposition in der CCU "0% offen", obwohl es aktuell 100% offen ist.

Schon mal herzlichen Dank für Eure Lösungsvorschläge!

Grüße

BidCos-RF.NEQ1228455:0.AES_KEY
BidCos-RF.NEQ1228455:0.CONFIG_PENDING
BidCos-RF.NEQ1228455:0.DEVICE_IN_BOOTLOADER
BidCos-RF.NEQ1228455:0.INHIBIT
BidCos-RF.NEQ1228455:0.LOWBAT
BidCos-RF.NEQ1228455:0.RSSI_DEVICE
BidCos-RF.NEQ1228455:0.RSSI_PEER
BidCos-RF.NEQ1228455:0.STICKY_UNREACH
BidCos-RF.NEQ1228455:0.UNREACH
BidCos-RF.NEQ1228455:0.UPDATE_PENDING
BidCos-RF.NEQ1228455:4.ACTUAL_TEMPERATURE
BidCos-RF.NEQ1228455:4.AUTO_MODE
BidCos-RF.NEQ1228455:4.BATTERY_STATE
BidCos-RF.NEQ1228455:4.BOOST_MODE
BidCos-RF.NEQ1228455:4.BOOST_STATE
BidCos-RF.NEQ1228455:4.COMFORT_MODE
BidCos-RF.NEQ1228455:4.CONTROL_MODE
BidCos-RF.NEQ1228455:4.FAULT_REPORTING
BidCos-RF.NEQ1228455:4.LOWERING_MODE
BidCos-RF.NEQ1228455:4.MANU_MODE
BidCos-RF.NEQ1228455:4.PARTY_MODE_SUBMIT
BidCos-RF.NEQ1228455:4.PARTY_START_DAY
BidCos-RF.NEQ1228455:4.PARTY_START_MONTH
BidCos-RF.NEQ1228455:4.PARTY_START_TIME
BidCos-RF.NEQ1228455:4.PARTY_START_YEAR
BidCos-RF.NEQ1228455:4.PARTY_STOP_DAY
BidCos-RF.NEQ1228455:4.PARTY_STOP_MONTH
BidCos-RF.NEQ1228455:4.PARTY_STOP_TIME
BidCos-RF.NEQ1228455:4.PARTY_STOP_YEAR
BidCos-RF.NEQ1228455:4.PARTY_TEMPERATURE
BidCos-RF.NEQ1228455:4.SET_TEMPERATURE
BidCos-RF.NEQ1228455:4.VALVE_STATE

[Xel66]

Es gibt keine direkte Möglichkeit, diesen Zustand zu erkennen. Es bleibt Dir also nur die Ursachenforschung, warum Ventile in diesen Modus gehen. Eine Ursache könnte ein Kontaktmangel der Batterien sein, der die Thermostate neu booten lässt (nein, auch "DEVICE_IN_BOOTLOADER" ist da nicht hilfreich, da das Thermostat ja durchbootet) oder eine zu geringe Versorgungsspannung durch Verwendung von Akkus. Ursache ist jedenfalls ein Neustart der Thermostate. Und normal ist das nicht. Ich betreibe das System mit den HM-CC-RT-DN nunmehr sein deren Erscheinen (also vor fast 10 Jahren) und hatte bisher noch keine derartigen Effekte und kenne den INS-Zustand nur durch den Batteriewechsel. Ich betreibe meine Thermostate und eigentlich alle Hm(IP)-Geräte ausschließlich mit Batterien vom Lidl (aktuell die blauen).

EDIT: Eine Idee hätte ich vielleicht. Aber hierfür müssten die Scripter ran. Das ist mir zu aufwändig. Vielleicht kannst Du dieses Problem an @Henke hier aus dem Forum herantragen. Der codet gern. Vorgehensweise: Man könnte den Zeitstempel des Datenpunkts "DEVICE_IN_BOOTLOADER" auswerten. Dieser trägt im Normalzustand das letzte Boot-Datum der CCU, wenn in der Zwischenzeit nicht die Batterien gewechselt wurden. Hier könnte man periodisch schauen, ob dieser innerhalb der letzten überwachten Periode neu gesetzt wurde. Man würde z.B. stündlich schauen, ob die Differenz des Zeitpunkt zur aktuellen Systemzeit kleiner eine Stunde ist und dann eine entsprechende Aktion auslösen. Bei einem Reboot und einem Batteriewechsel bekommt man dann einmalig diese Warnung trotzdem.

Gruß Xel66

[rr745]

dann sind die teile doch quasi nicht erreichbar.
frag doch den Status "unreach" ab.

[Sven_A]

Was ich in den letzten zwei Jahren beobachtet habe: Ich hatte zum testen mal die sauteueren "Varta Energy on Demand" Batterien bestellt, die zum Teil auch mit "Smart Home" beworben wurden. Die liefern Power bis zum totalen Zusammenbruch, der dann so schnell kommt das Wandthermostate&Co. es nichtmehr geschafft haben eine LowBat Meldung zu schicken. Seitdem nutze ich wieder die normalen "Varta High Energy".

Wenn deine Thermostate nach der Ins-Fahrt wieder laufen wird es das eher nicht sein, trotzdem kann es nicht schaden mal einen anderen Batterietyp zu testen.

[Henke]

Aktive mal das Systemprotokoll auf Kanal 0 und 4.
Mal sehen was bei DEVICE_IN_BOOTLOADER und FAULT_REPORTING kommt.

[Xel66]

dann sind die teile doch quasi nicht erreichbar.

Nö! Was ist an ...

Ach übrigens: Wenn der INS-Zustand auftritt zeigt die Ventilposition in der CCU "0% offen", obwohl es aktuell 100% offen ist.

... nicht verständlich? Die Teile booten ja vollständig durch und verhalten sich in der WebUI ganz normal, nur dass sie eben physisch nicht funktionieren, weil sie auf den "initialen" Adaptionslauf warten. Und auch diesen kann man nicht von extern anstoßen, sondern muss die Boost-Taste vor Ort drücken.

Mal sehen was bei DEVICE_IN_BOOTLOADER und FAULT_REPORTING kommt.

In der Anleitung für die Datenpunkte stehen für Kanal 4 folgenden Signalisierungsmöglichkeiten für FAULT_REPORTING...

Code: Alles auswählen

...
Parameter FAULT_REPORTING
Typ: option
Zugriffsart: lesend
 über Ereignisse
Werteliste: 
0 = NO_FAULT (Standard)
1 = VALVE_TIGHT
2 = ADJUSTING_RANGE_TOO_LARGE
3 = ADJUSTING_RANGE_TOO_SMALL
4 = COMMUNICATION_ERROR
5 =
6 = LOWBAT
7 = VALVE_ERROR_POSITION

Der Punkt VALVE_ERROR_POSITION wird aber in dem Fall nicht gesetzt, weil es keine Fehlerposition ist. In den vergangenen Jahren haben sich an dem Problem schon mehrere Anwender versucht. Kanal 0 ist nicht dokumentiert, aber DEVICE_IN_BOOTLOADER ist ein boolscher Wert. Da kann außer true und false auch nicht viel kommen.


Gruß Xel66

[rr745]

dann sind die teile doch quasi nicht erreichbar.

Nö! Was ist an ...

Ach übrigens: Wenn der INS-Zustand auftritt zeigt die Ventilposition in der CCU "0% offen", obwohl es aktuell 100% offen ist.

... nicht verständlich? Die Teile booten ja vollständig durch und verhalten sich in der WebUI ganz normal, nur dass sie eben physisch nicht funktionieren, weil sie auf den "initialen" Adaptionslauf warten. Und auch diesen kann man nicht von extern anstoßen, sondern muss die Boost-Taste vor Ort drücken.

Mal sehen was bei DEVICE_IN_BOOTLOADER und FAULT_REPORTING kommt.

In der Anleitung für die Datenpunkte stehen für Kanal 4 folgenden Signalisierungsmöglichkeiten für FAULT_REPORTING...

Code: Alles auswählen

...
Parameter FAULT_REPORTING
Typ: option
Zugriffsart: lesend
 über Ereignisse
Werteliste: 
0 = NO_FAULT (Standard)
1 = VALVE_TIGHT
2 = ADJUSTING_RANGE_TOO_LARGE
3 = ADJUSTING_RANGE_TOO_SMALL
4 = COMMUNICATION_ERROR
5 =
6 = LOWBAT
7 = VALVE_ERROR_POSITION

Der Punkt VALVE_ERROR_POSITION wird aber in dem Fall nicht gesetzt, weil es keine Fehlerposition ist. In den vergangenen Jahren haben sich an dem Problem schon mehrere Anwender versucht. Kanal 0 ist nicht dokumentiert, aber DEVICE_IN_BOOTLOADER ist ein boolscher Wert. Da kann außer true und false auch nicht viel kommen.


Gruß Xel66

Ich frage den Kanal 0 ab und wenn unreach dann Nachricht via Talagram aufs Handy um zu sehen warum nicht erreichbar (evtl. eben auch Batterie leer)

[Xel66]

Im Status INS ist das Gerät aber nun mal ganz normal erreichbar und steht mit 100% geöffneten Ventil da (Stift komplett im Thermostat zurückgezogen, aber übermittelter Ventilposition 0%!) und wartet auf die Adaptionsfahrt. Das hat nichts mit "Batterie leer" oder der Erreichbarkeit (RSSI-Werte) zu tun. Das Teil ist nur (aus welchem Grund auch immer) neu gebootet. Wäre die Zelle leer, würde es die Fehlerpostion anfahren und man hätte einen eindeutigen Trigger. Hat man aber in dem Fall nicht.

Kann man ganz einfach nachstellen, indem man kurzfristig mal die Batterien entfernt und wieder einsetzt. Du wirst in den Status der Datenpunkte nichts dazu finden. Der einzige Indikatior sind eben irgendwelche aktualisierten Zeitstempel. Es ist ja nicht so, dass das Problem in den fast 10 Jahren, in denen die Geräte auf dem Markt sind, noch nie aufgetreten wäre und Anwender nicht nach einer Möglichkeit gesucht hätten. Aber alle Threads dazu sind eben im Sande verlaufen, weil man diesen INS-Status eben nicht eindeutig anhand der Status der Datenpunkte identifizieren kann. Das Thermostat arbeitet ja und wartet auf die physische Anwenderinteraktion (ADA-Lauf durch Betätigung der Boost-Taste).

Gruß Xel66

[Henke]

Lass das mal laufen. Mal sehen, ob da irgendwas interessantes in den Zeitstempeln kommt.

Code: Alles auswählen

WriteLine("START");
string sDP;
foreach(sDP, dom.GetObject(ID_DATAPOINTS).EnumIDs()) {
  object oDP = dom.GetObject(sDP.ToInteger());
  if((oDP) && (oDP.Type() == OT_HSSDP) ) {
  if ( oDP.HssType() == "DEVICE_IN_BOOTLOADER" )  {
    WriteLine(oDP.Name() # " - " # " TS " # oDP.Timestamp() # "/" # oDP.Value()# " LT " # oDP.LastTimestamp()# "/" # oDP.LastValue() );
    }
  }
}
WriteLine("ENDE");

[Xel66]

Das Problem interessiert mich auch, obwohl ich keine Probleme damit habe, aber in der Vergangenheit eben schon davon gelesen habe. Habe mal bei mir das Script laufen lassen. Bis auf wenige begründete Ausnahmen tragen alle Geräte den Zeitstempel vom letzten Zentralenreboot (mit ein paar Sekunden Abweichung). Nur ein neues hinzugefügtes Wandthermostat und ein Heizkörperthermostat, bei welchem ich Mitte November die Batterien gewechselt habe, tragen einen anderen Stempel für den Bootloader. Ich kopiere mal nur etwas relevantes rein.

Code: Alles auswählen

...
BidCos-RF.PEQ1642565:0.DEVICE_IN_BOOTLOADER -  TS 2022-11-05 13:54:30/false LT 1970-01-01 01:00:00/false
BidCos-RF.SEQ0706450:0.DEVICE_IN_BOOTLOADER -  TS 2022-11-05 13:54:19/false LT 1970-01-01 01:00:00/false
BidCos-RF.SEQ3310718:0.DEVICE_IN_BOOTLOADER -  TS 2022-11-05 13:54:36/false LT 1970-01-01 01:00:00/false
BidCos-RF.SEQ2820337:0.DEVICE_IN_BOOTLOADER -  TS 2022-11-13 14:12:13/false LT 1970-01-01 01:00:00/false
VirtualDevices.INT0000004:0.DEVICE_IN_BOOTLOADER -  TS 2022-11-13 16:59:15/20.0 LT 1970-01-01 01:00:00/
BidCos-RF.TEQ2539116:0.DEVICE_IN_BOOTLOADER -  TS 2023-01-19 10:50:12/false LT 1970-01-01 01:00:00/false
VirtualDevices.INT0000005:0.DEVICE_IN_BOOTLOADER -  TS 2023-01-19 11:50:15/20.0 LT 1970-01-01 01:00:00/20.0
ENDE

Deckt sich mit meinen Überprüfungen in der XML-API. Die Abfrage des letzten Zeitstempel scheint nicht so richtig zu funktionieren.

Gruß Xel66