SIGNALDuino Oregon Sensoren

Sidey · 18 November 2016, 23:09:15

Zitat von: Ralf9 am 18 November 2016, 20:03:21
@hdp1999
Bei den Nachrichten bei denen die Länge (88 Bit) vorher schon gepasst hat, hat sich nichts geändert, das achte Bit der checksum ist immer noch 1.

Da bin ich noch am suchen. Um welches bit oder Nibble geht es denn da genau?
Kannst Du die korrekte Ausgabe ermitteln, dann komme ich ja auch drauf.

Zitat von: Ralf9 am 18 November 2016, 21:49:46
ja, das sieht jetzt recht gut aus.
Beim RGR918 ist mir aufgefallen, das es Nachrichten mit 80 und mit 88 Bit gibt.
Wenn ich die 41_OREGON.pm anpasse, damit auch 4- und 8 Bit längere Nachrichen verarbeitet werden, dann müsste es passen

Hmm, sendet das Gerät tatsächlich in variabler Länge oder ist das auch ein Konvertierungsproblem?

Einfacher, als den Code zu verändern ist es vielleicht weitere "Typen" zu definieren.

Code Auswählen

   # RGR126, RGR682, RGR918:
   OREGON_type_length_key(0x2a1d, 84) =>
   {
    part => 'RGR918', checksum => \&OREGON_checksum6plus, method => \&OREGON_common_rain,
   },

Mich würde das aber mal eher interessieren, was da mit der Länge passiert.

Ralf9 · 18 November 2016, 23:44:07

Zitat von: Sidey am 18 November 2016, 23:09:15
Da bin ich noch am suchen. Um welches bit oder Nibble geht es denn da genau?
Kannst Du die korrekte Ausgabe ermitteln, dann komme ich ja auch drauf.

Beim OSV2 werden die Nachrichen ja doppelt gesendet. Es sieht so aus, daß bei der 1.Nachricht die checksumme falsch ist (achte Bit ist 1),
Bei der Nachrichten wiederholung passt es dann.
Die checksumme ist das letzte Byte der Nachricht, siehe auch meine Nachriicht um 20:03

Zitat
Hmm, sendet das Gerät tatsächlich in variabler Länge oder ist das auch ein Konvertierungsproblem?

80 Bit

Code Auswählen

2016.11.18 23:32:43.983 4: sduinoD/msg get raw: MC;LL=-1022;LH=930;SL=-482;SH=477;D=555555553332CD4AAAAACB4D2AAAAAAAB4B2CAAAAAD532ACD5;C=485;L=200;
2016.11.18 23:32:43.983 5: sduinoD: extracted data 10101010101010101010101010101010110011001100110100110010101101010101010101010101001101001011001011010101010101010101010101010101010010110100110100110101010101010101010100101010110011010101001100101010 (bin)
2016.11.18 23:32:43.983 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.18 23:32:43.983 4: sduinoD: OSV2 protocol converted to hex: (502A1D00D900002601F042) with length (88) bits
2016.11.18 23:32:43.983 5: sduinoD dispatch 502A1D00D900002601F042
2016.11.18 23:32:43.983 5: OREGON: decoding delay=7773.79730415344 hex=502A1D00D900002601F042
2016.11.18 23:32:43.983 5: OREGON: sensor_id=2a1d BitsMsg=80 Bits=80
2016.11.18 23:32:43.983 5: OREGON: checksum6plus = 47 berechnet: 47
2016.11.18 23:32:43.983 4: RGR918_d9 decoded Oregon: RR: 0 TR: 12  BAT: ok

88 Bit

Code Auswählen

