Mysensors Empfangsthematik

Begonnen von smoudo, 24 Juli 2017, 21:30:21

Vorheriges Thema - Nächstes Thema

smoudo

Ich betreibe mysensors über Hexenmeister's Gateway
und habe mittlerweile 3 Nodes am laufen.
Auf dem Gateway sitzt ein nrf24 + externe Antenne.
Auf den Nodes habe ich die version ohne externe Antenne.

Auf meinem Stromzähler Node habe ich eine Reichweite von locker 10 Meter durch 2 Räume
Auf den anderen beiden Nodes sind baugleiche Module der selben charge und die haben einen
Empfang von vielleicht 3 Metern! Durch Wände ist nicht dran zu denken.

Probiert habe ich schon die Adapter Platinen mit eigenem Spannungswandler und auch stützkondensatoren in smd + die großen mit Beinchen 47uf.

Softwareseitig vergebe ich die ID fest,
Channel auf allen Nodes 36

Welche Erfahrungen habt Ihr bezüglich nrf24?
Bringt etwas Besserung?
Bezugsquellen anständiger Module?
Schonmal jemand den 69er Chip mit 868 MHz getestet? Wie läuft das Softwareseitig(stabil)?

Was sich so liest haben viele damit Probleme. Währe schön wenn wir hier eine hilfreiche Sammlung und Anlaufstelle für Funkprobleme anlegen könnten!


Grüße

Matze

Beta-User

Mit den nRF habe ich auch so meine Erfahrungen gemacht ;) .

Ursachen waren - seit ich eine pa+lna-Variante am GW habe - in der Regel eher weniger die HW-Themen (mal abgesehen von Kondensatoren), eher war irgendwann (kurz vor 2.0 und bis zum Release 2.1, mit dem das behoben wurde) mal softwareseitig richtig der Wurm drin.

Die nRF24-lib wurde übrigens neulich erst wieder mit einem Update beglückt.

Der PA-Level sollte auch zur Spannungsquelle passen (der verwendete  Arduino könnte also auch einen Einfluß haben, je nachdem, wie der versorgt wird bzw. ob der Wandler verwendet wird).

Dann hat die Sendehäufigkeit noch einen Einfluß (Buffer overflow auf dem nRF oder Stromproblem, wenn man sehr viele (signierte?) Nachrichten aufeinanderfolgend sendet).

Aber zum Glück gibt's ja RS485, da bin ich im Moment bei, einiges umzuziehen ;) , von daher werde ich bis auf weiteres keine andere Funktechnik testen.

Den Kanal höher wählen hilft nach dem Hörensagen auch (bis 84 ist erlaubt), mit 36 dürfte man noch im WLAN-Bereich sein (Nachbar, andere Hausseite?).

Bin aber mal gespannt, was andere so berichten...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Generell geht man davon aus (gleiche Antennenquali, gleiche Sendeleistung):

Dass auf tieferen Frequenzen die Reichweite deutlich besser wird.

433 MHz (genannt Deppenband ist recht voll, aber ansonsten das mit der besten Reichweite in dieser Liste)
868 MHz ist bei mir ziemlich frei, etwas geringere Reichweite
5 GHz für WLAN haben die meisten noch nicht entdeckt, ballern dafür aber 2,4GHz voll (z.T. mit dümmlichen Repeatern):
2,4 GHz: Den Tipp von Beta-User mit Kanal84 versuche ich mir mal zu merken und zu recherchieren...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

smoudo

Ich Flash die Tage mal sämtliche boards auf Kanal 84 und Berichte!
Rs485 finde ich auch spannend, habe allerdings von nicht funktionierenden libs gelesen!
Wie sieht da das Gateway aus? ESP Gateway fänd ich gut!

Grüße

Matze

Beta-User

Hab's nachgesehen: Kanal 83 ist wohl das eigentliche Limit, steht in der MyConfig.h (ab Zeile 609) so drin:
* In some countries there might be limitations, in Germany for example only the range 2400,0 - 2483,5 Mhz is allowed
* http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2013_10_WLAN_2,4GHz_pdf.pdf


