[GELÖST] HM-LC-Sw1PBU-FM: Fehler bei Pairing "has no TYPE"

Begonnen von MadEagle, 21 November 2020, 17:08:27

Vorheriges Thema - Nächstes Thema

MadEagle

Hi zusammen,

ich versuche einen neuen HM-LC-Sw1PBU-FM mit FHEM zu pairen. Im Log steht, dass das neue Device defined ist, dann kommt eine Fehlermeldung und das Device ist nicht vorhanden. Hier das genaue Vorgehen:

- IO-Device (HMLAN) in Pairing-Modus versetzen -> In der Oberfläche steht hmPair auf 1
- Config-Button beim HM-LC-Sw1PBU-FM drücken -> LED am HM-LC-Sw1PBU-FM blinkt

Hier ein beispielhafter Auszug aus dem Logfile:


2020.11.21 15:27:26 2: CUL_HM Unknown device HM_723A96 is now defined
2020.11.21 15:27:26 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4582.
2020.11.21 15:27:26 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1627.
2020.11.21 15:27:26 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1628.
2020.11.21 15:27:26 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1672.
2020.11.21 15:27:26 2: CUL_HM Unknown device HM_723A96 is now defined
2020.11.21 15:27:26 3: HMLAN: Unknown code A1A028400723A960000002800695245513034393432383110010100::-58:HMLAN, help me!
2020.11.21 15:27:55 1: Error: >< has no TYPE, but following keys: >helper<


Bei weiteren Versuchen fehlen die Warnings, der Rest wird immer wieder gemeldet. Das Device ist anschließend entgegen der Meldung nicht defined, es taucht weder in in der Logdatei nach einem Speichern oder in fhem.save auf.

Ich habe es mehrfach probiert, auch den Schalter auf Werkseinstellungen zurück gesetzt. Reichweite kann nicht das Problem sein, der Schalter lag zum Anlernen 2m neben dem HMLAN. FHEM ist nach einem "update all" und anschließendem Restart auf den neusten Stand, ein anderer HM-LC-Sw1PBU-FM funktioniert seit langem und auch aktuell ohne Probleme.

Hat irgendjemand eine Idee, woran das liegen kann? Mache ich was falsch, ist der Schalter kaputt oder ist das ein Fehler im Modul?

Danke, Steffen

MadEagle

Wow, das scheint ja ein größeres Problem zu sein, dass es keine Idee hier gibt, woran es liegen kann.

Ich habe selber mal Perl programmiert und könnte versuchen, das Problem zu debuggen. Kann mir jemand Hinweise dazu geben, wie ich das am besten angehe?

Danke, Steffen

Otto123

Hallo Steffen,

Hast Du noch alte Varianten von 10_CUL_HM.pm 98_HMinfo.pm HMConfig.pm?
Sowas z.B.?
10_CUL_HM.pm    22022 2020-05-24 08:50:40Z martinp876
98_HMinfo.pm    21999 2020-05-22 11:05:41Z martinp876
HMConfig.pm     20888 2020-01-05 06:59:29Z martinp876


Gruß 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

noansi

Hallo Steffen,

gehe ich richtig in der Annahme, dass Du autocreate nicht aktiv hast?
Oder mit ignoreTypes das Anlegen des devices durch autocreate unterbindest?

Gruß, Ansgar

MadEagle

Zitat von: Otto123 am 24 November 2020, 19:12:46
Hast Du noch alte Varianten von 10_CUL_HM.pm 98_HMinfo.pm HMConfig.pm?

Ich habe gerade noch einmal eine "update all" mit anschließendem Restart gemacht. Meine Dateien sehen so aus:


632942 Nov 15 18:48 10_CUL_HM.pm
194653 Nov 15 18:48 98_HMinfo.pm
202800 Nov 15 18:48 HMConfig.pm


Das sollte also aktuell sein.

Gruß, Steffen

frank

zeige besser die ausgabe von cmd "version".

und, was ist mit autocreate?
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

MadEagle

Zitat von: noansi am 24 November 2020, 19:34:29
gehe ich richtig in der Annahme, dass Du autocreate nicht aktiv hast?

Boah, ist das peinlich. Du bist richtig in der Annahme gegangen, autocreate war nicht aktiv. Mit definiertem autocreate wird das Gerät erkannt und funktioniert wie es soll. Der Fehler "has no Type" tritt auch nicht mehr auf.

Danke für Eure Hilfe und sorry für so einen dämlichen Fehler. Das kommt davon, wenn man sich nach langer Zeit das System erweitert und sich von den Meldungen im Log dann von der Fährte zur Lösung abbringen lässt.

Danke, Steffen

Otto123

Zitat von: MadEagle am 25 November 2020, 09:23:40
Das sollte also aktuell sein.

Gruß, Steffen
Hallo Steffen,

schön das es funktioniert. Ich hatte meine Frage missverständlich formuliert: Ich meinte ja genau andersherum: vielleicht liegt es an der aktuellen Version - nimm doch mal eine Alte :)

Gruß 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