SIGNALduino und ESA2000

Begonnen von daubsi, 08 September 2024, 00:04:19

Vorheriges Thema - Nächstes Thema

Ralf9

wenn Du ein paar mal "get ccconf" machst, bekommst Du dann immer die gleichen Werte?

Evtl bringts was, wenn Du die cc1101_bWidth erhöhst

Du kannst mal testweise die MC Nachrichten deaktivieren

set disableMessagetype_4 manchesterMC

ein "get config" ergibt dann: config: A: MS=1;MU=1;MC=0; ...
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

daubsi

Ich hatte gestern Abend ja nochmal auf 433.92 umgestellt und dort auch zunächst nichts empfangen.
Das hat sich heute nacht geändert. Gegen 0:30 sprudelten auf einmal wieder Nachrichten rein:

2024.09.13 00:20:28 5: sduino SW: P
2024.09.13 00:20:28 4: sduino/msg READ: OK
2024.09.13 00:20:28 5: sduino/noMsg Parse: OK
2024.09.13 00:20:28 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 00:20:29 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 00:21:28 4: sduino/keepalive ok, retry = 0
2024.09.13 00:22:28 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2024.09.13 00:22:28 5: AddSendQueue: sduino: P (1)
2024.09.13 00:22:28 5: sduino SW: P
2024.09.13 00:22:28 4: sduino/msg READ: OK
2024.09.13 00:22:28 5: sduino/noMsg Parse: OK
2024.09.13 00:22:28 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 00:22:29 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 00:23:28 4: sduino/keepalive ok, retry = 0
2024.09.13 00:24:28 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2024.09.13 00:24:28 5: AddSendQueue: sduino: P (1)
2024.09.13 00:24:28 5: sduino SW: P
2024.09.13 00:24:28 4: sduino/msg READ: OK
2024.09.13 00:24:28 5: sduino/noMsg Parse: OK
2024.09.13 00:24:28 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 00:24:29 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 00:25:28 4: sduino/keepalive ok, retry = 0
2024.09.13 00:26:28 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2024.09.13 00:26:28 5: AddSendQueue: sduino: P (1)
2024.09.13 00:26:28 5: sduino SW: P
2024.09.13 00:26:28 4: sduino/msg READ: OK
2024.09.13 00:26:28 5: sduino/noMsg Parse: OK
2024.09.13 00:26:28 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 00:26:29 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 00:27:28 4: sduino/keepalive ok, retry = 0
2024.09.13 00:27:56 4: sduino/msg READ: ^BMU;P0=-776;P1=512;P2=-1025;P3=-1949;P4=-476;P5=1154;P6=-96;P7=144;CP=1;R=240;D=121313131213121313121212121212121213121213131312131313131213121452125216701676;e;^C
2024.09.13 00:27:56 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2024.09.13 00:27:56 5: sduino: regex ((?:)((?:12|52){43,})) did not match, aborting
2024.09.13 00:27:56 4: sduino: Fingerprint for MU Protocol id 9 -> weatherID9 matches, trying to demodulate
2024.09.13 00:27:56 5: sduino: regex ((?:)((?:12|52){60,}(?:5|1)?)) did not match, aborting
2024.09.13 00:27:56 4: sduino: Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2024.09.13 00:27:56 5: sduino: regex ((?:1)((?:45|21){19,}(?:2|4)?)) did not match, aborting
2024.09.13 00:27:57 5: sduino applied filterfunc: SIGNALduino_compPattern, count=0
2024.09.13 00:27:57 4: sduino: Fingerprint for MU Protocol id 48 -> TFA Dostmann matches, trying to demodulate
2024.09.13 00:27:57 5: sduino: regex ((?:31)((?:25|21){47,})) did not match, aborting
2024.09.13 00:27:57 4: sduino: Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2024.09.13 00:27:57 5: sduino: regex ((?:)((?:12|52){47,}(?:1|5)?)) did not match, aborting

Aber ab 1 Uhr war wieder Funkstille für mehrere Stunden(!) bevor dann um 03:00 und 06:00 wieder was reinkam?
Das kann doch nicht sein?

