IODev Handling durch device

Begonnen von noansi, 22 April 2021, 19:16:57

Vorheriges Thema - Nächstes Thema

noansi

#45
Hallo Rudolf und andere interessierte Mitleser.

da es einen Blumenstrauß an IOs und IO Eigenschaften in fhem gibt, sehe ich spontan folgende Punkte, die das Framework auf standardisiertem Weg mit Systemfunktionen unterstützen kann:

- welche IOs sind registriert (IO Modul Unterstützung erforderlich)
- welche IOs für das Modul sind registriert (IO Modul Unterstützung erforderlich)
- ist das IO konfiguriert auf das Modul - oder schon von konträren Module allokiert (IO Modul Unterstützung erforderlich)
- ist das IO enabled/nutzbar (disabled/dummy...)
- ist das IO sendefähig (oder ist es ein listen only IO für das anfordernde Modul) (IO Modul Unterstützung erforderlich)
- ist das IO erreichbar (ggf. IO Modul Unterstützung erforderlich)
- besteht ein sonstiger Error (IO Modul Unterstützung erforderlich)
- besteht ein Overload Zustand (Pufferlimits, Funkkontingent ausgeschöpft) (IO Modul Unterstützung erforderlich)
- wieviel vom maximalen Sendekontingent (Funkkontingent) ist verfügbar (IO Modul Unterstützung erforderlich)

Es geht dabei um Standardmethoden, die ein Modul, welches mehrere mögliche IO Module nutzen kann, aufrufen kann, um die Informationen zu bekommen. Derzeit muss man die Informationen aus dem System/den Modulen/den IOs individuell extrahieren.
Das bedeutet natürlich auch, dass die IO Module entsprechend angepasst werden müssen, um die Informationen passend zu liefern. 00_CUL.pm ist mit dabei.

Hier https://forum.fhem.de/index.php/topic,120268.msg1160889.html#msg1160889 übrigens noch Verbesserungen an 00_CUL.pm auch als diff, wie in dem Thread entstanden.
Es verbessert das Timing für Folgesendemessages, die zuvor beim User zu früh gesendet wurden, außerdem das Message Logging für den HM Support.

Gruß, Ansgar.

martinp876

Hallo Ansgar,

das ist alles rightig, hört sich komplex an und wird am Ende vereinfacht sein.
Wir haben configState und operState (die Namen könnt ihr gerne anpassen)

Config State
Das Modul meldet den Config state an den Kernel -also alle Modultypen, welche es zu unterstützen gedenkt. Wird es auf einen Typ geprägt muss der Kernel informiert werden, die Liste wird upgedated.
=> ein IO kann mehrere Typen parallel unterstützen. Der IO-Modul entwickler muss die angebotenen Optionen natürlich erfüllen können
=> ein Dummy-modul liefert eine leere Liste (kann ja nix)
=> ein Modul kann anfragen, welche IOs möglich sind.
=> das Modul kann (muss) sich über Änderungen informieren lassen (können) - Kernel funktion.

Schön wäre, wenn sich ein Modul beim IO enrolen könnte - direkt oder über den Kernel, egal. Damit kann man sicherstellen, dass ein besetztes IO nicht gekapert wird. Es ist also möglich, dass mehrere Module enrolt sind, wenn das IO dies zulässt.

OperState:
=> Der Oper-State des Modul kann abgefragt werden. Das sollte direkt gehen - hier geht es um Performance.
=> bei Oper-state handelt es sich um dynamiche Änderungen jenseits der Configuration
Wenn das Enrolement genutzt wird informiert das IO das Modul, ansonsten kann man es abfragen (eine Standart-variable würden reichen).
Die states sind zu definieren
- operational|highLoad|noTransmition
noTransmission beinhaltelt alles, wenn das IO nicht senden wird. Der Grund ist egal, könnte sich aber schnell ändern
Alternativ kann man auch schlicht die Sendekapazität zurückgeben. Error entspricht "0% kapazität"
=> immer daran denken: Das Modul muss nicht über details informiert werden, das macht das IO schon selbst. Nur ein Wert welcher eine Entscheidung ermöglicht ist notwendig.

Wie du siehst und sicherlich weisst sind Interworking und Architektur zu definieren.
So kommen wir der Sache langsam näher.

