Verbesserungen an der ProtocolListSIGNALduino

[Ralf9]

Ich habe angefangen verbesserungen an der ProtocolListSIGNALduino und IDlist vorzunehmen, es ist noch nicht ganz fertig und es sind noch recht viele Debugausgaben drin https://github.com/Ralf9/RFFHEM/commit/66b73cdfb5bb24f46a356bf74e4edfb61eee7a65 https://github.com/Ralf9/RFFHEM/commit/2461ada1a8dc630da14c1a276eaeaba4cb8b2eb3

Es können damit ProtokollIds reserviert werden (developId => 'p' in der Protokolldefinition). Damit wird diese Id nur noch verwendet, wenn sie in die whitelist oder "pxx" (xx = id) in dem neuen Attribut "development" eingetragen ist.

Wenn developId => 'y' in der Protokolldefinition steht, dann ist dies eine deveplop Id. Damit wird diese Id nur noch verwendet, wenn sie in die whitelist oder "y" in dem neuen Attribut "development" y eingetragen ist. (z.B. die ID 63)

developId => 'm' in der Protokolldefinition möchte ich noch einbauen. Dies ist vorgesehen für Module die nicht im SVN sind. Damit bei diesen Modulen ein dispatch ausgeführt wird, muß "mxx" (xx = id) im Attribut "development" eingetragen sein.

Es gibt jetzt auch eine blacklist

Ich würde es hilfreich finden, wenn wir zukünftig in den Kommentar der Protokolldefinition auch den Namen desjenigen eintragen könnten, der die ID eingebaut hat

[sidey79]

Hallo Ralf,

Finde ich gut dass Du an der Umsetzung bist. Gestern habe ich mir wieder überlegt, wie wir das mit dem SVN jetzt machen :)

Was ich jetzt verstanden habe ist, dass Du im Attribut development die IDs der Protokolle pflegen willst.

Die Protokolle sollen ein Attribut developID erhalten. Der Wert von Y sollte hier true oder false sein, das wäre für mich eindeutiger als y.

Mit den logischen Modulen sollten wir das vielleicht etwas anders machen. Ich hatte schon vor Ewigkeiten die Idee, dass man die Clientlist dynamisch erzeugt. Wäre doch eine Option, dass wir anhand von ClientModule die ClientList erzeugen. Wenn jemand das Protokoll aktiviert (whitelist, Develop), dann würde man die Clientlist erzeugen. Wenn er das Modul dann nicht hat könnte man mit einer Fehlermeldung abbrechen.

Vorteil, das wäre dynamischer zu ändern. Wenn wir das im Code einbauen, ist es aufwändig ein neues logisches Modul mit in das Konstrukt aufzunehmen.

Bei den Kommentaren bin ich bei dir. Sowohl Beispieldaten als auch Ansprechpartner wären gut.

[Ralf9]

Die IDs der Protokolle werden in der ProtocolListSIGNALduino gepflegt. Damit es nicht zu doppelten Ids kommt sollte dort so früh wie möglich ein neues Protokoll eingetragen/reserviert werden. Damit diese reservierten Protocol Ids nicht verwendet werden, wenn keine whitelist_IDs definiert ist, wird developId => 'p' in die Protokolldefinition eingetragen.

Bei den Protokollen, die zwar funktionieren, aber noch nicht vollständig getestet sind oder noch nicht wie gewünscht funktionieren (z.B. die Id 63 Warema MU) wird developId => 'y' in die Protokolldefinition eingetragen. Da es anscheinend noch recht viele gibt die keine whitelist_IDs verwenden, können diejenigen diese developIds verwenden, wenn sie 'y' in das Attribut development eintragen.

Damit bei Modulen die noch nicht im SVN sind, wie z.B. das Siro Modul, kein dispatch ausgeführt wird, wird developId => 'm in die Protokolldefinition eingetragen. Wer diese Module verwenden will, muß "mxx" (xx = id) im Attribut "development" eintragen, z.B. m72.

Die Protokolle sollen ein Attribut developID erhalten. Der Wert von Y sollte hier true oder false sein, das wäre für mich eindeutiger als y.

Wenn es z.B. im Wiki und in der Comandref dokumentiert ist, müsste das y eindeutig sein.

Mit den logischen Modulen sollten wir das vielleicht etwas anders machen.

Mit der dynamischen Clientlist alleine ist es wahrscheinlich nicht getan, es gibt auch noch eine matchlist. Die client- und matchlist müsste dann in der sub SIGNALduino_IdList aufgebaut und zugewiesen werden

  $hash->{Clients} = $clientsSIGNALduino;
  $hash->{MatchList} = \%matchListSIGNALduino;

Kann diese Zuweisung jederzeit im laufenden Betrieb gemacht werden?

Ich würde damit aber erstmal abwarten bis der jetzige Stand mit den developid und evtl auch die IDs 73 und 74 von HomeAutoUser im SVN ist, damit wir dort eine aktuelle und Stabile Version haben.

[sidey79]

Ist das Thema noch aktuell? Eventuell besser ein neues Issue aufmachen und dieses schließen

[sidey79]

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