Autor Thema: [erledigt] OWDevice feature request  (Gelesen 2565 mal)

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 630
Antw:[erledigt] OWDevice feature request
« Antwort #15 am: 27 August 2021, 10:22:07 »
Hi Boris,
der korrigierte code im Attachment.
@Beta-User, klingt alles richtig, allerdings würde ich das Boris überlassen.
l.g. erwin
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:OWDevice feature request
« Antwort #16 am: 27 August 2021, 10:33:02 »
@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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:[erledigt] OWDevice feature request
« Antwort #17 am: 27 August 2021, 12:39:59 »
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?
« Letzte Änderung: 27 August 2021, 16:56:26 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 630
Antw:[erledigt] OWDevice feature request
« Antwort #18 am: 27 August 2021, 14:37:43 »
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

FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:[erledigt] OWDevice feature request
« Antwort #19 am: 27 August 2021, 14:45:22 »
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)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 630
Antw:[erledigt] OWDevice feature request
« Antwort #20 am: 27 August 2021, 16:00:55 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:[erledigt] OWDevice feature request
« Antwort #21 am: 27 August 2021, 16:08:35 »
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?
« Letzte Änderung: 27 August 2021, 16:21:00 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 630
Antw:[erledigt] OWDevice feature request
« Antwort #22 am: 27 August 2021, 16:35:02 »
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  :D).
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:[erledigt] OWDevice feature request
« Antwort #23 am: 27 August 2021, 16:50:39 »
10_KNX.pm NotifyFN - war/ist vorgesehen für delayed start
;D 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)

Zitat
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 ;) .

Zitat
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!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4998
  • Are we just self-replicating DNA?
Antw:[erledigt] OWDevice feature request
« Antwort #24 am: 27 August 2021, 17:23:06 »
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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:[erledigt] OWDevice feature request
« Antwort #25 am: 27 August 2021, 17:28:59 »
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...).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 630
Antw:[erledigt] OWDevice feature request
« Antwort #26 am: 27 August 2021, 17:30:43 »
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..)
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:[erledigt] OWDevice feature request
« Antwort #27 am: 27 August 2021, 17:44:58 »
 ;D 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 ;D ...
(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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4998
  • Are we just self-replicating DNA?
Antw:[erledigt] OWDevice feature request
« Antwort #28 am: 28 August 2021, 18:40:13 »
eingecheckt
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

 

decade-submarginal