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?

[elektron-bbs]

Die nur manchmal auftretende Wiederholung von Fehlermeldungen hat leider nicht aufgehört:

2017.04.22 16:30:15 1: sduino: WS2000 Sensortyp 7 - ERROR lenght of message 45 (85) 2017.04.22 16:46:59 1: sduino: WS2000 Sensortyp 1 - ERROR lenght of message 35 (50) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35) 2017.04.22 16:52:49 1: sduino: WS2000 Sensortyp 2 - ERROR lenght of message 65 (35)

[HomeAutoUser]

Hallo,

ich habe mal soeben ein aktuelle Update gemacht um zu testen, ob der WS7000 ohne manuelle Änderungen sofort erkannt wird.

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!

Das ganze scheint bei mir nun zu klappen. Danke für die Aktualisierung. Die "Fehlerrate" kann ich erst in ein paar Tagen beurteilen.

MfG

[elektron-bbs]

Da ich jetzt irgendwo im Netz eine Erläuterung zu den Parametern "clockabs", "zero" und "one" gefunden habe, habe ich die Parameter angepasst:

  "60" =>   ## ELV, LA CROSSE (WS2000/WS7000)
  {
     # MU;P0=32001;P1=-381;P2=835;P3=354;P4=-857;D=01212121212121212121343421212134342121213434342121343421212134213421213421212121342121212134212121213421212121343421343430;CP=2;R=53;            # tested sensors:   WS-7000-20, AS2000, ASH2000, S2000, S2000I, S2001A, S2001IA,
     #                    ASH2200, S300IA, S2001I, S2000ID, S2001ID, S2500H 
     # not tested:        AS3, S2000W, S2000R, WS7000-15, WS7000-16, WS2500-19, S300TH, S555TH
     # das letzte Bit 1 und 1 x 0 Preambel fehlt meistens
     #  ___        _
     # |   |_     | |___
     #  Bit 0      Bit 1
     # kurz 366 µSek / lang 854 µSek / gesamt 1220 µSek - Sollzeiten 
     name                 => 'WS2000',
     id                   => '60',
     one                  => [3,-7],    
     zero                 => [7,-3],
     clockabs             => 122,
     preamble              => 'K',        # prepend to converted message
     postamble             => '',         # Append to converted message
     clientmodule         => 'CUL_WS',   
     length_min           => '44',        # eigentlich 46
     length_max           => '82',        # eigentlich 81
        postDemodulation     => \&SIGNALduino_postDemo_WS2000,
    }, 

Außerdem können aus meinem Code (SIGNALduino_postDemo_WS2000) 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.

"manchesterMC" muss bei mir weiterhin ausschaltet bleiben, da der meiste Teil der Nachrichten sonst als Manchester deklariert wird.

Die bereits erwähnte Wiederholung von Fehlermeldungen passiert immer noch manchmal.

[elektron-bbs]

Da auch diese Korrektur noch nicht eingearbeitet wurde, melde ich mich nochmal. Bitte ändert mal die im letzten Post geänderte Definition. Außerdem habe ich in der "sub SIGNALduino_postDemo_WS2000" Korrekturen vorgenommen (siehe letztes Posting). Die Loglevel der Fehlermeldungen habe ich auf 3 gesetzt:

sub SIGNALduino_postDemo_WS2000($@) { my ($name, @bitmsg) = @; 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 $datastart = 0; my $datalength = 0; my $datalength1 = 0; my $index = 0; my $data = 0; my $dataindex = 0; my $error = 0; my $check = 0; my $sum = 5; my $typ = 0; my $adr = 0; my @sensors = ( "Thermo", "Thermo/Hygro", "Rain", "Wind", "Thermo/Hygro/Baro", "Brightness", "Pyrano", "Kombi" );

while ($bit_msg[$datastart] == 0) { $datastart++; } # Start bei erstem Bit mit Wert 1 suchen
$datalength = $protolength - $datastart;
$datalength1 = $datalength - ($datalength % 5);         # modulo 5
Log3 $name, 5, "$name: WS2000 protolength: $protolength, datastart: $datastart, datalength $datalength";
$typ = oct( "0b".(join "", reverse @bit_msg[$datastart + 1.. $datastart + 4]));     # Sensortyp
if ($typ > 7) {
    Log3 $name, 3, "$name: WS2000 Sensortyp $typ - ERROR typ to big";
    return 0, undef;
}
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: WS2000 Sensortyp $typ - ERROR lenght of message $datalength1 ($datalenghtws[$typ])";
    return 0, undef;
} elsif ($datastart > 10) {                                 # max 10 Bit preamble
    Log3 $name, 3, "$name: WS2000 ERROR preamble > 10 ($datastart)";
    return 0, undef;
} else {
    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 += $data;
            }
        }
        $index += 5;
    } until ($index >= $datalength);
}
if ($error != 0) {
    Log3 $name, 3, "$name: WS2000 Sensortyp $typ Adr $adr - ERROR examination bit";
    return (0, undef);
} elsif ($check != 0) {
    Log3 $name, 3, "$name: WS2000 Sensortyp $typ Adr $adr - ERROR check XOR";
    return (0, undef);
} else {
    if ($datalength < 45 || $datalength > 46) {             # Summe prüfen, außer Typ 1 ohne Summe
        $data = oct( "0b".(join "", reverse @bit_msg[$dataindex .. $dataindex + 3]));
        if ($data != ($sum & 0x0F)) {
            Log3 $name, 3, "$name: WS2000 Sensortyp $typ Adr $adr - ERROR sum";
            return (0, undef);
        }
    }
    Log3 $name, 4, "$name: WS2000 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
            }
        }
    }
    return (1, @new_bit_msg);
}

}

