98_cloneDummy.pm [war: Erweiterungsvorschlag für 98_dummy.pm]

[Joachim]

Sieht auf den ersten Blick gut aus, bitte teste es ausführlich, und gib dann nocheinmal Rückmeldung.

Gruß joachim

[gandy]

Hi Joachim,

nachdem das Modul nun über einige Stunden mit 9 Instanzen lief, komme ich auf folgende Statistik:

Code Auswählen Erweitern


PowerMeter01    uniq:8337       dupl:14500
PowerMeter02    uniq:6153       dupl:10479
PowerMeterCW    uniq:6601       dupl:5885
PowerMeterGS    uniq:2784       dupl:2724
PowerMeterKS    uniq:7345       dupl:11592
PowerMeterMM    uniq:8204       dupl:13874
PowerMeterTM    uniq:8687       dupl:15138
PowerMeterWK    uniq:4548       dupl:120
PowerMeterWM    uniq:6463       dupl:5983


Die Zahl hinter uniq und dupl ist jeweils die Anzahl von publizierten bzw als doppelt erkannt und geblockten Readings je Instanz.

Eine Analyse des FileLog, in das alle Device Readings geschrieben werden, ergab für die Tage vor der Einführung von CheckDuplicate, dass durchschnittlich mehr als jeder zweite Eintrag von einer Doppelung herrührt (identische Timestamps, aber nur Sekundengenau), während nach Einführung keine einzige mehr auftritt. Nach allem was ich beurteilen kann, geht auch nichts fälschlicherweise verloren.

Ist dir das schon ausführlich genug? Kann das bei Bedarf natürlich auch gerne detaillierter anhang der Logfiles belegen

Grüße,
Andy.

PS: Der letzte Auszug aus meinem Logfile zeigt etwas zu wenig "drop duplicate" Meldungen, weil ich in meinen Testsystem Events von einem "echten" Device mit solchen aus FHEM2FHEM mische. Auf meinem Produktivsystem, wo ich identische Events aus zwei FHEM2FHEM Instanzen mische, sieht das Filterergebnis, wie schon die Zahlen erkennen lassen, sehr viel beeindruckender aus...

[Bennemannc]

Hallo,

ich habe mal eine Frage zu cloneDummy. Kann ich für ein Device nur ein cloneDummy erstellen oder sollte pro Reading eines gehen?
Ich habe folgendes Problem:
ich habe für einen Panstamp einen Sketch gebastelt, der den Pulscounte sowie die Themperatur des Battery Board überträgt. Das ganze läuft über das SWAP Protokoll. Die Werte für die Counter (4 Stück) stehen im Register 0D. Diese wird per XML in 4 Readings zerlegt. Ich habe einen cloneDummy für den ersten Wert erstellt. Der lief auch soweit gut. Jetzt wollte ich für den zweiten Counter auch einen eigenen cloneDummy erstellen, aber bei dem kommen keine Werte mehr an - es steht da immer nur _state. Die Readings sind , wie schon erwähnt einzeln nach dem Muster 0D.0-Counter_0 bis 0D.3-Counter_ 3.
Mache ich etwas falsch oder geht das was ich vorhabe nicht.
Ach so - das Ganze möchte ich machen, weil ich die Werte mit average aufsummieren lassen möchte.

Gruß Christoph

[Joachim]

Moin gandy,
da bisher keine Einwände von anderen gekommen sind, und ich diese Erweiterung auch für sinnvoll und nebenwirkungsfrei halte (die zusätzlich verbrauchte Rechenzeit sollte nicht ins Gewicht fallen), spricht nichts gegen eine Aufnahme in das Modul.

Drei Bitten hätte ich noch an Dich:
1. Hier im Thread eine  ausführliche Beschreibung, was gemacht werden muss, um doppelte Readings mit diesem Modul ausblenden (optimal einen Wiki-Beitrag).
2. Im Modul die Beschreibung für die commandref Englisch und Deutsch anpassen, am besten als Patch anhängen, damit ich das geänderte Modul dann mit Beschreibung hochladen kann.
3. Wenn das Modul von mir hochgeladen wurde (aber erst dann!) Deine Modulanhänge in diesem Thread entfernen, damit niemand verwirrt wird, und eventuell mit veralteten Modulen arbeitet.


@ Bennemannc,

liefere mal bitte das, was über den Eventmonitor geliefert wird, ich verstehe z.Z. noch nicht, was Du willst.
dann sehen wir weiter.

