Frohe Ostern
Ich nutze die freien Tage, um mein FHEM ein bisschen aufzuräumen und bei einem configCheck bekomme ich mehrere Meldungen
PairedTo mismatch to IODev
HM_4EAC69 paired:0xF11034 IO attr: -.
schl_wz paired:0xF11034 IO attr: -.
St_bad paired:0xF11034 IO attr: -.
St_ei paired:0xF11034 IO attr: -.
St_ez paired:0xF11034 IO attr: -.
Diese Geräte funktionieren bis heute aber perfekt daher die Frage, was diese Meldung im Detail zu bedeuten hat und wie ich diese loswerde
ein simples getConfig für jedes Device scheint nicht zu funktionieren.
Nach meinem Verständnis heisst das, dass die HMID bei dem IODevice nicht zu der HMID aus dem entsprechenden Device passt.
Das kann unterschiedliche Gründe haben, dafür solltest Du vielleicht mal ein list eines betroffenen devices posten.
Bei mir kommt das zum Beispiel bei einem Device vor, den ich nie ander Zentrale angelernt hatte
"Funktionieren" ist relativ. Daten eines nicht mit der eigenen Zentrale gepairten Gerätes mitzulesen ist ja kein Problem. Nur jede Steuerung - und dazu gehört auch die Anforderung von Statusdaten aus FHEM heraus - ignoriert das Gerät natürlich.
Wenn das Gerät bereits mit einer anderen Zentrale gepairt ist, kann man
a1) der eigenen Zentrale vorübergehend diese ID zuweisen, dann das Gerät ent-pairen (unpair, im Ur-Homematic-Slang "ablernen") - dabei bleiben Geräteeinstellungen erhalten
oder
a2) das Gerät komplett zurücksetzen per Reset-Prozedur (dabei werden aber alle Einstellungen und Verknüpfungen im Gerät zerstört - wird die zugehörige Definition in FHEM nicht gelöscht, stehen deren Einstellungen aber (Räume, Namen, Icons) nach dem Anlernen wieder zur Verfügung)
und dann anschließend
b) das Gerät an FHEM sauber pairen nach den üblichen Methoden.
b) funktioniert nicht ohne a).
In Deinem Fall dürften keine Konfigurationen vorgenommen worden sein (wie auch) und damit a2) einfacher sein - nur wenn peers vorhanden sind, dann gibt es mehr Arbeit.
Im Falle eines gesetzten AES mit eigenem Schlüssel führt an a1) nebst Kenntnis des richtigen Schlüssels aber kein Weg vorbei...
Ganz ehrlich interpretiere ich die Meldung aber nur so: F11034 ist die eigene Zentrale, aber in den Devices fehlt die Angabe eines IODev-Attributs ... ???
du nutzt einen cul als io und bei diesem fehlt das attr hmid.
Zitat von: viegener am 01 April 2018, 15:00:21
Nach meinem Verständnis heisst das, dass die HMID bei dem IODevice nicht zu der HMID aus dem entsprechenden Device passt.
Das kann unterschiedliche Gründe haben, dafür solltest Du vielleicht mal ein list eines betroffenen devices posten.
Bei mir kommt das zum Beispiel bei einem Device vor, den ich nie ander Zentrale angelernt hatte
Hier ein Beispiel list:
Internals:
CUL_0_MSGCNT 61
CUL_0_RAWMSG A0B50A44034B9CC4194020108::-47.5:CUL_0
CUL_0_RSSI -47.5
CUL_0_TIME 2018-04-01 14:58:16
DEF 34B9CC
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 61
NAME Schliesserkontakt_wz
NOTIFYDEV global
NR 227
STATE Schliesserkontakt_wz_Btn_01 Short
TYPE CUL_HM
channel_01 Schliesserkontakt_wz_Btn_01
channel_02 Schliesserkontakt_wz_Btn_02
channel_03 Schliesserkontakt_wz_Btn_03
channel_04 Schliesserkontakt_wz_Btn_04
lastMsg No:50 - t:40 s:34B9CC d:419402 0108
protLastRcv 2018-04-01 14:58:16
protSnd 69 last_at:2018-04-01 14:41:55
protState CMDs_done
rssi_at_CUL_0 max:-40.5 avg:-49.43 min:-60 lst:-47.5 cnt:61
READINGS:
2018-04-01 14:41:06 CommandAccepted yes
2018-04-01 14:41:52 D-firmware 1.5
2018-04-01 14:41:52 D-serialNr LEQ1237887
2018-04-01 14:41:52 PairedTo 0xF11034
2018-04-01 14:41:06 R-pairCentral 0xF11034
2018-04-01 14:41:52 RegL_00. 02:01 0A:F1 0B:10 0C:34 00:00
2018-04-01 14:58:16 battery ok
2018-04-01 14:58:16 state Schliesserkontakt_wz_Btn_01 Short
helper:
HM_CMDNR 80
cSnd 01F1103434B9CC01044194020104,01F1103434B9CC02044194020104
mId 0034
regLst ,0
rxType 4
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +34B9CC,00,00,00
nextSend 1522587496.22998
prefIO
rxt 0
vccu
p:
34B9CC
00
00
00
mRssi:
mNo 50
io:
CUL_0:
-39.5
-39.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_CUL_0:
avg -49.4344262295082
cnt 61
lst -47.5
max -40.5
min -60
shadowReg:
tmpl:
Attributes:
IODev CUL_0
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.5
model HM-PBI-4-FM
room CUL_HM,Wohnzimmer
serialNr LEQ1239845
subType pushButton
webCmd getConfig:clear msgEventsZitat von: Pfriemler am 01 April 2018, 15:31:59
"Funktionieren" ist relativ. Daten eines nicht mit der eigenen Zentrale gepairten Gerätes mitzulesen ist ja kein Problem. Nur jede Steuerung - und dazu gehört auch die Anforderung von Statusdaten aus FHEM heraus - ignoriert das Gerät natürlich.
Ich kann die Geräte aber auch aus FHEM steuern.
Das IODev ist in den attr gesetzt.
mach mal attr CUL_0 hmId F11034
Und schau ob der Fehler verschwindet...
Ach, das ist ermüdend. Solche Fehlermeldungen helfen doch wirklich nicht. Natürlich macht die Sache mit der fehlenden hmID beim CUL den meisten Sinn.
Aber wenn Tarja schreibt, dass ein getConfig nicht funktioniert, aber das Gerät aus FHEM zu steuern ist, dann ist das erste Widerspruch, und der zweite: wie das mit einem CUL ohne hmID geht.
Ich gehe jetzt weiter Eier suchen ... ;D
Zitat von: Otto123 am 01 April 2018, 19:10:24
mach mal attr CUL_0 hmId F11034
Und schau ob der Fehler verschwindet...
Ich glaube das war die Lösung! So einfach und doch müsste man daran denken.
Zitat von: Pfriemler am 01 April 2018, 19:25:54
Ach, das ist ermüdend. Solche Fehlermeldungen helfen doch wirklich nicht. Natürlich macht die Sache mit der fehlenden hmID beim CUL den meisten Sinn.
Aber wenn Tarja schreibt, dass ein getConfig nicht funktioniert, aber das Gerät aus FHEM zu steuern ist, dann ist das erste Widerspruch, und der zweite: wie das mit einem CUL ohne hmID geht.
Ich gehe jetzt weiter Eier suchen ... ;D
Scheinbar ging es doch irgendwie ;-)
Viel Spass beim Eier suchen!
Danke an Alle für eure Hilfe
Naja, das ist mal wieder eine Beispiel für den Thread -> https://forum.fhem.de/index.php?topic=81852.0
Martin hat zwar irgendwann diesen "Fehler" eingebaut aber das Grundübel liegt aus meiner Sicht darin, dass der CUL Benutzer oft gar nicht weiß, dass es eine hmId gibt.
Schöne Ostern
Otto
wie kann man eine vergebene hmid wieder löschen, um das system auf einen definierten Zustand zu bringen?
Mfg
Michael
Moin,
die vergebene HMID zu löschen, wäre aus meiner Sicht der undefinierte Zustand.
Ansonsten gibt es das attr hmId beim IO und wenn eine VCCU definiert ist bestimmt diese die hmId für die untergeordneten IOs.
Es wäre besser Du beschreibst dein Problem mehr im Detail.
Gruß Otto
ich mach mal einen neuen Thread auf