Ich habe jetzt auch immer noch den Fall, dass ccpatable die Frequenz 868.350 enthält. Wie stelle ich das um?

cc1101_config freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) 2024-09-12 23:53:10
ccpatable 868.350 MHz, C3E = 00 81 00 00 00 00 00 00 => 5_dBm 2024-09-12 23:13:35
cmdBank A: b=1 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100] ccmode=0 sync 2024-09-12 23:52:58
config A: MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;maxNumPat=8;Mdebug=1;MdebFifoLimit=150/200 2024-09-12 23:14:33
ping OK 2024-09-13 09:47:35
raw. detect A: Partn=0 Ver=0x14. 2024-09-12 23:07:40
rfmode. SlowRF_ccFactoryReset => ccFactoryReset done. 2024-09-12 23:03:57
state. opened. 2024-09-12 23:02:17
version. V 4.2.2-dev220712 SIGNALduinoAdv ESP32 cc1101 (R: A1* B-) - compiled at Sep 11 2024 22:57:57

daubsi

Und, ja, mehrere cconf Aufrufe liefern immer das gleiche Ergebnis.

"ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK)"

Ralf9

#33
ccpatable wird nur zum Senden benötigt, wenn das Attribut cc1101_frequency definiert ist, dann wird die Frequenz von dort geholt, sonst wird die Frequenz (433 oder 868) von ccconf geholt.

Die empfangene MU Nachricht ist recht schwach, nur -82 dB, wenn es bei Dir kein 433 MHz SlowRF gibt, vermutlich von einem Nachbar.

Du kannst mal die bWidth auf ca 400-500 erhöhen

Ist der elv ESA2000WZ-LED das einzigste was auf 868 SlowRF sendet?
Was sendet sonst noch auf 868 MHz?
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

daubsi

Ich habe gerade mit "set sduino cc1101_freq 868.350" die Frequenz wieder auf 868.350 MHz geändert. Bislang (seit 5min) noch kein Event.
Im selben Raum (alles innerhalb von 5m) sendet auch ein WMBus Funkwasserzähler. Der müsste AFAIR jede Minute senden, der ESA2000 nur - je nach Stromverbrauch im Moment - so ca. alle 5 Minuten.

Hab die Bandwidth jetzt mal auf 650KHz erhöht, da muss ja definitiv was sein... Ich habe auch Homematic IP im Einsatz und zumindest in einem anderen Kellerraum auch die HmIP Thermostate und da ist der Empfang prinzipiell gegeben. Das sollte ich dann auch auffangen können. (Wobei ich jetzt nicht weiss ob HmIP nicht eher FSK nutzt als ASK? - vermutlich)

ccconf liefert "ccconf: freq:868.350MHz bWidth:650KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK)"

Ich möchte jetzt natürlich nicht ausschliessen, dass es nicht doch am Board/Antenne liegt. Ich habe noch eine 868er Antenne da mit SMA, die probiere ich auch mal. Aber bei nur 3m Entfernung zum Sender sollte es doch nicht sein, dass GAR NIX empfangen wird, selbst wenn die Antenne nicht abgestimmt ist?
Notfalls habe ich auch noch so ein grünes 868er CC1101 Board mit den Stummelantennen, da müsste ich aber erst Header dranlöten, die sind gestern erst gekommen von Ali.

Wo kannst Du denn den RSSI Wert der MU Nachricht sehen? Welcher Wert gibt Dir die -82 dB?


daubsi