Zu Beginn (ohne pa+lna) hatte ich noch eine Repeater-Node drin, mein GW ist im OG, der 1. Repeater war im EG (wird nicht mehr benötigt), mittlerweile ist meine wichtigste node im Keller auch als GW definiert und mit einem pa+nla ausgestattet. Über den lief eine Zeitlang dann der Funkverkehr zur Garage (ebenfalls pa+nla) und in den Garten, mittlerweile (seit 2.1) ist die Reichweite aber bis direkt zum GW, Luftlinie ca. 7 bis 9m).

Was RS485 angeht: bin noch nicht besonders weit gekommen, aber an sich funktioniert das. Wobei ich nie auf die Idee gekommen wäre, eine Funkbrücke zwischenzuschalten. Der Sinn des Kabels ist für mich, die Steuerung autonom von sonstiger Infrastruktur zu machen, und WLAN geht da eigentlich gar nicht 8) .
Da die RS485-Ansteuerung aber sehr eng an bestimmte PINs gebunden ist, dürfte das auch nicht ganz einfach sein, von AVR auf ESP zu wechseln.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

smoudo

Und wie bring ich das dann an mein fhem auf dem Raspi?

Grüße

Matze

Beta-User

Geht m.E. viel einfacher mit einem Arduino, nennt sich dann serielles GW:

Bei mir hängt das meiste seriell dran, so:
Zitatpi@fhem-amlogic:/opt/fhem/FHEM/firmware$ ls -l /dev/serial/by-id                                                                                                                   
total 0                                                                                                                                                                           
lrwxrwxrwx 1 root root 13 Jul 22 19:17 usb-busware.de_CUL868-if00 -> ../../ttyACM0                                                                                                 
lrwxrwxrwx 1 root root 13 Jul 23 06:03 usb-FTDI_MySensorsGW_74336002-if00-port0 -> ../../ttyUSB0                                                                                   
lrwxrwxrwx 1 root root 13 Jul 17 12:17 usb-JR_MyS-GW-RS485_001-if00-port0 -> ../../ttyUSB1                                                                                         
lrwxrwxrwx 1 root root 13 Jul 24 21:43 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB2                                                             
lrwxrwxrwx 1 root root 13 Jul 22 19:13 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB3
Der Prolific ist ein Signalduino, am SiliconLabs hängt mein HMUART (PI-Modul) ;) .

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

smoudo

Also rs485<-> arduino nano <-> usb <-> rpi
Richtig? Wird das vom Raspian automatisch erkannt? Hab welche mit dem 340er Chipsatz
In fhem dann angelegt als:
define meinMSG MYSENSORS /dev/ttyUSB1@115200
?!?
Wie sieht das bei zB 3 Nodes auf einem Bus aus? Braucht man da Widerstände etc.?


Grüße

Matze

Beta-User

An sich wäre RS485 ein seperater Thread ;) , wenn Du es ausprobiert hast, darfst Du gerne das Wiki ergänzen und/oder einen Howto-Thread erstellen, wir pinnen den dann an...

