[GELÖST] HB-RF-USB-TK: Probleme Wechsel von HM-MOD-RPI-PCB auf RPI-RF-MOD

[deimos]

Hi,

die Platine braucht inkl. Funkmodul weniger als 150mA, so wie es in den USB Descriptoren angeben ist. Das kann man sehr genau aus den ganzen Datenblättern der verschiedenen ICs ablesen, genau das habe ich im Vorfeld gemacht und dann mit etwas Sicherheitspuffer die 150mA eingetragen.

Viele Grüße
Alex

[Scrounger]

die Platine braucht inkl. Funkmodul weniger als 150mA

Ok 900mA zu 150mA ist eine sehr große Differenz. Könnte die von mir beschriebene Problematik durch Fehler beim Löten erklärt werden?

[deimos]

Hi,

klar kann das ein Lötfehler sein, braucht nur irgendwo einen Kurzschluss. Aber wahrscheinlicher ist es, dass die beiden Ports eine unterschiedliche Restwelligkeit haben und diese kann im dümmsten Fall ähnlich wie Störstrahlung auf das Funkmodul einwirken.

Viele Grüße
Alex

[Scrounger]

Hi,

klar kann das ein Lötfehler sein, braucht nur irgendwo einen Kurzschluss. Aber wahrscheinlicher ist es, dass die beiden Ports eine unterschiedliche Restwelligkeit haben und diese kann im dümmsten Fall ähnlich wie Störstrahlung auf das Funkmodul einwirken.

Viele Grüße
Alex

Ich würde mal behaupten das ich vom Löten speziell Stiftleisten schon eine gewisse Erfahrung besitze.

Und was könnte ich hier jetzt noch machen? USB Kabel durch Ferritkern führen?
Der Pin-Header für das HM-MOD-RPI-PCB Modul ist noch drauf, kann das evtl. noch Auswirkungen haben?

[Scrounger]

Nachtrag:
Hab jetzt den wahren Grund identifizieren können - die zwei per USB3 angeschlossenen Festplatten.
Wenn ich die abklemme, dann spielt das USB Kabel und der verwendete Port auch keine Rolle mehr.

Scheint also so zu sein, dass die USB3 Platten nicht nur den WLAN 2,4GHZ Bereich stören können, sondern auch den 868 Mhz Bereich.
Was ich allerdings interessant finde, das die Störung nicht das alte HM-MOD-RPI-PCB betreffen.

[Marrom77]

Servus,

ich würde gern nochmal nachfragen, weil ich den Umstieg auf RPI-RF-MOD wegen solcher Probleme bislang abgebrochen und aufgegeben habe. Dass die Schlüssel neu gezogen und aktiviert werden müssen und dass das Zeit braucht habe ich verstanden. Auch in diesem Thread ist die Rede von "HMIP-Geräte nicht erreichbar". Aber bei mir ist es immer so, dass nach dem Wechsel (egal ob gleiche CCU oder neue mit Einspielen Backup) alle HMIP-Geräte einfach fort sind. Natürlich sind sie noch in der Konfiguration enthalten, aber die WebUI zeigt kein einziges mehr an. Ist das normal während der Re-Keying-Phase oder ist bei mir doch irgendwas anderes problematisch? Ich habe übrigens einen gezielten Versuch dazu mit mehreren Stunden Wartezeit hinter mir. Ergebnis: Kein einziges HMIP-Gerät mehr angezeigt und Kommunikation funktioniert auch nicht.

[jmaus]

Aber bei mir ist es immer so, dass nach dem Wechsel (egal ob gleiche CCU oder neue mit Einspielen Backup) alle HMIP-Geräte einfach fort sind. Natürlich sind sie noch in der Konfiguration enthalten, aber die WebUI zeigt kein einziges mehr an. Ist das normal während der Re-Keying-Phase oder ist bei mir doch irgendwas anderes problematisch?

Für mich hört sich das in der Tat nach einem anderen Problem an, denn die Geräte sollten aus der WebUI nicht einfach verschwinden nur wegen dem Re-keying. Ich würde also an deiner stelle mal eine Blick in das hmserver.log logfile werfen und auch schauen was unter /etc/config/crRFD/data so zu finden ist wenn die Geräte verschwunden sind.

[Marrom77]

Danke für die Bestätigung. Das gibt mir schon mal einen besseres Verständnis der Situation. Wenn ich mal wieder die Zeit (und den Mut )dafür finde, werde ich nochmal einen Anlauf unternehmen. Denn der Fallback auf das alte Modul ist dann auch immer anstrengend und zeitaufwendig, vielleicht weil zumindest teilweises Re-keying wieder "zurückgedreht" werden muss...