search

lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
947 stars 222 forks source link

Weak NRF Signal #1129

Closed Otto-Normal closed 3 months ago

Otto-Normal commented 1 year ago

Hardware

Modelname: Wemos D1 mini Retailer URL: __

nRF24L01+ Module

Antenna:

Power Stabilization:

Version / Git SHA:

Version: 0.7.42 Github Hash: ___

Build & Flash Method:

Debugging:

Hallo, super in v0.7.42 kann nun mit Anzeige der Signalstärke die Position zum Wechselrichter optimiert werden! Klappt bei mir aber leid nicht…… Abstand zum HM 1500 circa 4 Meter. Auch eine Änderung des Power Levels auf HIGH, oder MAX zeigt unverändert „Weak signal < 64dBm“. Stärkeres Netzteil mit 2,5 A macht keine Änderung.

Übrigens, müsste es nicht heißen (größer) > 64dBm?

Danke!

knickohr commented 1 year ago

Ahhh, da war jemand schneller 😉

Ja, es kommt immer „weak“, obwohl, ich nur ein paar Zentimeter durch eine Wand muß. Und es scheint wohl so, das es nur für einen Inverter gemacht wird. Was ist bei mehreren Invertern ? Eigentlich müßte man das für jeden Inverter abfragen 🤔

Korrekt müßte es :

heißen 🤓

Ollipop030 commented 1 year ago

Übrigens, müsste es nicht heißen (größer) > 64dBm?

Da fehlt eigentlich das Minus Zeichen, oder irre ich mich? Aber das Selbe zeigt er bei mir auch, drei Meter Entfernung mit externer Antenne.

Karlo49 commented 1 year ago

Es muß heißen < -64dbm 0 dbm = 1mW 64 dbm = 2,51 kW das ist schon ein starker Sender Es wird wohl keiner schaffen eine Anzeige von > -64dbm zu bekommen. Dafür muß man das Modul direkt an die Sendeantenne halten

knickohr commented 1 year ago

Korrekt, es fehlt eigentlich nur das -

Ach so, das Power-Level hat nichts mit der Empfangsstärke zu tun. Das ist nur wie stark die DTU sendet. Das andere ist die Empfangsrichtung (WR zur DTU), und das soll dieses Feature anzeigen.

rmayergfx commented 1 year ago

Also ich finde die Bezeichnung etwas unglücklich gewählt. Für das "normale" WLAN wird wifi_rssi angegeben mit korrektem? Wert -62 Warum dann beim nrf24l01+ nun die Bezeichnung in dBm und Weak Signal? Jeder Wert näher an der 0 ist besser, siehe: grafik

Somit steht hier eine verwirrende Information "-" fehlt und es ist ein "Sehr gut" statt "Weak signal". AhoyDTU wurde zum Test gerade mal 2m daneben platziert, mit externer Antenne: grafik

rmayergfx commented 1 year ago

@lumapu Habe gerade mal mit der FW GIT SHA: a515dbb :: 0.7.42 an verschiedenen Standorten im Haus getestet. Da ändert sich nichts, es wird immer "NRF Signal: Weak signal < 64dBm" angezeigt. Kann man irgendwo in der API den richtigen Wert ansehen. Diese Anzeige kann definitiv nicht stimmen, denn ich habe es an Positionen getestet wo ich einen Meter weiter keinen Connect mehr zum WR aufbauen kann.

knickohr commented 1 year ago

😉

IMG_1133

Ob die Anzeige stimmt oder nicht, steht auf einem anderen Blatt. Aber sie funktioniert im Prinzip. Und Ja, es kommt mir auch zu wenig „Strong“. Das obige Bild stammt von einem Fusion Board, offenbar hat es eine bessere Empfangsempfindlichkeit als ein EByte Modul.

lumapu commented 1 year ago

-75dBm heißt weak, -64dBm sind strong. Strong habe ich leider noch nicht sehen können, obwohl der Inverter ca. 3m entfernt (durchs Dach) ist.

grafik

knickohr commented 1 year ago

Wo kommen die -75 her ? Ich dachte es gibt nur die Fallungerscheidung < -64 und > -64

😲

rmayergfx commented 1 year ago

@lumapu Warum sehe ich hier bei mir mit der Firmware keine Werte? Muss dazu etwas freigeschaltet werden?

