Protokoll für WS7000-20

[HomeAutoUser]

Hallo, Inputs für den WS7000-20

MU;P0=32001;P1=-438;P2=781;P3=288;P4=-922;D=01212121212121212121342121342134343434213434342121343434212134213421213421212121342121212134213421213421212134343421212134212121343434343421343421342134343434213;CP=3;R=112 MU;P0=32001;P1=-444;P2=778;P3=297;P4=-928;D=01212121212121212121342121342134343434213434342121343434212134213421213421212121342121212134213421213421212134343421212134212121343434343421343421342134343434213;CP=3;R=112 MU;P0=11656;P1=-458;P2=765;P3=279;P4=-937;D=01212121212121212121342121342134343434213421213421343434212134213421213421212121342121212134213421213421212134343421212134212121343434212134342121343434342121213;CP=3;R=113 MU;P0=20680;P1=-460;P2=758;P3=271;P4=-951;D=01212121212121212121342121342134343434213421212134343421342134213421213421212121342121212134213421213421212134343421212134212121343434343434342121212134342121213;CP=3;R=72 MU;P0=6144;P1=-457;P2=766;P3=273;P4=-941;D=01212121212121212121342121342134343434213434212134342121212134213421213434212134342121213434343421213421343421343421212134212121343421213434343421213434343421213;CP=3;R=74

Protokollinfo Erklärung

Wie würde dann die Definitionen one => [], zero => [], .... lauten?

[sidey79]

Ich habe die Demudulierung eingebaut. Allerings ist zu Beginn nur 9x das 0 Bit im Signal. In Summe sind 79 Bits vorhanden. So wie ich das Protokoll verstanden habe, sollten aber 81 Bits vorhanden sein. Das Erste fehlt und vermutlich auch das letzte.

[HomeAutoUser]

1) Ich habe deine Änderungen übernommen via Update. Es passiert noch nichts, keine Erkennung bisher. Jeweils die richtige Zeile welche aber dann nicht sichtbar weiterverarbeitet wird.

2) Dazu fällt mir auf, das ich nach einem Programmstart erst immer den Empfänger Bsp. mit ccconf anfragen muss, bevor sich überhaupt am kompletten Empfang sich etwas ergibt. | Am Code oder der Initialisierung etwas geändert? Der Empfänger ist aber jedoch auf Status: opened.

[sidey79]

Die Werte für zero und one habe ich aus dem Link Protokollinfo... Clockabs habe ich halt mal auf 200 angenommen... in etwa passt das ja auch.

Wenn der sduino auf opened steht, dann sollte er auch funktionieren. Warum nichts erkannt wird, verstehe ich nicht. Was passiert denn im Log?

[HomeAutoUser]

Vorgehensweise:

• Stop FHEM via Konsole
• Start FHEM via Konsole
• Empfänger als opened im Status
• nix passiert (bekomme ich schnell mit, da bei der Anzahl der Sensoren Minütlich was passiert)
• ccconf Anfrage, sofort rennt er los

Logfile:

