Optimierungen an der sub SIGNALduino_Parse_MU()

[Ralf9]

Mir ist hier https://forum.fhem.de/index.php/topic,88568.0.html bei dem Sensor Quigg_gt9000 aufgefallen, daß es ab und zu vorkommen kann, daß die Strings für One und Zero falsch ermittelt werden.

Z.B. hier wird
MU;P0=-563;P1=479;P2=991;P3=-423;P4=361;P5=-1053;P6=3008;P7=-7110;D=2345454523452323454523452323452323452323454545456720151515201520201515201520201520201520201515151567201515152015202015152015202015202015202015151515672015151520152020151520152020152020152020151515156720151515201520201515201520201520201520201515151;CP=1;R=21;

mit dieser Protokolldefinition (one und start habe ich angepasst)

    "49"    =>          ## quigg / Aldi gt_9000
        {
            name            => 'quigg_gt9000',  
            id              => '49',
            clockabs        => 400,                         
            one         => [2,-1.2],
            zero            => [1,-3],
            start           => [6,-15],
            format          => 'twostate',  
            preamble        => 'U49#',                      # prepend to converted message  
            #clientmodule    => '',                         # not used now
            modulematch     => '^U49#.*',                   # not used now
            length_min      => '22',
            length_max      => '28',
        }, 

für one 23 und für zero 45 ermittelt. Richtig wäre 20 und 15. Das Problem dabei ist, daß die 23 (991 u -423) am Anfang als one erkannt werden. Mit diesem one 23 werden dann die 20 (991 u -563) nach dem start (67) nicht mehr als one erkannt!

Ich habe es so angepasst, daß zuerst der Startstring 67 gesucht wird und dann alles bis zum Startstring abgeschnitten wird. Erst dann werden die one und zero Strings ermittelt.

Ist es ok, wenn ich die Anpassungen als neuen branch vom dev-r33 comitte?

[sidey79]

Das deckt sich mit dem, was ein anderer Anwender auch herausgefunden hat.

Ich würde halt bei den Zuordnungen Versuchen bei Ganzzahlen zu bleiben.

Committen ist gut, ein neuer Branch wäre nicht nötig finde ich.

Grüße Sidey

[Ralf9]

Ein neuer Branch ist mir lieber, da ich recht viel geändert und es nicht komplett getestet habe. Ist es eigentlich möglich den neuen Branch nach dem Mergen zu Löschen?

Das deckt sich mit dem, was ein anderer Anwender auch herausgefunden hat.

Hast Du einen Link dazu?

[sidey79]

Was hast Du denn noch außer die Protokoll Definition geändert?

[Ralf9]

Ich habe in der SIGNALduino_Parse_MU() einiges geändert, auch bei "searching new start" und "restarting demodulation" habe ich Anpassungen vorgenommen

[sidey79]

Okay, dann mach Mal einen neuen Branch. Den kann man später auch wieder löschen :)

[Ralf9]

evtl macht es auch Sinn die Anzahl der repeats (restartings) zu begrenzen. Z.B mit einem Attribut und mit einem default von z.B. 3

z.B. die Protocol id 79 -> VTX-BELL_Funkklingel hat 7 repeats