16:19:55 I: (#0) resetPayload 16:19:55 I: (#0) enqueCommand: 0x0b 16:19:55 I: (#0) prepareDevInformCmd 0x0b 16:19:55 I: TX 27B Ch40 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad 0b 00 00 00 00 00 00 00 00 5e 5c e1 16:19:55 W: (#0) Frame 1 missing: Request Retransmit 16:19:55 I: TX 11B Ch61 | 15 82 03 41 27 84 77 03 44 81 c7 16:19:55 I: procPyld: cmd: 0x0b 16:19:55 I: procPyld: txid: 0x95 16:20:25 I: (#0) resetPayload 16:20:25 I: (#0) enqueCommand: 0x0b 16:20:25 I: (#0) prepareDevInformCmd 0x0b 16:20:25 I: TX 27B Ch75 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad 29 00 00 00 00 00 00 00 00 ff dc e2 16:20:25 I: procPyld: cmd: 0x0b 16:20:25 I: procPyld: txid: 0x95 16:20:55 I: (#0) resetPayload 16:20:55 I: (#0) enqueCommand: 0x0b 16:20:55 I: (#0) prepareDevInformCmd 0x0b 16:20:55 I: TX 27B Ch3 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad 47 00 00 00 00 00 00 00 00 9d 38 0a 16:20:55 I: procPyld: cmd: 0x0b 16:20:55 I: procPyld: txid: 0x95 16:21:25 I: (#0) resetPayload 16:21:25 I: (#0) enqueCommand: 0x0b 16:21:25 I: (#0) prepareDevInformCmd 0x0b 16:21:25 I: TX 27B Ch23 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad 65 00 00 00 00 00 00 00 00 3c b8 09 16:21:25 I: procPyld: cmd: 0x0b 16:21:25 I: procPyld: txid: 0x95 16:21:55 I: (#0) resetPayload 16:21:55 I: (#0) enqueCommand: 0x0b 16:21:55 I: (#0) prepareDevInformCmd 0x0b 16:21:55 I: TX 27B Ch40 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad 83 00 00 00 00 00 00 00 00 58 5a 69 16:21:55 W: (#0) Frame 1 missing: Request Retransmit 16:21:55 I: TX 11B Ch61 | 15 82 03 41 27 84 77 03 44 81 c7 16:21:55 I: procPyld: cmd: 0x0b 16:21:55 I: procPyld: txid: 0x95 16:22:25 I: (#0) resetPayload 16:22:25 I: (#0) enqueCommand: 0x0b 16:22:25 I: (#0) prepareDevInformCmd 0x0b 16:22:25 I: TX 27B Ch75 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad a1 00 00 00 00 00 00 00 00 f9 da 6a 16:22:25 I: procPyld: cmd: 0x0b 16:22:25 I: procPyld: txid: 0x95 16:22:55 I: (#0) resetPayload 16:22:55 I: (#0) enqueCommand: 0x0b 16:22:55 I: (#0) prepareDevInformCmd 0x0b 16:22:55 I: TX 27B Ch3 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad bf 00 00 00 00 00 00 00 00 59 5b 55 16:22:55 I: procPyld: cmd: 0x0b 16:22:55 I: procPyld: txid: 0x95 16:23:25 I: (#0) resetPayload 16:23:25 I: (#0) enqueCommand: 0x0b 16:23:25 I: (#0) prepareDevInformCmd 0x0b 16:23:25 I: TX 27B Ch23 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad dd 00 00 00 00 00 00 00 00 3b ea e4 16:23:25 I: procPyld: cmd: 0x0b 16:23:25 I: procPyld: txid: 0x95 16:23:55 I: (#0) resetPayload 16:23:55 I: (#0) enqueCommand: 0x0b 16:23:55 I: (#0) prepareDevInformCmd 0x0b 16:23:55 I: TX 27B Ch40 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ad fb 00 00 00 00 00 00 00 00 5a 58 11 16:23:55 W: (#0) Frame 1 missing: Request Retransmit 16:23:55 I: TX 11B Ch61 | 15 82 03 41 27 84 77 03 44 81 c7 16:23:55 W: (#0) Frame 2 missing: Request Retransmit 16:23:55 I: TX 11B Ch75 | 15 82 03 41 27 84 77 03 44 82 c4 16:23:55 I: procPyld: cmd: 0x0b 16:23:55 I: procPyld: txid: 0x95 16:24:25 I: (#0) resetPayload 16:24:25 I: (#0) enqueCommand: 0x0b 16:24:25 I: (#0) prepareDevInformCmd 0x0b 16:24:25 I: TX 27B Ch3 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ae 19 00 00 00 00 00 00 00 00 f1 78 7b 16:24:25 I: procPyld: cmd: 0x0b 16:24:25 I: procPyld: txid: 0x95 16:24:55 I: (#0) resetPayload 16:24:55 I: (#0) enqueCommand: 0x0b 16:24:55 I: (#0) prepareDevInformCmd 0x0b 16:24:55 I: TX 27B Ch23 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ae 37 00 00 00 00 00 00 00 00 50 ad 21 16:24:55 I: procPyld: cmd: 0x0b 16:24:55 I: procPyld: txid: 0x95 16:25:25 I: (#0) resetPayload 16:25:25 I: (#0) enqueCommand: 0x0b 16:25:25 I: (#0) prepareDevInformCmd 0x0b 16:25:25 I: TX 27B Ch40 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ae 55 00 00 00 00 00 00 00 00 32 1c 90 16:25:25 W: (#0) Frame 1 missing: Request Retransmit 16:25:25 I: TX 11B Ch61 | 15 82 03 41 27 84 77 03 44 81 c7 16:25:25 I: procPyld: cmd: 0x0b 16:25:25 I: procPyld: txid: 0x95 16:25:55 I: (#0) resetPayload 16:25:55 I: (#0) enqueCommand: 0x0b 16:25:55 I: (#0) prepareDevInformCmd 0x0b 16:25:55 I: TX 27B Ch75 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ae 73 00 00 00 00 00 00 00 00 53 ae 65 16:25:55 I: procPyld: cmd: 0x0b 16:25:55 I: procPyld: txid: 0x95 16:26:25 I: (#0) resetPayload 16:26:25 I: (#0) enqueCommand: 0x0b 16:26:25 I: (#0) prepareDevInformCmd 0x0b 16:26:25 I: TX 27B Ch3 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ae 91 00 00 00 00 00 00 00 00 f7 7e f3 16:26:25 I: procPyld: cmd: 0x0b 16:26:25 I: procPyld: txid: 0x95 16:26:55 I: (#0) resetPayload 16:26:55 I: (#0) enqueCommand: 0x0b 16:26:55 I: (#0) prepareDevInformCmd 0x0b 16:26:55 I: TX 27B Ch23 | 15 82 03 41 27 84 77 03 44 80 0b 00 64 ec ae af 00 00 00 00 00 00 00 00 96 66 b4 16:26:55 I: procPyld: cmd: 0x0b 16:26:55 I: procPyld: txid: 0x95

lumapu commented 1 year ago

ja die habe ich definiert, Vorschläge sind willkommen. Ich könnte auch -65 hinschreiben

lumapu commented 1 year ago

@rmayergfx ja Version 0.7.43 - steckt noch in der Pipeline 😂

knickohr commented 1 year ago

Nein, bitte keine Werte da rein interpretieren. Die Funktion liefert nur die Aussage <-64dBm oder >-64dBm, siehe bitte den PR #1050

Alles andere ist gequirlte Sch… !

lumapu commented 1 year ago

auf der anderen Seite haben wir aber auch ein gegebenes Konstrukt (von den HMS / HMT Wechselrichtern). Es gibt extra ein Feld RSSI für jeden Inverter, das würde ich gerne auch verwenden. Ich weiß dass absolute Werte falsch sind, in der WebUI wird es auch korrekt dargestellt:

grafik

rmayergfx commented 1 year ago

@lumapu Jetzt bin ich noch verwirrter wie vorher. Woher nimmt er bei mir diesen Wert, ich kann da absolut nichts finden. Habe auch mal auf Debug umgeschaltet um mehr angezeigt zu bekommen. Ist das vielleicht ein Wert der nur von den Hoymiles zurückgegeben wird? Mit einem TSUN sehe ich hier nichts.

knickohr commented 1 year ago

Es gibt keinen Wert zurück, im Prinzip nur gut und schlecht, nein sogar nur true/false. In der NRF24 Lib ist das als >-64dBm und <-64dBm definiert.

Der WR gibt nichts zurück, das macht das NRF-Modul.

knickohr commented 1 year ago

Ahhh sooo, jetzt verstehe ich das.

Nur in der seriellen Konsole kommt das mit -75 und -64 🫣

Akzeptiert. Jetzt noch in MQTT und API 🙉🙈🙊

lumapu commented 1 year ago

Akzeptiert. Jetzt noch in MQTT und API 🙉🙈🙊

ok

rmayergfx commented 1 year ago

Ich seh den Wert nicht, warum? Ab welcher FW Version wird das angezeigt?

lumapu commented 1 year ago

ab 0.7.44 für HM Wechselrichter, nicht für MI Wechselrichter

rmayergfx commented 1 year ago

Ich seh nun mit der 0.7.44 im System keine Info mehr, dafür im Live: grafik Serial Log spuckt das aus:

17:38:26 W: (#0) Frame 3 missing: Request Retransmit 17:38:26 I: TX 11 CH61 | 15 82 03 41 27 84 77 03 44 83 c5 17:38:26 I: RX 23 CH3, -75dBm | 95 82 03 41 27 82 03 41 27 83 00 00 00 0a 03 e8 01 00 00 01 58 58 f7

Erklärt mir doch bitte mal, was nun genau hier abläuft. Werden hier nun realistische Werte von irgendwas zurück geliefert oder wie soll das funktionieren. Ich habe mit der 0.7.44 nun verschiedene Punkte im Haus "abgemessen" und in der Anzeige ändert sich nichts, selbst wenn ich direkt neben den WR in 1m Luftlinie positioniere. WR ist ein TSUN M-800(EU), ESP32 mit nrf24l01+ mit ext. Antenne, der sollte schon etwas besser sein als die kleinen onboard Platinen.

knickohr commented 1 year ago

Es ist eine experimentelle Funktion in der Library vom NRF. Warum liest Du den betreffenden Issue #1050 dazu nicht, bzw. den PR #1119 ?

Ob es real ist, oder ob es richtige/falsche Werte sind, das kann Dir nur der Author der Library sagen. Wir versuchen das nur hier mal zu implementieren.

Ich bin auch noch nicht so glücklich damit, weil bei meinen 13 Invertern nur hin und wieder mal ein gutes Empfangssignal kommt. Da kann aber weder @lumapu noch die Library noch Ahoy was dafür.

rmayergfx commented 1 year ago

Mir ging es doch darum zu verstehen was da passiert, habe nun etwas weiter gegraben und es ist wohl so, das es sich um den Wert -64 dBm dreht, der irgendwo auf einem Register verfügbar ist und 0 oder 1 zurückgibt. Da ein genauer Wert hier wohl nicht ausgelesen werden kann, versteckt es bitte gerne wieder im System Menü, damit man sich nicht an einem Wert festklammert, der nicht wirklich aussagekräftig ist. Anscheinend hat der Entwickler des Chipset da nur mit WLAN "gut" und "schlecht" experimentiert. Wenn es keine wirklich nachvollziehbaren realen Werte gibt, würde ich dieses Goodie erstmal auf Eis legen.

lumapu commented 1 year ago

im System Menü hat's nichts verloren, da es wechselrichterspezifisch ist. Jetzt spielt mal damit rum, als nächstes müsste man sich dann die Lösung von @Oberfrizte mal anschauen, da gibt es mW. 10 Stufen

beegee3 commented 1 year ago

die Lösung von @Oberfritze hat nichts mit der Signalstärke zu tun. Bei ihm geht es darum, auf welchen Kanälen vorrangig gesendet werden soll. Dazu wird eine Sende-Erfolgs-Statistik angelegt, um die Kanäle mit den meisten Antworten bevorzugt zu nutzen. Das ist sicher hilfreich, wenn man eine permanente Störquelle in der näheren Umgebung hat, entspricht aber nicht dem von den Invertern genutztem Gazell-channel-hopping, wonach der Empfänger für eine gewisse (feste) Zeit auf einem Kanal horcht bevor er auf den nächsten wechselt. Dabei werden immer alle Kanäle benutzt! Der Sender hingegen startet laut Gazell-Protokoll zunächst mit einem zufälligen Kanal und versucht die Empfänger Wechsel nachzubilden, sobald er eine Antwort erhält. Aufgrund von Asynchronität wird dieses Nachbilden aber nicht lange durchgeführt (höchstens 2 Sek), dann nimmt der Sender wieder einen zufälligen Kanal. Daher ist dieses Nachbilden für uns uninteressant. Die Zeiträume zwischen zwei Sendevorgängen würden in der Regel zur Auswahl eines zufälligen Kanals führen. Wegen meiner kann ich den Gazell-Pseudo-Random-Algorithmus raussuchen (ist ein 5-Zeiler) und für hmRadio aufbereiten. Hilft vielleicht, wenn man mehrere Ahoy ESPs im Einsatz hat, so dass die sich weniger in die Quere kommen können.

knickohr commented 1 year ago

Schon, er hat aber auch eine Bewertung der Kanäle durchgeführt. In der Heuristik kann man eine Art Pseudo-rssi errechnen. Ist zwar kein echtes rssi, aber immerhin.

lumapu commented 11 months ago

gehört für mich irgendwie zu issue #718, glaube hier geht es nicht mehr weiter

DanielR92 commented 3 months ago

Die https://github.com/lumapu/ahoy/issues/718 ist doch closed, kann man dieses Issue auch closen?