Missing Log output for development state m protocol

[sidey79]

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

• Version (Module): till commit 8462693 behaviour can be reproduced because later the protocol is not any longer in development state m.

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

[sidey79]

Bezüglich eines möglichen Fhem Absturzes durch eine Postdemodulation habe ich eine Idee wie wir das verhindern.

[Ralf9]

Mit dem develop hash funktioniert es nun wie es soll. Für developId=p habe ich keine eigene Liste gemacht, da es diese normalerweise nicht oder nur kurz geben sollte.

2018.12.02 16:53:48.945 3 : sduinoD IdList: ID=76 skiped (developId=p), not for user
2018.12.02 16:53:48.945 3 : sduinoD IdList: ID=76.1 skiped (developId=p), not for user
2018.12.02 16:53:48.945 3 : sduinoD: IDlist MS 0 1 2 3 3.1 6 7 13 13.2 14 15 17 22 23 25 32 33 35 38 41 42 51 55 65 68 72.1
2018.12.02 16:53:48.945 3 : sduinoD: IDlist MU 8 9 13.1 16 17.1 19 20 21 24 26 27 28 29 30 31 32.1 34 36 37 39 40 44 44.1 45 46 48 49 50 56 59 60 61 62 64 66 67 69 70 71 72 74 75 78 79 80 81 82 83 84 85 86
2018.12.02 16:53:48.945 3 : sduinoD: IDlist MC 10 11 12 12.1 18 43 47 52 57 58
2018.12.02 16:53:48.945 3 : sduinoD: IDlist development skipped = 5 73 77 87
2018.12.02 16:53:48.945 3 : sduinoD: IDlist blacklist skipped = 4 63
2018.12.02 16:53:48.945 3 : sduinoD: IDlist develop module used (dispatch must aktivated) = 2 82

[Ralf9]

habe es fertig, wenn für Euch die log Ausgabe so passt, kann ich einen pullrequest machen

[Ralf9]

Hier ist ein weiterer Anwendungsfall für die developId m Wenn während der Entwicklung eines Moduls, bei allen IDs die dieses Modul verwenden, developId m eingetragen wird, dann sind davon nur die wenigen user betroffen die diese IDs ins Attribut development eingetragen haben.

https://github.com/RFD-FHEM/RFFHEM/issues/405 https://forum.fhem.de/index.php/topic,94039.0.html

[sidey79]

@Ralf9

Was soll die Information "not for user" ausdrücken?

2018.12.02 16:53:48.945 3 : sduinoD IdList: ID=76 skiped (developId=p), not for user
2018.12.02 16:53:48.945 3 : sduinoD IdList: ID=76.1 skiped (developId=p), not for user

Hier sollte must aktivated durch must be activated via ... ersetzt werden. Was genau soll wer hier aktivieren wäre noch die Frage. 2018.12.02 16:53:48.945 3 : sduinoD: IDlist develop module used (dispatch must aktivated) = 2 82

[sidey79]

Hier ist ein weiterer Anwendungsfall für die developId m Ja :)

Wenn während der Entwicklung eines Moduls, bei allen IDs die dieses Modul verwenden, developId m eingetragen wird, dann sind davon nur die wenigen user betroffen die diese IDs ins Attribut development eingetragen haben.

Wenn wir anstatt des Attributes development das Attribut WhitelistID dafür herannehmen wäre dieser Fall ebenso abgedeckt oder?

[Ralf9]

Was soll die Information "not for user" ausdrücken?

Dies soll bedeuten, daß developId=p nur für Entwicker ist, nicht für den Endanwender. Lässt sich evtl etwas besser formulieren.

Die IDs mit developId=p sollten die Ausnahme sein. Wenn die Anpassung von @HomeAutoUser für die ID 76 (Kabellose LED-Weihnachtskerzen) funktioniert, haben wir momentan keine IDs mit developId=p mehr.

2018.12.02 16:53:48.945 3 : sduinoD: IDlist develop module used (dispatch must aktivated) = 2 82 Hier sollte must aktivated durch must be activated via ... ersetzt werden. Was genau soll wer hier aktivieren wäre noch die Frage.

Damit das develop module bei einem dispatch aufgerufen wird, muß die ID in das development Attribut eingetragen werden.

[Ralf9]

