fhem 4 Nerds or users?

Begonnen von martinp876, 02 Oktober 2022, 08:52:11

Vorheriges Thema - Nächstes Thema

Beta-User

Nur mal kurz:
- "Weichzeichnen" kann man auch mit passenden Einstellungen für "event-on-change-reading", dazu braucht man nichts doppeln (mAn. ist Doppelung genau der falsche Weg!).
- Start- und Endwerte (außerhalb des eigentlichen Zeitrahmens bekannte Reading-Werte) für SVG kann logProxy bereitstellen
- "Muster" für "kopierwillige User" könnte u.a. auch "archetype" bereitstellen (das ist ähnlich (!) wie deine m.E. überkomplexe "post-init"-config!) (Es gibt dazu einen support-Thread, da findest du auch ein Beispiel für CUL_HM-Heizungs-Geräte, das hilft dir vielleicht zu verstehen, was es tut)

Das sind alles eher (aus Einsteigersicht) "unerklärte" Ansätze für den jeweiligen Anwendungsfall, also "nerd-typisch". Vielleicht sollte man checken, ob die Ansätze "richtig" sind, und wenn ja kann man  versuchen,
a) das "userfreundlicher" zu erklären bzw. die Leute erst mal dahin führen, dass sie es "einfach machen" (ähnlich wie attrTemplate bei MQTT2_DEVICE), und
b) die tools ggf. zu verbessern bzw. die damit gezeigten "Musterlösungen".

Alles "auf den Kopf" stellen zu wollen (und sich (mit DBLog, mehr oder weniger) genau ein Modul rauszupicken (!)) ist m.E. in der Entwicklergemeinde eher nicht vermittelbar.

Just my2ct.

Zitat von: CoolTux am 12 November 2022, 08:09:26
Ansonsten empfinde ich die meisten Deiner Anmerkungen hier als wirklich Hilfreich und man merkt das Du Dir hier echt Gedanken gemacht hast. Über einen längeren Zeitraum.
Dem kann ich im Übrigen nur zustimmen!
Meine Anmerkung möge bitte nicht als "geht nicht"-Kritik verstanden sein, es geht eher um den Weg...
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876

Hi,
danke für das feedback.
CoolTux
1) ich lasse das immer dem Moderator zu kommen. Ich wollte shon viel weiter sein - werde aber jetzt doch erst meine Installation zu DBLog auf einen Stand bringen, welcher m.E. sinnvoll ist. Hierbei werde ich mir Werkzeuge Entwickeln ( wohl ein muDbMgmt (my Utility Database management - Modul) welches dann ein Frontend für User bietet - so wie ich es mir vorstellen. Das ist m.E. der beste Weg, dem Entwickler darzulegen, was ich meine. Ich komme bei DBlog von einem Detail zum nächsten. Am Ende muss es aber ein Gesamtkomzept geben - möglichst einfach und gleichförmig. Das Konzept ist klar, die Umsetzung dauert.

Beta-User
1) mir nicht klar, wie ich mit event-on-change-readings "weichzeichnen" kann. Doppelt ist klar der falsche Weg (daher biete ich meine Anpassungen nur an und veröffentliche keine Konkurenz-Module). Event-on-change-reading .* ist und bleibt für mich das A und O einer Datenerfassung. ALLES, was damit nicht geht ist einfach schlecht implementiert - m.E. Bastelwerk. Harte Aussage, ok. Bei mir geht es.
=> Wie kann ich mit Event-on-change-readings nur dann Events erzeugen, wenn sich die Temperatur um +-0,3° ändert? Tip würde mich interessieren.
=> mein Weichzeichnen ist ein level mehr zu event-on-change-readings.* . Wenn ich erst einmal optimiere, dann möglichst umfassend.
2) Start und Ende... wie geht das?
Die Aufgabe ist: meine desired-temp ändert sich um 7:00, 15:00, 20:00. In der 2-Tage Grafik beginnt die Linie also nicht um 00:00:00 sondern um 07:00:00. Sie endet um 20:00, nicht um 22:31 wenn ich den Graphen ansehe.
Den letzten Wert vor dem Darstellungszeitraum kann die Datenbank easy zu verfügung stellen. Ich haben die Anpassung schon vorbereitet. Die estrapulation auf das Ende es Darstellungszeitraums man auch einfach machen - das kann die DB oder auch SVG. Ich würdas das extrapulieren der Werte ich beide Richtungen an einer Stelle machen - also in der DB. Da ist dann konsequent
=> welche Lösung gibt es schon jetzt?
So erhalte ich den letzten Wert vor Zeitraum aus der DB
(SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1
                               AND DEVICE = 'haLnge_Clima'
                               AND READING = 'measured-tempS'
                               AND TIMESTAMP < STR_TO_DATE('2022-11-11 00:00:00', '%Y-%m-%d %H:%i:%s')
                               ORDER BY TIMESTAMP DESC
                               limit 1)