2018.06.23 10:38:48.136 4 : sduinoD/msg get raw: MU;P0=656;P1=-656;P2=335;P3=-326;P4=-5024;D=01230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303;CP=2;O;
2018.06.23 10:38:48.136 4 : sduinoD: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
2018.06.23 10:38:48.136 5 : sduinoD: Starting demodulation (Start: 42 cut Pos 25; Signal: ^(30|12) Pos 0)
2018.06.23 10:38:48.136 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.136 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 0
2018.06.23 10:38:48.136 5 : sduinoD Dispatch: U79#A5E, test gleich
2018-06-23 10:38:48.142 SIGNALduino sduinoD DMSG U79#A5E
2018.06.23 10:38:48.142 5 : sduinoD: restarting demodulation at Position 24+2
2018.06.23 10:38:48.142 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.142 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 1
2018.06.23 10:38:48.142 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.142 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.142 5 : sduinoD: restarting demodulation at Position 50+2
2018.06.23 10:38:48.142 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.142 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 2
2018.06.23 10:38:48.142 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.142 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.142 5 : sduinoD: restarting demodulation at Position 76+2
2018.06.23 10:38:48.142 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.142 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 3
2018.06.23 10:38:48.142 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.142 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.142 5 : sduinoD: restarting demodulation at Position 102+2
2018.06.23 10:38:48.142 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.142 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 4
2018.06.23 10:38:48.142 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.142 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.142 5 : sduinoD: restarting demodulation at Position 128+2
2018.06.23 10:38:48.143 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.143 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 5
2018.06.23 10:38:48.143 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.143 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.143 5 : sduinoD: restarting demodulation at Position 154+2
2018.06.23 10:38:48.143 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.143 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 6
2018.06.23 10:38:48.143 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.143 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.143 5 : sduinoD: restarting demodulation at Position 180+2
2018.06.23 10:38:48.143 5 : sduinoD: dispatching bits: 1 0 1 0 0 1 0 1 1 1 1 0
2018.06.23 10:38:48.143 4 : sduinoD: decoded matched MU Protocol id 79 dmsg U79#A5E length 12 repeat 7
2018.06.23 10:38:48.143 5 : sduinoD Dispatch: U79#A5E, test gleich
2018.06.23 10:38:48.143 4 : sduinoD Dispatch: U79#A5E, Dropped due to short time or equal msg
2018.06.23 10:38:48.143 5 : sduinoD: restarting demodulation at Position 206+2
2018.06.23 10:38:48.143 5 : sduinoD: length (12/) does not match (1 0 1 0 0 1 0 1 1 1), 10 bits

[sidey79]

Wofür wäre es gut, die Anzahl an Wiederholungen zu limitieren?

[Ralf9]

max ca 3 Wiederholungen müssten eigentlich normalerweise ausreichend sein. Es ist auch denkbar, daß es in Zukunft mal eine firmware geben wird (z.B. für den ESP) wo der Datenteil einer MU-Nachricht länger als 256 Zeichen ist, dann kann es auch mehr Wiederholungen geben. Oder kannst Du ausschließen, daß es in Zukunft so eine firmware geben wird?

Und damit es unter keinen Umständen zu einer Endlosschleife kommen kann. So wie ich es programmiert habe kann es eigentlich nicht zu einer Endlosschleife kommen, aber ich kann es trotzem nicht zu 100% ausschließen. Ich hatte beim Entwickeln mal eine Endlosschleife, die fhem.log hatte dann innerhalb von kurzer Zeit eine Größe von 1 GB

[Ralf9]

Repeat zugefügt https://github.com/RFD-FHEM/RFFHEM/commit/5b24ee8334d09ec08594b2a238b6138a005e2086

[Ralf9]

Endlosschleife bei Parse_MU gefixt https://github.com/RFD-FHEM/RFFHEM/commit/d4694ed2d9ad75a361bc5c70e30238e5040433de

[Ralf9]

Mir ist aufgefallen, daß bei einigen IDs eine demodulation versucht wird obwohl die clockabs nicht in der Toleranz ist. Z.B. bei einer ID 79 MU-Nachricht und die ID 8.

Zuerst habe ich gedacht es einfach so wie bei den MS-Nachrichten zu machen und zum Testen die in CP stehende clock zu nehmen. Mir ist dann aber aufgefallen, daß bei MU-Nachrichten in CP nicht immer die richtige clock steht. Z.B.

        name           => 'WS7053', 
        id             => '67',
            one            => [-38,10],
            zero           => [-38,28],      
            clockabs       => 122,