[elektron-bbs]

Danke für den Einbau. Die Änderung des Loglevels der Fehlermeldungen von 4 auf 3 wolltest du wohl nicht einbauen? Da scheinen ja die Meinungen auseinander zu gehen.

[sidey79]

Stimmt. Im Normalfall braucht ein Anwender diese Meldungen nicht. Was soll er damit machen?

Wenn etwas zu analysieren ist, da es ein Problem gibt, kann man doch den verbose level auf 4 stellen.

[elektron-bbs]

Naja, gefällt mir eigentlich nicht. Bei Level 4 kommt gleich wieder zu viel Schrott ins Log, den man im Normalfall nicht braucht. Ich würde im Normalfall (Level 3) schon gern die Fehler sehen und kann dem dann auf den Grund gehen, wenn es zu viel wird. Euch als Entwickler spart deine Ansicht natürlich lästige Nachfragen, weil Otto-Normaluser die Fehler gar nicht erst zu sehen bekommt.

[sidey79]

So, nach langer Zeit wollte ich doch zumindest jetzt einmal einen Informationsstand bekanntgeben.

Wie vermutet, ist in dem MCDecoder ein Bug, so dass er dieses Signal als MC erkennt, obwohl es keines ist. Ich habe mich nun die letzten Tage damit beschäftigt. Ich muss mir da noch etwas einfallen lassen, damit der fix keine neuen Probleme verursacht.

[sidey79]

@Ralf9 @HomeAutoUser ich habe an den MC Decoder angepasst. In meinen Versuchen, wird das 1. Bit nun wieder invertiert erkannt. Eventuell eher richtiger als vor. Ganz sicher bin ich mir da nicht. Die Spezifikation wertet erst ab dem ersten langen puls aus und das habe ich etwas optimiert.

Ich habe eine angepasste Firware für Arduino Nano mit cc1101 compiliert: https://drive.google.com/file/d/0B3UU1FxM6ZDUY1lJQUlJRmhxSGM/view?usp=sharing

Bitte mal insbesondere auch auf MC Empfang testen. Eventuell muss noch etwas im FHEM Modul oder auch im Arduino code angepasst werden.

[HomeAutoUser]

Hallo, ich werde es mal testen @sidey79. Sollte es @elektron-bbs noch nicht gelesen haben, so kann er dies auch mal testen.

[Ralf9]

Ich habe gerade kein Nano mit cc1101 aufgebaut. Ich verwende ein 3,3V pro mini, da ich dazu keine levelshifter benötige. @pejonp hast Du einen Nano mit cc1101 mit dem Du den MC Empfang testen kannst.

Bitte dann die raw-Nachrichten vom MC Sensor hier posten. Ich kann es mir dann auch mal anschauen.

[elektron-bbs]

Da bei mir auch kein Nano mit CC1101 in Verwendung ist, habe ich mir den Branch dev-r33_fixmc geladen und für meinen Radino compiliert. Ich hoffe, @sidey79 hat auch diesen verwendet, passt zumindest vom Änderungsdatum dazu.

Meine Sensoren werden jedenfalls jetzt alle als "MU" erkannt, auch nachdem ich "MC" wieder aktiviert habe. Das musste ich ja bisher abschalten. Der SIGNALduino läuft mit dieser Version seit 30 Minuten. Die Sensoren senden im Takt von knapp 180 Sekunden:

[pejonp]

@ralf die neue version habe ich mir runtergeladen und compiliert und lasse sie jetzt auf einem nano + cc1101 laufen. bis jetzt werden alle sensoren angezeigt. kann noch nichts negativen fetstellen.

