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

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 567
[erledigt] OWDevice feature request
« am: 21 August 2021, 09:13:02 »
Ich hab eine Bitte zum OWDevice Modul:

könnte man ein disable Attr. supporten?
Background: Ich habe etliche OW-devices (nicht mit Bus-Power), die "saisonal" nicht in Betrieb sind.. (Stichwort: z.B.: Swimmingpool, Heizung) und daher bei jedem poll unschöne Log messages produzieren...
Es sollte ja reichen, wenn die devices nicht mehr gepollt werden.
Alternativ set <device> poll 0, das produziert dzt. 5-10 Log msg/sec.
Es ist mühsam und fehleranfällig, jedesmal die devices aus der config zu löschen und wieder neu anzulegen...
Mit einem disable attr. könnte ich das automatisieren (und WAF freundlich machen)
PS: in der OWdevice_Notify Fn sind schon Ansätze für disable-attr drin...
 l.g. erwin

edit: auf erledigt gesetzt - DANKE!
« Letzte Änderung: 25 August 2021, 08:30:22 von 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 eldrik

  • Sr. Member
  • ****
  • Beiträge: 921
Antw:OWDevice feature request
« Antwort #1 am: 21 August 2021, 17:17:57 »
eine kurzfristige Abhilfe zur Verringerung der Log Meldungen würde das erhöhen des Abfrageintervals auf z.B 10000 bringen.

Dazu ein paar passende notifies zum bequemen setzen der Werte.

Greetz
Eldrik

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4981
  • Are we just self-replicating DNA?
Antw:OWDevice feature request
« Antwort #2 am: 23 August 2021, 09:51:12 »
Hallo Erwin,

kannst Du bitte das beigefügte schnell zusammengehackte und ungetestete überarbeitete Modul  ausprobieren? Ich habe ihm das gewünschte disable-Attribut spendiert.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 567
Antw:OWDevice feature request
« Antwort #3 am: 23 August 2021, 11:53:23 »
Danke Boris,
...Test läuft, bisher ist mir folgendes aufgefallen (verbose 5):
1) disable 1 funktioniert
2) ein defmod (mit disable=1) bringt folgendes:
2021.08.23 11:31:11.368 4: DS18S20_30BDDD010800: I/O device is myOWServer
2021.08.23 11:31:11.369 5: DS18S20_30BDDD010800: polling every 60 seconds
2021.08.23 11:31:11.370 5: DS18S20_30BDDD010800: interfaces: temperature
2021.08.23 11:31:11.371 5: DS18S20_30BDDD010800: getters: address crc8 family id locator power r_address r_id r_locator temperature temphigh templow type
2021.08.23 11:31:11.371 5: DS18S20_30BDDD010800: setters: temphigh templow
2021.08.23 11:31:11.372 5: DS18S20_30BDDD010800: polls: temperature
2021.08.23 11:31:11.372 5: DS18S20_30BDDD010800: state: temperature
2021.08.23 11:31:11.373 5: DS18S20_30BDDD010800: alerting: 1
2021.08.23 11:31:11.610 3: DS18S20_30BDDD010800: reading type did not return a value
...wobei mich nur die letzte Zeile stört!
3) ein disable 0 started das polling offensichtlich nicht.
4) löschen disable attr - kein polling - erst ein defmod <device> hilft, wobei dann wieder folgender Log kommt:
2021.08.23 11:42:43.026 3: DS18S20_30BDDD010800: reading type did not return a value
2021.08.23 11:42:43.094 3: DS18S20_30BDDD010800: reading temperature did not return a value
2021.08.23 11:43:43.086 3: DS18S20_30BDDD010800: reading temperature did not return a value
...reading type did.. kommt allerdings nicht bei jedem poll, sondern nur beim defmod!

danke nochmal für deinen support, es ist jedoch nicht wirklich dringend. Die devices funktionieren ja problemlos.
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 Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4981
  • Are we just self-replicating DNA?
Antw:OWDevice feature request
« Antwort #4 am: 23 August 2021, 14:25:51 »
Hallo Erwin,

Danke für Deinen Test. Wie gesagt, es war ein schneller Hack. Mangels aktivem Equipment nach Umzug kann ich selber nicht weiter testen und entwickeln, schon gar nicht diese Randfälle.

Der Hack unterbindet einfach das Lesen vom Bus, entsprechend kommen beim Öffnen der Verbindung vom Gerät keine brauchbaren Werte zum Typ, was zur Fehlermeldung führt. Das ganze braucht bzgl. der Zustände eine dokumentierte Überlegung, um es vollständig richtig hinzubekommen. Das kann ich nicht leisten.

Wenn ich weiter nichts Negatives höre, checke ich diese Fassung die Tage mal ein. Besser als nix wär das dann hoffentlich.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 567
Antw:OWDevice feature request
« Antwort #5 am: 23 August 2021, 18:50:52 »
Hallo Boris,

ich hab jetzt noch 2 Änderungen versucht und damit läuft alles wie es soll:
in OWDevice_UpdateValues:
#     return if  AttrVal($name, 'disable', 0);
      return if (AttrVal($name, 'disable', 0) == 1);
und in OWDevice_Attr:
        elsif($attrName eq "disable" && ($cmd eq 'del' || $attrVal == 0)) { # restart poll after disable
                RemoveInternalTimer($hash);
                InternalTimer(int(gettimeofday()) + $hash->{fhem}{interval}, "OWDevice_UpdateValues", $hash, 0)
                   if(defined($hash->{fhem}{interval}));
        }
