[erledigt] OWDevice feature request

[erwin]

Hi Boris,
der korrigierte code im Attachment.
@Beta-User, klingt alles richtig, allerdings würde ich das Boris überlassen.
l.g. erwin

[Beta-User]

@Beta-User, klingt alles richtig, allerdings würde ich das Boris überlassen.

"prinzipiell" ist das schon die richtige Haltung, aber:

Mangels aktivem Equipment nach Umzug kann ich selber nicht weiter testen und entwickeln, schon gar nicht diese Randfälle.

Zum einen: die "disabled"-Reading-Auswertung _kann_ m.E. so nicht richtig sein, wenn sie vor $init_done erfolgt (=> neuer bug!)
Zum anderen: du hast gute Gründe, das selbst zu fixen, denn Boris ist auf passende Zuarbeit angewiesen . Falls du MySensors im Einsatz hast: z.B. 00_MYSENSORS.pm hat so einen verzögerten Start implementiert (man kann die statischen Teile auch gleich machen und nur den Rest nach "Start()" verlegen). Ist kein Hexenwerk.

[Beta-User]

Hallo zusammen,

nachdem ich mir den Code mal angesehen habe...

Die Initialisierung wird bisher via notifyFn gemacht, und dann aussortiert, was nicht relevant ist. Das ist hier nur die Erstinitialisierung und RereadCfg. Im laufenden Betrieb also mAn. völlig unnötiger overhead. Würde vorschlagen, das auf Timer-Basierte Initialisierung umzustellen, Code-Vorschlag (außer dem prinzipiellen Laden ungetestet!) anbei.

@erwin: vielleicht magst du testen?

[erwin]

Hi,
ich hab getestet, Funktion ok, alle devices pollen, disable/enable funktioniert, shutdown restart unauffällig!
Herzlichen Dank für deinen Input!
Ich möchte Boris bitten, deine Version einzuchecken.
l.g. erwin

[Beta-User]

Danke für die Rückmeldung.

Vielleicht magst du noch eine "aufgeräumte" Version erstellen? Ich hatte teils nur auskommentiert, was überflüssig wurde und auch die Funktion selbst nicht umbenannt. Das könnte/sollte man m.E. noch machen (hüftgeschossener Vorschlag für sowas wäre .*_Start oder .*_firstInit)

[erwin]

Hi Beta-User,
ich hab ein wenig aufgeräumt, die auskommentierten Zeilen im Init hab ich bewusst drin gelassen - damit man gleich sieht, dass es keine NotifyFn gibt.
Kurz nochmal getestet - funktioniert!
l.g. erwin

[Beta-User]

Thx. Habe grade noch gesehen, dass da NOTIFYDEF direkt (In Initialize) gesetzt wird, die Zeile sollte auch noch raus; sorry for inconvenience...

(@erwin: Falls du betr. der neu übernommenen Module Bedarf in Richtung der Initialisierung etc. hast oder sonst eine Frage: ggf. melden!).Edit: Kurzer Blick in den Code genügt: offenbar kein support erforderlich...)

EDIT 2, etwas intensiver nachgesehen: Warum hat 10_KNX.pm eigentlich überhaupt eine notifyFn?

[erwin]

hi,
NOTIFYDEF auch noch gelöscht, sollte passen...

10_KNX.pm NotifyFN - war/ist vorgesehen für delayed start und evtl. auch falls ich Attribute wärend des defines brauchen würde... - macht dzt. nix (ausser cpu-verschwenden  ).
Ich werde beim nächsten update ein frühes return einbauen...
PS: das komische IsDisabled($ownName) == 1 kommt daher, weil es KNX devices git, die als state disabled / enabled setzen. Bin damals darüber gestolpert...
l.g.erwin

[Beta-User]

10_KNX.pm NotifyFN - war/ist vorgesehen für delayed start

nach der Diskussion hier nehme ich an, dass "war" die korrekte aktuelle Lesart ist...?
Initialisierung macht man besser Timer-basiert. (Zwischenzeitlich, früher war das anders in der Doku gestanden bzw. die ist in dem Punkt ggf. nicht mehr aktuell)

