FHEM Forum

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

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

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:
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 !  ;D ;D ;D :) :)

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

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
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)
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)
MC;LL=-953;LH=1078;SL=-400;SH=522;D=55555555334CCD4CAAAAAB4CAACCB2B2AAACACACACB52D2AD4CC;C=492;L=208;

Gruß Ralf

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

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.

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

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

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

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

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

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:
  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:
 
  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

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

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

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

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

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

Es müsste im log ungefähr so aussehen:

2016.11.11 22:57:26.098 4: sduinoD/msg READ: MC;LL=-994;LH=961;SL=-499;SH=490;D=AAAAAAAB332B4B4D54D4CCB55555553554D33532D4;C=483;
2016.11.11 22:57:26.098 4: sduinoD: Found manchester Protocol id 10 clock 483 -> OSV2o3
2016.11.11 22:57:26.098 4: sduinoD: OSV2 protocol detected: preamble_pos = 31
2016.11.11 22:57:26.098 4: sduinoD: OSV2 protocol converted to hex: (481A2D1035002090A2) with length (80) bits

Ok,

das ist ja echt seltsam.
Wenn ich beim THGR228N_1_sduino nun die kurzform eingebe "THGR228N_1" bei dem IODev sduino eingestellt ist finde ich wieder Daten.
Sduino ist aber auf longids? Kann es sein dass trotz IODev er auch die Ausgaben vom CUL parsed?
Ist das normal.

Im log finde ich auch nur ein Eintrag der dem von dir Ähnelt vom Sduino. Dafür viele vom CUL_REDIRECT.

Eintrag:
2016.11.11 00:12:42 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.11 00:12:42 4: sduino: Found manchester Protocol id 12 clock 489 -> Hideki protocol
2016.11.11 00:12:42 4: sduino/msg READ: MC;LL=-1059;LH=1014;SL=-444;SH=579;D=59664;C=515;L=18;
2016.11.11 00:13:21 4: sduino/msg READ: MC;LL=-1076;LH=858;SL=-531;SH=416;D=6959A6555955A6655598;C=480;L=78;
2016.11.11 00:13:21 4: sduino: Found manchester Protocol id 10 clock 480 -> OSV2o3
2016.11.11 00:13:21 4: sduino: Found manchester Protocol id 12 clock 480 -> Hideki protocol
2016.11.11 00:13:21 4: sduino/msg READ: MC;LL=-1072;LH=905;SL=-543;SH=403;D=55555555334ACD32AACAAD332AACCB4AAAAAACB3528;C=487;L=170;
2016.11.11 00:13:21 4: sduino: Found manchester Protocol id 10 clock 487 -> OSV2o3
2016.11.11 00:13:21 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.11 00:13:21 4: sduino: OSV2 protocol converted to hex: (401A2D10AC401900A4) with length (72) bits
2016.11.11 00:13:21 4: OREGON: ERROR: Unknown sensor_id=1a2d bits=64 message='401A2D10AC401900A4'.
2016.11.11 00:13:21 4: sduino: Found manchester Protocol id 12 clock 487 -> Hideki protocol

Ist es möglich dass der sduino meinen Sensor nicht kennt?
Ich habe das device von dem das der CUL per autocreate angelegt hat copiert gehabt.

Viele Grüße und nochmals vielen Dank,
Stefan

Zitat von: stefanru am 11 November 2016, 23:32:04
2016.11.11 00:13:21 4: sduino/msg READ: MC;LL=-1072;LH=905;SL=-543;SH=403;D=55555555334ACD32AACAAD332AACCB4AAAAAACB3528;C=487;L=170;
2016.11.11 00:13:21 4: sduino: Found manchester Protocol id 10 clock 487 -> OSV2o3
2016.11.11 00:13:21 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.11 00:13:21 4: sduino: OSV2 protocol converted to hex: (401A2D10AC401900A4) with length (72) bits
2016.11.11 00:13:21 4: OREGON: ERROR: Unknown sensor_id=1a2d bits=64 message='401A2D10AC401900A4'.

Das müssten die Daten vom THGR228N_1 sein, sie sind aber zu kurz. Es müssten 80 Bit sein.
Was für ein Empfänger verwendest Du beim sduino?

Das IODev sduino wirkt sich nur beim senden aus. z.B. beim IT-Modul.

Es werden auch die Ausgaben vom CUL parsed

Gruß Ralf

Ah,
dann ist ziemlich alles klar.
Nur etwas seltsam das er auch reagiert wenn ich ne kurze Bezeichnung eingebe und der CUL ne lange hat.
Habe gerade mal den CUL abgezogen und dann ist beim sduino auch ruhe.

Also parst er wohl den CUL. Auch wenn ich dort die kurze Bezeichnung eingetragen habe bei DEF und CODE und beim CUL die Lange.

Ich verwende die hier: http://www.ebay.de/itm/221652085232?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Habe mir aber schon die hier bestellt da die Reichweite des ersten Empfängers nicht berauschend ist: http://www.ebay.de/itm/282083075986?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Meinst du daran könnte es liegen?

Gruß und Danke,
Stefan

Zitat von: stefanru am 12 November 2016, 00:28:55
Ich verwende die hier: http://www.ebay.de/itm/221652085232?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Ja, mit diesem einfachen Empfänger ist es klar, daß Du nur einen schlechten Empfang hast. Der empfängt wahrscheinlich nur bei sehr kurzen Entfernungen was brauchbares.

Ok Danke!!
Ist der andere brauchbar?

Und noch ne Frage, woher weiß ich ob ein Protokol erfolgreich decodiert wurde?

hier mal die Erkennung meines Wetter Sensors mit dem CUL:
2016.11.12 02:32:13 4: CUL_Parse: nanoCUL433 omAAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030
2016.11.12 02:32:13 5: nanoCUL433 dispatch omAAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030
2016.11.12 02:32:13 5: CUL_REDIRECT (mAAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030) length: 53 RSSI: -50
2016.11.12 02:32:13 5: CUL_REDIRECT (mAAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030) match Manchester COODE length: 53
2016.11.12 02:32:13 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030)
2016.11.12 02:32:13 5: bitdata: 1010101010101010101010101010101011001100101101010011001011001101010101010011010101010010110011001011010101010100110011010011010101010101010011010100101101001101001100101010110101001100101010101000000000110000
2016.11.12 02:32:13 5: OSV2 protocol detected (AAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030)
2016.11.12 02:32:13 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D10AC811220263DFA) with length (88) bits

2016.11.12 02:32:13 5: nanoCUL433 Dispatch now to Oregon Module.
2016.11.12 02:32:13 5: converted Data to (501A2D10AC811220263DFA)
2016.11.12 02:32:13 5: nanoCUL433 dispatch 501A2D10AC811220263DFA
2016.11.12 02:32:13 3: OREGON: Unknown device THGR228N_ac_1, please define it
2016.11.12 02:32:13 2: autocreate: define THGR228N_ac_1 OREGON THGR228N_ac_1
2016.11.12 02:32:13 2: autocreate: define FileLog_THGR228N_ac_1 FileLog ./log/THGR228N_ac_1-%Y.log THGR228N_ac_1
2016.11.12 02:32:13 2: autocreate: define SVG_THGR228N_ac_1 SVG FileLog_THGR228N_ac_1:temp4hum4:CURRENT
2016.11.12 02:32:13 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030)
2016.11.12 02:32:13 5: bitdata: 1010101010101010101010101010101011001100101101010011001011001101010101010011010101010010110011001011010101010100110011010011010101010101010011010100101101001101001100101010110101001100101010101000000000110000
2016.11.12 02:32:13 5: CUL_REDIRECT decode Hideki (AAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030)
2016.11.12 02:32:13 5: nanoCUL433: search in 1010101010101010101010101010101011001100101101010011001011001101010101010011010101010010110011001011010101010100110011010011010101010101010011010100101101001101001100101010110101001100101010101000000000110000

2016.11.12 02:32:13 5: protocol does not match, ignore received package (AAAAAAAACCB532CD553552CCB554CD35554D4B4D32AD4CAA8030) Reason: Not a hideki protocol

Und dann ein normales einlesen, erkennen tu ich da nix das was gefunden wurde:

2016.11.12 02:54:58 5: CUL/RAW: /o
2016.11.12 02:54:58 5: CUL/RAW: o/mAAAA
2016.11.12 02:54:58 5: CUL/RAW: omAAAA/AAAB32
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32/D4CB3
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32D4CB3/554D54
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32D4CB3554D54/B32D52D2D5
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32D4CB3554D54B32D52D2D5/554D4A
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32D4CB3554D54B32D52D2D5554D4A/CCAD34
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34/CD4B2
2016.11.12 02:54:58 5: CUL/RAW: omAAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B2/39

2016.11.12 02:54:58 4: CUL_Parse: nanoCUL433 omAAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239
2016.11.12 02:54:58 5: nanoCUL433 dispatch omAAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239
2016.11.12 02:54:58 5: CUL_REDIRECT (mAAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239) length: 51 RSSI: -45.5
2016.11.12 02:54:58 5: CUL_REDIRECT (mAAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239) match Manchester COODE length: 51
2016.11.12 02:54:58 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239)
2016.11.12 02:54:58 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010011010101010010110011001011010101001011010010110101010101010101001101010010101100110010101101001101001100110101001011001000111001
2016.11.12 02:54:58 5: OSV2 protocol detected (AAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239)
2016.11.12 02:54:58 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D10AC610610D749B1) with length (88) bits

2016.11.12 02:54:58 5: nanoCUL433 Dispatch now to Oregon Module.
2016.11.12 02:54:58 5: converted Data to (501A2D10AC610610D749B1)
2016.11.12 02:54:58 5: nanoCUL433 dispatch 501A2D10AC610610D749B1
2016.11.12 02:54:58 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239)
2016.11.12 02:54:58 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010011010101010010110011001011010101001011010010110101010101010101001101010010101100110010101101001101001100110101001011001000111001
2016.11.12 02:54:58 5: CUL_REDIRECT decode Hideki (AAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239)
2016.11.12 02:54:58 5: nanoCUL433: search in 10101010101010101010101010101011001100101101010011001011001101010101010011010101010010110011001011010101001011010010110101010101010101001101010010101100110010101101001101001100110101001011001000111001

2016.11.12 02:54:58 5: protocol does not match, ignore received package (AAAAAAAB32D4CB3554D54B32D52D2D5554D4ACCAD34CD4B239) Reason: Not a hideki protocol


Gruß,
Stefan

Erstaunlich, daß diese Mist-Empfänger immer noch einen Käufer finden... :(

Zitat von: stefanru am 12 November 2016, 01:18:20
Ist der andere brauchbar?

Und noch ne Frage, woher weiß ich ob ein Protokol erfolgreich decodiert wurde?

Der andere ist brauchbar. Es ist z.Zt. der beste Empfänger den Du aus China bekommen kannst.
Mir ist kein besserer bekannt.

Wenn ein dispatch erfolgt, dann wurde es erfolgreich decodiert.
Wenn kurz hintereinander die gleiche Nachricht empfangen wird, dann wird sie ignoriert.

2016.11.12 02:54:58 5: nanoCUL433 Dispatch now to Oregon Module.
2016.11.12 02:54:58 5: converted Data to (501A2D10AC610610D749B1)
2016.11.12 02:54:58 5: nanoCUL433 dispatch 501A2D10AC610610D749B1

Gruß Ralf

Ok,

vielen vielen Dank!

Ok noch eine Frage ;-)

So wie ich das sehe wird mein OREGON Sensor THGR228N nur vom CUL mit a-culfw entdeckt SIGNALDuino erkennt ihn nicht.
Kann man den integrieren?

Die logs Verbose 5 vom CUL hätte ich.
2016.11.13 00:31:57 5: nanoCUL433 Dispatch now to Oregon Module.
2016.11.13 00:31:57 5: converted Data to (501A2D10573002000527C8)
2016.11.13 00:31:57 5: nanoCUL433 dispatch 501A2D10573002000527C8
2016.11.13 00:31:57 5: OREGON: decoding delay=78 hex=501A2D10573002000527C8
2016.11.13 00:31:57 5: OREGON: checksum2 = 39 berechnet: 39
2016.11.13 00:31:57 4: THGR228N_57_1_sduino decoded Oregon: T: 2.3 H: 50 BAT: ok
2016.11.13 00:31:57 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAB32D4CB3554D4ACCD54B535555554CD54AD35534A3D)
2016.11.13 00:31:57 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010011010100101011001100110101010100101101010011010101010101010101010101010011001101010101001010110100110101010100110100101000111101

Und hier vom Sduino zu der Zeit wo der Sender gefunkt hat:
2016.11.13 02:17:15 4: sduino/msg READ: MU;P0=923;P1=-1048;P3=454;P4=-508;P5=-3526;P7=254;D=0101010134010104313435043134043101010101010134010431057101017;CP=0;
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 13b -> FLAMINGO FA21 b matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 13b -> FLAMINGO FA21 b mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2016.11.13 02:17:15 5: sduino: applying filterfunc SIGNALduino_filterSign
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 21 -> einhell garagedoor mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 26 -> remote26 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: Starting demodulation at Position 9
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 36 -> socket36 mismatches, aborting
2016.11.13 02:17:15 5: sduino: applying filterfunc SIGNALduino_compPattern
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: Starting demodulation at Position 28
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 49 -> quigg_gt9000 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: Starting demodulation at Position 0
2016.11.13 02:17:15 4: sduino/msg READ: MU;P0=385;P1=-581;P2=827;P3=-1086;D=0121030121030121032323232323230123210323230323232323012103;CP=0;
2016.11.13 02:17:15 5: sduino: applying filterfunc SIGNALduino_filterSign
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 21 -> einhell garagedoor mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 26 -> remote26 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: Starting demodulation at Position 19
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 36 -> socket36 mismatches, aborting
2016.11.13 02:17:15 5: sduino: applying filterfunc SIGNALduino_compPattern
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: Starting demodulation at Position 2
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: start pattern for MU Protocol id 49 -> quigg_gt9000 mismatches, aborting
2016.11.13 02:17:15 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.11.13 02:17:15 5: sduino: Starting demodulation at Position 4
2016.11.13 02:17:19 5: SW: C0D
2016.11.13 02:17:19 5: CUL/RAW (ReadAnswer): C0D = 10 / 16

Viele Grüße,
Stefan

Das siehst Du falsch.
Hier ist auch ein THGR228N im Einsatz und wird problemlos von der aktuellen Signalduino software erkannt.

Hmm, ok.
Was hast du denn auf deinem SIGNALDuino?

Ich hab die dev-r33_flamenco.
Mein sneder wird leider nicht erkannt. Ist ein TX01 und wird vom CUL als THGR228N erkannt.
VomSIGNALDuino aber nicht. Sieht man ja in meinen Logauszügen.

Viele Grüße,
Stefan

Hallo stefanru,

gib mal diesen String in FEHM ein. Bei mir wurde ein OREGON Sensor angelegt. Ich habe auch den Flamingo/Flamenco-Sketch im Einsatz.

{ Dispatch($defs{sduino}, "501A2D10573002000527C8", undef) }

THGR228N_57_1   T: 2.3 H: 50 BAT: ok

Version:
00_SIGNALduino.pm     10484 2016-10-09 17:00:00Z v3.3.1-dev
# $Id: 14_FLAMINGO.pm 3818 2016-08-15 $
# $Id: 41_OREGON.pm 34476 2016-02-09 21:00:00 wherzig $

pejonp

Hi pejonp,

kannst du mir den Befehl erklären?
mit {}? Wo muss ich den eingeben?
Die Kommandozeile frisst den doch nicht oder?

Habs mal eingegeben, kam diese Rückmeldung: ARRAY(0x38d5570)

Ok hab das nochmal auf mein Sensor angepasst und eingegeben. Nun geht es über den sduino:
2016.11.13 19:05:58 5: sduino dispatch 501A2D1057521010062CDF
2016.11.13 19:05:58 5: OREGON: decoding delay=73 hex=501A2D1057521010062CDF
2016.11.13 19:05:58 5: OREGON: checksum2 = 44 berechnet: 44
2016.11.13 19:05:58 4: THGR228N_57_1_sduino decoded Oregon: T: 10.5 H: 61 BAT: ok

Irgendwie aber nicht dauerhaft. Muss der Befehl wo rein?
Danach hatte ich noch ein redaing vom CUL wieder und seit dem nix mehr. Weder sduino noch CUL.

Denke ich starte FHEM mal durch. Wäre toll wenn du mir den Dispatch mal erklären würdest.
Habe ihn nur in Artikeln zum entwickeln gefunden.



Danke und Gruß,
Stefan

Zitat von: stefanru am 13 November 2016, 18:29:49
..
Habs mal eingegeben, kam diese Rückmeldung: ARRAY(0x38d5570)

Ok hab das nochmal auf mein Sensor angepasst und eingegeben. Nun geht es über den sduino:
2016.11.13 19:05:58 5: sduino dispatch 501A2D1057521010062CDF
2016.11.13 19:05:58 5: OREGON: decoding delay=73 hex=501A2D1057521010062CDF
2016.11.13 19:05:58 5: OREGON: checksum2 = 44 berechnet: 44
2016.11.13 19:05:58 4: THGR228N_57_1_sduino decoded Oregon: T: 10.5 H: 61 BAT: ok
....

Hallo,

das war nur ein Test um festzustellen ob dein Signalduino diesen String verarbeiten kann. Ja das macht er. Es sollte auch ein neuer Eintrag angelegt worden sein.
Erkennt dein Signalduino überhaupt einen Sender. Ist die Verdrahtung richtig ? Hast du eine Whitelist im Einsatz, also Protokolle ausgeschaltet.
Arbeitet der Empfänger mit AM OOK/ASK oder FM OOK/FSK ??

Als Empfänger für meine Bresser (Hideki), Orgeon, LogiLink (WS0001) und Pearl habe ich diesen hier im Einsatz
http://www.tme.eu/de/details/rfm83c-433d/rf-kommunikationsmodule/hope-microelectronics/.

pejonp

Hi, also der Befehl schickt an einen Empfänger ein Kommando zum decodieren? Das ist ja cool :-)
Der sduino hat einen china 433,92 Empfänger. Er empfängt ziemlich viel .
Aber ich habe mir einen besseren Empfänger bestellt da der China Empfänger keine gute Reichweite hat.

Aber der sduino empfängt ohne Probleme meine Funksteckdosen und die Somfy Rolläden.

Mein Oregon habe ich zum Test immer neben dran liegen. Sollte also empfangen werden.
Der CUL macht es.

Wie sehe ich denn ob der sduino den empfängt?
Ich denke schon., immer zur selben Zeit wie der CUL empfängt der sduino auch etwas.
Cul dekodiert, Sduino nicht.