Gruß Joachim

[justme1968]

hallo joachim,

das ganze ist eigentlich unabhängig vo dem was christoph machen machen möchte.

der knackpunkt ist das $dev->{CHANGED} ein array ist und du nur das erste element

• auswertest. das ist vermutlich deshalb bis her nicht aufgefallen weil da nie mehr als ein reading/event drin steht wenn das ganze von fhem2fhem kommt. wenn du aber events von einem lokalen device bekommst sind alle readings die zwischen einem readingsBeginUpdate und dem zugehörigen readingsEndUpdate geändert werden in einem einzigen aufruf der notifyFn und das CHANGED array hat mehr als einen eintrag. was du tun musst ist in einer schleife über alle elemente zu laufen und dein readingsBeginUpdate vor bzw das readingsEndUpdate nach diese schleife zu packen.
  
  schau dir mal z.b. readingsGroup an.
  
  gruss
    andre

[gandy]

Hallo Joachim,

freut mich, dass mein Vorschlag Deine Zustimmung findet. Deine drei Punkte sehe ich grundsätzlich ein, habe aber noch Kommentare dazu:

• So wie ich das Entfernen der Duplikate umgesetzt habe, kann man es nicht an/abschalten, man muss diesbezüglich also nichts tun (außer man soll dies können, dann müsste ich nochmal ran). Ansonsten könnte ich mir vorstellen, dass der Hinweis auf das globale Attribut dupTimeout von Interesse sein könnte.
• Dieses Attribut sollte auf jeden Fall in der CommandRef (de/en) enthalten sein, werde ich nachliefern.
• Guter Punkt, gibt Sinn 

Eine Sache, die mir aufgefallen ist und entgegen meiner ersten Einschätzung gerade an Relevanz gewinnt, ist die Sache mit mehr als einem Reading im Event: CheckDuplikate prüft im Moment auf das erste Reading im Event, weil das ohnehin das einzige ist, das weiterpropagiert wird. Wenn nun jedes geprüft werden soll, muss das entsprechend angepasst werden. Zum Testen habe ich hier eine etwas abstrus aufgesetzte aber für den Zweck gut geeignete Testumgebung. Sag also gern Bescheid, wenn es etwas zu testen gibt. Willst Du die Entfernung der Duplikate einchecken bevor Du das nächste Thema angehst, oder möchtest Du das noch abwarten?

Grüße,
Andy.

[justme1968]

beim spielen mit dupTimeout muss man aufpassen weil es ja auch zentral für fs20 verwendet wird. wenn der timeout zu gross gewählt wird erkennt man z.b. nicht mehr das rauf und runter dimmen per fs20 fernbedienung.

gruss
  andre

[gandy]

Right, das wollte ich noch nachsehen, sollte ja hoffentlich in der commandref so beschrieben sein. Im Normalfall sollte man auch gar nichts daran machen müssen, da die Dupletten ja in rascher Reihenfolge reinkommen. Wenn das in wenigen Ausnahmefällen mal nicht so ist, kommt schlimmstenfalls eine Duplette durch und man hat im überwiegenden Rest der Fälle immer noch Overhead gespart. Oder ist das zu pragmatisch gedacht?

Sollte eine Loslösung von dupTimeout gewünscht/nötig sein, gäbe es m.E. zwei gangbare Lösungen:

• Kopieren des CheckDuplicate nach cloneDummy_CheckDuplicate mit eigenem Duplikat-Hash und eigenem Attribut für das Timeout.
• Eine API Erweiterung für CheckDuplicate beantragen, die es erlaubt, die Lebenszeit des Duplikats von dupTimeout zu übernehmen, ausser sie ist per zusätzliches Argument anders spezifiziert.

Grüße,
Andy.

[Joachim]

@ gandy,

So wie ich das Entfernen der Duplikate umgesetzt habe, kann man es nicht an/abschalten, man muss diesbezüglich also nichts tun (außer man soll dies können, dann müsste ich nochmal ran). Ansonsten könnte ich mir vorstellen, dass der Hinweis auf das globale Attribut dupTimeout von Interesse sein könnte.

Ich glaube nicht, dass das entfernen der Dupöikate abschaltbar sein muß, der Hinweis auf dupTimeout ist wichtig.
Das Thema mit mehr als einem Reading im Event habe ich noch nicht verstanden, vondaher glaube ich, man kann ersteinmal diese Änderung einchecken, das andere erst dann, wenn ich weiß worum es geht.

@ andre,