union
(SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1
                               AND DEVICE = 'haLnge_Clima'
                               AND READING = 'measured-tempS'
                               AND TIMESTAMP >= STR_TO_DATE('2022-11-11 00:00:00', '%Y-%m-%d %H:%i:%s')
                               AND TIMESTAMP <= STR_TO_DATE('2022-11-13 00:00:00', '%Y-%m-%d %H:%i:%s')
                               ORDER BY TIMESTAMP);

Ich würde die Auswirkungen noch testen und ggf den Timestamp frisieren - auch für den Endwert.

3) meine Einlassungen hier sind für Entwickler, nachzudenken, on sie uerfreundlich oder für Nerds das Frontend gestalten. Ich versuche es anhand von Beispielen darzustellen - und mein Weg ist definitiv nicht der einzige. Nur ist das Angebotene in manchen Fällen einfach nicht das, was ich mir erwarte. Und ganz klar - manche sind super!!!

Zu DBlog und meinen Recherchen. Eigentlich wollte ich nicht so tief eintauchen...
Ich prüfe gerade meine Einstellungen und haben geprüft, was so geloggt wird. Hierzu einmal verbose 5 gesetzt.
=> DBlog lässt sich tatsächlich über alle Events informieren. Das sollte dringend abgeschaltet werden. Ok, es ist bei mir so, dass ich die Kriese bekomme wenn ich so etwas sehe.
Ich habe SelectionModemode "include" eingestellt. Zuerst Text im Commandref könnte üerarbeitet werden.
ZitatExclude: DbLog behaves just as usual. This means everything specified in the regex in DEF will be logged by default and anything excluded via the DbLogExclude attribute will not be logged
Include: Nothing will be logged, except the readings specified via regex in the DbLogInclude attribute (in source devices). Neither the Regex set in DEF will be considered nor the device name of the source device itself.
Exclude/Include: Just almost the same as Exclude, but if the reading matches the DbLogExclude attribute, then it will further be checked against the regex in DbLogInclude whicht may possibly re-include the already excluded reading.
"DbLog behaves just as usual. " ist eine coole Aussage - sagt mir nix.

Exclude: logs any reading except if excluded by DbLogExclude. DbLogInclude is ignored
(DbLog Include sollte dann aber gleich aus der Liste verschwinden!)
Include: logs nothing except if included DbLogInclude. DbLogExclude is ignored
(DbLog Exclude sollte dann aber gleich aus der Liste verschwinden!)
Exclude/Include: logs any reading except if excluded by DbLogExclude. The exclude can be oderruled by DBinclude
macht dieser Mode Sinn? na meinet wegen.

Aber nun zur Performance.
Ich habe "selectionMode" include gewählt - m.E. das was einfach zu verstehen ist. In meiner Anwendung gäbe es nichts anderes. Der User kann mit "attr .* DBinclude .*"fix alles einschalten.
Ich erwarte schlicht von einem guten Modul, dass es sich nun bei Notify überall einhängt, bei welchen das Attribut DBinclude gesetzt ist. Alle notifies anderer Devices werden ignoriert.
Das Bedarf natürlich, dass man code investiert. Man muss sich an "global" hängen und bei Define/delete/rename/defmod aktiv werden genauso wie beim setzen des Attribut DBloginclude.
Wie das geht habe ich in meiner Variante des Notify durchexerziert. It machbar, kostet etwas Hirnschmalz, etwas performance bei Init und ein wenig bei Konfig (attr change). Operational ist es dann ein Gewinn!

Im Exclude mode gilt das gleiche - hier klammere ich alle Devices aus, welche ich nicht loggen will. Exclude ist m.E. ... wie soll ich ses freundlich sagen ... quatsch? alles zu loggen ist Aufgabe der NSA. Nun ja, aber nun sollte ich wenigstens eine Methode haben, ein device auszuklammern. also "DBexclude .*"

Allein schon, wenn ich mir hier überlege, wie ich einem Anwender klar machen will, wie er  den einen Mode gegen den anderen Bewerten muss komme ich zum Schluss " zu kompliziert".

Mein Vorschlag zum Frontend zu diesem Detail: Weniger ist mehr

a) selection mode ist immer include  ein Attribut braucht es nicht mehr
b) DbLogExclude braucht es nicht mehr
c) DbLogInclude wird genutzt. Will ich alles loggen mache ich ein .* - das sollte einem Anwender klar zu machen sein - man sollte davon abraten
Exclude kann man einfach mit !(temperature|status) realiseiren - sollte kein Problem sein.
includeExclude lässt sich auch machen - hier bräuchte ich eine Idee, warum ich so etwas machen soll. Dann kann ich einen Vorschlag machen evtl !(exclude1|!excude2)||(include1|include2)









