Kann man RFUSB Stick testen?

[Baxxy]

Also ich würde ja nochmal von null anfangen.

- alle Batterien aus den Geräten raus
- RaspberryMatic "System Reset" über die Systemsteuerung in der WebUI
- nach dem "Neustart" die Ersteinrichtung machen und gucken ob der HmIP-RFUSB unter den Geräten gelistet ist, wenn nicht ihn aus dem Posteingang holen

Dann die ganze "Anlernprozedur" wie ich weiter vorn beschrieben hatte Step-by-Step wiederholen.

Mehr fällt mir gerade dazu nicht mehr ein.

[jp112sdl]

Hängt in /usr/local/etc/config/crRFD/data evtl. noch eine .dev Datei, die auf die Seriennummer des Geräts endet, fest?
Falls ja, die mal löschen. CCU neustarten. Neu anlernen

[bm-magic]

@jp112sdl & @Baxxy, DANKE für eure Mühe.
a. Wie komme ich aus den Programmen raus auf die Ordner des Raspberry?
Ich hätte es gern versucht die vorgeschlagene Datei zu löschen.
b. Die Idee mit dem System Reset ist natürlich am einfachsten durchzuführen.

Ich wollte "eigentlich" mein erstes Erfolg zeigen, bevor ich die SW De und neu-installiere.
- Zu erst fand ich ein Updates, was ich installiert habe.
- Da nach habe ich es mit dem Test SWDM noch einmal versucht...ohne Erfolg.
- Als nächstes habe ich mein zweites SWDM angelernt versucht...und es funktionierte...)
Anbei das Foto

Ich warte auf die Antwort a. denn damit hätte ich das System reparieren können.
- Die Mögligkeit b. steht auf der nächsten Stelle.

[MichaelN]

Ich glaube du hast ein CarrierSenseLevel Problem, auch wenn nur 3% angezeigt werden.

[jp112sdl]

a. Wie komme ich aus den Programmen raus auf die Ordner des Raspberry?

Geh über den Menüpunkt "Programme und Verknüpfungen" > "Skript testen".

In das Fenster fügst du das hier ein:

Code: Alles auswählen

string a;
system.Exec("ls -l /etc/config/crRFD/data/*.dev", &a);
WriteLine("ls Ausgabe:\n"#a);

und klickst unten links auf "Ausführen".

[Xel66]

Ich glaube du hast ein CarrierSenseLevel Problem...

Könnte sein. Der angezeigte CS ist ja auch nur der des Funkmoduls. Wenn sich der potenzielle Störer mehr in der Nähe der Aktorik befindet, kann das für die CCU noch OK sein und sie signalisiert einen geringen CS. Für den Aktor kann der Störpegel aber zu hoch sein, dass beim "listen before talk" sein eigener CS zuschlägt.

Darum immer im Hinterkoof behalten. Die angezeigten Werte der WebUI (speziell RSSI und CS) sind lediglich Hilfsmittel und stellen keinesfalls die Wahrheit dar, nur weil sie ein "gemessene" (oder auf andere Weise ermittelte) Werte daherkommen. Man muss die Werte auch interpretieren. Es ist wahrscheinlich, daß die Zentrale auch den Störer empfängt und in seinen CS einbezieht, aber es ist eben nicht zwangsweise so.

Den Fall hatten wir vor einiger Zeit hier. Da war der Störer das Netzteil des Monitors am Schreibtisch, der das Anlernen verhindert hat. Die CCU war montiert und das anzulernende Gerät lag auf dem Schreibtisch. Also so, wie es wohl viele machen.
Gruß Xel66

[jp112sdl]

Den Sinn von

"listen before talk"

bei HmIP habe ich ohnehin noch nicht verstanden.
Was ist der Mehrwert? Gefühlt haben die Leute jetzt mehr Kommunikationsprobleme als vorher beim BidCos.

Selbst bei BidCos hätte es schon die LBT-Möglichkeit gegeben (letztendlich ist es der Funkmodul-Chip, der das übernimmt).
Dort hat man jedoch darauf verzichtet.
Und ich kann mich nicht daran erinnern, dass es (wenn überhaupt?) viele Beschwerden über die Geräte-Kommunikation aufgrund von Telegrammkollisionen gab.

[Xel66]

Den Sinn von
...
bei HmIP habe ich ohnehin noch nicht verstanden.

Ich denke, dass der grundsätzliche Ansatz nicht verkehrt ist. Sorgt es doch allein für Funkhygiene und eine gewisse Serialisierung. Leider scheint diese "Automatik" etwas zu scharf justiert zu sein und tritt in grenzwertigen Umgebungen eher als Kommunikationsverhinderer als als -koordinator auf. Bei BidCos hat man es eben mit der Anzahl der Wiederholungen und Zufallsanteilen "in den Griff" bekommen. Die Variante bei HmIP empfinde ich als eleganter, aber eben mit negativen Nebenwirkungen behaftet. Es gibt einfach zu viele Störer im Bereich und der Überwachungsbereich ist m.E. wohl etwas zu breitbandig ausgelegt. Warum? Keine Ahnung. Vielleicht eine Hardwarelimitierung.

Gruß Xel66

[bm-magic]

@jp112sdl, danke
-Deine Idee war sehr gut. Dein Script funktioniert und zeigt, das und wo die *.dev Dateien gibt.
Leider hast Du mir nicht "verraten", wie ich direkt ins OS komme und die Datei löschen kann.
- Aus "Verzweiflung" habe ich die SD Karte direkt ins PC eingesteckt und nach *.dev suchen lassen.
Anbei ein Foto mit dem Pfad, nach dem die Datei gelöscht wurde.
Leider half es nicht.

[bm-magic]

@MichaelN, DANKE SEHR, ich habe Dein Hinweis ernst genommen und habe "provisorisch" den Raspberry ins Topf gesteckt,
Für die Endlösung werde ich Metallgehäuse organisieren.
- Beim anlernen die linke Option gewählt.
Nach dem Aktivierung des Lernvorgang waren alle Geräte nach max. 10 s in dem Posteingang.