CC1101 und RSSI-Werte bei HB-Devices

[tndx]

Guten Abend,

ich habe mittlerweile einige HM-kompatible Nachbauten mit AskSinPP-basierter Firmware im Einsatz und heute ist mir eine Sache aufgefallen. Zunächst mal die RSSI-Werte von 4 davon:

1:

Code Auswählen Erweitern

rssi_at_myHmUARTLGW     cnt:68 min:-83 max:-57 avg:-65.47 lst:-57
rssi_at_myHmUARTUSB     cnt:52 min:-75 max:-60 avg:-65.86 lst:-65
rssi_myHmUARTLGW        cnt:27 min:-89 max:-73 avg:-82.44 lst:-88
rssi_myHmUARTUSB        cnt:24 min:-81 max:-72 avg:-76.33 lst:-76

2:

Code Auswählen Erweitern

rssi_at_myHmUARTLGW     cnt:10 min:-59 max:-51 avg:-53.3 lst:-54
rssi_at_myHmUARTUSB     cnt:10 min:-79 max:-65 avg:-70 lst:-68
rssi_myHmUARTLGW        cnt:3 min:-89 max:-86 avg:-88 lst:-86
rssi_myHmUARTUSB        cnt:1 min:-79 max:-79 avg:-79 lst:-79

3:

Code Auswählen Erweitern

rssi_at_myHmUARTLGW     cnt:27 min:-46 max:-40 avg:-42.74 lst:-46
rssi_at_myHmUARTUSB     cnt:27 min:-78 max:-60 avg:-62.96 lst:-62
rssi_myHmUARTLGW        cnt:7 min:-102 max:-95 avg:-99.14 lst:-95
rssi_myHmUARTUSB        cnt:1 min:-75 max:-75 avg:-75 lst:-75

4:

Code Auswählen Erweitern

rssi_at_myHmUARTLGW     cnt:34 min:-93 max:-78 avg:-84.08 lst:-85
rssi_at_myHmUARTUSB     cnt:44 min:-66 max:-38 avg:-49.61 lst:-38
rssi_myHmUARTLGW        cnt:1 min:-81 max:-81 avg:-81 lst:-81
rssi_myHmUARTUSB        cnt:32 min:-97 max:-72 avg:-85.28 lst:-94

Die Aktoren 1-3 sind im selben Raum, zusammen mit dem IO-Device myHmUARTLGW, lediglich der Abstand variiert zw. ca 2 und 6 m, bis myHmUARTUSB sind es immer mindestens 5 m und 1-2 Wände mehr.

Beim 4. Aktor ist es genau umgekehrt, was die IO-Devices angeht.

Was mir nun auffällt ist, dass die "at"-RSSI-Werte besser bei dem IO-Device sind, was am nächsten ist, was für mich auch logisch und nachvollziehbar ist. Die "ohne-at"-RSSI-Werte sind aber besser bei den weiter entfernten IO-Devices, was für mich nicht logisch ist, gibt es dafür eine nachvollziehbare Erklärung?

Das Problem dabei ist, dass FHEM/VCCU das IO-Device offenbar anhand der "at"-RSSI-Werte bestimmt, was widerum dazu führt, dass die Verbindung von FHEM zu den Aktoren hin über die suboptimale, um nicht zu sagen unterirdische Funkstrecke verläuft. Dabei kommt es zu Verzögerungen (vermutlich, weil Messages mehrfach gesendet werden müssen, nicht überprüft) bzw. zu Nicht-Reaktionen (weil Messages vermutlich verloren gehen).

Auch wenn es an sich doch noch recht zuverlässig funktioniert und ich andernfalls die Aktoren auch manuell an die "besseren" IO-Devices binden könnte, würde es mich interessieren, wie es zu diesem RSSI-Ungleichgewicht kommt und wie ich vielleicht FHEMs/VCCUs-Strategie zur Bestimmung der IO-Devices beeinflußen könnte?

[tndx]

Weil es so schön ist:

hier sind die RSSI-Werte des 2. Aktors in einem anderen Raum, eine Stahlbetondecke von den IO-Devices entfernt:

Code Auswählen Erweitern

rssi_at_myHmUARTLGW     cnt:6 min:-78 max:-75 avg:-76.66 lst:-77
rssi_at_myHmUARTUSB     cnt:6 min:-75 max:-71 avg:-72.83 lst:-71
rssi_myHmUARTLGW        cnt:2 min:-78 max:-77 avg:-77.5 lst:-77
rssi_myHmUARTUSB        cnt:4 min:-82 max:-77 avg:-79 lst:-82

Der rssi_myHmUARTLGW-Wert ist deutlich besser, als im selben Raum nur etwa 3m vom IO-Device entfernt... Wie kann das sein?

[frank]

setze doch am aktor das andere io als prefered io, wenn du meinst das wäre besser geeignet.

ein ausrichten der antennen könnte besserung bringen.

[tndx]

setze doch am aktor das andere io als prefered io, wenn du meinst das wäre besser geeignet.

Ist mir schon klar, habe ja auch geschrieben, dass ich das könnte...

ein ausrichten der antennen könnte besserung bringen.

Die Original-HM-Aktoren zeigen dieses Verhalten aber nicht, obwohl die antennentechnisch ähnlich aufgebaut sind und die Platzierung im Raum ähnlich ist.

[papa]

Hm - das Senden der RSSI-Werte ist nicht wirklich intelegent in der AskSinPP-Library. Es wird sich immer der letzte Wert gemerkt und gegebenenfalls beim der Statusmessage mitgesendet. Wenn es blöd läuft, wurde zwischendurch ne andere Nachricht empfangen und es wird der "falsche" RSSI-Wert mitgesendet. AUßerdem bin ich mir auch nicht wirlich sicher, ob die RSSI-Berechnung 100% OK ist.

[tndx]

Das betrifft aber nur die "Nicht-at"-RSSI-Werte? D.h. möglicherweise sind sie bei mir nicht umgekehrt proportional zur Entfernung, wie es den Anschein erweckt,  sondern es werden die falschen (vom falschen HM-Device/IO-Device?) angezeigt? Und die (vermeintlichen) Verzögerungen beim Schalten liegen nicht an den verlorenen Messages, oder zumindest nicht aufgrund von schlechten RSSI-Werten verlorenen Messages? Das müsste ich dann noch mal gesondert untersuchen.

Was mich aber wundert, dass es noch niemandem aufgefallen ist. Aber so gesehen kann es ja nur bei AskSinPP-Devices auffallen, die Befehle von FHEM entgegen nehmen, also Aktoren (bei den Sensoren werden keine "Nicht-at"-RSSI-Werte angezeigt, oder habe ich sie noch nicht entdeckt). Und zum anderen spielt es u.U. eine Rolle, dass ich mehr als ein IO-Device habe...