Autor Thema: Define mit parameter? Warum keine Attribute z.b. bei at oder notify  (Gelesen 2553 mal)

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3752
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #30 am: 07 November 2021, 10:57:20 »
readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

Aktuell funktioniert  im Dummy nur die Kombination readingList und seLlist, ohne readingList wäre es dann eine neue Funktionalität.

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20868
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #31 am: 07 November 2021, 11:11:05 »
Zitat
Erschreckend, dass Module wie LightScene ihren NOTIFYDEF nicht setzen

nein. ich finde es nicht erschreckend. zum einen ist LightScene sehr viel älter als NOTIFYDEF und zum anderen hat LightScene einige eigene Optimierungen eingebaut die nicht unbedingt schlechter als NOTIFYDEF sind. wenn z.b. kein browser offen ist wird die NotifyFn sehr früh direkt wieder verlassen.

im übrigen waren für NOTIFYDEF auch einige runden nötig weil die ersten versionen ohne cache zu langsam waren.

das heisst nicht das sich das ganze nicht noch optimieren lässt, aber zumindest habe ich bisher noch keine meldung gesehen das LightScene tatsächliche performance probleme hat. ganz so schlimm ist es also wohl nicht.

ich glaube es gibt stellen in fhem an denen eine optimierung deutlich mehr bringt. by the way: hast du mal gemessen wie die performance unterschiede zwischen vielen kleinen notifys für jede der 12 tasten im vergleich zu einer version mit einem notify für alle tasten und anschließendervVerzweigung sind?
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24686
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #32 am: 07 November 2021, 11:13:44 »
readingList ist in dummy notwendig, damit die set Argumente nicht im state landen.
Da ich nicht vorhabe, im notify state zu aendern, ist es da nicht notwendig.

Offline martinp876

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11042
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #33 am: 07 November 2021, 15:52:40 »
 nun - nachdem mein Threat gekapert wurde mache ich noch einen Versuch.

Angesprochen hatte ich eigentlich die (natürlich aus meiner Sicht) unpassende Defintion bspw von Notify. Weiter sehe ich nicht, dass dies für den User - insbesondere bei der aktuellen Doku-Lage wirklich einfacher ist. Es ist möglich, das aktuelle notify auch clever zu nutzen. Unterstützt wird es nicht, im Gegenteil.
Schade, dass sich schon alle arrangiert haben und somit zufrieden sind.
Stattdessen wird über readingList diskutiert oder setList. Konkret habe ich hierzu keine Meinung, da mich er Konkrekte Implementierungsplan, Syntax uns Semantik interessert. Scheinen alle zu wissen, ok - aber schon wieder ein abdriften.

Wie ich mit ein Notify vorstelle kann man im Anhang sehen. Es ist noch tuning notwendig....
Den WebInterface Wizzard müsste ich noch löschen. Doku ist auch noch nicht enthalten...
Ich werden das nicht veröffentlichen... Wäre aber schön, wenn das Ürsprüngliche Thema wieder betrachtet wird.
Erinnerung: keine parameter sondern Attribute
Bewertung unter ignorieren der aktuellen Implementierung - wie würde man es jetzt erstellen (grüne Wiese!). Erst danach: Wie kommt man da hin.

Btw: Mehrere Readings im Bulk zu setzen ist nicht meine Problem. Mache ich regelmäßig mit Userreadings.

Wäre schön, wenn wenigstens käme: das wollen wir nicht, weil inkonsistent.
Aber wer glaubt schon an den Weihnachtsmann :(

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24686
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #34 am: 07 November 2021, 17:09:39 »
Zitat
Wäre schön, wenn wenigstens käme: das wollen wir nicht, weil inkonsistent.
Ich will das nicht, weil mAn der Nutzen in keinen sinvollen Verhaeltnis zum Aufwand ist.

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2313
  • FHEMinist
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #35 am: 13 November 2021, 13:59:38 »
Ich bin nicht abgeneigt, setList in notify einzubauen, falls auch Andere dafuer sind.
readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

Hallo Rudi,

Ich würde gerne nochmal auf diesen "Nebenkriegsschauplatz" aus der vorangegangenen Diskussion zurückkommen.

Das würde u.a. den Umweg über sertreading, sowie wahrscheinlich diverse userattr ersparen und natürlich die Eingabe vereinfachen

Was mir dabei allerdings zum Glück noch fehlen würde wäre, dass notify auch stateFormat unterstützt. Bisher ist zwar devStateIcon vorhanden, aber der Vollständigkeit halber sollte m.E. auch stateFormat dabei sein.

Mit dieser Kombination könnte ich zumindest bei mir eine ganze Menge dummy-Devices und teilw. readingsProxy los werden.

Vielleicht magst du deiner Unabgeneigtheit bei Gelegenheit noch nachgeben?

Eventuell fände das auch noch der eine oder andere gut, dann kann er das ja gerne noch kund tun.
(Müsste man ggf. mal noch außerhalb des Developer-Bereichs abfragen?)

gb#


Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24686
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #36 am: 13 November 2021, 14:13:50 »
Ich warte nur auf Meldungen, hier: https://forum.fhem.de/index.php/topic,123956 gibt es schon eine Umfrage, bisher ohne Feedback.
Diese Diskussion sollte auch da weitergefuehrt werden.
Bei zwei Leuten bin ich ja schon fast soweit, was zu tun :)