DS_Starter

#32
Guten Morgen,

ich möchte ein grundsätzliches Statement zur allgemeinen Kenntnisnahme abgeben.
Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.
Dann kommt nämlich das heraus was wir bei Homematic hatten ... monatelangen Stress mit Fehlern die zumindest bei mir dazu geführt haben dass ich das/die Module vom Update ausgeschlossen habe. Das wird es bei DbLog nicht geben !
Ich möchte das nur klargestellt haben, damit es nicht irgendwann Diskussionen deswegen gibt.

Was aber herauskommen kann ist ein Nachfolger für DbLog zu entwerfen; was ich schon lange vorhatte (DbLogNG); welcher bestimmte Unzulänglichkeiten des bisherigen Moduls beseitigt (z.B. BlockingCall). Hier wäre auch Augenmerk darauf zu richten den SVG Editor voll nutzbar zu machen (Stichwort Erhalt erstellter Codes im plot-File).

Und Martin ... der Hinweis ist nicht despektierlich gemeint .... denke bitte daran dass du nicht der Nabel der Welt bist.
Wenn du der Meinung bist etwas so und nicht anders zu brauchen oder im Umkehrschluss etwas nicht als benötigt ansiehst heißt es noch lange nicht dass andere User diese Meinung teilen.

Just my2ct.


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

Zitat von: martinp876 am 13 November 2022, 07:49:19
Beta-User
1) mir nicht klar, wie ich mit event-on-change-readings "weichzeichnen" kann. Doppelt ist klar der falsche Weg (daher biete ich meine Anpassungen nur an und veröffentliche keine Konkurenz-Module). Event-on-change-reading .* ist und bleibt für mich das A und O einer Datenerfassung. ALLES, was damit nicht geht ist einfach schlecht implementiert - m.E. Bastelwerk. Harte Aussage, ok. Bei mir geht es.
=> Wie kann ich mit Event-on-change-readings nur dann Events erzeugen, wenn sich die Temperatur um +-0,3° ändert? Tip würde mich interessieren.
=> mein Weichzeichnen ist ein level mehr zu event-on-change-readings.* . Wenn ich erst einmal optimiere, dann möglichst umfassend.

Ich teile nach wie vor NICHT die Meinung, dass "event-on-change-reading .*" eine allumfassend (!) gute Lösung ist. Das Attribut kennt nämlich bereits einen threshold...
Und man kann das wunderbar ergänzen mit "min-interval", was du wüßtest, wenn du den Thread zu archetype 2022 gelesen hättest. Hier also mal Klartext dazu:
defmod Thermostat_EssZi_Climate CUL_HM 2642E802
attr Thermostat_EssZi_Climate devStateIcon {devStateIcon_Clima($name)}
attr Thermostat_EssZi_Climate event-min-interval measured-temp:900,desired-temp:1800,humidity:1800
attr Thermostat_EssZi_Climate event-on-change-reading measured-temp:0.2,.*
attr Thermostat_EssZi_Climate genericDeviceType thermostat
attr Thermostat_EssZi_Climate group Heizung
attr Thermostat_EssZi_Climate icon hm-tc-it-wm-w-eu
attr Thermostat_EssZi_Climate model HM-TC-IT-WM-W-EU
attr Thermostat_EssZi_Climate peerIDs 00000000,2E7A0802,2E7BA002
attr Thermostat_EssZi_Climate rhasspySpecials priority:inRoom=desired-temp,temperature,humidity
attr Thermostat_EssZi_Climate room Esszimmer,Steuerung->Heizung
attr Thermostat_EssZi_Climate sortby 1
attr Thermostat_EssZi_Climate tempListTmpl none
attr Thermostat_EssZi_Climate webCmd desired-temp
attr Thermostat_EssZi_Climate widgetOverride desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225

Wie man das DIREKT beim Anlegen des Devices automatisiert als Attributsatz bekommt? Link zum Beitrag im archetype-Thread: https://forum.fhem.de/index.php/topic,125930.msg1209967.html#msg1209967

Zitat2) Start und Ende... wie geht das?
Die Aufgabe ist: meine desired-temp ändert sich um 7:00, 15:00, 20:00. In der 2-Tage Grafik beginnt die Linie also nicht um 00:00:00 sondern um 07:00:00. Sie endet um 20:00, nicht um 22:31 wenn ich den Graphen ansehe.
https://wiki.fhem.de/wiki/LogProxy#Erweitern_des_zu_plottenden_Bereichs_um_ausserhalb_liegende_Anfangs-_und_Endwerte
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: DS_Starter am 13 November 2022, 08:21:15
Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.
Dem kann ich nur zustimmen!