Läuft jetzt seit knapp 1h mit 868 MHz und ich habe bislang 0.0 Nachrichten empfangen... :-(

Lediglich die Ping Meldungen sind im Log...
...
2024.09.13 13:47:38 5: AddSendQueue: sduino: P (1)
2024.09.13 13:47:38 5: sduino SW: P
2024.09.13 13:47:38 4: sduino/msg READ: OK
2024.09.13 13:47:38 5: sduino/noMsg Parse: OK
2024.09.13 13:47:38 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 13:47:39 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 13:48:38 4: sduino/keepalive ok, retry = 0
2024.09.13 13:49:38 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2024.09.13 13:49:38 5: AddSendQueue: sduino: P (1)
2024.09.13 13:49:38 5: sduino SW: P
2024.09.13 13:49:38 4: sduino/msg READ: OK
2024.09.13 13:49:38 5: sduino/noMsg Parse: OK
2024.09.13 13:49:38 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 13:49:39 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 13:50:38 4: sduino/keepalive ok, retry = 0
2024.09.13 13:51:38 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2024.09.13 13:51:38 5: AddSendQueue: sduino: P (1)
...

daubsi

Ein "get cmdBank" zeigt mir:

A: b=1 freq:868.350MHz bWidth:650KHz rAmpl:42dB sens:12dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100]

   ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)

Ist das mit dem sync=D391 in Ordnung? Hinten heisst es ja "No preamble/sync". Widerspricht sich das nicht? Das er keine Preamble will/braucht passt?


Ralf9

Das sync wird immer angezeigt, unabhängig davon ob es verwendet wird.

R=240 ist der empfangene RSSI Wert, bei bekannten Nachrichten wird er nach dB umgerechnet.

Nach der Formel
rssi/2-74
bei Werten > 127
(rssi-256)/2-74

Für WMBUS gibts bei set rfmode auch 2 Einträge
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

daubsi

Ich habe gerade mal die 433er Stummeladresse durch eine andere extra 868er Antenne ersetzt... Guess what!

024.09.13 14:26:39 4: sduino/msg READ: OK
2024.09.13 14:26:39 5: sduino/noMsg Parse: OK
2024.09.13 14:26:39 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 14:26:39 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 14:27:39 4: sduino/keepalive ok, retry = 0
2024.09.13 14:28:39 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2024.09.13 14:28:39 5: AddSendQueue: sduino: P (1)
2024.09.13 14:28:39 5: sduino SW: P
2024.09.13 14:28:39 4: sduino/msg READ: OK
2024.09.13 14:28:39 5: sduino/noMsg Parse: OK
2024.09.13 14:28:39 4: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2024.09.13 14:28:39 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2024.09.13 14:29:39 4: sduino/keepalive ok, retry = 0
2024.09.13 14:29:43 4: sduino/msg READ: MC;LL=-484;LH=524;SL=-224;SH=275;D=17308B491734F38CF502C06F4E10AE7B30784;C=251;L=148;R=243;s24;b19;
2024.09.13 14:29:43 4: sduino: Found manchester Protocol id 47 clock 251 RSSI = -80.5 -> Maverick
2024.09.13 14:29:43 5: sduino: extracted data 0001011100110000100010110100100100010111001101001111001110001100111101010000001011000000011011110100111000010000101011100111101100110000011110000100 (bin)
2024.09.13 14:29:43 5: sduino: protocol does not match return from method: (header not found)
2024.09.13 14:29:43 4: sduino: Found manchester Protocol id 96 clock 251 RSSI = -80.5 -> Grothe Mistral SE
2024.09.13 14:29:43 5: sduino: extracted data 0001011100110000100010110100100100010111001101001111001110001100111101010000001011000000011011110100111000010000101011100111101100110000011110000100 (bin)
2024.09.13 14:29:43 5: sduino: protocol does not match return from method: (Start pattern (01000111) not found)

"Grothe Mistral SE" und "Maverick" sagt mir jetzt nix (hab ich bei mir nicht), aber mal sehen ob ich nun auch noch andere Dinge empfange...


daubsi

Das Grothe Mistral/Maverick wiederholt sich ca. alle 45-90 Sekunden... das könnte vlt. der WMBus sein, der nicht als solcher erkannt wird. Der ist, wie gesagt, auch in unmittelbarer Nähe und den empfange ich mit einem anderen CUL direkt an FHEM angeschlossen...
Mal sehen ob ich dann in ein paar Minuten auch den Stromzähler sehe...

daubsi

Schon wieder was Neues... wieder ganz schlechte RSSI - kann nicht mein Zähler sein...

