Patch für CUL_TX

Begonnen von Sidey, 05 August 2018, 23:34:26

Vorheriges Thema - Nächstes Thema

Sidey

Hallo Rudi,

ich habe beim undefine einen unschönen Fehler festgestellt der nach einem Batteriewechsel auftreten dürfte.

1. Gerätedefinition nach dem es via autocreate angelegt wird einen Namen vergeben
2. Batteriewechsell (aus- und wieder einschalten)
3. Den code durch die von autocreate neu angelegte Gerätedefinition in die ursprüngliche Definition eintragen (Code ändern)
4. Die zuletzt angelegete Definition löschen

Danach legt autocreate wieder ein neues Gerät an, da in defptr der passende Eintrag zum CODE gelöscht wurde.

Dieses Verhalten gibt es wohl in etlichen anderen Modulen auch. Ich habe einen Fehlertext eingebaut, damit man als Anwender wenigstens mitbekommt, dass löschen so nicht funktioniert.
Dazu habe ich Zusätzlich eine Prüfung des NAME Internals mit eingefügt.




Die restlichen Anpassungen sind eher Kosmetik, das autocreateThreshhold soll dafür sorgen, dass erst nach 2 Meldungen für das gleiche Gerät etwas angelegt wird. Ich bekomme immer mal wieder eine Leiche rein.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

rudolfkoenig

Ich habe einen anderen Vorschlag: define/modify lehnt es ab, ein Geraet anzulegen, wenn der neue Code schon vergeben ist. Ich glaube damit vermeidet man weitere Fehlersituationen. Ich habe es "trocken" (sprich ohne Geraet) getestet und eingecheckt, waere nett, wenn du es pruefen koenntest.
Die beiden anderen Aenderungen habe ich uebernommen.

Sidey

#2
Ich werde es gleich testen, mein Gefühl sagt mir aber, dass es $hash->{OLDDEF} nicht gibt.

Wie der Anwender dann einen Codewechsel macht, ist mir mit dieser Anpassung aber noch nicht ganz klar.


So, habe jetzt auch getestet. $hash->{OLDDEF} war vorhanden. Habe im Wiki aber nicht gefunden, was in dieser Variable steht.

Ablauf

1. CUL_TX_104 war schon angelegt
2. CUL_TX_83 durch autocreate anlegen lassen
3. In CUL_TX_104 den code auf 83 geändert
  -> Meldung passt, dass es bereits CUL_TX_83 gibt  :D
4. CUL_TX_83 gelöscht
5. In CUL_TX_104 den Code auf 83 geändert  -> Funktioniert auch tadellos


Ich habe dann noch einen Schritt gemacht, weil ich mich mit dem CUL_TX_104 vertan hatte....

6. In CUL_TX_104 den Code 104 eingetragen
->  "Cannot modify CUL_TX_104 as the code 104 is already used by CUL_TX_104"

Der defptr wird beim Modify nicht entfernt.

Dazu müsste in der define sub noch so etwas wie

delete ($modules{CUL_TX}{defptr}{$hash->{CODE}});

mit aufgenommen werden, wenn $a[2] != $hash->{CODE}


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

rudolfkoenig

ZitatWie der Anwender dann einen Codewechsel macht, ist mir mit dieser Anpassung aber noch nicht ganz klar.
Neu angelegtes Geraet erst loeschen, dann Code beim alten aendern.

ZitatIn CUL_TX_104 den Code 104 eingetragen
Wird ab jetzt auch geprueft.

Uebrigens konnte dieses Problem auch bisher geloest werden:
- Methode 1: alten CUL_TX auf dem neuen Code aendern, neu angelegtes CUL_TX loeschen, und FHEM neustarten.
- Methode 2: neuen CUL_TX entfernen, alten CUL_TX auf dem neuen CODE setzen. In defptr bleibt der alte Code zwar drin, dieserwird aber aber nicht mehr gesendet.
Nur wenn man auf Deine Reihenfolge besteht, gibts das Problem.