Hier ist die clock 3421 MU;P0=1148;P1=3421;P6=-664;P7=-4631;D=16170717071717171717071717071717171717070707170717171717070717171710;CP=1;R=29; und hier ist die clock 1149 MU;P0=3389;P3=2560;P4=-720;P5=1149;P7=-4616;D=345407570757070707070757070757070707070757570707075707070707570757575;CP=5;R=253;

Eine möglichkeit wäre zur ermittlung der richtigen clock einen neuen Eintrag in der Protokolldefinition zu verwenden. Z.B bei der ID 8 MU;P0=656;P1=-656;P2=335;P3=-326;P4=-5024;D=01230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303;CP=2;O;

        name            => 'TX3 Protocol',  
    id              => '8',
    one             => [1,-2],
    zero            => [2,-2],
    clockabs        => 470,
    clockpos        => 1,

$signal_regex = "(21|01)" Die clockpos 1 in der $signal_regex ist 2 -> clock=335

[sidey79]

Ja das liegt daran, dass bei einem MU Signal die clock kein kompletter puls sein muss. Bei MS Signalen ist das halt per definition so.

Die clockpos verstehe ich nicht. Den CP Wert bei MU Nachrichten können wir ja auch weiterhin ignorieren oder?

[Ralf9]

$signal_regex = "($oneStr" . "|" . "$zeroStr)"
ergibt
$signal_regex = "(21|01)"
21 -> one [1,-2],
01 -> zero [2,-2]

Da die 2 die Clock ist (P2=335) ist und die pos 1 im $signal_regex ist, ist clockpos => 1,

Falls es MU IDs gibt, wo in CP immer die richtige clock steht, können wir dies mit clockpos => -1 markieren und dann die CP als clock nehmen

[sidey79]

welche Werte könnte clockpos noch annehmen? -1 ist wohl sowas wie false und 1 true?

[Ralf9]

Hier ist die $signal_regex = (45|12) Da hier 1 (P1=429) die clock ist und die pos im signal_regex String 4 ist, ist clockpos => 4,

MU;P0=-21652;P1=429;P2=-367;P4=634;P5=-555;D=012121212121212121212121245124545121245451212454545121245124545454512454545121245451212121212124512451245451245121212;CP=1;R=38;

            name            => 'FHT80TF',
            comment        => 'Door/Window switch (868Mhz)',
            id              => '70',
            one             => [1.5,-1.5],  # 600
            zero            => [1,-1],  # 400
            clockabs        => 400,
            clockpos        => 4,

Die ID 80 ist ein Fall wo die CP eigentlich immer passen müsste:

            name            => 'EM (Energy-Monitor)',
            comment     => 'EM (Energy-Monitor) (868Mhz)',
            id              => '80',
            one         => [1,-2],  # 800
            zero            => [1,-1],  # 400
            clockabs        => 400,
            clockpos        => -1

[Ralf9]

Es sieht dann etwas vereinfacht so aus

my clockpos = $ProtocolListSIGNALduino{$id}{clockpos};
my $clockidx = substr($signal_regex, clockpos, 1);
my $msgclockabs= $msg_parts{pattern}{$clockidx};

[Ralf9]

Evtl ist bei der clockpos die folgende Form praktischer: clockpos => [one, 0],

z.B. bei dieser ID:

            name                 => 'WS2000',
            comment              => 'Series WS2000/WS7000 of various sensors',
            id                   => '60',
            one                  => [3,-7], 
            zero                 => [7,-3],
            clockabs => 122,
            clockpos        => [one, 0],

dies hier MU;P0=32001;P1=-381;P2=835;P3=354;P4=-857;D=01212121212121212121343421212134342121213434342121343421212134213421213421212121342121212134212121213421212121343421343430;CP=2;R=53; ergibt hiermit bei one $pstr=SIGNALduino_PatternExists($hash,\@{$ProtocolListSIGNALduino{$id}{one}},\%patternList,\$rawData)) einen $pstr 24