Hier mal das log vom erfolgreichen CUL un dgescheitertem Sduino. Sollte beides mein Sensor sein:
2016.11.13 22:45:06 4: CUL_Parse: nanoCUL433 omAAAAAAAAAA46
2016.11.13 22:45:06 4: CUL_Parse: nanoCUL433 omAAAAAAAB32D4CB3554D4ACCD34B4D4D555532D5534B54CB244
2016.11.13 22:45:06 4: THGR228N_57_1 decoded Oregon: T: 11.3 H: 68 BAT: ok
2016.11.13 22:45:06 4: sduino/msg READ: MU;P0=-1452;P1=944;P2=-1058;P3=-110;P4=536;P5=404;P7=-532;D=341535101010101010101075157075157010751010157075157010751570751010101010157075101015701010751570751570751015707510157010751015707510101570751010101010101010101570751570107510041121212571752125712175212121257175257121752571;CP=5;
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 34 -> unknown34 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 37 -> weather37 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.11.13 22:45:06 4: sduino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate


Gruß,
Stefan

Hallo Stefan.

Ich hab die dev-r33 drauf.

Bei mir sehen die Internals so aus:

CODE THGR228N_1
DEF    THGR228N_1
IODev sduino
NAME HumTemp1
NR 235
STATE T: 2.5 H: 70 D: -2.4 BAT: low
TIME 2016-11-14 09:57:54
TYPE OREGON

Ok danke. Vieleicht test ich mal mit r33.
Deine Kennung sieht aber nach longid=0 aus.  Hast du das gesetzt?
Genau so würde ich ihn empfangen wollen. Dann kann CUL (longid = 1) und sduino das gemeinsam machen.

Gruß,
Stefan

Si !
longid=0

Hallo Ralf ,Hallo Sidey

Bei mir läßt sich seit gestern Abend der  THGR918 nur noch mit Checksumme 72 Decodieren !! Echt nicht schön mir diesen Sensoren !! Meine Wetterstation und der FHEMduino interessieren das nicht ! Die Decodieren es immer noch!!
Warum ändert sich die Längen der Sensoren ab und an ?

Gruß Dirk

Kannst Du mal vom THGR918 einige raw-Nachrichten posten. Nach Möglichkeit auch mit den Nachrichten vom FHEMduino

Nachtrag:
Welchen Empfänger hast Du beim FHEMduino?
Welchen Empfänger hast Du beim Signalduino?
Ist die Entfernung vom FHEMduino zum THGR918 und die Entfernung vom Signalduino zum THGR918 ähnlich?

Gruß Ralf

Hallo Ralf,

Ich kann dir heute Nachmittag einige Raw´s senden ! Wenn du möchtest auch ein komplettes Log von heute Nacht ! Sowohl vom FHEMduino als auch vom Signalduino habe die heute Nacht mal im Verbose 5 laufen lassen !

Zum Empfänger Ich habe den Aurel AC-RX 5 V/DC siehe

https://www.conrad.de/de/empfaengermodul-aurel-ac-rx-5-vdc-190276.html?sc.ref=Product%20Details

den habe Ich auf dem Signalduino als auch auf dem FHEMduino eingesetzt und beide komplett neu mit einem Messender abgeglichen .
Der Empfang funktioniert auch sehr gut bis jetzt keine Probleme außer diese Oregon Sensoren ! Funksteckdosen und Sender  werden auch zuverlässig empfangen,auch durch diverse Wände .
Als Antenne dient ein 433 MHZ Halbwellendipol mit Balun.
Die Entfernung zwischen beiden Systemen ist ca 30 cm und die Entfernung zum THGR ist gleich !

Moin zusammen,

Ich habe diesen Thread leider nicht verfolgt.

Ralf hat mich gestern zum Glück auf das Thema aufmerksam gemacht.

Ich habe für einige Probleme ein Fix eingebaut.
Getestet habe ich es nicht wirklich, es könnte leider auch negative Auswirkungen haben.

Der fix ist in dev-r33 enthalten. Ein Flashen des Arduino ist nicht notwendig.

Viele Grüße
Sidey

Hallo Sidey,

Soll ich die 00_Signalduino.pm aus der dev-33 austauschen ?

Gruß Dirk

Ja, die 00_Signalduino.pm austauschen oder nur die korrigierte Zeile ändern:

https://github.com/RFD-FHEM/RFFHEM/commit/bb258d9d1f44ef553e40ea3fe75ac7dc58f14661

Danke für die Info ! Werde heute Nachmittag mal etwas testen und berichten !

Gruß Dirk

Zitat von: hdp1999 am 18 November 2016, 10:18:30
Danke für die Info ! Werde heute Nachmittag mal etwas testen und berichten !

Gruß Dirk

@all
Werde erst einmal die Änderungen von Sidey in der 00_SIGNALduino testen und bei Bedarf hier die Logs posten ! sind nur 15 MB Logfile gestern Nacht geworden !! :-)  :o :o

@Ralf
währe es für dich Interessant das komplette LOG zu bekommen ?

Gruß Dirk

@hdp1999
nein, daß komplette log ist nicht notwendig. Mich würde ca 10-20 min vom log und dann ca 10-20 min vom neuen log mit der Änderung interssieren. 

Ich habe mal beim BTHR918 die alten raw-Nachrichten mit der Änderung simuliert. Es hat sich deutlich gebessert.
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.
Bei den Nachrichten die vorher zu kurz waren (80 Bit), da passt es jetzt (88 Bit) und die checksum ist ok.

alt:
2016.10.25 15:41:40 4: sduino/msg READ: MC;LL=-953;LH=1077;SL=-420;SH=517;D=AAAAAAA99A666A6555555A65566595955565656565A96956A660;C=494;L=205;
2016.10.25 15:41:40 4: sduino: Found manchester Protocol id 10 clock 494 -> OSV2o3
2016.10.25 15:41:40 4: sduino: OSV2 protocol detected: preamble_pos = 30
2016.10.25 15:41:40 4: sduino: OSV2 protocol converted to hex: (585A5D005850224044E40CD7) with length (96) bits
2016.10.25 15:41:40 4: OREGON: ERROR: checksum error sensor_id=5a5d (bits=88)
2016.10.25 15:41:40 4: sduino: Found manchester Protocol id 12 clock 494 -> Hideki protocol
2016.10.25 15:41:40 4: sduino/msg READ: MC;LL=-955;LH=1057;SL=-408;SH=517;D=55555555334CCD4CAAAAAB4CAACCB2B2AAACACACACB52D2AD4CC;C=489;L=208;
2016.10.25 15:41:40 4: sduino: Found manchester Protocol id 10 clock 489 -> OSV2o3
2016.10.25 15:41:40 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.10.25 15:41:40 4: sduino: OSV2 protocol converted to hex: (505A5D005850224044E40C) with length (88) bits
2016.10.25 15:41:40 4: OREGON: ERROR: Unknown sensor_id=5a5d bits=80 message='505A5D005850224044E40C'.

neu mit der Änderung:
2016.11.18 19:17:20.822 4: sduinoD/msg get raw: MC;LL=-953;LH=1077;SL=-420;SH=517;D=AAAAAAA99A666A6555555A65566595955565656565A96956A660;C=494;L=205;
2016.11.18 19:17:20.822 5: sduinoD: extracted data 0101010101010101010101010101011001100101100110011001010110011010101010101010101010100101100110101010100110011010011010100110101010101010100110101001101010011010100110100101011010010110101010010101100110011111 (bin)
2016.11.18 19:17:20.822 4: sduinoD: OSV2 protocol detected: preamble_pos = 30
2016.11.18 19:17:20.822 4: sduinoD: OSV2 protocol converted to hex: (585A5D005850224044E40CD7) with length (96) bits
2016.11.18 19:17:20.822 5: sduinoD dispatch 585A5D005850224044E40CD7
2016.11.18 19:17:20.822 5: OREGON: decoding delay=54.962944984436 hex=585A5D005850224044E40CD7
2016.11.18 19:17:20.822 4: OREGON: sensor_id=5a5d Bits=88
2016.11.18 19:17:20.822 5: OREGON: checksum5plus = 215 berechnet: 87
2016.11.18 19:17:20.822 4: OREGON: ERROR: checksum error sensor_id=5a5d (bits=88)

2016.11.18 19:19:07.394 4: sduinoD/msg get raw: MC;LL=-955;LH=1057;SL=-408;SH=517;D=55555555334CCD4CAAAAAB4CAACCB2B2AAACACACACB52D2AD4CC;C=489;L=208;
2016.11.18 19:19:07.394 5: sduinoD: extracted data 1010101010101010101010101010101011001100101100110011001010110011010101010101010101010100101100110101010100110011010011010100110101010101010100110101001101010011010100110100101011010010110101010010101100110011 (bin)
2016.11.18 19:19:07.394 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.18 19:19:07.394 4: sduinoD: OSV2 protocol converted to hex: (585A5D005850224044E40C57) with length (96) bits
2016.11.18 19:19:07.394 5: sduinoD dispatch 585A5D005850224044E40C57
2016.11.18 19:19:07.394 5: OREGON: decoding delay=106.572170972824 hex=585A5D005850224044E40C57
2016.11.18 19:19:07.394 4: OREGON: sensor_id=5a5d Bits=88
2016.11.18 19:19:07.394 5: OREGON: checksum5plus = 87 berechnet: 87
2016.11.18 19:19:07.394 4: BTHR918_58 decoded Oregon: T: 22.5 H: 44 P: 1023  BAT: ok

Hallo Ralf

Ich habe die Änderung seit ca 17:00 Uhr eingespielt ! Bis Jetzt sieht es sehr gut aus alle meine Sensoren 7 Stk. werden mindesten 1 x pro Minute empfangen !
Anbei 2 Logs von heute Morgen vor der Änderung der 00_Signalduino.pm und von ebend nach der Änderung !


Gruß Dirk

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

@Sidey
kann ich es so machen?
alt:
  my $key = OREGON_type_length_key($type, $bits);

  my $rec = $types{$key} || $types{$key&0xfffff};
  unless ($rec) {
    #Log 1, "OREGON: ERROR: Unknown sensor_id=$sensor_id bits=$bits message='$msg'.";
    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";
}

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

2016.11.18 21:22:06.130 4: sduinoD/msg get raw: MC;LL=-1003;LH=951;SL=-519;SH=438;D=AAAAAAA999966A5555565A6955555555A596555556A99566A8;C=485;L=197;
2016.11.18 21:22:06.130 4: sduinoD: Found manchester Protocol id 10 clock 485 -> OSV2o3
2016.11.18 21:22:06.130 4: sduinoD: OSV2 protocol converted to hex: (582A1D00D900002601F0421F) with length (96) bits
2016.11.18 21:22:06.130 5: sduinoD dispatch 582A1D00D900002601F0421F
2016.11.18 21:22:06.131 5: OREGON: decoding delay=0 hex=582A1D00D900002601F0421F
2016.11.18 21:22:06.131 5: OREGON: sensor_id=2a1d BitsMsg=88 Bits=80
2016.11.18 21:22:06.131 5: OREGON: checksum6plus = 47 berechnet: 47
2016.11.18 21:22:06.131 4: RGR918_d9 decoded Oregon: RR: 0 TR: 12  BAT: ok

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.
   # 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.

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
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
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

Ich habe den Fix von Gestern noch mal etwas verfeinert.


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


Grüße Sidey

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.

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

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

Soweit das halt geht.

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  ;D ;D ;D

Gruß Dirk

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.
OREGON: sensor_id=2a1d BitsMsg=84 Bits=80

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?

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

Gruß Ralf

Hallo Ralf

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

Willst du davon auch ein Log haben ?

Gruß Dirk

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

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

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

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 !!

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

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 

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.

Zitat von: Ralf9 am 19 November 2016, 11:32:44
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.

Hi Ralf,

bei zwei von den drei Sensoren / Logauszügen ist das Ende = dem Ende der Daten. Auf FHEM Seite kann ich da glaube ich nichts machen.
Bei einem von den drei Sensoren, wurde der Start der Wiederholung nicht korrekt identifiziert. Das konnte ich beheben. (ist berereits eingecheckt)

Bei den anderen beiden tappe ich noch etwas im Dunkeln. Vielleicht ein Problem auf dem Arduino. Bevor ich da in die Analyse einsteige, wie oft treten diese zu langen Nachrichten auf ?

Grüße Sidey

Zitat von: Sidey am 20 November 2016, 23:08:18
bei zwei von den drei Sensoren / Logauszügen ist das Ende = dem Ende der Daten. Auf FHEM Seite kann ich da glaube ich nichts machen.
Bei einem von den drei Sensoren, wurde der Start der Wiederholung nicht korrekt identifiziert. Das konnte ich beheben. (ist berereits eingecheckt)

Hast Du Deinen fix mit den Nachrichten der 3 Sensoren getestet?
Ich habe den fix mal mit den Nachrichten
https://forum.fhem.de/index.php/topic,60170.msg524148.html#msg524148
getestet. Sie werden mit dem fix nicht mehr richtig decodiert.
2016.11.21 22:35:14.922 4: sduinoD/msg get raw: MC;LL=-996;LH=963;SL=-513;SH=437;D=555555553352CD2AAAAACB552AAAD4CAACCAAAAAAAAACCD2B533;C=484;L=208;
2016.11.21 22:35:14.922 4: sduinoD: OSV2 protocol converted to hex: (588AE5FF0DFED1D7FFFF95A3) with length (96) bits
2016.11.21 22:35:14.922 5: OREGON: decoding delay=59 hex=588AE5FF0DFED1D7FFFF95A3
2016.11.21 22:35:14.922 4: OREGON: ERROR: Unknown sensor_id=8ae5 bits=88 message='588AE5FF0DFED1D7FFFF95A3'.
Die richtige ID wäre 3a0d

Gruß Ralf