2016.11.18 21:23:10.185 4: sduinoD/msg get raw: MC;LL=-1003;LH=951;SL=-519;SH=438;D=AAAAAAA999966A5555565A6955555555A596555556A99566A8;C=485;L=197;
2016.11.18 21:23:10.185 5: sduinoD: extracted data 01010101010101010101010101010110011001100110100110010101101010101010101010101001101001011001011010101010101010101010101010101010010110100110100110101010101010101010100101010110011010101001100101010111 (bin)
2016.11.18 21:23:10.185 4: sduinoD: OSV2 protocol detected: preamble_pos = 30
2016.11.18 21:23:10.185 4: sduinoD: OSV2 protocol converted to hex: (582A1D00D900002601F0421F) with length (96) bits
2016.11.18 21:23:10.186 5: sduinoD dispatch 582A1D00D900002601F0421F
2016.11.18 21:23:10.186 5: OREGON: decoding delay=64.0551729202271 hex=582A1D00D900002601F0421F
2016.11.18 21:23:10.186 5: OREGON: sensor_id=2a1d BitsMsg=88 Bits=80
2016.11.18 21:23:10.186 5: OREGON: checksum6plus = 47 berechnet: 47
2016.11.18 21:23:10.186 4: RGR918_d9 decoded Oregon: RR: 0 TR: 12  BAT: ok

Sidey · 19 November 2016, 00:22:55

Ich habe den Fix von Gestern noch mal etwas verfeinert.

Mal sehen ob das Nebenwirkungen hat. Sollte eigentlich nicht so sein.

Grüße Sidey

Ralf9 · 19 November 2016, 01:21:52

Ja, sieht gut aus. Beim BTHR918 passt jetzt auch die erste Nachricht.
Beim RGR918 mit der Länge 88 Bit sind es jetzt 84 Bit geworden.

Code Auswählen

2016.11.19 01:10:07.040 4: sduinoD/msg get raw: MC;LL=-1003;LH=951;SL=-519;SH=438;D=AAAAAAA999966A5555565A6955555555A596555556A99566A8;C=485;L=197;
2016.11.19 01:10:07.041 5: sduinoD: extracted data 01010101010101010101010101010110011001100110100110010101101010101010101010101001101001011001011010101010101010101010101010101010010110100110100110101010101010101010100101010110011010101001100101010111 (bin)
2016.11.19 01:10:07.041 4: sduinoD: OSV2 protocol detected: preamble_pos = 30
2016.11.19 01:10:07.041 4: sduinoD: OSV2 protocol converted to hex: (542A1D00D900002601F042F) with length (92) bits
2016.11.19 01:10:07.041 5: sduinoD dispatch 542A1D00D900002601F042F
2016.11.19 01:10:07.041 5: OREGON: decoding delay=448.332516908646 hex=542A1D00D900002601F042F
2016.11.19 01:10:07.041 5: OREGON: sensor_id=2a1d BitsMsg=84 Bits=80
2016.11.19 01:10:07.041 5: OREGON: checksum6plus = 47 berechnet: 47
2016.11.19 01:10:07.041 4: RGR918_d9 decoded Oregon: RR: 0 TR: 12  BAT: ok

ZitatEinfacher, als den Code zu verändern ist es vielleicht weitere "Typen" zu definieren.

Die Codeänderung hat auch den Vorteil, daß die %types übersichtlicher wird, da ich dann einige doppelte Typen entfernen kann.
Und ich muss zukünftig keine weiteren doppelten Typen mehr zufügen falls weitere Sensoren mit zu langer Nachricht auftauchen.

Gruß Ralf

Sidey · 19 November 2016, 08:45:15

Super, die Änderung hat den Anspruch, die Anpassungen im Oregon Modul überflüssig zu machen...

Soweit das halt geht.

hdp1999 · 19 November 2016, 09:13:49

anbei noch mal ein Log File nach den letzten Änderungen von heute Morgen ! Sieht soweit gut aus !
Ich benutze im Moment die Oregon.pm aus der rev33 ohne Änderungen ! Wenns so bleibt

Gruß Dirk

Ralf9 · 19 November 2016, 11:32:44

