SIGNALDuino Oregon Sensoren

Ralf9 · 04 November 2016, 17:59:00

Vom SIGNALDuino werden die Oregon Sensoren Version 2 und 3 unterstützt.
Dazu ist das angepasste 41_OREGON.pm Modul vom dev-Branch erforderlich

Ralf9 · 04 November 2016, 18:17:09

Zitat von: hdp1999 am 24 Oktober 2016, 16:23:26
Hallo

Habe mal eine Frage !
Ich versuche mit dem Signalduino meine Oregon Wetter Sensoren zu empfangen ! Klappt alles wunderbar!
Nach Änderung in der 41_Oregon.pm beim BTHR918N Checksummer auf 88 gesetzt klappt es mit dem Sensor auch super !
Nur 1 Sensor der BTHR 918 ohne N wird nicht oder nur alle 4-8 Stunden einmal richtig empfangen !
Es kommt immer die Fehlermeldung OREGON: ERROR: checksum error sensor_id=5a5d (bits=88).Diese dauerhaft alle 2-4 Minuten in LOG .

Meine anderen Sensoren werden 100 % empfangen

BTHR918N_0f T: 18.3 H: 47 BAT: ok

RGR918_7d RR: 0 TR: 1077 F: 4 BAT: ok

THGR228N_30_1 T: 22.3 H: 46 BAT: low

THGR228N_84_2 T: 22.6 H: 43 BAT: ok

THGR228N_a6_4 T: 21.4 H: 42 BAT: low

THGR918_08_1 T: 8.8 H: 83 BAT: ok

WGR918_a9 W: 1 WA: 1 WD: 40 WDN: NNE BAT: ok

selbst der Windmesser wo Ich immer mit einem FHEMduino in einem anderm System Probleme hatte klappt Perfekt !

Ich nutze die letzte Firmware des Signalduino
V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28

Was kann das sein ??

Gruß Dirk

Zitat von: hdp1999 am 24 Oktober 2016, 20:18:08
Hallo Ralf

Danke erstmal das du mal drüberschaust ! Habe jetzt die Aktuelle 41_Oregon.pm Muße aber auch hier die Checksumme für den 918N ändern da sonst der nicht dekodiert wird.

Anbei ein Auszug aus mein Log !

BTHR918
2016.10.24 20:00:30 4: sduino/msg READ: MC;LL=-983;LH=985;SL=-474;SH=475;D=AAAAAAAA99A666A6555555A6555A5959556A565656A69A5556A60;C=486;L=209;
2016.10.24 20:00:30 4: sduino/msg READ: MC;LL=-995;LH=1012;SL=-453;SH=478;D=55555555334CCD4CAAAAAB4CAAB4B2B2AAD4ACACAD4D34AAAD4C;C=489;L=208;
2016.10.24 20:01:08 4: sduino/msg READ: MC;LL=-998;LH=1012;SL=-457;SH=473;D=AAAAAAAA99A666A6555555A6556A5959556A565656A69A5566A60;C=489;L=209;
2016.10.24 20:01:08 4: sduino/msg READ: MC;LL=-992;LH=1028;SL=-468;SH=471;D=55555555334CCD4CAAAAAB4CAAD4B2B2AAD4ACACAD4D34AACD4C;C=493;L=208;

BTHR918N

918N nach Änderung in 41_Oregon.pm Checksumme auf 88

2016.10.24 20:00:25 4: sduino/msg READ: MC;LL=-1024;LH=964;SL=-520;SH=402;D=55555555334CCD34AAAAD52AAAACAAB2AAAAACAB4D4B4AB4B4CCB0;C=483;L=213;
2016.10.24 20:00:25 4: sduino: Found manchester Protocol id 10 clock 483 -> OSV2o3

2016.10.24 20:00:25 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.10.24 20:00:25 4: sduino: OSV2 protocol converted to hex: (585A6D000F402000849D6156) with length (96) bits
2016.10.24 20:00:25 5: sduino: converted Data to (585A6D000F402000849D6156)
2016.10.24 20:00:25 5: sduino dispatch 585A6D000F402000849D6156
2016.10.24 20:00:25 5: OREGON: decoding delay=19 hex=585A6D000F402000849D6156
2016.10.24 20:00:25 4: BTHR918N_0f decoded Oregon: T: 20.4 H: 40 BAT: ok
2016.10.24 20:00:25 5: Triggering BTHR918N_0f (6 changes)
2016.10.24 20:00:25 5: Starting notify loop for BTHR918N_0f, first event temperature: 20.4
2016.10.24 20:00:25 4: sduino: Found manchester Protocol id 12 clock 483 -> Hideki protocol