Ja, ich habe mit diversen Testdaten die Funktion verifiziert...
:(

Ich habe meinen Signalduino-Part gestern um kuz nach 11 Uhr morgens mit
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
auf den neuesten Stand gebracht.
Seitdem ist beim THGR228N hier Sendepause... kein einziges Telegramm mehr... :(

Alte 00_Signalduino.pm und 41_Oregon.pm zurückgespielt - läuft wieder...

Zitat von: Ralf9 am 21 November 2016, 22:50:34
Hast Du Deinen fix mit den Nachrichten der 3 Sensoren getestet?
Ich habe den fix mal mit den Nachrichten
https://forum.fhem.de/index.php/topic,60170.msg524148.html#msg524148
getestet.

Habe den Fehler gefunden und korrigiert.


Grüße Sidey

 :) Läuft.

Zitat von: Sidey am 20 November 2016, 23:08:18
Bei einem von den drei Sensoren, wurde der Start der Wiederholung nicht korrekt identifiziert. Das konnte ich beheben. (ist berereits eingecheckt)

Bei der Erkennung des Nachrichtenendes hat was noch nicht ganz gepasst. Ich habe es gefixt. Außerdem habe ich noch das folgende log ergänzt, wenn das Endemuster erkannt wurde.
OSV2 message end pattern found at pos 188  lengthBitData=208

Bei den zu langen Nachrichten des WGR918 wird das Ende nur z.T. korrekt erkannt.
Hier z.B. werden nur bei den ersten 3 Nachrichten das Ende korrekt erkannt.
2016.11.25 20:02:25.661 4: sduinoD/msg get raw: MC;LL=-996;LH=963;SL=-513;SH=437;D=555555553352CD2AAAAACB552AAAD4CAACCAAAAAAAAACCD2B533;C=484;L=208;
2016.11.25 20:02:25.662 5: sduinoD: extracted data 1010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010101010101001010110011010101010011001101010101010101010101010101010101010100110011001011010100101011001100 (bin)
2016.11.25 20:02:25.662 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.25 20:02:25.662 4: sduinoD: OSV2 message end pattern found at pos 188  lengthBitData=208
2016.11.25 20:02:25.662 4: sduinoD: OSV2 protocol converted to hex: (503A0D00F9001714000035) with length (88) bits
2016.11.25 20:02:25.662 5: OREGON: decoding delay=1114 hex=503A0D00F9001714000035
2016.11.25 20:02:25.662 5: OREGON: sensor_id=3a0d BitsMsg=80 Bits=80
2016.11.25 20:02:25.662 4: WGR918_f9 decoded Oregon: W: 1.4 WA: 0 WD: 170  WDN: SSE  BAT: ok

2016.11.25 20:12:37.656 4: sduinoD/msg get raw: MC;LL=-1010;LH=942;SL=-502;SH=441;D=AAAAAAAA99A96695555565AA95565A59555555555555566965658;C=482;L=209;
2016.11.25 20:12:37.656 5: sduinoD: extracted data 01010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010101010011010010110100110101010101010101010101010101010101010101010101010101010011001011010011010100110100111 (bin)
2016.11.25 20:12:37.656 4: sduinoD: OSV2 protocol detected: preamble_pos = 34
2016.11.25 20:12:37.656 4: sduinoD: OSV2 message end pattern found at pos 193  lengthBitData=212
2016.11.25 20:12:37.657 4: sduinoD: OSV2 protocol converted to hex: (503A0D00F9402600000034) with length (88) bits
2016.11.25 20:12:37.657 5: OREGON: decoding delay=134 hex=503A0D00F9402600000034
2016.11.25 20:12:37.657 5: OREGON: sensor_id=3a0d BitsMsg=80 Bits=80
2016.11.25 20:12:37.657 4: WGR918_f9 decoded Oregon: W: 0 WA: 0 WD: 264  WDN: WSW  BAT: ok

2016.11.23 23:44:16.313 4: sduinoD/msg get raw: MC;LL=-1007;LH=946;SL=-512;SH=436;D=555555554CD4B34AAAAAB2D54AACB2D2AAAAAAAAAAAAAB34B4AD4;C=483;L=210;
2016.11.23 23:44:16.313 5: sduinoD: extracted data 10101010101010101010101010101010101100110010101101001100101101010101010101010101010011010010101010110101010100110100110100101101010101010101010101010101010101010101010101010101010101001100101101001011010100101011 (bin)
2016.11.23 23:44:16.313 4: sduinoD: OSV2 protocol detected: preamble_pos = 35
2016.11.23 23:44:16.313 5: sduinoD: OSV2 message end pattern found at pos 194  lengthBitData=212
2016.11.23 23:44:16.313 4: sduinoD: OSV2 protocol converted to hex: (503A0D00F9201900000034) with length (88) bits
2016.11.23 23:44:16.313 5: OREGON: decoding delay=0 hex=503A0D00F9201900000034
2016.11.23 23:44:16.313 5: OREGON: sensor_id=3a0d BitsMsg=80 Bits=80
2016.11.23 23:44:16.313 4: WGR918_f9 decoded Oregon: W: 0 WA: 0 WD: 192  WDN: S  BAT: ok


2016.11.23 23:02:22.164 4: sduinoD/msg get raw: MC;LL=-999;LH=960;SL=-503;SH=446;D=555555553352CD2AAAAACB552AAACB4AAAAAAAAAAAAAB2D2D4B2;C=484;L=208;
2016.11.23 23:02:22.164 5: sduinoD: extracted data 1010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010101010101001101001011010101010101010101010101010101010101010101010101010101001101001011010010101101001101 (bin)
2016.11.23 23:02:22.164 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.23 23:02:22.164 4: sduinoD: OSV2 protocol converted to hex: (583A0D00F900190000003227) with length (96) bits
2016.11.23 23:02:22.164 5: OREGON: decoding delay=3356 hex=583A0D00F900190000003227
2016.11.23 23:02:22.164 5: OREGON: sensor_id=3a0d BitsMsg=88 Bits=80
2016.11.23 23:02:22.165 4: WGR918_f9 decoded Oregon: W: 0 WA: 0 WD: 190  WDN: S  BAT: ok

2016.11.23 23:02:22.235 4: sduinoD/msg get raw: MC;LL=-1020;LH=941;SL=-513;SH=430;D=555555554CD4B34AAAAAB2D54AAAB2D2AAAAAAAAAAAAACB4B52C8;C=483;L=210;
2016.11.23 23:02:22.235 5: sduinoD: extracted data 10101010101010101010101010101010101100110010101101001100101101010101010101010101010011010010101010110101010101010100110100101101010101010101010101010101010101010101010101010101010100110100101101001010110100110111 (bin)
2016.11.23 23:02:22.235 4: sduinoD: OSV2 protocol detected: preamble_pos = 35
2016.11.23 23:02:22.235 4: sduinoD: OSV2 protocol converted to hex: (583A0D00F900190000003227) with length (96) bits
2016.11.23 23:02:22.235 5: OREGON: decoding delay=0 hex=583A0D00F900190000003227
2016.11.23 23:02:22.235 5: OREGON: sensor_id=3a0d BitsMsg=88 Bits=80
2016.11.23 23:02:22.235 4: WGR918_f9 decoded Oregon: W: 0 WA: 0 WD: 190  WDN: S  BAT: ok

2016.11.23 23:02:22.291 4: sduinoD/msg get raw: MC;LL=-1014;LH=940;SL=-516;SH=431;D=AAAAAAAA99A96695555565AA955565A555555555555559696A590;C=483;L=209;
2016.11.23 23:02:22.291 5: sduinoD: extracted data 01010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010101010101001101001011010101010101010101010101010101010101010101010101010101001101001011010010101101001101111 (bin)
2016.11.23 23:02:22.291 4: sduinoD: OSV2 protocol detected: preamble_pos = 34
2016.11.23 23:02:22.291 4: sduinoD: OSV2 protocol converted to hex: (583A0D00F900190000003227) with length (96) bits
2016.11.23 23:02:22.291 5: OREGON: decoding delay=0 hex=583A0D00F900190000003227
2016.11.23 23:02:22.291 5: OREGON: sensor_id=3a0d BitsMsg=88 Bits=80
2016.11.23 23:02:22.291 4: WGR918_f9 decoded Oregon: W: 0 WA: 0 WD: 190  WDN: S  BAT: ok

2016.11.23 23:44:16.262 4: sduinoD/msg get raw: MC;LL=-1006;LH=956;SL=-497;SH=448;D=555555553352CD2AAAAACB552ACB2B32B2CAAAAAAAAAB552CB32;C=484;L=208;
2016.11.23 23:44:16.262 5: sduinoD: extracted data 1010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010100110100110101001100110101001101001101010101010101010101010101010101010101001010101011010011010011001101 (bin)
2016.11.23 23:44:16.262 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.23 23:44:16.262 4: sduinoD: OSV2 protocol converted to hex: (583A0D00F990281200003E29) with length (96) bits
2016.11.23 23:44:16.262 5: OREGON: decoding delay=0 hex=583A0D00F990281200003E29
2016.11.23 23:44:16.262 5: OREGON: sensor_id=3a0d BitsMsg=88 Bits=80
2016.11.23 23:44:16.262 4: WGR918_f9 decoded Oregon: W: 1.2 WA: 0 WD: 289  WDN: W  BAT: ok

2016.11.23 23:44:16.281 4: sduinoD/msg get raw: MC;LL=-1015;LH=948;SL=-514;SH=433;D=555555553352CD2AAAAACB552AAACB32AAAAAAAACAAAACD2CD34;C=484;L=208;
2016.11.23 23:44:16.281 5: sduinoD: extracted data 1010101010101010101010101010101011001100101011010011001011010101010101010101010100110100101010101101010101010101001101001100110101010101010101010101010101010101001101010101010101010011001011010011001011001011 (bin)
2016.11.23 23:44:16.281 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.23 23:44:16.281 4: sduinoD: OSV2 protocol converted to hex: (583A0D00F90029000001346D) with length (96) bits
2016.11.23 23:44:16.282 5: OREGON: decoding delay=0 hex=583A0D00F90029000001346D
2016.11.23 23:44:16.282 5: OREGON: sensor_id=3a0d BitsMsg=88 Bits=80
2016.11.23 23:44:16.282 4: WGR918_f9 decoded Oregon: W: 0 WA: 1 WD: 290  WDN: W  BAT: ok

Zitat von: Sidey am 20 November 2016, 23:08:18
Bei den anderen beiden tappe ich noch etwas im Dunkeln. Vielleicht ein Problem auf dem Arduino. Bevor ich da in die Analyse einsteige, wie oft treten diese zu langen Nachrichten auf ?

Die zu langen Nachrichten treten ca bei einem Drittel der Nachrichten auf. Dies ist aber egal, da sie durch meine Anpassung am Oregon Modul trotzdem decodiert werden.

Gruß Ralf

Hi,

vielen Dank für die Verbesserungen. Mein Sensor läuft mit sduino auch gut!
Habe aber komische logzeilen im Log:
2016.11.26 20:21:19 1: Error: >T: 8.9 H: 56 BAT: ok< has no TYPE, but following keys:
>sduino_DMSG,sduino_MSGCNT,sduino_RAWMSG,sduino_TIME<

Was ist das?

Danke und Gruß,
Stefan

Zitat von: stefanru am 26 November 2016, 20:26:50
Habe aber komische logzeilen im Log:
2016.11.26 20:21:19 1: Error: >T: 8.9 H: 56 BAT: ok< has no TYPE, but following keys:
>sduino_DMSG,sduino_MSGCNT,sduino_RAWMSG,sduino_TIME<

Was ist das?

Bitte poste mal einen log Auszug mit sduino verbose 5

Gruß Ralf

Zitat von: Ralf9 am 25 November 2016, 23:37:25

Bei den zu langen Nachrichten des WGR918 wird das Ende nur z.T. korrekt erkannt.
Hier z.B. werden nur bei den ersten 3 Nachrichten das Ende korrekt erkannt.

Hallo Ralf,

Danke für die Anpassungen.
Hast Du eine Idee, was dazu führt, dass manchmal das Ende nicht richig erkannt wird?
Das Ende ist ja entweder der Start einer Wiederholung oder das Ende einer Übertragung.

Grüße Sidey

Das ist komisch, die scheinen ab und zu zu kommen z.B.:
2016.11.26 20:52:05 4: sduino/msg READ: MU;P0=-4070;P1=562;P2=-2068;D=012101012101010121212121212121212101212101210121012101012121010121010121010;CP=1;
2016.11.26 20:52:05 4: sduino: Fingerprint for MU Protocol id 13b -> FLAMINGO FA21 b matches, trying to demodulate
2016.11.26 20:52:05 5: sduino: start pattern for MU Protocol id 13b -> FLAMINGO FA21 b mismatches, aborting
2016.11.26 20:52:05 5: sduino: applying filterfunc SIGNALduino_filterSign
2016.11.26 20:52:05 5: sduino: applying filterfunc SIGNALduino_compPattern
2016.11.26 20:52:06 4: sduino/KeepAliveOk: 1
2016.11.26 20:52:06 4: sduino/keepalive retry = 0
2016.11.26 20:52:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.11.26 20:52:29 1: Error: >T: 8.5 H: 55 BAT: ok< has no TYPE, but following keys: >LASTInputDev,MSGCNT,nanoCUL433_DMSG,nanoCUL433_MSGCNT,nanoCUL433_RAWMSG,nanoCUL433_TIME,sduino_DMSG,sduino_MSGCNT,sduino_RAWMSG,sduino_TIME<

Dann aber auch nach einem CUL Empfang:
2016.11.26 20:52:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.11.26 20:52:03 5: CUL/RAW: /omAA
2016.11.26 20:52:03 5: CUL/RAW: omAA/AAAAAB
2016.11.26 20:52:03 5: CUL/RAW: omAAAAAAAB/32D4C
2016.11.26 20:52:03 5: CUL/RAW: omAAAAAAAB32D4C/B3554
2016.11.26 20:52:03 5: CUL/RAW: omAAAAAAAB32D4CB3554/D4ACCD
2016.11.26 20:52:03 1: Error: >T: 8.5 H: 55 BAT: ok< has no TYPE, but following keys: >LASTInputDev,MSGCNT,nanoCUL433_DMSG,nanoCUL433_MSGCNT,nanoCUL433_RAWMSG,nanoCUL433_TIME,sduino_DMSG,sduino_MSGCNT,sduino_RAWMSG,sduino_TIME<

Weiß nicht ob es mit den lese Geräten sduino oder CUL zu tun hat.
Glaube eher nicht. Aber was ist es dann?
Hatte es bevor ich heute den Sduino mit superhet empfänger in Betrieb genommen habe nicht.


Gruß,
Stefan

Zitat von: Sidey am 26 November 2016, 20:41:23
Hast Du eine Idee, was dazu führt, dass manchmal das Ende nicht richig erkannt wird?
Das Ende ist ja entweder der Start einer Wiederholung oder das Ende einer Übertragung.

Nein ich hab auch keine Idee.
Ich denke das Problem könnte sein, daß die Pause zwischen dem Ende der Nachricht und der Wiederholung bei den verschiedenen Modulen unterschiedlich ist. Evtl gibt es bei einigen Modulen keine Pause.
Wenn ich das richtig verstehe dürfte doch normalerweise am Ende der Nachricht gar keine Wiederholung kommen. Die Mancester Routine in der Firmware müsste doch normalerweise den beginn der Wiederholung erkennen.
Ich denke den Fehler zu finden dürfte recht aufwändig sein. Ich sehe momentan keine Notwendigkeit diesen Fehler zu suchen, da die Decodierung trotzdem funktioniert. 

Gruß Ralf

Zitat von: stefanru am 26 November 2016, 20:55:05
Weiß nicht ob es mit dem lese Geräte sduino oder CUL zu tun hat.
Glaube eher nicht. Aber was ist es dann? Hatte es vorher nicht.

Kannst Du eingrenzen ob es vom sduino oder CUL kommt?
Du kannst z.B. mal testen ob der Fehler auch kommt, wenn Du den sduino oder CUL aussteckst oder deaktivierst. Beim sduino gibt es ein "set close"

Gruß Ralf

Ja, habe ich gemacht, ganz komisch.

Ist mit abgestecktem CUL aufgetreten:
2016.11.26 21:48:23 1: Error: >T: 8.5 H: 56 BAT: ok< has no TYPE, but following keys: >LASTInputDev,MSGCNT,nanoCUL433_DMSG,nanoCUL433_MSGCNT,nanoCUL433_RAWMSG,nanoCUL433_TIME,sduino_DMSG,sduino_MSGCNT,sduino_RAWMSG,sduino_TIME<

Aber auch mit abgesteckem Sduino?
Es kommt acu viel zu oft. So oft sendet der Sensor garnicht.

Kann es was mit diesem Logeintrag zu tun haben?
2016.11.26 21:51:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.

Hat jemand ne Idee?

Gruß,
Stefan

Zitat von: stefanru am 26 November 2016, 21:52:26
Kann es was mit diesem Logeintrag zu tun haben?
2016.11.26 21:51:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.

Schau mal hier:

https://forum.fhem.de/index.php/topic,58090.msg495097.html#msg495097

https://forum.fhem.de/index.php/topic,59456.msg508295.html#msg508295

Gruß Ralf

Hi Ralf,

vielen Dank.

Ich finde aber auch dort nur raus dass es >T: 8.5 H: 56 BAT: ok< has no TYPE.
Ich habe aber alles durchsucht und kein device gefunden das so heißt.
Das ist doch eigentlich die Rückgabe vom oregon Sensor.

Habe alle Oregons nochmal gelöscht.
Wurden per autocreate wieder angelegt.
Hat aber auch nichts geholfen.

Bin jetzt ratlos. Jemand noch ne Idee?

P.S.: Habe den Sender weiter weg gestellt.
Nun findet ihn nur der Sduino. FHEM durchgestartet und die Fehler sind erstmal weg.
Scheint dann doch eher vom a-cul zu kommen, oder zusammenspiel?
Leider sobald ich den Sensor wieder näher bringe tritt es wieder auf.
Trozdem erstmal mit Workaround für mich gelöst.


Gruß,
Stefan

Hallo,

ich versuche den Oregon-Sender THRG228N mittels SIGNALDuino zu empfangen und zu dekodieren. Das Empfangen klappt soweit (jedenfalls denke ich so), aber nicht das Dekodieren. Ich habe das Gefühl, dass die Verarbeitung vom Modul 00_SIGNALDuino.pm nicht an das Modul 41_OREGON.pm weitergegeben wird.

Das Empfänger TI-CC1101 ist an Atmega-Nano328 angeschlossen und Atmega an Raspi-3.

Über jede Hilfe wäre ich dankbar.

Gruß Tansel

Hier sind die Logeinträge:

2016.11.30 22:20:47 0: Server started with 51 defined entities (fhem.pl:12680/2016-11-28 perl:5.020002 os:linux user:fhem pid:27959)
2016.11.30 22:20:52 3: sduino/init: disable receiver (XQ)
2016.11.30 22:20:53 3: sduino/init: get version, retry = 0
2016.11.30 22:20:53 4: sduino/msg READ: V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28
2016.11.30 22:20:53 2: sduino: initialized
2016.11.30 22:20:53 3: sduino/init: enable receiver (XE)
2016.11.30 22:20:55 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/99_myUtils.pm line 57.
2016.11.30 22:21:04 4: sduino/msg READ: MC;LL=-981;LH=977;SL=-523;SH=479;D=66959A655595;C=493;L=48;
2016.11.30 22:21:04 4: sduino/msg READ: MC;LL=-1012;LH=955;SL=-490;SH=446;D=9A6555A569555556A95A59596564;C=483;L=110;
2016.11.30 22:21:04 4: sduino: Found manchester Protocol id 10 clock 483 -> OSV2o3
2016.11.30 22:21:04 4: sduino: Found manchester Protocol id 12 clock 483 -> Hideki protocol
2016.11.30 22:21:07 4: sduino/msg READ: MC;LL=-975;LH=985;SL=-464;SH=475;D=559555656666A695965;C=483;L=76;
2016.11.30 22:21:07 4: sduino: Found manchester Protocol id 10 clock 483 -> OSV2o3
2016.11.30 22:21:07 4: sduino: Found manchester Protocol id 12 clock 483 -> Hideki protocol
2016.11.30 22:21:18 4: sduino/msg READ: MS;P0=-350;P1=-956;P2=292;P4=911;P6=-9894;D=26212121212121214021402140212121402140214021212140;CP=2;SP=6;O;
2016.11.30 22:21:18 4: sduino: Matched MS Protocol id 3 -> itv1
2016.11.30 22:21:18 4: sduino: Decoded MS Protocol id 3 dmsg i015151 length 24
2016.11.30 22:21:18 4: sduino IT: message "i015151" (7)
2016.11.30 22:21:18 4: sduino IT: msgcode "000FFF0FFF0F" (12) bin = 000000010101000101010001
2016.11.30 22:21:18 4: sduino/msg READ: MU;P0=271;P1=-953;P3=945;P4=-349;P5=-266;P6=-9944;D=010101010134013401340135013401340135343434340601010101010101340134013401350134;CP=0;
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: decoded matched MU Protocol id 40 dmsg u40#0A8 length 12
2016.11.30 22:21:18 4: SIGNALduino_unknown incomming msg: u40#0A8
2016.11.30 22:21:18 4: SIGNALduino_unknown rawData: 0A8
2016.11.30 22:21:18 4: SIGNALduino_unknown Protocol: 40
2016.11.30 22:21:18 4: SIGNALduino_unknown converted to bits: 000010101000
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino/msg READ: MU;P0=336;P2=-917;P3=946;P4=-316;P7=-9948;D=00234023434343434070202020202020234023402340234023402340234343434340;CP=0;
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.11.30 22:21:18 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.30 22:21:18 4: sduino/msg READ: MS;P1=337;P2=-1041;P3=255;P4=919;P5=-351;P6=-9918;D=36123232323212124512451245321212451245124532453232;CP=3;SP=6;O;
2016.11.30 22:21:19 4: sduino/msg READ: MS;P0=-917;P1=341;P3=944;P4=-315;P6=-9932;P7=262;D=16107070707010103410341034703410347034103434343434;CP=1;SP=6;
2016.11.30 22:21:19 4: sduino: Matched MS Protocol id 3 -> itv1
2016.11.30 22:21:20 4: sduino/msg READ: MS;P0=311;P1=-975;P2=935;P3=-327;P6=-9940;D=06010101010101012301230123012301010123012301010123;CP=0;SP=6;
2016.11.30 22:21:20 4: sduino: Matched MS Protocol id 3 -> itv1
2016.11.30 22:21:20 4: sduino: Decoded MS Protocol id 3 dmsg i015451 length 24
2016.11.30 22:21:20 4: sduino IT: message "i015451" (7)
2016.11.30 22:21:20 4: sduino IT: msgcode "000FFFF0FF0F" (12) bin = 000000010101010001010001
2016.11.30 22:21:21 4: sduino/msg READ: MU;P0=-348;P1=337;P2=-955;P3=945;P6=-9956;D=012301230123012121230123030303030161212121212121230123012301230123012301230303030301;CP=1;
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.11.30 22:21:21 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.30 22:21:21 4: sduino/msg READ: MS;P0=-975;P1=344;P2=259;P3=932;P4=-335;P5=-9895;D=15102010101020103410341034103410101034203420341010;CP=1;SP=5;O;
2016.11.30 22:21:21 4: sduino: Matched MS Protocol id 3 -> itv1
2016.11.30 22:21:32 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/98_DBPlan.pm line 1153.
2016.11.30 22:21:43 4: sduino/msg READ: MC;LL=-1042;LH=918;SL=-534;SH=437;D=55555555334ACD32AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=488;L=191;
2016.11.30 22:21:43 4: sduino: Found manchester Protocol id 10 clock 488 -> OSV2o3
2016.11.30 22:21:43 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.30 22:21:43 4: sduino: OSV2 protocol converted to hex: (481A2D102D300680C744) with length (80) bits
2016.11.30 22:21:43 4: sduino: Found manchester Protocol id 12 clock 488 -> Hideki protocol
2016.11.30 22:21:43 4: sduino/msg READ: MC;LL=-1018;LH=958;SL=-508;SH=455;D=55555555334ACD32AACAC;C=489;L=84;
2016.11.30 22:21:43 4: sduino: Found manchester Protocol id 10 clock 489 -> OSV2o3
2016.11.30 22:21:43 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.30 22:21:43 4: sduino: Found manchester Protocol id 12 clock 489 -> Hideki protocol
2016.11.30 22:21:43 4: sduino/msg READ: MC;LL=-1018;LH=958;SL=-508;SH=455;D=6555A569555556A95A59596564;C=489;L=102;
2016.11.30 22:21:43 4: sduino: Found manchester Protocol id 10 clock 489 -> OSV2o3
2016.11.30 22:21:43 4: sduino: Found manchester Protocol id 12 clock 489 -> Hideki protocol
2016.11.30 22:21:47 4: sduino/msg READ: MC;LL=-1045;LH=915;SL=-507;SH=458;D=66959A655565595A5599956555595999A9A56594;C=487;L=158;
2016.11.30 22:21:47 4: sduino: Found manchester Protocol id 10 clock 487 -> OSV2o3
2016.11.30 22:21:47 4: sduino: Found manchester Protocol id 12 clock 487 -> Hideki protocol
2016.11.30 22:21:48 4: sduino/msg READ: MC;LL=-1048;LH=915;SL=-545;SH=414;D=55555555334ACD32AAB2ACAD2ACCCAB2AAACACCCD4D2B2CA;C=486;L=191;
2016.11.30 22:21:48 4: sduino: Found manchester Protocol id 10 clock 486 -> OSV2o3
2016.11.30 22:21:48 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.30 22:21:48 4: sduino: OSV2 protocol converted to hex: (481A2D20C45021405437) with length (80) bits
2016.11.30 22:21:48 4: sduino: Found manchester Protocol id 12 clock 486 -> Hideki protocol
2016.11.30 22:21:53 4: sduino/KeepAliveOk: 1
2016.11.30 22:21:53 4: sduino/keepalive retry = 0
2016.11.30 22:22:22 4: sduino/msg READ: MC;LL=-1029;LH=986;SL=-534;SH=430;D=D5555555334ACD3;C=496;L=60;
2016.11.30 22:22:22 4: sduino/msg READ: MC;LL=-925;LH=999;SL=-441;SH=533;D=2AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=482;L=131;
2016.11.30 22:22:22 4: sduino: Found manchester Protocol id 10 clock 482 -> OSV2o3
2016.11.30 22:22:22 4: sduino: Found manchester Protocol id 12 clock 482 -> Hideki protocol
2016.11.30 22:22:22 4: sduino/msg READ: MC;LL=-968;LH=1008;SL=-454;SH=518;D=55555555334ACD32AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=491;L=191;
2016.11.30 22:22:22 4: sduino: Found manchester Protocol id 10 clock 491 -> OSV2o3
2016.11.30 22:22:22 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.11.30 22:22:22 4: sduino: OSV2 protocol converted to hex: (481A2D102D300680C744) with length (80) bits
2016.11.30 22:22:22 4: sduino: Found manchester Protocol id 12 clock 491 -> Hideki protocol
2016.11.30 22:22:29 4: sduino/msg READ: MU;P0=-485;P1=-11628;P3=-2344;P4=1042;P5=-946;P7=536;D=13454545454545104015454545104075454510454015454545104015104015104015454545104015454545454510454015454545104015104015104015451045401510454015451040154510454545401145454545454545454545454545454545407570407570454075454570407570454075704075454545454545704075;CP=4;O;
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 48 -> TFA Dostmann matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.11.30 22:22:29 4: sduino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2016.11.30 22:22:29 4: sduino/msg READ: MC;LL=-967;LH=964;SL=-458;SH=525;D=AB2B4;C=485;L=18;
2016.11.30 22:22:29 4: sduino/msg READ: MC;LL=-921;LH=1047;SL=-459;SH=485;D=559996AAD2AC;C=485;L=46;
2016.11.30 22:22:29 4: sduino/msg READ: MC;LL=-921;LH=1047;SL=-459;SH=485;D=665A6965AA;C=485;L=40;

Zitat von: Dansayisi am 30 November 2016, 22:46:34
ich versuche den Oregon-Sender THRG228N mittels SIGNALDuino zu empfangen und zu dekodieren. Das Empfangen klappt soweit (jedenfalls denke ich so), aber nicht das Dekodieren. Ich habe das Gefühl, dass die Verarbeitung vom Modul 00_SIGNALDuino.pm nicht an das Modul 41_OREGON.pm weitergegeben wird.
Das Empfänger TI-CC1101 ist an Atmega-Nano328 angeschlossen und Atmega an Raspi-3.

Der Empfänger TI-CC1101 dürfte eigentlich nicht am SIGNALDuino funktionieren, sieht nach einem Empfänger fur den cul aus.
Empfohlen wird ein Superheterodyne Empfänger. z.B.
http://www.ebay.de/itm/RXB6-433Mhz-Superheterodyne-Wireless-Receiver-Modul-fur-Arduino-ARM-AVR-/282083075986?hash=item41ad762792:g:LDQAAOSwXeJXc0s1


Wenn Du ein update auf die aktuelle Signalduino Version machst, dann passt es
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

2016.11.30 23:20:27.124 4: sduinoD/msg get raw: MC;LL=-1042;LH=918;SL=-534;SH=437;D=55555555334ACD32AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=488;L=191;
2016.11.30 23:20:27.124 4: sduinoD: Found manchester Protocol id 10 clock 488 -> OSV2o3
2016.11.30 23:20:27.124 5: sduinoD: extracted data 101010101010101010101010101010101100110010110101001100101100110101010101001101010011001011001101010101010010110101001011010101010101010101010100101010110101001011010011010100110100110101001101 (bin)
2016.11.30 23:20:27.124 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.30 23:20:27.124 4: sduinoD: OSV2 protocol converted to hex: (501A2D102D300680C74422) with length (88) bits
2016.11.30 23:20:27.124 5: sduinoD: converted Data to (501A2D102D300680C74422)
2016.11.30 23:20:27.124 5: sduinoD dispatch 501A2D102D300680C74422
2016.11.30 23:20:27.124 5: OREGON: decoding delay=0 hex=501A2D102D300680C74422
2016.11.30 23:20:27.124 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.11.30 23:20:27.124 5: OREGON: checksum2 = 68 berechnet: 68
2016.11.30 23:20:27.124 3: OREGON: Unknown device THGR228N_2d_1, please define it
2016.11.30 23:20:27.126 2: autocreate: define THGR228N_2d_1 OREGON THGR228N_2d_1

2016.11.30 23:23:04.437 4: sduinoD/msg get raw: MC;LL=-968;LH=1008;SL=-454;SH=518;D=55555555334ACD32AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=491;L=191;
2016.11.30 23:23:04.437 4: sduinoD: Found manchester Protocol id 10 clock 491 -> OSV2o3
2016.11.30 23:23:04.437 5: sduinoD: extracted data 101010101010101010101010101010101100110010110101001100101100110101010101001101010011001011001101010101010010110101001011010101010101010101010100101010110101001011010011010100110100110101001101 (bin)
2016.11.30 23:23:04.437 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.30 23:23:04.437 4: sduinoD: OSV2 protocol converted to hex: (501A2D102D300680C74422) with length (88) bits
2016.11.30 23:23:04.437 5: sduinoD: converted Data to (501A2D102D300680C74422)
2016.11.30 23:23:04.437 5: sduinoD dispatch 501A2D102D300680C74422
2016.11.30 23:23:04.437 5: OREGON: decoding delay=157 hex=501A2D102D300680C74422
2016.11.30 23:23:04.438 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.11.30 23:23:04.438 5: OREGON: checksum2 = 68 berechnet: 68
2016.11.30 23:23:04.438 4: THGR228N_2d_1 decoded Oregon: T: 6.3 H: 78 BAT: ok

Gruß Ralf

Zitat von: Ralf9 am 30 November 2016, 23:48:52
Der Empfänger TI-CC1101 dürfte eigentlich nicht am SIGNALDuino funktionieren, sieht nach einem Empfänger fur den cul aus.
Empfohlen wird ein Superheterodyne Empfänger. z.B.
http://www.ebay.de/itm/RXB6-433Mhz-Superheterodyne-Wireless-Receiver-Modul-fur-Arduino-ARM-AVR-/282083075986?hash=item41ad762792:g:LDQAAOSwXeJXc0s1


Wenn Du ein update auf die aktuelle Signalduino Version machst, dann passt es

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Code Auswählen Erweitern

2016.11.30 23:20:27.124 4: sduinoD/msg get raw: MC;LL=-1042;LH=918;SL=-534;SH=437;D=55555555334ACD32AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=488;L=191;
2016.11.30 23:20:27.124 4: sduinoD: Found manchester Protocol id 10 clock 488 -> OSV2o3
2016.11.30 23:20:27.124 5: sduinoD: extracted data 101010101010101010101010101010101100110010110101001100101100110101010101001101010011001011001101010101010010110101001011010101010101010101010100101010110101001011010011010100110100110101001101 (bin)
2016.11.30 23:20:27.124 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.30 23:20:27.124 4: sduinoD: OSV2 protocol converted to hex: (501A2D102D300680C74422) with length (88) bits
2016.11.30 23:20:27.124 5: sduinoD: converted Data to (501A2D102D300680C74422)
2016.11.30 23:20:27.124 5: sduinoD dispatch 501A2D102D300680C74422
2016.11.30 23:20:27.124 5: OREGON: decoding delay=0 hex=501A2D102D300680C74422
2016.11.30 23:20:27.124 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.11.30 23:20:27.124 5: OREGON: checksum2 = 68 berechnet: 68
2016.11.30 23:20:27.124 3: OREGON: Unknown device THGR228N_2d_1, please define it
2016.11.30 23:20:27.126 2: autocreate: define THGR228N_2d_1 OREGON THGR228N_2d_1

2016.11.30 23:23:04.437 4: sduinoD/msg get raw: MC;LL=-968;LH=1008;SL=-454;SH=518;D=55555555334ACD32AACACD32AAD2B4AAAAAB54AD2CACB2B2;C=491;L=191;
2016.11.30 23:23:04.437 4: sduinoD: Found manchester Protocol id 10 clock 491 -> OSV2o3
2016.11.30 23:23:04.437 5: sduinoD: extracted data 101010101010101010101010101010101100110010110101001100101100110101010101001101010011001011001101010101010010110101001011010101010101010101010100101010110101001011010011010100110100110101001101 (bin)
2016.11.30 23:23:04.437 4: sduinoD: OSV2 protocol detected: preamble_pos = 33
2016.11.30 23:23:04.437 4: sduinoD: OSV2 protocol converted to hex: (501A2D102D300680C74422) with length (88) bits
2016.11.30 23:23:04.437 5: sduinoD: converted Data to (501A2D102D300680C74422)
2016.11.30 23:23:04.437 5: sduinoD dispatch 501A2D102D300680C74422
2016.11.30 23:23:04.437 5: OREGON: decoding delay=157 hex=501A2D102D300680C74422
2016.11.30 23:23:04.438 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.11.30 23:23:04.438 5: OREGON: checksum2 = 68 berechnet: 68
2016.11.30 23:23:04.438 4: THGR228N_2d_1 decoded Oregon: T: 6.3 H: 78 BAT: ok

Gruß Ralf

Hallo Ralf,

super! Vielen dank! Nach dem Update klappt es jetzt bei mir auch. 

Ich habe tatsächlich einen TI-CC1101-Empfänger (s. das Bild).

Gruß Tansel

Hier sind die neue Logeinträge:

2016.12.01 00:05:18 1: Including fhem.cfg
2016.12.01 00:05:33 1: Cannot init /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0, ignoring it (nanoCUL)
2016.12.01 00:05:33 1: sduino/define: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2016.12.01 00:05:33 1: sduino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2016.12.01 00:05:33 1: Including ./log/fhem.save
2016.12.01 00:05:33 1: usb create starting
2016.12.01 00:05:39 1: usb create end
2016.12.01 00:05:39 1: in INITIALIZED
2016.12.01 00:05:39 0: Featurelevel: 5.7
2016.12.01 00:05:39 0: Server started with 57 defined entities (fhem.pl:12680/2016-11-28 perl:5.020002 os:linux user:fhem pid:1831)
2016.12.01 00:05:39 3: sduino/init: disable receiver (XQ)
2016.12.01 00:05:39 3: sduino/init: get version, retry = 0
2016.12.01 00:05:39 4: sduino/msg READ: V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28
2016.12.01 00:05:39 2: sduino: initialized
2016.12.01 00:05:39 3: sduino/init: enable receiver (XE)
2016.12.01 00:05:40 4: sduino/msg READ: MC;LL=-962;LH=1029;SL=-495;SH=439;D=A566995559565695559559556956566A695959;C=487;L=152;
2016.12.01 00:05:40 4: sduino: Found manchester Protocol id 10 clock 487 -> OSV2o3
2016.12.01 00:05:40 4: sduino: Found manchester Protocol id 12 clock 487 -> Hideki protocol
2016.12.01 00:05:40 4: sduino/msg READ: MC;LL=-963;LH=1002;SL=-466;SH=513;D=55555555334ACD0;C=490;L=57;
2016.12.01 00:05:40 4: sduino/msg READ: MC;LL=-1028;LH=994;SL=-480;SH=443;D=655565595A5556556555A55959A9A56564;C=490;L=134;
2016.12.01 00:05:40 4: sduino: Found manchester Protocol id 10 clock 490 -> OSV2o3
2016.12.01 00:05:40 4: sduino: Found manchester Protocol id 12 clock 490 -> Hideki protocol
2016.12.01 00:05:41 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/99_myUtils.pm line 57.
2016.12.01 00:05:47 4: sduino/msg READ: MC;LL=-1005;LH=986;SL=-497;SH=438;D=8CD2B34CAAB2B34CAAB52D2AAAAD352B4D2B2B4CC;C=487;L=162;
2016.12.01 00:05:47 4: sduino: Found manchester Protocol id 10 clock 487 -> OSV2o3
2016.12.01 00:05:47 4: sduino: Found manchester Protocol id 12 clock 487 -> Hideki protocol
2016.12.01 00:05:47 4: sduino/msg READ: MC;LL=-1003;LH=1041;SL=-431;SH=490;D=55555555334ACD32AACACD32AAD4B4AAAAB4D4AD34ACAD33;C=494;L=192;
2016.12.01 00:05:47 4: sduino: Found manchester Protocol id 10 clock 494 -> OSV2o3
2016.12.01 00:05:47 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.12.01 00:05:47 4: sduino: OSV2 protocol converted to hex: (501A2D102D700660C746AC) with length (88) bits
2016.12.01 00:05:47 4: THGR228N_1 decoded Oregon: T: 6.7 H: 76 BAT: ok
2016.12.01 00:05:47 4: sduino: Found manchester Protocol id 12 clock 494 -> Hideki protocol
2016.12.01 00:05:47 1: nothing to do...
2016.12.01 00:06:20 4: sduino/msg READ: MC;LL=-1026;LH=1003;SL=-475;SH=439;D=A655565595A5556556555A55959A9A5656;C=490;L=136;
2016.12.01 00:06:20 4: sduino: Found manchester Protocol id 10 clock 490 -> OSV2o3
2016.12.01 00:06:20 4: sduino: Found manchester Protocol id 12 clock 490 -> Hideki protocol
2016.12.01 00:06:21 4: sduino/msg READ: MC;LL=-962;LH=965;SL=-483;SH=508;D=55555555334ACD32AAB2ACAD2AAB2AB2AAD2ACACD4D2B2B2;C=486;L=191;
2016.12.01 00:06:21 4: sduino: Found manchester Protocol id 10 clock 486 -> OSV2o3
2016.12.01 00:06:21 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.12.01 00:06:21 4: sduino: OSV2 protocol converted to hex: (501A2D20C4802030443722) with length (88) bits
2016.12.01 00:06:21 4: THGR228N_2 decoded Oregon: T: 20.8 H: 43 BAT: ok
2016.12.01 00:06:21 4: sduino: Found manchester Protocol id 12 clock 486 -> Hideki protocol
2016.12.01 00:06:22 4: sduino/msg READ: MU;P0=-621;P1=423;P3=246;P4=-1082;P5=886;D=3454545454545034305034305450145454105014;CP=5;
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2016.12.01 00:06:22 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.12.01 00:06:22 4: sduino/msg READ: MC;LL=-1045;LH=915;SL=-488;SH=462;D=D32AACACD0;C=484;L=37;
2016.12.01 00:06:22 4: sduino/msg READ: MC;LL=-994;LH=937;SL=-513;SH=440;D=6555A969555569A95A69595A66;C=480;L=103;
2016.12.01 00:06:22 4: sduino: Found manchester Protocol id 10 clock 480 -> OSV2o3
2016.12.01 00:06:22 4: sduino: Found manchester Protocol id 12 clock 480 -> Hideki protocol
2016.12.01 00:06:22 4: sduino/msg READ: MC;LL=-1002;LH=1001;SL=-496;SH=462;D=55555555334ACD32AACACD32AAD4B4AAAAB4D4AD34ACAD3;C=493;L=188;
2016.12.01 00:06:22 4: sduino: Found manchester Protocol id 10 clock 493 -> OSV2o3
2016.12.01 00:06:22 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.12.01 00:06:22 4: sduino: OSV2 protocol converted to hex: (501A2D102D700660C7462C) with length (88) bits
2016.12.01 00:06:22 4: THGR228N_1 decoded Oregon: T: 6.7 H: 76 BAT: ok
2016.12.01 00:06:22 4: sduino: Found manchester Protocol id 12 clock 493 -> Hideki protocol
2016.12.01 00:06:23 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/98_DBPlan.pm line 1153.
2016.12.01 00:06:39 4: sduino/KeepAliveOk: 1
2016.12.01 00:06:39 4: sduino/keepalive retry = 0
2016.12.01 00:07:01 4: sduino/msg READ: MC;LL=-981;LH=957;SL=-537;SH=438;D=55555555334ACD32AACACD32AAD4B4AAAAB4D4AD34ACAD33;C=485;L=192;
2016.12.01 00:07:01 4: sduino: Found manchester Protocol id 10 clock 485 -> OSV2o3
2016.12.01 00:07:01 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.12.01 00:07:01 4: sduino: OSV2 protocol converted to hex: (501A2D102D700660C746AC) with length (88) bits
2016.12.01 00:07:01 4: THGR228N_1 decoded Oregon: T: 6.7 H: 76 BAT: ok
2016.12.01 00:07:01 4: sduino: Found manchester Protocol id 12 clock 485 -> Hideki protocol
2016.12.01 00:07:01 4: sduino/msg READ: MC;LL=-960;LH=1034;SL=-465;SH=481;D=55555555334ACD32AACACD32AAD4B4AAAAB4D4AD34;C=489;L=167;
2016.12.01 00:07:01 4: sduino: Found manchester Protocol id 10 clock 489 -> OSV2o3
2016.12.01 00:07:01 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.12.01 00:07:01 4: sduino: OSV2 protocol converted to hex: (401A2D102D700660C7) with length (72) bits
2016.12.01 00:07:01 4: OREGON: ERROR: Unknown sensor_id=1a2d bits=64 message='401A2D102D700660C7'.
2016.12.01 00:07:01 4: sduino: Found manchester Protocol id 12 clock 489 -> Hideki protocol
2016.12.01 00:07:02 4: sduino/msg READ: MC;LL=-922;LH=1007;SL=-476;SH=505;D=55555555334ACD32AAB2ACAD2AAB2AB2AAD2ACACD4D2B2B2;C=484;L=191;
2016.12.01 00:07:02 4: sduino: Found manchester Protocol id 10 clock 484 -> OSV2o3
2016.12.01 00:07:02 4: sduino: OSV2 protocol detected: preamble_pos = 33
2016.12.01 00:07:02 4: sduino: OSV2 protocol converted to hex: (501A2D20C4802030443722) with length (88) bits
2016.12.01 00:07:02 4: THGR228N_2 decoded Oregon: T: 20.8 H: 43 BAT: ok
2016.12.01 00:07:02 4: sduino: Found manchester Protocol id 12 clock 484 -> Hideki protocol

Zitat von: Dansayisi am 01 Dezember 2016, 00:28:27
Ich habe tatsächlich einen TI-CC1101-Empfänger (s. das Bild).

Dies verwirrt mich ein wenig. Der CC1101 wird von der Signalduino Firmware gar nicht unterstützt.
Damit dieser funktioniert müssten eigentlich größere Änderungen an der Firmware vorgenommen werden.

Gruß Ralf

Das interessiert mich jetzt auch, wie hast Du den cc1101 an den Arduino angebunden? Welche Pins sind wie verbunden.

Level Shifter habe ich auch keine gesehen, der cc1101 verträgt doch nur 3,3V.
Hast Du da mal einen Link zu dem Händler, der ihn verkauft hat?

Grüße Sidey

Hallo,

Folgende Hardware habe ich gekauft:

USB Nano V3.0 ATMEGA328P:
http://www.ebay.de/itm/Hot-Mini-USB-Nano-V3-0-ATMEGA328P-Module-Board-USB-Cable-for-Arduino-SV-/131747473705?hash=item1eacc2e929:g:hrkAAOSwwpdW4DLD (http://www.ebay.de/itm/Hot-Mini-USB-Nano-V3-0-ATMEGA328P-Module-Board-USB-Cable-for-Arduino-SV-/131747473705?hash=item1eacc2e929:g:hrkAAOSwwpdW4DLD)

CC1101 Funk Module:
https://www.amazon.de/Stable-Funk-Module-Technische-externer-Antenne/dp/B00GBW6WJY/ref=sr_1_1?ie=UTF8&qid=1480608609&sr=8-1&keywords=Ultra+Stable+CC1101+Funk+Module+%2F+Technische+Grade+mit+externer+Antenne (https://www.amazon.de/Stable-Funk-Module-Technische-externer-Antenne/dp/B00GBW6WJY/ref=sr_1_1?ie=UTF8&qid=1480608609&sr=8-1&keywords=Ultra+Stable+CC1101+Funk+Module+%2F+Technische+Grade+mit+externer+Antenne)


Pins verbinden:

Ich habe die Pins wie unter diesem Link beschrieben, verbunden (die Pin 17 von Arduino Nano liefert 3,3V.):

https://techblog.one/funksteckdosen-mit-fhem-schalten/ (https://techblog.one/funksteckdosen-mit-fhem-schalten/)

Das Flashen von Arduino Nano (wie dort beschrieben wird) müsst Ihr nicht tun, das wird mit dem SIGNALDuino gemacht.


Das Modul SIGNALDuino installieren:

Dafür habe ich die Anleitung unter dem Link

http://www.fhemwiki.de/wiki/SIGNALduino (http://www.fhemwiki.de/wiki/SIGNALduino)

verwendet. Hier könnt Ihr den Arduino (Nano) wie beschrieben flashen.


Als letztes habe ich das Update von Ralf durchgeführt:

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Danach wurden meine zwei Oregon-Sender erkannt.

Gruß Tansel

Danke für die Beschreibung, aber da stimmt was nicht. Das kann nicht mit der SIGNALduino Firmware funktionieren.
Die reagiert nur auf Daten an Pin#2. Dort ist nichts angebunden.


Grüße Sidey

theoretisch könnte es funktionieren. Ich habe mal hier eine Frage gestellt:
https://forum.fhem.de/index.php/topic,61774.msg531994.html#msg531994

Gruß Ralf

Hi,

habe nun folgende Meldung im Log:
ERROR: >OREGON: ERROR: Unknown sensor_id=1a2d bits=72. < returned by the OREGON ParseFn is invalid, notify the module maintainer

Gruß,
Stefan

verwendest Du das aktuelle Oregon Modul aus der dev-r33?
Wenn Du ein fhem update machst dann hast Du wieder die alte Version.

Unter global gibt es das Attribut "exclude_from_update"

Gruß Ralf

Hi Ralf,

das Problem ist das sich Signalduino nicht installieren lässt.
Hab es im Update als Quelle dabei und es wird nach dem FHEM update normalerweise drüber gebügelt:
siehe https://forum.fhem.de/index.php/topic,62025.0.html

Gruß,
Stefan

Ja, da hat sich anscheinend beim letzten Patch von Sidey ein Fehler eingeschlichen

Zitat von: Ralf9 am 01 Dezember 2016, 21:19:08
theoretisch könnte es funktionieren. Ich habe mal hier eine Frage gestellt:

Es funktiioniert auch praktisch, wenn man den CC11001 wie beim nanocul initialisiert.
https://forum.fhem.de/index.php/topic,38561.msg534333.html#msg534333

Gruß Ralf

Hallo zusammen,

habe gestern ein Udpate gemacht seit dem hab ich ständig:

2016.12.06 07:05:36.624 1: ERROR: >OREGON: ERROR: Unknown sensor_id=2a80 bits=112.
< returned by the OREGON ParseFn is invalid, notify the module maintainer


fortlaufend im Log, wie kann ich das wieder abschalten?

Grüße
Torte

Hallo Torte,

Das Problem wurde bereits analysiert.
Du kannst es lösen, wenn Du Folgenden Befehl auslöst:



update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Grüße Sidey
   

Hi Sidey,

danke für die Info,

läuft heute morgen nur noch nicht  ???


2016.12.06 07:48:59.540 1: backup done: FHEM-20161206_074811.tar.gz (30496096 Bytes)
2016.12.06 07:49:00.045 1: UPD FHEM/14_SD_WS.pm
2016.12.06 07:49:00.225 1: Got 16924 bytes for FHEM/14_SD_WS.pm, expected 13075
2016.12.06 07:49:00.228 1: aborting.
2016.12.06 07:49:12.609 1: ERROR: >OREGON: ERROR: Unknown sensor_id=2a82 bits=112.
< returned by the OREGON ParseFn is invalid, notify the module maintainer


probiere es im laufe des Tages noch mal....

Grüße
Torte

Uups,. Habe es korrigiert. Das Update müsste jetzt funktionieren

Perfekt  :) :)