Zitat von: smoudo am 24 Juli 2017, 22:54:31
Also rs485<-> arduino nano <-> usb <-> rpi
Korrekt.
Zitat
Wird das vom Raspian automatisch erkannt? Hab welche mit dem 340er Chipsatz
Auf OS-Ebene ist das idR. kein Problem, auch mit dem 340-er WinChipHead. Das Problem dabei ist nur, dass man nicht mehrere Arduinos haben sollte mit diesem Chipsatz, sonst läßt sich das nicht sauber auseinanderhalten (siehe meinen Post vorher, also besser das Geld in FTDI's anlegen (eventuell geht auch ATmega32U4 als MC für Gateways, das habe ich aber noch nicht ausprobiert, wie man da die USB-Kennung eindeutig macht und ob das mit dem MySensors-Code geht. Es sollte aber an sich kein Problem sein... ;) )

Zitat
In fhem dann angelegt als:
define meinMSG MYSENSORS /dev/ttyUSB1@115200
Besser "by-id", aber so geht es auch. Bei mir sehen die GW's so aus (ich mache nur "by-id"!):
define MySensorsRS485GW MYSENSORS /dev/serial/by-id/usb-JR_MyS-GW-RS485_001-if00-port0@115200
define MyGateway MYSENSORS /dev/serial/by-id/usb-FTDI_MySensorsGW_74336002-if00-port0@115200

Zitat
Wie sieht das bei zB 3 Nodes auf einem Bus aus? Braucht man da Widerstände etc.?
Es ist ein Bus. Also (mit den RS485-Modulen) bis zu 32 Teilnehmer auf einem Bus, Widerstände sind auf den handelsüblichen Modulen schon drauf. Man kann auch Ranseyers Platinen nehmen und 487-Bausteine draufmachen, da gehen dann 64 oder 128 (?) Teilnehmer, und es bräuchte nur je Widerstände am Anfang und Ende des Busses (@Ranseyer: Bitte um Korrektur, wenn ich das falsch im Kopf haben sollte). Verkabelung optimalerweise in Serie, (es gibt aber Berichte, dass RS485 recht unempfindlich sein soll, was Sternverkabelung angeht).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zum nRF-Reichweitenthema noch gefunden:
https://forum.mysensors.org/topic/7213/repeatrer-level-limit-nrf24l01-transport/4#

Zitatit depends on the chip quality: there are some performing better with lower power, it is a matter of doing tests to figure it out, there is not rule to follow with all those counterfeit nrf24 chips around
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

smoudo

Sorry hab den rs485 Thread gerade erst gesehen :o

Mit den verschiedenen pa Leveln hatte ich auch schon rumprobiert und konnte keinen merklichen Unterschied feststellen.

Grüße

Matze

Beta-User

Zitat von: smoudo am 25 Juli 2017, 20:24:51
Mit den verschiedenen pa Leveln hatte ich auch schon rumprobiert und konnte keinen merklichen Unterschied feststellen.
Habe das selbst noch nicht verifiziert, nur irgendwo aufgelesen. Beim Querlesen des "Integrations"-Treads ist mir noch aufgefallen, das die verwendeten libs eine sehr große Rolle spielen. Ich würde in jedem Fall empfehlen, die aktuellste nRF-lib zu nehmen,  bei MySensors die 2.2-beta einzusetzen und die Board-Defs auf dem aktuellsten Stand.

Zitat von: smoudo am 25 Juli 2017, 20:24:51
Sorry hab den rs485 Thread gerade erst gesehen :o

...den gibt es auch noch nicht so lange, ist ein Auszug aus dem "Mega-Thread"; hoffe, das ist hilfreich ;) ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

smoudo

Gefällt mir sehr gut!

Libs technisch hab ich seit 2.1.1 gefühlt größere reichweitenprobleme wie unter 1.5.4.
Trotzdem hab ich das Gefühl das diese nrf Viecher eine Riesen Streuung haben!

Grüße

Matze

Beta-User

Thx, ich fand's auch launig beim Querlesen der RS485-Beiträge :) . Wenn Dir beim Querlesen des Integrations-Threads was auffallen sollte, was man herausheben sollte: Einfach verlinken, darf gerne auch in die Fundgrube.

Zu 1.5.4 kann ich nix sagen als Reichweitenvergleich; ich fand das coding unter 2.0.0-beta sehr viel einleuchtender, also war das meine erste Version (daher auch der Nickname ;) ).