Falls du noch mehr Infos benötigst kein Problem !!

Ach ja auf einem 2 PI mit FHEMDUINO läuft der Sensor ohne Probleme , dafür andere nicht !Das ist mit ein Grund warum Ich auf Signalduino umstellen möchte ! Ebenso an meiner Original Wetterstation von Huger keine Probleme mit dem Sensor !

Gruß Dirk

Ralf9 · 04 November 2016, 18:43:17

Zitat von: Sidey am 25 Oktober 2016, 07:19:30
Kannst Du den Fhemduino und den SIGNALduino gleichzeitig Betreibern? Mich würde interessieren, was der FHEMduino weitergibt und zeitgleich was der Signalduino übergibt.

In beiden Fällen werden die Daten an das Oregon Modul übergeben, das hatte ich beim Fhemduino damals auch eingebaut. Dort sollte also kein Unterschied sein.

Zitat von: Sidey am 25 Oktober 2016, 17:11:56
Kannst Du die Logs gleichzeitig machen?

Mich würde interessieren, wie die Daten der gleichen Übertragung verarbeitet werden.

Zweimal, ist normal bei dem Protokoll.

Grüße Sidey

Zitat von: Ralf9 am 25 Oktober 2016, 18:11:30
im Anhang ist das angepasste Oregon Modul
Bitte auch mal testen ob der Druck im plot sauber angezeigt wird.
Im Modul war der Druck beim state auskommentiert:
Code Auswählen Erweitern
# do not add it due to problems with hms.gplot $val .= "P: ".$i->{current}." ";

Gruß Ralf

Beim Vergleichen der logs vom FHEMduino und sduino vom BTHR918 fällt auf, daß es bis auf das letzte Byte (checksum) gleich ist.
Die checksum vom sduino ist um 0x80 zu hoch:

Code Auswählen

585A5D005850224044E40C57  FHEMduino
585A5D005850224044E40CD7  sduino

Zitat von: hdp1999 am 26 Oktober 2016, 06:23:46
Moin Ralf ,

habe es über Nach mal laufen lassen ! Sieht soweit gut aus ! Mega großes Danke dafür !

Was mir allerdings aufgefallen ist das die THGR228N nicht mehr so oft Empfangen werden wie in Vergleich zu meiner alten 41_Oregon.pm habe für die Sensoren die alte Checksummenberechnung eingefügt !

sub OREGON_checksum2plus {
$_[0]->[8] == ((OREGON_nibble_sum(8,$_[0]) - 0xa) & 0xff);
}

Damit laufen die THGR228 auch bei mir wieder in 3 Min Takt !

Gruß Dirk

Ralf9 · 04 November 2016, 18:44:33

Zitat von: hdp1999 am 26 Oktober 2016, 06:23:46
Was mir allerdings aufgefallen ist das die THGR228N nicht mehr so oft Empfangen werden wie in Vergleich zu meiner alten 41_Oregon.pm habe für die Sensoren die alte Checksummenberechnung eingefügt !

Kannst Du vom THGR228N einige RAW Nachrichten posten?

Ich habe die Checksum Routine vom BTHR918 nochmals angepasst

Code Auswählen

sub OREGON_checksum5plus {
  my $hash = $_[1];
  my $c = ($_[0]->[10]) & 0x7f;
  my $s = ((OREGON_nibble_sum(10,$_[0]) - 0xa) & 0x7f);
  Log3 $hash, 5, "OREGON: checksum5plus = $c berechnet: $s";
  $s == $c;
}

Damit wird für die Checksum nur noch 7 Bit verwendet.
So wies aussieht ist beim Signalduiono das achte Bit der checksum immer 1. Beim Fhemduino passt es.

@Sidey
Mir ist beim BTHR918 aufgefallen, daß bei den Nachrichen, die mit AAAA anfangen, die Länge passt (88 Bit)

Code Auswählen

MC;LL=-953;LH=1077;SL=-420;SH=517;D=AAAAAAA99A666A6555555A65566595955565656565A96956A660;C=494;L=205;

Die Nachrichen die mit 555555 sind zu kurz (80 Bit)

Code Auswählen

MC;LL=-953;LH=1078;SL=-400;SH=522;D=55555555334CCD4CAAAAAB4CAACCB2B2AAACACACACB52D2AD4CC;C=492;L=208;

Gruß Ralf

Ralf9 · 04 November 2016, 18:45:07

Zitat von: hdp1999 am 27 Oktober 2016, 17:01:08
Hallo Ralf

Habe in Anhang noch einige RAW Nachrichten für den THGR228N mitgeschnitten ! Mit der Änderung der Checksumme habe Ich eingefügt und teste ! Falls du noch andere RAW Daten der Sensoren von Oregon haben möchtest sag bescheid !