Meldungen im Log sind weg, Danke!

Viele Grüße
Torte

Update geht wieder, Meldungen sind weg im Log.

Super! Vielen Dank!

hallo
habe ich das richtig verstanden, dass man den signalduino mit dem CC1101 verwenden kann?
Ich habe nämlich den SelbstbauCUL mit cc1101 https://wiki.fhem.de/wiki/Selbstbau_CUL (https://wiki.fhem.de/wiki/Selbstbau_CUL)
in verwendung, kann ich den "einfach" mit der SignalDuino FW flashen und dann kann ich auch empfangen? was muss ich beachten/ändern/bearbeiten damit der SIGNALduino mit cc1101 funktioniert?

Danke lg
michl

Zitat von: Michl1003! am 12 Dezember 2016, 10:03:38
habe ich das richtig verstanden, dass man den signalduino mit dem CC1101 verwenden kann?

Ja, wenn der CC1101 richtig initialsiert wird, kann man den signalduino mit dem CC1101 verwenden.
Dazu muß die  initialsierung des CC1101 noch in die Signalduino FW eingebaut werden.

Gruß Ralf

Hallo Sidey,

hast Du inzwischen von Willi eine Antwort wegen dem Oregon Modul bekommen?

Gruß Ralf

Nein, die Frage ist halt jetzt, wer will der neue maintainer werden