Ich werde beim nächsten update ein frühes return einbauen...

Bzgl. "return": Bei der kurzen Hineinsicht in KNX bin ich auch über die "Variable" "$UNDEF" gestolpert. Bin zwar kein Perl-Experte, aber alle meine bisherigen Erfahrungen mit dem Thema gehen in die Richtung, dass man (in eigenem Code) immer entweder was zurückgibt, oder direkt einen Strichpunkt nach dem return setzt .

PS: das komische IsDisabled($ownName) == 1 kommt daher, weil es KNX devices git, die als state disabled / enabled setzen. Bin damals darüber gestolpert...

Das Problem (bzw. was Ähnliches) hatte ich in RandomTimer auch; habe das irgendwie anders gelöst, mir scheint bisher entgangen zu sein, dass es auch andere "disabled-Level" gibt ... Wieder was gelernt!

[Dr. Boris Neubert]

Erstmal herzlichen Dank an Erwin und Beta-User für Eure Arbeit und dass Ihr Euch der Weiterentwicklung angenommen habt.


Da die Diskussion noch andauert, warte ich noch bis morgen oder übermorgen ab, bis ich mir das überarbeitete Modul auch ansehe und dann einchecke, wenn mir nichts mehr auffällt!

Liebe Grüße
Boris

[Beta-User]

Die weitere Diskussion ist/war hier eigentlich OT, sorry ...

(Wir (erwin und ich) hatten nur bzgl. Doku-Checks und 10_KNX.pm gestern noch eine Irritation, von daher wollte ich nur grundsätzliche Bereitschaft signalisieren, manche Punkte zu klären, die sich einem als "neuer" Maintainer ggf. nicht direkt erschließen, weil sie (noch) nicht unbedingt gut dokumentiert sind, und da wir hier jetzt schon mal dabei waren...).

[erwin]

Hi,
ich hab ja das Modul geerbt....
bez. return $UNDEF:
kommt aus der developer docu: etliche externe Funktionen wollten (vor ca. 1 Jahr) ein return undef; . Nachdem aber PBP darüber gemeckert hat, hab ich nachgegeben und irgendwo my $UNDEF = undef; definiert und ab da verwendet.
Ob die developer docu in dem Punkt (noch) korrekt ist, kann ich nicht sagen.
l.g. erwin
PS: Bin immer offen für reviews! (ich werd mir die 00_MYSENSORS.pm anschauen..)

[Beta-User]

  Das Unbehagen, überkommene "Anforderungen" über Bord zu werfen kann ich gut nachvollziehen...

MYSENSORS.* ist aber (wie MQTT-Classic) etwas "speziell", weil es - obwohl zweistufig - keine ParseFn kennt. (Das ist - im Sinne einer strukturierten Eventverarbeitung - nicht gut, aber schwer zu ändern!)

Fragen aber gerne - wo auch immer. Notfalls hier weiter OT, obwohl es Boris wohl davon abhält, das einzuchecken ...
(Ich habe bewußt weggesehen, was elsif-Kaskaden oder return undef; angeht, aber das jetzt hier auch noch abzuarbeiten, war/ist nicht mein Anliegen!)

@KNX.pm:
Die doku bzgl. "return undef;" dürfte auch schlicht dem bisher üblichen "common style" entsprechen, aber funktional kann man nach meiner Erfahrung auch ohne weiteres PBP-"pur" fahren. Soweit ich das im Kopf habe: Nur, wenn die aufrufende Funktion ein Array erwartet, ist "return undef;" funktional was anderes als "return;" - und das sind die allerwenigsten Funktionen...
Schon gleich, was die Frage der Aufrufe "von extern" angeht - du hast das eingepackt, außer "Initalize" ist keine Funktion mehr unter dem alten Namen aufrufbar, und wo du modulintern selbst ein Array erwartest, müsstest du recht schnell klären können.

Also "hau es weg", teste es eine Woche, und dann ab mit "return pur" ins svn.
Just my2ct.

[Dr. Boris Neubert]

eingecheckt