Wenn wir anstatt des Attributes development das Attribut WhitelistID dafür herannehmen wäre dieser Fall ebenso abgedeckt oder?

Damit das Attribut WhitelistID anstatt des Attributes development verwendet werden kann, muß das Attribut WhitelistID aber auch definiert sein.

Wenn das Attribut WhitelistID nicht verwendet wird, muß bei den developId=m IDs der dispatch durch eintragen der ID in das Attribut development aktiviert werden.

Die IDs mit developId=m sollten die Ausnahme sein. Momentan ist das developId=m nur bei den IDs 2 und 82 notwendig. Bei der Neuentwicklung oder sehr umfangreichen Änderungen an einem Modul ist das developId=m nur temporär bis das Modul fertig ist, notwendig. Bei IDs ohne developId=m sollte dies nachträglich nicht mehr zugefügt werden.

[sidey79]

Vorschläge für die Logausgaben:

sduinoD IdList: ID=76 skiped (developId=p), not for user in folgendes ersetzen: sduinoD IdList: ID=76 skiped (developId=p), use this only in a test environment! (instable protocol) Für was war p die Abkürzung?

ID76 hat sich HomeAutoUser vertan. Ich habe die FB vor mir liegen, aber werde nicht schlau aus dem Teil.

sduinoD: IDlist develop module used (dispatch must aktivated) = 2 82 in folgendes Ersetzen: sduinoD: IDlist develop available (to activate this protocol add the protocol id to the attribute development)

[sidey79]

Damit das Attribut WhitelistID anstatt des Attributes development verwendet werden kann, muß das Attribut WhitelistID aber auch definiert sein.

Das ist richtig. Da in jedem Fall ein Attribut definiert werden muss und aktuell ggf. auch zwei wäre das doch einfacher, wenn wir das ganze nur über ein Attribut steuern. Die Blacklist ist durch meine Idee, das im Webfrontend klickbar zu machen auch mehr oder weniger hinfällig glaube ich und ohne development Attribut wäre das aus Endanwendersicht doch viel leichter zu handhaben, oder was meinst Du?

[Ralf9]

in folgendes ersetzen: sduinoD IdList: ID=76 skiped (developId=p), use this only in a test environment! (instable protocol)

developId=p ist eigentlich für Entwickler und für die beim Entwickeln mithelfen wollen. Wer mithelfen will bekommt von uns gesagt, das er die ID in das Attribut development eintragen soll. Das Protokoll kann auch noch nicht funktionsfähig sein.

sduinoD: IDlist develop module used (dispatch must aktivated) = 2 82 in folgendes Ersetzen: sduinoD: IDlist develop available (to activate this protocol add the protocol id to the attribute development)

damit ist dann aber nicht mehr erkennbar, daß bei dieser ID kein dispatch erfolgt da ein develop Modul verwendet wird.

[Ralf9]

Die Blacklist ist durch meine Idee, das im Webfrontend klickbar zu machen auch mehr oder weniger hinfällig glaube ich

Wie willst Du das im Webfrontend darstellen, daß die Whitelist nicht aktiv ist und alle IDs außer den developIDs aktiv sind. Du kannst zwar eine Option einbauen mit dem alle IDs aktiviert werden und diese dann in die whitelist gespeichert werden. Wie willst Du das aber handhaben wenn nach einem update weitere IDs dazukommen, die fehlen dann in der whitelist. Der Anwender müsste dann nach jedem update in das Protokoll Webfrontend gehen und schauen ob neue IDs dazugekommen sind und diese aktivieren.

Momentan geht bei jedem aktivieren oder deaktivieren eines Protokolls das Webfrontend zu und die detailview ist weg, dies ist so nicht praktikabel.

Die Aussage Attribute gehören dem user, kennst Du? Wenn Du dies trotzdem machen möchtest solltest Du es deutlich kennzeichnen, daß das whitelist Attribut geändert wird.

[sidey79]

Wer mithelfen will bekommt von uns gesagt, das er die ID in das Attribut development eintragen soll.

Okay, dann vielleicht einfach die Logausgabe weglassen und das Protokoll in allen Sichten ausblenden?

sduinoD: IDlist develop available (to activate this protocol add the protocol id to the attribute development)

damit ist dann aber nicht mehr erkennbar, daß bei dieser ID kein dispatch erfolgt da ein develop Modul verwendet wird.