Zitat von: Sidey am 19 November 2016, 08:45:15
Super, die Änderung hat den Anspruch, die Anpassungen im Oregon Modul überflüssig zu machen...

Soweit das halt geht.

Die Probleme mit den zu kurzen Nachrichten und dem achten Bit der Checksumme sind damit behoben.
Bei 3 Sensoren sind die Nachrichten noch zu lang.
Ich habe die 41_OREGON.pm ergänzt, damit auch um 4- und 8 Bit längere Nachrichten verarbeitet werden. Die Änderung ist in der dev-r33 enthalten.
Ich habe auch das log ergänzt. Dabei ist BitsMsg die Länge der empfangenen Nachricht und Bits die Länge im Oregon Modul.

Code Auswählen

OREGON: sensor_id=2a1d BitsMsg=84 Bits=80

Code Auswählen

2016.11.19 09:51:09.865 4: sduinoD/msg get raw: MC;LL=-1036;LH=913;SL=-541;SH=398;D=AAAAAAAA99A6669A5555569A995A5A65555596555565A556A95A55A90;C=479;L=225;
2016.11.19 09:51:09.865 5: sduinoD: extracted data 010101010101010101010101010101010110011001011001100110010110010110101010101010101010100101100101011001101010010110100101100110101010101010101010011010011010101010101010100110100101101010101001010101101010010110101010010101101111 (bin)
2016.11.19 09:51:09.865 4: sduinoD: OSV2 protocol detected: preamble_pos = 34
2016.11.19 09:51:09.865 4: sduinoD: OSV2 protocol converted to hex: (605A6D00EC6216800490C16338) with length (104) bits
2016.11.19 09:51:09.879 5: OREGON: decoding delay=0 hex=605A6D00EC6216800490C16338
2016.11.19 09:51:09.879 5: OREGON: sensor_id=5a6d BitsMsg=96 Bits=88
2016.11.19 09:51:09.879 4: BTHR918N_ec decoded Oregon: T: 16.6 H: 48 P: 1000  BAT: ok

2016.11.19 09:54:15.280 4: sduinoD/msg get raw: MC;LL=-1083;LH=885;SL=-525;SH=395;D=55555555334CCD34AAAAAD3532B4B4CAAAAB2CAAAACB4AAD52B4A;C=480;L=211;
2016.11.19 09:54:15.280 5: sduinoD: extracted data 10101010101010101010101010101010110011001011001100110010110010110101010101010101010100101100101011001101010010110100101100110101010101010101010011010011010101010101010100110100101101010101001010101101010010110101 (bin)
2016.11.19 09:54:15.280 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.19 09:54:15.280 4: sduinoD: OSV2 protocol converted to hex: (585A6D00EC6216800490C163) with length (96) bits
2016.11.19 09:54:15.280 5: OREGON: decoding delay=186 hex=585A6D00EC6216800490C163
2016.11.19 09:54:15.280 5: OREGON: sensor_id=5a6d BitsMsg=88 Bits=88
2016.11.19 09:54:15.281 4: BTHR918N_ec decoded Oregon: T: 16.6 H: 48 P: 1000  BAT: ok

2016.11.19 10:05:51.048 4: sduinoD/msg get raw: MC;LL=-996;LH=963;SL=-513;SH=437;D=555555553352CD2AAAAACB552AAAD4CAACCAAAAAAAAACCD2B533;C=484;L=208;
2016.11.19 10:05:51.048 5: sduinoD: extracted data 1010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010101010101001010110011010101010011001101010101010101010101010101010101010100110011001011010100101011001100 (bin)
2016.11.19 10:05:51.048 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.19 10:05:51.048 4: sduinoD: OSV2 protocol converted to hex: (583A0D00F9001714000035AE) with length (96) bits
2016.11.19 10:05:51.048 5: OREGON: decoding delay=158 hex=583A0D00F9001714000035AE
2016.11.19 10:05:51.048 5: OREGON: sensor_id=3a0d BitsMsg=88 Bits=80
2016.11.19 10:05:51.048 4: WGR918_f9 decoded Oregon: W: 1.4 WA: 0 WD: 170  WDN: SSE  BAT: ok