Gruß Dirk

Ralf9 · 04 November 2016, 18:58:46

Zitat von: hdp1999 am 26 Oktober 2016, 06:23:46
Was mir allerdings aufgefallen ist das die THGR228N nicht mehr so oft Empfangen werden wie in Vergleich zu meiner alten 41_Oregon.pm habe für die Sensoren die alte Checksummenberechnung eingefügt !

sub OREGON_checksum2plus {
$_[0]->[8] == ((OREGON_nibble_sum(8,$_[0]) - 0xa) & 0xff);
}

Damit laufen die THGR228 auch bei mir wieder in 3 Min Takt !

Dies dürfte eigentlich keinen Unterschied machen, die beiden checksum2 Routinen sind gleich, sie sind nur etwas anders geschrieben.

Code Auswählen

sub OREGON_checksum2 {
  my $hash = $_[1];
  my $c = $_[0]->[8];
  my $s = ((OREGON_nibble_sum(8,$_[0]) - 0xa) & 0xff);
  Log3 $hash, 5, "OREGON: checksum2 = $c berechnet: $s";
  $s == $c;
}

Kannst Du auch mal beim BTHR918N den Fhemduino und den SIGNALduino gleichzeitig betreiben? Mich würde interessieren, was der FHEMduino weitergibt und zeitgleich was der Signalduino übergibt.

Gruß Ralf

stefanru · 11 November 2016, 12:27:07

Hallo,

ich habe eine Frage zum Oregon im SIGNALDuino.
Ich empfange meinen Oregon Wetter Sensor nicht, bzw. er wird nicht erkannt.
Wie ich merken kann ob es ein empfangs oder ein decodier Problem is ist mir nicht ganz klar.

Da aber mein selbstbau CUL und der Raspberry mit pilight ihn empfangen gehe ich von einem decodier Problem aus.

Habe hier gelesen dass Puffer Werte nicht stimmen.
https://github.com/RFD-FHEM/SIGNALDuino/issues/32

Am Ende dieses git bugs steht dass es in DEV-r32 enthalten wäre.
Das sehe ich aber nicht. In 41_OREGON.pm steht:
# BTHR918N, BTHR968
OREGON_type_length_key(0x5a6d, 96) =>
{
part => 'BTHR918N', checksum => \&OREGON_checksum5, method => \&OREGON_alt_temphydrobaro,
},

Das muss doch angeblich 88 sein?

Ich verwende sogar dev_r33_flamenco wegen den Rauhmeldern, aber auch hier ist die 41_OREGON.pm ohne den fix.

Soll ich die Änderungen die im bug beschrieben sind einfach lokal auf dem Raspberry machen?

Also:
OREGON_type_length_key(0x5a6d, 88) =>
{
part => 'BTHR918N', checksum => \&OREGON_checksum5, method => \&OREGON_alt_temphydrobaro,
},

Und:
# WTGR800 Temp hydro v3
OREGON_type_length_key(0xfab8, 84) =>

Bekomme demnächst noch einen Adurino, dort werde ich noch ein FHEMduino draus machen.
Dann kann ich gern mal beides laufen lassen.
Zur Zeit empfange ich den Oregon sensor mit CUL. Kann ich dort auch ein daten log für dich ziehen?

Gruß,
Stefan

stefanru · 11 November 2016, 13:08:28

Ok,

es scheint sich etwas anders zu verhalten.

Ich habe sowohl ein sduino als auch ein CUL am FHEM.

erkannt wurde der Sensor vom CUL und dieses Device angelegt:
THGR228N_ac_1

Ändere ich das IODEV auf sduino eird fleisig aktualisiert.
Ändere ich zurück auf CUL geht es auch.

Scheinbar ist der DEF name das wichtige Attribut.
Ist es möglich die Sensordaten für das Device THGR228N_ac_1 vom CUL und vom sduino zu empfangen und anzuzeigen?

Ich möchte einfach erstmal herausfinden welcher empfänger die bessere Reichweite hat.

Gruß,
Stefan

Ralf9 · 11 November 2016, 18:14:22

Zitat von: stefanru am 11 November 2016, 13:08:28
Ist es möglich die Sensordaten für das Device THGR228N_ac_1 vom CUL und vom sduino zu empfangen und anzuzeigen?

Ja, das müsste gehen, wenn Du beim CUL die longids setzt und beim sduino die longids löscht.

ZitatSoll ich die Änderungen die im bug beschrieben sind einfach lokal auf dem Raspberry machen?

Also:
OREGON_type_length_key(0x5a6d, 88) =>
{
part => 'BTHR918N', checksum => \&OREGON_checksum5, method => \&OREGON_alt_temphydrobaro,
},