Reicht es aus, wenn man das in der Protokoll Übersicht sieht? Ich finde leider kein Beispiel, bei dem developID = m ist und kein logisches Modul definiert wurde.

Ist dem Anwender doch auch egal ob eine Logmeldung kommt, dass er es fürs Dispatchen aktivieren soll. Sobald das Protokoll aktiviert ist, kann es eben dispatchen oder eben nicht. Abhängig davon, was bereits implementiert wurde. Ändern kann es der "normale" Anwender in der Regel ja nicht.

[sidey79]

Wie willst Du das im Webfrontend darstellen, daß die Whitelist nicht aktiv ist und alle IDs außer den developIDs aktiv sind.

Habe ich schon erledigt, sieht dann so aus:

Du kannst zwar eine Option einbauen mit dem alle IDs aktiviert werden und diese dann in die whitelist gespeichert werden. Wie willst Du das aber handhaben wenn nach einem update weitere IDs dazukommen, die fehlen dann in der whitelist.

Macht nichts, dass die fehlen. Ist doch der Sinn einer Whitelist, dass explizit etwas aktiviert werden muss und es nicht automatisch einfach so reinrutscht. Man könnte auch argumentieren, dass er die neuen Protokolle nach jedem Update deaktivieren muss, weil er sie nicht mag oder cpu Zeit sparen möchte. Die Anwender sollten doch ohnehin bei nahezu 100 Protokollen mit der Whitelist arbeiten und gar nicht mehr in die Versuchung geraten ohne zu arbeiten.

Der Anwender müsste dann nach jedem update in das Protokoll Webfrontend gehen und schauen ob neue IDs dazugekommen sind und diese aktivieren.

Das macht er doch nur, wenn er ein neues Gerät empfangen will. In der Regel weiss er das (hoffentlich). Wer einfach alles empfangen möchte, verzichtet auf das Attribut whitelistIDs und halt auch auf developID Protokolle. Die verwendet er doch vermutlich auch nur, wenn er vorher Hilfe erbeten hat und dann sucht er doch etwas ganz bestimmtes und nicht einfach nur alles.

Momentan geht bei jedem aktivieren oder deaktivieren eines Protokolls das Webfrontend zu und die detailview ist weg, dies ist so nicht praktikabel.

Ich arbeite daran. Muss jetzt nur noch die Grafiken beim Klicken auf den neuen Zustand ändern. Den Rest habe ich bereits beisammen.

Die Aussage Attribute gehören dem user, kennst Du? Wenn Du dies trotzdem machen möchtest solltest Du es deutlich kennzeichnen, daß das whitelist Attribut geändert wird.

Der Anwender klickt doch und ändert das Attribut. Er macht es halt nur nicht über das Eingabefeld sondern nennen wir es über ein Widget oder halt eine andere Anzeige. Es wird ja nicht unabhängig vom Anwender verändert.

Wir können ja auch noch eine Statistik mit einbauen, wie oft welches Protokoll einen Treffer erhalten hat, das kann ja auch noch bei der Entscheidung helfen etwas zu deaktivieren.

[Ralf9]

@sidey79 sehe ich das richtig, daß Du davon ausgehst, daß die Attribute blacklist und development zukünftig nicht mehr benötigt werden. Dann wird ja der pullrequst, den ich machen wollte, nicht mehr benötigt.

[HomeAutoUser]

Versuche uns das bitte zu erklären wie es funktionieren soll @sidey79

Die Anwender sollten doch ohnehin bei nahezu 100 Protokollen mit der Whitelist arbeiten und gar nicht mehr in die Versuchung geraten ohne zu arbeiten.

Willst du wirklich das ich alle Protokolle anklicken soll weil ich KEINE whitelist nutze. MAX bei einem richtigen Störenfried ein Blackeintrag.

DevelopID? Bleibt diese?

Ohne zu wissen wie es arbeitet, könnte ich mir vorstellen, das das Widget beim Klick die withelist setzt aber bitte nicht so umsetzen das alle Protokolle angeklickt werden müssen.

[sidey79]

sehe ich das richtig, daß Du davon ausgehst, daß die Attribute blacklist und development zukünftig nicht mehr benötigt werden. Dann wird ja der pullrequst, den ich machen wollte, nicht mehr benötigt.