Die pos 0 im $pstr ist 2 (P2=835). Und die clock von der Protokoll ID definition ist: $clockabs * 3 (3 ergibt sich aus der pos 0 von [3,-7])

[sidey79]

Wenn sich die Werte in clockpos auf die ID der Pulse bezieht, dann ist das in meinen Augen wie Lotto spielen.

Die IDs der Pulse werden durch den Empfänger beeinflusst und sind ja nicht immer identisch, obwohl das gleiche Signal empfangen wurde.

[Ralf9]

Die Werte in clockpos beziehen sich auf $pstr In $pstr stehen dann die IDs der pulse

[Ralf9]

Ich habs bei mir eingebaut, es gibt 3 Fälle.

Der Fall wo die CP aus der Nachricht eigentlich immer passen müsste. In clockpos steht was ungleich one oder zero

Z.B. bei der Id 80

            one         => [1,-2],  # 800
            zero            => [1,-1],  # 400
            clockabs        => 400,
            clockpos        => ['cp',0],

            my $msgclock;
            my $clocksource = $ProtocolListSIGNALduino{$id}{clockpos}[0];
            if (!defined($clocksource))
            {
                $clocksource = "";
            } elsif ($clocksource ne "one" && $clocksource ne "zero") { # 
                $msgclock = $msg_parts{pattern}{$msg_parts{clockidx}};
                if (!SIGNALduino_inTol($clockabs,$msgclock,$msgclock*0.30)) {
                    Log3 $name, 5, "$name: for MU Protocol id $id, clockId=$clockabs, clockmsg=$msgclock (cp) is not in tol=" . $msgclock*0.30;
                    next;
                }
            }

Der Fall wo die clock in "one" ist Z.B. bei der Id 8

    one     => [1,-2],
    zero        => [2,-2],
    clockabs        => 470,
    clockpos    => ['one',0],

            my $ProtocListClock;

            $valid = $valid && ($pstr=SIGNALduino_PatternExists($hash,\@{$ProtocolListSIGNALduino{$id}{one}},\%patternList,\$rawData)) >=0;
            Debug "Found matched one" if ($debug && $valid);
            if ($valid && $clocksource eq "one")
            {
                $msgclock = $msg_parts{pattern}{substr($pstr, $ProtocolListSIGNALduino{$id}{clockpos}[1], 1)};
                $ProtocListClock = $clockabs * $ProtocolListSIGNALduino{$id}{one}[$ProtocolListSIGNALduino{$id}{clockpos}[1]];
                if (!SIGNALduino_inTol($ProtocListClock,$msgclock,$msgclock*0.30)) {
                    Log3 $name, 5, "$name: for MU Protocol id $id, protocClock=$ProtocListClock, msgClock=$msgclock (one) is not in tol=" . $msgclock*0.30;
                    next;
                }
            }