Wieder einmal lege ich eine ModulInstanz nahe bspw eine "CUL_HM Entity".


Nebenbei: Wenn ihr alles so lasst wie es ist (nun, war) sind in CUL_HM schon genug "arbeite-herum" um die Misstände eingebaut. Entferne ich gerne, aber nur wenn es ein sinnhaltiges Konzept gibt



noansi

Hallo Martin,

Zitatdas ist alles rightig, hört sich komplex an und wird am Ende vereinfacht sein.
Das ist nur ein Versuch, etwas abzugrenzen, damit sich hoffentlich auch andere Entwickler ein Stück weit darin wieder finden.
Schließlich würden Änderungen in Richtung von Standardmethoden einige betreffen, nicht nur Rudolf als Bereitsteller von Interfaces.

Nur CUL_HM spezifisch macht es wenig Sinn und es wird sich dazu sicherlich kein Konsens finden lassen.

Deine Aufstellung der letzten Beiträge macht aber schon deutlich, was CUL_HM im Optimalfall brauchen könnte.

Wäre schön, wenn andere ähnliches aus ihrer Sicht darlegen würden, was gebraucht wird/werden kann oder derzeit stört (und damit meine ich nicht das Reading IODev, das ist zunächst nur Gewohnheitssache und ein zusätzliches Feature zur Wiederherstellung eines letzten Zustandes bei Neustart. Braucht auch nicht jedes Modul, aber auch nicht jedes Modul braucht z.B. ein Write).

Sonst bleibt es sicherlich beim Stand, der von der Basis her auf Rudolfs Module zugeschnitten ist.
Der Baukasten ist ja auch nicht schlecht, nur einige sehr ähnliche und öfter gebrauchte Legosteine muss ein Modul überall zusammensuchen und kann sie hoffentlich dauerhaft in der einmal vorgefunden Form weiter benutzen.

Was mir auch nicht so gefällt, ist Kommandos an das IO-device (das logische in FHEM) ebenfalls über das Write Interface zu realisieren.
Da sammelt sich mit der Zeit ein Christbaum an Abfragen im IO-Modul (insbesondere bei Multifunktions-IOs) an, die das Senden von Nutzinformation ausbremsen bzw. jedes mal Zeit kosten. Dafür halte ich es für sinnvoll ein zusätzliches IOCommand Funktionsinterface als Alternative zu etablieren.

Gruß, Ansgar.

justme1968

beim überfliegen des thread verstehe ich denn sinn des iodev reading nicht so ganz.

und zu attributen: ja. attribute sind für den anwender. aber ich bin der meinung das ein modul durchaus die möglichkeit haben soll am anfang attribute sinnvoll vorzubelegen und dem anwender einen hinweis über die möglichkeiten zu geben. wenn der anwender ein attribut ein mal gesetzt oder geändert hat darf ein modul nicht mehr 'dazwischen pfuschen'. schade ist hier das es keine möglichkeit gibt zwischen nicht gesetztem und leerem attribut zu unterscheiden.

wenn es dinge gibt die ein modul sich selber über einen neustart 'merken' muss sollte es das in den unsichtbaren .readings tun. wenn es als reading sichtbar ist verführt das nur dazu mit setrading zu spielen.

dinge die nur zur laufzeit relevant sind wären dann in den internals aufgehoben.

das wäre dann ein iodev attribut das sinnvoll vorbelegt werden kann vom modul, das ein anwender dann ändern kann und das dann geändert bleibt. in iodev könnte auch eine (priorisiere) liste stehen. das aktuell tatsächlich verwendete iodev wäre dann im internal sichtbar. ein modul das sich zwingen sein iodev selber merken muss und dem user keine änderung erlaubt würde ein .iodev reading verwenden.

zu keiner zeit taucht ein iodev reading auf das nur zu zweideutigkeiten führt.

in fhem ganz allgemein mehrerer iodevs im iodev attribut ablegen und verwenden zu können wäre schön der als modul spezifische sonder wege.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

noansi

#49
Hallo Andre,