Immer noch keiner da, der Willi entlasten/unterstützen/ablösen will?
Die Error-Meldungen im Log sind unschön...

Zitat von: RappaSan am 18 Dezember 2016, 10:53:01
Immer noch keiner da, der Willi entlasten/unterstützen/ablösen will?
Die Error-Meldungen im Log sind unschön...

Warum nimmst Du nicht einfach das von mir angepasste Oregon Modul, dort sind die Fehler beseitigt.
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/FHEM/41_OREGON.pm

Hier ist das angepasste Oregon Modul enthalten:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

siehe auch
https://forum.fhem.de/index.php/topic,62695.0.html

Gruß Ralf

Danke, hab' das Update durchgeführt.

Moin,

nach dem Update und einem restart sind bei mir auch die nervigen Logs weg, danke  :)

Gruß
Mathias

Hallo,

hier gibt es Probleme mit dem event-min-interval beim Oregon Modul, ich ging eigentlich davon aus, daß es funktioniert
https://forum.fhem.de/index.php/topic,63643.msg548842.html#msg548842

Funktioniert bei euch das event-min-interval beim Oregon Modul?

Gruß Ralf

Nö, ob's da ist oder nicht -  kein Unterschied.

Ich wüsste gerade nicht, wie man das im Modul implementiert oder eben nicht..

Liegt es evtl daran, daß das event über DoTrigger und nicht über readingsEndUpdate erzeugt wird?

Ich habe mir den Code angesehen... Es liegt daran, dass Willi direkt in die Variablen Reading die Werte geschrieben hat und nicht mit Reading Update gearbeitet hat.

Das sollte sich leicht lösen lassen.

Bezüglich Maintainer hat sich niemand gemeldet, ich werde es dann formal übernehmen.

Ich habe das 41_Oregon angepasst:

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Habe es mit einem Temperatursensor bei mir getestet und es funktioniert meiner Meinung nach.

Grüße Sidey

@Ralf

ich habe mal ein Patch erstellt um das 41_Oregon zwischen FHEM Update und unserem git zu vergleichen

Du hast dort einen Sensor entfernt, funktioniert der wirklich nicht oder können wir den wieder aufnehmen?


Grüße Sidey

Du meinst wahrscheinlich diese beiden Sensoren

   OREGON_type_length_key(0x3a0d, 80) =>

   # RGR126, RGR682, RGR918:
   OREGON_type_length_key(0x2a1d, 80) =>

Durch meine Anpassung werden bei den beiden Sensoren auch die Nachrichtenlängen 84 und 88 berücksichtigt. Dadurch sind die beiden gelöschten Sensoren mit den doppelten Ids nicht mehr notwendig

Gruß Ralf

Ich meine den WGR918. Wird der durch rgr918 ersetzt?

Zitat von: Sidey am 31 Dezember 2016, 14:52:03
Ich meine den WGR918. Wird der durch rgr918 ersetzt?

Der ist doch in Zeile 201 drin
part => 'WGR918', checksum => \&OREGON_checksum4, method => \&OREGON_wgr918_anemometer,

OK, habe ich auf dem Handy übersehen

Ein "Frohes neues Jahr" in die Runde.  :)

Kleine Rückmeldung: event-min-interval  funktioniert nach Sidey's patch bei mir.

Moin,

bin etwas verwirrt (kommt schon mal vor, aber diesmal ist es was technisches;-) ): 

Ich habe im Dezember 2016 eine WH5300 Wetterstation gekauft und diese wurde vom SignalDuino als CTW600 erkannt:
Internals:
   CODE       CTW600
   DEF        CTW600
   NAME       CTW600
   NR         223
   STATE      Defined
   TYPE       SD_WS09
   bitMSG
   lastMSG
   Readings:
     2017-01-05 20:52:51   battery         4
     2017-01-05 20:52:51   humidity        64
     2017-01-05 20:52:51   id              41
     2017-01-05 20:52:51   rain            27.9
     2017-01-05 20:52:51   state           T: -4.7  H: 64  Ws: 0.0  Wg: 0.0  Wd: W  R: 27.9
     2017-01-05 20:52:51   temperature     -4.7
     2017-01-05 20:52:51   windDirection   12
     2017-01-05 20:52:51   windDirectionDegree 270
     2017-01-05 20:52:51   windDirectionText W
     2017-01-05 20:52:51   windGust        0.0
     2017-01-05 20:52:51   windSpeed       0.0
Attributes:
   alias      WH5300
   icon       WH5300
   room       21-SignalDuino RX6B,22-SignalDuino CC1101,Garten
   showtime   1
   stateFormat temperature °C
   
Lief über meherere Wochen einwandfrei (mit dem RSSI Wert -78).
Dann am 5.1.2017 kamen plötzlich keine neuen Werte mehr an.

Stattdessen hat FHEM eine WH1080 erkannt und angelegt (Status "defined", aber es kommen auch keine Werte an).

Im Log sehe ich, dass nun ein Protokoll id 10 (ich denke das fällt in die Oregon Sparte) erkannt wird
2017.01.07 15:34:02 4 : SingalDuino.cc1101: Found manchester Protocol id 10 clock 329 -> OSV2o3
Aber ein entsprechendes Device wird nicht erstellt.

Und neu sind die Protokolle mit den ids 20+29+40+57 ...

ID 29 (HT12e remote)
Das id 29 - Gerät können wir, glaube ich aussen vor lassen, weil das vom RSSI Wert eher bei den Nachbarn steht:
2017.01.07 17:16:44 4 : SingalDuino.cc1101: decoded matched MU Protocol id 29 dmsg u29#000 length 12 RSSI = -82.5
2017.01.07 17:16:44 4 : SIGNALduino_unknown incomming msg: u29#000
2017.01.07 17:16:44 4 : SIGNALduino_unknown rawData: 000
2017.01.07 17:16:44 4 : SIGNALduino_unknown Protocol: 29
2017.01.07 17:16:44 4 : SIGNALduino_unknown converted to bits: 000000000000
2017.01.07 17:16:44 4 : Unknown, please report
2017-01-07 17:16:44 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u29#000
2017.01.07 17:16:44 3 : SingalDuino.cc1101: Unknown code u29#000, help me!


&

ID 40 (romotec)
sagt mir überhaupt nichts, ist aber vom Empfangswert (RSSI) gleich der Wetterstation:
2017.01.07 17:22:09 4 : SingalDuino.cc1101: decoded matched MU Protocol id 40 dmsg u40#28423CF7385 length 44 RSSI = -78
2017-01-07 17:22:09 SIGNALduino SingalDuino.cc1101 opened
2017.01.07 17:22:09 4 : SIGNALduino_unknown incomming msg: u40#28423CF7385
2017.01.07 17:22:09 4 : SIGNALduino_unknown rawData: 28423CF7385
2017.01.07 17:22:09 4 : SIGNALduino_unknown Protocol: 40
2017.01.07 17:22:09 4 : SIGNALduino_unknown converted to bits: 00101000010000100011110011110111001110000101
2017.01.07 17:22:09 4 : Unknown, please report
2017-01-07 17:22:09 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u40#28423CF7385
2017.01.07 17:22:09 3 : SingalDuino.cc1101: Unknown code u40#28423CF7385, help me!

&

ID 20 (livolo)
sagt mir überhaupt nichts, ist aber vom Empfangswert (RSSI) gleich der Wetterstation:
2017.01.07 17:22:10 4 : SingalDuino.cc1101: decoded matched MU Protocol id 20 dmsg u20#FFFFFF length 24 RSSI = -78
2017.01.07 17:22:10 4 : SIGNALduino_unknown incomming msg: u20#FFFFFF
2017.01.07 17:22:10 4 : SIGNALduino_unknown rawData: FFFFFF
2017.01.07 17:22:10 4 : SIGNALduino_unknown Protocol: 20
2017.01.07 17:22:10 4 : SIGNALduino_unknown converted to bits: 111111111111111111111111
2017.01.07 17:22:10 4 : Unknown, please report
2017-01-07 17:22:10 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u20#FFFFFF
2017.01.07 17:22:10 3 : SingalDuino.cc1101: Unknown code u20#FFFFFF, help me!

&

ID 57 (m-e)
sagt mir überhaupt nichts, ist aber vom Empfangswert (RSSI) gleich der Wetterstation
2017.01.07 17:22:10 4 : SingalDuino.cc1101: Found manchester Protocol id 57 clock 339 RSSI -78 -> m-e
2017.01.07 17:22:10 4 : SIGNALduino_unknown incomming msg: u57#420AA2801520
2017.01.07 17:22:10 4 : SIGNALduino_unknown rawData: 420AA2801520
2017.01.07 17:22:10 4 : SIGNALduino_unknown Protocol: 57
2017.01.07 17:22:10 4 : SIGNALduino_unknown converted to bits: 010000100000101010100010100000000001010100100000
2017.01.07 17:22:10 4 : Unknown, please report
2017-01-07 17:22:10 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u57#420AA2801520
2017.01.07 17:22:10 3 : SingalDuino.cc1101: Unknown code u57#420AA2801520, help me!

Diese Geräte/Protokolle hat es vor dem 5.1.2017, meiner Meinung, nach noch nicht im Log gegeben.

Was noch komisch ist, dass das Protokoll id 10 nur eine einzige Zeile auswirft:
2017.01.07 15:34:02 4 : SingalDuino.cc1101: Found manchester Protocol id 10 clock 329 -> OSV2o3

Die anderen sind immer mehrzeiler mit decodier versuchen.


Verbose ist auf 4
In der Anlage hab ich noch mal ein komplettes Log über 30 Minuten angefügt.

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
hatte ich heute (7.1.2017) um ~16:30 gemacht.

Steh nun irgendwie auf dem Schlauch.


Gruß
Seq

Zitat von: Sequenzial am 07 Januar 2017, 18:20:57
Ich habe im Dezember 2016 eine WH5300 Wetterstation gekauft und diese wurde vom SignalDuino als CTW600 erkannt:

Dies passt zu diesem Thema nicht so richtig, da es hier um Oregon Sensoren geht.

