search

RFD-FHEM / RFFHEM

Counterpart of SIGNALDuino, it's the code for FHEM to work with the data received from the uC
GNU General Public License v3.0
44 stars 33 forks source link

Missing Log output for development state m protocol #375

Closed sidey79 closed 5 years ago

sidey79 commented 5 years ago

Expected Behavior

with development=m34 the output should be :

2018.11.19 19:12:56.988 5 : sduinoD: dispatch P34#9E4EE
2018.11.19 19:12:56.991 4 : sduinoD: SD_UT protocol 34, bitData 10011110010011101110
2018.11.19 19:12:56.991 1 : sduinoD: SD_UT_Parse UNDEFINED sensor unknown detected, code 9E
2018.11.19 19:12:56.997 2 : autocreate: define unknown SD_UT unknown

2018.11.19 19:19:17.412 4 : sduinoD: decoded matched MU Protocol id 34 dmsg P34#9E4EE length 20 RSSI = -75
2018.11.19 19:19:17.412 5 : sduinoD: dispatch P34#9E4EE
2018.11.19 19:19:17.437 4 : sduinoD: SD_UT protocol 34, bitData 10011110010011101110
2018.11.19 19:19:17.437 3 : sduinoD: SD_UT Please define your model of Device unknown in Attributes!

Actual Behavior

2018.11.22 21:47:02.698 5: dummyDuino: start pattern for MU Protocol id 85 -> TFA 35.1140.01 not found, aborting
2018.11.22 21:47:02.693 5: dummyDuino: start pattern for MU Protocol id 84 -> IAN283582 not found, aborting
2018.11.22 21:47:02.687 5: dummyDuino: start pattern for MU Protocol id 81 -> SA-434-1 not found, aborting
2018.11.22 21:47:02.684 5: dummyDuino: 0. try, regex ((?:)((?:12|12){104,})) did not match
2018.11.22 21:47:02.682 4: dummyDuino: Fingerprint for MU Protocol id 80 -> EM (Energy-Monitor) matches, trying to demodulate
2018.11.22 21:47:02.677 5: dummyDuino: start pattern for MU Protocol id 79 -> m-e VTX-BELL not found, aborting
2018.11.22 21:47:02.673 5: dummyDuino: 0. try, regex ((?:)((?:32|14){32,})) did not match
2018.11.22 21:47:02.671 4: dummyDuino: Fingerprint for MU Protocol id 75 -> ConradRSL2 matches, trying to demodulate
2018.11.22 21:47:02.666 5: dummyDuino: 0. try, regex ((?:)((?:12|12){50,})) did not match
2018.11.22 21:47:02.663 4: dummyDuino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.11.22 21:47:02.658 5: dummyDuino: start pattern for MU Protocol id 72 -> Siro shutter not found, aborting
2018.11.22 21:47:02.655 5: dummyDuino: 0. try, regex ((?:)((?:12|34){48,})) did not match
2018.11.22 21:47:02.653 4: dummyDuino: Fingerprint for MU Protocol id 71 -> PV-8644 matches, trying to demodulate
2018.11.22 21:47:02.647 5: dummyDuino: 0. try, regex ((?:)((?:12|12){50,})) did not match
2018.11.22 21:47:02.645 4: dummyDuino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.11.22 21:47:02.640 5: dummyDuino: start pattern for MU Protocol id 69 -> Hoermann not found, aborting
2018.11.22 21:47:02.637 5: dummyDuino: one pattern for MU Protocol id 67 not found, aborting
2018.11.22 21:47:02.633 5: dummyDuino: start pattern for MU Protocol id 66 -> WS7035 not found, aborting
2018.11.22 21:47:02.630 5: dummyDuino: 0. try, regex ((?:)((?:12|32){48,})) did not match
2018.11.22 21:47:02.628 4: dummyDuino: Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2018.11.22 21:47:02.622 5: dummyDuino: start pattern for MU Protocol id 62 -> Clarus_Switch not found, aborting
2018.11.22 21:47:02.619 5: dummyDuino: 0. try, regex ((?:)((?:12|12){38,})) did not match
2018.11.22 21:47:02.616 4: dummyDuino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.11.22 21:47:02.612 5: dummyDuino: one pattern for MU Protocol id 60 not found, aborting
2018.11.22 21:47:02.608 5: dummyDuino: start pattern for MU Protocol id 59 -> AK-HD-4 not found, aborting
2018.11.22 21:47:02.605 5: dummyDuino: start pattern for MU Protocol id 56 -> Celexon not found, aborting
2018.11.22 21:47:02.602 5: dummyDuino: 0. try, regex ((?:)((?:14|34){47,})) did not match
2018.11.22 21:47:02.599 4: dummyDuino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2018.11.22 21:47:02.594 5: dummyDuino: start pattern for MU Protocol id 49 -> QUIGG_GT-9000 not found, aborting
2018.11.22 21:47:02.591 5: dummyDuino: one pattern for MU Protocol id 48 not found, aborting
2018.11.22 21:47:02.586 5: dummyDuino: one pattern for MU Protocol id 46 not found, aborting
2018.11.22 21:47:02.583 5: dummyDuino: start pattern for MU Protocol id 45 -> Revolt not found, aborting
2018.11.22 21:47:02.580 5: dummyDuino: start pattern for MU Protocol id 44.1 -> BresserTemeo not found, aborting
2018.11.22 21:47:02.577 5: dummyDuino: start pattern for MU Protocol id 44 -> BresserTemeo not found, aborting
2018.11.22 21:47:02.574 5: dummyDuino: start pattern for MU Protocol id 40 -> romotec not found, aborting
2018.11.22 21:47:02.571 5: dummyDuino: start pattern for MU Protocol id 39 -> X10 Protocol not found, aborting
2018.11.22 21:47:02.566 5: dummyDuino: for MU Protocol id 39, applying filterfunc SIGNALduino_compPattern
2018.11.22 21:47:02.564 5: dummyDuino: start pattern for MU Protocol id 37 -> Bresser 7009994 not found, aborting
2018.11.22 21:47:02.560 5: dummyDuino: start pattern for MU Protocol id 36 -> socket36 not found, aborting
2018.11.22 21:47:02.557 5: dummyDuino: start pattern for MU Protocol id 32 -> freetec 6946 not found, aborting
2018.11.22 21:47:02.554 5: dummyDuino: start pattern for MU Protocol id 31 -> Pollin Isotronik not found, aborting
2018.11.22 21:47:02.548 5: dummyDuino: start pattern for MU Protocol id 29 -> HT12e remote not found, aborting
2018.11.22 21:47:02.545 5: dummyDuino: start pattern for MU Protocol id 28 -> IC Ledspot not found, aborting
2018.11.22 21:47:02.542 5: dummyDuino: start pattern for MU Protocol id 27 -> remote27 not found, aborting
2018.11.22 21:47:02.539 5: dummyDuino: start pattern for MU Protocol id 26 -> remote26 not found, aborting
2018.11.22 21:47:02.535 5: dummyDuino: start pattern for MU Protocol id 24 -> visivon remote not found, aborting
2018.11.22 21:47:02.532 5: dummyDuino: start pattern for MU Protocol id 21 -> Einhell Garagedoor not found, aborting
2018.11.22 21:47:02.529 5: dummyDuino: one pattern for MU Protocol id 20 not found, aborting
2018.11.22 21:47:02.522 5: dummyDuino: for MU Protocol id 20, applying filterfunc SIGNALduino_filterSign
2018.11.22 21:47:02.520 5: dummyDuino: one pattern for MU Protocol id 19 not found, aborting
2018.11.22 21:47:02.517 5: dummyDuino: one pattern for MU Protocol id 17.1 not found, aborting
2018.11.22 21:47:02.513 5: dummyDuino: start pattern for MU Protocol id 16 -> Dooya shutter not found, aborting
2018.11.22 21:47:02.510 5: dummyDuino: start pattern for MU Protocol id 13.1 -> FLAMINGO FA22RF / FA21RF / LM-101LD not found, aborting
2018.11.22 21:47:02.507 5: dummyDuino: 0. try, regex ((?:)((?:12|32){60,})) did not match
2018.11.22 21:47:02.505 4: dummyDuino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.11.22 21:47:02.499 5: dummyDuino: 0. try, regex ((?:)((?:12|32){43,})) did not match
2018.11.22 21:47:02.496 4: dummyDuino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.11.22 21:47:02.491 5: dummyDuino: 0. try, regex ((?:)((?:32|14){24,})) did not match
2018.11.22 21:47:02.488 4: dummyDuino: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2018.11.22 21:47:02.479 4: dummyDuino/msg get raw: MU;P0=-9840;P1=593;P2=-660;P3=1230;P4=-1312;D=012341412323232341412341412323234123232341;CP=1;R=254;