[sidey79]

@Ralf9

Hier auch eine Version für den Arduino pro mini (3v3): https://drive.google.com/file/d/0B3UU1FxM6ZDULWxqTnBXZkFFRHc/view?usp=sharing

@elektron-bbs Ja der dev-r33_fixmc ist der richtige branch. Du hast doch recht viele Sensoren :)

[HomeAutoUser]

@sidey79

Ich habe eine angepasste Firware für Arduino Nano mit cc1101 compiliert: https://drive.google.com/file/d/0B3UU1FxM6ZDUY1lJQUlJRmhxSGM/view?usp=sharing

Kannst du bitte das File auch im Hex-Format zur Verfügung stellen.

[sidey79]

Für welchen Mikrocontroller brauchst Du die Datei?

Gesendet von meinem Motorola XT1650 mit FastHub

[Ralf9]

@sidey79

Hier auch eine Version für den Arduino pro mini (3v3)

Ich habe damit mal mit einem Bresser Sensor (Hideki) den MC- Empfang getestet. Der Empfang ist damit ähnlich gut wie vorher. Ich hatte den Eindruck, daß die Empfangsqualität geringfügig schlechter geworden ist. Mit der vorherigen Version wurden ein klein wenig mehr korrekte Wiederholungen empfangen. Es ist aber trotzdem noch ausreichend.

[Ralf9]

ich habe an den MC Decoder angepasst. In meinen Versuchen, wird das 1. Bit nun wieder invertiert erkannt.

Ich habe es nochmals getestet. Dazu habe zum Dekodieren der nicht invertierten Nachrichten die ID 12.1 zugefügt:

    "12.1"    =>            ## hideki
        {
            name            => 'Hideki protocol***',    
            id              => '12',
            clockrange      => [420,510],                   # min, max better for Bresser Sensors, OK for hideki/Hideki/TFA too     
            format          => 'manchester',    
            preamble        => 'P12#',                      # prepend to converted message  
            clientmodule    => 'hideki',                # not used now
            modulematch     => '^P12#75.+',                         # not used now
            length_min      => '71',
            length_max      => '128',
            method          => \&SIGNALduino_Hideki,    # Call to process this message
            #polarity        => 'invert',           
        },

Bei diesen Zeilen habe ich das loglevel von 4 auf 3 geändert

            if (defined($rssi)) {
                Log3 $name, 3, "$name: Found manchester Protocol id $id clock $clock RSSI $rssi -> $ProtocolListSIGNALduino{$id}{name}";
            } else {
                Log3 $name, 3, "$name: Found manchester Protocol id $id clock $clock -> $ProtocolListSIGNALduino{$id}{name}";
            }

und mit dieser whitelist attr sduino whitelist_IDs 12,12.1

habe ich im Event monitor folgendes erhalten. Da ist erkennbar, daß recht viele Nachrichten als id 12.1 (nicht invertiert) erkannt werden. Ich habe dann auch nochmal eine Version ohne den mcfix getestet, damit wurden dann keine nicht invertierten Nachrichten (id 12.1) erkannt.

2017.08.24 20:35:12.378 3 : sduino: Found manchester Protocol id 12.1 clock 485 RSSI -51 -> Hideki protocol***
2017-08-24 20:35:12.383 Hideki Hideki_30_d4.5 T: 22.1 H: 71

2017.08.24 20:35:13.008 3 : sduino: Found manchester Protocol id 12.1 clock 486 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:35:13.009 Hideki Hideki_30_d4.5 T: 22.1 H: 71

2017.08.24 20:36:03.377 3 : sduino: Found manchester Protocol id 12 clock 485 RSSI -50 -> Hideki protocol
2017-08-24 20:36:03.383 Hideki Hideki_30_d4.5 T: 22.1 H: 71

2017.08.24 20:36:54.360 3 : sduino: Found manchester Protocol id 12.1 clock 485 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:36:54.364 Hideki Hideki_30_d4.5 T: 22.2 H: 71
2017.08.24 20:36:54.520 3 : sduino: Found manchester Protocol id 12.1 clock 487 RSSI -50.5 -> Hideki protocol***
2017-08-24 20:36:54.521 Hideki Hideki_30_d4.5 T: 22.2 H: 71

