CUL_RFR - Revolt CUL868/CUL434

[tdoe]

Hallo zusammen,

ich habe an einem RPI3 einen CUL434 und einen CUL868. Ein weiterer CUL868 habe ich zum RFR CUL konfiguriert.
Gerne würde ich jetzt eine Revolt EnergieMonitoring Steckdose per RFR CUL empfangen. Jedoch scheint es so als ob hier keine Revolt Nachrichten empfangen werden auf dem Stick. (keine r* per screen sichtbar)
Hatte auch versucht #define HAS_REVOLT in die hoard.h zu packen und auch die frequenz auf 433 geändert. Dann erreiche ich jedoch den CUL nicht mehr und per screen sind nachwievor keine r* Nachrichten abrufbar.

Hat mir jemand einen Tip was ich tun muss um das Setup so zum laufen zu bekommen?
Oder ist das schlicht nicht möglich in dieser konstellation.

Gruß tdoe

[KölnSolar]

Ich kann Dir nicht sagen, ob es geht oder nicht. Was ich Dir aber sagen kann, dass es nur wenige Protokolle gibt die per RFR unterstützt werden. Das steht dann leider nirgends so deutlich, so dass man glaubt es ginge viel mehr. Und die Theorie des RFR ist ja klasse.

Ich bin bei meinem RFR-Thema auch noch nicht weiter 
Grüße Markus

[rudolfkoenig]

@tdoe:
Die RFR Funktionsweise kurz: Falls aktiviert ist, dann sendet ein RFR alles, was normalerweise per USB ausgegeben wird, an dem naechst-hoeheren RFR Knoten weiter. Dazu wird erst im SlowRF ein 6-bit Ping gesendet, danach schalten beide auf dem CC1101-eigenen Paketmodus mit 250kHz Datenrate, und nach dem Senden/Empfang wieder zurueck auf SlowRF. Es gibt kein ack oder gar resend.
WICHTIG:
- beide (bzw. alle betroffenen) CULs muessen wg. dem Ping im SlowRF Mode sein.
- alle muessen auf die gleiche freq/bwidth/etc eingestellt sein.
- ich habe RFR nie mit 433 getestet, evtl. sind da die Wartezeiten fuer Umschaltung / Zurueckschaltung falsch.

@KölnSolar:
RFR haengt sich bei Dispatch() (nach dem Empfang) und IOWrite (vor dem Senden) rein, um die Nachrichten mit dem entsprechenden Prefix zu versehen, bzw. beim Empfang zu entfernen. 10_IT.pm ruft in vielen Faellen CUL Funktionen direkt per CallFn auf, damit modifiziert das Modul ein direkt per USB angeschlossenes CUL, anstatt diese Nachrichten ueber RFR an dem "IT"-CUL zu uebermitteln. Fraglich ist auch, ob diese Funktionen ueber RFR realisierbar ist. Die oben erwaehnte Enschraenkungen bleiben fuer IT natuerlich auch bestehen.

[KölnSolar]

Hallo Rudi,
danke für die Erläuterungen. Ich verstehe das noch nicht im Detail, glaube aber, dass Ralf9 mir das bzgl. IT ähnlich erklärt hatte. Wie immer ist die Zeit aber zu knapp bzw. andere Prioritäten(Betty  ).

- ich habe RFR nie mit 433 getestet, evtl. sind da die Wartezeiten fuer Umschaltung / Zurueckschaltung falsch.

Könntest Du dazu nicht einen klitzekleinen Hinweis in die commandref einbauen oder umgekehrt eine Positivliste ?

WICHTIG:
- beide (bzw. alle betroffenen) CULs muessen wg. dem Ping im SlowRF Mode sein.

Das alleine schließt ja schon etliches aus und steht nur recht "verschlüsselt/undeutlicher" in der commandref

after pinging the base CUL at the usual 1kBaud.

Die Revolt ist ja nur ein Sensor, also RFR-CUL --> Haupt-CUL bzw.

RFR haengt sich bei Dispatch() (nach dem Empfang)

ein.
@Rudi: Dann müsste es ja theoretisch klappen, wenn alle von Dir genannten Bedingungen erfüllt sind bzw. man könnte sich auf diese

- ich habe RFR nie mit 433 getestet, evtl. sind da die Wartezeiten fuer Umschaltung / Zurueckschaltung falsch.

Fehlerursache konzentrieren ? Anders ausgedrückt: 868 müsste f. slowRF und RFR-Empfang unabhängig Modul/Protokoll  immer funktionieren während wir bei 433 "nur" noch testen müssten?

Dann verschiebe ich meine Prioritäten, da meine Revolts auch nach Verstärkung gieren 

Schönes Wochenende
Markus

[rudolfkoenig]

Könntest Du dazu nicht einen klitzekleinen Hinweis in die commandref einbauen oder umgekehrt eine Positivliste ?

Habe Folgendes hinzugefuegt:

In theory every SlowRF protocol should work, as the hook is implemented in the culfw output routine: instead of sending the data to the USB-Interface it is transmitted via radio to the base CUL. There are still some restrictions:
- due to the ping both CULs have to be in SlowRF mode, and use the same parameters (freq, bwidth, etc).
- the logical module handling the protocol is not allowed to access the routines of the IODev (i.e. CUL) directly.
Tested protocols are FHT, FS20, EM, HMS, S300.
Since there is no ack or a resend mechanism, it should be primarily used to forward "unimportant" data.

[KölnSolar]

Superb  Danke.

Vielleicht noch ein kurzes ja,nein, weiß nicht
zu

@Rudi: Dann müsste es ja theoretisch klappen, wenn alle von Dir genannten Bedingungen erfüllt sind bzw. man könnte sich auf diese
Zitat
- ich habe RFR nie mit 433 getestet, evtl. sind da die Wartezeiten fuer Umschaltung / Zurueckschaltung falsch.

Fehlerursache konzentrieren ? Anders ausgedrückt: 868 müsste f. slowRF und RFR-Empfang unabhängig Modul/Protokoll  immer funktionieren während wir bei 433 "nur" noch testen müssten?

[rudolfkoenig]

Weiss nicht
Theoretisch ja, aber wenn es nicht tut, bitte mich nicht schlagen.
Habe kein 433-er CUL (und 2 schon gar nicht), um es zu testen.
Und die Motivation, mich wieder mit RFR zu beschaeftigen, ist auch begrenzt. Das war damals ein "Quick-Hack", um den Sender auf dem Dach verlaesslicher zu empfangen, und wollte nicht gleich die Welt verbessern.

[KölnSolar]

Danke, ging mir nur darum, ob Du aus dem Stehgreif die "Versuch-macht-kluch"-Variante erschlägst 

Theoretisch ja, aber wenn es nicht tut, bitte mich nicht schlagen.

keine Sorge. Bei dem FHEM-Größenunterschied treffe ich gerade mal Deine Füße.

Ich probier es dann mal bei Gelegenheit.(oweh, noch was auf der FHEM-To-Do-List)