Zitatbeim überfliegen des thread verstehe ich denn sinn des iodev reading nicht so ganz.
Wenn der User das Attribut IODev löscht, dann kann ein Automatismus darin den letzten Zuweisungsstand ablegen, der beim nächsten Start denn wiederhergestellt werden kann.
So lange das Attribut existiert, hat das Attribut die Macht, so hat es Rudolf festgelegt.

Gruß, Ansgar.

justme1968

das klingt nach etwas internem und nach etwas das unsichtbar sein sollte also ein reading mit punkt. oder noch besser ein attribut mit punkt. es sollte jedenfalls nicht sichtbar sein.

andererseits: wenn ein anwender etwas löscht dann hat er das doch mit absicht gemacht und es sollte nicht hinter seinem rücken wieder geändert werden. andere attribute werden ja auch nicht gesichert und nach dem löschen wieder repariert. das gleiche argument würde ja auch für readings gelten und die werden nach dem löschen nicht 'repariert'. oder ist der nächste schritte dann ein backup vom backup reading?

was ist wenn der anwender durch das löschen erreichen möchte das das system automatisch neu nach einem passenden iodev sucht und nicht das alte wieder herstellt?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

noansi

Hallo Andre,

ob mit oder ohne Punkt ist eigentlich egal, denn jeder kann sich auch die versteckten Daten sichtbar machen.

Zitatwenn ein anwender etwas löscht dann hat er das doch mit absicht gemacht und es sollte nicht hinter seinem rücken wieder geändert werden.
Zitatwas ist wenn der anwender durch das löschen erreichen möchte das das system automatisch neu nach einem passenden iodev sucht und nicht das alte wieder herstellt?
Wenn der Anwender sich so viel Systemverständniss angeeignet hat, dass er den Zusammenhang versteht, dann ist es dem Anwender ein leichtes, auch noch das Reading zu löschen.  ;)

Zitatandere attribute werden ja auch nicht gesichert und nach dem löschen wieder repariert.
Es geht auch nicht darum, das Attribut zu sichern, es geht darum, den letzten Zustand der IO Zuordnung über den FHEM Neustart zu erhalten und der steht im Reading.
Attr IODev == Reading IODev -> Attr == Reading IODev wird zu Internal IODev nach FHEM Neustart (effektiv)
Attr NULL != Reading IODev -> Reading IODev wird zu Internal IODev nach FHEM Neustart
Attr NULL && Reading NULL -> Neuzuordnungsversuch seitens FHEM bei Neustart (konkret, letztes definierte geeignete IO-device aus der config, das nicht disabled ist)

Attr NULL während des FHEM Betriebs -> Modulautomatik kann ein anderes IODev wählen, so Rudolfs Vorstellung
Attr IODev gesetzt während des FHEM Betriebs -> Modulautomatik soll durch Attribut überstimmt werden

Gruß, Ansgar.

justme1968

ah. ok. die zusammenfassung ist hilfreich.

es klingt für mich aber immer noch eher nach einem versteckten reading. oder besser verstecktem attribut. es sollte nicht sichtbar sein. iodev enthält ein oder mehrere einträge, .iodev enthält das aktuell tatsächlich ausgewählte damit es beim neustart nicht verloren geht. das iodev internal enhält sichtbar das aktuell relevante iodev.

natürlich kann ein anwender im prinzip alles löschen. verstecke readings oder attribute sieht er aber erst al nicht. auch nicht per list. es ist also nicht 'mal so' passiert.

warum das letzte iodev zu verwenden besser ist als neu zu suchen ist mit aber nicht klar. durch den neustart kann sich ja alles mögliche geändert haben. vielleicht war ja sogar fas genau der sinn des neustarts.

vielleicht kommt das aber auch von der arbeitsweise. mein fhem läuft monatelang ohne neustart durch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

noansi

#53
Hallo Andre,

da Du ja gerade raus gearbeitet hast, dass der User sowohl Attribut, als auch Reading löschen können muss, ist es schon sinnvoller, beide nicht zu verstecken. Zumindest sieht man dann, was man im ersten Anlauf eventuell vergessen hat...