Der Fall wo die clock in "zero" ist Z.B. bei der Id 45

        one          => [2,-2],
        zero         => [1,-2],
        start        => [83,-3], 
        clockabs     => 120, 
        clockpos     => ['zero',0],

            if (scalar @{$ProtocolListSIGNALduino{$id}{zero}} >0) {
                $valid = $valid && ($pstr=SIGNALduino_PatternExists($hash,\@{$ProtocolListSIGNALduino{$id}{zero}},\%patternList,\$rawData)) >=0;
                Debug "Found matched zero" if ($debug && $valid);
                if ($valid && $clocksource eq "zero")
                {
                    $msgclock = $msg_parts{pattern}{substr($pstr, $ProtocolListSIGNALduino{$id}{clockpos}[1], 1)};
                    $ProtocListClock = $clockabs * $ProtocolListSIGNALduino{$id}{zero}[$ProtocolListSIGNALduino{$id}{clockpos}[1]];
                    if (!SIGNALduino_inTol($ProtocListClock,$msgclock,$msgclock*0.30)) {
                        Log3 $name, 5, "$name: for MU Protocol id $id, protocClock=$ProtocListClock, msgClock=$msgclock (zero) is not in tol=" . $msgclock*0.30;
                        next;
                    }
                }

[Ralf9]

Zur Verdeutlichung hier noch ein Beispiel: Mit dieser MU-Nachricht mit der ID 79 MU;P0=656;P1=-656;P2=335;P3=-326;P4=-5024;D=01230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303012423012301212301230303030124230123012123012303030301242301230121230123030303;CP=2;O; wird beim parse_MU ohne whitelist durch die clock abfrage bei der ID 8 und 31 eine unnötige demodulation verhindert. Bei der ID 8 wären es bei der demodulation 36 restarting Versuche und bei der ID 31 wären es 8 restarting Versuche.

Wenn man sich die restarting Versuche der einzeln IDs anschaut mach es Sinn die restarting Versuche zu begrenzen. ID 8 -> 36 restartings ID 60 -> 17 restartings ID 61 -> 36 restartings ID 70 -> 26 restartings ID 73 -> 26 restartings ID 74 -> 26 restartings ID 80 -> 36 restartings

[HomeAutoUser]

@sidey79 + @Ralf9

Ich weiß nun nicht ob es das richtige Thema ist wo dies genau hinzu passt. Derzeit haben wir bei @sidey79 in der DEV-r33 einen anderen Stand als bei @Ralf9 im Master. Jeder von Euch denkt sich seinen Teil dabei. Nun habe ich mir mal die Mühe gemacht beide Versionen hin und her zu testen. Da beide Versionen eine selbige Definition der Protokolle nutzt so habe ich mal diesen MU Befehl zum Dispatchen genommen aus dem Protokoll 5.

MU;P0=-563;P1=479;P2=991;P3=-423;P4=361;P5=-1053;P6=3008;P7=-7110;D=2345454523452323454523452323452323452323454545456720151515201520201515201520201520201520201515151567201515152015202015152015202015202015202015151515672015151520152020151520152020152020152020151515156720151515201520201515201520201520201520201515151;CP=1;R=21;

Dabei fällt mir auf, das trotz der selben Definition die Verarbeitung bei @Ralf9 funktioniert und bei @sidey79 nicht. Bei @Ralf9 legt es mir einen neues Device an.

Liegt es an den Anpassungen von @Ralf9 ? Es wäre schön, wenn wir dort einen Nenner finden, da sonst die "Fehlersuche" später immer schwieriger wird.

@sidey79 Was spricht gegen @Ralf9 seine Anpassungen oder worin siehst du noch Verbesserungen?

[Ralf9]

Dies ist eine spezielle Nachricht von Caleus, ich weiß nicht wie es entstehen kann. Vor dem start 67 haben one und zero andere Werte D=234545452345232345452345232345232345232345454545 als nach dem start 20151515201520201515201520201520201520201515151567201515152015

Ich suche zuerst die Postition vom Start und schneide dann den Teil vor dem Start ab, dann habe ich die richtigen Werte für one und zero

Nachtrag: alle Nachrichten, die ich mir von diesem Sensor angeschaut habe, sehen so seltsam aus.

[HomeAutoUser]

@Ralf9 verstehe ich.

Wie kann es dann dazu kommen das bei dir und der von @sidey79 Variante andere HEX-Werte zustande kommen? Ich greife da gern wieder das "unbeaknnte 49er Protokoll" auf.

MU;P0=-563;P1=479;P2=991;P3=-423;P4=361;P5=-1053;P6=3008;P7=-7110;D=2345454523452323454523452323452323452323454545456720151515201520201515201520201520201520201515151567201515152015202015152015202015202015202015151515672015151520152020151520152020152020152020151515156720151515201520201515201520201520201520201515151;CP=1;R=21;

U49#165B60	Sidey
U49#8B2DB0	Ralf

[Ralf9]

dies ist genau dieser von mir o.g. Fall vom Quigg_gt9000 vom user Caleus Siehe hier ganz oben die erste Nachricht.

[HomeAutoUser]

ok, dann sollten wir überlegen was besser ist, da sich das Ganze dann auch auf andere Protokolle niederschlägt wo Ihr beiden die SELBEN Definitionen habt.

Vergleich hier: u.a. Prot 49 / 63 - wieso die 27 trotz gleicher Definition bei Dir geht keine Ahnung ...

@Ralf9

2018.09.23 13:16:13 3: nano_433Mhz/init: enable receiver (XE)
2018.09.23 13:16:23 4: sduino_dummy/msg get raw: MU;P0=-563;P1=479;P2=991;P3=-423;P4=361;P5=-1053;P6=3008;P7=-7110;D=2345454523452323454523452323452323452323454545456720151515201520201515201520201520201520201515151567201515152015202015152015202015202015202015151515672015151520152020151520152020152020152020151515156720151515201520201515201520201520201520201515151;CP=1;R=21;
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 5 dmsg i8B2DB0 length 24 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy IT: message "i8B2DB0" (7)
2018.09.23 13:16:23 4: sduino_dummy IT: msgcode "" (0) bin = 100010110010110110110000
2018.09.23 13:16:23 4: sduino_dummy IT: 1527x8b2db not defined (Switch code: 0000)
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 5 dmsg i8B2DB0 length 24 repeat 1 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: i8B2DB0, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 5 dmsg i8B2DB0 length 24 repeat 2 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: i8B2DB0, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 27 dmsg u27#74D24F length 24 RSSI = -63.5
2018.09.23 13:16:23 4: SIGNALduino_unknown incomming msg: u27#74D24F
2018.09.23 13:16:23 4: SIGNALduino_unknown rawData: 74D24F
2018.09.23 13:16:23 4: SIGNALduino_unknown Protocol: 27
2018.09.23 13:16:23 4: SIGNALduino_unknown converted to bits: 011101001101001001001111
2018.09.23 13:16:23 3: SIGNALduino_unknown sduino_dummy Protocol:27 | To help decode or debug, please add u27! (attr sduino_dummy development m29,m30,y73,y73.1,y74,m81,m83,u27)
2018.09.23 13:16:23 4: Unknown, please report
2018.09.23 13:16:23 3: sduino_dummy: Unknown code u27#74D24F, help me!
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 27 dmsg u27#74D24F length 24 repeat 1 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: u27#74D24F, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 27 dmsg u27#74D24F length 24 repeat 2 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: u27#74D24F, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 49 dmsg U49#8B2DB0 length 24 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 49 dmsg U49#8B2DB0 length 24 repeat 1 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: U49#8B2DB0, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 49 dmsg U49#8B2DB0 length 24 repeat 2 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: U49#8B2DB0, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 49 dmsg U49#8B2DB0 length 24 repeat 3 RSSI = -63.5
2018.09.23 13:16:23 4: sduino_dummy Dispatch: U49#8B2DB0, Dropped due to short time or equal msg
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 60 -> WS2000 matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: Fingerprint for MU Protocol id 63 -> Warema matches, trying to demodulate
2018.09.23 13:16:23 4: sduino_dummy: decoded matched MU Protocol id 63 dmsg u637FE000000000000000000000000 length 108 RSSI = -63.5
2018.09.23 13:16:24 3: sduino_dummy: Unknown code u637FE000000000000000000000000, help me!
2018.09.23 13:16:24 4: sduino_dummy: Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2018.09.23 13:16:24 4: sduino_dummy: Fingerprint for MU Protocol id 75 -> ConradRSL2 matches, trying to demodulate

@Sidey79

> 2018.09.23 13:14:56 4: sduino_dummy/msg get raw: MU;P0=-563;P1=479;P2=991;P3=-423;P4=361;P5=-1053;P6=3008;P7=-7110;D=2345454523452323454523452323452323452323454545456720151515201520201515201520201520201520201515151567201515152015202015152015202015202015202015151515672015151520152020151520152020152020152020151515156720151515201520201515201520201520201520201515151;CP=1;R=21;
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: decoded matched MU Protocol id 5 dmsg i8B2DB0 length 24 RSSI = -63.5
> 2018.09.23 13:14:56 4: sduino_dummy IT: message "i8B2DB0" (7)
> 2018.09.23 13:14:56 4: sduino_dummy IT: msgcode "" (0) bin = 100010110010110110110000
> 2018.09.23 13:14:56 4: sduino_dummy IT: 1527x8b2db not defined (Switch code: 0000)
> 2018.09.23 13:14:56 1: PERL WARNING: Argument "300;FS10" isn't numeric in subtraction (-) at ./FHEM/98_autocreate.pm line 167.
> 2018.09.23 13:14:56 4: sduino_dummy: decoded matched MU Protocol id 5 dmsg i8B2DB0 length 24 RSSI = -63.5
> 2018.09.23 13:14:56 4: sduino_dummy Dispatch: i8B2DB0, Dropped due to short time or equal msg
> 2018.09.23 13:14:56 4: sduino_dummy: decoded matched MU Protocol id 5 dmsg i8B2DB0 length 24 RSSI = -63.5
> 2018.09.23 13:14:56 4: sduino_dummy Dispatch: i8B2DB0, Dropped due to short time or equal msg
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 30 -> diverse matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: decoded matched MU Protocol id 49 dmsg U49#165B60 length 24 RSSI = -63.5
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 59 -> AK-HD-4 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 60 -> WS2000 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 75 -> ConradRSL2 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 81 -> SA-434-1 matches, trying to demodulate
> 2018.09.23 13:14:56 4: sduino_dummy: Fingerprint for MU Protocol id 83 -> RH787T matches, trying to demodulate
> 2018.09.23 13:15:46 0: Server shutdown

[sidey79]

Also grundsätzlich die Werte für 0 und 1 erst für den Bereich nach start vornehmen erscheint mir eine gute Option.

Das Zuordnen der Pulse zu 0 und 1 erfolgt durch die Ermittlung der Abweichung Der Ideale Wert wird mit clock * angegebenen Faktor ermittelt.

Dann wird durch einfache substraktion der Wert ermittelt der den geringsten Wert hat. Wenn es die Sequenz dann auch noch in der ermittelten Form gibt, wird es für die weitere Verarbeitung übernommen.

Grüße Sidey

[sidey79]

@homeautouser

Du wolltest wissen, was gegen die Anpassung von Ralf spricht.

Eigentlich nichts konkretes außer ein ungutes Gefühl. Wenn ich jetzt nichts verwechsle, dann hat Ralf die parse_MU sehr stark modifiziert.

Bislang habe ich das nicht verstanden, wieso derart viel verändert werden musste. Um nur diesen genannten Fall abzudecken glaube ich, dass weniger Anpassungen ausreichen. Ob mit der angepassten Variante von Ralf noch alles funktioniert konnte bislang nicht geprüft werden.

[Ralf9]

Es ist wahrscheinlich am Besten, wenn ich erstmal beschreibe, was ich alles geändert habe und wie ich mir das Parse_MU vorstelle. Mir ist einiges aufgefallen, was optimiert werden kann. Bei einigen Sachen werde ich eure Hilfe benötigen

Macht es Sinn dafür einen neuen branch "dev-r33_modified_Parse_MU" zu erstellen und dann den branch "dev-r33_new_Parse_MU" zu löschen? In dem "dev-r33_new_Parse_MU" sind einige commits drin, die da nicht reingehören.

[sidey79]

Ja, das klingt gut.

Hängen die Änderungen alle zusammen oder sind da welche unabhängig von anderen?

Vielleicht können wir ja auch gleich einen oder zwei Tests für die Anpassungen schreiben :)