2024.09.13 14:32:47 5: sduino: protocol does not match return from method: (Start pattern (01000111) not found)
2024.09.13 14:33:39 4: sduino/keepalive ok, retry = 0
2024.09.13 14:34:15 4: sduino/msg READ: MC;LL=-1000;LH=1004;SL=-499;SH=516;D=AAAAAAAAAA;C=503;L=40;R=193;i;s1;b1;w;
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 52 clock 503 RSSI = -105.5 -> Oregon Scientific PIR
2024.09.13 14:34:15 5: sduino: extracted data 0101010101010101010101010101010101010101 (bin)
2024.09.13 14:34:15 5: sduino: protocol does not match return from method: ( message is to long)
2024.09.13 14:34:15 4: sduino/msg READ: MC;LL=-1000;LH=1004;SL=-499;SH=516;D=B6A1AFFEECBEFEBCF0;C=503;L=70;R=193;s1;b0;
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 10 clock 503 RSSI = -105.5 -> Oregon Scientific v2|v3
2024.09.13 14:34:15 5: sduino: extracted data 010010010101111001010000000000010001001101000001000000010100001100001111 (bin)
2024.09.13 14:34:15 5: sduino: protocol does not match return from method: (undef)
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 12 clock 503 RSSI = -105.5 -> Hideki
2024.09.13 14:34:15 5: sduino: extracted data 010010010101111001010000000000010001001101000001000000010100001100001111 (bin)
2024.09.13 14:34:15 5: sduino: protocol does not match return from method: (Start pattern (10101110) not found)
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 52 clock 503 RSSI = -105.5 -> Oregon Scientific PIR
2024.09.13 14:34:15 5: sduino: extracted data 010010010101111001010000000000010001001101000001000000010100001100001111 (bin)
2024.09.13 14:34:15 5: sduino: protocol does not match return from method: ( message is to long)
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 58 clock 503 RSSI = -105.5 -> TFA 30.3208.0
2024.09.13 14:34:15 5: sduino: extracted data 010010010101111001010000000000010001001101000001000000010100001100001111 (bin)
2024.09.13 14:34:15 5: sduino: protocol does not match return from method: (undef)
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 119 clock 503 RSSI = -105.5 -> Funkbus
2024.09.13 14:34:15 5: sduino: extracted data 101101101010000110101111111111101110110010111110111111101011110011110000 (bin)
2024.09.13 14:34:15 5: sduino: protocol does not match return from method: (message is to long)
2024.09.13 14:34:15 4: sduino: Found manchester Protocol id 212 clock 503 RSSI = -105.5 -> HMS
2024.09.13 14:34:15 5: sduino: extracted data 010010010101111001010000000000010001001101000001000000010100001100001111 (bin)
2024.09.13 14:34:15 4: sduino: HMS 10010010101111001010000000000010001001101000001000000010100001100001111, remove one bit at begin
2024.09.13 14:34:15 4: sduino: HMS 494f0091415086 parity ok, xorsum ok
2024.09.13 14:34:15 5: sduino Dispatch: 810e04xx0510a001494f000000914150, test ungleich: disabled
2024.09.13 14:34:15 4: sduino Dispatch: 810e04xx0510a001494f000000914150, -105.5 dB, dispatch
2024.09.13 14:34:15 5: sduino: dispatch 810e04xx0510a001494f000000914150
2024.09.13 14:34:39 4: sduino/keepalive ok, retry = 0
2024.09.13 14:34:47 4: sduino/msg READ: MC;LL=-497;LH=520;SL=-244;SH=260;D=1710AB693714D3ACAB591612B36C7A2B307AA;C=253;L=148;R=241;s30;b25;
2024.09.13 14:34:47 4: sduino: Found manchester Protocol id 47 clock 253 RSSI = -81.5 -> Maverick
2024.09.13 14:34:47 5: sduino: extracted data 0001011100010000101010110110100100110111000101001101001110101100101010110101100100010110000100101011001101101100011110100010101100110000011110101010 (bin)
2024.09.13 14:34:47 5: sduino: protocol does not match return from method: (header not found)
2024.09.13 14:34:47 4: sduino: Found manchester Protocol id 96 clock 253 RSSI = -81.5 -> Grothe Mistral SE
2024.09.13 14:34:47 5: sduino: extracted data 0001011100010000101010110110100100110111000101001101001110101100101010110101100100010110000100101011001101101100011110100010101100110000011110101010 (bin)
2024.09.13 14:34:47 5: sduino: protocol does not match return from method: (Start pattern (01000111) not found)