ans ende der sub.
Danke nochmal für den support!
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 Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4981
  • Are we just self-replicating DNA?
Antw:OWDevice feature request
« Antwort #6 am: 24 August 2021, 16:13:40 »
Danke, Erwin.

Kannst Du bitte die Datei hier anhängen. Dann checke ich sie ein.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 567
Antw:OWDevice feature request
« Antwort #7 am: 24 August 2021, 16:23:47 »
Hallo Boris,
bitte schön, die Datei - und danke!
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 eldrik

  • Sr. Member
  • ****
  • Beiträge: 921
Antw:OWDevice feature request
« Antwort #8 am: 25 August 2021, 07:59:46 »
Moin zusammen,

ich habe die Ergänzungen auch einmal für meine 1Wire Instanzen eingepflegt und bisher keine Probleme festgestellt.

Für Devices die ich nicht Pollen muss, da sie rein zum schalten verwendet werden (DS2408, DS2413 etc.) oder es sich um 1Wire RGBW Controller handelt, hatte ich bisher Intervalle von 100000 eingetragen, für den Busverkehr kann es aber ja nur von Vorteil sein, diese in Gänze aus dem Polling zu nehmen.

Danke für die Anregung und Erweiterung.

Greetz
Eldrik

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4981
  • Are we just self-replicating DNA?
Antw:OWDevice feature request
« Antwort #9 am: 25 August 2021, 08:01:42 »
Überarbeitete Version eingecheckt, wird ab morgen früh per Update verteilt
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 567
Antw:[erledigt] OWDevice feature request
« Antwort #10 am: 27 August 2021, 09:06:17 »
Sorry Boris,
ich hab jetzt noch einen kleinen Bug entdeckt - (..meine Änderungen...) während startup kommt:
PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/11_OWDevice.pm line 725Kannst du bitte die Zeile 725 ändern:
#  return if($attr{$name} && $attr{$name}{disable} == 1);
  return if(ReadingsVal($name,'disable',1) == 1);
danke 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 Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4981
  • Are we just self-replicating DNA?
Antw:[erledigt] OWDevice feature request
« Antwort #11 am: 27 August 2021, 09:29:36 »
Klar!

Kannst Du mir bitte wieder Deine getestete Version anhängen? Das minimiert das Fehlerpotential bei mir  :P

Viele 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: 15600
Antw:[erledigt] OWDevice feature request
« Antwort #12 am: 27 August 2021, 09:31:02 »
Zwischenfragen:
- warum "1" als default?
- warum ReadingsVal() bei nummerischem "Zwangsergebnis"? (=>ReadingsNum())
- warum überhaupt nummerisch?
- warum nicht gleich IsDisabled() aus fhem.pl? Das würde ggf. direkt auch "disabledForIntervals" erlauben, was sich aber mit dem Löschen des Timers beißt (solange das Attribut aber nicht zugelassen ist, dürfte es auch egal sein...). Jedenfalls wäre es dann von den syntaktischen Anforderungen an den Attributwert 1:1 mit anderen Modulen vergleichbar...
(- warum die Klammern bei "nachgelagertem if"? Da kann man die genausogut weglassen)
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 erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 567
Antw:[erledigt] OWDevice feature request
« Antwort #13 am: 27 August 2021, 09:41:23 »
Hi Beta-User!

ReadingsVal vs. ReadingsNum -> du hast natürlich recht!
Zitat
- warum überhaupt nummerisch?
- warum nicht gleich IsDisabled()
..disabled attr hat 0,1 als erlaubte werte, minimale Änderung an bestehendem code - der gehört Boris!
Das heutige Problem war ausschließlich im startup schlagend. (attr noch nicht verfügbar...)
l.g. erwin

edit: Readings(Val|Num) ist natürlich Blödsinn, mein Fehler, muss AttrVal heissen... Danke fürs anstupsen!
« Letzte Änderung: 27 August 2021, 10:15:02 von 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: 15600
Antw:[erledigt] OWDevice feature request
« Antwort #14 am: 27 August 2021, 09:50:26 »
disabled attr hat 0,1 als erlaubte werte, minimale Änderung an bestehendem code - der gehört Boris!
Jein: Das "Problem" ist, dass manche "Schlauberger" die cfg editieren oder ggf. über die Kommandozeile Werte setzen. Wenn dann der Modulcode nicht eine Validierung durchführt (?), kommt "Käse" raus, der schwer zu entdecken ist. Die Validierung kann man sich schenken, wenn man einfach nur prüft, ob "wahr" (also nicht 0 oder undef).

IsDisabled (an der richtigen Stelle, s.U.) hat den weiteren Vorteil, dass man "inactive" als state setzen könnte. (k.A., ob das zum sonstigen Modulkonzept paßt, nur eine Anmerkung).

Zitat
Das heutige Problem war ausschließlich im startup schlagend. (attr noch nicht verfügbar...)
Dann sollte man m.E. die eigentliche Initialisierung nach "$init_done" erledigen (InternalTimer-Aufruf), weil mAn. zu diesem Zeitpunkt auch kein ReadingsVal ein irgendwie sinnvolles Ergebnis bringt (statefile wird erst nach der cfg geladen).
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}