[gelöst] PairedTo mismatch to IODev - funktioniert aber trotzdem?

Begonnen von Pfriemler, 08 Januar 2020, 13:37:58

Vorheriges Thema - Nächstes Thema

Pfriemler

Bin gerade am Aufräumen meiner configCheck-Fehlerliste.

PairedTo mismatch to IODev
    LEDDimmer3 paired:0x1411A0 IO attr: 1411AB.


Also eine spontane HmID-Änderung hatte ich vor zwei Jahren mal an einem Wandthermostat. So eine temporäre Registeränderung hätte ich hier auch vermutet.
Man sollte nun vermuten, dass das betroffene Gerät sich aus FHEM nicht mehr steuern lässt. Aber weit gefehlt: Es funktioniert noch, und redet nach einem getConfig auch brav mit FHEM, besteht aber auch danach noch darauf, mit der falschen Zentrale (die es mit dieser ID nie gab hier) gepairt zu sein, siehe "PairedTo". Oder ist das ein copy-Fehler aus dem (älteren) R-pairCentral?

READINGS:
     2017-04-02 14:16:49   .D-devInfo      410100
     2017-04-02 14:16:49   .D-stc          20
     2017-10-16 16:15:15   .R-confBtnTime  1 min
     2017-01-24 19:46:47   .R-intKeyVisib  invisib
     2017-01-24 19:46:47   .R-localResDis  off
...
     2019-01-09 10:13:15   CommandAccepted yes
     2017-04-02 14:16:49   D-firmware      2.9
     2017-04-02 14:16:49   D-serialNr      MEQ0344519
     2020-01-08 13:23:37   PairedTo        0x1411A0
     2019-09-12 20:32:13   R-pairCentral   0x1411A0
...
     2020-01-03 09:05:18   powerOn         2020-01-03 09:05:17
     2018-08-17 16:57:35   sabotageAttack_ErrIoAttack cnt 6
     2020-01-08 13:24:44   state           CMDs_done

BTW: Das powerOn ist komisch, es gab m.W. keinen Stromausfall.

Jemand ne Idee was da schief läuft?
"Ä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

ein komplettes list könnte antworten geben.

eventuell hilft set clear all mit anschliessendem getconfig.

meine erfahrungen mit powerOn generell:
je nach device ist es mal vorhanden, oder nicht. wenn es existiert, funktioniert es oder nicht. oder nur eine zeitlang, da manchmal der msg-counter überwacht wird, der aber im normalen betrieb irgendwann "überlauft", und dann einen "falschen" powerOn auslöst.
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

Pfriemler

#2
Welche readings hattest Du vermisst? Ich dachte alles relevante geliefert zu haben. Bin kein Freund von Config-Backups via FHEM-Forum  ::)
edit: ich habe verstanden. msgCounter war um 111, aber lastMsg etc. ... nu is zu spät.


Wie auch immer: "set clear all" und ein getConfig hat es gebracht, es ist alles wieder richtig. (Ich sollte das öfter versuchen, wenn was unstimmig ist).
Anscheinend liefert ein normales getConfig diese Daten nicht (hatte ich ja probiert), insbesondere wenn ein R-pairCentral vorhanden ist. Offenbar wird nach einem clear all mehr abgefragt...

Also scheint im Device alles ordentlich gewesen und geblieben zu sein (sonst wäre ja auch keine Kommunikation möglich gewesen), FHEM war der irrigen Meinung, dass das Pairing nicht stimme.

Danke, wie immer!
"Ä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 ..."