Aber immerhin empfange ich nun was... krass was eine andere Antenne selbst auf so kurze Entfernung (3m) ausmacht...


daubsi

#41
Aber egal was ich probiere, den Strommesser scheine ich nicht zu empfangen... Die Nachrichten müssten VIEL länger sein:

Das ist eine der Nachrichten die ich mit dem RTL-SDR mal aufgefangen hatte... Das kommt alle paar Minuten vorbei... Sowas "suche" ich...

1010101010101010101010101010100110011001011001011001010110101010101010010101101001010101011010010101101001100101011001101001010101101001101010101001100101010110100101010110101010011001100110101010010101010101101010100101011010010110100101010101011010011001010110101010101001100101101001011010101001101010101010010110101

320 Bits... Gibt es da was wo Du sagst "Für dem Empfang solch langer Messages musst Du noch Setting XYZ machen"?

Das waren die Parameter die rtl_433 ausgespuckt hatte zu dem Signal:

Detected OOK package @6.135356s
Analyzing pulses...
Total count:  130,  width: 80.55 ms  (20138 S)
Pulse width distribution:
 [ 0] count:  100,  width:  228 us [220;236] (  57 S)
 [ 1] count:   30,  width:  484 us [476;492] ( 121 S)
Gap width distribution:
 [ 0] count:   99,  width:  272 us [268;284] (  68 S)
 [ 1] count:   30,  width:  528 us [524;536] ( 132 S)
Pulse period distribution:
 [ 0] count:   80,  width:  500 us [492;512] ( 125 S)
 [ 1] count:   38,  width:  760 us [748;772] ( 190 S)
 [ 2] count:   11,  width: 1016 us [1008;1024] ( 254 S)
Pulse timing distribution:
 [ 0] count:  199,  width:  248 us [220;284] (  62 S)
 [ 1] count:   60,  width:  508 us [476;536] ( 127 S)
 [ 2] count:    1,  width: 10004 us [10004;10004] (2501 S)
Level estimates [high, low]:   1000,      7
RSSI: -12.1 dB SNR: 21.5 dB Noise: -33.7 dB
Frequency offsets [F1, F2]:  -15989,      0 (-61.0 kHz, +0.0 kHz)
Guessing modulation: Manchester coding

Die Pulse haben also immer eine Breite von 500 us.

Die Bitfolge oben soll zu "FF FE A4 8F E3 06 34 58 6F A1 87 AB C0 F1 98 1A 3F 4C F7 E7" decodiert werden.

https://triq.org/pdv/#AAB10300F801FC27148080808080808080808080808080819191809180918080908080808080818080908180808080908180809081918080919081808080908190808080819180808090818080809080808191919080808180808080809080808180809081809081808080808090819180809080808080819180908180908080819080808080818090808255

triq sagt aber z.B.  Pulsbreite 250ms im Gegensatz zu dem was der "Flexdecoder" von rtl_433 ausspuckt. Habe von dem dev schon das Feedback, dass der Flexdecoder das manchmal nicht 100% korrekt macht. Deswegen stimmt auch das Decodierungsergebenis von rtl_433 nicht, das von Triq schon. Für rtl_433 habe ich inzwischen selber einen Decoder geschrieben, der funktioniert auch wunderbar. Jetzt würde ich es aber gerne auch mit Signalduino realisieren - sofern möglich....

Ralf9

Per Default ist die maxMsgSize 1024, was Du Dir mit "get config" anzeigen lassen kannst.