2017.08.24 20:37:45.390 3 : sduino: Found manchester Protocol id 12 clock 485 RSSI -50 -> Hideki protocol
2017-08-24 20:37:45.392 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:38:36.387 3 : sduino: Found manchester Protocol id 12.1 clock 484 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:38:36.389 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:38:37.001 3 : sduino: Found manchester Protocol id 12 clock 486 RSSI -72.5 -> Hideki protocol
2017-08-24 20:38:37.002 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:39:27.381 3 : sduino: Found manchester Protocol id 12 clock 487 RSSI -72.5 -> Hideki protocol
2017-08-24 20:39:27.383 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:40:18.377 3 : sduino: Found manchester Protocol id 12.1 clock 486 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:40:18.379 Hideki Hideki_30_d4.5 T: 22.2 H: 70
2017.08.24 20:40:18.998 3 : sduino: Found manchester Protocol id 12 clock 487 RSSI -50 -> Hideki protocol
2017-08-24 20:40:18.000 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:41:09.383 3 : sduino: Found manchester Protocol id 12.1 clock 483 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:41:09.388 Hideki Hideki_30_d4.5 T: 22.1 H: 70
2017.08.24 20:41:09.981 3 : sduino: Found manchester Protocol id 12.1 clock 486 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:41:09.982 Hideki Hideki_30_d4.5 T: 22.1 H: 70

2017.08.24 20:42:00.361 3 : sduino: Found manchester Protocol id 12 clock 486 RSSI -72.5 -> Hideki protocol
2017-08-24 20:42:00.363 Hideki Hideki_30_d4.5 T: 22.2 H: 70
2017.08.24 20:42:00.526 3 : sduino: Found manchester Protocol id 12.1 clock 487 RSSI -51 -> Hideki protocol***
2017-08-24 20:42:00.528 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:42:51.380 3 : sduino: Found manchester Protocol id 12 clock 485 RSSI -72.5 -> Hideki protocol
2017-08-24 20:42:51.385 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:43:42.378 3 : sduino: Found manchester Protocol id 12 clock 486 RSSI -72.5 -> Hideki protocol
2017-08-24 20:43:42.383 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:43:42.993 3 : sduino: Found manchester Protocol id 12.1 clock 485 RSSI -72.5 -> Hideki protocol***
2017-08-24 20:43:42.994 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:44:33.393 3 : sduino: Found manchester Protocol id 12.1 clock 486 RSSI -50 -> Hideki protocol***
2017-08-24 20:44:33.396 Hideki Hideki_30_d4.5 T: 22.2 H: 70

2017.08.24 20:46:15.363 3 : sduino: Found manchester Protocol id 12 clock 486 RSSI -72.5 -> Hideki protocol
2017-08-24 20:46:15.368 Hideki Hideki_30_d4.5 T: 22.1 H: 70
2017.08.24 20:46:15.528 3 : sduino: Found manchester Protocol id 12.1 clock 486 RSSI -50 -> Hideki protocol***
2017-08-24 20:46:15.530 Hideki Hideki_30_d4.5 T: 22.1 H: 70

[sidey79]

@ralf9: Das mit dem Invertiert empfangen ist doch aus einer Anpassung im MAC Decoder entstanden. Ich glaube, die war nicht ganz richtig.

So wie es jetzt übergeben wird, (nicht Invertiert) müsste es korrekt sein. Was mich wundert ist aber, dass es manchmal Invertiert und manchmal nicht Invertiert sein soll. Dem würde ich gerne auf den Grund gehen, weiss aktuell nur noch nicht wie :)

Gesendet von meinem Motorola XT1650 mit FastHub

[elektron-bbs]

Da die Arbeiten an dem FHT80TF ( #171 ) noch etwas dauern, möchte ich den Fehler, der dort aufgefallen ist und auch beim WS2000 auftreten könnte, hier korrigieren. In der sub SIGNALduino_postDemo_WS2000 müsste deshalb die Zeile:

while ($bit_msg[$datastart] == 0) { $datastart++; } # Start bei erstem Bit mit Wert 1 suchen

durch diesen Code ersetzt werden:

for ($datastart = 0; $datastart < $protolength; $datastart++) {   # Start bei erstem Bit mit Wert 1 suchen
    last if $bit_msg[$datastart] eq "1";
}
if ($datastart == $protolength) {                                 # all bits are 0
    Log3 $name, 3, "$name: WS2000 - ERROR message all bit are zeros";
    return 0, undef;
}

[HomeAutoUser]

Da das Protokoll WS7000 eingearbeitet wurde und die Anpassungen von @elektron-bbs ebenso eingerarbeitet wurden, so schließe ich das Thema. Andere Theme bitte unter dem dazugehörigen Faden führen. Ich möchte gern die Ordnung ein wenig behalten bzw. schaffen ;-) um die Übersichtlichkeit für @sidey79 und @Ralf9 und co zu gewährleisten.