Nach meiner bisherigen Erfahrung (ich gehöre zu den wenigen Maintainern, die auch mal was ausgephast oder Module radikal umgebaut haben), sind es übrigens in der Regel NICHT die nerds, die mit derartigen Veränderungen ihre Probleme haben, sondern eher die "Gelegenheits-User", die alle paar Jahre mal ein update machen und dann Fehlermeldungen entweder schon gar nicht erst finden oder selbst einfache (im Sinne von "häufigen") Meldungen im Log  nicht interpretieren können und dann darauf bestehen, dass alles bleibt, wie es ist...

(Bestes Beispiel in diesem Thread hier ist der "Anlass" für Doppelung von Funktionen in DBLog und DbRep).
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

enno

Moin zusammen,

ich melde mich mal als User. Die Idee etwas zu verbessern halte ich für eine Gute Idee. Aber ich möchte die Aussage von DS_Starter unterstreichen!
Zitat von: DS_Starter am 13 November 2022, 08:21:15
Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.
Dann kommt nämlich das heraus was wir bei Homematic hatten ... monatelangen Stress mit Fehlern die zumindest bei mir dazu geführt haben dass ich das/die Module vom Update ausgeschlossen habe. Das wird es bei DbLog nicht geben !
Mich hat die Änderung bei Homematic ziemlich heftig getroffen. Das Modul ist eines der wichtigsten in meiner FHEM Installation. Nach der Erfahrung wie geändert wurde, steht es  bei mir immer noch auf  "exclude" und ich mache das Update immer erst mehrere Tage später um im Forum zu erkennen, ob es unerwünschte Nebenwirkungen hat.

Damit ziehe ich mich wieder raus und lese weiter interessiert mit.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

martinp876

@DS_Starter:
ZitatIch werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.
das habe ich erwartet, ist die übliche Reaktion und endet meist damit, dass ich die Anwendung an meine Bedürfnisse selbst anpasse.
ZitatWas aber herauskommen kann ist ein Nachfolger für DbLog zu entwerfen
das hatte ich betreits vorgeschlagen - wäere mir lieber!
ZitatUnd Martin ... der Hinweis ist nicht despektierlich gemeint .... denke bitte daran dass du nicht der Nabel der Welt bist.
da hast du recht. Dennoch werde ich meine Meinung kund tun - sonst hatte ich gleich schweigen müssen. Das, was ich hier mache ist ein Diskusionsbeitrag. Es gibt immer (ich hatte es, denke ich mehrfach erwähnt) mehrere Wege zum Ziel.
ZitatIch teile nach wie vor NICHT die Meinung, dass "event-on-change-reading .*" .... mit "min-interval",
hier werden wir nicht zusammen kommen. So gut wie alle Automation systeme sind "edge-triggered". "level triggered" ist  nur selten notwendig. Wäre schön, wenn ich einmal eine Anwendung sehen könnte, bei der es nicht möglich ist.
Für min-interval sehe ich keine Anwendung.
a) mit event-on-change-reading kann es genutzt werden um doppelte Meldungen des gleichen Ereignisses abzufangen (bei Homematic wenn ein Ack und dann ein Status kommt, welche beide das gleiche Reading setzen, kann man eines unterdrücken)
b) ohne event-on-change-reading fehlt mir die Fantasie. Da werden ggf Anderungen weggefiltert... Die Anwendung kenne ich nicht.
c) zu Trigger werde ich noch einen eigenen Post erstellen - das läuft aktuell nicht so wie ich mir das vorstellen

Danke für den Link zur extrapulation der Readings. Werde ich mir noch ansehen.

ah, 2. Einwad zu Änderungen. Aber ich hatte doch eh schon vorgeschlagen, ein "lean-Logging" modul zu bauen - habt ihr das übersehen? Aus meiner Sicht kann das aktuelle nicht nach "lean" umgebaut werden. Das ist alles viel zu verzettelt... da muss man (die Meinung vom Nabel :) so viel anpassen, dass ein merge nicht möglich ist.

Oh - noch ein 3. Verängstigter.  Muss ich noch einmal antworten
1) ich werde nichts an dem Modul ändern - wie auch. Stand nie zur Diskussion
2) ich stelle hier da, was mir am Modul nicht gefällt. Ich die MEINUNG vom Nabel. Kann(SOLLTE) diskutiert werden und um andere Meinungen angereichert werden.
3) die Betrachtung bewertet das Modul explizit OHNE die angabe, ob und wie es implementiert wird/werden könnte/werden sollte/werden KANN. Mir ist bei der Betrachtung explizit EGAL ob es einen update geben kann. All das schränkt die freie Sicht ein. Die Frage ist: Wie sollte(könnte) ein DbLog aussehen - mit der Erfahrung aus der aktuellen Implementierung.
4) Ob, wie und wer es dann realisiert diskutiere ich hier und jetzt doch garnicht.

