Betreibe FHEM mit CUL am Raspberry PI. Benötige aber jetzt AES-Verschlüsselung!

frank · 04 März 2016, 11:40:43

genau, ohne pairing keine kommunikation, also auch kein einspielen der sicherung. die sicherung ist ja auch eher für konfigurationsänderungen und peerings gedacht.

das pairing bleibt ja erhalten, wenn man es nicht absichtlich löscht.

wenn du deine zentralen hmid änderst (zb durch wechsel der zentrale, indem vorher mit eq3 sw gespielt wurde), bringt dir das alte pairing natürlich auch nichts mehr, da das device nur mit der gespeicherten hmid kommuniziert.

Alcamar · 04 März 2016, 11:57:21

die hmid habe ich nicht geändert. Lediglich die Firmware von CUL und nun auch hmusb habe ich aktualisert.

Da ich auch nicht an Zufällen glaube, kann ich zumindest berichten, was jetzt auch das zweite Device vermutlich zum pairen überredet hat. Ein shutdown restart von fhem (?).
Als ich die unzähligen Versuche des ersten Fenstersensors auch zum Erfolg gebracht habe, hatte ich davor auch ein Restart gemacht. Bilde ich mir das nur ein?

Ich bin jedenfalls froh, dass alle Sensoren wieder gepaired sind.

Danke für die Unterstützung.
Kann mich nun den restlichen kleinen Baustellen in der hminfo configCheck widmen.

Alcamar · 05 März 2016, 16:49:35

Wenn in den internals CMDs_processing steht, soll ich da besser nix machen und nur bei pending mal auf den Device-Knopf drücken?
Weil mir das zufällige Pairing der Devices davor keine Ruhe läßt, habe ich ein Device resettet (Werkseinstellungen). Dann "set myVCCU hmPairForSec 300" und anschließend Knopf auf dem Fenstersensor. Es folgt minutenlang (>10) CMDs_processing. Irgendwann kommt pending und das schiebe ich wieder mit Knopfdruck an. ....
Ich bekomme den Sensor nicht gepaired. Ich hätte aber gerne einen Anlernprozess, der kontrolliert durchgeht. Das habe ich nicht. Die anderen Fenstersensonsoren waren irgendwann gepaired, aber warum und was endlich zur Erfolg geführt hat, ist mir ein Rätsel. Das stimmt mich einfach nicht zuversichtlich. Ich habe das Gefühl, dass fhem mich im Griff hat, aber nicht umgekehrt. 😎

frank · 05 März 2016, 17:55:41

ZitatWenn in den internals CMDs_processing steht, soll ich da besser nix machen und nur bei pending mal auf den Device-Knopf drücken?

bei prozessing sind beide noch aktiv, also noch ein moment warten und dann den browser aktualisiren.

lies meine beiträge nochmal sorgfältig durch.

Alcamar · 05 März 2016, 21:42:48

Hallo Frank,
ich habe zu diesem Thema alle Deine Beiträge aufmerksam gelesen. Damit habe ich auch einiges erfolgreich erledigen können. Refresh des Browsers und keine nervösen Finger

habe ich alles beherzigt. Die Queue geleert mit clear msgEvents und dann auch Processing abgewartet. Auch das Wecken durch einfaches öffnen des Fensters usw. Vielleicht mache ich auch noch einen systematischen Fehler, der mir diese Sensoren einfach nicht reibungslos pairen lässt. Ich habe bisher eine Vielzahl von devices problemlos an fhem anbinden können. Soviel Probleme wie mit diesen Sensoren hatte ich nicht.
ich hätte gerne beliebig reproduzierbare Ergebnisse und keine "Zufallsresultate". Dafür lese ich auch gerne alle notwendigen Beiträge.

Alcamar · 06 März 2016, 09:50:07

Pairing hat nun geklappt.

Warum? Kann ich nicht wirklich sagen.
Als IODevice nutze ich ein CUL und ein HMUSB. In IOgrp war beim Fenstersensor der CUL als bevorzugt eingetragen, weil der leicht bessere RSSI-Werte hat. Alle Komponenten befinden sich in einem Radius von 3 Meter voneinander entfernt. In der Konstellation habe ich mehrmals (mindestens 15 Mal) den Anlernprozess vergeblich gestartet.
Die Stadien CMDs_processing dauerten bis zu 30 Minuten, um dann wechselweise nach CMDs_pending zu gehen wo ich dann wieder auf den Knopf gedrückt habe usw., usw. Alles vergeblich. Auch das leeren der msgQueue, Resetten des Sensors, etc. etc.
Dann habe ich in der IOgrp einfach den "schlechteren" HMUSB eingetragen (--> Save) und den Anlernvorgang wieder angestoßen. Der Vorgang war in Sekundenschnelle erledigt. Fenstersensor ist gepaired. In der IOgrp steht natürlich automatisch der CUL drin (wg bessere RSSI). Hat die kurzzeitige Änderung des IOgrp den Erfolg gebracht? Oder war es Zufall?

Wenn ich mehr Zeit hätte, würde ich einen neuen Sensor mir vorknöpfen, aber das muss ich ein andermal machen.

Markus · 06 März 2016, 10:10:10

Ich hatte die selben Probleme wie du aber ich bin nicht so geduldig hab 3-4 mahl den Anlern knopf gedrückt wen es nicht geklappt hat Batterie raus kurz warten und wieder von vorne ging eigentlich ganz gut...

Gruss Markus

frank · 06 März 2016, 10:32:38

ZitatDann habe ich in der IOgrp einfach den "schlechteren" HMUSB eingetragen (--> Save) und den Anlernvorgang wieder angestoßen. Der Vorgang war in Sekundenschnelle erledigt. Fenstersensor ist gepaired. In der IOgrp steht natürlich automatisch der CUL drin (wg bessere RSSI). Hat die kurzzeitige Änderung des IOgrp den Erfolg gebracht? Oder war es Zufall?

das ist sicherlich das problem.

grundsätzlich hat der cul nachteile bei der kommunikation mit homematic gegenüber hmlan, hmusb, da das timing der messages von fhem nicht kontrollierbar ist. wenn nun auch noch aes im spiel ist, wird das timing durch die umfangreichere kommunikation sicherlich immer kritischer.

im homematicbereich ist ein thread angepinnt, der eine verbesserte fw bietet. damit sollten die probleme entschärft werden können.

du kannst beim pairen auch direkt entscheiden mit dem hmusb zu pairen, indem du gleich "set hmusb pairforsec" benutzt. dann wird allerdings nicht automatisch das attr iogrp gesetzt. das müsstest du dann manuell ändern.

sofern es die rssi zulassen, würde ich allen homematic devices den hmusb als prefered io zuordnen, zumindestens diejenigen mit eingeschaltetem aes, oder andere problemkinder. dann übernimmt der cul nur, falls der hmusb verhindert ist. das empfangen der messages wird sowieso von allen io's gemacht.