Offline martinp876

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11042
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #37 am: 28 November 2021, 09:54:08 »
Ich habe notify nun einmal nach meinem dafürhalten umgebaut. Ist aktuell nicht aufwärts kompatibel - kann man aber machen. Dennoch sehe ich hier einige dinge realisiert welche Rudi sowieso wieder ablehnen wird :( . Alles in allem sind hier m.E. einige Aspekte realisiert welche ich mir wünschen würden - unabhängig von notify. JEDES! module sollte nach diesen Grundsätzen arbeiten - oder abgewandelt, klar. Aber Grundsätze eben.
Das schränkt die Freiheit der Programmierer ein - was m.E. kein Schaden sein muss.
Und eigentlich ist es nicht so weit weg von allem - nur eben STRICT! Wird nicht gerne gesehen hier.
Grundsätze sein
1) CPU performance @ operations
2) memory performance
3) CPU performance @ config
4) WISIWIG

Die Kommandos werden definiert auf Module ebene und/oder auf entity Ebene. Vielen Modulen wird die Modulebene reichen (notify bspw) - einigen nicht (CUL_HM,...).
Jedes Kommando wird spezifiziert - möglichst komplett mit Parametern.
Der Parser "ntf_cmdParser" prüft die Kommandos und deren Parameter nach Anzahl und Inhalt gemäß Spec. Default Parameter werden automatich eingefügt.
=> beim Abarbeiten der Kommandos kann sich der Programierer darauf verlassen, dass mandatory params auch vorhanden sind
=> der User kann mit "get cmdList" sehen, was programmiert ist - direkt. Nicht von einer Kopie sondern im Orginal
=> Defaults werden gesetzt - automatisch
=> die replies bei fehleingabe sind standartisiert
>>> die Funktion ntf_cmdParser ist generisch und kann so für jedes Modul eingesetzt werden. Eigentlich sollte es eine kernal funktion sein. Eigentlich sollte sie automatisch ausgeführt werden.

Ein starres System? nein.
- Kommandos können auf Modul-ebene on-the-fly nachgereicht/modufiziert werden - ok. der Programmer muss ein re-eval starten.
  eingebaut haben ich zum testen alle Kommandos mit "tst.*". Hier kann der geneigte Programmer einmal neue Kommandos einpflegen und löschen. Diese Funktionen sind natürlich nicht relevant für notify, nur zur Evaluierung.
- Parameter mit "Dynamic Option List" werden automatisch gearbeitet. Sowohl in drop-down listen alsauch im parser

=> der Anwender bekommt nun konsistente Eingabe - bspw wenn ein Kommando keinen Parameter hat wird auch KONSEQUENT! noArg eingetragen. Eine Schlamperei welche ich schon häufig gesehen habe.

=> die Performance  des beliebten und wichtigen Kommandos "set xx ?" und "get xx ?" liegt deutlich unter 1ms!

Eingebaut sind set, get und auch attr. Leider ist das Handling bei attr abweichend - nun ja. Dennoch habe ich den selben Algorithmus eingebaut.
Die Funktion "ntf_AttrCheck" ist hier notwendig - siehe Implementierung. Hier wird auch konsequent durchgesetzt, dass nur gültige Attribute zugelassen sind. Der User muss also erst UserAttribute definieren bevor er sie nutzen kann. Wenn er UserAttribute löscht mussen auch die Attribute gelöscht werden. Eine hässliche Lücke in fhem welche schon seit beginn besteht. Das handling der userAttr habe ich noch nicht drin werde ich in ntf aber noch machen.
==> es kann nicht sein, dass attribute eingetragen werden können welche eine Reboot nach Save nicht überleben!