Einen Umbau des aktullen Moduls halte ich (ich wiederhole mich zum x-ten mal) für nicht machbar.
I) wenn ein neues Modul gebaut wird, werde ich es mir ansehen
2) wie das neuen Modul funktionieren könnte kann (auch hier) erarbeitet werden
3) erst einmal feasibility, dann requirements, dann implementieren.

==> ich experimentiere gerade mit einem Add-on Modul welches unter Nutzung von DbLog und DbRef ein für mich sinnvolles Userinterface zu Verfügung stellt. Ich denke ich kann in kürze einen unausgereiften Prototypen vorstellen. ACHTUNG: mein Modul ist als Experiment gedacht.  Es ist die schlechteste Lösung und wird NIE in FHEM Einzug halten. Ich sammle damit Erfahrungen. Ihr werdet sehen, wenn ihr interesse habt.

###########################################################
eigentlich wollte ich heute zum Thema Performance das Logging ansprechen.
Mir ist seit Jahren (also Performance Spinner) unwohl bei der Art, wie in FHEM debug-logs gehändelt werden. Typisch ist ein
Log3 ($name, 4, "DbLog $name -> DbLogType is: $DbLogType");
Sicher wissen alle Programmierer, was hier passiert:
a) der Log-string wird generiert
b) die 3 Argumente werden als call-by-value in den Stack der subroutine "Log3" kopiert
c) in Log3  prüft name, errechnet den Loglevel, vergleicht den Loglevel und entscheidet über das Printen
d) der Text wird geloggt (wenn Bedingung erfüllt ist).

Wird der Text geloggt ist das alles ok. Die meisten Logs allerdings werden nicht gedruckt. Hier wird dennoch der Text "errechnet" und kopiert.
I) es sollte erst geprüft werden, ob wir loggen wollen, dann wird der String errechnet
II) ein call by reference macht deutlich mehr Sinn
=> im Code sieht es dann nicht mehr so cool aus... schade. Aber es werden nicht kontinuierlich sinnlose Dinge errechnet und kopiert.

LogMe($name,,$loglevel,\"hallo $a") if(LogLvl($name,$loglevel))
wäre mein Voschlag. Dann würde ich mich deutlich wohler fühlen und mehr Logs einbauen - zum Debuggen.
Ich denke ich muss in dieem Kreis nicht erklären: "LogLvl" prüft, ob gedruckt werden soll, LogMe druck dann - wobei der String nur errechnet wird, wenn eine Druckzusage erteile wurde. Ausserdem wird nicht der String sondern die Adresse kopiert.

Programmierer sollten dennoch mit den Logs haushalten. Wenn ich code finde wie:
  if($memcount && $dolog && !$hash->{HELPER}{".RUNNING_PID"}) {     
      Log3 ($name, 4, "DbLog $name -> ################################################################");
      Log3 ($name, 4, "DbLog $name -> ###      New database processing cycle - asynchronous        ###");
      Log3 ($name, 4, "DbLog $name -> ################################################################");
      Log3 ($name, 4, "DbLog $name -> MemCache contains $memcount entries to process");
      Log3 ($name, 4, "DbLog $name -> DbLogType is: $DbLogType");

löst es bei mir komplettes unverständnis aus - insbesondere in einer notify-routine
  if($vb4show && !$hash->{HELPER}{".RUNNING_PID"}) {
      Log3 $name, 4, "DbLog $name -> ################################################################";
      Log3 $name, 4, "DbLog $name -> ###              start of new Logcycle                       ###";
      Log3 $name, 4, "DbLog $name -> ################################################################";
      Log3 $name, 4, "DbLog $name -> number of events received: $max of device: $dev_name";
  }


A) warum der Log so wichtig ist, dass es 3 Zeilen Header rechtfertigt ist mir unklar. Wennd das jeder Module-owner so sieht wird das log ausch schnell voll.
B) mir vollkommen unklar, wie man 4 mal bedingungslos die gleiche Routine aufrufen kann, wo man es doch in einem einzigen Aufruf erledigen kann. In einer doch recht stark frequentierten notify-routine
=> Das ist noch einmal ein ganz anderer level. Wenn so codiert wird kann ich mir ersparen, mir über Performance Gedanken zu machen.









martinp876

das 2. Performance Thema für mich heute sind Notification.
Bei meinen DB Untersuchungen haben ich mich wieder einmal und noch etwas genauer mit notifies befasst. Insbesondere mit dem Hintergrund, die Einträge in die LogDb auf ein sinnvolles mass zu reduzieren. Das erhöht die Performance an mehr als ener Stelle!