Zitatwarum das letzte iodev zu verwenden besser ist als neu zu suchen ist mit aber nicht klar. durch den neustart kann sich ja alles mögliche geändert haben.
CUL_HM bietet dynamische IO-Zuweisung auf Basis des RSSI mit dem das jeweilige device beim jeweiligen IO empfangen wird.
Die dabei entstehende Zuweisung ist somit umgebungsabhängig, bei den meisten devices aber doch eher statisch (ständiger Umbau des Heimes ist eher unüblichl).
D.h. die Zuordnung nach dem Neustart passt am ehesten zu der vor dem Neustart -> die Kommunikation sollte damit am besten wieder anlaufen.
Das würde auch für andere Funkprotokolle gelten, so sie eine solche empfangsqualitätsabhängige IO-Zuordnung in FHEM implementiert bekommen.
Auch Protokolle mit dynamischem Routing würden davon profitieren können.
Und dann gibt es noch einen Grund die IOs betreffend. Sofern der Zuordnungszustand im IO in nicht flüchtigem Speicher abgelegt ist, ist es für den IO Zuordnungsspeicher am schonendsten, die gleiche Einstellung weiter nutzen zu können, statt alle Zuordnungen neu einzurichten. Wie sich gerade heraus kristallisiert https://forum.fhem.de/index.php/topic,121139.msg1160404.html#msg1160404, gibt es nicht nur tsculfw (nur die mit wenig RAM) IOs mit Zuordnungsinformation in nichtflüchtigem Speicher.

Zitatvielleicht war ja sogar fas genau der sinn des neustarts.
Das statische (via Attribut) bleibt statisch, das dynamische wird entsprechend Optimierungsziel dynamisch verändert.
Wenn es um's Testen der Dynamik geht kann man auch
- vorher Reading (und Attribut IODev) löschen
- oder (bei CUL_HM) gleich mal eine andere Zuordnung via IOgrp Vorzugs-IO einstellen und dann schauen, wie sich das bei Rücknahme des Vorzugs-IO entwickelt, auch ohne Neustart

Gruß, Ansgar.

rudolfkoenig

Ich bin erstaunt ueber die heftigen Reaktionen als Konsequenz einer Aenderung, die mAn keine Auswirkungen haben sollte.
 
Zitates klingt für mich aber immer noch eher nach einem versteckten reading. oder besser verstecktem attribut.
IODev sollte nicht versteckt werden, man will schliesslich als Benutzer sehen, wie die automatische Zuordnung erfolgt ist, um Fehler korrigieren zu koennen. Und Reading ist es, weil es damit offensichtlich ist, dass es vom System gesetzt ist.

Zitatda es einen Blumenstrauß an IOs und IO Eigenschaften in fhem gibt, sehe ich spontan folgende Punkte, die das Framework auf standardisiertem Weg mit Systemfunktionen unterstützen kann:
Eigentlich(TM) muss ein Virtuelles IO Interface (wie es in HM implementiert ist) diese Aufgaben uebernehmen, und wie man es an dern "Problemen" (Erreichbarkeit, Sendezeit, Pufferoverflow) sieht, ist es stark Protokoll abhaengig.
Die Liste der verfuegbaren IO-Instanzen, und was diese gerade uenterstuetzen ist auch jetzt verfuegbar, eine Reservierung waere Sache der virtuellen Schicht (wenn ueberhaupt, manche Protokolle erfordern keine Reservierung, bei anderen ist Multi-IO nicht vorgesehen).

Ich bin nicht ueberzeugt, dass es sich lohnt dynamisches(!) Multi-IO Steuerung zu implementieren, sowohl wegen Aufwand fuer den Programmierer, Komplexitaet fuer den Benutzer und Haeufigkeit der fuer FHEM relevanten Faelle. Heisst nicht, dass ich was gegen Module habe, die das selbst implementieren, aber eine Generalisierung sehe ich z.Zt. nicht.

justme1968

als benutzer sieht man es aber doch in den internals. die sind dazu da informationen zu zeigen die nur zur laufzeit relevant sind.

so wie die attribute eigentlich dem anwender gehören gehören die readings eigentlich dem modul und die internals dem system.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

noansi

#56
Hallo Rudolf,

ZitatIch bin nicht ueberzeugt, dass es sich lohnt dynamisches(!) Multi-IO Steuerung zu implementieren
Kann ich verstehen, die Beiträge hier lassen bisher nur bei einem Modul Bedarfswünsche erkennen. Schade.

