Befehlsreferenz für RFXtrx433-USB gesucht

Begonnen von ext23, 25 Dezember 2012, 00:12:33

Vorheriges Thema - Nächstes Thema

ext23

Hallo,

ich habe heute mein RFXtrx433 bekommen, nettes Teil, doch um einiges besser als meine selbst gebaute Variante (//images/smiley_icons/icon_smile.gif)

Eine Frage, gibt es für das Teil eine Befehlsreferenz? Ich meine da werden wild hex Codes ausgetauscht aber ist irgendwie auch das Protokoll erklärt? Jetzt alles aus den Beispiel Programmen zu saugen ist ja nun auch nicht unbedingt der Hit.
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Willi

Zitat von: ext23 schrieb am Di, 25 Dezember 2012 00:12Eine Frage, gibt es für das Teil eine Befehlsreferenz? Ich meine da werden wild hex Codes ausgetauscht aber ist irgendwie auch das Protokoll erklärt? Jetzt alles aus den Beispiel Programmen zu saugen ist ja nun auch nicht unbedingt der Hit.

Hallo,

klar gibt es die. Heisst bei RFXCOM SDK.

Wenn Du selbst mit dem RFXtrx433 programmieren willst, ist das kein Problem. Auf der Homepage steht:  "Developers can request the free SDK at support"

Frag also einfach beim Support bei RFXCOM nach. Anscheinend willst Du selbst programmieren, sonst bräuchtest Du dies ja nicht.

Ich freue mich, wenn Du mich bei den FHEM-Treibern oder beim Support unterstützen willst oder sogar zukünftig die Weiterentwicklung bzw. Support übernehmen willst. Oder hast Du ein anderes Projekt abseits von FHEM im Auge?

MfG Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

ext23

Danke Willi, dann werde ich da mal anfragen.

Und ich möchte erstmal das Teil verstehen und dazu zählt auch die Kommunikation ;-) Ich hatte ja nun sowas selber gebaut und da interessiert mich das eben (//images/smiley_icons/icon_smile.gif) Auch falls man das Teil mal außerhalb FHEM einsetzt. Ich bin nur im Moment ein bissel überrascht das ich 6 Temperatur Sensoren empfange die alle nicht von mir stammen, oder die Stasi 2.0 hat hier was versteckt. Und das müssen Sender sein die eine recht gute Leistung haben, weil meine eigenen beiden empfängt der nur sporadisch wenn die Fenster auf sind (Das Glas ist gier heftig).

Ich mag eben wissen was da abgeht bei der Kommunikation. Gerade bei HomeEasy braucht das Teil ja theoretisch auch eine eigene ID die er mitsendet und die auch angelernt sein muss beim Aktor. Und das möchte ich eben alles wissen wie man den Befehlsstring dazu generiert.

Achso und, hier gab es doch an anderer Stelle die Diskussion mit dem Empfang der Mäuseklavier Fernbedienungen von H+H bzw. Elro etc. Der RFXTRX433 empfängt ja alles sauber, ist dann eben uncodiert, aber egal, das sollte man mit FHEM doch auch umsetzen können. Ich denke mir das so:

Da es ja dieser Überschneidung gibt wegen Drehschalter Geräte und Mäuseklavier Geräte, warum kann man das nicht so umgehen indem man diese Protokolle alle auf disabled setzt damit man ein einheitliches undecodedes Format hat und die Auswertung bzw. Decodierung mit FHEM macht und bei FHEM stellt man dann eben beim Gerät als attr ein ob das ein Drehschalter oder Mäuseklavier Gerät ist. Wäre sowas in die Richtung nicht auch machbar?

Das Problem ist doch hier nur das der USB Dongle nicht weiß was er da gerade empfängt und es deswegen nicht richtig decodiert, aber wenn ich ihm sage was es ist (was aber nicht geht) sollte es doch gehen, und genau das muss eben FHEM dann übernehmen.

Viele Grüße

achso und FROHE WEIHNACHTEN!!! HO HO HO (//images/smiley_icons/icon_smile.gif)
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Willi

Hmm. Nette Idee mit dem Disablen der Protokolle.
Hast Du das mal mit RFXmngr ausprobiert?
Ich hatte angenommen, dass beim Disable eines Protokolls dieses nicht als UNDEC auftaucht. Man hat es ja ausgeschaltet.
Erzähl mal, wenn Du das getestet hast.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

ext23

Da hast du leider recht, wenn man AC und ARC deaktiviert kommt garnichts mehr an, das ist natürlich dumm und schade.

Aber ich meine das wäre natürlich auch mal ein Feature von RFXCOM das man pro Protokoll angeben kann ob es decodiert wird oder als RAW durch gereicht wird.

Naja dann hat sich der Gedanke also auch erledigt... schade

Aber ich lese hier gerade "This parameter is for internal use by RFXCOM." Mhh also ich finde das nicht unbedingt nur für interne Zwecke wichtig.
Ich weiß ja nicht wie schwer es für dich ist das in dem Modul umzusetzen, aber so wie ich das oben geschrieben habe wäre es ja theoretisch auch sinnvoll bestimmte Protokolle über die Anwendung zu interpretieren. Gerade bei solchen Fällen wie wir es hier mit dieser Überschneidung aufn Tisch haben. Vielleicht sollte man damit wirklich mal bei RFXCOM vorsprechen. Nichts gegen diese Fernbedienungs Anpassungen die hier beschrieben wurden, aber eine saubere Lösung sieht anders aus ;-)

Ich könnt mich immer noch beäumeln das ich hier mehrere Wetter Sensoren empfange die mir nicht gehören, ich frage mich wozu ich eigene gekauft habe ;-) Das Teil ist wirklich eine feine Sache, naja fast ;-)
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)