SIGNALDuino Oregon Sensoren

Begonnen von Ralf9, 04 November 2016, 17:59:00

Vorheriges Thema - Nächstes Thema

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Ja, ich habe mit diversen Testdaten die Funktion verifiziert...
:(
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

RappaSan

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

RappaSan

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

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

RappaSan


Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

stefanru

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

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey



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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

stefanru

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

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

#73
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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

stefanru

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