Ja, Du kannst die Änderung bei Dir lokal machen.

Kannst Du vom WTGR800 ein paar raw Nachrichten (MC;LL=-1010;LH=9..) posten?

Gruß Ralf

Ralf9 · 11 November 2016, 20:26:53

Ich habe mir das Problem mit den unterschiedlichen Längen nochmals angeschaut.

Code Auswählen

THN132N  0xea4c  Länge 64 und 68

WGR918   0x3a0d  Länge 80 und 88

RGR918   0x2a1d  Länge 80 und 84

BTHR918N 0x5a6d  Länge 88 und 96

Am einfachsten dürfte es sein in der sub OREGON_Parse($$) dies zu erweitern:

Code Auswählen

  my $key = OREGON_type_length_key($type, $bits);

  my $rec = $types{$key} || $types{$key&0xfffff};
   unless ($rec) {
         Log3 $iohash, 4, "OREGON: ERROR: Unknown sensor_id=$sensor_id bits=$bits message='$msg'.";
          return "OREGON: ERROR: Unknown sensor_id=$sensor_id bits=$bits.\n";
     }

in so ungefähr:

Code Auswählen

  
  my $key = OREGON_type_length_key($type, $bits);
  my $rec = $types{$key} || $types{$key&0xfffff};
  if (!$rec) {
     $key = OREGON_type_length_key($type, $bits-4);
     $rec = $types{$key} || $types{$key&0xfffff};
     if (!$rec) {
          $key = OREGON_type_length_key($type, $bits-8);
          $rec = $types{$key} || $types{$key&0xfffff};
          if (!$rec) {
               Log3 $iohash, 4, "OREGON: ERROR: Unknown sensor_id=$sensor_id bits=$bits message='$msg'.";
               return "OREGON: ERROR: Unknown sensor_id=$sensor_id bits=$bits.\n";
          }
     }
  }

@Sidey
hast Du eine bessere Idee wie man das Problem mit den unterschiedlichen Längen lösen könnte?

Gruß Ralf

stefanru · 11 November 2016, 21:18:46

Hi Ralf,

danke für die schnelle Antwort! Das ist ja super support.
Ich habe gemerkt dass es bei mir nicht an den Längen liegt. Mein Sensor wird nämlich mit THGR228N_ac_1 erkannt.

Ich hätte noch eine Frage zu den LongIDs.
Habe jetzt wie von dir vorgeschlagen beim sduino longids 0 gesetzt und beim cul longids 1.
Leider bemerke ich keinen Unterschied.

Kann nach wie vor nur mit jeweils einem empfangen.

Wie sollte sich die lange id auswirken? Ein neues Device?

Gruß und vielen Dank,
Stefan

Ralf9 · 11 November 2016, 21:33:52

Zitat von: stefanru am 11 November 2016, 21:18:46
Ich habe gemerkt dass es bei mir nicht an den Längen liegt. Mein Sensor wird nämlich mit THGR228N_ac_1 erkannt.

Wie sollte sich die lange id auswirken? Ein neues Device?

Bei longids 0 müsste ein neues Device THGR228N_1 angelegt werden

stefanru · 11 November 2016, 22:12:48

Ok,

das klappt irgendwie nicht.
Sduino hat longid 0 und beliefert fleisig den
CODE
THGR228N_ac_1
DEF
THGR228N_ac_1

mit THGR228N_1 findet es nichts.

Danke und Gruß,
Stefan

Ralf9 · 11 November 2016, 22:22:34

hast Du mir vom THGR228N vom sduino ein paar raw Nachrichten?

stefanru · 11 November 2016, 22:34:02

Also ich hab jetzt mal longid beim sduino auf 1 und beim Cul auf 0.
Der Cul empfängt nun
CODE
THGR228N_1
DEF
THGR228N_1

leider seit der umstellung der sduino nix mehr mit
CODE
THGR228N_ac_1
DEF
THGR228N_ac_1

Das ist ja echt komisch.

Raw nachrichten kann ich dir gerne schicken.

Du meinst mit verbose 5 aus dem log?
Wie finde ich den Auszug vom Oregon? Da kommt so viel durch.

Heute Mittag hatte ich Einträge vom CUL:
2016.11.11 13:02:19 4: THGR228N_ac_1 decoded Oregon: T: 7.3 H: 51 BAT: ok

Seit dem aber gar keine mehr mit THGR228N. Obwohl es ja funktioniert. Sehr seltsam.

Hoffe du hast eine Erklärung.
Bin noch ziemlich neu im Thema FHEM.

Danke und Gruß,
Stefan