Deswegen vielleicht noch einmal etwas konkreter am Beispiel von einem SlowRf Sendemodul mit 'IODevList' Implementierung (und es unterstützt kein Attribut IODev mehr):

# erstes aktives IODev ermitteln
  my @ionames = split(/,/, AttrVal($name, 'IODevList', ''));
  my $ioh;
  foreach my $ioname (@ionames) {
    $ioh = $defs{$ioname};
    if (   defined($ioh)
        && defined($ioh->{STATE})
        && $ioh->{STATE} ne 'disconnected'
        && !IsDummy($ioname)) {
      AssignIoPort($hash, $ioname) if (   !defined($hash->{IODev})
                                       || ($hash->{IODev}->{NAME} ne $ioname));
      last if (   defined($hash->{IODev})
               && defined($hash->{IODev}->{CMDS})
               && ($hash->{IODev}->{CMDS} =~ m/G/) );
    }
  }

  return 'no IO available, adapt attribute IODevList' if (!defined($hash->{IODev}));


Da steckt viel Vorwissen drin, dass das in dem Fall spezielle IO Modul (hmm, eigentlich sind es zwei) eigentlich beantworten sollte.
Zunächst sollte schon der User das Vorwissen einbringen, dass das IO, welches er in das Attribut eingetragen hat, überhaupt ein 'G' fähiges Modul ist. Sonst ist nicht sicher, dass die Prüfungen nicht falsch positive Aussagen liefern. Eine Prüfung auf den Modultyp des IOs möchte ich vermeiden, das hält es offener für neue IO-Module.

Dann weiter im Code
1. Frage: ist das IO verfügbar?
Nach einigem Code Studium bin ich zur Erkenntniss gekommen, dass STATE eq disconnected diese Frage bei den in Frage kommenden IOs verneint. Ist das immer so? Bei allen IOs?

2. Frage: ist das IO irgendwie disabled?
Wiederum nach einigem Code Studium bin ich zur Erkenntnis gekommen, das IsDummy diese Frage hinreichend für die in Frage kommenden IOs beantwortet. Ist das immer so? Bei allen IOs? Gibt es noch andere nicht in Erwägung gezogene Attribute/Readings/Internals, die auf disabled schließen lassen?

3. Frage: unterstützt das IO den CULG 'G' Befehl?
Das ist in diesem Fall speziell auf die beiden (mir bekannten) IO Module zugeschnitten, die CULG unterstützen (sofern in die Firmware compiliert).
Die Frage wird durch die Dispatcherseitig verfügbare Information zu CULG Unterstützung durch das jeweilige IO nur bezüglich Empfang beantwortet. In diesem Fall falsch, da nur Senden unterstützt wird, nicht aber Empfang. Das CMDS Internal ist auch kein IO-Modulübergreifender Standard, denke ich. Außerdem kann ein unterstützendes anderes IO Modul auch ein anderes Befehlskürzel nutzen.

Wie schön wäre es, beim Kernel mit IsIOUseable($ioname) die erste und zweite Frage beantwortet zu bekommen. Das Kernel muß die Frage auch nicht zwingend selbst beantworten, sondern seinerseits beim IO die Anfrage stellen, weil es eine IsIOUseableFn Modulfunktion hat, die via Modul Initialize Funktion bekannt gemacht wird, damit das Kernel nicht alle speziellen Funktionsnamen der Module kennen muss.

Die dritte Frage wäre schön durch eine Kernel Funktion IOSendSupportForModule($ioname,$hash->{TYPE}) beantwortet und könnte als Zusatzinfo auch den zu nutzenden Befehlscode liefern. Wiederum seitens Kernel Anfrage beim IO.

Bei beiden Funktionen wäre eine Rückabe 'undef' eine sinnvolle Rückmeldung dafür, dass das IO die Anfragefunktion (noch) nicht unterstützt und auch das Kernel die Anfrage nicht beantworten kann.

In diesem Sinne ist meine Auflistung zu verstehen und damit auch nicht begrenzt auf dynamische MultiIO Unterstützung.

Gruß, Ansgar.

martinp876