Wenn ein Oregon Sensor erkannt wird, dann steht im log auch noch die folgende Zeile:
sduino: OSV2 protocol detected: preamble_pos = 33


Wird die WH5300 von dem sduino mit dem RX6B erkannt?

Gruß Ralf

Hi,

Zitat von: Ralf9 am 07 Januar 2017, 21:03:42
Dies passt zu diesem Thema nicht so richtig, da es hier um Oregon Sensoren geht.

Wenn ein Oregon Sensor erkannt wird, dann steht im log auch noch die folgende Zeile:

Code Auswählen Erweitern

sduino: OSV2 protocol detected: preamble_pos = 33

hmm, was mich hierher getrieben hat war halt die Protokoll ID 10
2017.01.07 15:34:02 4 : SingalDuino.cc1101: Found manchester Protocol id 10 clock 329 -> OSV2o3
was ich erstmal als Oregon interpretiert habe.
Wo wäre ich damit denn besser aufgehoben?
Ich war über die SignalDuino Entwicklung 3.3.1 hier her "gestolpert".

Zitat
Wird die WH5300 von dem sduino mit dem RX6B erkannt?

ja ... hmm ...
cc1101 abgezogen und den RX6B dran gehängt.
Hab im Attachment mal das Debug Log + Verbose 4 gehängt (und diesmal auf SignalDuino gefiltert)
Der empfängt schon was, aber so richtig schlau was er empfängt werde ich nicht aus dem Log.

Aber irgendwie kommt mir das unvollständig vor
2017.01.07 23:29:03 4 : SingalDuino.rx6b/msg READ: MU;P0=-973;P1=1446;P3=450;P4=684;P5=-232;P6=1088;D=01010101010101010101030101010101045301010106;CP=1;
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: incomming message: (MU;P0=-973;P1=1446;P3=450;P4=684;P5=-232;P6=1088;D=01010101010101010101030101010101045301010106;CP=1;)
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 0 -973
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 1 1446
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 3 450
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 4 684
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 5 -232
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 6 1088
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted data 01010101010101010101030101010101045301010106
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted clockidx 1
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: processing unsynced message
2017.01.07 23:29:03 1 : DEBUG>Testing against Protocol id [...]
Rest -> Attachment

Es kommt meiner Meinung nach keine abschließende Meldung das ein decodieren (via Protokoll ID) möglich war oder eben nicht...
Der cc1101 sagt zumindest, dass er damit nichts anfangen kann.

Die Empfangseinheit von der Wetterstation bekommt ihre Daten noch einwandfrei,
insofern gehe ich davon aus, dass an der Quelle der Fehler nicht liegt.


Ich werde die Wetterstation noch mal komplett "resetten" und die angelegten Devices aus der fhem.cfg löschen.

Aber du hast schon recht, dass ich bei den Oregons nicht richtig bin.
Werde hier einen neuen Versuch starten:
    FHEM Forum » CUL » Hard- und Firmware » günstige Wetterstation CTW-600, WS-0101, WS/WH1080 sduino

(bitte ggf. die letzten Posts von mir hier raus nehmen)

Danke erst mal!

Gruß
Seq

Zitat von: Ralf9 am 29 Dezember 2016, 20:28:03
Hallo,

hier gibt es Probleme mit dem event-min-interval beim Oregon Modul, ich ging eigentlich davon aus, daß es funktioniert
https://forum.fhem.de/index.php/topic,63643.msg548842.html#msg548842

Funktioniert bei euch das event-min-interval beim Oregon Modul?

Gruß Ralf

So ein Modul mit diesem Fehler gibt's noch:

Internals:
   CFGFN
   CODE       SD_WS07_TH_1
   DEF        SD_WS07_TH_1
   LASTInputDev sduino
   MSGCNT     6
   NAME       SD_WS07_TH_1
   NR         333
   STATE      T: 12.6 H: 58
   TYPE       SD_WS07
   bitMSG     10110101 1 000 000001111110 1111 00111010
   lastMSG    B5807EF3A
   lastReceive 1492105063
   sduino_DMSG P7#B5807EF3A
   sduino_MSGCNT 6
   sduino_RAWMSG MS;P4=-3867;P5=467;P6=-1989;P7=-997;D=54565756565756575656575757575757575756565656565657565656565757565656575657;CP=5;SP=4;O;
   sduino_TIME 2017-04-13 19:37:43
   Readings:
     2017-04-13 19:37:43   battery         ok
     2017-04-13 19:37:43   channel         1
     2017-04-13 19:37:43   humidity        58
     2017-04-13 19:37:43   state           T: 12.6 H: 58
     2017-04-13 19:37:43   temperature     12.6
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   room       Autocreated

Das Attribut event-min-interval spielt keine Rolle, hier wird ein event ca. alle 20 Sekunden ausgelöst.  :(

Hallo,

ich benötige zum Testen von einem Oregon v3 und von den folgenden Oregon v2 Sensoren die empfangenen Nachrichten als MU-Nachrichten.
THN132N
THGR228N
WGR918 oder BTHR918N

Dazu muß mit
set sduino disableMessagetype syncedMS
und
set sduino disableMessagetype manchesterMC
der MS- und MC-Decoder deaktivert werden.

Die MU-Nachrichten benötige ich zum Testen von einem komplett überarbeitetem MC-Decoder.

Gruß Ralf

Hi Ralf,

haben wir doch alles:

OSV3:

String dstr(F("MU;P0=-296;P1=420;P2=-581;P3=-1090;P4=887;D=01212121212121212121212121212121212121212134343431243124213121212124312121212124212121312431212121212121212121212121212121212121242131212121;"));

String dstr2(F("MU;P0=-542;P1=434;P2=-1040;P3=911;D=01010101010101010101012323210103012101010103012101010101010321010323210301210101030101210101032301012101010301010101010101010101232321010301210101010301210101010101032101032321030121010103010121010103230101210101030101010101010101010123232101030121010101;"));

String dstr2(F("MU;P0=-1198;P1=1676;P2=-541;P3=433;P4=-160;P5=124;P7=905;D=012345432323232323232323232323232323232323232323070723232323032327070323232707032327230323272323230323272323032723032323232323232323232327032703270327230703270323232707032;CP=3;"));


Für OSV2 liegt es auch vor, sogar mit dem korrekten Ergebnis:

  std::string fullpreamble("MU;P1=-1063;P2=881;D=212121212121212121212121212121212;");
  std::string shortpreamble("MU;P0=385;P1=-1063;P2=881;D=01212121212121212121212;");
  std::string data("MU;P0=-1580;P1=873;P2=-1071;P3=-591;P4=388;P5=-3076;D=3424313424313424313424313421243121213424312121213421243134243134243121342124313421212121243134243121342124313421243121342121212121212121212121212431342431342124313424313421245;");
  std::string spDataHex = "555554CCCCB5354B334B2AB34B2D2AAAAAB32CCA";  // Short Preamble + data in HEX Format
  std::string fpDataHex = "AAAAAAAACCCCD2B2AD332D35532D34B555555334CD0";  // Short Preamble + data in HEX Format

OSV1 ebenso:
dstr = String(F("MU;P0=-27224;P1=1673;P2=-1260;P3=-4304;P4=5712;P5=-6752;P6=3145;P7=-2718;D=345126712671212121267621712121212121212121212621712126;CP=1;R=245;")); // Lange pause zwischen den Wiederholungen einbauen


Ich hab auch noch Maverick, X10 und etliches mehr.

Grüße Sidey

Könnt Ihr auch Oregon senden mit dem S'duino oder scheitert das an den checksums ?
Grüße Markus

Wir können das was wir empfangen auch wieder senden.
Wenn Du aber eigene Temperaturen senden willst mußt Du auch die checksums neu berechnen.

Gruß Ralf

Hallo Sidey,

bei OSV3 funktioniert nur der dritte String, mit den ersten beiden kann ich nichts anfangen.

Mit dem Baukasten zum selberzusammenbauen einer OSV2 Nachricht kann ich auch nichts anfangen, ich benötige die komplette MU-Nachricht.

Gruß Ralf

ZitatWenn Du aber eigene Temperaturen senden willst mußt Du auch die checksums neu berechnen.

Genau das hab ich vor, um meinen ungenauen Außensensor für die Station zu ersetzen.  ;) Dann muss ich das in den CUL basteln...
Danke&Grüße Markus

Zitat von: Ralf9 am 18 Februar 2018, 21:34:30
Hallo Sidey,

bei OSV3 funktioniert nur der dritte String, mit den ersten beiden kann ich nichts anfangen.

Was Funktioniert da nicht?

Zitat von: Ralf9 am 18 Februar 2018, 21:34:30
Mit dem Baukasten zum selberzusammenbauen einer OSV2 Nachricht kann ich auch nichts anfangen, ich benötige die komplette MU-Nachricht.

Was genau ist das Problem?
Ich jage die auch in den Decoder und das klappt. Jeden String halt nacheinander:

Die 1. Nachricht hat eine kürzere Preamble (shortpreamble) und dann kommen die eigentlichen Daten (data)
Die 2. Nachricht hat dann die komplette Preamble (fullpreamble) und dann kommen die gleichen Daten wieder (data).

Bei der 1. Nachricht fehlt ein Teil der preamble, da der Empfänger erst noch sein AGC macht.

Grüße Sidey

Der RTHN318 hat nur eine Länge von 64 Bit. Ich benötige zum Testen auch längere Nachrichten wie z.B.
THGR228N
WGR918 oder BTHR918N

Bei der ersten OSV3 Nachricht bekomme ich vom Oregon Modul eine Fehlermeldung
und bei der zweiten OSV3 Nachricht passt irgend was nicht.

Gruß Ralf

@stefanru liest Du hier mit?
Wenn ich das richtig überblicke müsstest Du die gesuchten Oregon Sensoren haben.
Könnte ich von Dir bitte ein Log-Auszug mit MU-Nachrichten und mit verbose 4 von ca 5-10 Minuten haben?

Dazu mit
set sduino disableMessagetype syncedMS
und
set sduino disableMessagetype manchesterMC

den MS- und MC-Decoder deaktivieren.
Wenn Du dann noch in das Attribut WhitelistId nur 0 einträgst, dann wird das Log übersichtlicher.

Danke

Gruß Ralf

Zitat@stefanru liest Du hier mit?
Wenn ich das richtig überblicke müsstest Du die gesuchten Oregon Sensoren haben.
Könnte ich von Dir bitte ein Log-Auszug mit MU-Nachrichten und mit verbose 4 von ca 5-10 Minuten haben?

Das log kann natürlich auch gerne jemand anders  posten der diese Sensoren hat:
THGR228N oder THGN122N
BTHR918 oder BTHR918N oder  BTHR968

Gruß Ralf

Ich habe hier an einem Nano Cul welche, die FHEM als "THGR228N_77_1" erkennt.

Kann ich dir helfen oder muss es der SignalDuino sein?

Nein, mit einem Cul kannst Du mir nicht helfen, dies geht nur mit einem Signalduino.

Gruß Ralf

Hi Ralf,
ich blick bei Euch noch nicht so ganz durch woher welche Sourcen/Firmware zu nehmen sind. Wenn Du mir einen Link postest, könnte ich versuchen meinen nanoCUL als S'duino zu flashen und dann testen.
Grüße Markus

Hallo Ralf,

hab mal ein log gezogen mit den settings die du geschrieben hast. Stammt alles vom gleichen (weil einzigen) THGR228N.
Hoffe du kannst damit was anfangen. Falls du mehr oder was anderes brauchst sag Bescheid. Ich hab aus dem Oregon Zoo auch noch andere Tiere hier ;)

lg, Christina

Hallo Christina,

Danke für das Log. Ich habe es mir angeschaut. Es waren einige brauchbare Nachrichten vom THGR228N dabei. Welche Firmwareversion hast Du?
Für mich sieht es so aus als wären zwei THGR228N auf dem selben Kanal 2.

THGR228N_2 T: 19.8 H: 42 BAT: ok
THGR228N_2 T: 15.6 H: 38 BAT: ok

Gruß Ralf

Zitat von: KölnSolar am 20 Februar 2018, 07:48:56
ich blick bei Euch noch nicht so ganz durch woher welche Sourcen/Firmware zu nehmen sind. Wenn Du mir einen Link postest, könnte ich versuchen meinen nanoCUL als S'duino zu flashen und dann testen.

Hallo Markus,

die aktuelle Version ist z.Zt. die 3.3.1-dev
https://github.com/RFD-FHEM/RFFHEM/tree/dev-r33/FHEM/firmware

Im normalen fhem update ist die Version 3.3.0, diese ist nicht mehr zu empfehlen. Bei dieser ist z.B. die Ausgabe der Wiederholungen bei MS-Nachrichten fehlerhaft.

Es gibt von mir und von Sidey eine Entwicklungsversion, dort wurden einige Fehler behoben und einiges optimiert. Bei diesen Versionen kann es ein, daß noch nicht alles 100% funktioniert.

Du kannst zum Testen mal meine Firmware 3.3.2 nehmen
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332r.hex

Bitte mal schauen ob diese kurze Anleitung fürs flashen ausreichend ist:
https://forum.fhem.de/index.php/topic,58397.msg762083.html#msg762083

Bei den Modulen sind normalerweise die vom normalen fhem update (svn) ausreichend.

Mit dem folgenden Befehl kannst Du die config anschauen
get sduino config

Wenn Du auch noch mit
get sduino raw CSmuthresh=0
den split von MU Nachrichten ausgeschaltet hast, müsste die config so aussehen:

config: MS=0;MU=1;MC=0;...;MuSplitThresh=0;

Mit dem neuen Befehl "eC" kannst Du die im EEPROM gespeicherte konfig wieder auf default zurücksetzen

Gruß Ralf

ZitatWelche Firmwareversion hast Du?

V 3.3.1-dev

ZitatFür mich sieht es so aus als wären zwei THGR228N auf dem selben Kanal 2.

du hast sehr wahrscheinlich recht ... ich hab 3 Stk. davon, es ist zwar nur einer im sduino definiert aber senden tun ja trotzdem alle  :)

Ich könnte noch MU-Nachrichten von einem Oregon V3 und einem der folgenden Oregon V2 Sensoren gebrauchen
BTHR918 oder BTHR918N oder  BTHR968

Gruß Ralf

Oregon V3 habe ich (THGR810), log kann ich dir abends liefern. Die BTHRs hab ich leider nicht.
lg, Christina

Zitat von: Wetterhexe am 21 Februar 2018, 12:16:36
Oregon V3 habe ich (THGR810), log kann ich dir abends liefern. Die BTHRs hab ich leider nicht.

Ok, dann benötige ich nur noch die Logs von den BTHRs .

Liest hier niemand mit der diese BTHRs hat?

Gruß Ralf

Zitat von: Wetterhexe am 21 Februar 2018, 12:16:36
Oregon V3 habe ich (THGR810), log kann ich dir abends liefern.

Ja, das wäre für mich hilfreich, wenn Du mir ein log vom Oregon V3 liefern könntest.

Gruß Ralf

sorry bin erst jetzt dazugekommen

Vielen Dank für das log.
Ich habe darin zwei THGR810 gefunden:
THGR810_2 T: 18.2 H: 45 BAT: ok
THGR810_4 T: 20.2 H: 37 BAT: ok

Bis auf die BTHRs habe nun alles was ich benötige.

Die logs habe ich benötigt um zu testen ob der komplett überarbeitete ManchesterDecoder meiner neuen V 3.3.2-dev firmware die Oregon Sensoren noch sauber erkennt.
https://forum.fhem.de/index.php/topic,82379.msg766909.html#msg766909

Gruß Ralf

Hi Ralf,
das definieren und flashen des nanoCUL hat relativ problemlos geklappt.

version V 3.3.2b-dev SIGNALduino cc1101 - compiled at Feb 13 2018 20:39:29
aber trotz

Zitatget sduino raw CSmuthresh=0

bekomme ich immer:

config MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=0;MdebFifoLimit=80

Meine Revolts wurden erkannt. Ebenso 3 THGR122N als THGR228N u. ein THGN500 als THGR918. Genau wie beim RFXTRX. IT V1 u. V3 von meiner Betty wurden nicht erkannt. Ist aber zu speziell, um sich Gedanken darüber zu machen. Entsprechende Signale mit dem RFXTRX wurden erkannt.

Ab und zu hab ich u20er unterschiedlicher Länge, wo ich mir keinen Reim drauf machen kann. Manchmal u61er, die vom nicht immer erkannten IT-PIR1000 stammen.

Ich vermisse regelmäßige Meldungen meiner FA21RFFA20RF(u13). Testauslösung ist mir zu laut  ;D

Wenn ich etwas testen soll, melde Dich.
Grüße Markus

Zitat von: KölnSolar am 23 Februar 2018, 12:49:45
Hi Ralf,
das definieren und flashen des nanoCUL hat relativ problemlos geklappt.

Code Auswählen Erweitern


version V 3.3.2b-dev SIGNALduino cc1101 - compiled at Feb 13 2018 20:39:29
aber trotz bekomme ich immer:

Code Auswählen Erweitern


config MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=0;MdebFifoLimit=80

Meine Revolts wurden erkannt. Ebenso 3 THGR122N als THGR228N u. ein THGN500 als THGR918. Genau wie beim RFXTRX. IT V1 u. V3 von meiner Betty wurden nicht erkannt. Ist aber zu speziell, um sich Gedanken darüber zu machen. Entsprechende Signale mit dem RFXTRX wurden erkannt.

Hallo Markus,

Danke für das Testen.

MS=0 bekommst Du mit
set sduino disableMessagetype syncedMS

MC=0 bekommst Du mit
set sduino disableMessagetype manchesterMC

Mit "set sduino enableMessagetype .." kannst Du sie wieder aktivieren

Nachrichten mit MS=0 und MC=0 benötige ich nur noch von den  BTHRs


Zu dem Rest habe ich Dir hier geantwortet:
https://forum.fhem.de/index.php/topic,82379.msg771612.html#msg771612

Gruß Ralf

Hallo zusammen

Eigentlich wollte ich drei Oregon Sensoren THGR221 in Betrieb nehmen. Habe dann gesehen, dass die leider nicht implementiert sind im 41_OREGON.pm.
Besteht da die Möglichkeit, dass sich dem jemand annehmen möchte? Ich selber bin dafür leider zu wenig bewandert.

Gruss und Dank
David

Da der THGR221 ein neuer Sensor ist, ist der noch nicht in der 41_OREGON.pm enthalten.
Wo ist der schon erhältlich?

Wenn Du mir einige MC Nachrichten mit dazugehöriger Temperatur und Feuchtigkeit hast, schaue ich es mir mal an.
Die raw Nachrichten sehen ungefähr so aus:
MC;LL=-1043;LH=907;SL=-515;SH=466;D=FFFFFF5891200D0A030000004CB800;C=457;

Gruß Ralf

Hallo Ralf