Der Status ist (so wie ich es aktuell kenne)
- faktisch alle Readings sollten vom Programm heraus trigger aufrufen. Der User geht typisch davon aus und als Codierer will ich das nicht vorschreiben. De-facto mache ich bei CUL_HM ausnahmen bei "Register-daten". Alles andere ist "Trigger-fähig"
- Wer event-on-update-reading liebt soll es nutzen - mache ich ggf zu debug zwecken - ist hilfreiche. Ich werde immer (und mir muss hier keiner folgen!) propagieren, dass event-on-change-reading .* genutzt wird. Das reduziert die CPU Last erheblich.
- Rudi hat nun schon geraume Zeit implementiert, dass  notfications von Trigger-Devices nur an enroled Processing-Devices gehen. Nicht ganz korrekt: un-enroled Processing-Devices werden automatisch überall enrolled.  Diesen unsauberen Fall betrachte ich hier nicht - das ist schlamperei und sollte korrigiert werden.
- Das filtern von Readings ist vom Processing-device vorznehmen.

Nun ist es faktisch so (ich bringe noch 2 Beispiele) dann die Notifikation bei jeder Änderung IRGENDEINES Readings stattfindet.
Beispiel:
ein CUL_HM RT liefert temperaturwerte auf Kanal 1 und 4. Weiter wird die Temperatur von einem möglichen TC auch noch gemeldet.
=> alle 3 Minuten erhalte ich einen Temperatur-wert - mehrfach den gleichen.
=> loggen muss ich den nur einmal -  es wird nicht wärmer oder kälter durch mehrfaches schreiben - nur langsamer.
=> Bei Temperaturmessungen schwankt der Messwert um 0.1° - was in der Auswertung und einer Grafik irrelevant ist. Für meinen Fall reicht es, bei Änderungen von +-0.3° zu loggen

also baue ich ein user-reading (ich hatte ein notif - viel cooler. Allerdings macht das noch mehr stress - also abgeschafft) welches ein "meas-tempS" für "smooth" erstellt. Schnell geschrieben.
==> ich logge also nur nioch meas-tempS, das Log ist geschmeidiger, die Grafiken deutlich schneller.
Was ich als User aber nicht abstellen kann ist, dass jede Änderung von meas-temp einen Trigger auslöst und alles geprüft werden muss. Na wenigstens identische Werte erzeugen keine Last

Auch event-min-interval gibt keine Hilfe hier. Entweder werden potentielle Änderungen unterdrückt oder es werden doch alle Änderungen processed.

Ich überlege, wie ich als User das  Auslösen eines Triggers durch bestimmte Readings unterdrücken kann.
Zum einen ärgern mich die RTs/TCs - das sind einige - vorhersehbarer unnötiger Verkehr.
Weiter habe ich einen Power-sensor welcher kontinuierlich eine Änderung in der Leistung sieht und tatsächlich alle paar Sekunden einen Trigger schicke für den es überhaupt keinen Empfänger gibt.

Sollte es ein attribut "no-Event-for-reading" geben stellt sich die Frage, wie man das user-geeignet befüllen kann. Bei der Datenbank könnte ich mir eine Auswertung über DBinclude vorstellen. Bei notifies kann es etwas ähnliches geben.

Eine Professionelle  SW hatte einen Mechanismus, wie sich en Device bei einem anderen für gewisse Readings enrolled. Kein Enrolement, kein Trigger .

Für mein System nähere ich mich einer Lösung, das system wirklich nutzbar zu machen. DerAnspruch hier ist aber: Wie kann man das automatich schaffen.

p.s. Auf die Anwendungen, warum man Event-on-update-reading brauche bin ich gespannt Damit auch evnt-min-interval. Aus meiner Sicht unnötig. So etwas gibt es auch noch replizerit in DbLog... man kann es nicht oft genug haben, glaube ich ;)  nichts für ungut.

Die Beispiele später....

Beta-User

Martin, irgendwie habe ich den Eindruck, dass die Möglichkeiten, die mit event-on-change-reading bereits da sind, immer noch nicht bei dir angekommen sind.
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876

ZitatMartin, irgendwie habe ich den Eindruck, dass die Möglichkeiten, die mit event-on-change-reading bereits da sind, immer noch nicht bei dir angekommen sind.
das ist sicher möglich. Aber ich sehe es gerade nicht.
Machen wir ein Beispiel (nicht real, aber  du verstehst es sicher)

