Achtung: Spontane HMID-Änderung in Wandthermostat (ohne Zutun) ...!?

Begonnen von Pfriemler, 12 August 2017, 15:05:55

Vorheriges Thema - Nächstes Thema

Pfriemler

Moinsen,
nein, es ist nicht der 1. April. Aber das ist echt komisch!

Vor 14 Tagen wurde mein Wandthermostat (HM-TC-IT-WM-W-EU) im Kellerbadezimmer für FHEM unsichtbar.
Folgende Symptome:
- actStatus auf "dead"
- keine Events empfangen, verbundene DOIFS und Events funktionierten nicht mehr.
- Display meldet "Funkverbindung ok" (Funksymbol dauerhaft an)
- keine Reaktion auf getStatus etc.
Der Thermostat ist mit einem Heizkörperthermostat und einem Fensterkontakt (SCo) gepairt, letzterer zusätzlich mit dem Heizkörper. So wird der Fensterstatus sofort an beide Geräte übermittelt und die Absenktemperatur bei offenen Fenster gesetzt.
- Fensterstatus wird sowohl am Heizkörper als auch am Wandthermostat sauber angezeigt
- SCo meldet aber stets "rot" - d.h. die Quittung der Empfänger fehlt (teilweise)
- Heizkörper reagiert nicht auf Temperaturänderungen am Wandthermostat.

Heute habe ich nun den Wandthermostat entnommen und in die Nähe meiner IOs gebracht, ein getStatus gesetzt und spaßeshalber mal den Drehknopf lange gedrückt (so versetzt man ihn in den Anlernmodus).

Fröhliches Geblinke,  und am Ende hatte ich ein neues Gerät in FHEM per autocreate. Dessen HMID war statt der erwarteten und bei der Inbetriebnahme damals extern dokumentierten 388E07 aber nun 388E47. In Auszügen:

Internals:
   DEF        388E47
...
   IODev      HMUART
   LASTInputDev HMLAN1
   MSGCNT     137
...
   rssi_at_HMLAN1 lst:-56 avg:-55.8 min:-69 max:-55 cnt:68
   rssi_at_HMUART max:-45 cnt:69 avg:-45.57 lst:-45 min:-58
   Readings:
     2017-08-12 14:11:27   D-firmware      1.3
     2017-08-12 14:11:27   D-serialNr      MEQ0180408
     2017-08-12 14:11:39   PairedTo        0x1411AB
     2017-08-12 14:11:39   R-burstRx       on
     2017-08-12 14:11:39   R-cyclicInfoMsg on
     2017-08-12 14:11:39   R-cyclicInfoMsgDis 0
     2017-08-12 14:11:39   R-pairCentral   0x1411AB


Ups? Hat da ein Nachbar ein neues Gerät? die rssi sprechen da eine andere Sprache und passen zu den Entfernungen zu meinen IOs.
Moment mal: Das Ding hat doch die gleiche Seriennummer!!!

Nun habe ich mal die Batterien aus dem Wandthermostat entfernt und nach kurzer Zeit wieder eingesetzt. Und plötzlich erwacht in FHEM das tote Gerät wieder zum Leben und die Daten fließen wieder. Und nicht nur das: Die Steuerung zum Heizkörperthermostaten funktionert auch wieder, und der SCo leuchtet wieder grün. Als sei nix gewesen.

Meine einzige Erklärung: Der Wandthermostat hat spontan seine HMID geändert! Dadurch aktzeptierte der Heizkörper die Anweisungen nicht mehr, und der SCo war nicht zufrieden, weil die Quittung vom erwarteten Gerät ausblieb. Dass FHEM keine Daten mehr empfing, war natürlich genauso logisch.

Hier die korrespondierenden Auszüge der DEF des verlorengegangen und nach dem Batterie-Neustart wieder erschienenen Gerätes:
Internals:
   DEF        388E07
...
   IODev      HMUART
   LASTInputDev HMLAN1
   MSGCNT   23696
...
   NAME       KBadThermostat
...
   rssi_HMUART min:-47 avg:-46.5 lst:-47 cnt:2 max:-46
   rssi_at_HMLAN1 avg:-67.13 lst:-64 min:-79 max:-51 cnt:11801
   rssi_at_HMUART max:-42 cnt:11658 avg:-77.29 lst:-74 min:-89
   Readings:
...
     2017-04-26 06:07:53   D-firmware      1.3
     2017-04-26 06:07:53   D-serialNr      MEQ0180408
     2017-08-12 14:21:22   PairedTo        0x1411AB
     2017-01-07 17:26:51   R-burstRx       on
     2016-02-29 12:40:11   R-cyclicInfoMsg on
     2016-02-29 12:40:11   R-cyclicInfoMsgDis 0
     2016-02-29 12:40:11   R-pairCentral   0x1411AB
...


Ist so etwas schon einmal beobachtet worden? Oder könnten manche spontane unerklärliche Nichtfunktionen (rein vom Display her schien ja alles in Ordnung, das Ding ließ sich bedienen und zeigte plausible Messwerte), die sich durch einen Batteriereset in Luft auflösen, vielleicht mit so etwas zu tun haben?

Wohlgemerkt: Das Problem entstand offenbar ohne Zutun von FHEM und hat auch mit FHEM nichts zu tun!
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

LuckyDay

Ich würde sagen der Flashspeicher im Gerät defekt, so etwas ähnliches habe ich bei den HM-SEC-RHS, die ihr pairing vergessen.

Nobby1805

Muss nicht unbedingt kaputt sein, es reicht auch ein (seltener) Soft-Error https://de.wikipedia.org/wiki/Soft_Error ... und ich glaube kaum, das eQ-3 Speicher mit Parity verwendet
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Pfriemler

@fhem-hm-knecht (wat'n schöner Name übrings, ich fühle mich direkt mit angesprochen   :o):
Flash-Speicher würde ich ja gerade nicht vermuten - nach einem "Stromausfall" startet das Ding ja mit den beabsichtigten und konfigurierten Werten. Oder vergessen Deine RHS ihr Pairing genauso und sind nach einem Batterie-Entfernen wieder von allein "da"? Ich konnte das jetzt auf die Schnelle nicht "ersuchen".

Soft-Error trifft es da schon eher, würde aber auch hier bedeuten, dass die gespeicherten Werte im Flash nur beim "Booten" gelesen werden und ansonsten im RAM bleiben - und genau da könnten sie sich verfälscht haben. Aber dass das ausgerechnet und nur die HMID betrifft...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

LuckyDay

vergisst entgültig, muß dann immer neu pairen mit Fhem.
Garantie ist schon lange abgelaufen.