Der sollte doch ausgeben dass Protokolle deaktiviert sind und man diese aktivieren muss dachte ich.

[sidey79]

Versuche uns das bitte zu erklären wie es funktionieren soll @sidey79

Die Anwender sollten doch ohnehin bei nahezu 100 Protokollen mit der Whitelist arbeiten und gar nicht mehr in die Versuchung geraten ohne zu arbeiten.

Willst du wirklich das ich alle Protokolle anklicken soll weil ich KEINE whitelist nutze. MAX bei einem richtigen Störenfried ein Blackeintrag.

Im Auslieferungs Zustand sind ja alle Protokolle aktiviert die kein developID haben. Wenn nun ein developID Protokoll Zusätzlich aktiviert werden soll, dann muss einmal geklickt werden. Wenn alle bis auf eines deaktiviert werden soll dann muss aktuell ca. 100 mal geklickt werden, oder der Anwender schreibt einfach die Protokoll ID in das Attribut whitelistIDs

DevelopID? Bleibt diese?

Ja, die brauchen wir ja um bestimmen zu können ob ein Protokoll out of the box aktiv oder inaktiv ist.

Ohne zu wissen wie es arbeitet, könnte ich mir vorstellen, das das Widget beim Klick die withelist setzt aber bitte nicht so umsetzen das alle Protokolle angeklickt werden müssen.

Genau, die whitelistIDs wird duch eine FHEM Funktion neu gesetzt. Die Grafik wird dabei neu generiert basierend auf dem tatsächlichen Zustand ob das Protokoll aktiv ist oder eben nicht. So ist zumindest sichergestellt, dass immer der richtige Zustand angezeigt wird. Blacklist und development Attr, beeinflussen ja aktuell ob das Protokoll aktiv ist oder nicht.

Ich würde den Teil erst mal prinzipiell fertig machen wollen. Das mit dem "alles klicken" ist ja keine Verschlechterung zu heute. Da kann man ja nichts klicken.

[HomeAutoUser]

Okay, ich habe verstanden @sidey79. Dann sollte es so klappen wie wir denken. Die Praxis wird es dann auch sofort zeigen.

[sidey79]

Genau. Prototyp fertig machen und dann mal schauen.

[Ralf9]

Der sollte doch ausgeben dass Protokolle deaktiviert sind und man diese aktivieren muss dachte ich.

nein, er macht viel mehr. Bei aktiver whitelist werden die Attribute blacklist und development ignoriert. Bei nicht aktiver whitelist beeinflussen die Attribute blacklist und development ob das Protokoll aktiv ist oder nicht.

[sidey79]

@Ralf9:

Das ist so nicht ganz richtig. An dem Verhalten von Blacklist, Whitelist oder development Attributen ändere ich aktuell nichts.

Ich passe die Übersicht der Protokolle an und mache Protokolle leicht aktivierbar / deaktiviert wenn Blacklist und development nicht verwendet werden!

Im Zuge dieser Anpassungen ist mir aufgefallen, dass das Attribut Blacklist und development das leichte aktivieren von Protokollen beeinflusst.

Wenn wir auf das Blacklist und Development Attribut verzichten könnten, wäre es für den Anwender und uns Entwickler weniger komplex glaube ich.

[Ralf9]

Im Zuge dieser Anpassungen ist mir aufgefallen, dass das Attribut Blacklist und development das leichte aktivieren von Protokollen beeinflusst.

Das hängt evtl damit zusammen, daß in der sub SIGNALduino_IdList die Behandlung von der developID und vom Attribut development noch fehlerhaft ist.

An dem Verhalten von Blacklist, Whitelist oder development Attributen ändere ich aktuell nichts. Wenn wir auf das Blacklist und Development Attribut verzichten könnten, wäre es für den Anwender und uns Entwickler weniger komplex glaube ich.

Ich warte erst mal ab, ob Du es hinbekommst so auf das Blacklist und Development Attribut zu verzichten, das @HomeAutoUser und @elektron-bbs noch damit leben können.

Ich habe es, so wie ich es beschrieben habe, bei mir eingebaut. Es ist zwar bei der Nichtverwendung der whitelist etwas komplexer, hat aber beim Entwickeln und Testen mit dem Dummy sduino Vorteile.