Verringerung der Probleme wegen versch. Vers. des Signalduino im SVN u github

Begonnen von Ralf9, 17 Juni 2017, 12:17:58

Vorheriges Thema - Nächstes Thema

Ralf9

Hallo,

ich habe mir Gedanken darüber gemacht wie man die Probleme, die dadurch entstehen, daß es beim Signalduino eine ältere Version im SVN und eine aktuelle Version im github gibt, verringern kann.

Wenn sich im SVN und im github die selbe Version der 00_SIGNALduino.pm befindet, dann hat es keine Auswirkungen wenn jemand die Version im github verwendet und diese durch ein fhem update mit der älteren Version überschreibt.

Spricht etwas dagegen in der Client- und Matchlist Module einzutragen die es im SVN nicht gibt. Z.B. das  SD_UT Modul?

Nach meinem Verständnis wird ein Eintrag in der Clientlist nur verwendet, wenn es zuvor durch die Matchlist geladen wurde oder es für ein device des Moduls ein define Eintrag in der fhem.cfg gibt.
Es muß dann noch dafür gesorgt werden, daß bei einem dispatch Aufruf es beim regex Ausdruck des nicht vorhandenen Moduls keinen Treffer geben kann. 
Ein Matchlist Eintrag sieht z.B. so aus:
"17:SD_UT"            => '^u30#.*',

Dies kann dadurch erreicht werden, daß bei den Protokoll Ids für die es nur im github ein Modul gibt in dem ProtocolListSIGNALduino Hash ein neuer Eintrag "developId" zugefügt wird.
Diese Protokoll Id wird dann nur noch verwendet, wenn sie in der Whitelist eingetragen wurde.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rudolfkoenig

@Ralf: ich gehe davon aus, dass dein Vorschlag an dem Signalduino Entwickler gerichtet ist. Wenn ich der Adressat sein sollte, dann bitte das Problem nochmal explizit beschreiben.

Ralf9

Mich interessiert eigentlich nur ob etwas dagegen spricht in der Client- und Matchlist Module einzutragen die es im FHEM Verzeichnis nicht gibt.
Nach meinem Verständnis müsste es reichen, wenn dafür gesorgt wird, daß bei einem dispatch Aufruf es beim regex Ausdruck der Matchlist des nicht vorhandenen Moduls keinen Treffer geben kann.
Oder habe ich da was übersehen?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Also meiner Meinung nach ist das ganze leichter realisierbar.

Zum einen sollten wir nicht so viele Dinge in einem Release entwickeln. Ein paar Änderungen reichen ja, sonst geht einfach der Überblick verloren. Wir packen ja dauernd was neues an, noch bevor wir wissen ob die letzte Änderung reif ist.

Zum anderen kann man nicht vorhandene Module auch einfach aus kommentieren, wenn man die Version ins SVN überführt. Die Matchlist und die Clientlist könnte man auch zur Laufzeit pflegen.

Alternativ könnte man auf Updates über SVN auch gänzlich verzichten. Fände ich aber nicht so gut.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Ich würde es besser finden, wenn man die 00_SIGNALduino.pm im SVN aktuell halten könnte.
Dann müsste eigentlich die Mehrzahl der User auf das regelmässige update vom github verzichten können und das Problem mit der veralteten Datei im restoreDir wäre auch weg.

Zitat von: SabineT am 10 Juni 2017, 19:42:01
ich hab jetzt die Erklärung, warum da eine veraltete Datei im restoreDir landet:

durch controls_fhem.txt wird erst mal die 00_SIGNALduino.pm ins restoreDir gesichert und dann mit der Version vom Jänner überschrieben, controls_signalduino.txt sichert danach diese veraltete Version, überschreibt damit die eigentlich richtige Sicherung und ladet die aktuelle Datei.

@Sidey wie groß ist für Dich der Aufwand die 00_SIGNALduino.pm regelmässig bei Änderungen im github mit einigen Tagen verzögerung auch ins SVN zu commiten?

Bei experimentellen IDs wie z.B. 63 oder bei IDs für die es im SVN kein Modul gibt, müsste dann in dem ProtocolListSIGNALduino Hash ein neuer Eintrag "developId" zugefügt werden.
Wer diese IDs verwenden möchte, muss sie in die Whitelist oder komma getrennt in ein neues Attribut "developIds" eintragen.
Dadurch kann dann im github und im SVN die gleiche Version der 00_SIGNALduino.pm verwendet werden.

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Der Aufwand ist nicht so groß dass z.B. 1* im Monat zu machen. Wir sollten dann nur prüfen, ob auch Anpassungen in den Modulen mit aufgenommen werden sollen... Eine kleine Checkliste im Github reicht uns da ja im Prinzip.

Das mit den IDs die man einzeln aktivieren muss, waren eine Art Blacklist... Da hatte ellert doch mal was entwickelt.  Die Frage ist nur, wann ist ein Protokoll nicht mehr im Modus develop

Gesendet von meinem Nexus 5 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

Eine Ignorierung von Fehlern bei LoadModule wuerde bei "normalen" Modulen Probleme verstecken, da brauche ich noch gute Argumente, bevor ich dafuer was einbaue.

