Die Geschichte geht so:
Zuerst hatte ich als Basis Busware auf RPi-GPIO. Zeitlich folgend stellte ich alles auf VCCU um. Vor vielleicht zwei Wochen dann Ersatz für die Basis: HM-MOD-UART auf RPi-GPIO. Alles völlig problemlos. Auch drei Rauchmelder und knapp zwei Hände voll Öffnungsmelder.
Exakt zwei Öffnungsmelder HM-SEC-SC-2 machen seit längerem Ärger: Die sind miteinander gepeert. Ich weiß, es wurde mir schon gesagt: "Das geht doch gar nicht!". Doch, das geht, leider.
Gestern habe ich die halbe Nacht damit zugebracht: Beide lagen neben mir, einer links, einer rechts. Und dann habe ich beiden mühevoll das Peering abgewöhnt. Und HMinfo peerXref und configCheck - immer und immer wieder. Und dann einen der beiden mit der VCCU [¹] verheiratet, also gepeert. Und dann noch mehrmals geprüft, alles war schick.
Heute schaue ich naiverweise da mal nach - und falle fast um: Die beiden Melder haben wieder geheiratet, ganz alleine! Die sind gegenseitig gepeert (dafür ist das Peering mit VCCU weg). Das muss Liebe sein ...
Ich bin mit meinem Latein am Ende - was mache ich denn jetzt nun? Bitte helft mir!
(Welche lists soll ich liefern? Was noch liefern?)
[¹] Alle Melder sind gar nicht mit irgendwas gepeert, die melden einfach nur an VCCU. Ich habe noch nicht verstanden ob (und warum) ich jeden einzelnen vielleicht mit VCCU peeren muss.
Meinst Du peeren oder pairen?
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
https://wiki.fhem.de/wiki/Homematic_Peering_Beispiele
Mit der VCCU muss er gepaired werden.
Dann gibt es die Möglichkeit Aktoren und Sensoren miteinander zu peeren. Aber das geht nicht von alleine ;)
Poste mal ein "list" von deinen Devices.
Zitat von: amenomade am 11 Februar 2019, 00:33:36
Meinst Du peeren oder pairen?
Otto (?) hatte mir das schon mal sehr deutlich gesagt. Ja, bekannt.
Zitat von: amenomade am 11 Februar 2019, 00:33:36
Mit der VCCU muss er gepaired werden.
Alle Rauchmelder und alle Kontaktmelder sind mit VCCU gepeart.
Zitat von: amenomade am 11 Februar 2019, 00:33:36
Dann gibt es die Möglichkeit Aktoren und Sensoren miteinander zu peeren. Aber das geht nicht von alleine ;)
Wie gesagt: Ich hatte gestern die Terrassentuer mit VCCU gepeert - ohne zu wissen, ob man das machen muss. Das ging. Und wurde angezeigt.
Zitat von: amenomade am 11 Februar 2019, 00:33:36
Poste mal ein "list" von deinen Devices.
Unten die Terrassentuer - die beiden Sensoren haben hat übrigens JETZT auch:
configCheck done:
missing register list
Haustuer: RegL_04.Terrassentuer_chn-01
Terrassentuer: RegL_04.Haustuer_chn-01
Das ist völlig neu.
Internals:
CFGFN ./FHEM/z-include-fenster.cfg
DEF 3301C1
FUUID 5c47b07e-f33f-769b-2ca2-9af17ff5dcf2f9ed
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 2
NAME Haustuer
NOTIFYDEV global
NR 99
NTFY_ORDER 50-Haustuer
STATE closed
TYPE CUL_HM
lastMsg No:25 - t:41 s:3301C1 d:FF1312 011B00
myHmUART_MSGCNT 2
myHmUART_RAWMSG 0501004A25A6413301C1FF1312011B00
myHmUART_RSSI -74
myHmUART_TIME 2019-02-10 23:27:16
peerList Terrassentuer,
protLastRcv 2019-02-10 23:27:16
protRcv 2 last_at:2019-02-10 23:27:16
protSnd 2 last_at:2019-02-10 23:27:16
protState CMDs_done
rssi_at_myHmUART cnt:2 min:-76 max:-74 avg:-75 lst:-74
READINGS:
2018-11-26 20:20:29 3SSunknownMsg 00053301C10103
2019-02-10 23:04:42 Activity alive
2019-02-09 23:01:21 CommandAccepted no
2019-02-09 23:09:20 D-firmware 2.4
2019-02-09 23:09:20 D-serialNr LEQ0893196
2019-02-09 23:09:22 PairedTo 0xFF1312
2019-02-09 22:52:24 R-Terrassentuer_chn-01-expectAES off
2019-02-09 22:52:24 R-Terrassentuer_chn-01-peerNeedsBurst off
2018-07-28 02:36:25 R-cyclicInfoMsg off
2018-07-28 02:36:26 R-eventDlyTime 0 s
2019-02-09 21:59:17 R-pairCentral 0xFF1312
2018-07-28 02:36:25 R-sabotageMsg on
2018-07-28 02:36:26 R-sign off
2019-02-09 23:09:22 RegL_00. 00:00 02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06
2019-02-09 23:09:22 RegL_01. 00:00 08:00 20:60 21:00 22:64 30:06
2019-02-09 23:17:27 alive yes
2019-02-10 23:27:16 battery ok
2019-02-10 23:27:16 contact closed (to VCCU)
2019-02-10 23:04:42 peerList Terrassentuer,
2019-02-09 21:59:11 powerOn 2019-02-09 21:59:11
2019-02-09 23:17:27 recentStateType info
2019-02-09 23:17:27 sabotageError off
2019-02-10 23:27:16 state closed
2018-07-29 00:16:47 trigDst_FF1312 noConfig
2019-02-09 22:34:57 trigLast Terrassentuer:open
2019-02-09 22:34:57 trig_Terrassentuer Open_8
2019-02-10 23:27:16 trigger_cnt 27
helper:
HM_CMDNR 37
mId 00B1
regLst ,0,1,4p
rxType 4
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3301C1,00,00,00
nextSend 1549837636.77106
rxt 0
vccu VCCU
p:
3301C1
00
00
00
prefIO:
myHmUART
mRssi:
mNo 25
io:
myHmUART:
-72
-72
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1549837636.4761
ack:
HASH(0x3ef6df8)
258002FF13123301C10101C800
rssi:
at_myHmUART:
avg -75
cnt 2
lst -74
max -74
min -76
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev myHmUART
IOgrp VCCU:myHmUART
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
battery_change 2018-12-03
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 2.4
fp_Hauptseite 376,651,1,structure_Fenster
model HM-SEC-SC-2
peerIDs 00000000,3301D301,
room Unsorted
serialNr LEQ0893196
subType threeStateSensor
userattr Fenster_Status Fenster_Status_map structexclude
Mein Tipp wäre für dich
das attr peerIDs 00000000,3301D301,
das rote löschen!
dann alle readings loschen , die vom 9.2 sind doch alt
kann man mit set ... clear readings im device
und dann ein getConfig und knöpfchen drücken.
und dann ein save bitte
poste ein neues list
Zitat von: fhem-hm-knecht am 11 Februar 2019, 01:08:38
das attr peerIDs 00000000,3301D301,
das rote löschen!
dann alle readings loschen , die vom 9.2 sind doch alt
kann man mit set ... clear readings im device
und dann ein getConfig und knöpfchen drücken.
Das Rote - das sollte die andere Türe sein. An der Löschung krampfte ich gestern stundenlang rum - und immerzu Knöpfchen.
Ich hatte auf der Seite der Terrassentuer: "set peerchan 0 Haustuer single unset" - ist das denn richtig? Oder geht das un-peeren noch anders?
naja
set peerchan 0 Haustuer single unset
das kann eh nicht funktionieren, nach set fehlt das device!
an deiner stelle würde ich die zwei device in fhem löschen , save in fhem drücken, einen Werksreset mit zweimal 5 sek Knöfchen drücken machen an den zwei Fenstersensoren,
und dann frisch pairen mit
set VCCU hmPairForSec 600, fünf minuten mussen dir reichen um Knöfchen anzutippen am Fensterkontakt
Zitat von: fhem-hm-knecht am 11 Februar 2019, 01:26:36
naja
set peerchan 0 Haustuer single unset
das kann eh nicht funktionieren, nach set fehlt das device!
Ja, klar. - Ich bezog mich auf den html-Bildschirm von FHEM (da die Seite der Terrassentuer), da kann man ja auch set machen.
Zitat von: fhem-hm-knecht am 11 Februar 2019, 01:26:36
an deiner stelle würde ich die zwei device in fhem löschen,
Das wird das Beste sein. Das geht einfach über "delete Terrassentuer"? - Ich lese immerzu, dass man da bei HM noch zig andere Dinge bedenken und machen müsse?
Zitat von: fhem-hm-knecht am 11 Februar 2019, 01:26:36
save in fhem drücken,
Ok, das beantwortet den Punkt, der mir vorhin unklar blieb: Wo/wie "save" zu machen sei.
Zitat von: fhem-hm-knecht am 11 Februar 2019, 01:26:36
einen Werksreset mit zweimal 5 sek Knöfchen drücken machen an den zwei Fenstersensoren,
5sec, 1sec Pause, 5sec. <- So?
Zitat von: fhem-hm-knecht am 11 Februar 2019, 01:26:36
und dann frisch pairen mit
set VCCU hmPairForSec 600, fünf minuten mussen dir reichen um Knöfchen anzutippen am Fensterkontakt
Den Teil kriege ich hin. Oft geübt.
P.S: Meine vielen Fragen sind auch wegen des/der künftigen Thermostate, ich muss das lernen.
Moin
Und gib uns doch mal ein list von beiden devices!
Gruss Christoph
Ich habe noch nichts gemacht, da ich noch auf Antwort von @fhem-hm-knecht hoffe.
Das eine Listing ist in #2. Die andere Device sah zu gleichem Zeitpunkt so aus:
define Terrassentuer CUL_HM 3301D3
setuuid Terrassentuer 5c47b07e-f33f-769b-3a11-9218644417b26829
attr Terrassentuer userattr Fenster_Status Fenster_Status_map structexclude
attr Terrassentuer Fenster_Status structure_Fenster
attr Terrassentuer IODev myHmUART
attr Terrassentuer IOgrp VCCU:myHmUART
attr Terrassentuer actCycle 028:00
attr Terrassentuer actStatus alive
attr Terrassentuer autoReadReg 4_reqStatus
attr Terrassentuer battery_change 2018-04-22
attr Terrassentuer devStateIcon open:fts_door_open@red closed:fts_door@green
attr Terrassentuer expert 2_raw
attr Terrassentuer firmware 2.4
attr Terrassentuer fp_Hauptseite 376,651,1,structure_Fenster
attr Terrassentuer model HM-SEC-SC-2
attr Terrassentuer peerIDs 00000000,3301C101,
attr Terrassentuer room Unsorted
attr Terrassentuer serialNr LEQ0893214
attr Terrassentuer subType threeStateSensor
Du darfst nicht auf mich warten :)
Wie man Werksreset mach steht in der Bedienungsanleitung, die gilt nach wie vor.
da du keinen AES key, bzw sign on hast kannst du die so reseten wie geschrieben.
Falls sign on , müsstest über Zentrale ablernen , Unpair / da geht das mit zweimal 5 sek Köpfen drücken nicht.
set <device> unpair , und wieder knöpfen drücken. Erfolg sieht man dann , dass er orange blinkt bei Auslösen des Kontakts.
-->Probably associated with , da siehst du doch mit was du alles den Kontakt verknüft hast in Fhem. (notieren)
Wie gesagt
nachdem du Delete this device (xxxxxxx) gemacht hast bei beiden, save , shutdown restart ,
set VCCU hmPairForSec 600
knöpfchen drücken 1. device
kontrolle
set VCCU hmPairForSec 600
knöpfchen drücken 2. device
kontrolle
save
Zitat von: fhem-hm-knecht am 11 Februar 2019, 21:31:50
Du darfst nicht auf mich warten :)
Kennst Du Silbermond? "Gib mir 'n kleines bisschen Sicherheit ..." ;)
Ich habe alles abgearbeitet.
Internals:
DEF 3301C1
FUUID 5c61e0f3-f33f-769b-cdc5-5e480d015a8b96a5
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 6
NAME Haustuer
NOTIFYDEV global
NR 976
NTFY_ORDER 50-Haustuer
STATE closed
TYPE CUL_HM
lastMsg No:40 - t:41 s:3301C1 d:FF1312 013400
myHmUART_MSGCNT 6
myHmUART_RAWMSG 0501004740A6413301C1FF1312013400
myHmUART_RSSI -71
myHmUART_TIME 2019-02-11 22:48:04
protLastRcv 2019-02-11 22:48:04
protRcv 6 last_at:2019-02-11 22:48:04
protSnd 6 last_at:2019-02-11 22:48:04
protState CMDs_done
rssi_at_myHmUART cnt:6 min:-71 max:-63 avg:-67.83 lst:-71
READINGS:
2019-02-11 22:21:08 Activity alive
2019-02-11 21:54:12 CommandAccepted yes
2019-02-11 21:54:11 D-firmware 2.4
2019-02-11 21:54:11 D-serialNr LEQ0893196
2019-02-11 21:54:11 R-pairCentral set_0xFF1312
2019-02-11 22:23:44 alive yes
2019-02-11 22:48:04 battery ok
2019-02-11 22:48:04 contact closed (to VCCU)
2019-02-11 22:23:44 recentStateType info
2019-02-11 22:23:44 sabotageError off
2019-02-11 22:48:04 state closed
2019-02-11 22:48:04 trigger_cnt 52
helper:
HM_CMDNR 64
mId 00B1
regLst ,0,1,4p
rxType 4
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3301C1,00,00,00
nextSend 1549921685.17406
rxt 0
vccu VCCU
p:
3301C1
00
00
00
prefIO:
myHmUART
mRssi:
mNo 40
io:
myHmUART:
-69
-69
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1549921684.87909
ack:
HASH(0x4b2f4a8)
408002FF13123301C10101C800
rssi:
at_myHmUART:
avg -67.8333333333333
cnt 6
lst -71
max -63
min -71
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev myHmUART
IOgrp VCCU:myHmUART
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
battery_change 2018-12-03
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 2.4
model HM-SEC-SC-2
room Unsorted
serialNr LEQ0893196
subType threeStateSensor
userattr Fenster_Status Fenster_Status_map structexclude
Internals:
DEF 3301D3
FUUID 5c61e312-f33f-769b-982e-446f8b676d2630c2
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 6
NAME Terrassentuer
NOTIFYDEV global
NR 977
NTFY_ORDER 50-Terrassentuer
STATE closed
TYPE CUL_HM
lastMsg No:35 - t:41 s:3301D3 d:FF1312 012D00
myHmUART_MSGCNT 6
myHmUART_RAWMSG 0501003E35A6413301D3FF1312012D00
myHmUART_RSSI -62
myHmUART_TIME 2019-02-11 22:47:30
protLastRcv 2019-02-11 22:47:30
protRcv 6 last_at:2019-02-11 22:47:30
protSnd 6 last_at:2019-02-11 22:47:30
protState CMDs_done
rssi_at_myHmUART cnt:6 min:-64 max:-59 avg:-62.16 lst:-62
READINGS:
2019-02-11 22:21:09 Activity alive
2019-02-11 22:03:15 CommandAccepted yes
2019-02-11 22:03:14 D-firmware 2.4
2019-02-11 22:03:14 D-serialNr LEQ0893214
2019-02-11 22:03:14 R-pairCentral set_0xFF1312
2019-02-11 22:24:10 alive yes
2019-02-11 22:47:30 battery ok
2019-02-11 22:47:30 contact closed (to VCCU)
2019-02-11 22:24:10 recentStateType info
2019-02-11 22:24:10 sabotageError off
2019-02-11 22:47:30 state closed
2019-02-11 22:47:30 trigger_cnt 45
helper:
HM_CMDNR 53
mId 00B1
regLst ,0,1,4p
rxType 4
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3301D3,00,00,00
nextSend 1549921651.01997
rxt 0
vccu VCCU
p:
3301D3
00
00
00
prefIO:
myHmUART
mRssi:
mNo 35
io:
myHmUART:
-58
-58
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1549921650.72436
ack:
HASH(0x4737de0)
358002FF13123301D30101C800
rssi:
at_myHmUART:
avg -62.1666666666667
cnt 6
lst -62
max -59
min -64
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev myHmUART
IOgrp VCCU:myHmUART
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
battery_change 2018-04-22
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 2.4
model HM-SEC-SC-2
room Unsorted
serialNr LEQ0893214
subType threeStateSensor
userattr Fenster_Status Fenster_Status_map structexclude
* Ist das so jetzt richtig?
* Muss ich die jetzt mit VCCU peeren? Falls ja: Warum?
du hast gepaired gut
ZitatlastMsg No:40 - t:41 s:3301C1 d:FF1312 013400
ZitatlastMsg No:35 - t:41 s:3301D3 d:FF1312 012D00
und wie du siehst schickt er, beide schon direkt zu deiner vccu FF1312
also nein nicht nochmal extra mit einem Kanal der vccu peeren.
die Fenster /Drehgiff sensoren sind da Sonderlocken von HM, im Gegensatz zu Remote /Fernbedienungen, wo du jeden Kanal/Taste peeren mußt um grüne Led zu bekommen.
noch bei beiden getConfig damit das set_0xFF1312 verschwindet, set heißt ja hätte gern, sensor hat auch schon, du hast es nur noch nicht zurückgelesen vom Sensor,
ist halt so bei Batterie Device , Knöpfchen drücken
Zitat von: fhem-hm-knecht am 11 Februar 2019, 23:58:14
noch bei beiden getConfig ... Knöpfchen drücken
Beide zeigten folgendes Verhalten: längere Zeit oranges blinken, dann rot. Ok, nochmals drücken. Irgendwann nach längerer Zeit fanden beide kurz nacheinander, dass jetzt "grün" sei.
Leider mit einem Seiteneffekt: ALLE anderen Kontaktmelder haben nun "missing register list - RegL_00.,RegL_01.". Und ALLE anderen stehen nun unter "PairedTo missing/unknown".
Beispiel-List:
Internals:
CFGFN ./FHEM/z-include-fenster.cfg
DEF 32FB4C
FUUID 5c47b07e-f33f-769b-79e4-5668390fa13a421c
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 2
NAME Kueche
NOTIFYDEV global
NR 108
NTFY_ORDER 50-Kueche
STATE closed
TYPE CUL_HM
lastMsg No:12 - t:41 s:32FB4C d:FF1312 011100
myHmUART_MSGCNT 2
myHmUART_RAWMSG 0501003612A64132FB4CFF1312011100
myHmUART_RSSI -54
myHmUART_TIME 2019-02-12 00:14:04
protLastRcv 2019-02-12 00:14:04
protRcv 2 last_at:2019-02-12 00:14:04
protSnd 2 last_at:2019-02-12 00:14:04
protState CMDs_done
rssi_at_myHmUART cnt:2 min:-54 max:-52 avg:-53 lst:-54
READINGS:
2019-02-12 00:14:04 battery ok
2019-02-12 00:14:04 contact closed (to VCCU)
2019-02-12 00:14:04 state closed
2019-02-12 00:14:04 trigger_cnt 17
helper:
HM_CMDNR 18
mId 00B1
regLst ,0,1,4p
rxType 4
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +32FB4C,00,00,00
nextSend 1549926844.89701
prefIO
rxt 0
vccu VCCU
p:
32FB4C
00
00
00
mRssi:
mNo 12
io:
myHmUART:
-48
-48
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1549926844.60141
ack:
HASH(0x2a92748)
128002FF131232FB4C0101C800
rssi:
at_myHmUART:
avg -53
cnt 2
lst -54
max -52
min -54
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev myHmUART
IOgrp VCCU
actCycle 028:00
actStatus unknown
autoReadReg 4_reqStatus
battery_change 2018-03-31
devStateIcon open:fts_window_1w_tilt@red closed:fts_window_1w@green
expert 2_raw
firmware 2.4
fp_Hauptseite 376,651,1,structure_Fenster
model HM-SEC-SC-2
peerIDs 00000000,
room Unsorted
serialNr LEQ0891066
subType threeStateSensor
userattr Fenster_Status Fenster_Status_map structexclude
Die readings fehlen ja auch!
wurde dein fhem.save nicht geschrieben eingelesen?
nach shutdown restart?
du hast doch noch andere Probleme. das hat mal weniger mit HM zu tun.
deswegen auch
Zitatmissing register list - RegL_00.,RegL_01.". Und ALLE anderen stehen nun unter "PairedTo missing/unknown".
mangels Readings
Nein, das stimmt nicht.
Alles hat gestimmt, alles war in Ordnung, auch restart.
Dann habe ich die letzte von Dir gestellte Aufgabe erledigt - DIREKT danach waren die Register weg usw.
Moin
Kueche ist auf jeden Fall nicht gepairt! Und bitte zeige auch noch mal ein list der beiden Anderen!
Gruss Christoph
Zitat
Autor: pc1246
« am: Heute um 06:40:53 »
Zitat einfügen
Moin
Kueche ist auf jeden Fall nicht gepairt!
Die Küche ist gepaired lt lastMsg
ZitatlastMsg No:12 - t:41 s:32FB4C d:FF1312 011100
Ich merkte, dass die angeblich nicht gepairten Melder wieder als gepairt angegeben werden, wenn ich das zugehörige Fenster einmal öffne. Danach blieben die fehlenden Register der einzelnen Melder: getConfig und Knöpfchen drücken. Manche zierten sich ein wenig. Die Übung macht stramme Waden und schlanke Figur.
Aktueller Stand:
configCheck done:
peer list incomplete. Use getConfig to read it.
incomplete: Haustuer:
incomplete: Terrassentuer:
Das habe ich nicht gemacht. - Wo kommt das nun wieder her? Ich befürchte, dass die beiden schon wieder heiraten wollen.
Die beiden zugehörigen Listings:
Internals:
DEF 3301C1
FUUID 5c61e0f3-f33f-769b-cdc5-5e480d015a8b96a5
IODev myHmUART
NAME Haustuer
NOTIFYDEV global
NR 976
NTFY_ORDER 50-Haustuer
STATE closed
TYPE CUL_HM
READINGS:
2019-02-12 19:05:05 Activity alive
2019-02-11 21:54:12 CommandAccepted yes
2019-02-12 00:09:53 D-firmware 2.4
2019-02-12 00:09:53 D-serialNr LEQ0893196
2019-02-12 00:09:53 PairedTo 0xFF1312
2019-02-12 00:09:53 R-cyclicInfoMsg off
2019-02-12 00:09:53 R-eventDlyTime 0 s
2019-02-12 00:09:53 R-pairCentral 0xFF1312
2019-02-12 00:09:53 R-sabotageMsg on
2019-02-12 00:09:53 R-sign off
2019-02-12 00:09:53 RegL_00. 00:00 02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06
2019-02-12 00:09:53 RegL_01. 00:00 08:00 20:60 21:00 22:64 30:06
2019-02-12 00:12:17 alive yes
2019-02-12 18:28:16 battery ok
2019-02-12 18:28:16 contact closed (to VCCU)
2019-02-12 00:12:17 recentStateType info
2019-02-12 00:12:17 sabotageError off
2019-02-12 18:28:16 state closed
2019-02-12 18:28:16 trigger_cnt 101
helper:
HM_CMDNR 123
mId 00B1
regLst ,0,1,4p
rxType 4
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3301C1,00,00,00
rxt 0
vccu VCCU
p:
3301C1
00
00
00
prefIO:
myHmUART
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev myHmUART
IOgrp VCCU:myHmUART
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
battery_change 2018-12-03
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 2.4
model HM-SEC-SC-2
room Unsorted
serialNr LEQ0893196
subType threeStateSensor
userattr Fenster_Status Fenster_Status_map structexclude
Internals:
DEF 3301D3
FUUID 5c61e312-f33f-769b-982e-446f8b676d2630c2
IODev myHmUART
NAME Terrassentuer
NOTIFYDEV global
NR 977
NTFY_ORDER 50-Terrassentuer
STATE closed
TYPE CUL_HM
READINGS:
2019-02-12 19:05:06 Activity alive
2019-02-11 22:03:15 CommandAccepted yes
2019-02-12 00:10:02 D-firmware 2.4
2019-02-12 00:10:02 D-serialNr LEQ0893214
2019-02-12 00:10:03 PairedTo 0xFF1312
2019-02-12 00:10:03 R-cyclicInfoMsg off
2019-02-12 00:10:03 R-eventDlyTime 0 s
2019-02-12 00:10:03 R-pairCentral 0xFF1312
2019-02-12 00:10:03 R-sabotageMsg on
2019-02-12 00:10:03 R-sign off
2019-02-12 00:10:03 RegL_00. 00:00 02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06
2019-02-12 00:10:03 RegL_01. 00:00 08:00 20:60 21:00 22:64 30:06
2019-02-12 00:12:41 alive yes
2019-02-12 00:12:44 battery ok
2019-02-12 00:12:44 contact closed (to VCCU)
2019-02-12 00:12:41 recentStateType info
2019-02-12 00:12:41 sabotageError off
2019-02-12 00:12:44 state closed
2019-02-12 00:12:44 trigger_cnt 52
helper:
HM_CMDNR 79
mId 00B1
regLst ,0,1,4p
rxType 4
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3301D3,00,00,00
rxt 0
vccu VCCU
p:
3301D3
00
00
00
prefIO:
myHmUART
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev myHmUART
IOgrp VCCU:myHmUART
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
battery_change 2018-04-22
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 2.4
model HM-SEC-SC-2
room Unsorted
serialNr LEQ0893214
subType threeStateSensor
userattr Fenster_Status Fenster_Status_map structexclude
Moin curt
Das Peering wird im device hinterlegt, da es ja die direkte Kommunikation zwischen Devices beschreibt. Ein getConfig bewirkt also nur, dass von den Devices alle noch nicht bekannten Infos abgeholt werden. Wenn dann also wieder das Peering auftaucht, dann hast Du das da irgendwann reingeschrieben, und musst es dementsprechend loeschen!
BTW: Es ist sehr schwierig Dir zu folgen, da man nicht immer genau weiss, was Du machst/gemacht hast, und Deine Saetze manchmal auch nicht vollstaendig sind!
Gruss Christoph
Ich beobachte hier eine seltsame Form der Vergesslichkeit.
Wenn ein getConfig auf ein Gerät die Register von anderen unbeteiligten vergessen macht, liegt da woanders der Hase im Pfeffer.
Dann fehlen sämtliche Infos, vom Pairing-Status bis zu allen Registerwerten. Erstere werden natürlich von allein restauriert, sobald sich ein Kontakt wieder bei der Zentrale meldet, eben nach Betätigung.
Speicherkarte intakt, fhem.save (das Statefile) wird richtig geschrieben?
Eher sehr unwahrscheinlich, aber dennoch: Wurden mal hm-templates angewendet, deren Vorgaben FHEM vielleicht ständig wiederherzustellen versucht?
es wurde wahrscheinlich mindestens ein fhem restart gemacht, da protokoll infos und io infos in den internals fehlen.
wird denn beim restart immer grundsätzlich automatisch das statefile gesichert?
Zitat von: frank am 13 Februar 2019, 12:15:22
wird denn beim restart immer grundsätzlich automatisch das statefile gesichert?
Normalerweise schon, ich habe mich noch nie darum gekümmert und der Zeitstempel ist immer aktualisiert.
Zitat von: curt am 11 Februar 2019, 01:32:55
Ok, das beantwortet den Punkt, der mir vorhin unklar blieb: Wo/wie "save" zu machen sei.
Ich bin mir nicht sicher, ob auch wirklich immer ein "save" mit im Spiel war. Deswegen schrieb ich ja auch, dass man nicht so richtig verfolgen kann, was gemacht wurde.
Gruss Christoph
warum fehlt bei dem Device
Haustuer und Terrassentuer
das Attr < >peerIDs 00000000,
bei der Kueche ist es vorhanden, im Übrigen , bei meinen eigenen Device ist es auch vorhanden.
bei einem shutdown, bzw shutdown restart -->wird immer ein statefile bzw. die Datei fhem.save geschrieben, es sei denn du hättest es bei global entfernt.
So isses. Ein getconfig liest das device aus. Es schreibt und setzt nichts. Danach sollte bei entities welche gepeert werden können zumindest ein 00000000 auftauchen. Das zeigt dass das Lesen abgeschlossen ist.
Sollte also nach einem getconfig ein cmds_done erscheinen aber kein peers 00000000 dann ist etwas schief gelaufen.
Peers sind immer an einen Kanal gebunden, nicht an das device ( siehe Unterscheidung in den Grundlagen).
Device welche gepairt sind peeren nur noch über die Zentrale. Also nur über deine Kommandos. Automatisch geht nix.
Und wenn du nicht lesen läst (getconfig) wirst du den Zustand nicht erfahren
Zitat von: fhem-hm-knecht am 13 Februar 2019, 19:29:04
warum fehlt bei dem Device
Haustuer und Terrassentuer
das Attr < >peerIDs 00000000,
Nach Erstellung war das vorhanden, siehe #13. Dann waren die Reg aller anderen weg. Als ich die mühselig wieder mit getConfig geholt hatte, waren die beiden peerIDs weg.
Zitat von: fhem-hm-knecht am 13 Februar 2019, 19:29:04
bei einem shutdown, bzw shutdown restart -->wird immer ein statefile bzw. die Datei fhem.save geschrieben, es sei denn du hättest es bei global entfernt.
Dort steht "attr global statefile ./log/fhem.save".
* # $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $
* ls -l 10_CUL_HM.pm
-rw-r--r-- 1 fhem dialout 590655 Jan 23 00:19 10_CUL_HM.pm
Ich habe mich exakt an das gehalten, was Du mir vorgegeben hast. Natürlich kann ich nicht völlig ausschließen, dass da ein Linux-Reboot dazwischen war, möchte das aber verneinen.
Frage: Warum wird sowas nicht sofort gespeichert?
Frage: Bei den beiden Türen nun getConfig? (Und die Hoffnung, das die nicht wieder untereinander "heiraten" ...)
ZitatNach Erstellung war das vorhanden, siehe #13. Dann waren die Reg aller anderen weg. Als ich die mühselig wieder mit getConfig geholt hatte, waren die beiden peerIDs weg.
Und eben das kommt normalerweise nie vor. Was vorkommt ist, dass ein unvollständiger Registersatz zu einem Gerät nach einem weiteren Leseversuch noch unvollständiger ist, weil die Register immer "am Stück gelesen" und alte Einstellungen verworfen werden. Nur mit einem fehlerfreien Leseversuch sind die Daten vollständig zu bekommen. Aber das ein fehlgeschlagener oder erfolgreicher Leseversuch die Daten anderer Geräte in Mitleidenschaft zieht, kommt normalerweise nie vor.
Hast Du zwischendurch mal ein "clear msgEvents" am IO bzw. der VCCU gemacht? Wenn alte misslungene Konfigurations- oder Leseversuche den Queue verstopfen, ist das in aller Regel der Fälle kontraproduktiv.
ZitatFrage: Warum wird sowas nicht sofort gespeichert?
Änderungen an der FHEM-Konfiguration werden (default) auch nicht sofort gespeichert.
Registerdatensätze können übrigens auch separat gespeichert werden...
Zitat(Und die Hoffnung, das die nicht wieder untereinander "heiraten" ...)
Ich sag's letztmalig: Fehlen FHEM die Registerdaten, dann kann es auch keine Kanäle als gepeert anzeigen. Tauchen nach einem Auslesen die Geräte als gepeert auf, ist der naheliegende Schluss daher nicht, dass sie sie wieder "geheiratet" haben, sondern dass sie nie "geschieden" wurden.
Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
Aber das ein fehlgeschlagener oder erfolgreicher Leseversuch die Daten anderer Geräte in Mitleidenschaft zieht, kommt normalerweise nie vor.
Bei mir kann man das ja besichtigen.
Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
Hast Du zwischendurch mal ein "clear msgEvents" am IO bzw. der VCCU gemacht? Wenn alte misslungene Konfigurations- oder Leseversuche den Queue verstopfen, ist das in aller Regel der Fälle kontraproduktiv.
Nein, habe ich nicht. Ich habe den Satz nicht richtig verstanden: Soll ich das machen? Wann genau?
Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
ZitatFrage: Warum wird sowas nicht sofort gespeichert?
Änderungen an der FHEM-Konfiguration werden (default) auch nicht sofort gespeichert.
Bei der FHEM-Konfiguration leuchtet mir das ein. Aber aus welchem Grund wird das bei HM nicht sofort gespeichert?
Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
Registerdatensätze können übrigens auch separat gespeichert werden...
Den Satz habe ich nicht verstanden.
Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
Tauchen nach einem Auslesen die Geräte als gepeert auf, ist der naheliegende Schluss daher nicht, dass sie sie wieder "geheiratet" haben, sondern dass sie nie "geschieden" wurden.
Bei beiden gab es ein Hardware-Reset. Aber mich würde nichts mehr wundern.
Zitat von: curt am 14 Februar 2019, 13:06:24
Bei beiden gab es ein Hardware-Reset. Aber mich würde nichts mehr wundern.
Moin
Wie sieht denn ein HW-reset bei Dir aus?
Gruss Christoph
Zitat von: pc1246 am 14 Februar 2019, 13:39:02
Wie sieht denn ein HW-reset bei Dir aus?
So, wie mir das in diesem Thread erklärt wurde: "delete Devicename", save. Dann 2x5sec Knöpfchen. Dann
set VCCU hmPairForSec 600, dann in der Zeit Knöpfchen kurz drücken. Dann getConfig, dann Knöpfchen kurz drücken. save.
Nachtrag:
Und daran anschließend waren die Register (RegL_00.,RegL_01.) wirklich aller anderen Kontaktmelder weg. Und das kann man jetzt wirklich nicht mehr mit "curt ist zu doof um was zu speichern" begründen.
Diese Register von weiteren sieben Meldern waren monatelang da.
@curt
Ich denke, wir glauben Dir alle, was Du schreibst. Was mich, persoenlich, etwas wundert, dass Du alles immer noch einmal nachfragst. Speziell zu deinem Reset, 2 mal 5Sec Knoepfchen druecken, kann jetzt vieles bedeuten! Das haettest Du als Aufforderung auch hinterfragt! Denn das Geblinke muss schon auch stimmen!
Beim getConfig gehe ich uebrigens mit den Anderen nicht konform, da ich eine andere Vorgehensweise nutze, die mich bisher immer sicher zum Ziel gebracht hat. Ich setze das getConfig ab, druecke das Knoepfchen, warte das das Blinken aufhoert, und falls es noch cmdsPending gibt, dann druecke ich das Knoepfchen erneut. Beim Thermostaten z.B. muss man das bis zu 3mal machen.
Was ich mir auch angewoehnt habe, ist nicht nur den save-Button auf der Oberflaeche zu druecken, sondern ab und an auch mal ein save in die Kommandozeile einzugeben.
Jetzt aber zurueck zum eigentlichen Thema, wie ist denn jetzt der Stand bei Dir?
Gruss Christoph
Zitat von: pc1246 am 15 Februar 2019, 07:47:06
Was ich mir auch angewoehnt habe, ist nicht nur den save-Button auf der Oberflaeche zu druecken, sondern ab und an auch mal ein save in die Kommandozeile einzugeben.
Welchen Unterschied macht das? Für mich passiert mit "Save config" aus der Navi-Leiste links und "save" in der Eingabezeile irgendwie das Gleiche.
Was sich gelegentlich mal empfiehlt, ist ein "set <hminfo> saveConfig".
Ich bin trotzdem auch völlig ratlos, warum gelesene Register wieder so schnell verschwinden.
curt, hast Du Zugriff auf die Dateien (Samba oder FTP) und kannst Du mal schauen, ob wirklich ein fhem.save geschrieben wird (bei mir ist das im im Log-Verzeichnis).
sollte so ähnlich aussehen (alle Werte aller Geräte sind alphabetisch sortiert)
#Fri Feb 15 19:22:37 2019
setstate 1BattAkt2 off
setstate 1BattAkt2 2017-11-30 22:02:25 .R-HM_PB4Dis1_Btn_20-lgCtDlyOff geLo
setstate 1BattAkt2 2017-11-30 22:02:25 .R-HM_PB4Dis1_Btn_20-lgCtDlyOn geLo
setstate 1BattAkt2 2017-11-30 22:02:25 .R-HM_PB4Dis1_Btn_20-lgCtOff geLo
...
Zitat von: pc1246 am 15 Februar 2019, 07:47:06
Was mich, persoenlich, etwas wundert, dass Du alles immer noch einmal nachfragst.
Solche Probleme habe ich nicht zum ersten Mal. Von daher halte ich es für klug, das gemeinsam mit Fachleuten durchzugehen.
Übrigens hatte ich etwas vergessen: Einige Melder sind aus zweiter Hand, waren in magenta Telekom-Verpackung. Gleicher Typ, gleiches Aussehen.
Zitat von: pc1246 am 15 Februar 2019, 07:47:06
Jetzt aber zurueck zum eigentlichen Thema, wie ist denn jetzt der Stand bei Dir?
Noch kein getConfig bei den beidem ausstehenden. Ich wollte zunächst Meinungen abwarten. Und heute abend habe ich keine Lust, mich ggf. schwarz zu ärgern.
Zitat von: Pfriemler am 15 Februar 2019, 20:13:26
curt, hast Du Zugriff auf die Dateien (Samba oder FTP) und kannst Du mal schauen, ob wirklich ein fhem.save geschrieben wird (bei mir ist das im im Log-Verzeichnis).
Zugang via ssh. - Ich drücke auf "Save config" im Browser, dann wird fhem.save in /opt/fhem/log mit korrektem Zeitstempel geschrieben. Einträge wirken auch aktuell.
Was bewirkt "set <hminfo> saveConfig" genau?
set hm saveConfig speichert die HM-Device configuration - also alle registersettings (und auch die templates und template-zuweisungen). Per default wird es im File regSave.cfg geschrieben.
save speichert die FHEM-configuration - also defines und attribute. Ein HM saveConfig wird ebenfalls getriggert, ist also inclusive.
für devices wie ein SC welche von FHEM nur mit dem Config-button zur Kommuniation angeregt werden können ist es unabdingbar, das zu tun. Am saubersten ist es
set <sc> clear msgEvents
set <sc> getConfig
<config button drücken - KEIN RESET>
<prüfen, dass cmd_done zu sehen ist>nun steht auch 00000000 in den peerIds. Das ist bei allen so.
ein "save" würde sich jetzt anbieten, damit FHEM diese information sichert.
Zitat
Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
Aber das ein fehlgeschlagener oder erfolgreicher Leseversuch die Daten anderer Geräte in Mitleidenschaft zieht, kommt normalerweise nie vor.
Bei mir kann man das ja besichtigen.
kann ich nicht erkennen. Da hast du ein alleinstellungsmerkmal.
ZitatNoch kein getConfig bei den beidem ausstehenden. Ich wollte zunächst Meinungen abwarten. Und heute abend habe ich keine Lust, mich ggf. schwarz zu ärgern.
nun, wenn du kein getConfig ausführst können wir dir nicht helfen und könnten uns schwarz ärgen :(.
Du kannst den Ablauf gerne sniffen. Dann kann ich genau nachvollziehen, was das System macht und muss mich nicht auf deine subjektiven Beochachtungen stützen. Bitte 'sniffen' aus dem Wiki beachten und das Problem nach der Aktion schildern.
Zitat
save speichert die FHEM-configuration - also defines und attribute. Ein HM saveConfig wird ebenfalls getriggert, ist also inclusive.
Ist dieses Verhalten neu bzw. muss man das "inclusive" irgendwo aktivieren?
Ich habe natürlich eine fhem.cfg, aber "
find /opt/fhem -name *.cfg" liefert definitiv keine regSave.cfg.
Das Verhalten ist uralt.
Was passiert bei set hm saveConfig? Da sollte ein file angelegt werden. Das gleiche bei save.
Ich habe verstanden dass saveConfig ( und loadConfig) funktionieren.
Zitat von: martinp876 am 16 Februar 2019, 14:12:00
Das Verhalten ist uralt.
Was passiert bei set hm saveConfig? Da sollte ein file angelegt werden. Das gleiche bei save.
Hm ... gerade getestet: "save" erneuert fhem.cfg und fhem.save, aber regSave.cfg bleibt auf dem Stand des gestrigen manuellen Speicherns.
OldFhem hat offenbar noch gar keine Datei.
edit: Oder meinst Du den Befehl "set <hminfo> save" - Speichern von Temperaturlisten (lt. commandref)?
Trotzdem erklärt das nicht den Gedächtnisverlust bei curt: die Infos zu den Registern stecken auch in fhem.save und das sollte immer aktuell sein.
Ich habe bislang nie ein manuelles "set <hminfo> saveConfig" ausgeführt und bislang auch noch nie ein regSave.cfg beim "Save config" erzeugt.
Nun habe ich einmal "set <hminfo> saveConfig" manuell ausgeführt und es wurde erwartungsgemäß ein regSave.cfg erzeugt.
Automatisch scheint hier aber nichts angestossen zu werden ...
Zitat von: martinp876 am 16 Februar 2019, 14:12:00
Das Verhalten ist uralt.
Was passiert bei set hm saveConfig? Da sollte ein file angelegt werden. Das gleiche bei save.
Würdest Du bitte präziser formulieren?
Welches Verhalten ist uralt? - Mein fhem ist eigentlich immer aktuell.
Bei save wird fhem.save und fhem.cfg aktualisiert. Eine regSave.cfg habe ich nicht.
Zitat von: Pfriemler am 16 Februar 2019, 17:46:32
OldFhem hat offenbar noch gar keine Datei.
Ich auch nicht.
Zitat von: Pfriemler am 16 Februar 2019, 17:46:32
Trotzdem erklärt das nicht den Gedächtnisverlust bei curt: die Infos zu den Registern stecken auch in fhem.save und das sollte immer aktuell sein.
Mit martinp876 haben wir nun aber den, der es wissen müsste:
Martin,
9 Melder HM-SEC-SC-2 sowie 1 Melder HM-SEC-SCo. Alle sind seit längerem in Betrieb. Auf Anraten wechselte ich von Busware-CC1101 auf HM-MOD-UART. Da VCCU vorhanden, war das ohne Probleme. Alle Register bei allen Meldern vorhanden, alles prima.
Irgendwann stellte ich fest, dass zwei Melder UNTEREINANDER gepeert waren, das wollte ich loswerden. Der Fortgang ist in diesem Thread zu lesen. Beachte bitte insbesondere #13, da ist der spannende Punkt: Mit der Neuanmeldung der beiden fraglichen Melder verloren ALLE ANDEREN Melder ihre Register.
Ich habe nun so verstanden: Die sind in fhem gespeichert, die kann man gar nicht verlieren. Da kann mal der falsche Wert drin stehen, aber man kann die nicht verlieren. Ist das so richtig? Oder kennst Du eine Situation, in der das möglich erscheint?
Martin,
was käme als Ursache noch in Frage?
Wäre es möglich, dass ich auf einen bislang nicht erkannten Bug in Deinen Modulen gelaufen bin?
1) Pfriemler hat nominell recht: ein "save" löst kein "hm saveConfig" aus. Aber ein "hm archConfig" wenn man "attr hm autoArchive 1" gesetzt hat. HAtteich schon wieder vergessen. Der Unterschied arch und save ist, dass bei arch nur Änderungen aus dem laufenden Betrieb gespeichert werden. Daher wurde auch kein neues File angelegt oder geändert. Save speichert bedingugnslos. Mache ein getConfig und dann ein Save - dann wird das file angelegt.
2) das kein File angelegt wird kann ich mir nicht vorstellen. Das file wird sich auf dem Default-pfad von FHEM finden - also mal im fhem und fhem/FHEM nachsehen.
3) Uralt sind mehrere Jahre. Sollte präzise genut sein, schaue ich jetzt nicht nach :)
4) bei meinem test wurde ein fhem/regSave.cfg nach einem save angelegt.
5) die Register werde auch aus dem Statefile nachgeladen. Da verlasse ich mich nicht drauf, hatte ich schon zu viele verluste. Daher nutze ich "attr hm autoLoadArchive 1"
ZitatIrgendwann stellte ich fest, dass zwei Melder UNTEREINANDER gepeert waren, das wollte ich loswerden
würde ich auch loswerden. Leider kann ich es nicht sehen oder nachvolluziehen.
ZitatMit der Neuanmeldung der beiden fraglichen Melder verloren ALLE ANDEREN Melder ihre Register.
Das ist schlecht. Leider kann ich es nicht nachvollziehen und kann nicht sehen, was du gemacht hast. Wenn du das nachstellen kannst bin ich an einem log interessiert. Das beinhaltet: list der fraglichen devices (eines wird reichen) mit den Registern, anmelden mit sniffen, list der fraglichen devices welche die Register verloren haben
Beachte: wenn das getConfig gestartet wird werden alle Register-Readings dieser Sektion gelöscht. Schlägt das Lesen fehl sind auch keine Register mehr da. Ein konsequentes vorgehen: wenn du die Register von "jetzt" haben willst und das fehlschlägt wird dir nicht vorgegaukelt "hat doch geklappt". Die gespeicherten Register in regConfig.cfg werden erst nach erfolgreichem Lesen überschrieben - ein Unterschied zu den "einfachen Readings" - und dem autoLoadArchive.
ZitatDie sind in fhem gespeichert, die kann man gar nicht verlieren
a) falsch
b) was ist fhem?
c) regConfig.cfg und autoLoadArch sollte das so unterstützen (wenn kein Bug :( ), fhem.state nicht. Da gibt es Lücken
ZitatDa kann mal der falsche Wert drin stehen, ...
falscher Wert verstehe ich nicht. Kenne ich nicht. Fehlen ja.
Zitatwas käme als Ursache noch in Frage?
Für was jetzt? Das Fehlen von Registern/peerings oder das seltsame peeren? 2teres habe ich noch nie gehört.
ZitatWäre es möglich, dass ich auf einen bislang nicht erkannten Bug in Deinen Modulen gelaufen bin?
bei bisher unbekannten Dingen das so, das sie bisher noch nicht bekannt sind. Also klares "ja". Allerdings kann ich den Hergang noch nicht nachvollziehen - ausser dass ich mich bei Registern auf das statefile verlasse und verlassen würde.
=> solltest du das korrekt eingestellt haben und das Fehlen von Registern immernoch stattfinden bitte mitteilen.
Korret ist (für mich)
attr hm autoArchive 1
attr hm autoLoadArchive 1_load
attr hm autoUpdate 0:3
attr hm hmAutoReadScan 30optional (weil ich meine settings file im getrennten Dir sehen will):
attr hm configFilename regConfig.cfg
attr hm configTempFile tempList.cfg
attr hm configDir setup
attr hm webCmd update:protoEvents:rssi:peerXref:configCheck:models:msgStat:clear Protocolund dann erst einmal ein
set hm savConfig
@martinp876
Teile der von Dir vorgeschlagenen Konfiguration waren mir neu. Das habe ich bei mir nun so nachgetragen. Danke!
Nein, noch kein getConfig bei den beiden nicht vollständigen Türmeldern, dafür fehlten mir die Nerven. Und auch noch keine Lösung bei meinen drei Rauchmeldern: Denen fehlt seit Deinem verunglückten Modul-Update das "model", da steht jeweils ein HASH. Dafür habe ich noch gar keine Lösung - bei einem kann ich (verbaut) kein Knöpfchen drücken.
Ich melde mich wieder, wenn ich neues zu melden habe.
Alle Türmelder sind nun sauber, die beiden Türen wollten auch nicht wieder heiraten.
Ersatzweise haben die drei Rauchmelder (direkt nach dieser Aktion) vergessen, dass sie einen Chef haben:
PairedTo missing/unknown
HM_5A5754
HM_5A6710
HM_5A6737
Andererseits wissen die drei ihr "model" auch nicht, da steht immer noch "HASH...".