Modifikationen an der 41_OREGON.pm

[Ralf9]

Hallo,

benutzt hier noch jemand den USB-RFXCOM-Receiver?

Sidey und ich haben im SIGNALduino das Oregon v3 Protokoll implementiert.
Dazu waren einige modifikationen an der 41_OREGON.pm notwendig
https://github.com/RFD-FHEM/RFFHEM/commit/569b256b535826e735c48041c1b232193b5534ff

Könnte mal jemand testen ob die angepasste 41_OREGON.pm noch mit dem RFXCOM-Receiver funktioniert?

Die 41_OREGON.pm kann hier unter "Raw" heruntergeladen werden:
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r32/FHEM/41_OREGON.pm

Gruß Ralf

[Willi]

Hallo,

benutzt hier noch jemand den USB-RFXCOM-Receiver?

Sidey und ich haben im SIGNALduino das Oregon v3 Protokoll implementiert.
Dazu waren einige modifikationen an der 41_OREGON.pm notwendig
https://github.com/RFD-FHEM/RFFHEM/commit/569b256b535826e735c48041c1b232193b5534ff

Hallo,

erst einmal danke für die Hinweise.

Sind das alle Änderungen, die bei diesem Link angezeigt wurden, also ist das ein DIFF zu meiner letzten Version im FHEM-SVN?

Showing  1 changed file  with 25 additions and 4 deletions

OREGON war mein erster FHEM-Treiber und ist für den RFXCOM-Receiver vorgesehen. Wird seit 2010 eingesetzt. Neben mir setzen noch eine Reihe von anderen Usern den Original RFXCOM-Empfänger ein. Der ist unverwüstlich und wird vermutlich noch lange leben.....

Ich prüfe bei Gelegenheit mal alle Änderungen. Danke erst einmal dafür.

Was ich auf die Schnelle gesehen habe.

checksun ist sicherlich ein Typo.

Ich vermute, dass die Änderung der keylen bei "OREGON_type_length_key(0xea4c, 68)" nach "OREGON_type_length_key(0xea4c, 64)" nicht kompatibel ist.

Ich habe gerade mal bei http://syno.haeflinger.com/index.php/Domotique gesehen, dass dort auch beschrieben wird, dass  es bei 0xea4c 68 Bits sind. Wenn dies so sein sollte, würde ich empfehlen, dass Ihr Eure Firmware diesbezüglich so ändert, dass dieser bei diesem Gerät 'THWR288A' kompatibel mit dem Treiber wird. ich habe hier selbst leider kein entsprechendes Gerät zur Verfügung, um das zu testen, muss das also bei anderen RFXCOM-Treibern prüfen.

Die weiteren Devices wie 'THWR800' und 'RTHN318' und checksum9 hinzuzufügen, wird aber kein Problem sein, da diese bisher noch nicht vorhanden sind.
Ob die Änderung von checksum2 kompatibel mit dem RFXCOM-Receiver ist, weiss ich jetzt noch nicht. Mal sehen, ob ich Devices habe, bei der checksum2 verwendet wird.

Da ich 41_OREGON.pm von Code von Mark Hindess abgeleitet habe, muss bei diesem Modul übrigens weiter die Perl-License bleiben. GPL-License passt hier leider nicht.

Grüße

Willi

[Ralf9]

Sind das alle Änderungen, die bei diesem Link angezeigt wurden, also ist das ein DIFF zu meiner letzten Version im FHEM-SVN?

Hier ist die akuelle Version:
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r32/FHEM/41_OREGON.pm
Mit "raw" kannst Du sie downloaden und unter "history" siehst Du meine (Ralf9) änderungen. 

Ich hab noch folgende Änderungen vorgenommen:
Das log habe ich in "Log3 $iohash .." geändert, damit die verbose vom physikalischen Modul verwendet wird.
Bei der attrList habe ich " $readingFnAttributes" hinzugefügt.
Beim OREGON_Parse($$) habe ich

Code Auswählen Erweitern

Log3 $iohash, 4, "$name decoded Oregon: $val";
zugefügt.

Ich vermute, dass die Änderung der keylen bei "OREGON_type_length_key(0xea4c, 68)" nach "OREGON_type_length_key(0xea4c, 64)" nicht kompatibel ist.

evtl gibt es beim THN132N zwei Versionen. Spricht etwas dagegen beide einzutragen?

Code Auswählen Erweitern

OREGON_type_length_key(0xea4c, 64) =>
   {
    part => 'THN132N', checksum => \&OREGON_checksum1, method => \&OREGON_common_temp,
   },
OREGON_type_length_key(0xea4c, 68) =>
   {
    part => 'THN132N', checksum => \&OREGON_checksum1, method => \&OREGON_common_temp,
   },

Ob die Änderung von checksum2 kompatibel mit dem RFXCOM-Receiver ist, weiss ich jetzt noch nicht. Mal sehen, ob ich Devices habe, bei der checksum2 verwendet wird.

Falls die Änderungen nicht kompatibel sind, kann für die v3 Sensoren eine eigene checksum2 Routine erstellt werden.

Die folgenden Oregon v3 Sensoren wurden mit dem SIGNALduino erfolgreich getestet:

PCR800
THGR810
THWR800
UVN800
WGR800

Gruß Ralf

[Willi]

evtl gibt es beim THN132N zwei Versionen. Spricht etwas dagegen beide einzutragen?

Spricht nichts dagegen.

Ich habe gesehen, dass sich checksum2 von der Berechnung nicht geändert hat. Nur ein zusätzliches Logging. Die Änderung checksum8 habe ich gerade mal mit meinem PCR800 getestet. Scheint zu laufen.