Zitatcontrols_signalduino.txt sichert danach diese veraltete Version, überschreibt damit die eigentlich richtige Sicherung und ladet die aktuelle Datei.
Um das zu verhindern kann man ab sofort in exclude_from_update auch Quelle:Dateiname spezifizieren, in diesem Fall vmtl. sowas wie fhem.de.*:00_SIGNALduino.pm

Ralf9

ZitatEine Ignorierung von Fehlern bei LoadModule wuerde bei "normalen" Modulen Probleme verstecken
Ich sehe keine Notwendigkeit für die Ignorierung von Fehlern bei LoadModule.
Ich habe es mal getestet.
Ich habe das Modul 14_SD_UT.pm im FHEM Verzeichnis gelöscht. Ich habe beim restart und beim Betrieb keine Fehler von LoadModule bekommen obwohl das Modul SD_UT in der Client- und Matchlist eingetragen ist.
Es kommt nur zu einer Fehlermeldung "ERROR: Cannot autoload SD_UT", wenn es beim dispatch Aufruf zu einem Treffer beim regex Ausdruck von SD_UT der Matchlist kommt.
Daß es beim dispatch Aufruf zu einem Treffer kommen kann lässt sich durch das Flag developId verhindern.
Oder habe ich da ein Problem oder Fehlermeldung übersehen?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Ich möchte darauf nochmal zurückkommen.

Ich habe das mit der Match- und Clientlist folgendermaßen verstanden:
Bei einem dispatch wird zuerst bei den geladenen Modulen der Clientlist die regexp der $hash->{Match} geprüft. Passt keine der client regex, werden die regexp in der matchlist überprüft. Bei einem treffer wird das entsprechende Modul geladen und die dispatch Parameter übergeben.

Wenn nun ein Client Modul xy in der Client- und Matchlist eingetragen ist und es dieses Modul xy im FHEM Verzeichnis nicht gibt, da es noch nicht im SVN ist.
Und wenn mit einem Flag dafür gesorgt wird, daß kein dispatch Aufruf mit einer dmsg für das xy Modul erfolgt.
Kann es dann  irgendwelche Probleme geben.
Ich habe es mal getestet, solange es beim dispatch zu keinem regex Treffer im Matchlist Eintrag vom Modul xy kommt, gibt es keine Fehlermeldungen.
Kann es beim durchsuchen der Clientlist nach geladenen Modulen Probleme geben, wenn es ein Modul nicht gibt?

Dies soll nur eine Übergangslöung sein. Wir wollen die 00_SIGNALduino.pm demnächst auf dynamische match- und clientlist umzustellen.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rudolfkoenig

Die Beschreibung der Abfolge im zweiten Absatz ist richtig. MatchList wird nur im Dispatch verwendet. Wenn Signalduino kein Event fuer die nicht vorhandenen Module generiert, dann werden Eintraege fuer die nicht vorhendenen Module in Matchlist folgenlos sein. Um die Codestelle zu zitieren:

  if(!int(@found) || !defined($found[0])) {
    my $h = $hash->{MatchList};
    $h = $module->{MatchList} if(!$h);
    if(defined($h)) {
      foreach my $m (sort keys %{$h}) {
        if($dmsg =~ m/$h->{$m}/) {

Die zweite Zeile implementiert ein Sonderform: damit kann man eine instanzabhaengige Matchlist implementieren. Beim CUL wird damit je nach rfMode eine andere MatchList aktiv.

Ralf9

Ok, dann paßt es so wie ich gedacht habe.
Damit können wir bereits am Anfang der Entwicklung eines neues Moduls dieses in die Client- und Matchlist eintragen.
Über ein Flag wird dann gesteuert ob ein dispatch zu diesem Modul erfolgen kann.
Mit dem .clientArray funktioniert es noch besser als ich gedacht hatte.

Bei dem .clientArray ist mir was aufgefallen. Wenn das erste device eines Moduls z.B. per autocreate definiert wurde, wird das Clientmodul nicht sofort in das ".clientArray" eingetragen.
Es wird erst nach einem fhem restart oder einem ändern des Attributs IODev in das ".clientArray" eingetragen.
Ist dies normal?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rudolfkoenig

ZitatWenn das erste device eines Moduls z.B. per autocreate definiert wurde, wird das Clientmodul nicht sofort in das ".clientArray" eingetragen.
Der Zusammenhang geht anders: clientarray wird in Dispatch neu berechnet, falls es nicht existiert, und es wird bei jeder Aenderung eines IODevs geloescht. D.h. falls ein neu angelegtes Geraet IODev per AssignIoPort oder attr setzt, dann wird es auch ins .clientArray eingetragen. Bin z.Zt. noch dagegen, bei einem define generell alle .clientArrays zu loeschen, das wuerde z.Bsp. bei wiederkehrenden at, das sich staendig neu definiert, fuer viel sinnlose Berechnung des .clientArrays sorgen.

Ralf9

Zitat von: rudolfkoenig am 01 Oktober 2017, 12:29:54
Bin z.Zt. noch dagegen, bei einem define generell alle .clientArrays zu loeschen, das wuerde z.Bsp. bei wiederkehrenden at, das sich staendig neu definiert, fuer viel sinnlose Berechnung des .clientArrays sorgen.

Ich denke es ist nicht unbedingt nötig dieses Verhalten zu ändern. Wenn dieses Verhalten allgemein bekannt ist, müsste man damit leben können.
Die meisten machen wahrscheinlich sowieso recht oft ein Update.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7