RT sendet: meas-tempS erstelle ich mit einen UserReading weil ich das Rauschen der Messung weder triggern und schon garnicht loggen will. Wenn meas-temp um +-0,3 von meas-tempS abweicht wird meas-tempS upgedated.
Annahme: ich bin für RT enroled (ich will ja meas-tempS abfangen.
Event-on-change-reading
(t) bedeutet ein notify wird gestartet, (-) kein notify
t1: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t2: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t3: des-temp: 20 (-) meas-temp: 19,2 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t4: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t5: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t6: des-temp: 23 (t) meas-temp: 19,3 (-) controlmode: auto  (-) meas-tempS: 19,3 (-)
t7: des-temp: 23 (-) meas-temp: 19,5 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t8: des-temp: 22 (t) meas-temp: 19,7 (t) controlmode: auto  (-) meas-tempS: 19,7 (t)
t9: des-temp: 22 (-) meas-temp: 20,3 (t) controlmode: auto  (-) meas-tempS: 20,3 (t)

==> Resultat: mein notify wird getriggert für jeden der timestamps. ich brauche nur t8/t9.

Nun setze ich evOnChRead .* und minInterval auf 2 ticks.
t1: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t2: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (t) meas-tempS: 19,3 (-)
t3: des-temp: 20 (t) meas-temp: 19,2 (t) controlmode: auto  (-) meas-tempS: 19,3 (t)
t4: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t5: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (t) meas-tempS: 19,3 (-)
t6: des-temp: 23 (t) meas-temp: 19,3 (-) controlmode: auto  (-) meas-tempS: 19,3 (t)
t7: des-temp: 23 (-) meas-temp: 19,5 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t8: des-temp: 22 (t) meas-temp: 19,7 (t) controlmode: auto  (t) meas-tempS: 19,7 (t)
t9: des-temp: 22 (-) meas-temp: 20,3 (t) controlmode: auto  (-) meas-tempS: 20,3 (t)

==> Resultat: mein notify wird getriggert für jeden der timestamps. ich brauche nur t8/t9.

##> wie kann ich einstellen, dass ich nur 2 trigger erhalte? Ok, deal: wenn ein anderes notfify auch T6 braucht, dann bekomme ich das eben auch.
##> anders gefragt: ich will dass niemand vom Plappermaul meas-temp notifiziert wird. niemand ausser mein userReading (welches die Glättung macht)

--> ich kann sicherstellen, dass nur meas-tempS geloggt wird (das ist ja einfach).

Fakt: ich haben ein power-meter welches quasi kontinuierlich triggert (alle paar sekunden - echtzeit!) und keiner will dieses Reading.

So, wenn es eine Einstellung gibt, die das leistet bin ich mehr als erfreut sie kennen zu lernen. Die suche ich tatsächlich dringend.


martinp876

ich habe mir extend und offset aus svg angesehen. Am ende nicht das, was ich brauche und was robust ist.
Offset: die Angabe holt aus der Datenbank einfach alle werte aus dem Zeitraum "vor dem Zeitraum", verarbeitet dies und los gehts.
Unschön ist dabei
- ich weiss nicht, wie lange ich vorher nachsehen muss - will ich auch nicht wissen. Das kann Tage her sein!
- wenn viele Werte gesampelt sind muss svg viele verarbeiten und filtern. Ich brauche aber nur einen einzigen.

extend:
typisch stelle ich die Grafiken bis zum "jetzt" dar. Da kommt kein Wert mehr.
Also wieder ein Beispiel: Desired-temp. Drehe ich in den Raum nie. Wir haben Zeitpunkt T9. Der Graph geht von T5 bis T12(T12 ist Zukunft)
1) von T9 bis T12 werden keine Linien gezeichnet (Zukunft)
2) um T-20 wurde desTemp auf17 gestellt. Um T7 auf 20.
3) der Grap soll also T5=17, T6=17, T7=20, T8=20, T9=20, T10=, T11=, T12=

Anforderung an ein inteligentes System:
- hole alle Messwerte von T5 bis T12
- hole den letzten Wert vor T5
  passe den Zeitstempel an, so dass T5-0,000001 gesetzt ist (1 sec vor T5)
- wenn curtime < T12: setze Tcur auf value T12
- wenn curtime > T12: setze T12 auf den letzte gefundenen Wert

Der Vorschlag bietet mir das nicht. Ich habe aktuell zwar nicht meinen Vorschlag am Start, dennoch denke ich ist meiner effizienter also dein Angebot. Aber eher nerd-ware. Nichts für jedermann.

Icinger

Zitat
##> wie kann ich einstellen, dass ich nur 2 trigger erhalte? Ok, deal: wenn ein anderes notfify auch T6 braucht, dann bekomme ich das eben auch.
##> anders gefragt: ich will dass niemand vom Plappermaul meas-temp notifiziert wird. niemand ausser mein userReading (welches die Glättung macht)

Ohne mich in euren Dialog hier einmischen zu wollen, aber wo liegt das Problem? Wozu ein (unnötiges) Userreading?


attr <device> event-on-change meas-tempS:0,3

gibt dir doch nur genau diese 2 Events, welche du haben willst?? Oder versteh ich da grad was nicht?
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

martinp876