Drei THGR221 sind bei der Wetterstation RAR502SX dabei. Diese Wetterstation ist auch auf amazon erhältlich. Ist meiner Meinung nach auch ein guter Preis für drei Sensoren.
Ich habe mal versucht die raw-Nachrichten zu erwischen. Es ist etwas schwierig zu erkennen, was effektiv von diesem Sensor gesendet wird. Ich denke Du kannst das besser beurteilen.
Um genau 21:04:00 habe ich die Batterien eingelegt. Anzeige auf Display: 22,6°C / 53%RH

2018.12.07 21:04:03 4: sduino/msg READ: MU;P0=910;P1=184;P2=136;P3=-1508;P4=421;P5=-1037;P7=-552;D=234547074547050745470745050505050505470745054707450505470505050745050505050505470507450547074505050505050505470745054705050507450505470505050505074505470745470505074547050507451;CP=0;R=243;
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 40 -> romotec matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.12.07 21:04:03 4: sduino/msg READ: MC;LL=-1045;LH=912;SL=-548;SH=409;D=66995559656A9555A5955565AA56AA966A6A0;C=485;L=145;R=242;
2018.12.07 21:04:03 4: sduino: Found manchester Protocol id 10 clock 485 RSSI -81 -> OSV2o3
2018.12.07 21:04:03 4: sduino: Found manchester Protocol id 12 clock 485 RSSI -81 -> Hideki protocol
2018.12.07 21:04:03 4: sduino: hideki start pattern (10101110) not found
2018.12.07 21:04:03 4: sduino: Found manchester Protocol id 52 clock 485 RSSI -81 -> OS_PIR
2018.12.07 21:04:03 4: sduino: Found manchester Protocol id 58 clock 485 RSSI -81 -> tfa 30.3208.0
2018.12.07 21:04:03 4: sduino/msg READ: MU;P0=324;P1=-1983;P2=464;P3=-4072;P4=-8944;P6=212;P7=-32001;D=6701212321232423212323212323212121212121232123212323212121212121212121212321212123212;CP=2;R=224;
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 13.1 -> FLAMINGO FA21 b matches, trying to demodulate
2018.12.07 21:04:03 4: sduino: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.12.07 21:04:04 4: sduino/msg READ: MS;P1=438;P2=-2000;P3=-4128;P4=-8947;D=14131213131213131212121212121312131213131212121212121212121213121212131213;CP=1;SP=4;R=224;
2018.12.07 21:04:04 4: sduino: Matched MS Protocol id 0 -> weather1
2018.12.07 21:04:04 4: sduino: Decoded MS Protocol id 0 dmsg sB60560045000 length 40 RSSI = -90
2018.12.07 21:04:04 4: sduino: CUL_TCM97001 hex:d60a6002a000  msg:B60560045000 aR:d 6 0 a 6 0 0 2 a 0 0 0
2018.12.07 21:04:04 4: sduino: CUL_TCM97001 nib2:00 aRev: 0
2018.12.07 21:04:04 4: sduino: CUL_TCM97001 nib2R:00 hexR: d60a6002a000
2018.12.07 21:04:04 4: sduino: CUL_TCM97001 Temp/Hum Msgype: 00 nib3:a
2018.12.07 21:04:04 4: sduino: CUL_TCM97001 using longid: 1 model: TCM21....
2018.12.07 21:04:04 4: sduino: Matched MS Protocol id 68 -> PFR-130
2018.12.07 21:04:04 4: sduino: Decoded MS Protocol id 68 dmsg sB60560045000 length 40 RSSI = -90
2018.12.07 21:04:04 4: sduino Dispatch: sB60560045000, Dropped due to short time or equal msg
2018.12.07 21:04:15 4: sduino/msg READ: MC;LL=-991;LH=958;SL=-511;SH=464;D=34CAAB2AD5548;C=487;L=49;R=242;
2018.12.07 21:04:15 4: sduino: Found manchester Protocol id 52 clock 487 RSSI -81 -> OS_PIR
2018.12.07 21:04:15 4: sduino/msg READ: MC;LL=-988;LH=967;SL=-504;SH=467;D=D7AEA9D377E6BF5A48;C=486;L=470;R=37;
2018.12.07 21:04:15 4: sduino: Found manchester Protocol id 10 clock 486 RSSI -55.5 -> OSV2o3
2018.12.07 21:04:15 4: sduino: Found manchester Protocol id 12 clock 486 RSSI -55.5 -> Hideki protocol
2018.12.07 21:04:15 4: sduino: Found manchester Protocol id 52 clock 486 RSSI -55.5 -> OS_PIR
2018.12.07 21:04:15 4: sduino: Found manchester Protocol id 58 clock 486 RSSI -55.5 -> tfa 30.3208.0
2018.12.07 21:04:23 4: sduino/keepalive ok, retry = 0


Bitte einfach sagen, wenn Du noch mehr wissen musst. Vielen Dank.
Grüsse David

Hallo Ralf

Jetzt habe ich gerade gesehen, dass über autocreate ein device mit dem Code THGR810 erzeugt wurde. Da kommen aber nur sehr sporadisch Werte rein.
Vielleicht hilft Dir das noch weiter.

Gruss David

ZitatJetzt habe ich gerade gesehen, dass über autocreate ein device mit dem Code THGR810 erzeugt wurde. Da kommen aber nur sehr sporadisch Werte rein.
Vielleicht hilft Dir das noch weiter.

Passt Da die Temperatur und Feuchtigkeit?

Bei Deinem log sind MC-Nachrichten dabei, es sieht so aus als würden sie nicht sauber empfangen. Wie ist die Entfernung von den THGR221 zum sduino?

Gruß Ralf

Ja, die Temperatur und Luftfeuchtigkeit passen. Die Distanz zwischen THGR221 und sduino beträgt nur ca. 4m. Die sind im gleichen Raum.
Gruss David

was ergibt ein
get version
get ccconf

Gruß Ralf

version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Gruss David

Du hast eine recht alte firmware von 2017, Du kannst mal eine aktuelle firmware testen
https://wiki.fhem.de/wiki/SIGNALduino

Evtl bringt es was die bWidth z.B. auf 541 kHz zu erhöhen

Gruß Ralf

Hallo Ralf

Die Firmware habe ich aktualisiert und auch die Bandbreite vergrössert. Das hat an der Situation leider nichts geändert. Seit längerem habe ich auch zwei THGR122NX in Betrieb. Dort kommen schön regelmässig alle Werte rein.
Könnte das vielleicht weiter helfen:
https://fccid.io/NMTTHGR221-01/Test-Report/Test-Report-4066974.html (https://fccid.io/NMTTHGR221-01/Test-Report/Test-Report-4066974.html)

Grüsse David

Hast Du mir nochmals einige raw-Nachrichten, es müssten MC-Nachrichten sein.
Haben die THGR221 auch eine LED, damit Du erkennen kannst, wann sie senden?

Gruß Ralf

Hallo Ralf

Ich wollte auf dem nanoCUL noch eine alternative firmware testen. Leider kriege ich jetzt gar keine firmware mehr drauf.
FHEM: "sduino is not active, may firmware is not suppoted, please flash or reset"
pi@raspberrypi:~ $ sudo avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTD                                                                                                                                   I_FT232R_USB_UART_00000000-if00-port0 -p atmega328p -vv -U flash:w:SIGNALduino_n                                                                                                                                   anoCC1101.hex

avrdude: Version 6.3
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skippi                                                                                                                                   ng

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_U                                                                                                                                   ART_00000000-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.


Ich glaube da ist was hinüber...
Ich melde mich, sobald ich das wieder auf die Reihe gekriegt hab.

Gruss David

Hallo Ralf

Da bin ich wieder. Ich musste den arduino nano tauschen, da war was faul.
Beim THGR221 gibt es ein Symbol auf dem LCD, welches aufleuchtet, wenn gesendet wird.
Hier noch einige raw-Nachrichten:

MC;LL=-976;LH=983;SL=-484;SH=504;D=000000A0EBD73479E7F55FEDAA;C=491;L=104;R=244;
T: 18.6 H: 55

MC;LL=-991;LH=954;SL=-504;SH=480;D=55555554CD2B34CAAB2AD554AAD2B32AAACB32AAAAB2CAAA;C=488;L=191;R=245;
T: 22.6 H: 46

MC;LL=-972;LH=985;SL=-473;SH=503;D=5075EB9A39DDFEEDFED08000005075EB9A39DDFC;C=488;L=158;R=24;
T: 22.3 H: 44

Die erste raw-Nachricht wurde übrigens von FHEM richtig ausgewertet (siehe Bild). Die anderen zwei nicht mehr.


Gruss und Dank.
David

Hallo David,

was heißt bei dir, die Nachrichten werden nicht ausgewertet?
Wenn du verbose 4 einstellst, gehen da die Nachrichten an ein Modul bzw. werden decodiert?

MfG

wenn ich mit der zweiten Nachricht simuliere bekomme ich

2018.12.20 23:26:10.396 4 : sduinoD/msg get raw: MC;LL=-991;LH=954;SL=-504;SH=480;D=55555554CD2B34CAAB2AD554AAD2B32AAACB32AAAAB2CAAA;C=488;L=191;R=245;
2018.12.20 23:26:10.396 4 : sduinoD: Found manchester Protocol id 10 clock 488 RSSI -79.5 -> Oregon Scientific v2|v3
2018.12.20 23:26:10.396 4 : sduinoD: OSV2 protocol detected: preamble_pos = 31
2018.12.20 23:26:10.396 4 : sduinoD: OSV2 protocol converted to hex: (501A2D10FE601420054002) with length (88) bits
2018.12.20 23:26:10.396 4 : sduinoD Dispatch: 501A2D10FE601420054002, -79.5 dB, dispatch
2018.12.20 23:26:10.396 4 : THGR228N_1 decoded Oregon: T: 14.6 H: 52 BAT: ok

Gibt es bei Dir einen Sensor zu der "T: 14.6 H: 52" passt, oder evtl ein Sensor vom Nachbar?

Die driite Nachricht wird als ID 12 Hideki mit fascher Prüfsumme erkannt.

Gruß Ralf

Hallo Ralf

Der "T: 14.6 H: 52" war wahrscheinlich der andere Sensor (THGR122NX) bei mir im Keller. Der hat da wohl etwa zeitgleich gesendet.

Das Problem beim THGR221 ist, dass der eigentlich jede Minute sendet, aber nur etwa 2-3mal pro Tag das Signal decodiert wird und im state die entsprechenden Werte erscheinen.
Bei erfolgreichem decodieren sieht das so aus:
2018.12.22 22:28:57 4: sduino/msg READ:  MC;LL=-963;LH=986;SL=-485;SH=501;D=00005075EBEE76DDFCEFF6CB0;C=489;L=97;R=251;
2018.12.22 22:28:57 4: sduino: Found manchester Protocol id 10 clock 489 RSSI -76.5 -> Oregon Scientific v2|v3
2018.12.22 22:28:57 4: sduino: OSV3 protocol detected: preamble_pos = 17, message_length = 79
2018.12.22 22:28:57 4: sduino: OSV3 protocol =                     F82414C842206408469
2018.12.22 22:28:57 4: sduino: OSV3 protocol converted to hex: (50FA2814C4482260044896) with length (80) bits
2018.12.22 22:28:57 4: sduino: Found manchester Protocol id 12 clock 489 RSSI -76.5 -> Hideki
2018.12.22 22:28:57 4: sduino: hideki start pattern (10101110) not found
2018.12.22 22:28:57 4: sduino: Found manchester Protocol id 52 clock 489 RSSI -76.5 -> Oregon Scientific PIR
2018.12.22 22:28:57 4: sduino: Oregon PIR protocol detected: header_pos = 17
2018.12.22 22:28:57 4: SIGNALduino_unknown incomming msg: u52#FFFFAF8A1411892203100934F
2018.12.22 22:28:57 4: SIGNALduino_unknown rawData: FFFFAF8A1411892203100934F
2018.12.22 22:28:57 4: SIGNALduino_unknown Protocol: 52
2018.12.22 22:28:57 4: SIGNALduino_unknown converted to bits: 1111111111111111101011111000101000010100000100011000100100100010000000110001000000001001001101001111
2018.12.22 22:28:57 4: SIGNALduino_unknown sduino Protocol:52 | To help decode or debug, please add u52! (attr sduino development u52)
2018.12.22 22:28:57 4: Unknown, please report
2018.12.22 22:28:57 4: SIGNALduino_unknown incomming msg: u52#FFFFAF8A1411892203100934F
2018.12.22 22:28:57 4: SIGNALduino_unknown rawData: FFFFAF8A1411892203100934F
2018.12.22 22:28:57 4: SIGNALduino_unknown Protocol: 52
2018.12.22 22:28:57 4: SIGNALduino_unknown converted to bits: 1111111111111111101011111000101000010100000100011000100100100010000000110001000000001001001101001111
2018.12.22 22:28:57 4: SIGNALduino_unknown sduino Protocol:52 | To help decode or debug, please add u52! (attr sduino development u52)
2018.12.22 22:28:57 4: Unknown, please report
2018.12.22 22:28:57 3: sduino: Unknown code u52#FFFFAF8A1411892203100934F, help me!
2018.12.22 22:28:57 4: sduino: Found manchester Protocol id 58 clock 489 RSSI -76.5 -> TFA 30.3208.0
2018.12.22 22:28:57 4: sduino: TFA 30.3208.0 preamble_pos = 19
2018.12.22 22:28:57 4: sduino: TFA message start=19 end=100 with length81
2018.12.22 22:28:57 4: sduino: 7C50A08C49101
STATE: T: 22.4 H: 46 (siehe Bild).

In den meisten Fällen sieht es aber so und im STATE erscheinen keine aktuellen Werte:
2018.12.22 22:42:10 4: sduino/msg READ:  MC;LL=-972;LH=982;SL=-478;SH=497;D=00141D7AED1DA77F3BFEA8C00000141D7AED1C;C=487;L=151;R=22;
2018.12.22 22:42:10 4: sduino: Found manchester Protocol id 10 clock 487 RSSI -63 -> Oregon Scientific v2|v3
2018.12.22 22:42:10 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -63 -> Hideki
2018.12.22 22:42:10 4: sduino: receive Hideki protocol not inverted
2018.12.22 22:42:10 4: sduino: Hideki protocol converted to hex: 75C596FDDCBFC5000040E0BD with 104 bits, messagestart 28
2018.12.22 22:42:10 4: sduino Hideki_Parse: incomming P12#75C596FDDCBFC5000040E0BD
2018.12.22 22:42:10 4: sduino Hideki_crc: rawdata=75C596FDDCBFC5000040E0BD to short, count=29 data length=12
2018.12.22 22:42:10 4: sduino: Found manchester Protocol id 52 clock 487 RSSI -63 -> Oregon Scientific PIR
2018.12.22 22:42:10 4: sduino: Oregon PIR protocol detected: header_pos = 115
2018.12.22 22:42:10 4: sduino: Found manchester Protocol id 58 clock 487 RSSI -63 -> TFA 30.3208.0
2018.12.22 22:42:10 4: sduino: TFA 30.3208.0 preamble_pos = 13
2018.12.22 22:42:10 4: sduino: TFA message start=13 end=104 with length91
2018.12.22 22:42:10 4: sduino: 7C50A25C4B101
2018.12.22 22:42:10 4: sduino: TFA message start=117 end=152 with length35
2018.12.22 22:42:10 4: sduino: 3E28512E3
Werte auf dem Display vom Sensor T: 23.4 H: 46%

Gruss David

welche firmware version verwendest Du?
get sduino version

Gruß Ralf

version: V 3.3.1-RC10 SIGNALduino cc1101 - compiled at Nov 19 2018 23:11:15

ccconf: freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Grüsse David

mich würde noch interessieren wie es zum Vergleich mit meiner firmware V 3.3.2.1-rc6 aussieht
https://forum.fhem.de/index.php/topic,82379.msg840645.html#msg840645

Gruß Ralf

version: V 3.3.2.1-rc6 SIGNALduino cc1101 - compiled at Dec 1 2018 21:26:50

Das sieht dann so aus:
2018.12.23 00:08:20 4: sduino/msg READ: MC;LL=-983;LH=967;SL=-489;SH=489;D=00000283AF5DF796EFCF7C8EEC00000283AF5D8;C=487;L=153;R=37;s45;b2;O;w;
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 10 clock 487 RSSI -55.5 -> Oregon Scientific v2|v3
2018.12.23 00:08:20 4: sduino: OSV3 protocol detected: preamble_pos = 22, message_length = 130
2018.12.23 00:08:20 4: sduino: OSV3 protocol =                     F82411485220340B322FFFFFFAF82419
2018.12.23 00:08:20 4: sduino: OSV3 protocol converted to hex: (84FA281441582230043B22FFFFFFFA28140) with length (132) bits
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -55.5 -> Hideki
2018.12.23 00:08:20 4: sduino: receive Hideki protocol not inverted
2018.12.23 00:08:20 4: sduino: Hideki protocol converted to hex: 75EFB4FDDE13BB000040E0BD with 104 bits, messagestart 39
2018.12.23 00:08:20 4: sduino Hideki_Parse: incomming P12#75EFB4FDDE13BB000040E0BD
2018.12.23 00:08:20 4: sduino Hideki_crc: rawdata=75EFB4FDDE13BB000040E0BD to short, count=14 data length=12
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 52 clock 487 RSSI -55.5 -> Oregon Scientific PIR
2018.12.23 00:08:20 4: sduino: Oregon PIR protocol detected: header_pos = 126
2018.12.23 00:08:20 4: SIGNALduino_unknown incomming msg: u52#FFFFFD7C50A208691030837113FFFFFD7C50A27
2018.12.23 00:08:20 4: SIGNALduino_unknown rawData: FFFFFD7C50A208691030837113FFFFFD7C50A27
2018.12.23 00:08:20 4: SIGNALduino_unknown Protocol: 52
2018.12.23 00:08:20 4: SIGNALduino_unknown converted to bits: 111111111111111111111101011111000101000010100010000010000110100100010000001100001000001101110001000100111111111111111111111111010111110001010000101000100111
2018.12.23 00:08:20 4: SIGNALduino_unknown sduino Protocol:52 | To help decode or debug, please add u52! (attr sduino development u52)
2018.12.23 00:08:20 4: Unknown, please report
2018.12.23 00:08:20 3: sduino: Unknown code u52#FFFFFD7C50A208691030837113FFFFFD7C50A27, help me!
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 58 clock 487 RSSI -55.5 -> TFA 30.3208.0
2018.12.23 00:08:20 4: sduino: TFA 30.3208.0 preamble_pos = 24
2018.12.23 00:08:20 4: sduino: TFA message start=24 end=115 with length91
2018.12.23 00:08:20 4: sduino: 7C50A20869103
2018.12.23 00:08:20 4: sduino: TFA message start=128 end=156 with length28
2018.12.23 00:08:20 4: sduino: 7C50A27
2018.12.23 00:08:20 4: sduino/msg READ: MC;LL=-987;LH=970;SL=-481;SH=483;D=F796EFCF7C8EEC00000283AF5DF796EFCF7C8EE8;C=486;L=157;R=36;s7;b0;O;w;
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 10 clock 486 RSSI -56 -> Oregon Scientific v2|v3
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 12 clock 486 RSSI -56 -> Hideki
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 52 clock 486 RSSI -56 -> Oregon Scientific PIR
2018.12.23 00:08:20 4: sduino: Oregon PIR protocol detected: header_pos = 78
2018.12.23 00:08:20 4: sduino: Found manchester Protocol id 58 clock 486 RSSI -56 -> TFA 30.3208.0
2018.12.23 00:08:20 4: sduino: TFA 30.3208.0 preamble_pos = 80
2018.12.23 00:08:20 4: sduino: TFA message start=80 end=160 with length80
2018.12.23 00:08:20 4: sduino: 7C50A20869103

