Hallo zusammen,
ich habe im Bad einen HM-CC-RT-DN, der dummerweise einen zu hohen Stromverbrauch hat. Die Batterie hält nur ca. 6-8 Wochen. Da ich im Produktivbetrieb nicht testen kann, ohne es mir mit meiner besseren Hälfte zu verscherzen, habe ich mir einen neuen (Bausatz) gekauft, aufgebaut und möchte jetzt den alten rauswerfen.
Derzeit ist im Bad folgende Kombination:
- HM-CC-RT-DN gepeert mit Fensterkontakt
- HM-CC-RT-DN gepeert mit Wandthermostat
- alle drei gepaart mit der FHEM Zentrale
Gibt es eine Möglichkeit, den alten Thermostat durch den neuen zu ersetzen, ohne alles auf Werkszustand zu bringen und wieder neu anzulernen?
Danke + Gruß
Peter
nicht so einfach, da du alle peerings zurücksetzen und neu setzen musst. das hier sollte helfen:
https://forum.fhem.de/index.php/topic,83496.msg757233.html#msg757233 (https://forum.fhem.de/index.php/topic,83496.msg757233.html#msg757233)
aber: wenn du wirklich noch den "fehler" finden willst, solltest du zuerst die aktuelle konstellation untersuchen.
theoretisch könnten zb auch burst meldungen vom nachbarn die ursache sein.
Hallo Frank,
danke für den Link. Habe den Thermostat mal ersetzt (um den WAF zu retten) und werde die Analyse des alten offline verfolgen.
Gruß Peter
Hallo,
jetzt wird's ein bisschen off-topic. Ich habe den Fensterkontakt mit dem Heizungsthermostat gepeert.
In der Anleitung des Heizungsthermostates steht, dass bei offenem Fenster das Symbol D Fenster-auf-Funktion angezeigt wird (Anleitung v1.6, 11/2016). Ist aber bei mir nicht der Fall. Anbei ein List des Fensterkontakts:
Internals:
DEF 267F73
IODev PMCUL01
LASTInputDev PMCUL01
MSGCNT 2
NAME OG_Badfenster
NOTIFYDEV global
NR 255
NTFY_ORDER 50-OG_Badfenster
PMCUL01_MSGCNT 2
PMCUL01_RAWMSG A0C028441267F73000000010200::-56.5:PMCUL01
PMCUL01_RSSI -56.5
PMCUL01_TIME 2018-12-31 10:04:27
STATE closed
TYPE CUL_HM
lastMsg No:02 - t:41 s:267F73 d:000000 010200
peerList HM_Bad_HKT_WindowRec,
protLastRcv 2018-12-31 10:04:27
rssi_at_PMCUL01 cnt:2 min:-62.5 max:-56.5 avg:-59.5 lst:-56.5
READINGS:
2018-12-30 16:05:54 Activity alive
2018-12-27 13:31:32 D-firmware 2.4
2018-12-27 13:31:32 D-serialNr KEQ1096112
2018-12-30 15:56:03 R-HM_Bad_HKT_WindowRec-expectAES set_off
2018-12-30 15:56:03 R-HM_Bad_HKT_WindowRec-peerNeedsBurst set_on
2018-12-30 16:02:44 alive yes
2018-12-31 10:04:27 battery ok
2018-12-31 10:04:27 contact closed (to broadcast)
2018-12-30 16:05:54 peerList HM_Bad_HKT_WindowRec,
2018-12-30 16:02:44 powerOn 2018-12-30 16:02:44
2018-12-30 16:02:44 recentStateType info
2018-12-30 16:02:44 sabotageError off
2018-12-31 10:04:27 state closed
2018-12-31 10:04:27 trigger_cnt 2
helper:
HM_CMDNR 2
mId 0030
regLst ,0,1,4p
rxType 20
supp_Pair_Rep 0
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +267F73,00,00,00
nextSend 1546247067.51838
prefIO
rxt 2
vccu
p:
267F73
00
00
00
mRssi:
mNo 02
io:
PMCUL01:
-50.5
-50.5
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rssi:
at_PMCUL01:
avg -59.5
cnt 2
lst -56.5
max -56.5
min -62.5
shadowReg:
tmpl:
Attributes:
IODev PMCUL01
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_window_1w_open@red tilted:fts_window_1w_tilt@orange closed:fts_window_1w@green
expert 251_anything
firmware 2.4
model HM-SEC-RHS
peerIDs 00000000,6A1E3D03,
room 1_Bad,1_Obergeschoss
serialNr KEQ1096112
subType threeStateSensor
Ist das so, oder habe ich irgendwo noch einen Fehler drin?
Danke, Gruß und einen guten Rutsch.
Peter
Das peering ist nicht vollständig durchgeführt: "set_on" bei needs burst...
Kurz-mobile Grüße.
getConfig und knöpfen drücken
2018-12-30 15:56:03 R-HM_Bad_HKT_WindowRec-peerNeedsBurst set_on
im Moment steht da erst was du gerne hättest set_on
und ob das Teil gepairt ist? ist auch noch die Frage (closed (to broadcast))
Hallo zusammen,
danke für die Tipps. Muss leider eine Pause machen, da der Fensterkontakt dauern CMDs_pending liefert. Vermutlich brauchs da eine neue Batterie, obwohl die, die drin sind noch 1,5 V (Leerlauf haben). Ich werde berichten ...
Guten Rutsch allerseits.
Peter
Dein Fensterkontakt ist nicht gepairt (insbesondere wenn er an Broadcast sendet, außerdem fehlt das Reading im list). Solange wirst Du CMDs_pending bei jedem Kommunikationsversuch haben.
Mach ein "set OG_Badfenster clear msgEvents" und paire ihn nochmal neu (vccu oder wenn nicht vorhanden CUL auf "hmPairForSec 60" und einmal den Knopf am Fensterkontat kurz drücken).
Erneure dann am besten das Peering des Kontakts mit dem RT-DN, damit der FK einen Burst sendet (peerNeedsBurst => on)
Hallo zusammen,
vielen Dank für Eure Hinweise.
Ich habe jetzt gefühlte 100 mal angelernt und mit getconfig Knöpfchen gedrückt. Da kommt immer CMDs_pending. Mit einem zweiten (auch mit der Seriennummer KEQ1...) dasselbe. Ich probier's mal mit neuen Batterien, aber mir scheint, dass diese Serie irgendwie eine "Macke" hat. Ggf. tausche ich das Ding gegen einen Eigenbau-Sensor, dann ist Ruhe ...
Euch allen ein gutes Neues Jahr.
Gruß Peter
mache ein
clear msgEvents
stelle sniffen ein(siehe wiki sniffen) und logge mit
Versuche
a) pairForSec
Bei Versuch b) mache
- device config drücken (hält 30sec)
- hmPairSerial <seriennummer> abschicken
Die Logs posten, wenn es nicht klappt