2017.02.22 23:11:29 0: Server shutdown 2017.02.22 23:11:29 5: sduino_radino SW: XQ 2017.02.22 23:11:36 1: Including fhem.cfg 2017.02.22 23:11:36 3: WEB: port 8083 opened 2017.02.22 23:11:36 3: WEBphone: port 8084 opened 2017.02.22 23:11:36 3: WEBtablet: port 8085 opened 2017.02.22 23:11:36 2: eventTypes: loaded 787 events from ./log/eventTypes.txt 2017.02.22 23:11:36 3: Opening CUL_868Mhz device /dev/serial/by-id/usb-busware.de_CUL868-if00 2017.02.22 23:11:36 3: Can't open /dev/serial/by-id/usb-busware.de_CUL868-if00: Datei oder Verzeichnis nicht gefunden 2017.02.22 23:11:36 3: sduino_radino: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 41 45 51 55 6 7 2017.02.22 23:11:36 3: sduino_radino: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 34 36 37 39 40 42 44 44.1 46 48 49 5 50 56 59 60 8 9 2017.02.22 23:11:36 3: sduino_radino: IDlist MC 10 11 12 18 43 47 52 57 58 2017.02.22 23:11:36 3: Opening sduino_radino device /dev/serial/by-id/usb-Unknown_radino_CC1101-if00 2017.02.22 23:11:36 3: Setting sduino_radino serial parameters to 57600,8,N,1 2017.02.22 23:11:36 1: sduino_radino/define: /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600 2017.02.22 23:11:36 1: sduino_radino/init: /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600 2017.02.22 23:11:36 3: sduino_radino device opened 2017.02.22 23:11:36 3: sduino_radino: setting Verbose to: 5 2017.02.22 23:11:36 3: sduino_nano: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 41 45 51 55 6 7 2017.02.22 23:11:36 3: sduino_nano: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 34 36 37 39 40 42 44 44.1 46 48 49 5 50 56 59 60 8 9 2017.02.22 23:11:36 3: sduino_nano: IDlist MC 10 11 12 18 43 47 52 57 58 2017.02.22 23:11:36 3: Opening sduino_nano device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 2017.02.22 23:11:36 3: Can't open /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0: Datei oder Verzeichnis nicht gefunden 2017.02.22 23:11:36 3: sduino_nano: setting Verbose to: 4 2017.02.22 23:11:37 1: Including ./log/fhem.save 2017.02.22 23:11:38 1: usb create starting 2017.02.22 23:11:38 3: Probing CUL device /dev/ttyAMA0 2017.02.22 23:11:38 3: Probing TCM_ESP3 device /dev/ttyAMA0 2017.02.22 23:11:38 3: Probing FRM device /dev/ttyAMA0 2017.02.22 23:11:43 1: usb create end 2017.02.22 23:11:43 0: Featurelevel: 5.8 2017.02.22 23:11:43 0: Server started with 117 defined entities (fhem.pl:13447/2017-02-19 perl:5.020002 os:linux user:fhem pid:5842) 2017.02.22 23:15:00 5: sduino_radino: command for gets: C0DnF 2017.02.22 23:15:00 3: sduino_radino/init: disable receiver (XQ) 2017.02.22 23:15:00 5: sduino_radino SW: XQ 2017.02.22 23:15:00 3: telnetForBlockingFn_1487801700: port 43097 opened 2017.02.22 23:15:00 3: sduino_radino/init: get version, retry = 0 2017.02.22 23:15:00 5: sduino_radino SW: V 2017.02.22 23:15:00 5: sduino_radino SW: C0DnF 2017.02.22 23:15:00 4: sduino_radino/msg READ: V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Feb 22 2017 18:06:42 2017.02.22 23:15:00 5: sduino_radino/msg READ: regexp=V\s.SIGNAL(duino|ESP). cmd=version msg=V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Feb 22 2017 18:06:42 2017.02.22 23:15:00 2: sduino_radino: initialized. v3.3.1-dev 2017.02.22 23:15:00 5: sduino_radino SW: XE 2017.02.22 23:15:00 3: sduino_radino/init: enable receiver (XE) 2017.02.22 23:15:00 4: sduino_radino/msg READ: C0Dn11=10B07157C43023B900070018146C070091 2017.02.22 23:15:00 4: sduino_radino/HandleWriteQueue: nothing to send, stopping timer 2017.02.22 23:15:09 4: sduino_radino/msg READ: bufferMove -> 5 bufferMove -> 11 bufferMove -> 5 bufferMove -> 11 bufferMove -> 9 bufferMove -> 4 bufferMove -> 9 bufferMove -> 9 bufferMove -> 2 bufferMove -> 9 bufferMove -> 9 check:mcrst:MU;P0=962;P1=-992;P2=-513;P3=469;D=010102323132023231023101320102323101320101320231320232313232323232023232323101323232320231323201010101323201320132323202323102323132;CP=3;R=12; 2017.02.22 23:15:09 4: sduino_radino/msg READ: check:mcrst:mlen:129:mstart: 0 2017.02.22 23:15:09 4: sduino_radino/msg READ: pulseShift:1;L1l0L1l0L1s0S_s0S_l0S1s_L1s0S_s0S_l0L1s0S_l0L1l0S1s_L1l0L1s0S_s0S_l0L1l0S1s_L1l0L1l0S1s_S1s_L1l0S1s_L1s0S_s0S_l0S1s_S1s_S1s_S1s_S1s_L1s0S_s0S_s0S_s0S_l0L1l0S1s_S1s_S1s_S1s_L1s0S_l0S1s_S1s_L1l0L1l0L1l0L1l0S1s_S1s_L1l0S1s_L1l0L1l0S1s_L1l0L1s0S_l0S1sL1l0S1s:mpos=129:mstart=1:mend=129:vcnt=89:bfin: 2017.02.22 23:15:09 4: sduino_radino/msg READ: MC;LL=-991;LH=944;SL=-524;SH=462;D=A8C4B45AEC7E0BE755DAD34;C=486;L=90;R=15; 2017.02.22 23:15:09 4: sduino_radino: Found manchester Protocol id 10 clock 486 RSSI -66.5 -> OSV2o3 2017.02.22 23:15:09 5: sduino_radino: extracted data 01010111001110110100101110100101000100111000000111110100000110001010101000100101001011001011 (bin) 2017.02.22 23:15:09 4: sduino_radino: Found manchester Protocol id 12 clock 486 RSSI -107.25 -> Hideki protocol 2017.02.22 23:15:09 5: sduino_radino: extracted data 01010111001110110100101110100101000100111000000111110100000110001010101000100101001011001011 (bin) 2017.02.22 23:15:09 4: sduino_radino: hideki protocol converted to hex: 75B7BA8A0EBE3055524D01 with 91 bits, messagestart 1 2017.02.22 23:15:09 5: sduino_radino: converted Data to (P12#75B7BA8A0EBE3055524D01) 2017.02.22 23:15:09 5: sduino_radino: dispatch P12#75B7BA8A0EBE3055524D01 2017.02.22 23:15:09 4: Hideki_Parse sduino_radino incomming P12#75B7BA8A0EBE3055524D01 2017.02.22 23:15:09 4: Hideki_Parse SensorTyp = 30 decodedString = 75d9ce9e12c250fff6d703 2017.02.22 23:15:09 4: sduino_radino decoded Hideki protocol model=Hideki_30, sensor id=d9, channel=5, bat=ok, temp=21.2, humidity=50 2017.02.22 23:15:09 5: deviceCode: Hideki_30_5 2017.02.22 23:15:09 4: sduino_radino: Found manchester Protocol id 52 clock 486 RSSI -127.625 -> OS_PIR 2017.02.22 23:15:09 5: sduino_radino: extracted data 01010111001110110100101110100101000100111000000111110100000110001010101000100101001011001011 (bin) 2017.02.22 23:15:09 4: sduino_radino: Found manchester Protocol id 58 clock 486 RSSI -137.8125 -> tfa 30.3208.0 2017.02.22 23:15:09 5: sduino_radino: extracted data 01010111001110110100101110100101000100111000000111110100000110001010101000100101001011001011 (bin) 2017.02.22 23:15:09 4: sduino_radino/msg READ: MC;P1=944;P2=-991;P3=-524;P4=462;D=0121213434243134342134212431213434212431212434312431343424343434343134343434212434343431342434312121212434312431212431213424312431;CP=4; 2017.02.22 23:15:09 4: sduino_radino/msg READ: check:mcrst:mlen:46:mstart: 0 2017.02.22 23:15:09 4: sduino_radino/msg READ: pulseShift:1;L1l0L1l0L1s0S_s0S_l0S1s_L1s0S_s0S_l0L1s0S_l0L1l0S1s_L1l0L1s0S_s0S_l0L1l0S1s_L1l0L1l0S1s_L1:mpos=46:mstart=1:mend=46:vcnt=33:bfin: 2017.02.22 23:15:09 4: sduino_radino/msg READ: MC;LL=-1007;LH=938;SL=-522;SH=461;D=A8C4B45AC;C=487;L=34;R=14; 2017.02.22 23:15:09 4: sduino_radino: Found manchester Protocol id 52 clock 487 RSSI -67 -> OS_PIR 2017.02.22 23:15:09 5: sduino_radino: extracted data 010101110011101101001011101001010011 (bin) 2017.02.22 23:15:09 4: sduino_radino/msg READ: MC;P1=938;P2=-1007;P3=-522;P4=461;D=01212134342431343421342124312134342124312124313;CP=4; 2017.02.22 23:15:09 4: sduino_radino/msg READ: check:mcrst:mlen:69:mstart: 0 2017.02.22 23:15:09 4: sduino_radino/msg READ: pulseShift:6;S1s_S1s_S1s_L1s0S_s0S_s0S_s0S_l0L1l0S1s_S1s_S1s_S1s_L1s0S_l0S1s_S1s_L1l0L1l0L1l0L1l0S1s_S1s_L1l0S1s_L1l0S1s_L1l0L1s0S_l0L1s0S_l0L1l0S1s_H(vcnt:47:mpos=68:mstart=0:mend:68:found::pidx=96 bufferMove -> 68 2017.02.22 23:15:09 4: sduino_radino/msg READ: MC;LL=-1003;LH=952;SL=-508;SH=462;D=F05F3AAEDA4A;C=487;L=47;R=14; 2017.02.22 23:15:09 4: sduino_radino: Found manchester Protocol id 52 clock 487 RSSI -67 -> OS_PIR 2017.02.22 23:15:09 5: sduino_radino: extracted data 000011111010000011000101010100010010010110110101 (bin) 2017.02.22 23:15:09 4: sduino_radino/msg READ: MC;P0=462;P1=-508;P2=952;P3=-1003;D=41;CP=0; 2017.02.22 23:15:13 4: sduino_radino/msg READ: bufferMove -> 9 bufferMove -> 9 bufferMove -> 9 bufferMove -> 8 bufferMove -> 9 check:mcrst:MU;P0=-935;P1=526;P2=-1928;P3=-248;D=01010101010121010101010101010101212121010121212121210101013;CP=1;R=213; 2017.02.22 23:15:14 4: sduino_radino/msg READ: bufferMove -> 8 bufferMove -> 11 check:mcrst:MU;P0=-112;P1=556;P2=-1920;P3=-908;P4=-352;D=01213131313131313121313131313131313131214;CP=1;R=215; 2017.02.22 23:15:15 4: sduino_radino/msg READ: bufferMove -> 9 bufferMove -> 2 bufferMove -> 7 bufferMove -> 7 bufferMove -> 9 bufferMove -> 2 check:mcrst:mlen:127:mstart: 0 2017.02.22 23:15:15 4: sduino_radino/msg READ: preamble:9Cl0L1l0L1s0S_s0S_l0S1s_L1l0S1s_L1l0L1s0S_s0S_l0S1s_L1l0L1s0S_s0S_l0L1l0S1s_L1l0L1l0S1s_L1s0S_l0L1s0S_l0S1s_L1s0S_l0S1s_S1s_S1s_S1s_S1s_S1s_S1s_S1s_L1l0S1s_S1s_L1s0S_s0S_l0S1s_S1s_L1l0L1l0L1s0S_l0L1l0L1l0L1l0S1s_L1l0S1s_L1s0S_l0S1s_S1sL1l0L1l0L1l0S1s:mpos=127:mstart=0:mend=127:vcnt=88:bfin: 2017.02.22 23:15:15 4: sduino_radino/msg READ: MC;LL=-1014;LH=938;SL=-525;SH=455;D=51B468B5933FEE3A956CEA8;C=488;L=89;R=244; 2017.02.22 23:15:15 4: sduino_radino: Found manchester Protocol id 10 clock 488 RSSI -80 -> OSV2o3 2017.02.22 23:15:15 5: sduino_radino: extracted data 10101110010010111001011101001010011011001100000000010001110001010110101010010011000101010111 (bin) 2017.02.22 23:15:15 4: sduino_radino: Found manchester Protocol id 12 clock 488 RSSI -114 -> Hideki protocol 2017.02.22 23:15:15 5: sduino_radino: extracted data 10101110010010111001011101001010011011001100000000010001110001010110101010010011000101010111 (bin) 2017.02.22 23:15:15 4: sduino_radino: hideki protocol converted to hex: 75E9BACA33408EADC95403 with 92 bits, messagestart 0 2017.02.22 23:15:15 5: sduino_radino: converted Data to (P12#75E9BACA33408EADC95403) 2017.02.22 23:15:15 5: sduino_radino: dispatch P12#75E9BACA33408EADC95403 2017.02.22 23:15:15 4: Hideki_Parse sduino_radino incomming P12#75E9BACA33408EADC95403 2017.02.22 23:15:15 4: Hideki_Parse SensorTyp = 30 decodedString = 753bce5e55c092f75bfc05 2017.02.22 23:15:15 4: sduino_radino decoded Hideki protocol model=Hideki_30, sensor id=3b, channel=1, bat=ok, temp=5.5, humidity=92 2017.02.22 23:15:15 5: deviceCode: Hideki_30_1 2017.02.22 23:15:15 4: sduino_radino: Found manchester Protocol id 52 clock 488 RSSI -131 -> OS_PIR 2017.02.22 23:15:15 5: sduino_radino: extracted data 10101110010010111001011101001010011011001100000000010001110001010110101010010011000101010111 (bin) 2017.02.22 23:15:15 4: sduino_radino: Found manchester Protocol id 58 clock 488 RSSI -139.5 -> tfa 30.3208.0 2017.02.22 23:15:15 5: sduino_radino: extracted data 10101110010010111001011101001010011011001100000000010001110001010110101010010011000101010111 (bin) 2017.02.22 23:15:15 4: sduino_radino/msg READ: MC;P1=938;P2=-1014;P3=-525;P4=455;D=01212134342431243121343424312134342124312124313421342431342434343434343434312434313434243431212134212121243124313424343121212434;CP=4; 2017.02.22 23:15:15 4: sduino_radino/msg READ: check:mcrst:mlen:105:mstart: 0 2017.02.22 23:15:15 4: sduino_radino/msg READ: s_L1l0L1s0S_s0S_l0L1l0S1s_L1l0L1l0S1s_S1s_L1l0L1s0S_l0S1s_L1s0S_l0S1s_S1s_S1s_S1s_S1s_S1s_S1s_S1s_L1l0S1s_S1s_L1s0S_s0S_l0S1s_S1s_L1l0L1l0L1s0S_l0L1l0L1l0L1l0S1s_L1l0S1s_S1s_L1l0S1s_L1s0S_s0S_l0L1s0S_l0S1s_H(vcnt:71:mpos=103:mstart=0:mend:103:found::pidx=96 bufferMove -> 103

PS: Die aktuelle Source wird verwendet.

[sidey79]

Da sind ein paar Debug Meldungen enthalten... So funktioniert der kram nicht an FHEM.

Nimm besser mal das Firmware File, welches ich für den Radino compiliert habe.

[HomeAutoUser]

Nimm besser mal das Firmware File, welches ich für den Radino compiliert habe.

Ich hatte das von der Vorversion genommen, welches auf dem Rechner liegt und bis zum Update von FHEM funktionierte. Kein Erfolg.

Dein File, ich finde dies auf Anhieb nicht und unter den FIRMWARE - FHEM Verzeichnis ist dies nicht vorhanden.

[sidey79]

Stimmt wohl, ich hatte nach dem 5.Februar keine mehr erstellt..naja dann compiliere diese Version:

https://github.com/RFD-FHEM/SIGNALDuino/commit/92374bf9744593ded7fa5d14f1ce10edc6d6abec

[HomeAutoUser]

Hier "rennt" er erstmal wieder. Da schau ich dann mal weiter zwecks dem Protokoll.

EDIT: Er findet zumindest schon mal Sensoren und legt diese an. Werte bleiben bisher noch aus.

[HomeAutoUser]

Hallo, die Devices werden angelegt nach der Anpassung von Dir. Werte bleiben jedoch noch aus. Grund dafür wird sein, die Übergabe an CUL_WS müssen angepasst werden. Die Zeichenkette, welche wir erhalten muss "zurecht gebogen" werden, indem man jede 5. 1 (CHK) herausfiltert ... usw.

Zeichenkette K..... welche für CUL_WS unverständlich ist

2017.02.23 16:30:09 4: sduino_radino: decoded matched MU Protocol id 60 dmsg K0025EB6292972DEF6ADC length 80 RSSI = -54 2017.02.23 16:30:09 5: sduino_radino: converted Data to (K0025EB6292972DEF6ADC) 2017.02.23 16:30:09 5: sduino_radino: dispatch K0025EB6292972DEF6ADC 2017.02.23 16:30:09 1: CUL_WS Cannot decode K0025EB6292972DEF6ADC

Vorschlag von mir, wäre eine Sub erstellen

sub SIGNALduino_WS7000() { "Veränderungen Zeichenkette durchführen" }

und die Rückgabe an CUL_WS, das die Daten verständlich sind.

Dazu noch eine Anpassung vornehmen Bsp:

"60" => ## WS7000 #############################################################################

MU;P0=3472;P1=-449;P2=773;P3=280;P4=-941;D=01212121212121212121342121342134343434213434212134342121212134213421213421343421342121212134212134213421343421342121213434343434213421212134343434213434342134343;CP=3;R=52;

{ name => 'WS7000',
id => '60', one => [2,-4],
zero => [4,-2],
clockabs => 200,
preamble => 'K', # prepend to converted message postamble => '', # Append to converted message
clientmodule => 'CUL_WS',

length_min => '78',

length_max => '80',

method => \&SIGNALduino_WS7000, # <--------- ????????????? }, );

Meine Frage wäre, wo wäre es am passendsten diese Sub einzubinden (00SIGNALduino.pm am Ende bei sämtlichen Sub´s ) und wie erhalte ich die Werte darin? Das war mir noch nicht gelungen obwohl ich mit shift probierte bzw. my ($name,$bitData,$id) = @; ... Die Dreherei würde ich hinbekommen denke ich, nur ohne die "Grunddaten" kann ich schlecht beginnen die Zeichenkette für CUL_WS anzupassen das Werte herauskommen, welche Stimmen.

MfG

[sidey79]

Also, das ist mir in der culfw so nicht aufgefallen, dass die 1er Check Bits dort entfernt werden.

Den Parameter Method gibt es bei den MU Nachrichten nicht. Die Demodulierung klappt in der Regel ohne Funktion.

Trotzdem kein Problem, wenn wir die Daten filtern müssen, dann geht das mit dem Parameter filterfunc .

Das ist aber vermutlich doch zu umständlich. Ich hatte einmal vor, auch nach der Verarbeitung noch eine Funktion optional durchlaufen zu können. Bin nicht sicher, ob ich es eingebaut habe :)

[HomeAutoUser]

filterfunc

Ich werde mal schauen ob ich es umgesetzt bekomme. Bisher hapert es daran, das ich die Übergabe in die Sub noch nicht erfolgreich umgesetzt bekam. Das "zurecht drehen" ist dann noch ein "Kinderspiel".

... 1er Check Bits dort entfernt werden

Die dortigen Daten sind in etwa so

"For KS300: KFFTTTHWHWWRRFR Data must be read backwards For S300TH: KaaTTHTHH Data must be read backwards " aber da kommt dann noch der Luftdruck hinzu.

Unsere Zeichenkette K0025EB6292972DEF6ADC ist dann für das Modul etwas zu "lang"

[sidey79]

filterfunc passt nicht... dafür ist es nicht gedacht.

es Fehlt noch eine predispatch oder sowas Option. Ich kann mich heute nicht mehr drum kümmern, baue es aber gerne ein. @Ralf9 was meinst Du sollen wir in dispatch generell eine Möglichkeit der Manipulation einbauen oder sollen wir das in parse_MU / parse_MC / parse_MS jeweils separat einbauen?

[HomeAutoUser]

Dann auf jedenfall über diese Funktion nachdenken bzw. den presdispatch. Im Grunde wurde schon einmal das selbige gemacht im Abschnitt

"12" => ## hideki { name => 'Hideki protocol', .... folgend und der dazugehörigen Sub

Dort werden Daten dann ebenso angepasst. Da dort auch ein Weg der method gewählt wurde schlussfolgerte ich auf diesen Weg, oder sehe ich das verkehrt, das dort dies so gemacht wurde?

[sidey79]

method ist ausschließlich für Manchester Nachrichten, da wir diese immer irgendwie analysieren müssen. Der Arduino übergibt da bereits hexadezimale Werte.

[Ralf9]

@Ralf9 was meinst Du sollen wir in dispatch generell eine Möglichkeit der Manipulation einbauen

Ich denke dies ist nicht notwendig. Bei MU Nachrichten gibt es eine "postDemodulation", evtl kann dies verwendet werden.

[sidey79]

Postdemodulation war genau das was ich in Erinnerung hatte @ralf9

Irgendwie habe ich das gestern nicht gefunden :(

[HomeAutoUser]

Postdemodulation

Ist ein Weg, welcher soeben genutzt wird ;-) Ergebnis folgt nach Vollendung.

Kleiner Zwischenschritt als Ansicht

2017.02.24 21:08:52 1: DEBUG>sduino: demodulated message raw (0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 1 1 0 1 1 0 0 1 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 1 1 1 0 1 1 1 0 0 1 0 0 0 1 1 1 0 0 1 1 1 1 1 0 1 1 1 0 1 1 1 0 0 0 1 1 0 0 1), 79 bits 2017.02.24 21:08:52 1: DEBUG>sduino: ########## Beginn SIGNALduino_postDemo_WS7000 ########## 2017.02.24 21:08:52 1: DEBUG>sduino: bit_msg vor Bearbeitung: 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 1 1 0 1 1 0 0 1 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 1 1 1 0 1 1 1 0 0 1 0 0 0 1 1 1 0 0 1 1 1 1 1 0 1 1 1 0 1 1 1 0 0 0 1 1 0 0 1 2017.02.24 21:08:52 1: DEBUG>sduino: Startbit 1 at pos: 9 2017.02.24 21:08:52 1: DEBUG>sduino: bit_msg nach Bearbeitung: 0 1 1 1 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0 0 0 1 1 0 1 1 1 2017.02.24 21:08:52 1: DEBUG>sduino: ########### Ende SIGNALduino_postDemo_WS7000 ########### 2017.02.24 21:08:52 4: sduino: decoded matched MU Protocol id 60 dmsg K74090237 length 32 RSSI = -45.5 2017.02.24 21:08:52 4: sduino: Speicherung Wert 60 dmsg HASH(0x211b5b0) 2017.02.24 21:08:52 1: DEBUG>sduino: dispatching now msg: K74090237 2017.02.24 21:08:52 1: CUL_WS Cannot decode K74090237

[HomeAutoUser]

Daumenhoch

Du kannst gern folgenden Code einarbeiten. Ich habe diesen laufen und die Werte kommen direkt über das CUL_WS Modul im FHEM an.

sub SIGNALduino_postDemo_WS7000()
{
    #$name,@bit_msg
    my @bit_msg = @_;
    my $name = "sduino";
    my $debug = AttrVal($name,"debug",0);
    my $index = 0;
    my @new_bit_msg;

    Debug "$name: ########## Beginn SIGNALduino_postDemo_WS7000 ##########" if ($debug);
    Debug "$name: bit_msg vor Bearbeitung:  @bit_msg" if ($debug);
    # Start bei erstem Bit mit Wert 1 suchen
    until (@bit_msg[$index] == 1) {
    $index++;
    }
    Debug "$name: Startbit @bit_msg[$index] at pos: $index" if ($debug);
    ##### Fehlerprüfung einbauen #####
    $index++;                                                           # first bit of data
    @new_bit_msg[0 .. 3] = reverse @bit_msg[$index+5 .. $index+8];      # [1] Sensoradresse
    @new_bit_msg[4 .. 7] = reverse @bit_msg[$index .. $index+3];        # [2] Sensortyp
    @new_bit_msg[8 .. 11] = reverse @bit_msg[$index+15 .. $index+18];   # [3] Temperatur 1
    @new_bit_msg[12 .. 15] = reverse @bit_msg[$index+10 .. $index+13];  # [4] Temperatur 0,1
    @new_bit_msg[16 .. 19] = reverse @bit_msg[$index+25 .. $index+28];  # [5] Humidity 0,1
    @new_bit_msg[20 .. 23] = reverse @bit_msg[$index+20 .. $index+23];  # [6] Temperatur 10
    @new_bit_msg[24 .. 27] = reverse @bit_msg[$index+35 .. $index+38];  # [7] Humidity 10
    @new_bit_msg[28 .. 31] = reverse @bit_msg[$index+30 .. $index+33];  # [8] Humidity 1
    @new_bit_msg[32 .. 35] = reverse @bit_msg[$index+45 .. $index+48];  # [9] Pressure 10
    @new_bit_msg[36 .. 39] = reverse @bit_msg[$index+40 .. $index+43];  # [10] Pressure 1
    @new_bit_msg[40 .. 43] = reverse @bit_msg[$index+55 .. $index+58];  # [12] Checksum
    @new_bit_msg[44 .. 47] = reverse @bit_msg[$index+50 .. $index+53];  # [11] Pressure 100

    Debug "$name: bit_msg nach Bearbeitung: @new_bit_msg" if ($debug);
    Debug "$name: ########### Ende SIGNALduino_postDemo_WS7000 ########### \n" if ($debug);
    return (@new_bit_msg);
}

    "60" => ##  WS7000 ## ggf. baugleiche
    {
        name                => 'WS7000',   
        id                  => '60',
        one                 => [2,-4],            
        zero                => [4,-2],          
        clockabs            => 200,                
        preamble            => 'K',                 # prepend to converted message
        postamble           => '',                  # Append to converted message       
        clientmodule        => 'CUL_WS',
        length_min          => '44',
        length_max          => '80',
        postDemodulation    => \&SIGNALduino_postDemo_WS7000,   # call the decode an mod-bit Sub
    }, 

[elektron-bbs]

Hallo, etwas voreilig gepostet, bitte noch nicht einbauen da die Fehlerprüfung noch fehlt. Es werden zufällig Sensoren angelegt, wenn mal ein Bit falsch kommt oder fehlt. MfG

[sidey79]

man könnte die Nachricht doch mit einer Regex prüfen

In etwa so meine ich das: https://regex101.com/r/W8BVBm/1

[elektron-bbs]

Das ist aber nur ein Teil der Prüfung. Mir geht es nicht nur um den einen Sensor, sondern um eine ganze Reihe. Das Protokoll ist beschrieben auf: http://www.dc3yc.homepage.t-online.de/protocol.htm Es gibt verschiedene Anzahl Bits in der Präambel, die Länge der Protokolle ist verschieden und dann gibt es Typ 1 auch noch mit oder ohne Prüfsumme als letztes Nibble. Ich denke, wir müssen schon alle Prüfungen durchführen, so hab ich es zumindest in meiner Eigenbau-Wetterstation gemacht und in der 14_CUL_WS.pm erfolgt ja keinerlei Prüfung, außer auf ungewöhnliche Temperaturänderungen von über 15 Grad. Eine Prüfung der Länge der Präambel und ob jedes 5. Bit 1 ist, habe ich jetzt schon drin. Trotzdem hat es mir über Nacht 5 zusätzliche Sensoren mit nicht plausiblen Werten angelegt.

[sidey79]

Auf meinem Testsystem wurde heute Nacht auch ein Sensor falschen angelegt.

Ich denke, da fehlen min und max length im Protokoll und dann im cul_ws Modul noch ein Autocreate threshhold

[elektron-bbs]

length_min und length_min habe ich jetzt schon drin. Bei mir sieht das aktuell so aus:

    "60" => ## WS7000, AS2000, ASH2000, S2000, S2001A, S2001IA, ASH2200, S300IA, S2001I, S2001ID, S2500H ##
    # das letzte Bit 1 fehlt immer
    {
        name                    => 'WS7000',
        id                          => '60',
        one                     => [2,-4],
        zero                    => [4,-2],
        clockabs                => 200,
        preamble                => 'K',                # prepend to converted message
        postamble               => '',                  # Append to converted message
        clientmodule            => 'CUL_WS',
        length_min              => '44',            # eigentlich 45, 1 Bit fehlt immer
        length_max              => '80',            # eigentlich 81, 1 Bit fehlt immer
        postDemodulation        => \&SIGNALduino_postDemo_WS7000,
    }, 

sub SIGNALduino_postDemo_WS7000() {

$name,@bit_msg

my @bit_msg = @_;
my $name = "sduino_WS7000";
my $debug = AttrVal($name,"debug",0);
my $index = 0;
my @new_bit_msg;
my $Error = 0;

Debug "$name: ########## Beginn SIGNALduino_postDemo_WS7000 ##########" if ($debug); Debug "$name: bit_msg vor Bearbeitung: @bit_msg" if ($debug);

Start bei erstem Bit mit Wert 1 suchen

# $bit_msg[9] = 0; # Test Startbit # Test Praeambel
until ($bit_msg[$index] == 1) {
    $index++;
}

Debug "$name: Startbit $bit_msg[$index] at pos: $index" if ($debug);

Fehlerpruefung

if ($index > 10) {                                                          # max 10 bits preamble
    Debug "$name: Preamble too long: $index" if ($debug);
    return 0;   # funktioniert nicht richtig!!!
} else {
    #my $length_bit_msg = length(@bit_msg)
    #Debug "$name: Length of bit_msg: $length_bit_msg" if ($debug);
    for(my $i = $index; $i < @bit_msg; $i+=5) {
        Debug "$name: Bit $bit_msg[$i] at position: $i" if ($debug);
        if (@bit_msg[$i] != 1 ) {                                           # Find errors bit 5
            $Error++;
        }
    }
    if ($Error != 0) {
        Debug "$name: Checkbits not 1" if ($debug);
        return 0;   # funktioniert nicht richtig!!!
    } else {

        ##### Fehlerprüfung einbauen #####

        # aus 14_CUL_WS.pm:
        #my $firstbyte = hex($a[1]);        # Adresse
        #my $secondbyte = hex($a[2]);   # Typ
        #if($typbyte == 4 && int(@a) > 10) {          # temp/hum/press
        #$sgn = ($firstbyte&8) ? -1 : 1;
        #$tmp = $sgn * ($a[6].$a[3].".".$a[4]) + $hash->{corr1};
        #$hum = ($a[7].$a[8].".".$a[5]) + $hash->{corr2};
        #$prs = ($a[12].$a[9].$a[10])+ 200 + $hash->{corr3};

        $index++;                                                                               # first bit of data
        @new_bit_msg[0 .. 3] = reverse @bit_msg[$index+5 .. $index+8];          # [1] Sensoradresse
        @new_bit_msg[4 .. 7] = reverse @bit_msg[$index .. $index+3];            # [2] Sensortyp
        @new_bit_msg[8 .. 11] = reverse @bit_msg[$index+15 .. $index+18];       # [3] Temperatur 1
        @new_bit_msg[12 .. 15] = reverse @bit_msg[$index+10 .. $index+13];  # [4] Temperatur 0,1

        @new_bit_msg[16 .. 19] = reverse @bit_msg[$index+25 .. $index+28];  # [5] Humidity 0,1
        @new_bit_msg[20 .. 23] = reverse @bit_msg[$index+20 .. $index+23];  # [6] Temperatur 10
        @new_bit_msg[24 .. 27] = reverse @bit_msg[$index+35 .. $index+38];  # [7] Humidity 10
        @new_bit_msg[28 .. 31] = reverse @bit_msg[$index+30 .. $index+33];  # [8] Humidity 1

        @new_bit_msg[32 .. 35] = reverse @bit_msg[$index+45 .. $index+48];  # [9] Pressure 10
        @new_bit_msg[36 .. 39] = reverse @bit_msg[$index+40 .. $index+43];  # [10] Pressure 1
        @new_bit_msg[40 .. 43] = reverse @bit_msg[$index+55 .. $index+58];  # [11] Checksum
        @new_bit_msg[44 .. 47] = reverse @bit_msg[$index+50 .. $index+53];  # [12] Pressure 100

        ##length 48 - 6 Byte - 12 Halbbyte
        Debug "$name: bit_msg nach Bearbeitung: @new_bit_msg" if ($debug);
        Debug "$name: ########### Ende SIGNALduino_postDemo_WS7000 ########### \n" if ($debug);
        return (@new_bit_msg);
    }
}

}

Irgendwie funktioniert das mit dem Code einfügen nicht so richtig. Ich lass das jetzt aber so.

Was uns auch noch aufgefallen war: Die Variable $name wird der SUB scheinbar nicht übergeben, ich musste das selbst definieren. Den korrekten returncode bei Fehlern habe ich auch noch nicht hinbekommen. Mit "return 0" wird "K0" an CUL_WS übergeben.

[HomeAutoUser]

Das Thema Fehlerüberprüfung sollte man auf jedenfall nicht nur bei diesem Protokoll verfolgen. Ich lasse das System soeben auch auf Test laufen und da ist mir neben "unserer" genannten "Fehleranlegung" CUL_WS_x auch noch eine aufgefallen bei SD_WS_X. Ich denke, es wäre auf jedenfall sinnvoll, das man für solche Auffälligkeiten vielleicht dann einen neuen Faden eröffnet.

EDIT - 23:05: Nach dem Einbau von elektron-bbs begonner Fehleranlalyse wurden bisher keine weiteren "Zufallssensoren" angelegt.

[sidey79]

Macht ihr noch einen pull request?

[HomeAutoUser]

Macht ihr noch einen Pullover request?

Erfolgt noch. Wird momentan noch dran gearbeitet und getestet.

[elektron-bbs]

Erst einmal vorweg, der Einbau der Fehlerkorrektur verzögert sich etwas, aber ich bin dran.

Bei mir zeigt sich jetzt ein anderes Problem. Ich hatte irgendwann fast keinen Empfang meiner Sensoren mehr. Nach mehrfachem Probieren und Ändern der Einstellungen bin ich dann dahinter gekommen. Wenn ich manchesterMC ausschalte, funktioniert der Empfang wunderbar (besser als mit dem CUL der zusätzlich noch am Rechner steckt. Die empfangenen Signale werden dann so dekodiert:

manchesterMC disabled: 2017.03.01 21:27:35 4: sduino/msg READ: MU;P0=32001;P1=-399;P2=830;P3=350;P4=-891;D=01212121212121212121342134342134212134213421212121342121212134212121213421212121342134212134342121213;CP=2;R=39; 2017.03.01 21:27:36 4: sduino/msg READ: MU;P0=13252;P1=-394;P2=842;P3=349;P4=-884;D=01212121212121212121342134342134213421213434343434343434212134212121213421212121342121213434343434213;CP=3;R=39; 2017.03.01 21:27:37 4: sduino/msg READ: MU;P0=21440;P1=-394;P2=840;P3=341;P4=-905;D=01212121212121212121342134342134212121213421212121342121212134212121213421212121342134342134342121213;CP=2;R=39; 2017.03.01 21:27:48 4: sduino/msg READ: MU;P0=7420;P1=-412;P2=838;P3=368;P4=-924;D=01212121212121212121343421342134212134213421342121343434212134212121213421212121342121212134343421213;CP=2;R=12; 2017.03.01 21:27:49 4: sduino/msg READ: MU;P0=32001;P1=-374;P2=840;P3=345;P4=-879;D=0121212121212121212134342121213421343421343421212134213421213421342121342134342134343434213421342121343421342134342134213;CP=3;R=39;

Schalte ich manchesterMC wieder ein, bekomme ich Protokolle in folgender Form, deren Dekodierung ich natürlich jetzt nicht eingebaut habe:

manchesterMC enabled: 2017.03.01 21:22:01 4: sduino/msg READ: MC;LL=-876;LH=834;SL=-385;SH=348;D=AAAA9549494949494AA4A4A550;C=407;L=101;R=37; 2017.03.01 21:22:08 4: sduino/msg READ: MC;LL=-873;LH=843;SL=-373;SH=358;D=AAAA954AA54AA954AA55252A554;C=407;L=107;R=254; 2017.03.01 21:22:22 4: sduino/msg READ: MC;LL=-873;LH=848;SL=-369;SH=347;D=AAAA954A4AA4A552A954A4AA554;C=406;L=106;R=35; 2017.03.01 21:22:42 4: sduino/msg READ: MC;LL=-841;LH=868;SL=-354;SH=375;D=AAAA954A4A4AA4A52552A9494A;C=406;L=103;R=243; 2017.03.01 21:22:45 4: sduino/msg READ: MC;LL=-890;LH=861;SL=-399;SH=369;D=AAAA94954A4AA552A954AA8;C=419;L=89;R=11;

Die gemessenen Pulszeiten passen eigentlich perfekt zum Soll von 366µS und 854µS (siehe Link weiter oben). Ich verwende die Firmware-Version V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38

Ich habe eben auch noch eine aktuell auf github liegende Entwickler-Version probiert. Diese wirft gleich alles durcheinander:

2017.03.01 21:16:13 4: sduino/msg READ: s_L1s0L1s0L1s0L1s0L1s0L1s0L1s0L1s0L1s0S_l0S1l0L1s0L1s0L1s0S_l0L1s0S_l0S1l0L1s0S_l0S1l0S1l0L1s0L1s0S_l0L1s0S_l0L1s0L1s0S_l0L1s0S_l0L1s0L1s0S_l0S1l0S1l0S1l0L1s0S_l0S1l0S1l0S1l0L1s0S_l0L1s0S_l0L1s0L1s0S_l0L1s0S_l0S1l0L1s0S_l0S1l0L1s0L1s0S_l0S1:mpos=121:mstart=1:mend=120:vcnt=102:bfin: 2017.03.01 21:16:13 4: sduino/msg READ: MC;LL=-869;LH=847;SL=-374;SH=351;D=AAAA95494AA4A45;C=406;L=103;R=38; 2017.03.01 21:16:13 4: sduino: Found manchester Protocol id 11 clock 406 RSSI -55 -> AS 2017.03.01 21:16:13 4: sduino/msg READ: MC;P0=14276;P1=-374;P2=847;P3=351;01212121212121212121343421212134213434213434342121342134212134213421213434343421343434342134213421213421343421343421213434;CP=3; 2017.03.01 21:16:15 4: sduino/keepalive ok, retry = 0 2017.03.01 21:16:21 4: sduino/msg READ: check:mcrst:mlen:122:mstart: 0 2017.03.01 21:16:21 4: sduino/msg READ: s_L1s0L1s0L1s0L1s0L1s0L1s0L1s0L1s0L1s0S_l0S1l0L1s0L1s0L1s0S_l0S1l0S1l0S1l0L1s0S_l0L1s0L1s0L1s0S_l0S1l0L1s0L1s0L1s0L1s0S_l0S1l0L1s0L1s0L1s0S_l0S1l0L1s0L1s0L1s0S_l0S1l0L1s0L1s0L1s0S_l0L1s0S_l0S1l0L1s0S_l0S1l0L1s0L1s0S_l0S1l0S1l0S1l0S1l0L1s0S_H(vcnt:107:mpos=121:mstart=1:mend:121:found::pidx=-20852 bufferMove -> 121 2017.03.01 21:16:21 4: sduino/msg READ: MC;LL=-878;LH=839;SL=-379;SH=347;D=AAAA954AA54AA94;C=407;L=107;R=253; 2017.03.01 21:16:21 4: sduino: Found manchester Protocol id 11 clock 407 RSSI -75.5 -> AS 2017.03.01 21:16:21 4: sduino/msg READ: MC;P0=7088;P1=-379;P2=839;P3=347;P51;CP=3; 2017.03.01 21:16:25 4: set sduino disableMessagetype manchesterMC CDC 2017.03.01 21:16:25 4: sduino/HandleWriteQueue: nothing to send, stopping timer 2017.03.01 21:16:26 4: sduino/msg READ: check:MU;P0=12048;P1=-408;P2=846;P3=360012121212121212121213434213421343421212134212134213421212121342121212134212121213421212121343434343435;CP=2;R=3; 2017.03.01 21:16:33 4: sduino/msg READ: bufferMove -> 15 check:MU;P0=28632;P1=-397;P2=829;P3=3460121212121212121212134342121213434213421342121212134213434213434212121342134342134342121213421213421342121212134342134343;CP=3;R=35; 2017.03.01 21:16:41 4: sduino/msg READ: check:MU;P0=32001;P1=-2746;P2=5020;P3=;0121345434545454545434543454345454545434343454545434543454345454545454343434545454345454543;CP=3;R=17; 2017.03.01 21:16:41 4: sduino/msg READ: check:MU;P0=-32001;P1=5008;P2=-2752;P3=01212345434545454545434543454345454545434343454545434543454345454545454343434545454345454543;CP=3;R=10;

[sidey79]

Hmm... wird als valides Manchester Signal erkannt und dann auch so behandelt.

Was die vielen Debug ausgaben aus der Entwickler Version angeht, ist es so dass ich da einen Fehler gesucht habe. Ich dachte die Meldungen hätte ich wieder deaktiviert.

[elektron-bbs]

Welche Daten muss ich dafür dann in die Konfiguration nehmen? Die für MU verwendeten funktionieren nicht.

[tbone4711]

Kennt ihr vielleicht das? Protocol of Lacrosse sensors Protocol of the Lacrosse WS7000-20 meteo sensor -Tbone

[sidey79]

Ich tendiere dazu, dass es keine Manchester Codierung ist und wir hier eine Fehlerkennung in der Firmware haben.

Ich werde es mir aber besser noch mal im Detail ansehen.

MC Nachrichten werden über Protokolldefinitionen verarbeitet. Diese müssen als Typ Manchester definiert werden.

[elektron-bbs]

OK, dann breche ich mir hier jetzt erst mal keinen weiter ab, ich habe nämlich schon versucht, die übergebenen Bits zu dekodieren, aber irgendwie passen schon die Längen der Nachrichten nicht und auch die Daten sind für mich nicht sinnvoll zu verarbeiten.

Hallo thone4711, die Seiten sind bekannt und die Protokolle wohl identisch.

[sidey79]

Hmm, bin noch ein wenig ratlos. Schaue ich mir diese Übertragung an,

MC;P0=14276;P1=-374;P2=847;P3=351;01212121212121212121343421212134213434213434342121342134212134213421213434343421343434342134213421213421343421343421213434;CP=3;�

Dann ist diese gleichanteilsfrei, was in der Regel nur bei Machester codierten Signalen der Fall ist. Ich tippe aber darauf, dass sich das ändert, sobald andere Werte gesendet werden

[elektron-bbs]

Mhmm, da hast du dir ausgerechnet eine Message aus dem Teil gepickt, wo fast nur fehlerhafte Nachrichten vom Signalduino geliefert wurden. Hier fehlt z.B. "D=" vor den Datenbits. P3=351;01212 P3=36001212121212 P3=;0121345434545454

[sidey79]

Es gibt eine eine checksumme, alle Nibbles bis auf das letzte mit xor müssen 0 ergeben

Alle Nibbles bis auf das letzte addiert +5 müssen das letzte Nibble ergeben

[elektron-bbs]

Danke, ist mir bekannt. Die Routine ist eigentlich fertig und befindet sich jetzt noch bei mir und HomeAutoUser im Testlauf.

Ich habe da etwas geändert in einer SUB, wobei ich mir aber nicht ganz sicher bin: `sub SIGNALduinocallsub { my $funcname =shift; my $method = shift; my $name = shift; my @args = @;

if ( defined $method && defined &$method )   
{
    Log3 $name, 5, "$name: applying $funcname method $method";
    #Log3 $name, 5, "$name: value bevore $funcname: @args";

    ##### elektron-bbs #####
    #my @returnvalues = $method->(@args) ;  
    my ($rcode, @returnvalues) = $method->($name, @args) ;  

   Log3 $name, 5, "$name: modified value after $funcname: @returnvalues";
    ##### elektron-bbs #####
    #return (1,@returnvalues);
   return ($rcode, @returnvalues);
} elsif (defined $method ) {                    
    Log3 $name, 5, "$name: Error: Unknown method $funcname Please check definition";
    return (0,undef);
}   
return (1,@args);           

} ` Zum ersten sollte der Name mit übergeben, was sicher kein Problem darstellt. Zum 2. gefiel es mir nicht, das dem übergeordneten Modul kein Erfolg beim Dekodieren mitgeteilt werden konnte, da hier offensichtlich fest "1" eingestellt war. Ich habe das jetzt dahingehend geändert, das mit "1" Erfolg gemeldet wird und mit "0" Misserfolg. In anderen Programmteilen finde ich aber auch "-1" als Returncode. Bei Übergabe von "1" wird allerdings die Protokollliste trotzdem noch bis zum Ende durchlaufen, allerdings ohne Aufruf des dazugehörigen Modules. Welche Vorgehensweise wäre richtig?

Bei meinen Versuchen ist mir aufgefallen, das der RSSI-Wert wohl noch nicht ganz richtig verarbeitet wird:

2017.03.01 20:46:49 4: sduino: Found manchester Protocol id 10 clock 485 RSSI -87 -> OSV2o3 2017.03.01 20:46:49 4: sduino: Found manchester Protocol id 52 clock 485 RSSI -117.5 -> OS_PIR 2017.03.01 20:46:49 4: sduino: Found manchester Protocol id 58 clock 485 RSSI -132.75 -> tfa 30.3208.0 Offensichtlich wird der RSSI mehrmals nachbearbeitet, wenn er an das nächste Modul übergeben wird. Wenn man Pech hat und das Protokoll ist weiter hinten in der Liste, wird einem ein schlechter Empfang angezeigt.

Des weiteren muss ich "ManchesterMC" immer noch abschalten, damit die Sensordaten der WS2000-Sensoren empfangen werden. Aktuelle Firmware vom 10.03. habe ich natürlich auf dem Signalduino.

[Ralf9]

Bei meinen Versuchen ist mir aufgefallen, das der RSSI-Wert wohl noch nicht ganz richtig verarbeitet wird:

Ja, stimmt da ist noch ein Fehler drin, ich werde es ändern

[HomeAutoUser]

Hallo,

da der Test seit Tagen sehr gut verläuft und auch keine "FremdInterpretation" in FHEM angelegt werden, so würde ich den Code zur Übernahme meinerseits freigeben. @sidey79 könnte Ihn einbinden.

sub SIGNALduino_postDemo_WS2000($@) {
    my ($name, @bit_msg) = @_;
    my $debug = AttrVal($name,"debug",0);
    my @new_bit_msg = "";
    my $protolength = scalar @bit_msg;
    my @datalenghtws = (35,50,35,50,70,40,40,85);
    my $subname = "WS2000";
    my $datastart = 0;
    my $index = 0;
    my $data = 0;
    my $dataindex = 0;
    my $sumindex = 0;
    my $error = 0;
    my $check = 0;
    my $sum = 5;
    my $adr = 0;
    my @sensors = (
        "Thermo",
        "Thermo/Hygro",
        "Rain",
        "Wind",
        "Thermo/Hygro/Baro",
        "Brightness",
        "Pyrano",
        "Kombi"
        );

   Debug "$name: $subname ########## Beginn SIGNALduino_postDemo_WS2000 ##########" if ($debug);

    while ($bit_msg[$datastart] == 0) { $datastart++; } # Start bei erstem Bit mit Wert 1 suchen
    my $datalength = $protolength - $datastart;
    my $datalength1 = $datalength - ($datalength % 5);      # modulo 5
    Debug "$name: $subname protolength: $protolength, datastart: $datastart, datalength $datalength" if ($debug);

    my $typ = oct( "0b".(join "", reverse @bit_msg[$datastart + 1.. $datastart + 4]));      # Sensortyp
    if ($typ > 7) {
        Log3 $name, 3, "$name: $subname Sensortyp $typ - ERROR Typ to big";
        $error ++;
        return (0);
    }

    if ($typ == 1 && ($datalength == 45 || $datalength == 46)) {$datalength1 += 5;}     # Typ 1 ohne Summe
    if ($datalenghtws[$typ] != $datalength1) {                                              # check lenght of message
        Log3 $name, 3, "$name: $subname Sensortyp $typ Adr $adr - ERROR lenght of message $datalength1";
        $error ++;
        return (0);
    }

    if ($datastart <= 10) {     # max 10 Bit preamble
        do {
            $error += !$bit_msg[$index + $datastart];           # jedes 5. Bit muss 1 sein
            $dataindex = $index + $datastart + 1;                
            $data = oct( "0b".(join "", reverse @bit_msg[$dataindex .. $dataindex + 3]));
            if ($index == 5) {$adr = ($data & 0x07)}            # Sensoradresse
            if ($datalength == 45 || $datalength == 46) {   # Typ 1 ohne Summe
                if ($index <= $datalength - 5) {
                    $check = $check ^ $data;        # Check - Typ XOR Adresse XOR … bis XOR Check muss 0 ergeben
                }
            } else {
                if ($index <= $datalength - 10) {
                    $check = $check ^ $data;        # Check - Typ XOR Adresse XOR … bis XOR Check muss 0 ergeben
                    $sum = $sum + $data;
                    $sumindex = $index + $datastart + 6;        # Position Summe
                }
            }
            $index += 5;
        } until ($index >= $datalength);
        if ($error != 0) {
            Log3 $name, 3, "$name: $subname Sensortyp $typ Adr $adr - ERROR examination bit 5";
            return (0);
        }

        if ($check != 0) {
            Log3 $name, 3, "$name: $subname Sensortyp $typ Adr $adr - ERROR check XOR";
            $error ++;
            return (0);
        }

        if ($datalength < 45 || $datalength > 46) {                         # Summe prüfen, außer Typ 1 ohne Summe
            $data = oct( "0b".(join "", reverse @bit_msg[$dataindex .. $dataindex + 3]));
            #$data = hex(SIGNALduino_b2h(join "", reverse @bit_msg[$sumindex .. $sumindex + 3]));
            if ($data != ($sum & 0x0F)) {
                Log3 $name, 3, "$name: $subname Sensortyp $typ Adr $adr - ERROR sum";
                $error += 1;
                return (0);
             }
        }

        if ($error == 0) {
            Log3 $name, 4, "$name: $subname Sensortyp $typ Adr $adr - $sensors[$typ]";
            $datastart += 1;                                                                                            # [x] - 14_CUL_WS
            @new_bit_msg[4 .. 7] = reverse @bit_msg[$datastart .. $datastart+3];                        # [2]  Sensortyp
            @new_bit_msg[0 .. 3] = reverse @bit_msg[$datastart+5 .. $datastart+8];                  # [1]  Sensoradresse
            @new_bit_msg[12 .. 15] = reverse @bit_msg[$datastart+10 .. $datastart+13];              # [4]  T 0.1, R LSN, Wi 0.1, B   1, Py   1
            @new_bit_msg[8 .. 11] = reverse @bit_msg[$datastart+15 .. $datastart+18];               # [3]  T   1, R MID, Wi   1, B  10, Py  10
            if ($typ == 0 || $typ == 2) {       # Thermo (AS3), Rain (S2000R, WS7000-16)
                @new_bit_msg[16 .. 19] = reverse @bit_msg[$datastart+20 .. $datastart+23];          # [5]  T  10, R MSN
            } else {
                @new_bit_msg[20 .. 23] = reverse @bit_msg[$datastart+20 .. $datastart+23];          # [6]  T  10,           Wi  10, B 100, Py 100
                @new_bit_msg[16 .. 19] = reverse @bit_msg[$datastart+25 .. $datastart+28];          # [5]  H 0.1,           Wr   1, B Fak, Py Fak
                if ($typ == 1 || $typ == 3 || $typ == 4 || $typ == 7) { # Thermo/Hygro, Wind, Thermo/Hygro/Baro, Kombi
                    @new_bit_msg[28 .. 31] = reverse @bit_msg[$datastart+30 .. $datastart+33];      # [8]  H   1,           Wr  10
                    @new_bit_msg[24 .. 27] = reverse @bit_msg[$datastart+35 .. $datastart+38];      # [7]  H  10,           Wr 100
                    if ($typ == 4) {    # Thermo/Hygro/Baro (S2001I, S2001ID)
                        @new_bit_msg[36 .. 39] = reverse @bit_msg[$datastart+40 .. $datastart+43];  # [10] P    1
                        @new_bit_msg[32 .. 35] = reverse @bit_msg[$datastart+45 .. $datastart+48];  # [9]  P   10
                        @new_bit_msg[44 .. 47] = reverse @bit_msg[$datastart+50 .. $datastart+53];  # [12] P  100
                        @new_bit_msg[40 .. 43] = reverse @bit_msg[$datastart+55 .. $datastart+58];  # [11] P Null
                    }
                }
            }
            Debug "$name: $subname ########### Ende SIGNALduino_postDemo_WS2000 ###########" if ($debug);
            return (1, @new_bit_msg);
        } else {
            return (0);
        }
    } else {
        Log3 $name, 3, "$name: $subname ERROR preamble";
        return (0);
    }
}

offen bleibt dann noch dies

Zum ersten sollte der Name mit übergeben, was sicher kein Problem darstellt. Zum 2. gefiel es mir nicht, das dem übergeordneten Modul kein Erfolg beim Dekodieren mitgeteilt werden konnte, da hier offensichtlich fest "1" eingestellt war. Ich habe das jetzt dahingehend geändert, das mit "1" Erfolg gemeldet wird und mit "0" Misserfolg. In anderen Programmteilen finde ich aber auch "-1" als Returncode. Bei Übergabe von "1" wird allerdings die Protokollliste trotzdem noch bis zum Ende durchlaufen, allerdings ohne Aufruf des dazugehörigen Modules. Welche Vorgehensweise wäre richtig?

sub SIGNALduino_callsub
{
my $funcname =shift;
my $method = shift;
my $name = shift;
my @args = @_;

if ( defined $method && defined &$method )   
{
    Log3 $name, 5, "$name: applying $funcname method $method";
    #Log3 $name, 5, "$name: value bevore $funcname: @args";

    ##### elektron-bbs #####
    #my @returnvalues = $method->(@args) ;  
    my ($rcode, @returnvalues) = $method->($name, @args) ;  

   Log3 $name, 5, "$name: modified value after $funcname: @returnvalues";
    ##### elektron-bbs #####
    #return (1,@returnvalues);
   return ($rcode, @returnvalues);
} elsif (defined $method ) {                    
    Log3 $name, 5, "$name: Error: Unknown method $funcname Please check definition";
    return (0,undef);
}   
return (1,@args);           
}

[elektron-bbs]

Hallo, schon wieder so voreilig - DAS IST NOCH NICHT FERTIG!

[sidey79]

Macht doch bitte einen Pull request, wenn es soweit ist. Gerne auch vorher um schon mal die ein oder andere Änderung zu begutachten

[Ralf9]

Bei meinen Versuchen ist mir aufgefallen, das der RSSI-Wert wohl noch nicht ganz richtig verarbeitet wird:

Ja, stimmt da ist noch ein Fehler drin, ich werde es ändern

Ich habe es geändert und in die dev-r33 commited

[elektron-bbs]

Hoffentlich habe ich beim pull request alles richtig gemacht? Wenn nicht, sorry, das war mein erster Versuch.

Wie schon weiter oben geschrieben, habe ich die sub SIGNALduino_callsub dahingehend umgeschrieben, das ein Returncode zurück gegeben wird, ob die SIGNALduino_postDemo erfolgreich oder nicht abgeschlossen wurde. Ich habe jetzt mehrere Varianten durchprobiert:

Bei Fehlern in der Dekodierung gebe ich ein "return 0" zurück. Die übergeordnete Routine erkennt das richtig und übergibt nicht an die CUL_WS. Soweit gut, aber es kommt mehrmals am Tag zu eigenartigen Wiederholungen:

2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) 2017.03.27 10:50:52 1: sduino: WS2000 Sensortyp 0 - ERROR lenght of message 55 (35) ... geht noch so weiter, insgesamt 32 mal.

oder auch gerade eben:

2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 18:59:18 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big

Manchmal auch ganz normal, bis auf die eine Wiederholung zwischendurch:

2017.03.28 19:18:50 1: sduino: WS2000 Sensortyp 1 - ERROR lenght of message 40 (50) 2017.03.28 19:51:39 1: sduino: WS2000 Sensortyp 6 - ERROR lenght of message 35 (40) 2017.03.28 19:54:47 1: sduino: WS2000 Sensortyp 1 - ERROR lenght of message 70 (50) 2017.03.28 20:00:07 1: sduino: WS2000 Sensortyp 1 - ERROR lenght of message 55 (50) 2017.03.28 20:00:07 1: sduino: WS2000 Sensortyp 1 - ERROR lenght of message 55 (50) 2017.03.28 20:18:58 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big

Ich hab es auch mit "return (0, @bit_msg);" versucht, mit dem gleichen Ergebnis.

Wenn ich "return 1" verwende, sieht das im Log so aus:

2017.03.28 00:08:44 1: sduino: WS2000 ERROR preamble > 10 (14) 2017.03.28 00:08:44 3: sduino: Unknown code K0, help me! 2017.03.28 01:14:58 1: sduino: WS2000 Sensortyp 1 Adr 6 - ERROR check XOR 2017.03.28 01:14:58 3: sduino: Unknown code K0, help me! 2017.03.28 01:40:48 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big 2017.03.28 01:40:48 3: sduino: Unknown code K0, help me! 2017.03.28 01:45:54 1: sduino: WS2000 Sensortyp 1 - ERROR lenght of message 35 (50) 2017.03.28 01:45:54 3: sduino: Unknown code K0, help me!

Irgend etwas funktioniert da noch nicht so richtig. Hat dazu jemand eine Idee?

[sidey79]

Ich sehe deinen Code leider nicht. :(

Den Pull request machst Du aus deinem fork gegen dev-r33 am besten. Dann sehen wir auch die geänderten Codestellen.

[HomeAutoUser]

Hallo und Frohe Ostern, seit langer Zeit finde ich nun mal wieder Zeit mich dem hier zu widmen. Nachdem ich nun mal ein Update gemacht habe um zu schauen was implementiert wurde bzw. geändert, so fiel mit auf, das einiges umgestellt wurde.

Es wurde Bsp. für den WS7000 an das Modul CUL_WS weiterverwiesen und scheinbar aber nicht die Fehlerüberprüfung eingebaut / weitergegeben. Der WS7000 wird nun bei mir erneut vermehrt zu CUL_WS 1 - x angelegt und kein echter WS7000 Wert außer "Müll" Das ist ein RÜCKSCHRITT!

Mit @elektron-bbs seiner Vorarbeit lief dies Fehlerfreier! Ist es bitte machbar, diese Vorlage mit zu implementieren oder woran hapert es?

MfG

[sidey79]

Ich hab den Überblick verloren.

Sind das die Änderungen, welche im Pull Request #147 enthalten sind?

[elektron-bbs]

Im Prinzip ja, allerdings sind noch einige Fragen offen: 1.. gepostet am 1.3. - manchesterMC muss ich weiterhin ausschalten

2. gepostet am 15.3. - wie machen wir das mit der "sub SIGNALduino_callsub"?
3. gepostet am 28.4. - manchmal häufige Wiederholungen der Fehlermeldungen. Ich habe dazu jetzt schon folgende Varianten probiert: return (0, @bit_msg); return 1; return 0; return ""; return 0, undef; Was ist als Rückgabe richtig, wenn Fehler in der Nachricht erkannt wurden?

[sidey79]

Zu 2. und 3. habe ich eventuell die Lösung gefunden. Bei 3. bin ich auf deine Hilfe angewiesen. Habe etwas committed, bitte mal testen.

2. schau ich selbst noch mal und bei 1. bin ich gerade etwas ratlos.... hmm da brauche ich noch etwas Zeit.

[elektron-bbs]

So richtig klappt das noch nicht:

2017.04.18 19:44:36 1: sduino: WS2000 Sensortyp 1 Adr 0 - ERROR examination bit

2017.04.18 19:48:35 1: 1: WS2000 Sensortyp 8 - ERROR typ to big

2017.04.18 20:47:25 1: sduino: WS2000 ERROR preamble > 10 (11)

2017.04.18 21:01:18 1: 1: WS2000 Sensortyp 8 - ERROR typ to big

2017.04.18 21:11:02 1: 1: WS2000 Sensortyp 8 - ERROR typ to big

2017.04.18 22:18:10 1: 1: WS2000 Sensortyp 10 - ERROR typ to big 2017.04.18 22:18:10 1: sduino: WS2000 Sensortyp 10 - ERROR typ to big

2017.04.18 23:47:57 1: 1: WS2000 Sensortyp 14 - ERROR typ to big

2017.04.18 23:55:49 1: sduino: WS2000 Sensortyp 8 - ERROR typ to big

2017.04.19 01:48:21 1: 0: WS2000 ERROR preamble > 10 (11) 2017.04.19 01:48:21 1: sduino: WS2000 ERROR preamble > 10 (12)

2017.04.19 04:51:30 1: sduino: WS2000 ERROR preamble > 10 (11)

2017.04.19 05:05:35 1: 0: WS2000 Sensortyp 14 - ERROR typ to big 2017.04.19 05:05:35 1: sduino: WS2000 Sensortyp 14 - ERROR typ to big

2017.04.19 07:30:33 1: 0: WS2000 ERROR preamble > 10 (17) 2017.04.19 07:30:33 1: sduino: WS2000 ERROR preamble > 10 (18)

Den Loglevel habe ich auf 1 gesetzt, sonst ist mir das zu unübersichtlich. Was auffällt, ist das manchmal "$name" nicht übergeben wird und dann offensichtlich dafür das erste Bit aus "@bit_msg" verwendet wird. Die Wiederholungen scheinen jetzt nur noch zweimal zu erfolgen.

Die Änderung von: next if (!$rcode); in: next if ($rcode < 1 ); hattest du nur in der Sub "SIGNALduino_Parse_MS($$$$%)" aber nicht in "SIGNALduino_Parse_MU($$$$@)" vorgenommen. War das Absicht?

[elektron-bbs]

Der Aufruf der sub SIGNALduino_postDemo_WS2000 ohne "$name " erfolgt durch die zuletzt neu hinzu gekommene Zeile in der sub SIGNALduino_callsub: my $subname = @{[eval {&$method}, $@ =~ /.*/]}; Diese und die darauf folgende Logausgabe habe ich erst mal auskommentiert. Ob die Wiederholungen wieder auftreten, muss ich jetzt erst mal abwarten.

Aus meinem Code (SIGNALduino_postDemo_WS2000) können noch folgende 2 Zeilen entfernt werden: my $sumindex = 0; $sumindex = $index + $datastart + 6; # Position Summe Hatte ich wohl übersehen, das das nicht mehr gebraucht wird.

[sidey79]

my $subname = @{[eval {&$method}, $@ =~ /.*/]}; hat ohnehin nicht das gemacht, was ich wollte. Der Name der Routine kann so leider nur extrahiert werden, wenn es die Routine nicht gibt. Das war zu spät, als ich das implementiert habe :)

Da gibt es aber noch spezielle Funktionen, die wollte ich mir ansehen.