2016.11.19 10:11:55.777 4: sduinoD/msg get raw: MC;LL=-1042;LH=963;SL=-509;SH=439;D=AAAAAAAA999966A5555565A6955555555A69655555556969598;C=492;L=201;
2016.11.19 10:11:55.777 5: sduinoD: extracted data 010101010101010101010101010101010110011001100110100110010101101010101010101010101001101001011001011010101010101010101010101010101010010110010110100110101010101010101010101010101001011010010110101001100111 (bin)
2016.11.19 10:11:55.777 4: sduinoD: OSV2 protocol detected: preamble_pos = 34
2016.11.19 10:11:55.777 4: sduinoD: OSV2 protocol converted to hex: (542A1D00D9000036010033A) with length (92) bits
2016.11.19 10:11:55.777 5: OREGON: decoding delay=46 hex=542A1D00D9000036010033A
2016.11.19 10:11:55.777 5: OREGON: sensor_id=2a1d BitsMsg=84 Bits=80
2016.11.19 10:11:55.777 5: OREGON: checksum6plus = 48 berechnet: 48
2016.11.19 10:11:55.778 4: RGR918_d9 decoded Oregon: RR: 0 TR: 13  BAT: ok

Ich habe auch im state den Luftdruck ergänzt. Dieser war vorher deaktiviert. Weiß jemand was hms.gplot ist?

Code Auswählen

# do not add it due to problems with hms.gplot
#$val .= "P: ".$i->{current}."  ";

Gruß Ralf

hdp1999 · 19 November 2016, 12:15:35

Hallo Ralf

habe die geänderte Oregon genommen und lasse jetzt mal laufen !

Willst du davon auch ein Log haben ?

Gruß Dirk

Ralf9 · 19 November 2016, 14:20:14

Zitat von: hdp1999 am 19 November 2016, 12:15:35
Willst du davon auch ein Log haben ?

Ja, kannst nochmals ein log von ca 20-30 Min anhängen

Sidey · 19 November 2016, 14:38:15

Vielleicht finde ich ja noch heraus, warum es Nachrichten mit 4 / 8 Bit mehr gibt.

hdp1999 · 19 November 2016, 17:23:23

Kein Problem ! Log läuft schon !!

Kann mir evt einer sagen warum auf dem FHEMduino der WGR918 und die BTHR918 und BTHR918N nicht decodiert werden ?

Gruß Dirk

hdp1999 · 19 November 2016, 17:43:07

Zitat von: hdp1999 am 19 November 2016, 17:23:23
Kein Problem ! Log läuft schon !!

Kann mir evt einer sagen warum auf dem FHEMduino der WGR918 und die BTHR918 und BTHR918N nicht decodiert werden ?

Gruß Dirk

anbei das LOG von 17:15 bis 17:40 !!

Ralf9 · 19 November 2016, 18:31:29

Ich habe mir das log mal angeschaut, sieht jetzt recht gut aus. Das müsstest Du auch in Deinen filelogs erkennen können, daß die Sensoren jetzt recht gut decodiert werden.

Gruß Ralf

hdp1999 · 20 November 2016, 12:09:13

Hallo Ralf ,

ja ist bis jetzt das beste Ergebniss was ich mit den Oregon Sensoren erhalten habe ! Schöne Kurven im Plot ! Danke nochmals für den Support !

Frage zum FHEMduino wird da noch etwas gemacht oder ist der Signalduino der Nachfolger ?

Gruß Dirk

Sidey · 20 November 2016, 15:09:32

Also ich habe damals den Oregon Support in den Fhemduino eingebaut.
Ich mache aber nichts mehr am Fhemduino, da ich ja den SIGNALduino entwickelt habe.