Steps to Reproduce the Problem

  1. set raw MU;P0=-9840;P1=593;P2=-660;P3=1230;P4=-1312;D=012341412323232341412341412323234123232341;CP=1;R=254;

Specifications

Reported here: https://github.com/RFD-FHEM/RFFHEM/issues/195#issuecomment-439982029

HomeAutoUser commented 5 years ago

Sobald ich wieder daheim bin, werde ich es nachvollziehen. Ich denke zu wissen was du meinst ;)

sidey79 commented 5 years ago

okay, Ralf9 hatte es berichtet. Ich hab noch nicht geschaut, woran es liegt

Ralf9 commented 5 years ago

Actual Behavior 5: dummyDuino: start pattern for MU Protocol id 36 -> socket36 not found, aborting 5: dummyDuino: start pattern for MU Protocol id 32 -> freetec 6946 not found, aborting

Wenn die id 34 nicht in der muIdList enthalten ist, kann die id 34 auch nicht im log erscheinen. Dieses Verhalten wurde von @HomeAutoUser mit diesem commit eingebaut https://github.com/RFD-FHEM/RFFHEM/commit/315e698bce43da338ba09321ca25621afdf0ff50 Damit werden beim Erzeugen der muIdList auch die Ids mit der developId=m übersprungen. Mir ist nicht klar zu was dies gut sein soll, daß beim Erzeugen der IdList auch die developId=m berücksichtigt werden.

HomeAutoUser commented 5 years ago

Es ist schon eine Weile her. Die Änderung war m.e. weil bei der Ausgabe was nicht passte. Vielleicht kann sich @elektron-bbs noch erinnern. Wir hatten da zusammen drüber geschaut. Ich werde dem Sachverhalt erst am So. Abend ansehen können. Vom Handy ist es immer sehr schwierig aus es zu simulieren.

HomeAutoUser commented 5 years ago