Dabei habe ich festgestellt, dass total-rain beim PCR800 beim 41_OREGON.pm und 46_TRX_WEATHER.pm unterschiedliche Werte liefert. Dem werde ich nachgehen. Eine der beiden muss falsch sein. Dem gehe ich nach.

Ich muss noch das gesamte Modul testen. Leider läuft es so nicht sofort, weil ich bei meinem RFXCOM-Receiver noch eine alte FHEM-VErsion habe, die z.B. die neuen Logs nicht unterstützt. Werde ich dann per FHEM2FHEM und einem Testsystem testen. Dauert aber noch etwas.

Gruß

Willi

[Sidey]

Hallo Willi,

für einen Teil der Änderungen hatte ich schon mal patches erstellt.

Diese sind in der verlinkten Version enthalten. Zusätzlich aber auch noch weitere Anpassungen.

Hier die Links zu den Patches mit Erklärung, warum diese Änderung notwendig ist.

http://forum.fhem.de/index.php/topic,40156.msg323969.html#msg323969

http://forum.fhem.de/index.php/topic,41929.msg341622.html#msg341622

Grüße Sidey

[Willi]

Danke für die Infos. Ich teste dies und melde mich dann.

[Willi]

Ich habe seit heute einen SIGNALduino aufgebaut und kann auch meine OS V3-Sensoren empfangen.
Die OS V1 und OS V2 Sensoren werden empfangen und nicht zu HEX decodiert. Richtig?

[Ralf9]

Ich habe seit heute einen SIGNALduino aufgebaut und kann auch meine OS V3-Sensoren empfangen.
Die OS V1 und OS V2 Sensoren werden empfangen und nicht zu HEX decodiert. Richtig?

OS V2 müsste funktionieren, ich habe es mit dem THN132N getestet:

Code Auswählen Erweitern

2016.02.11 23:49:04 4: sduinoD/msg get raw: MC;LL=-992;LH=954;SL=-510;SH=425;D=AAAAAAAB332B4B4D54D4AACB5534D53555554CD532;C=459;
2016.02.11 23:49:04 4: sduinoD: Found manchester Protocol id 10 clock 459 -> OSV2o3
2016.02.11 23:49:04 4: sduinoD: OSV2 protocol detected: preamble_pos = 31
2016.02.11 23:49:04 4: sduinoD: OSV2 protocol converted to hex: (40EA4C10DF20210014) with length (72) bits
2016.02.11 23:49:04 5: sduinoD: converted Data to (40EA4C10DF20210014)
2016.02.11 23:49:04 5: sduinoD dispatch 40EA4C10DF20210014
2016.02.11 23:49:04 5: OREGON: decoding delay=0 hex=40EA4C10DF20210014
2016.02.11 23:49:04 5: OREGON: checksum1 = 64 berechnet: 64
2016.02.11 23:49:04 4: THN132N_1 decoded Oregon: T: 21.2 BAT: ok

Zu OS V1 kann ich keine Aussage machen da ich nichts zum testen hatte.

Gruß Ralf

[Willi]

Mit welchem Code hast Du das gemacht? Welche Firmware und welcher FHEM-Code (00_SIGNALduino.pm)?

Ich habe es heute mit dem 3.2er-Branch versucht (also update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt).
Bei diesem Code wird der Type bei V2 noch nicht richtig gesetzt (habe den 0a-Hack mit dem Swap dann testweise selbst eingebaut. Allerdings waren die Hexcodes meiner Oregon V2-Sensoren weder von der Länge noch vom Inhalt richtig (habe es mit 41_OREGON.pm getestet).

Teste es gerne mit meinen V2-Sensoren aus, wenn Du mir den Code gibst.

Habe ich ganz vergessen: Euer Projekt ist wirklich toll. Da habt Ihr etwas tolles geschaffen. Den Code für die Decodierung aus der Firmware auszulagern ist eine tolle Idee.

[Ralf9]

Mit welchem Code hast Du das gemacht? Welche Firmware und welcher FHEM-Code (00_SIGNALduino.pm)?
Ich habe es heute mit dem 3.2er-Branch versucht (also update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt).

Damit müsstest Du die neuste Version haben.
Ich habe vor ein paar Tagen noch was in der 41_OREGON.pm geändert:
Die restlichen log auf "Log3 $hash, " geändert und die Attribute aktualisiert.
Dies müsste in Deiner Version enthalten sein.
https://github.com/RFD-FHEM/RFFHEM/commit/d20550e92abdcf13c7c9154d3c894409bc44ead4

Bei diesem Code wird der Type bei V2 noch nicht richtig gesetzt (habe den 0a-Hack mit dem Swap dann testweise selbst eingebaut. Allerdings waren die Hexcodes meiner Oregon V2-Sensoren weder von der Länge noch vom Inhalt richtig (habe es mit 41_OREGON.pm getestet).

Ich hatte angenommen, daß wenn es mit dem RTHN318 und THN132N funktioniert, daß dann auch die anderen V2 Sensoren funktionieren.
Ich möchte es mir mal anschauen. Hast Du mir von Deinen V2 Sensoren jeweils den Namen und die raw Nachricht. Schön wären auch zum Vergleich die per dispatch übergebenen Hex Daten vom RFXCOM-Receiver/Modul.

Das hier ist z.B. eine raw Nachricht:
MC;LL=-992;LH=954;SL=-510;SH=425;D=AAAAAAAB332B4B4D54D4AACB5534D53555554CD532;C=459;

Gruß Ralf

[Willi]

Danke! Du hast eine PM.