[Ralf9]

Teil 1, prüfen ob die im Protokoll definierten Werte in der Nachricht enthalten und in der Toleranz sind

Am Anfang direkt nach der filterfunc

wird geprüft ob in clockpos ein String ungleich one oder zero (z.B. cp) enthalten ist. Dann wird geprüft ob die in CP ausgegebene clock in der Toleranz ist.

        $msgclock = $msg_parts{pattern}{$msg_parts{clockidx}};
        if (!SIGNALduino_inTol($clockabs,$msgclock,$msgclock*0.30)) {
            next;
        }

Nun wird geprüft ob start im Protokoll definiert ist und ggf start in der patternList gesucht. Wenn nicht gefunden -> next Wenn start gefunden, dann wird alles vor start abgeschnitten.

Testen ob one in der patternList ist next if (($pstr=SIGNALduino_PatternExists($hash,\@{$ProtocolListSIGNALduino{$id}{one}},\%patternList,\$rawData)) eq -1); Wenn in clockpos one steht, dann wird getestet ob die im one Array enthaltene Clock in der Toleranz ist.

Testen ob zero im Protokoll definiert ist und in der patternList enthalten ist. Wenn in clockpos zero steht, dann wird getestet ob die im zero Array enthaltene Clock in der Toleranz ist.