Wenn die id 34 nicht in der muIdList enthalten ist, kann die id 34 auch nicht im log erscheinen. Dieses Verhalten wurde von @HomeAutoUser mit diesem commit eingebaut 315e698 Damit werden beim Erzeugen der muIdList auch die Ids mit der developId=m übersprungen. Mir ist nicht klar zu was dies gut sein soll, daß beim Erzeugen der IdList auch die developId=m berücksichtigt werden.

Ich habe soeben noch einmal geschaut, das der o.g. commit schuld daran sein sollte bezweifle ich. Ich habe mir die Mühe gemacht und den Abschnitt auskommentiert und da erfolgt auch keine Ausgabe bzw. Verarbeitung der ID mit m.

Der Commit war allein dafür da, das die Zeilen

2018.11.26 16:13:19 3: sduino_dummy: ID=m72.1 skipped (developId=m) 2018.11.26 16:13:19 3: sduino_dummy: ID=m34 skipped (developId=m) 2018.11.26 16:13:19 3: sduino_dummy: ID=m82 skipped (developId=m)

zusammengefasst werden

2018.11.26 16:13:19 3: sduino_dummy: IDlist development skipped = m34 m72.1 m82 p76 p76.1 y63 y75 y77 y78

Diese Ausgabe erfolgt ja jeweils nur beim RESTART und nicht beim Dispatchen.

sidey79 commented 5 years ago

Eigentlich ist doch egal durch wen und was es verursacht wurde. Wir sollten es einfach beheben :)

HomeAutoUser commented 5 years ago

Richtig :) Ich muss mir noch einen Überblick verschaffen wie alles abläuft um dahinter zu kommen. Die genannte Stelle ist es nicht.

Ralf9 commented 5 years ago

Der Fehler lässt sich doch recht einfach eingrenzen, einfach die genannte Stelle entfernen und aus dem Attribut development die "m" entfernen, dann müssen die IDs, die ein developid m haben, immernoch in der muIdList, msIdList und mcIdList sein. Wenn es dann trotzdem noch nicht funktioniert,dann ist noch ein zweiter Fehler.

#       if (defined($ProtocolListSIGNALduino{$id}{developId}) && substr($ProtocolListSIGNALduino{$id}{developId},0,1) eq "m") {
#           my $devid = "m$id";
#           if ($develop !~ m/$devid/) {        # skip wenn die Id nicht im Attribut development steht
#               #SIGNALduino_Log3 $name, 3, "$name: ID=$devid skiped (developId=m)";
#               push (@skipedId, $devid);
#               next;
#           }
#       }
elektron-bbs commented 5 years ago

Irgendwie stehe ich auf dem Schlauch...

Der Fehler lässt sich doch recht einfach eingrenzen, einfach die genannte Stelle entfernen und aus dem Attribut development die "m" entfernen, dann müssen die IDs, die ein developid m haben, immernoch in der muIdList sein.

Ich denke, Protokolle, die ein "m" oder "y" haben, sollen normalerweise NICHT berücksichtigt werden, oder? Dann brauchen sie auch nicht in der Liste stehen. Statt dessen erscheinen sie in der Liste "skipped". Oder willst du in der Liste immer alle Protokolle sehen?

Ralf9 commented 5 years ago

Wie soll in den ParseMS, MU und MC Routinen dies hier geprüft werden, wenn die Protokolle die ein "m" haben, geskipped werden und deshalb gar nicht in muIdList, msIdList oder mcIdList stehen?

        my $developATTR = AttrVal($name,"development","");
        my $developID = SIGNALduino_getProtoProp($id,"developId","");
        if ($developID eq "m") {
            if ( length($developATTR) > 0 && $developATTR =~ m/$developID$id/) { 
                return 1; #   return 1 da modulematch gefunden wurde            
            }
            SIGNALduino_Log3 $name, 3, "$name: ID=id skipped dispatch (developId=$developID). To use, please add $developID$id to the attr development";    
            return -1;
}
HomeAutoUser commented 5 years ago

Ich habe nun den Test gemacht

        # if (defined($ProtocolListSIGNALduino{$id}{developId}) && substr($ProtocolListSIGNALduino{$id}{developId},0,1) eq "m") {
            # my $devid = "m$id";
            # if ($develop !~ m/$devid/) {      # skip wenn die Id nicht im Attribut development steht
                # #SIGNALduino_Log3 $name, 3, "$name: ID=$devid skipped (developId=m)";
                # push (@skippedId, $devid);
                # next;
            # }
        # }

bringt auch keine Ausgabe. Der Fehler liegt nicht dort wo du ihn vermutest @Ralf9.

Ich habe mir hier mal eine Ausgabe hinzugefügt

    if (!defined($modMatchRegex) || $dmsg =~ m/$modMatchRegex/) {
        Debug "$name: modmatch passed for: $dmsg" if ($debug);
        my $developATTR = AttrVal($name,"development","");
        my $developID = SIGNALduino_getProtoProp($id,"developId","");
        SIGNALduino_Log3 $name, 3, "$name: TESTAUSGABE $developID"; 
        if ($developID eq "m") {
            if ( length($developATTR) > 0 && $developATTR =~ m/$developID$id/) { 
                return 1; #   return 1 da modulematch gefunden wurde            
            }
            SIGNALduino_Log3 $name, 3, "$name: ID=id skipped dispatch (developId=$developID). To use, please add $developID$id to the attr development";    
            return -1;
        }
        return 1;
    }
    return 0;