Gruss David

Die Nachricht wird anscheinend zweimal hintereinander gesendet
MC;LL=-983;LH=967;SL=-489;SH=489;D=00000283AF5DF796EFCF7C8EEC00000283AF5D8;C=487;L=153;R=37;
00000283AF5DF796EFCF7C8EEC
00000283AF5D
Im Gegensatz zu anderen Oregon V3 Nachrichten fehlt hier anscheinend die Pause nach er ersten Nachricht. Da es ein Pufferüberlauf gibt, fehlt bei der zweiten Nachricht ein Teil.
Wenn ich die zweite Nachricht entferne und damit simuliere, dann passt es:
MC;LL=-983;LH=967;SL=-489;SH=489;D=00000283AF5DF796EFCF7C8EEC;C=487;L=153;R=37;

2018.12.23 00:41:53.220 4 : sduinoD: Found manchester Protocol id 10 clock 487 RSSI -55.5 -> Oregon Scientific v2|v3
2018.12.23 00:41:53.220 4 : sduinoD: OSV2/3: 1111111111111111111111010111110001010000
2018.12.23 00:41:53.220 4 : sduinoD: OSV3 protocol detected: preamble_pos = 22, message_length = 78
2018.12.23 00:41:53.220 4 : sduinoD: OSV3 protocol = F82411485220340B322
2018.12.23 00:41:53.220 4 : sduinoD: OSV3 protocol converted to hex: (50FA281441582230043B22) with length (80) bits
2018.12.23 00:41:53.220 4 : sduinoD Dispatch: 50FA281441582230043B22, -55.5 dB, dispatch
2018.12.23 00:41:53.221 4 : THGR810_1 decoded Oregon: T: 22.5 H: 43 BAT: ok

Ich benötige noch mehr MC-Nachrichten, die nicht decodiert werden können.

Gruß Ralf

Momentan müssen bei der MC-Nachricht hinter dem D= mindestens vier Nullen folgen,
Du kannst mal darauf achten ob dies ausreichend oft der Fall ist.

Gruß Ralf

Hier sind mal zwei Zeitfenster von jeweils 5min. Habe alle MC-Nachrichten aus dem Log-File rauskopiert. Die konnten alle nicht decodiert werden. 8 davon starten nach dem D mit mindestens 4 Nullen. Das wäre dann ungefähr alle 75s eine Nachricht mit 4 Nullen. Das ist meiner Meinung nach genügend.

2018.12.23 16:00:35 4: sduino/msg READ: MC;LL=-962;LH=993;SL=-479;SH=500;D=0EBD77DF3FBFBDF8B73000000A0EBD77DF3FBE;C=488;L=151;R=32;s11;b4;O;w;
2018.12.23 16:00:35 4: sduino/msg READ: MC;LL=-973;LH=984;SL=-478;SH=493;D=EF7E2DCC00000283AF5DF7CFEFEF7E2DCC;C=487;L=134;R=33;s5;b0;
2018.12.23 16:01:28 4: sduino/msg READ: MC;LL=-975;LH=984;SL=-487;SH=482;D=000283AF5DF7CFEFEF7E2DCC00000283AF5DF7;C=487;L=152;R=31;s29;b2;O;w;
2018.12.23 16:01:28 4: sduino/msg READ: MC;LL=-976;LH=978;SL=-490;SH=486;D=E7F7F7BF16E600000141D7AEFBE7F7F7BF16E6;C=488;L=151;R=32;s5;b0;
2018.12.23 16:02:21 4: sduino/msg READ: MC;LL=-986;LH=968;SL=-494;SH=478;D=00000141D7AEFBE7F7F7BF16E600000141D7AC;C=487;L=150;R=33;s47;b2;O;w;
2018.12.23 16:02:21 4: sduino/msg READ: MC;LL=-982;LH=971;SL=-491;SH=483;D=DF7CFEFEF7E2DCC00000283AF5DF7CFEFEF7E2;C=487;L=152;R=33;s3;b0;O;w;
2018.12.23 16:03:14 4: sduino/msg READ: MC;LL=-978;LH=971;SL=-490;SH=486;D=00000283AF5DF7CFEFEF7E2DCC00000283AF5C;C=487;L=150;R=33;s45;b2;O;w;
2018.12.23 16:03:14 4: sduino/msg READ: MC;LL=-985;LH=975;SL=-481;SH=490;D=BEF9FDFDEFC5B98000005075EBBEF9FDFDEFC5;C=488;L=152;R=33;s1;b0;O;w;
2018.12.23 16:04:07 4: sduino/msg READ: MC;LL=-991;LH=967;SL=-487;SH=484;D=0000A0EBD77DF3FBFBDF8B73000000A0EBD74;C=488;L=146;R=34;s43;b12;O;w;
2018.12.23 16:04:07 4: sduino/msg READ: MC;LL=-989;LH=975;SL=-496;SH=473;D=FBE7F7F7BF16E600000141D7AEFBE7F7F7BF16;C=488;L=152;R=33;s9;b0;O;w;
2018.12.23 16:05:00 4: sduino/msg READ: MC;LL=-976;LH=974;SL=-485;SH=499;D=0000A0EBD77DFBFBFBDF4B1B000000A0EBD77D8;C=488;L=153;R=34;s33;b2;O;w;

2018.12.23 17:10:22 4: sduino/msg READ: MC;LL=-977;LH=971;SL=-493;SH=482;D=00005075EBBEF9FDFDEFC5B98000005075EB8;C=487;L=145;R=35;s45;b12;O;w;

2018.12.23 17:10:22 4: sduino/msg READ: MC;LL=-991;LH=962;SL=-489;SH=483;D=BEF9FDFDEFC5B98000005075EBBEF9FDFDEFC5;C=487;L=152;R=34;s1;b0;O;w;
2018.12.23 17:11:15 4: sduino/msg READ: MC;LL=-992;LH=964;SL=-489;SH=483;D=00000283AF5DF7CFEFEF7E2DCC00000283AF5C;C=487;L=150;R=34;s45;b2;O;w;
2018.12.23 17:11:15 4: sduino/msg READ: MC;LL=-975;LH=973;SL=-498;SH=488;D=BEF9FDFDEFC5B98000005075EBBEF9FDFDEFC5;C=488;L=152;R=34;s1;b0;O;w;
2018.12.23 17:12:09 4: sduino/msg READ: MC;LL=-969;LH=979;SL=-476;SH=503;D=000283AF5DF7CFEFEF7E2DCC00000283AF5DF;C=487;L=148;R=34;s35;b8;O;w;
2018.12.23 17:12:09 4: sduino/msg READ: MC;LL=-974;LH=987;SL=-487;SH=485;D=BE7F7F7BF16E600000141D7AEFBE7F7F7BF16E0;C=488;L=153;R=34;s1;b0;O;w;
2018.12.23 17:13:03 4: sduino/msg READ: MC;LL=-970;LH=987;SL=-493;SH=486;D=0EBD77DF3FBFBDF8B73000000A0EBD77DF3FBF;C=489;L=152;R=34;s8;b1;O;w;
2018.12.23 17:13:03 4: sduino/msg READ: MC;LL=-972;LH=982;SL=-484;SH=490;D=BDF8B73000000A0EBD77DF3FBFBDF8B73;C=487;L=132;R=33;s2;b1;
2018.12.23 17:13:54 4: sduino/msg READ: MC;LL=-978;LH=971;SL=-501;SH=482;D=00000A0EBD77DF3FBFBDF8B73000000A0EBD7;C=488;L=148;R=34;s45;b6;O;w;
2018.12.23 17:13:54 4: sduino/msg READ: MC;LL=-991;LH=963;SL=-498;SH=483;D=BEF9FDFDEFC5B98000005075EBBEF9FDFDEFC5;C=489;L=152;R=35;s1;b0;O;w;
2018.12.23 17:14:47 4: sduino/msg READ: MC;LL=-974;LH=977;SL=-496;SH=475;D=00000283AF5DF7CFEFEF7E2DCC00000283AF5C;C=486;L=150;R=35;s45;b2;O;w;
2018.12.23 17:14:47 4: sduino/msg READ: MC;LL=-975;LH=976;SL=-491;SH=491;D=BEF9FDFDEFC5B98000005075EBBEF9FDFDEFC5;C=488;L=152;R=34;s1;b0;O;w;

Ok, das passt dann so. Ich habe in der 00_signalduino.pm die Oregon Routine überarbeitet. Es gibt demnächst eine Testversion.
Zum Hintergrund. Die Nachricht ist invertiert. Am Anfang ist eine Preamble von 24 Einsen, dann kommt ein Sync 0101
Seither wurde auf 16 Einsen + sync am Anfang getestet, ich habe es geändert, damit nur auf 12 Einsen + sync getestet wird.

MC;LL=-975;LH=984;SL=-487;SH=482;D=000283AF5DF7CFEFEF7E2DCC00000283AF5DF7;C=487;L=152;R=31;

00028 ergibt bin
0000 0000 0000 0010 1000
und invertiert
1111 1111 1111 1101 0 111

Gruß Ralf

Hier ist der Patch:
https://github.com/Ralf9/RFFHEM/commit/6f19fb0a9da1ed11ef820137c5bd41fa47f4da54

hier ist zum Testen meine Version der 00_SIGNALduino.pm
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/00_SIGNALduino.pm

wenn es so passt, dann bringe ich es auch in die dev-r33

Gruß Ralf

Wunderbar! Ich habe es getestet, jetzt funktionieren die THGR221 perfekt. Da kommen jede Minute neue Werte rein.
Vielen Dank an Dich, Ralf. Da werden sicher noch einige froh drüber sein.

Grüsse David

Danke für den Test. Mich würde nun interessieren ob es 2 oder 3 Nachrichten hintereinander sind.
Dazu wäre es hilfreich, wenn Du mir die empfangenen Nachrichten als MU-Nachrichten posten könntest.
Dies müssten MU-Nachrichten mit einem sehr langen Datenteil (D=123...; ) sein. Es müssten ca über 350 Zeichen im Datenteil sein.

Den Modus für sehr lange MU-Nachrichten kannst Du damit aktivieren:
get sduino raw CEO
get sduino config
- ergibt
config: MS=1;MU=1;MC=1;Mred=1;MuNoOverflow=1;Mdebug=1_MScnt=4;MuOverflMax=3;MdebFifoLimit=120/140
Damit werden die MC-Nachrichten deaktiviert.
set sduino disableMessagetype manchesterMC
get sduino config
- ergibt
config: MS=1;MU=1;MC=0;Mred=1;MuNoOverflow=1;Mdebug=1_MScnt=4;MuOverflMax=3;MdebFifoLimit=120/140


Wenn Du fertig bist kannst Du es damit wieder auf default zurücksetzen:

get sduino raw eC
- ergibt
raw: Init eeprom to defaults
get sduino config
- ergibt
config: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140

Gruß Ralf

Guten Abend Ralf

Hier einige MU-Nachrichten:

2018.12.30 20:55:57 4: sduino/msg READredu(o1): MU;P0=-459;P1=348;P2=518;P3=-941;P4=1014;CP=2;R=234;D=0102020202343402020202320204343202020432043202040202020234320202043204320432020202020202020202043402023202040232040202343434340202340202020202020202020202020202020202020202020202343402020202320204343202020432043202040202020234320202043204320432020202020202020202043402023202;p;


2018.12.30 20:55:57 4: sduino/msg READredu: MU;P0=1024;P1=-461;P2=519;P3=-926;P4=-5016;CP=2;R=233;D=01232101212303030301212301212121212121212121212121212121212121212121212303012121212321210303212121032103212101212121230321212103210321032121212121212121212103012123212101232101212303030301212324;e;


2018.12.30 20:58:54 4: sduino/msg READredu(o1): MU;P0=92;P1=-467;P2=511;P3=-966;P4=986;CP=2;R=235;D=01212121232121434321212143214321214121212123432121214321432143212121212121212121214341212321214123214121234343434121234121212121212121212121212121212121212121212121234341212121232121434321212143214321214121212123432121214321432143212121212121212121214341212321214123214121234343434121234121212121212121212121212121212121212121212121234341212121232121434321212143214321214121212123432121214321432143212121212121212121214341212321214123214121234343434121232;p;

2018.12.30 20:59:53 4: sduino/msg READredu(o1): MU;P0=-474;P1=504;P2=-966;P3=992;CP=1;R=236;D=01010101010101010101010101010101010101010123230101010121010323210101032103210103010101012321010103210321032101010101010101010103230101210103012103010123232323010123010101010101010101010101010101010101010101010123230101010121010323210101032103210103010101012321010103210321032101010101010101010103230101210103012103010123232323010121;p;

2018.12.30 21:01:51 4: sduino/msg READredu(o1): MU;P0=-933;P1=141;P2=-2136;P3=532;P4=-444;P5=-136;P6=1015;CP=3;R=234;D=012341514606034343460346034346434343430603434346034603460343434343434343434346064343034346430346434306060606434306434343434343434343434343434343434343434343434306064343434303434606034343460346034346434343430603434346034603460343434343434343434346064343034346430346434306060606434306434343434343434343434343434343434343434343434306064343434303434606034343460346034346434343430603434346034603460343434343434343434346064343034346430346434306060606434303;p;

2018.12.30 21:02:50 4: sduino/msg READredu(o1): MU;P0=672;P1=-467;P2=506;P3=-956;P4=991;CP=2;R=235;D=01212121232121434321212143214321214121212123432121214321432143212121212121212121214341212321214123214121234343434121234121212121212121212121212121212121212121212121234341212121232121434321212143214321214121212123432121214321432143212121212121212121214341212321214123214121234343434121234121212121212121212121212121212121212121212121234341212121232121434321212143214321214121212123432121214321432143212121212121212121214341212321214123214121234343434121232;p;


Der Datenteil ist aber sehr unterschiedlich lang.

Grüsse David

Danke für die MU-Nachrichten, damit kann ich erkennen, das die Nachricht 3 mal ohne Pause gesendet wird.
Es sieht so aus als hättest Du keine optimale Empfangsbedingungen, es fehlt am Anfang oft ein großer Teil der 24 Bit Preamble.

Die neuen Oregon V3 Sensoren müssten nun auch mit der aktuellen Entwicklerversion dev-r33 funktionieren.

Hier ist eine Übersicht über die neuen Oregon Sensoren
http://global.oregonscientific.com/2018/Oregon_Scientific_IoT_Sensor_Compatibility/index.html

Gruß Ralf

Hallo an Ralf9,

irgendwie habe ich den Eindruck, dass mir hier evtl. geholfen werden kann. Ich bin relativ neu bei FHEM und möchte zwei OREGON-Sensoren (Thermo-Hygro-Sensor THGR810 und Regenmesser PCR800) einbinden. Bevor ich tiefer einsteige interessiert mich zunächst nur, ob ich dazu zwingend einen SIGNALDuino brauche oder ob das auch mit meinem vorhandenen nanoCUL (CC1101 / 433 MHz, culfw-1.67) möglich ist. Im Forum habe ich mir bereits "einen Wolf" gesucht und hoffe, dass ich hier weiter komme.

Gruß Gundermann

Die Oregon v2 Sensoren funktionieren auch mit dem CUL.

THGR810 und PCR800 sind Oregon v3 Sensoren, mir ist nicht bekannt ob die v3 Sensoren auch mit dem CUL funktionieren.
Du müsstest es mal testen ob sie mit dem CUL funktionieren.

Den  nanoCUL kannst Du recht einfach auf einen SIGNALDuino flashen.

Gruß Ralf

Hallo Ralf,

vielen Dank für die sehr schnelle Antwort.

Leider ergeben sich nun zwei neue Fragen:

1. Wenn die Oregon v3-Sensoren mit dem nanoCUL funktionieren würden, dann müssten doch, wenn die Sensoren senden (da bin ich sicher) und  bei aktivem "autocreate" irgendwelche "defines" erzeugt werden, oder? Da keine entsprechenden "defines" neu hinzu kommen, gehe ich davon aus, dass es eben leider nicht funktioniert. Ist das so einfach oder komplizierter?

2. Wenn ich nun den nanoCUL auf einen SIGNALDuino flashe (ich denke, das würde ich mit den Beiträgen aus dem Forum hinbekommen), werden dann meine sonstigen Aktoren (z.B. 433-MHz-Intertechno-Funksteckdosen) noch funktionieren, die der nanoCUL derzeit recht zuverlässig anfunkt?

Gruß Gundermann

ja, wenn die Oregon v3-Sensoren mit dem nanoCUL korrekt funktionieren würden, müssten irgendwelche "defines" oder define logmeldungen erzeugt werden.
Mit CUL verbose 5 sollten zumindest beim Empfang einige log Meldungen erscheinen.

Die Intertechno-Funksteckdosen sollten mit dem Signalduino funktionieren.
Was für Sensoren hast Du sonst noch?

Gruß Ralf

Hallo Ralf,

danke für die wieder sehr schnelle Antwort.

Habe jetzt den nanoCUL auf einen SIGNALDuino geflasht (V 3.3.1-RC7 SIGNALduino cc1101) und die Signale der Oregon v3-Sensoren werden empfangen. Auch die 433-MHz-Intertechno-Funksteckdosen funktionieren mit dem SIGNALDuino. Also ist jetzt soweit alles gut.

Sonstige Wettersensoren habe ich nicht und werde ich wohl auch nicht anschaffen.

Allerdings empfange ich aus der Nachbarschaft offensichtlich eine Menge Signale, die ich noch irgendwie eliminieren muss. Der Eventmonitor rotiert selbst bei "verbose 3". Ich werde mich dazu durch das Forum lesen und bei Problemen ggf. noch einmal melden.

Jetzt könnte eigentlich ich meine Oregon v3-Sensoren verschenken und die Signale der Nachbarn loggen ;).

Herzlichen Dank für die freundliche Unterstützung und
Grüße von Gundermann