Testen ob float im Protokoll definiert ist und in der patternList enthalten ist.

Zusammenfügen der signal_regex und der start_regex

            if (length ($startStr) > 0 ) {
                $start_regex = '^' . $signal_regex;
            } else {
                $start_regex = $signal_regex;
            }

Testen ob die start_regex in der rawData enthalten ist

[Ralf9]

Teil 2, demodulation

Es gibt ein neues Attribut maxMuMsgRepeat, damit wird die Anzahl der Wiederholungen begrenzt last if ($repeat > AttrVal($name,"maxMuMsgRepeat", 4));

Da es bei Nachrichten der ID 79 vorkommen kann, das es über 35 restarts der demodulation gibt, macht es Sinn die restarts bis zum ersten dispatch zu begrenzen, z.B. auf 10. Bei den Wiederholungen evtl eine Begrenzung auf 3 restarts pro Wiederholung

[sidey79]

Teil 1, prüfen ob die im Protokoll definierten Werte in der Nachricht enthalten und in der Toleranz sind

Am Anfang direkt nach der filterfunc

wird geprüft ob in clockpos ein String ungleich one oder zero (z.B. cp) enthalten ist. Dann wird geprüft ob die in CP ausgegebene clock in der Toleranz ist.

Irgendwie finde ich es nicht. Ein Hinweis auf die Zeile hilft mir da sicherlich: https://github.com/RFD-FHEM/RFFHEM/pull/245/files#diff-ffd75143a13a45dd2a5a1184d993cbfd

[Ralf9]

das Prüfen ob die clock in der Toleranz ist und die optimierung von valid ist neu und habe ich noch nicht commitet.

Wenn hier beim Testen der pattern auf one und zero -1 ergibt $valid = $valid && ($pstr=SIGNALduino_PatternExists( dann kann gleich mit next if (($pstr=SIGNALduino_PatternExists(...) eq -1 abgebrochen werden

wenn es so ok ist, dann werde ich das restliche nach dev-r33_new_Parse_MU commiten

[sidey79]

Ich habe Schwierigkeiten die aktuell committeten Änderungen zu verstehen.

Kann mir da jemand helfen?

[Ralf9]

wo hast Du Probleme, im Teil 1 oder im Teil 2 bei der demodulation

[sidey79]

Hier hat sich schon lange nichts mehr getan. Ich schließe das Issue. Bitte wieder öffnen, wenn es noch benötigt wird.