da kommt immer nur "nichts" oder "y" KEIN "m" bisher.

Ralf9 commented 5 years ago

Es kann hier oder woanderst auch noch ein zweiter Fehler sein, das habe ich nicht geprüft

        my $developATTR = AttrVal($name,"development","");
        my $developID = SIGNALduino_getProtoProp($id,"developId","");
        if ($developID eq "m") {
            if ( length($developATTR) > 0 && $developATTR =~ m/$developID$id/) { 
                return 1; #   return 1 da modulematch gefunden wurde            
            }
            SIGNALduino_Log3 $name, 3, "$name: ID=id skipped dispatch (developId=$developID). To use, please add $developID$id to the attr development";    
            return -1;
HomeAutoUser commented 5 years ago

Ich habe es nun mal weiter eingegrenzt.

    if (!defined($modMatchRegex) || $dmsg =~ m/$modMatchRegex/) {
        Debug "$name: modmatch passed for: $dmsg" if ($debug);
        my $developATTR = AttrVal($name,"development","");
        SIGNALduino_Log3 $name, 3, "$name: TESTAUSGABE ID=$id"; ### TEST
        my $developID = SIGNALduino_getProtoProp($id,"developId","");
        SIGNALduino_Log3 $name, 3, "$name: TESTAUSGABE developId=$developID"; ### TEST
        if ($developID eq "m") {
            if ( length($developATTR) > 0 && $developATTR =~ m/$developID$id/) { 
                return 1; #   return 1 da modulematch gefunden wurde            
            }
            SIGNALduino_Log3 $name, 3, "$name: ID=id skipped dispatch (developId=$developID). To use, please add $developID$id to the attr development";    
            return -1;
        }
        return 1;
    }

Hier ist in KEINEM Falle ein m oder y drin. ERST wenn ich in das Attribut development m34 oder y72 ... eintrage im Emfpnänger erhalte ich dort in der Variabte ein m oder y. Schlussfolgerung, der Fehler liegt "vorher irgendwo"

HomeAutoUser commented 5 years ago

In der 

sub SIGNALduino_Parse_MU($$$$@)
{
....

innerhalb der Schleife

foreach $id (@{$hash->{muIdList}}) {

ist es auch nicht vertreten.

HomeAutoUser commented 5 years ago

Das Problem ist, das die ID nicht in der muIdList enthalten ist, 

sub SIGNALduino_IdList($@)
{ ...
foreach $id (keys %ProtocolListSIGNALduino

sobald ich diese bei der Option m

        if (defined($ProtocolListSIGNALduino{$id}{developId}) && substr($ProtocolListSIGNALduino{$id}{developId},0,1) eq "m") {
            my $devid = "m$id";
            if ($develop !~ m/$devid/) {        # skip wenn die Id nicht im Attribut development steht
                #SIGNALduino_Log3 $name, 3, "$name: ID=$devid skipped (developId=m)";
                push (@skippedId, $devid);
                push (@muIdList, $id);
                next;
            }
        }

hinzunehme geht es. Da dachte ich mir, weil der Fehler auch bei y ist, diese Zeile dort hinzuzufügen aber dann hat sich ein anderes Verhalten aufgetan. Dann erhalte ich auf einmal Nachricht dispatched welche auf y steht aber ich NICHT in dem Attribut develoment drin stehen habe.

Nachtrag: Zusammenfassung muIdList, das ist die Liste aller MU Protokolle und da müsste die 34 ja hinzu weil das Modul erarbeitet wird im m-Status, richtig?

Nachtrag2: SOBALD man hier if (defined($ProtocolListSIGNALduino{$id}{developId}) && substr($ProtocolListSIGNALduino{$id}{developId},0,1) eq "y") {

die Zeile

push (@muIdList, $id);

hizufügt, so wird SOFORT ein Dispatch durchgeführt auch wenn KEIN ATTRIBUT gesetzt ist. Ich denke hier ist ein weiterer Fehler. Das kann aber nur @sidey79 oder und @Ralf9 einschätzen wie es gedacht ist richtig.

HomeAutoUser commented 5 years ago

Hier wäre mein Commit https://github.com/HomeAutoUser/RFFHEM/commit/faaf987befe084fcc8fe1b4e332938e6070e139f für den "m-Bug". Es bleibt aber das mit dem p offen.

sidey79 commented 5 years ago

Habe ich schon mal erwähnt, dass ich dieses Verhalten von development Attribut, developID und den möglichen Werten y, m, p total verwirrend finde?

Die Bezeichner sind auch nicht alle Protokoll Spezifisch gedacht gewesen, soweit ich das mal verstanden habe.

Ralf9 commented 5 years ago

Die whitelist_IDs haben nun vorrang vor der developId option. Z.B. wenn in der whitelist_IDs 78 steht, dann wird diese ID auch verwendet, wenn im attr development nichts steht. Wenn im development Attribut "y" enthalten ist, dann werden alle Protokolle mit developId => 'y' verwendet. Wenn im development Attribut "p" gefolgt von der ID eingetragen wird, dann wird nur diese developId verwendet.

Mit z.B. attr development p63p76 werden die developId 63 und 76 verwendet.

Wenn dieses Verhalten so ok ist, dann kann ich dazu einen pullrequest machen

sidey79 commented 5 years ago

Wieso brauchen wir überhaupt unterschiedliche Stufen? Reicht es nicht einfach die ID in das development Attribut zu schreiben und gut ist? Damit wäre es eine einfache an/aus Geschichte.

Was ist denn der Anwendungsfall, der vielen Optionen?

HomeAutoUser commented 5 years ago

Der jetzige definierte Anwendungsfall wäre ja das

# developId   => 'm'       # logical module is under development
# developId   => 'p'       # protocol is under development or to reserve IDs, the ID in the development attribute with developId => 'p' are only used without the other entries
# developId   => 'y'       # protocol is under development, all IDs in the development attribute with developId => 'y' are used

Das man nur einen an/aus Schalter hätte mit Entwickler/nicht Entwickler würde den vielen Varianten natürlich entgegen kommen um Verwirrung zu sparen. (natürlich auch Code)

Ich für meine bisherigen Zwecke habe nur die developId => 'y' und max developId => 'm' in Benutzung was auch auf eines geschrumpft werden könnte.

Die whitelist_IDs haben nun vorrang vor der developId option. Z.B. wenn in der whitelist_IDs 78 steht, dann wird diese ID auch verwendet, wenn im attr development nichts steht. Wenn im development Attribut "y" enthalten ist, dann werden alle Protokolle mit developId => 'y' verwendet. Wenn im development Attribut "p" gefolgt von der ID eingetragen wird, dann wird nur diese developId verwendet. Mit z.B. attr development p63p76 werden die developId 63 und 76 verwendet.

@Ralf9 sehe ich das richtig, das letztendlich nur 2 varianten zum tragen kommen? y und p? Das m hast du weggenommen?

Ralf9 commented 5 years ago

Das m bleibt (logical module is under development)

sidey79 commented 5 years ago

Mit Anwendungsfall meinte ich, wann setzt ein Anwender m, p oder y?

In der Regel sollte es einem Anwender doch egal sein in welchem Zustand das Protokoll ist. Es macht für ihn doch keinen Unterschied ob da ein logisches Modul entwickelt wurde oder nicht .

In der Regel dürfte es doch so ablaufen, dass ein Entwickler ihm mitteilt, er soll das Attribut development pflegen. Dann wird so lange entwickelt bis das Attribut nicht mehr notwendig ist. Im Moment muss der Anwender das Attribut anpassen, sollte die Entwicklung voran schreiten.

elektron-bbs commented 5 years ago

Ich muss @sidey79 da zustimmen. Die drei Varianten wären höchstens für uns zur Info nötig. Das könnte man dann aber auch irgendwo in den Kommentar schreiben. Auf jeden Fall sollte aber eine einheitliche Syntax verwendet werden und nicht einmal "development p63p76" und dann wieder kommagetrennt bei whitelist, blacklist etc. Auch bei der Ausgabe der Listen tanzt eine aus der Reihe: 2018.11.25 17:47:25 3: sduino434: IDlist MS 1 3 3.1 4 6 7 13 13.2 14 15 17 22 23 33 35 38 42 55 65 68 2018.11.25 17:47:25 3: sduino434: IDlist MU 5 8 9 13.1 16 17.1 21 24 26 27 28 29 30 31 32 34 36 37 39 44 44.1 45 48 49 50 56 59 60 61 62 64 66 67 69 70 71 72 74 75 79 80 81 83 84 85 86 2018.11.25 17:47:25 3: sduino434: IDlist MC 10 11 12 18 43 47 52 57 58 2018.11.25 17:47:25 3: sduino434: IDlist development = m30,m34,m81,m83,m86,y83 2018.11.25 17:47:25 3: sduino434: IDlist development skipped = m2 m72.1 m82 p76 p76.1 y63 y73 y77 y78 2018.11.25 17:47:25 3: sduino434: IDlist blacklist = 0,19,20,25,40,41,46,51 Ich fände es gut, wenn bei "development y" alle Protokolle verarbeitet werden, die in Entwicklung sind, aber bei "development y12,y57" nur diese beiden Protokolle.

HomeAutoUser commented 5 years ago

Ich lese hier einen Zwischenweg heraus der mir auch persönlich sehr gefallen könnte.

Daraus nun eins "formen" :-) Wäre das für alle ein Übereinkommen?

elektron-bbs commented 5 years ago

Bei "development y12,y57" könnte man eigentlich auch noch das "y" weglassen und hat damit das gleiche Format wie bei "blacklist", "whitelist"...

Ralf9 commented 5 years ago

Mit Anwendungsfall meinte ich, wann setzt ein Anwender m, p oder y?

Der normale Anwender, der den sduino produktiv einsetzt, sollte eigentlich mit der whitelist arbeiten. Er trägt in die whitelist die IDs von den Sensoren ein, die er empfangen möchte. Bei develop Modulen muß er die mid (z.B. m82) in das attr development eintragen. Damit er erkennen kann, welche IDs develop Module sind, ist es sinnvoll, wenn wir bei allen IDs mit developId m beim comment (developModule) reinschreiben und am Ende der Liste von "get protocolIDs" z.B. folgendes reinschreiben: To use develop Module, please add m<id> (e.g. m82) to the attr development

Alternativ kann es der Anwender auch durch folgenden log Eintrag erkennen: ID=id skipped dispatch (developId=$developID). To use, please add $developID$id to the attr development

Wer keine whitelist verwendet, kann y in das attr development eintragen, falls er einige IDs nicht empfangen möchte, kann er diese in die Blacklist eintragen.

Die Möglichkeit mit p (z.B. p63p76) einzelne develop IDs auswählen zu können, sollte nur in ausnahmefällen notwendig sein.

Auf jeden Fall sollte aber eine einheitliche Syntax verwendet werden und nicht einmal "development p63p76" und dann wieder kommagetrennt bei whitelist, blacklist etc.

Beim attr development können beide Syntaxvarianten (mit- und ohne kommagetrennt) verwendet werden Z.B. "yp63p76m82" oder "y p63 p76 m82" oder "y,p63,p76,m82"

sidey79 commented 5 years ago

Ich kommentiere mal:

Ich lese hier einen Zwischenweg heraus der mir auch persönlich sehr gefallen könnte.

  • Variante von Ralf wo bei "development y" alle Protokolle verarbeitet werden

Das ist quasi wie bei anderen Attributen ein * im Sinne eines wildcard. Könnte man dann so auch umsetzen.

  • bei "development y12,y57" nur diese beiden Protokolle

Schließe mich dem Vorschlag von elektron-bbs an. Hier können wir doch den Bezeichner weglassen oder?

  • gleiche Parameter bei whitelist, blacklist etc.

Eine sehr gute Idee.

Bitte bewerten ob es so ausreichend ist:

Es wäre noch festzulegen, wie das Verhalten mit der Whitelist wäre. Muss es hier zusätzlich aufgenommen werden wenn eine definiert ist oder nicht.

HomeAutoUser commented 5 years ago

https://github.com/RFD-FHEM/RFFHEM/issues/242 2. Faden der damals schon die Unstimmigkeit an Bild brachte.

sidey79 commented 5 years ago

Wie vereinfachen wir denn jetzt den eigentlichen Anwendungsfall, dass wir unfertige Protokolle in der Protokoll Liste anbieten?

Ralf9 commented 5 years ago

So wies aussieht habt Ihr beim attr development ganz andere Vorstellungen wie ich, da ist es wahrscheinlich sinnvoller wenn sidey den pullrequest macht.

sidey79 commented 5 years ago

@Ralf9 Wenn Du die Anwendungsfälle mal aufschreibst, die Du so im Kopf hast. Ich kenne aktuell nur einen.

Ralf9 commented 5 years ago

Für wen wollen wir es hauptsächlich vereinfachen? Für den Anwender der den sduino produktiv einsetzt oder für die Entwickler?

sidey79 commented 5 years ago

In erster Linie würde ich sagen für den Anwender.

Für die Entwickler sollte es nicht unnötig komplex werden.

Ralf9 commented 5 years ago

Es gibt 2 Anwendungsfälle

Der normale Anwender, der den sduino produktiv einsetzt und die whitelist verwendet. Er trägt in die whitelist die IDs von den Sensoren ein, die er empfangen möchte. Bei develop Modulen muß er diem<id> (z.B. m82) in das attr development eintragen.

Anwender und Entwickler die ohne die whitelist arbeiten. Sie können entweder y in das attr development eintragen und falls sie einige IDs nicht empfangen möchten, können sie diese in die Blacklist eintragen. Sie können auch die developIDs einzeln auswählen indem sie die IDs in das attr development eintragen. Es sind dabei einige Varianten möglich, da per regex nur nach den IDs gesucht wird. z.B. p63p76p76.1m82u81 p63 p76 p76.1 m82 u81 p63,p76,p76.1,m82,u79,u81 oder auch nur die IDs 63 76 76.1 82 81 63,76,76.1,82,81

Zur developId m habe ich folgenden Vorschlag: Die developId m sollte in der Protokoldefinition stehen bis eine stabile Version vom verwendeten Modul im SVN ist. Dabei sollte es möglich sein neue Module auch einzeln ins SVN zu bringen

sidey79 commented 5 years ago

Du hast dich jetzt sehr auf die Umsetzung mittels development Attribut fokussiert. Ein Anwendungsfall, sollte man aus Sicht dessen beschreiben, der ihn anwendet. Dabei fokussiert man sich auf die Problemstellung und lässt sich Optionen für eine Lösung offen. Anwender sind hier wohl "Endanwender" und "Entwickler".

Wenn ich den 1. Fall weg von der Umsetzung definiere, dann habe ich folgendes verstanden: Bestimmte markierte Protokolle sollen nicht per default aktiviert sein. Der Anwender soll die Möglichkeit erhalten, diese Protokolle explizit zu aktivieren.

Fall 2: Bestimmte markierte Protokolle sollen nicht per default aktiviert sein. Der Anwender soll die Möglichkeit erhalten, diese Protokolle einzeln oder gesamthaft zu aktivieren.

Idee zur Umsetzung dieser beiden Anwendungsfälle: Speziell markierte Protokolle, werden nur geladen, wenn diese in dem Whitelist Attribut aufgeführt sind. Fehlen sie dort, werden sie nicht geladen. Ist keine Whitelist gesetzt, werden diese Protokolle ebenfalls nicht geladen. Um alle markierten Protokolle in das Attribut zu schreiben, könnte man einen Set Befehl anbieten oder man schreibt ein codewort in das Attirbut der Whitelist um diese und auch zukünftige zu laden.

Module einzeln in SVN zu aktualisieren ist möglich.

Ralf9 commented 5 years ago

zu Fall 1: Dies ist doch der Sinn vom Whitelist Attribut, daß der Endanwender dort die IDs eintragen kann die er empfangen will. So mache ich es auch bei meinen beiden produktiven sduinos. Ich habe in deren Whitelist nur die IDs von den Sensoren und Fernbedienungen eingetragen, die ich habe.

zu Fall 2: Was meinst Du mit "Bestimmte markierte Protokolle"? Meinst Du damit die developID y und p ?

Speziell markierte Protokolle, werden nur geladen, wenn diese in dem Whitelist Attribut aufgeführt sind. Fehlen sie dort, werden sie nicht geladen. Ist keine Whitelist gesetzt, werden diese Protokolle ebenfalls nicht geladen.

Ja, so habe ich es gedacht.

Um alle markierten Protokolle in das Attribut zu schreiben, könnte man einen Set Befehl anbieten oder man schreibt ein codewort in das Attirbut der Whitelist um diese und auch zukünftige zu laden.

Dafür ist "Y" gedacht, wenn "Y" im Attribut development eingetragen wird, dann werden alle Protokolle die ein developID y haben, aktiviert.

sidey79 commented 5 years ago

Bestimmte markierte Protokolle sind z.B. mit dem Key developID markiert. Genau so habe ich es gemeint.

Um die beschriebenen Anwendungsfälle abdecken zu können braucht es kein development Attribut und auch keine Unterscheidung von y,p oder m im Feld developID. Für das Feld developID würde 0 oder 1 ausreichen um diese Fälle abdecken zu können.

Die Aktivierung eines deaktivierten Protokolles, kann man vornehmen, in dem es explizit in der whitelist benannt wird.

Wozu wäre die Option gut, alle deaktivierten Protokolle immer zu laden?

Ralf9 commented 5 years ago

Ja, das Y ist nicht unbedingt notwendig, aber es ist für einige eine Erleichterung und Vereinfachung. Beim Testen ob es für neue Sensoren oder Fernbedienungen schon eine ID gibt, ist es hilfreich, wenn alle IDs aktiv sind. Mit dem Y muß man sich dann nicht die Mühe machen alle developIDs rauszusuchen.

Das entfernen der developID m wird in einigen Fällen Nachteile haben, aber wenn Ihr damit leben könnt, kannst Du es gerne rausnehmen. Das hier kannst Du dann auch rausnehmen.

        if ($developID eq "m") {
            if ( length($developATTR) > 0 && $developATTR =~ m/$developID$id/) { 
                return 1; #   return 1 da modulematch gefunden wurde            
            }
            SIGNALduino_Log3 $name, 3, "$name: ID=id skipped dispatch (developId=$developID). To use, please add $developID$id to the attr development";    
            return -1;
}

Ich sehe schon, Du hast bei dem development Attribut andere Ansichten wie ich. Es ist wahrscheinlich besser, wenn Du den pullrequest selber machst. Ich halte mich jetzt da raus.

sidey79 commented 5 years ago

OK, der Anwendungsfall um alle IDs zu aktivieren ist, dass man als Anwender nicht weiss, welches passen könnte . Das verstehe ich und aus Anwendersicht kann man es auch nicht wissen, wenn es nicht zufällig irgendwo steht.

Für den Bezeichner y, m oder p vor einem Protokoll habe ich jetzt noch keinen Anwendungsfall gefunden.

Folgenden Fall habe ich gestern erlebt: Ich habe diese LED Funkkezen letztes Jahr als Protokoll 76 und 76.1 angelegt. Homeautouser hat dazu einen PR erstellt und developID Wert von y auf P geändert.

Den PR wollte ich ausprobieren. Also habe ich die Protokoll Definition angepasst. Da auf dem Testsystem alle Protokolle aktiv waren, habe ich erst Mal 76,76.1 in Whitelist ID eingetragen. Protokoll 76 wurde aber noch immer übersprungen. Im Attribut development hatte ich y76,y76.1 vom letzten Jahr noch stehen. Als normaler Anwender kommst Du doch an diesem Punkt nicht weiter. Vor dem Update hat es noch funktioniert und nach dem Update geht es auf einmal nicht mehr.

Ich habe mich dann erinnert, dass der developID Wert geändert wurde. Also habe ich p76,p76.1 in das Attribut development eingetragen. Dann war das Protokoll auch aktiviert.

Mein Anliegen ist es, diesen Ablauf zu vereinfache. Aus Sicht eines Anwenders, ist es doch auch unerheblich ob da jetzt y,p oder m im drvelopID steht. Diese Unterscheidung führt doch letztendlich nur dazu, dass man im Entwicklungs Verlauf dem Anwender mitteilen muss, seine Attribute zu ändern. Als Endanwender würde ich dann vermutlich einfach den globalen "alles an" Schalter bevorzugen. Damit habe ich keinen Pflegeaufwand an dieser Stelle.

Wenn wir stattdessen die wilhitelistID dafür verwenden, haben wir das gleiche Attribut mit dem gleichen Wert über den kompletten Lebenszyklus.

In welchem Fällen die Bezeichner m oder p von Vorteil sind habe ich leider noch immer nicht verstanden. :(

HomeAutoUser commented 5 years ago

Bei allen Formulierungen komme ich fast immer dahin, das es egal ist, was in developID steht. Der User sollte bei allen Varianten p / m / y drauf hingewiesen werden das dort für den Empfang der Eintrag im develoID Attribut notwendig ist.

Ist das gewollte nicht so wie @Ralf9 und du @Sidey79 beschreiben? Nutzung Black / Whitelist Nutzung. Alles developID für den Anwender aus aber ein Hinweis. Bei Nutzung muss er es eintragen.

Ich sehe fast die m / p / y Variante als eines. Es muss nur unterschieden werden, das beim Eintrag von y alle aktiviert werden und bei y56 m 45 oder p34 jeweils das einzige.

Lasst uns nicht im Kreise drehen, die Beseitigung des Bug wollen wir ungern nach hinten verschieben weil wir es zu „zerschreiben“ / nicht verstehen oder geringfügige Diff haben.

Ralf9 commented 5 years ago

In welchem Fällen die Bezeichner m oder p von Vorteil sind habe ich leider noch immer nicht verstanden.

p ist für die Fälle wo die ID nur reserviert oder noch nicht voll funktionsfähig ist, z.B. wenn sie eine postDemodulation Routine noch nicht fertig ist. Die IDs mit p sind noch nicht für den Endanwender bestimmt. z.B. die IDs 76 und 76.1 bevor HomeAutoUser sie überarbeitet hat.

m ist für die Fälle wo es ein Modul gibt, das nicht im github und noch nicht im SVN ist, oder das Modul noch nicht fertig ist.

sidey79 commented 5 years ago

Ist das mit dem p oder m für den Anwender interessant? Gibt es dafür einen Anwendungsfall oder interessiert es den Anwender nicht.

sidey79 commented 5 years ago

@HomeAutoUser

Ich Versuche die Motivation hinter den vielen Optionen zu ergründen. Das ist leider ein zäher Prozess.

Mit den mit jetzt bekannten Anwendungsfällen, muss der Anwender mit y, p oder m eigentlich nicht verwirrt werden. Er will nur ein Protokoll aktivieren .

HomeAutoUser commented 5 years ago

Das für den User m p oder y nicht relevant sind habe ich im o.g. Post gemeint. Die Option m p y ist für uns Entwickler eine Notiz würde ich sagen. Für den Anwender ist es maximal ein Schalter der egal ob m p y für ihn signalisiert werden sollte oder nach Aufforderung aktiviert werden soll. Um den Tatendrang vom User zu vereinfachen, so sollte mit einem y alle Entwickler freigeschalten werden.

sidey79 commented 5 years ago

Wenn wir damit alle Anwendungsfälle haben, würde ich auch einen PR erstellen.

Über den können wir dann ja noch weiter diskutieren.

Ralf9 commented 5 years ago

Ist das mit dem p oder m für den Anwender interessant?

Ohne p könnte es passieren, daß der Anwender mit y auch ein Protokoll aktiviert das noch nicht richtig funktioniert oder z.B. durch eine noch nicht fertige postDemodulation Routine einen fhem Absturz verursacht.

Beispiele für das m sind das Siro und Fernotron Modul Das Fernotron Modul ist z.Zt. weder im dev33 noch im SVN. Wenn es kein m gibt und das Protokoll aktiviert wird, wenn das Modul nicht in fhem ist, gibt es Fehlermeldungen im log. Beim Siro Modul gab es auch eine Phase wo es weder im dev33 noch im SVN war.

HomeAutoUser commented 5 years ago

Ich denke wir haben alle Fälle und ich denke wir kommen zu dem Punkt wo es Ralf seine Variante ist oder ich habe noch was falsch verstanden.

elektron-bbs commented 5 years ago

Bei Punkt stimme ich dir zu, aber wirklich nur als Entwicklernotiz. Im Prinzip kann ich alles dort hinschreiben. Auswertung dann nur true oder false, wenn definiert oder nicht.

Punkt 2: "y" oder vieleicht besser sogar "all" für alle DevelopID freischalten. Einzelne Protokolle sollten dann unabhängig von m, p, y nur mit einer Zahl aktiviert werden, wie bei blacklist oder whitelist. Eine Angabe einer DevleopID in der whitelist müsste dann exklusiv nur dieses eine Protokoll aktivieren.

Wer das Attribut "development" verwendet, sollte sich im Klaren sein, das er mit Fehlern rechnen muss. Ein entsprechender Hinweis in der commandref sollte klar darauf hinweisen. Evtl. könnte man das Attribut in der Master-Version ja auch gleich weglassen.

Ralf9 commented 5 years ago

Ich habe es mal versucht einzubauen, aber das mit der regex ist nicht so einfach wie ich dachte.

Mit dieser regex Abfrage

$develop = AttrVal($name,"development","");
...
if ($develop !~ m/$id/) {   # skip wenn die Id nicht im Attribut development steht
    push (@...
    next;
}

und diesen development Attribut Varianten m72.1m82p78 m72.1 m82 p78 72.1 82 78 72.1,82,78

erfolgt bei der ID 2 kein skip, da die 2 ja in 72 und 82 enthalten ist.

Nachtrag: geht dies mit einer regex oder muß ich die in development enthaltenen IDs in einen $hash einlesen?

Ralf9 commented 5 years ago

Eine möglichkeit wäre alles was keine Zahl, Punkt oder Komma ist durch Komma zu ersetzen und dann in einen $hash $develop =~ s/[^0-9\.,]/,/g und dann %developIDs = map { $_ => 1 } split(",", $develop);