Du hast in einer anderen Nachricht vermutet, daß es evtl diese sind
MC;LL=-1000;LH=1004;SL=-499;SH=516;D=AAAAAAAAAA;C=503;L=40;R=193;i;s1;b1;w;
MC;LL=-1000;LH=1004;SL=-499;SH=516;D=B6A1AFFEECBEFEBCF0;C=503;L=70;R=193;s1;b0;
Da passen aber die MC Pulslängen (short 500, long 1000) nicht.

Du kannst mal mit "set disableMessagetype..." die MS und MC Nachrichten deaktivieren und dann die MU Nachrichten posten
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

daubsi

Genau, das hatte ich vermutet, aber die passen ja nun wirklich nicht.. Aber das war halt das Einzige komplett unbekannte...
Aber da hatte ich auch die gleiche Antenne dran wie hier vorher... Am Ende ist das nur Noise gewesen, weil wir ja jetzt sehen, dass es offenbar auf die Antenne drauf ankommt, dass da überhaupt was empfangen wird?

OK, ich deaktiviere und sammle mal die Nachrichten

daubsi

Bisher keine neuen Nachrichten, aber ich habe jetzt im Log mal zufällig den Empfang eines ESA2000 Datagrams am CUL zeitgleich mit dem Emfang beim SignalESP
Das kann doch kein Zufall sein? Aber ich sehe noch nicht wie das Muster "Maverick" und "Grothe" zu dem passen soll/passend gemacht werden kann was triq/rtl_433 rausgelesen haben...

Die Nachricht S3F... vom CUL kann man nicht direkt aus dem decodierten Manchester lesen, dazu ist ein weiterer Bearbeitungsschritt (Rolling XOR) nötig, den ich nachgebildet habe. Dazu braucht es ein Decodierungsergebenis wie dieses: FF FE A4 8F E3 06 34 58 6F A1 87 AB C0 F1 98 1A 3F 4C F7 E7 - das ist das was ich irgendwie nach dem Manchester-Decoder sehen will... Der Prefix ist immer FF FE soweit ich sehe, insofern sind die vielen führenden 0 unten wenn man sie invertiert schon ein Schritt in die richtige Richgung... (1111 1111 1111 1110 == FF FE)

2024.09.13 16:57:03 5: CUL_Read: CUL_0 /S3F4750011E0013DF44001116352801B303
2024.09.13 16:57:03 4: CUL_Parse: CUL_0 S3F4750011E0013DF44001116352801B303 -72.5
2024.09.13 16:57:03 5: CUL_0: dispatch S3F4750011E0013DF44001116352801B3
2024.09.13 16:57:03 5: ESA2000 msg s3f4750011e0013df44001116352801b3
2024.09.13 16:57:03 5: ESA2000 seq 3f
2024.09.13 16:57:03 5: ESA2000 device 4750
2024.09.13 16:57:03 5: ESA2000 code 011e
2024.09.13 16:57:03 4: sduino/msg READ: MC;LL=-514;LH=505;SL=-247;SH=261;D=000A4B137259C8AF130BCAA907579F3E159840E0;C=254;L=157;R=241;s24;b1;
2024.09.13 16:57:03 4: sduino: Found manchester Protocol id 47 clock 254 RSSI = -81.5 -> Maverick
2024.09.13 16:57:03 5: sduino: extracted data 0000000000001010010010110001001101110010010110011100100010101111000100110000101111001010101010010000011101010111100111110011111000010101100110000100000011100000 (bin)
2024.09.13 16:57:03 5: sduino: protocol does not match return from method: (header not found)
2024.09.13 16:57:03 4: sduino: Found manchester Protocol id 96 clock 254 RSSI = -81.5 -> Grothe Mistral SE
2024.09.13 16:57:03 5: sduino: extracted data 0000000000001010010010110001001101110010010110011100100010101111000100110000101111001010101010010000011101010111100111110011111000010101100110000100000011100000 (bin)
2024.09.13 16:57:03 5: sduino: protocol does not match return from method: (Start pattern (01000111) not found)