ZitatOhne mich in euren Dialog hier einmischen zu wollen, aber wo liegt das Problem? Wozu ein (unnötiges) Userreading
Vielleicht habe ich mich falsch ausgedrückt: das normale Reading will ich ausblenden.
Das Userreading ist das für mich sinnvolle.

Nein. ALLE Readings eines device werden durchgereicht. Kennst du den notify Mechanismus von fhem?
1) der Modulschreiber definiert Readings und legt (typisch unveränderlich) fest, welches Trigger auslösen darf. Das sind meist alle, da der Anwender entscheiden darf, was er nutzen will.
2) im kernal darf sich jeder notify Empfänger enrolen WEN er sehen will. Aber WAS er sehen will muss er selbst filtern.

Jede notify entity welche ein Reading  von device A haben will bekommt alle und muss suchen und filtern.

Achtung: Anwender welche das notify Modul nutzen sehen das nicht. Das filtern macht das Modul im Hintergrund.

Ich habe da ein paar Plappermäulchen welche viele Readings Posten. Ein extrem fleißiger und dann einige, dafür mehrere, nicht so heftige.

Mit event-on-change kann man schon einmal viel reduzieren. Regelmäßige Sender wie Thermostate und Thermometer senden unermüdlich. Oft die identischen Werte. Das kann man unterbinden, was ich konsequent mache und empfehle. Das ist Blindleistung.

Ich will, wenn ich es schon anfasse würde ich es gerne konsequent und bestmöglich machen. Da sind zum einen Trigger und zum 2. Die logs.

Logging habe ich im Griff: Messwerte werden geglättet um das Rauschen der Sensoren nicht loggen zu müssen. Bspw Temperaturen welche um 0.1 Grad wackeln sind für Auswertungen irrelevant.
Vorteile eines systematisch sparsamen Umgangs mit Ressourcen liegt auf der Hand und zahlt sich aus je größer die Installation ist.

Aus deinen Anmerkungen vermute ich, dass du nie hinter die Kulissen gesehen hast

Beta-User

...ich bin vielleicht nicht der erfahrenste Code-Leser, aber nach meinem Verständnis des userReadings-Codes in fhem.pl funktioniert kein userReading ohne trigger. Der kann mehr oder weniger eng sein, ist aber erforderlich. Das vorausgeschickt, KANN ein zusätzliches userReading NIE so "sparsam" (im Sinne von effizient) sein wie ein (gefiltertes) Original-Reading.

Und dass ".*" (für den Rest) und eine Hysterese (z.B. für measured-temp) nebeneinander in event-on-change-reading möglich sind, könnte man bestimmt auch besser verstehen, wenn "man" mal in den Code schauen würde, statt irgendeinen (m.E. kruden) workaround zu verteidigen. Jedenfalls scheint mir so, dass Icingers und meine praktischen Erfahrungen die sind, dass das völlig ausreicht, um die "gesprächigen" CUL_HM-Geräte sinnvoll zu bändigen (und einiges mehr, falls man noch geschwätzigeres Zeug hat, das es durchaus gibt, wenn man die Augen nur weit genug aufmacht.)

Nur mein 2ct. als Perl-Novize...
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Irgendwie so ruhig hier?

Das mit dem Loggen fand ich auch eine Überlegung wert und werde das in jedem Fall bei der Überarbeitung von YAMAHA_AVR mit einfließen lassen. Da gibt es auch einige Interpolationen auf den verbose-Leveln 4 und 5, die man sich überwiegend sparen kann, wenn man vorab den gewünschten Level abcheckt. Das ist dann allerdings eine Doppelung zu dem, was Log3 sowieso tut, von daher werde ich das auch beschränken auf 4 und 5.

Sieht (im Moment; fhem.pl-Routinen ohne korrekte Klammern und "@a" etc. gehen eigentlich gar nicht!) konkret so aus (gepackagte Version, von daher bitte nicht an dem kurzen Funktionsnamen aufhängen):
Log3 $name, 5, "YAMAHA_AVR ($name) - set ".join(" ", @a) if _Log3Demand($hash,5);

und
sub _Log3Demand {
    my $hash = shift // return 0;
    my $lvl  = shift // 3;

    my $lcllvl = AttrVal($hash->{NAME}, 'verbose', undef);
    return $lcllvl <= $lvl if defined $lcllvl;
    return $lvl <= AttrVal('global', 'verbose', 0);
}


@Martin: Wenn wir schon beim Thema Effizienz im Coden sind: in CUL_HM finden sich ziemlich viele doppelte Quotes. Why?

(OT: frank hat eine konsolidierte CUL_HM-Version im Angebot, die diverse Kleinigkeiten gradezieht, die v.a. ihm nach den letzen Durchgängen noch so aufgefallen sind. Läuft stressfrei, soweit ich das beurteilen kann, vielleicht findest du mal Zeit, dir das näher anzusehen).
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files