Was Streuung angeht, habe ich auch nie ernsthafte Tests unternommen, aber es ist schon heftig, welchen Einfluß da die SW hat (es gab im MySensors-Forum einige Leute, die sich gewundert haben, dass sie plötzlich Kondensatoren bei alten Nodes brauchten nach einem SW-update. Und die Dinger sehen wirklich unterschiedlich aus, je nachdem, aus welcher Quelle sie kommen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

smoudo

Selbes Node, selbe Software.
10x nrf an einem Stück zum rausbrechen.
Also praktisch die selbe Charge. Und hier hab ich die beschriebenen Streuungen. Im Prinzip von 10 Stück 2 zu gebrauchen. Die anderen entweder katastrophal oder 5 Meter bei Sichtweite.

Was mir noch aufgefallen ist:
In fhem kann man ja das repeater Feature einschalten. Wenn ich das Node mit schlechter Reichweite neben das mit guter hänge bei aktivem repeater, kommt trotzdem nichts am Gateway an.


Wenn wir schon bei den libs sind. Gibt es eine einfache Möglichkeit an aktuelle libs zu kommen?
Ich lade die immer manuell aus den gits runter und kopier das rein. An manchen Stellen Finde ich die IDE sehr bescheiden. Gerade im paketmanager ist oft nur altes Zeug was kompilierfehler erzeugt.

Grüße

Matze

Ranseyer

Hmmm, Fake Chips ?

((Ansonsten die Bestückung ? (Kondensator Müll?)))
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

smoudo

Kondensator hab ich div smd probiert und auch die großen mit Beinchen. Fake Chips kann man leider nicht ausschließen. Sinnvolle Bezugsquellen?

Grüße

Matze

DerFrickler

Zitat von: Ranseyer am 24 Juli 2017, 22:04:30
Generell geht man davon aus (gleiche Antennenquali, gleiche Sendeleistung):

Dass auf tieferen Frequenzen die Reichweite deutlich besser wird.

433 MHz (genannt Deppenband ist recht voll, aber ansonsten das mit der besten Reichweite in dieser Liste)
868 MHz ist bei mir ziemlich frei, etwas geringere Reichweite
5 GHz für WLAN haben die meisten noch nicht entdeckt, ballern dafür aber 2,4GHz voll (z.T. mit dümmlichen Repeatern):
2,4 GHz: Den Tipp von Beta-User mit Kanal84 versuche ich mir mal zu merken und zu recherchieren...

Bei mir daheim funkt WLAN im 2,4 MHz (Kanäle 1, 5, 9 und 13) und 5 GHz (aktuell nur Kanal 40) Bereich. Dazu kommt noch HomeMatik im 868,3 MHz Bereich. Grundsätzlich hätte ich jetzt gesagt ich versuche mich mal an 433 MHz, da es ja eh die beste Reichweite zu haben scheint. Was für Anwendungen befinden sich in diesem Bereich?

Beta-User

433 ist halt auch das Band, in dem die "schmutzigsten" Anwendungen unterwegs sind. Würde ich eher meiden und auf 868MHz setzen. Da ist die Reichweite noch ok, aber die in D verkaufte HW respektiert idR. die 1%-Regel. Damit haben Signale tendenziell bessere Chancen, auch dort anzukommen, wo sie hin sollen.

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

Zitat von: Beta-User am 12 August 2017, 08:53:43
433 ist halt auch das Band, in dem die "schmutzigsten" Anwendungen unterwegs sind. Würde ich eher meiden und auf 868MHz setzen. Da ist die Reichweite noch ok, aber die in D verkaufte HW respektiert idR. die 1%-Regel. Damit haben Signale tendenziell bessere Chancen, auch dort anzukommen, wo sie hin sollen.

Just my2ct.

Zum Thema 1% Regel:
Die Bundesnetzagentur schreibt für die Nutzung verschiedener ansonsten frei nutzbarer Frequenzbereiche sogenannte maximale relative Frequenzbelegungsdauern fest. Sinn dieser Maßnahme ist es, die Nutzung der Frequenzbänder durch mehrere Nutzer auch bei Reichweitenüberlagerung zu ermöglichen. Für 868,35 MHz, also der Frequenz, in dem das HM, FS20 und FHT System arbeitet, sind ≤ 1% vorgeschrieben. Dies ergibt 36 Sekunden Sendedauer je Stunde. Besonders bei der eher langsamen Datenübertragung der FHT und FS20 Protokolle kann es zu Engpässen kommen.
Das bezieht sich auf den einzelnen Sensor? Wie viele Datenübertragungen dürften dann pro Stunde erfolgen?

Gruß und Danke!

Beta-User

Ja, pro Sender. Bei vernünftiger Menge an Datenpunkten dürfte das nicht das Problem sein.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

smoudo

Nachdem meine nodes jetzt relativ gut gelaufen sind, habe ich in den letzten paar Tagen ständig WLAN Probleme. Nach ausschalten der nodes ist sofort Besserung spürbar. Werde mich jetzt kurzfristig an die Umsetzung rs485 machen und weiter berichten.

Grüße

Matze

tante ju

Zitat von: smoudo am 28 August 2017, 21:28:50
Nachdem meine nodes jetzt relativ gut gelaufen sind, habe ich in den letzten paar Tagen ständig WLAN Probleme. Nach ausschalten der nodes ist sofort Besserung spürbar. Werde mich jetzt kurzfristig an die Umsetzung rs485 machen und weiter berichten.

Sorry, habe den Thread jetzt erst gesehen.
Zwei Dinge:
1. MySensors mit dem NRF verwendet standardmäßig Kanal 76 bei 2476 MHz. Das sollte sich eigentlich mit WLAN vertragen, aber nur, wenn Du auch wirklich nur Kanäle 1,6,11 nimmst und mit 20 MHz betreibst. Aber eigentlich ist es viel besser, gar kein WLAN im 2 GHz Band zu machen und das 5 GHz Band zu nutzen (802.11a, 802.11a/n, 802.11ac). Dann entfällt das Problem gänzlich.
2. Die Sende-/Empfangsqualität des NRF hängt ziemlich stark von der Qualität der Versorgungsspannung ab. "Ein Kondensator mit Beinchen" ist da eher suboptimal. Eine Paarung aus 100nF Keramik und 47 µF X5 direkt am Anschluß des NRF (keine langen Leiterbahnen, Zuleitungen, keine Windungen etc.) helfen massiv.

DerFrickler

Zitat von: tante ju am 07 September 2017, 11:38:17
1. MySensors mit dem NRF verwendet standardmäßig Kanal 76 bei 2476 MHz. Das sollte sich eigentlich mit WLAN vertragen, aber nur, wenn Du auch wirklich nur Kanäle 1,6,11 nimmst und mit 20 MHz betreibst. Aber eigentlich ist es viel besser, gar kein WLAN im 2 GHz Band zu machen und das 5 GHz Band zu nutzen (802.11a, 802.11a/n, 802.11ac). Dann entfällt das Problem gänzlich.
Wenn Du der einzige WLAN Betreiber in der Umgebung bist könnte das klappen. Oder Du überzeugst Deine Nachbarn auch auf das 5GHz Band umzusteigen. Bei mir kann ich aktuell 5 andere WLAN Netze im 2,4 GHz Bereich erkennen, die mit hervorragender Qualität im nähren Umfeld vertreten sind.
Zitat von: tante ju am 07 September 2017, 11:38:17
2. Die Sende-/Empfangsqualität des NRF hängt ziemlich stark von der Qualität der Versorgungsspannung ab. "Ein Kondensator mit Beinchen" ist da eher suboptimal. Eine Paarung aus 100nF Keramik und 47 µF X5 direkt am Anschluß des NRF (keine langen Leiterbahnen, Zuleitungen, keine Windungen etc.) helfen massiv.
Mit RFM69 868 MHz habe ich bisher die besten Erfahrungen gemacht, nRF24 hingegen nur verflucht.

tante ju

Zitat von: DerFrickler am 14 September 2017, 23:46:30
Wenn Du der einzige WLAN Betreiber in der Umgebung bist könnte das klappen. Oder Du überzeugst Deine Nachbarn auch auf das 5GHz Band umzusteigen. Bei mir kann ich aktuell 5 andere WLAN Netze im 2,4 GHz Bereich erkennen, die mit hervorragender Qualität im nähren Umfeld vertreten sind.

Bin mir nicht sicher, ob ich das richtig verstehe.
Bei 2.4 GHz sollte man eigentlich immer nur die Kanäle 1,6,11 verwenden. Auch, wenn da andere senden. Normalerweise wird 20 MHz für eine Übertragung verwendet (bei bgn kann man auf 40 MHz umschalten), der Kanalabstand ist aber nur 5 MHz. Das bedeutet, wenn einer Kanal 1 und der andere 3 verwendet, dann überlappen sich die Signale. Da aber die Mittelfrequenz unterschiedlich ist, erfolgt die Überlappung außerhalb des Protokolls, wird also als Interferenz wahrgenommen. Als Resultat verringert sich der Netto-Durchsatz für beide, plus einiger anderer negativer Effekte. Würden aber beide Netze auf Kanal 1 arbeiten, dann wird das im Protokoll erkannt und behandelt und der Netto-Durchsatz wird höher. Noch besser ist es natürlich, auf 6 oder 11 auszuweichen. Aber das hängt davon ab, wieviele Nachbarn man hat.
Die Anzeige der "Signalstärke" ist gemeinhin ziemlich nutzlos, denn zum einen ist der Signalüberschuß wichtig, also die Differenz zwischen Signalstärke und Rauschen (inklusive Interferenzen) und die Signalverzerrung. Dann kommen noch Protokolleffekte dazu, die ganz massiv den Durchsatz trotz hervorragender Signalqualität beeinträchtigen können.
Bei 5 GHz gibt es so viele überlappungsfreie Kanäle, daß man da eigentlich ohne Probleme immer was freies findet und somit vielen Problemen und den Nachbarn aus dem Weg geht.

Zitat von: DerFrickler am 14 September 2017, 23:46:30
Mit RFM69 868 MHz habe ich bisher die besten Erfahrungen gemacht, nRF24 hingegen nur verflucht.

Ich habe keine Erfahrung mit dem RFM69, aber reichlich NRF im Einsatz. Neben den Problemen mit Fake-Chips, die den Low-Power-Mode nicht unterstützen, habe ich festgestellt, daß schlechte Reichweite fast immer eine Folge von schlechter Entkopplung der Versorgungsspannung ist. Die sind da echte Mimosen, ähnlich dem ESP.

Hauswart

Zitat von: tante ju am 07 September 2017, 11:38:17
Eine Paarung aus 100nF Keramik und 47 µF X5 direkt am Anschluß des NRF (keine langen Leiterbahnen, Zuleitungen, keine Windungen etc.) helfen massiv.
Hast du davon ein Bild? Beide Parallel?
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Ranseyer

#26
Ja klar parallel. Ein kleiner Keramik Kondensator um die HF kurz zu schließen. Ein GROSSER z. B. Elko um die Spannung zu puffern.


ed: Die Rechtschreibkorrektur hatte mir den Text oben versaut. Nur sollte es verständlich sein.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Eben gefunden: Tester-Sketch, um schlechte nRF auszusortieren und ggf. den passenden PA-Level rauszufinden...

(Kann aber nicht sagen, ob der funktioniert).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Hauswart

Zitat von: Beta-User am 13 Oktober 2017, 07:54:35
Eben gefunden: Tester-Sketch, um schlechte nRF auszusortieren und ggf. den passenden PA-Level rauszufinden...

(Kann aber nicht sagen, ob der funktioniert).
Sehr interessant. Jetzt müsste man nur noch Zeit haben :)
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Beta-User