wahrscheinlich bin ich schwer von Begriff, aber ich verstehe das Problem immer noch nicht.
Ich kann mit cloneDummy mehrere Devices erstellen, die auf die gleiche Quelle matchen,
Ich kann multireadings in cloneDummy anzeigen,
cloneDummy zeigt auch zeitlich nicht zusammenfallende Readings an.
Bilder in der Anlage.

gruß Joachim

[gandy]

Hi Joachim,

sehr schön; die Infos für die commandref liefere ich, sobald ich wieder Zugang zum meinem Rechner habe.

Was Andre meint ist denke ich folgendes: Wenn FHEM2FHEM Readings für Events erzeugt, beinhaltet jedes dieser Events genau ein Reading, auch wenn diese (zumindest auf Sekundenbasis) den gleichen Zeitstempel haben. Für Devices, die mehrere Readings gleichzeitig aktualisieren wollen, gibt es aber eine effizientere Möglichkeit, sie werden dann in einem Event zusammengefasst. In dem Fall gibt es im Array $dev->{CHANGED} nicht nur einen Eintrag (auf den Du momentan mit $dev->{CHANGED}[0] zugreifst), sondern mehrere, die Du in einer Schelife durchgehen musst.
Im Grunde macht cloneDummy genau dieses, indem es per readingsBulkUpdate mehrere Readings in ein Event packt, das an die NotifyFn rausgeht, wenn readingsEndUpdate() aufgerufen wird. Soweit mein Verständnis der Materie.

Grüße,
Andy.

[justme1968]

genau so ist es.

$dev->{CHANGED} ist ein array und wenn ein 'original' device mit readingsBeginUpdate/readingsEndUpdate arbeitet enthält es mehr als ein event. cloneDummy wertet davon nur das erste aus und alle anderen gehen verloren.


du kannst den effekt am einfachsten selber sehen wenn du dir einen dummy anlegst und da mit setreading ein reading anlegst von dem per userReadings noch weitere readings abgeleitet sind.

auf diesen dummy lässt du einen cloneDummy los und baust in die notifyFn ein 'Log 3, Dumper $dev->{CHANGED}' ein. du wirst sehen das alle user readings auf ein mal in einem einzigen aufruf von deiner notifyFn übergeben werden und du alles ausser dem ersten array element ignorierst.

gruss
  andre

[gandy]

Hi Joachim,

anbei nun also die aktualisierte 98_cloneDummy.pm mit etwas Text für command_ref in de und en. Bitte nochmal durchlesen, ob Du so damit einverstanden bist. Den Hinweis auf dupTimeout habe ich direkt in die Modulbeschreibung gepackt, weil es sich ja um ein globals Attribut handelt.

Zudem habe ich im Quelltext den Kommentar zu CheckDuplicate() noch ein wenig erweitert.

Grüße,
Andy.

Edit: Anhang gemäß Nachricht #117 entfernt

[Joachim]

Moin gandy,
Deine Erweiterung ist eingecheckt, und ab morgen mit dem Update verfügbar.
Bitte entferne die Anhänge in Antwort 104 und 116, damit es nicht zu Verwirrungen kommt.

@ all,
CloneDummy kann ab morgen auch doppelte Events filtern, wenn das globale Attribut "dupTimeout" gesetzt ist.
Dafür noch einmal besten Dank an gandy.

Am "$dev->{CHANGED}[0]" bin ich dran, habe jetzt begriffen und nachstellen können wo das Problem ist.
Das kann so nicht bleiben. Der erste Lösungsansatz läuft bei mir, wenn ich zufrieden bin wird auch das hochgeladen.

Gruß Joachim

[gandy]

Hi Joachim,

super, danke, dann kann ich 98_cloneDummy.pm wieder über normale Updates beziehen

Die Anhänge sind wie gewünscht aus den Beiträgen gelöscht, ein entsprechender Vermerk ist jeweils eingefügt.

Nur ein Wort noch zu dupTimeout: Dieser Wert muss nicht angefasst werden, um das Entfernen der Duplikate zu aktivieren. Das Entfernen ist unabhängig davon immer aktiv. Der default Wert von dupTimeout ist gemäß command_ref bei 0.5 Sekunden und sollte im allgemeinen nicht verändert werden.

Grüße,
Andy.

[chris1284]

hi joachim,

kannst du hier bei gelegenheit noch mal reinschauen?
http://forum.fhem.de/index.php?topic=22553.msg167483#msg167483

danke