So - nun noch eine etwas weichere Forderung - notification/rename/define/... . Notifications von "global" sind - im Gegensatz zu allen anderen  - Config-notifications. Alle anderen sind "operational-notifications".
Jedes Modul  - übergreifend - Konfigurationsänderungen berücksichtigen. Das ist eigentlich standard. fhem hinkt hier weit hinterher.
Beispiel: Ich habe ein Notify welches auf  die Entity "LichtWohnLinks" triggert. Mache ich ein Rename von LichtWohnLinks nach LichtWohnraumLinks muss das notify automatisch! angepasst werden. Das trifft natürlich nicht auf "LichtWohn.*" zu. Alle nicht-unique entites werden nicht angefasst.


Fürs erste einmal gut. Zum Eigentlichen Notify nehme ich getrennt Stellung, kommt noch.

=> ich werde nur noch so arbeiten, auch wenn das Konzept -  wie vorhersehbar - abgelehnt wird.






Offline martinp876

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11042
Antw:Define mit parameter? Warum keine Attribute z.b. bei at oder notify
« Antwort #38 am: 28 November 2021, 11:12:28 »
so, nun abgegrenzt die (einseitige) Diskussion zum Notify.
das "ntf" Spielzeug zeigt, wie es bei mir aussehen würde. Wenn "notify" nicht auf einen angemessenen Stand gebracht wird werde ich wohl mit meiner Version arbeiten. Natürlich ungefährlich - sieht ja keiner.
Was macht den Unterschied:

Pseudo -attribute in der Kommandozeile sind ein no-go. Nicht diskutable und nur durch historische Hintergründe zu rechtfertigen. Dieser Tage geht es garnicht.
Aus meiner Sicht schwierige Trennung des "trigger-Filter" nach trigger-device und trigger-event. Das kann man deutlich sauberer machen - für mich ist das ein schwer zu behandender Klumpen.
Wenn man es stringent macht kann man auch das enrolen beim Notify-filter wasserdicht UND flexibel gestalten. Einfaches Beispiel ist:
- triggerDevice ist ein regex (oder device-spec) wie la.* oder "attr room schlafzimmer"
- die betreffenden Devices werden identifizert und angemeldet
- bei einer config-Änderung (rename, define, delete, attr) werden die Devices neu gesucht und enroled
=> eigentlich nichts besonderes, so muss das.

ich habe 2 Optionen zur Trigger-erkennung vorgesehen - combined und getrennt nach triggerName und triggerEvent

Bei Trigger-combined kann man über ein Kommando neue trigger addieren oder alte entfernen. Es ist KEIN fancy web-interface notwendig.
=> man sollte erst versuchen, die Funktionen mit Bordmitteln zu lösen bevor man extra-frontends einbaut. Aus meiner Sicht ist das frontend-addon schlicht unnötig.

Falls Rudi mit den Argument kommt, attribute darf man nicht verändern müsste ich die Augen verdrehen. Das Define wird aktuell manipuliert - auf seltsame weise. Bei mit klappt es nicht, da es nur bei einigen wenigen Formen der Trigger-filter klappt.
Nein, die aktuelle Implementierung halte ich für kompliziert, unfelxibel und auch noch unschön.

Selbstverständlich werden in den Readings wesentliche daten automaisch angezeigt (eigentlich eine Selbstverständlichkeit). So ist das letzte triggernde Device als auch das event zu sehen. m.E. immer sinnvoll und auch extrem hilfreich beim Einrichten und Testen.

Gets waren bisher wohl auch verpönt. Ein get trgFilter zeigt mir, welche events von welchem Device mir dieses Notify auslösen.
"shEnroled" könnte man weglassen, bei mir bleibt es noch.

Was ich noch nicht bearbeitet habe ist, die probably assiciated list auf Stand zu bingen. Warum ich das internal "NOTIFYDEV" permannent brauche ist mir unklar - insbesonderen wenn die Liste lang wird stört mich der Eintrag mehr , als er nutzt. Hier könnte man zumindest smart abkürzen.
=> ein standard-get ala shEnroled ist deutlich besser, da sortiert und formatiert

Ach ja, neben den gets sind die "get list" und "get cmdList" eigentlich kernal-kommandos. Die sollten immer da sein. "get  notifyEnroled"  würde dazu passen.

Alles zusammen ist das meine beta-Version. Sicher nicht bug-frei und es werden mir noch Verbesserungen einfallen.

Das bestehende Notify auf einen "Modernen" Stand zu konvertieren ist mit Sicherheit möglich - wenn man will

Ich gehe davon aus, dass der Vorschlag den üblichen Weg meiner Vorschläge folgt. Damit werde ich mich wohl alles auf meine "ntf" umstellen. Notify ist machbar aber nicht tragbar für mich.

Und noch einmal - die seltsamen sonder-kommandos "tst.*" sind nur zum Ausprobieren für programmierer - mit notify habe sie nichts zu tun.
Frohe Weihnachten.