Das die Diskussion so weit geht liegt daran, dass die Philosophie, wie mit Elementen umzugehen ist nicht niedergeschrieben ist sondern sich in den Köpfen, primär Rudis befinden. Startet man die Diskussion werden die Probleme sichtbar. Und das sind einige.

Ich bin zwar nicht einverstanden - und eure Felstlegung ist per eurer Definition  nicht haltbar, aber so verstehe ich eure Aussagen:
Dogmen:
D1) Attribute gehören dem User- Er kann einstellen was er will und bekommt recht
D2) Readings sind ... unklar. Der Programmierer kann sich hier Werte Merken - die kommen und gehen. Speichern und Recover ist deutlich schwächer
D3) Internals werden sowieso nicht gemerkt - was der einzige Unterschied zu Attributen ist. Ausnahme ist das Define.
D4) Dynamische IO Zuordnung braucht es nicht.


Stellungnahmen - Unsortiert:
D4) ist ok - im Allgemeinen. CUL_HM wird es machen (hat schon) - es ist ZWINGEND notwendig. Sollte sich Rudis Aussage auf den kernel beziehen ist das vollkommen ok. Würde ich auch so sehen. Es generell zu unterbinden ist nicht tragbar und werden/kann ich nicht unterstützen

D1) Ich sehe keine Notwendigkeit der starren Abgrenzung. Es hat schon seinen Sinn, dass Attribute beim Setzen geprüft werden. Der Modulschreiben kann bestimmte Werte ablehnen. Das geht bis dabin, dass einige Attribute vom User garnicht gesetzt werden können. Damit hat der User  hier auch nicht seinen Wunsch äussern dürfen - damit kann er es auch nicht einfordern.
2. Punkt: Attribute und deren Prüfung hängen von einander ab - FAKT! Rudi hat eingeführt (sehr gut!) dass Attribute je Entity erlaubt sein können. Das bedeutet, dass eine Entity einige Attribute manchmal unterstützt und manchmal nicht. Ich kennen jetzt die Beispiele nicht, wer das gebraucht hat - aber es kann ja nur sein, dass durch Einstellung eben attribute freigeschaltet werden und eliminiert werden. Damit ist es die Aufgabe!!! des Modulentwicklers dies konsistent zu halten. Das geht nur auf 2 Wegen: Entweder wird die Änderung verweigert, welche ein vorhandenes Attribut obsolet macht oder das obsolete Attribut wird gelöcht.
Ersteres geht nur, wenn der Anwender die Änderung initiiert. 2teres geht immer.
Obsoleten Attribute stehen lassen geht garnicht. Ein Reboot würde es sowieso löschen!
Sich in die Tasche lüge ist bspw:
Ein User stellt Attr IODev ein, fhem prüft (wie auch immer) ob es sich um ein gültiges IO handelt. => gut
Das IO wird gelöscht. Würde man das Attribut nun setzen, würde es verboten. Das ist also Quatsch. Entweder wird das Löschen verhindert oder das Attribut gelöscht. Oder das IO gegen ein gültiges ausgetauscht. Lässt man das Löschen (oder umbenennen ) eines IOs zu ist es Programmer-pflicht!!! die Attribute (bestmöglich) zu prüfen.
MD1) mein Dogma: wenn der Developer eine Prüfung beim Eintragen eines Attributs mache ist es SEINE Aufgabe, dies konsistent zu halten. Das Attribut muss eingeltich zu jedem Zeitpunkt der Prüfung genügen! Voll automatisch, best-möglich.
=> jetzt seid ihr dran.
Macht das CUL_HM? Nun ja, es gibt sicher Lücken. Bei einem "rename" bspw habe ich mich eingehängt und passe alles an, was ich identifizieren kann - innerhalb CUL_HM