Zitat von: Hauswart am 13 Oktober 2017, 11:40:20
Sehr interessant.
Fand ich auch.
Ergänzender Hinweis: Lt. Berichten auf der MySensors.org-Seite gibt es bei den Modulen teilweise erhebliche Serienstreuungen. Will heißen: Auch wenn man eine Platine mit mehreren zusammenhängenden nRF-Modulen bekommt, darf man leider nicht davon ausgehen, dass alle gleich gut (oder schlecht) funktionieren >:( . (Jedenfalls, wenn es keine "Blob"-Module sind, die sind zuverlässig schlecht ::) ).
Testen macht also tatsächlich Sinn (wenn man Zeit dafür hat oder sie sich nimmt, weil man die nicht in Fehlersuche investieren will).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sash.sc

Habe das hier mit großem Interesse gelesen, da der Betrieb von Mysensors praktisch unmöglich ist.
Habe mal meine wlan Kanäle überprüft.
In direkter Umgebung finden hier 13 wlan ap's in 2.4 GHz ihren Platz. Und alle schön über die ganze Bandbreite verteilt.
Im 5 GHz ist natürlich gähnende leere.

Da hat sich mir die Frage aufgedrängt, ob es nicht ein funkmodul mit 5 GHz gibt, die evtl von Mysensors unterstützt werden?

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Beta-User

Nicht 5Ggz: rfm69,


oder der neue chip, mit dem neverdie experimentiert
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sash.sc

Rfm69 wäre auch noch ne Alternative.

Von welchem Chip redest du?

Gesendet von meinem E6653 mit Tapatalk

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Beta-User

Zitat von: sash.sc am 16 Oktober 2017, 20:42:01
Von welchem Chip redest du?
Ich dachte an diesen Thread: https://forum.mysensors.org/post/77642. Habe aber keine Ahnung, was sich technisch dahinter verbirgt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tante ju

Zitat von: Beta-User am 17 Oktober 2017, 08:58:31
Ich dachte an diesen Thread: https://forum.mysensors.org/post/77642. Habe aber keine Ahnung, was sich technisch dahinter verbirgt...

nRF 52, das ist 2.4 GHz BLE 5.0