[Gelöst]PairedTo mismatch to IODev

Begonnen von Tarja, 01 April 2018, 14:53:25

Vorheriges Thema - Nächstes Thema

Tarja

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.


viegener

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
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Pfriemler

#2
"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 ... ???
"Ä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 ..."

frank

du nutzt einen cul als io und bei diesem fehlt das attr hmid.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Tarja

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 msgEvents


Zitat 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.

Otto123

mach mal attr CUL_0 hmId F11034
Und schau ob der Fehler verschwindet...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

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
"Ä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 ..."

Tarja

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

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz