3 von 7 Fensterkontakten (HM-Sec-SCo) (Bausätze) lassen sich nicht pairen

[christian.asd]

Hallo zusammen,

ich betreibe Fhem auf einem Raspi2 nun schon seit einem guten Jahr und habe seitdem sechs Heizkörperthermostate (HM-CC-RT-DN) in Betrieb. Diese sind zudem mit sechs virtuelle Thermometern gepeert, welche ihrerseits Daten von ESP8266-basierten Sensoren erhalten. Das funktioniert alles ohne größere Probleme. Das Gesamtsystem läuft also. Die Kommunikation erfolgt über einen Selbstbau-CUL an einer VCCU.

Nun sind sieben Fensterkontakte (HM-Sec-SCo) als Bausätze hinzugekommen. Vier von diese ließen sich (nach Installation von libcrypt-rijndael-perl) problemlos mit der VCCU pairen, drei wollen einfach nicht.

Der Startvorgang aller dieser Sensoren verläuft gleich. Also gleiche LED-Sequenz.

Wenn ich die Sensoren in den Anlernmodus bringe, blinken diese erst langsam. Die funktionierenden wechseln dann auf schnelles Blinken (Anlernen), die nicht funktionierenden Blinken einfach weiter langsam und hören dann irgendwann auf.

Was ich bisher probiert habe:

- Fhem updaten (sowieso!)
- CUL-Firmware updaten. Hatte bisher eine ältere a-culfw laufen. Dann die neuste a-culfw getestet und zur Zeit bin ich auf der neusten Standard-culfw.
- Sensoren resetten. Zweimal langes Drücken bis schnelles rotes Blinken. Es folgt Bestätigung durch 3 s rot und dann starten die Sensoren neu.
- Verschiedene Abstände zwischen CUL und den Sensoren.
- Debugging durch verbose=5 und hmProtocolEvents=3_dumpTrigger beim CUL. Nun habe ich sehr viel Zeug in den Logs, aber bezüglich der nicht funktionierenden Sensoren scheint nichts aufzutauchen. Jemand einen Tipp, wie ich die Logs sinnvoll Filtern kann bzw. nach welchen Strings ich eigentlich suche?
- Sensor direkt an ein Heizkörperthermostat anlernen. Wird mit "F4" abgebrochen, was aber zu erwarten ist, solange das Heizkörperthermostat mit der VCCU gepairt ist. Aber es bedeutet, dass der Sensor zumindest Signale sendet.
- Nun ein Heizkörperthermostat komplett entpeert und entpairt und dann versucht, die störrischen Sensoren direkt hier anzulernen und siehe da: Funktioniert bei allen dreien problemlos! Nun dieses Thermostat wieder mit der VCCU verbunden und die Register ausgelesen. Hier ist mir nun aufgefallen, dass die IDs aller bereits funktionierenden Sensoren mit "4E5A" beginnen, die IDs der nicht funktionierenden Sensoren beginnen allerdings bei allen mit "4E5B". Ich habe das Gefühl, dass dies kein Zufall ist. Ist es möglich, dass es irgendwo einen Bug oder sowas gibt, der nur bestimmte IDs durchlässt?

Ansonsten bin ich mit meinem Latein langsam ziemlich am Ende.

Für Ideen oder Lösungsvorschläge bin ich sehr dankbar!

Viele Grüße

Christian

[frank]

hmProtocolEvents=3_dumpTrigger beim CUL

das solltest du wieder löschen.

probiere die cul fw aus dem angepinnten thread inkl 00_cul.pm.

[christian.asd]

das solltest du wieder löschen.

Weil es den Log zumüllt oder hat es einen anderen Grund?

probiere die cul fw aus dem angepinnten thread inkl 00_cul.pm.

Danke, probiere ich heute Abend mal. Wusste bisher nicht, dass ich Probleme mit den Timings haben könnte bzw. wie diese überhaupt aussehen.

[christian.asd]

Noch eine Frage: Du meinst wahrscheinlich diesen Thread: https://forum.fhem.de/index.php/topic,31421.0.html ?

Hier finde ich nur eine Firmware für den CULV3, ich betreibe allerdings einen nanoCUL. Vermutlich kann ich die Firmware da nicht einfach drüberflashen?!

Der oben genannte Thread führt zu einem weiteren, in dem es mehr Sourcen gibt, auch aktuellere im letzten Beitrag. Evtl. besser dies nehmen? https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649

[klausw]

Im ersten Post gibt es dort noch einen Link.
Der führt zu einer Version, die auch die nano Quellen enthält (habe ich selber noch nicht getestet, werde es aber demnächst auch angehen, da meine HM Tür/Fenster-Kontakte nicht komplett pairen)

[frank]

hmProtocolEvents=3_dumpTrigger beim CUL

das soll sehr belastend sein. daher sicherlich nicht förderlich, wenn es ums timing geht.
genau, fw würde ich die neueste aus dem folge-thread nehmen, die passt.

[christian.asd]

Danke schon mal soweit. Ich habe alle Sourcen übernommen und den CUL geflasht. Nun bekomme ich zumindest Meldungen im Log.

Folgender Fehler taucht nun auf, wenn ich einen der Sensoren in den Anlernmodus versetze:

Code Auswählen Erweitern

2016.11.28 18:30:49.190 4 : TSCUL_Parse: nanoCUL868 342482 A FF11 01076352 00 1A 15 8400 4E5B00 000000 1000C74E45513039343031353680810101 -53.5
2016.11.28 18:30:49.195 1 : in UNDEFINED
2016.11.28 18:30:49.196 1 : in UNDEFINED
2016.11.28 18:30:49.196 1 : in UNDEFINED
2016.11.28 18:30:49.218 1 : PERL WARNING: Use of uninitialized value $mh{"devN"} in regexp compilation at ./FHEM/10_CUL_HM.pm line 2848.
2016.11.28 18:30:49.219 1 : stacktrace:
2016.11.28 18:30:49.219 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (2848)
2016.11.28 18:30:49.220 1 : main::CUL_HM_Parse called by fhem.pl (3427)
2016.11.28 18:30:49.221 1 : main::Dispatch called by ./FHEM/00_TSCUL.pm (770)
2016.11.28 18:30:49.221 1 : main::TSCUL_Parse called by ./FHEM/00_TSCUL.pm (292)
2016.11.28 18:30:49.222 1 : main::TSCUL_Read called by fhem.pl (3264)
2016.11.28 18:30:49.222 1 : main::CallFn called by fhem.pl (672)


edit: Problem gelöst! Ich hatte autocreate noch aus. Jetzt hat das Pairing mit allen neuen Devices geklappt.

Super Sache! Vielen Dank für Eure Hilfe!!!

[frank]

prima, und vergiss nicht 00_cul.pm von fhem-updates auszuschliessen.

[klausw]

prima, und vergiss nicht 00_cul.pm von fhem-updates auszuschliessen.

meinst du nicht die 10_CUL_HM.pm? 

habe jetzt auch die modifizierte Variante aus dem Thread übernommen. Meine beiden HM-Sec-SCo funktionierten auf Anhieb.

[frank]

meinst du nicht die 10_CUL_HM.pm? 

aha, es geht voran.
danke für den hinweis.

[christian.asd]

Ich habe einfach alle Files mit

Code Auswählen Erweitern

attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_TSSTACKED.pm DevIoTS.pm CUL_Util.pm 10_TSIT.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm CalcUtil.pm

ins Exclude übernommen.

[martinp876]

Warum? 00_cul verstehe ich. Ist modifiziert. 10_cul_hm?

[frank]

hallo martin,

klicke auf das zitat:

10_CUL_HM.pm muss ausgetauscht werden, bis @Martin die Änderung in den Standard übernommen hat. Hier wird auf CUL_Util.pm zurück gegriffen, um den CUL Typ abzufragen.