D2) Readings werden nur schwach gespeichert. Das ist störend - aber gut. Um Konfigurationen zu speichern war es lange nicht stabil genug. Evtl. muss ich es noch einmal prüfen, ob es nun hinreichend ist. Mir sind hier schon einige Werte verloren gegangen - leider oft. Mein Vertrauen ist leider gering - aus Erfahrung.
Readings löschen... ist unbedingt notwendig. Readings stellen den Zustand der Entity dar. Es sollten(dürfen!!!!!!!) nur gültige und verlässliche Readings sichtbar sein. Die Liste der Beispiele ist endlos.
CUL_HM: wenn eine Entity gepeert ist sind register-readings vorhanden. Wird das peering entfernt sind diese nicht mehr vorhanden. Selbstverständlich muss ich diese Löschen. Die sind schliesslich WEG!
YAMAHA_NP: hier schalte ich die modi ständig um: Radio, Server, CD. Ich sehe Senderlisten, DAB+ Infos,... je nach Source. NATÜRLICH ist es meine Aufgabe, ungültige Readings zu löschen. Die sind ungültig und das ist bekannt.
=> nichts schlechter als falsche Information. Besser keine Information

Anderes Thema: ihr habe auch über Sichtbarkeit von Parametern gesprochen. FHEM hat hier eine sehr schwache Implementierung - mehr hat Rudi mir nicht zugestanden.
Statements von mir
+ natürlich darf der User alles sehen
+ das einfache Frontent sollte in Sachen Sichtbarkeit einstellbar sein. Typisch will ich nur wenig sehen, manchmal alles. Die Listen aller Readings (oder auch Attribute ) ist unleserlich.
? Frage:Ist die "einfache" native Darstellung als Programmer-darstellung gedacht? Dann ist es egal, was dargestellt wird. Ist es als primary-User-Frontend gedacht gebe ich eine schlechte Note. Das macht keinen Spass, wenn man nicht nachbessert!
+ In CUL_HM habe ich ein "get list" eingebaut - das sollte Standart sein. Hier kann der User schnell und einfach alle (ALLE) Parameter ansehen. Über die Option "normal/full" kann man hidden parameter darstellen oder nicht.
+ Sichtbarkeit  von Parametern sollte der Übersichtlichkeit der Darstellung dienen. Diese sollte per entity einstellbar/umschaltbar sein - schnell und einfach.
+ CUL_HM hat einen mAn tragbaren, wenn auch sub-optimalen und programmtechnisch leider komplexen Weg implementiert, die Sichtbarkeit von Readings (primär Registern) zu steuern. Es nähert sich für meine Ansprüche eine User-Frontend an. Wirklich freundlich ist es an allen Ecken nicht, intern wie extern. Rudi hat damit allerdings den kernel einfach halten können.


Ich mache hier einmal ein schluss-statement:
Hier sind einige Themen angesprochen welche von einander unabhängig sind. Faktisch ist es ein Durcheinander und die Themen sollten eines nach dem Anderen besprochen werden. Die aktuellen Aussagen ALLER beteiligten geht nur von Sunny-Day Szenarien aus - Problemfälle werden noch nicht einmal angesprochen. So kann es nicht funktionieren.
Die Definition von Attribut sollte einmal KNALLHART! definiert werden, diskutiert und alle (ALLE) Konsequenzen besprochen werden. Insbesondere Problemfälle!!!
Was macht es für Sinn über die Nutzung von Attr IODev zu sprechen, wenn Attr selbst nicht auch für Regentage definiert ist und in sich zusammenfällt. Man muss vorne anfangen.

Typisch kenne ich es nicht, dass Rudi meine Eingaben wirklich diskutiert. Wenn etwas nicht mit einem Einwurf und einer Antwort erledigt ist wird es ignoriert.  Rudi sind jetzt schon die Mendungen wieder zu lang und ausschweifend, wir er hat durchblicken lassen.

Ich finde es schade wie schon häufiger, werde mich aber nicht daran aufarbeiten und bleiben bei meiner Aussage Eingangs: Gerne Kommentieren ich, werde mir das Ergebnis ansehen und CUL_HM auf Basis der Ergebnisse CUL_HM weiterhin Userfreundlich und Nutzbar halten.




noansi

#58
Hallo Martin und interessierte Mitleser,

Zitateure Felstlegung ist per eurer Definition
? wer ist eure

Die Vorstellung von Rudolf ist in fhem.pl bezüglich Attributen in CommandAttr($$) festgehalten:

ZitatD1) Attribute gehören dem User- Er kann einstellen was er will und bekommt recht
    $ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, $attrVal);
    delete($defs{$sdev}->{CL});
    if($ret) {
      push @rets, $ret;
      next;
    }

    $attr{$sdev}{$attrName} = $attrVal;

D.h. der Modulprogrammierer kann den Attributwert nicht verändern, aber eine Fehlerrückmeldung geben, wenn er ein Problem erkennt und damit verhindern, dass er gesetzt wird.
Das war der Aufhänger des Threads und Rudolf beharrt, aus durchaus nachvollziehbaren Gründen, auf diesem System. Ohne Ausnahme (was ich nicht nachvollziehen, aber aktzeptieren kann).

Während des FHEM Starts gibt es dabei nur das Problem, dass noch nicht alle devices definiert sind und nicht alle Attribute und noch gar keine Readings bereit stehen. D.h. sollte es da Abhängigkeiten geben, dann kann eine Fehlerrückmeldung nicht sinnvoll während des FHEM Inits gegeben werden.
Also kann der Modulprogrammierer nur nach dem FHEM Init eine Prüfung vornehmen und ggf. das Attribut (tja, hier wird dann zwar alles möglich, aber) nicht auf den neuen Wert setzen (so entspricht es der fhem.pl Logik).
Um sich als Programmierer diese Logik aufzuwingen, wäre es eine Möglichkeit, das jeweilige Attribut neu über die Systemfunktion zu setzen und die Prüfungen innerhalb der Modul Attributsfunktion abhängig vom fhem Initzustand auszuführen. Wenn der alte Attributwert schon Käse ist, dann muss der Modulprogrammierer das anderweitig abfangen.

Ohne Ausnahme? Im Grunde nicht ganz, denn in CommandAttr gibt es davor auch noch diese Codeteile:
    if($opt{a} && $attr{$sdev} && $attr{$sdev}{$attrName}) {
      $attrVal = $attr{$sdev}{$attrName} .
                        ($attrVal =~ m/^,/ ? $attrVal : " $attrVal");
    }
    if($opt{r} && $attr{$sdev} && $attr{$sdev}{$attrName}) {
      my $v = $attr{$sdev}{$attrName};
      $v =~ s/\b$attrVal\b//;
      $attrVal = $v;
    }

    if($attrName eq 'disable' && $attrVal eq 'toggle') {
       $attrVal = IsDisabled($sdev) ? 0 : 1;
    }
...
    if($fhemdebug && $sdev eq "global") {
      $attrVal = "-" if($attrName eq "logfile");
      $attrVal = 5   if($attrName eq "verbose");
    }

Warum dem Kernel Modifikationen des Attributwertes erlaubt sind aber dem Modul nicht ... . Ok steckt ein Nutzerwille dahinter..., war einfach umzusetzen, egal, Schwamm drüber.

Dafür gibt es jetzt eine alternative Möglichkeit, einen IODev Ist-Zustand über den FHEM Neustart zu erhalten (so der User-Wille dem nicht widerspricht) und das hilft schon mal beim ursprünglichen Problem.

ZitatD2) ... Speichern und Recover ist deutlich schwächer
Ja, vier Gründe fallen mir ein, warum dies passiert.
1. Der User löscht das Reading
2. Das Modul löscht das Reading
3. Zugriffsrechte im Filesystem verhindern das Speichern der Sicherungsdaten
4. Bugs im Modul, die einen Modulstart verhindern -> Readings verloren, so denn keine Sicherungskopie der Readingdaten vor einem regulären Stop von fhem angelegt wird.
@Rudolf: hier wäre es ein willkommenes Feature, beim Schreiben der Readingdaten vorher automatisch ein Backup zu erzeugen. Z.B. alte fhem.save in fhem.save.last umbennen und dann neue fhem.save schreiben.

Gruß, Ansgar.

rudolfkoenig

Zitat@Rudolf: hier wäre es ein willkommenes Feature, beim Schreiben der Readingdaten vorher automatisch ein Backup zu erzeugen. Z.B. alte fhem.save in fhem.save.last umbennen und dann neue fhem.save schreiben.
Beim vom Benutzer ausgeloesten Schreiben der Konfiguration wird per Voreinstellung auch eine Sicherung von fhem.save erzeugt.
fhem.save.last kann ich einbauen, allerdings sehe ich z.Zt. genausoviele neue Probleme wegen Erstellen eines weiteren Backups, wie es diese loest. Ich lass mich aber gerne umstimmen.