FHEM Forum

Allgemeiner Diskussionstread zum Modul 98_cloneDummy.pm

Beschreibung des Moduls siehe:
http://forum.fhem.de/index.php/topic,21718.0.html

========== ursprünglicher Text =============

Moin Rudi,
ich habe einen Erweiterungsvorschlag für die dummy.pm.

Hintergrund:
Ich möchte nicht RAW-fähige Module, die über FHEM2FHEM loggend eingebunden sind, lesend einbinden, um
a) Sensoren von entfernten FHEM instanzen in der Hauptinstanz anzuzeigen.
b) Module, die FHEM blockieren (z.B. OWX) aus meiner Hauptinstanz zu entfernen, die Readings aber trotzdem in der Hauptinstanz zu nutzen
c) in einener Testumgebung auf Readings der Hauptinstanz zuzugreifen, und mit realen Werten zu arbeiten.

dazu habe ich die 98_dummy.pm wie im Anhang angepasst.
Ich habe leider fast keine Programmiererfahrung, und diese Möglichkeit erschien mir die Einfachste.
Mit dieser Anpassung ist es nach Anlegen eines dummys möglich, den Dummy automatisch mit Readings zu füttern, und die Readings wie in einen realen Device zu verwenden.
Ich weiß nicht, ob es eventuell noch bessere Möglichkeiten für das Vorhaben gibt, deshalb soll das ersmal nur ein Diskussionsvorschlag sein.

Um die Änderung zu nutzen, einfach einen Dummy anlegen, der in der Bezeichnung am Anfang 2 Zeichen länger ist, wie das Device, welches man lesend Klonen möchte. Also:
Originaldevicename --> OWX_26_09FF26010000
Dummyname    -->     D_OWX_26_09FF26010000
   
Eintrag in der fhem.cfg:
define D_OWX_26_09FF26010000 dummy

jetzt erscheinen alle Readings des Originaldevices in diesem Dummy und können verwendet werden.
Hier der vorausgegangene Tread dazu:
http://forum.fhem.de/index.php/topic,21533.0.html

Ich freue mich auf Deine konstuktiven Rückmeldungen.

Gruß Joachim

Edit:
"eigenes" Modul angehängt. das Modul ist jetzt offizieller Bestandteil von FHEM
Syntax:
define <name> cloneDummy <sourceDevice>

ZitatIch freue mich auf Deine konstuktiven Rückmeldungen.

Ich finde es gut, dass du dich auch ohne Programmiererfahrung drangewagt hast :)

Was mir auffaellt:
- die Notify Funktion darf nicht Fhem2Fhem heissen, sie ist naemlich FHEM-Weit zu "sehen". Ueblich ist sowas wie dummy_NotifyFn.
- die Aktivierung sollte nicht durch passend gewaehlten Namen passieren, das ist zu eingeschraenkt. Ueblich ist Attribut oder define Argument.
- eine Instanz mit NotifyFn verlangsamt FHEM. Es gibt zwar neuerdings Tricks, um das zu umgehen ($hash->{NOTIFYDEV} auf was unmoegliches setzen), dieser Trick muesste aber fuer normale dummys per default angewendet werden, was ich unschoen finde.
- Ich finde es nicht intuitiv, den dummy fuer diesen Zweck zu missbrauchen.

Vorschlag:
- 98_dummy.pm nach 98_cloneDummy.pm kopieren, alle Namen anpassen
- Im define das zu clonende Geraet als Argument verlangen.
- NotifyFn wie in deiner Version einbauen.
- Unnoetiges wie setlist ausbauen. Oder lassen, je nach Geschmack. :)
- Doku anpassen, testen, einchecken.

Falls das zu viel fuer dich ist, kann das bestimmt auch sonst jemand uebernehmen (oder notfalls ich), aber da es deine Idee ist, faende ich es toll, wenn du es erstmal versuchst.

Gruss,
  Rudi

Hallo Joachim, ich kann gerne die "Patenschaft" für Deine Entwicklung übernehmen und Dich beim Umsetzen der von Rudi gemachten Vorschläge unterstützen, wenn Du nicht weiterkommst.

Gib einfach Bescheid, wenn Du Hilfe brauchst.

Moin Rudi,
danke für Deine Rückmeldung.

Zitat- die Notify Funktion darf nicht Fhem2Fhem heissen, sie ist naemlich FHEM-Weit zu "sehen". Ueblich ist sowas wie dummy_NotifyFn.

angepasst im ersten Post

Zitat- die Aktivierung sollte nicht durch passend gewaehlten Namen passieren, das ist zu eingeschraenkt. Ueblich ist Attribut oder define Argument.

Der Hintergedanke war, Änderungen bzw. erfolgreiche Versuche, die auf einem Testsystem gemacht wurden, mit wenig Aufwand in das Haupsystem zu integrieren. Der erste Versuch mit gleichem Namen brachte allerdings das Problem, das das Reading 3x gloggt wurde, und der Dummy den Originaltyp der von FHEM2FHEM übergeben wurde geklaut hat

2014-03-21 09:35:25.607 dummy OWX_26_09FF26010000 H: 69.95 V (T: 15.93 °C)
2014-03-21 09:35:25.607 dummy OWX_26_09FF26010000 H: 69.95 V (T: 15.93 °C)
2014-03-21 09:35:25.607 dummy OWX_26_09FF26010000 H: 69.95 V (T: 15.93 °C)


Zitat- Ich finde es nicht intuitiv, den dummy fuer diesen Zweck zu missbrauchen.

Ich wollte damit eine "Modulitis" in FHEM vermeiden, und war/bin der Meinung, der dummy ist der zweitbeste Platz nach FHEM2FHEM.
für eine Integration in FHEM2FHEM fehlt mir allerdings das Wissen.
Die in meinen Augen beste Variante wäre:
In FHEM2FHEM mit eienem attr definieren, das dieses Device geklont werden soll, FHEM2FHEM erstellt dann ein device mit 98_cloneDummy.pm, und gibt für dieses device keine events mehr aus.
Wäre in meinen Augen das intuitivste, es gäbe keine doppelten Events, man könnte auf $hash->{NotifyFn} verzichten, da FHEM2FHEM die Übergabe macht, das neue device hätte den gleichen Namen, wie das device auf dem entfernten System, ein irgenwann mal weiterer Schritt wäre dann die Rückkanalfähigkeit, damit man nicht nur Readings hat, sondern auch Befehle an z.B. OWX-Aktoren absetzen kann
Leider fehlt mir das Wissen über die Abläufe in FHEM, um soetwas zu realisieren (da bräuchte ich Hilfe).
Wenn Du der Meinung bist, das die Möglichkeit, devices von entfernten FHEM-Installationen zu Klonen, sinnvoll ist, wede ich gene versuchen, das mit Hilfe zu realisieren.

Moin betateilchen,
die Hilfe nehme ich gerne an.
Dafür muss allerdings ersteinmal der sinnvolste Weg gefunden werden (s.o.).
Hier bin ich für Vorschläge offen.


Gruß Joachim

Wegen der Modulitits musst Du Dir keine Gedanken machen, man sollte den Code schon separat halten, um auch das originale dummy-Modul "sauber" zu halten. Im Moment denke ich auch, dass ein Modul 98_cloneDummy.pm der sinnvollste Weg für die Umsetzung ist.

Meine Vorschläge:

• Den Namen des zu clonenden Devices würde ich auch im define unterbringen, da es ein fester Parameter für den angelegten Clone ist.
• Die Variablennamen in der Notify-Funktion würde ich umbenennen, das sieht erstmal sehr verwirrend aus.
• eigentlich braucht das Modul doch im Moment nur die Define und die Notify Funktion, wenn ich das richtig verstanden habe.

ZitatIm Moment denke ich auch, dass ein Modul 98_cloneDummy.pm der sinnvollste Weg für die Umsetzung ist.

Danke :)
Man kann vlt. mit einem cloneDummy auch andere Probleme loesen, nicht nur dein FHEM2FHEM Problem.

Um das aktuelle Problem zu loesen wuerde vermutlich reichen in FHEM2FHEM Zeile 159 readingsSingleUpdate() statt DoTrigger() aufzurufen.

@Joachim: warum schreibst Du eigentlich das ankommende Reading immer in "state" des clons? Das macht nicht immer Sinn. Wenn im Sourcedevice nämlich gleichzeitig mehrere Readings geändert werden, steht immer nur die letzte Änderung in state.


##############################################
# $Id:  $
package main;

use strict;
use warnings;

sub cloneDummy_Initialize($) {
my ($hash) = @_;

$hash->{DefFn}     = "cloneDummy_Define";
$hash->{NotifyFn}  = "cloneDummy_Notify";
$hash->{AttrList}  = $readingFnAttributes;
}

sub cloneDummy_Define($$) {
my ($hash, $def) = @_;
my @a = split("[ \t][ \t]*", $def);
return "Wrong syntax: use define <name> cloneDummy <sourceDevice>" if(int(@a) != 3);

$hash->{HELPER}{SOURCE} = $a[2];
readingsSingleUpdate($hash,'state','defined',1);
Log3($hash,4,"cloneDummy: $a[0] defined for source $a[2]");
return undef;
}

sub cloneDummy_Notify($$) {
my ($hash, $dev) = @_;
my $dn      = $dev->{NAME};
my $reading = $dev->{CHANGED}[0];

if($dn eq $hash->{HELPER}{SOURCE}) {
my $reading = $dev->{CHANGED}[0];
$reading = "" if(!defined($reading));

my ($rname,$rval) = split(/ /,$reading,2);
$rname = substr($rname,0,length($rname)-1);

readingsBeginUpdate($hash);
readingsBulkUpdate($hash, $rname, $rval);
# readingsBulkUpdate($hash,'state',$reading);
readingsBulkUpdate($hash,'state','active');
readingsEndUpdate($hash, 1);
}
return;
}

1;



(http://up.picr.de/17714952xe.png)

Zitat von: rudolfkoenig am 21 März 2014, 10:33:11
Man kann vlt. mit einem cloneDummy auch andere Probleme loesen
...
Um das aktuelle Problem zu loesen

Zwar habe ich keine Ahnung, warum es welche Probleme überhaupt gibt, aber die Aufgabenstellung, auftauchende Readings in einen dummy zu übertragen, ohne ein modulgebundenes Device dafür zu haben, habe ich zumindest verstanden :)

So, mal etwas gebalstelt,
ich weiss zwar noch nicht warum es jetzt besser geht, aber der Kunstgriff mit den 2 zusätzlichen Zeichen wird scheinbar nicht benötigt.
Allerdings klaut mein Modul immer noch den Originaltyp:

2014-03-21 11:37:20.445 cloneDevice OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:20.458 cloneDevice OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:20.470 cloneDevice OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:48.003 cloneDevice sysmon eth0_diff: RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
2014-03-21 11:37:48.012 cloneDevice sysmon loadavg: 0.01 0.03 0.00
2014-03-21 11:37:48.021 cloneDevice sysmon stat_cpu_percent: 1.30 0.00 1.12 97.43 0.00 0.02 0.13
2014-03-21 11:37:48.032 cloneDevice sysmon ram: Total: 108.67 MB, Used: 78.54 MB, 72.28 %, Free: 30.13 MB
2014-03-21 11:37:50.413 cloneDevice OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:50.427 cloneDevice OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:50.440 cloneDevice OWX_28_6119BA030000 Temperatur: 15.88
es wird aber nicht mehr 3x geloggt.

@ Rudi,

ZitatUm das aktuelle Problem zu loesen wuerde vermutlich reichen in FHEM2FHEM Zeile 159 readingsSingleUpdate() statt DoTrigger() aufzurufen.

brachte Fehler:
2014.03.21 11:10:08.970 1: reload: Error:Modul 93_FHEM2FHEM deactivated:
Not enough arguments for main::readingsSingleUpdate at ./FHEM/93_FHEM2FHEM.pm line 160, near "$msg)"

2014.03.21 11:10:08.971 0: Not enough arguments for main::readingsSingleUpdate at ./FHEM/93_FHEM2FHEM.pm line 160, near "$msg)"

2014.03.21 11:10:08.975 3: Please define FB7390 first
@ betateilchen,

Zitat@Joachim: warum schreibst Du eigentlich das ankommende Reading immer in "state" des clons?

Um einen STATE zu bekommen, mir ist klar, das der sich bei mehreren reading ändert, nur an den Original state kommt man nicht heran. Und man kann das ja mit stateFormat entsprechend einstellen.Das Modul soll mit so wenig Aufwand wie möglich einsetzbar sein, die Variante mit active geht natürlich auch.
Hier ersteinmal meine aktuelle Variante.

Ich werde jetzt mal versuchen Deinen Code zu verstehen, und melde mich dann wieder.

Gruß Joachim

Zitat von: Joachim am 21 März 2014, 11:56:05
Allerdings klaut mein Modul immer noch den Originaltyp:

was meinst Du damit?

2014-03-21 12:21:35.195 cloneDummy clone_OWX_26_09FF26010000 H: 69.938
2014-03-21 12:21:35.195 cloneDummy clone_OWX_26_09FF26010000 active
2014-03-21 12:21:35.205 OWMULTI OWX_26_09FF26010000 H: 69.938  --> Originalbezeichnung grün

bei mir:
2014-03-21 09:35:25.607 dummy OWX_26_09FF26010000 H: 69.95 V (T: 15.93 °C)
2014-03-21 09:35:25.607 dummy OWX_26_09FF26010000 H: 69.95 V (T: 15.93 °C)
2014-03-21 09:35:25.607 dummy OWX_26_09FF26010000 H: 69.95 V (T: 15.93 °C) --> hier hätte OWMULTI stehen müssen
aber da ist auch noch ein anderer Wurm drinnen, ich suche mal.
Deine Variante läuft gut.

Gruß Joachim

ZitatNot enough arguments for main::readingsSingleUpdate at ./FHEM/93_FHEM2FHEM.pm line 160, near "$msg)"

Ich meinte natuerlich eine sinnvolle Ersetzung, und dazu gehoert $msg splitten in name + Wert.

Zitat von: Joachim am 21 März 2014, 12:26:27aber da ist auch noch ein anderer Wurm drinnen, ich suche mal.

Du solltest auf keinen Fall das cloneDevice und das Originaldevice mit dem gleichen Namen bezeichnen!
Ich werde mal noch eine Fehlermeldung einbauen, falls das versucht wird.

Ich geb mich geschlagen, die Variante von betateilchen funktioniert so wie primär von mir gewünscht.
Habe deshalb diese Variante oben zum Testen angehängt.
Fehlermeldung eingebaut, wenn der Name des Devices identisch mit dem QuellDevice ist.
Bitte testen.

Danke für die Hilfe an Rudi und betateilchen.
an die Dokumentation werde ich mich als nächstes machen.

Gruß Joachim

so, dann brauche ich nocheinmal Hilfe.
habe versucht, den Teil für die commandref zu erstellen, komme aber nicht weiter
aufruf von:
root@raspberry-pi:/opt/fhem# perl contrib/commandref_join.pl

bringt:

*** EN FHEM/98_cloneDummy.pm: ignoring text due to DOS encoding
*** DE FHEM/98_cloneDummy.pm: ignoring text due to DOS encoding


Komando zurück, Wenn die richtige codierung genommen wird, geht es.

Von daher:
"feddich" :)

Im ersten Post wie immer die aktuelle Variante.

@Rudi,
wie jetzt weiter?
@betateilchen,
vielen Dank nochmal.

Gruß Joachim

Zitat@Rudi, wie jetzt weiter?

Sacken lassen, d.h. von ein paar Benutzer testen lassen. Danach auf Sourceforge dich anmelden, mir username schicken, ich trage dich ein, und du checkst das Modul nach .../fhem/FHEM ein.

P.S. Damit es etwas weniger Rechenzeit verwendet, bitte in DefFn folgende Zeile hinzufuegen:
$hash->{NOTIFYDEV} = $a[2];
Damit wird NotifyFn nur dann aufgerufen, falls der Ausloeser $a[2] ist.

Zitat von: rudolfkoenig am 21 März 2014, 15:22:11
P.S. Damit es etwas weniger Rechenzeit verwendet, bitte in DefFn folgende Zeile hinzufuegen:

Code Auswählen Erweitern

$hash->{NOTIFYDEV} = $a[2];
Damit wird NotifyFn nur dann aufgerufen, falls der Ausloeser $a[2] ist.

Kannte ich so auch noch nicht. Das vereinfacht das gesamte Coding nochmal.


##############################################
# $Id:  $
package main;

use strict;
use warnings;

sub cloneDummy_Initialize($) {
my ($hash) = @_;

$hash->{DefFn}     = "cloneDummy_Define";
$hash->{NotifyFn}  = "cloneDummy_Notify";
$hash->{AttrList}  = $readingFnAttributes;
}

sub cloneDummy_Define($$) {
my ($hash, $def) = @_;
my @a = split("[ \t][ \t]*", $def);
return "Wrong syntax: use define <name> cloneDummy <sourceDevice>" if(int(@a) != 3);
return "Error: cloneDevice and sourceDevice must not have the same name!" if($a[0] eq $a[2]);

$hash->{NOTIFYDEV} = $a[2];
readingsSingleUpdate($hash,'state','defined',1);
Log3($hash,4,"cloneDummy: $a[0] defined for source $a[2]");
return undef;
}

sub cloneDummy_Notify($$) {
my ($hash, $dev) = @_;
my $name    = $hash->{NAME};

my $reading = $dev->{CHANGED}[0];
$reading = "" if(!defined($reading));
Log3($name, 4, "cloneDummy: $name D: $dn R: $reading");

my ($rname,$rval) = split(/ /,$reading,2);
$rname = substr($rname,0,length($rname)-1);

readingsBeginUpdate($hash);
readingsBulkUpdate($hash, $rname, $rval);
readingsBulkUpdate($hash,'state','active');
readingsEndUpdate($hash, 1);

return;
}

1;


Mensch betateilchen, wie soll ich denn da was lernen? :(

hab das ganze jetzt mal entsprechend angepasst, den Fehler, den Du mir zum finden eingebaut hast beseitigt, und wieder oben angehängt.
Eigentlich ist das mittlerweile Dein Modul ;D
willst Du es einchecken und betreuen? ::)

Gruß Joachim

Hallo Joachim,

Dein neues Modul funktioniert echt super.

Ich verzweifele gerade daran, einen "notify" zu erstellen, der alle events in ein "F2dummy" überführt. So eine Art autocreate.

Als default nach dem Erstellen von F2dummy denke ich, dass das updaten von "state" am meisten Sinn macht, da man nicht weiss ob es sich um ein Multireading handelt (mehere ":", spaces, "=" usw.) oder nicht.

Von dort sollte es dem User möglich sein per attr zu definieren welche readings geklont werden sollen:

Attr F2Dummy cloneReading T, brightness

usw...

Wenn Du etwas davon umsetzen könntest - super!

Falls Du Hilfe beim Testen und der Doku brauchst, helfe ich gern...

MfGroby

Groby,

ZitatIch verzweifele gerade daran, einen "notify" zu erstellen, der alle events in ein "F2dummy" überführt. So eine Art autocreate.

Formuliere Deine Fragestellung bitte nocheinmal anders, da ich Dir im Moment nicht folgen kann.

ZitatAls default nach dem Erstellen von F2dummy denke ich, dass das updaten von "state" am meisten Sinn macht, da man nicht weiss ob es sich um ein Multireading handelt (mehere ":", spaces, "=" usw.) oder nicht.

da kämpfe ich noch mit mir,da
- betateilchen durchaus zu recht darauf hingewiesen hat, dass bei mehreren readings jedesmal der state neu
  geschrieben wird, und es dadurch zu der doppelten Anzahl an Events kommt.
- auf der anderen Seite bedeutet es aber auch, dass man zwingend ein stateFormat setzen muss, auch wenn es
  nur ein reading gibt. Also zwei Zeilen in der fhem.cfg und damit mehr Aufwand beim Erstellen des cloneDummys.
Je nach Einsatzzweck des cloneDummys macht beides Sinn.

ZitatVon dort sollte es dem User möglich sein per attr zu definieren welche readings geklont werden sollen:

da bin ich genau der gegenteiligen Meinung, da das auch wieder bedeutet, beim erstellen noch eine attr Zeile zu schreiben, vorstellen könnte ich mir analog zu DbLog ein
attr clone_OWX_26_09FF26010000 exclude temperature

Beim Testen werde ich an Dich denken.
Aber ich will Schritt 2 nicht vor dem ersten Schritt machen, oder anders gesagt, das was jetzt in der Pipe ist, soll ersteinmal vernünftig laufen, und über das normale Update zur Verfügung stehen.

Gruß Joachim

Welchen Fehler hatte ich eingebaut? Zumindest bewusst habe ich das nicht gemacht.

Zitat von: Joachim am 21 März 2014, 17:05:11
willst Du es einchecken und betreuen? ::)

Es ist und bleibt Deine Idee und Dein Modul :)

Aber Du musst zugeben, es war ein Versuch wert. ;)

Gruß Joachim

Ich kann gerne das Einchecken für Dich übernehmen. Aber ich würde trotzdem Dich als Maintainer für das Modul eintragen.

Na, dass ist doch ein Kompromiss.
Dann kann ich in ruhe einen Sourceforge Account beantragen und mich daran gewöhnen, dass ich Maintainer werde.

Danke für die Hilfe und Gruß Joachim

Ich habs mal für Dich eingecheckt, sollte morgen per Update verteilt werden.

Falls Du irgendwann Änderungen machst - lass bitte die 1. Zeile mit dem $Id drin, die hatte ich nicht zum Spass in das Coding gebaut.

Danke. :'(

ZitatFalls Du irgendwann Änderungen machst - lass bitte die 1. Zeile mit dem $Id drin, die hatte ich nicht zum Spass in das Coding gebaut.

Werde mich bemühen.

Gruß Joachim

Zitat von: Joachim am 21 März 2014, 21:03:51
Danke. :'(

Was gibts da zu Weinen? Hab ich das jetzt etwa falsch gemacht? Wolltest Du das noch nicht eingecheckt haben?

Ne, aber jetzt habe ich ein Modul an der Hacke. ;)
Übrigens, Deine Frage habe ich jetzt erst gesehen

ZitatWelchen Fehler hatte ich eingebaut? Zumindest bewusst habe ich das nicht gemacht.

sub cloneDummy_Notify($$) {
   my ($hash, $dev) = @_;
   my $name    = $hash->{NAME};

   my $reading = $dev->{CHANGED}[0];
   $reading = "" if(!defined($reading));
   Log3($name, 4, "cloneDummy: $name D: $dn R: $reading");

   my ($rname,$rval) = split(/ /,$reading,2);
   $rname = substr($rname,0,length($rname)-1);

den wollte er so nicht, musste ihn so variieren:

sub cloneDummy_Notify($$) {
   my ($hash, $dev) = @_;
   my $dn      = $dev->{NAME};
   my $hn      = $hash->{NAME};
   my $reading = $dev->{CHANGED}[0];
   $reading = "" if(!defined($reading));
   Log3($hash,4, "cloneDummy: $hn D: $dn R: $reading");

Gruß Joachim

Hallo Joachim,

kannst Du Events für state nicht umgehen, wenn Du setstate verwendest?

Warum? Ich denke da an cyclic messages von Heizkörpern, Wetterstationen u.ä. Was soll mir da ein T-reading sagen?


Events
CUL_HM WetterStation T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188
CUL_HM HK_Kueche T: 22.1 desired: 22.0 valve: 100

Readings
"T"    "7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"
"T"    "22.1 desired: 22.0 valve: 100"


Wie soll man state wiederherzustellen, wenn man kein stateFormat anwenden kann?


stateFormat T: T usw -> funktioniert so nicht...



Bei den technischen Feinheiten kann ich nicht mitreden, das überlasse ich den Profis. Ich sehe das aus der Sicht der Anwenders und mir persönlich würden die updates der "states" definitiv fehlen. Ausserdem glaube ich, dass man nicht jeden Event sauber "splitten" kann.

Anbei ein notify, dass dummies auf fhem2 automatisch anlegt:


define Watch_cloneDevice notify .* {if((ReadingsVal("F2".$NAME,"state","?")eq"?")&&(substr($NAME,0,2)ne"F2")&&($NAME ne"global")) {fhem('define F2'.$NAME.' dummy')}};;



MfGroby

Moin Groby,
Seit heute mogen sollte das Modul im regulären Update sein.
Dabei ist die standart Einstellung, dass der state von initialized nach active wechselt.
Ein stateFormat funktioniert bei mir einwandfrei, wenn Du dabei Probleme hast, dann brauche ich mehr Informationen.
- aussagekräftigen Auszug aus dem Eventmonitor
- komplette definition des Moduls mit den gesetzten attr

Gruß Joachim

Hallo Ihr,

habe ein Updatecheck durchgeführt, es ist drin.  ;D

Danke Jo und betateilchen

Gruß
Olaf

Joachim,

das update habe ich mir natürlich direkt heute morgen gezogen.

Solange "state" immer den kompletten "state" des Original devices enthält, gibt es keine Probleme. Ich kann dir Anhand der Wetterstation Events einmal versuchen zu erklären was ich meine.

Event:
CUL_HM WetterStation T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188

Jetzt:

"state" "T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"
"T" 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188


Kein Problem, da man immer noch den Original "state" wegschreiben kann. Sofern aber "state" nicht mehr kopiert wird, wäre das Modul für mich unbrauchbar, da ich immer den kompletten "state" wegschreiben will um Regenmenge usw. zu berechnen. Ansonsten müsste ich temperature, humidity, windSpeed usw. jeweils einzeln aus der Logdatei auslesen.

D.h. wenn Du das Modul weiterentwickelst und den "state" splittest oder einzelne Events erwartest wäre es für mich unbrauchbar.

Readings splitting ohne "state" updates (im Modul oder einzelne Events):

"T" "7"
"H" "85"
"W" "3.6"
"R" "159.005"
"IR" "0"
"WD" "10"
"WDR" "67.5"
"S" "188"


Aus diesen Werten würde ich den original "state" nie wieder zusammen bekommen da "stateFomat F2WetterStation T: T H: H W: W R: R IR: IR WD: WD WDR: WDR S: S" nicht funktioniert. Deswegen ist mir das portieren des original "state" wichtig, auch wenn es ggf. einen zusätzlichen z. Zt. Event gibt.

Die Idee die ich dazu hatte doppelte Events zu filtern war folgende. Das cloneDevice bekommt per Default nur "state" kopiert, es sei den man legt nachträglich ein attr an, welches die readings listet die Du "splitten" sollst, um "doppelte Events zu vermeiden...

also "Default" oder "attr F2WetterStation state" nur:

"state" "T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"


wenn "attr F2WetterStattion T,H,W" ->dann

"T" "7"
"H" "85"
"W" "3.6"


oder "attr F2WetterStattion state,T,H,W" ->dann

"state" "T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"
"T" "7"
"H" "85"
"W" "3.6"


Wie gesagt so wie das Modul jetzt läuft ist es ok, aber wenn es um Filtern von doppelten Events geht, wäre o.g. Beispiel ein möglicher Lösungsansatz...

MfGroby

Moin Groby,
Ich muss mich jetzt ersteinmal selber mit meinem Modul vertraut machen, ein Testsysten bauen, und etwas mit dem Modul herumspielen.
Ich glaube, dass ich verstanden habe, was Du willst.
Ich versuche mal, das ganze zusammenzufassen:

ZitatIch verzweifele gerade daran, einen "notify" zu erstellen, der alle events in ein "F2dummy" überführt. So eine Art autocreate.

Wenn ich das richtig verstehe, möchtest Du, dass Devices aus FHEM2FHEM automatisch angelegt werden, wenn gewünscht.
Könnte irgenwann mal kommen, steht aber ganz unten auf meiner todo-Liste.

ZitatAls default nach dem Erstellen von F2dummy denke ich, dass das updaten von "state" am meisten Sinn macht, da man nicht weiss ob es sich um ein Multireading handelt (mehere ":", spaces, "=" usw.) oder nicht.

Wird es so definitv nicht geben, da in den Events nicht zu erkennen ist, welcher der Events der STATE ist. Aber ich könnte mir vorstellen, dass ich in der Moduldefinition eine Möglichkeit schaffe, zu bestimmen, welches reading in den STATE wandern soll. Bis dahin kann man sich mit stateFormat den STATE so einstellen, wie gewünscht, also z.B. so
define Bad cloneDummy FS_Bad
attr Bad room Bad
attr Bad stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",ReadingsVal("Bad","Temperatur",0), ReadingsVal("Bad","Feuchte",0), ReadingsVal("Bad","dewpoint",0), ReadingsVal("Bad","absFeuchte",0))}

ZitatVon dort sollte es dem User möglich sein per attr zu definieren welche readings geklont werden sollen:

Wird so nicht kommen, da das Modul dazu da ist, Devices zu Klonen. Werte, die nicht gewünscht sind, kann man im Originaldevice blocken. Vielleicht baue ich irgendwann einmal eine exclude Funktion ein. Steht aber auch recht weit unten auf der todo-Liste.

Zitatkannst Du Events für state nicht umgehen, wenn Du setstate verwendest?

Das ist zu Hälfte ein Problem von FHEM und zur anderen Hälfte ein Problen Deine Definition im Originaldevice.
FHEM sendet leider in den Events die Information nicht mit, welches Reading der STATE ist und

ZitatCUL_HM WetterStation T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188

müsste eigentlich als
CUL_HM WetterStation STATE: T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188
geliefert werden, da dies so nicht der Fall ist, wird das T als readingsname erkannt, alles was dahinter ist, als reading. Das geht natürlich schief. Hier muss eine Lösung gefunden werden, gib mir etwas Zeit.

ZitatWie soll man state wiederherzustellen, wenn man kein stateFormat anwenden kann?

stateFormat geht, s.o.

ZitatBei den technischen Feinheiten kann ich nicht mitreden, das überlasse ich den Profis. Ich sehe das aus der Sicht der Anwenders und mir persönlich würden die updates der "states" definitiv fehlen. Ausserdem glaube ich, dass man nicht jeden Event sauber "splitten" kann.

Ich bin auch Anwender, und habe keine Ahnung von Perl. Allerdings kann ich mit Google umgehen, und durch lesen, testen und Hilfe habe ich dieses Modul für mich geschrieben, und der Allgemeinheit zur Verfügung gestellt.

ZitatAnbei ein notify, dass dummies auf fhem2 automatisch anlegt:

Sehe ich mir an, und versuche es zu Verstehen, vielleicht kann man davon was im Modul übernehmen.

Zu Deinem letzte Post mal folgender Kommentar:
Ich hatte Dich gebeten,

ZitatMoin Groby,
Seit heute mogen sollte das Modul im regulären Update sein.
Dabei ist die standart Einstellung, dass der state von initialized nach active wechselt.
Ein stateFormat funktioniert bei mir einwandfrei, wenn Du dabei Probleme hast, dann brauche ich mehr Informationen.
- aussagekräftigen Auszug aus dem Eventmonitor
- komplette definition des Moduls mit den gesetzten attr

Gruß Joachim

Deine Antwort darauf enthielt weder

Zitat- aussagekräftigen Auszug aus dem Eventmonitor

noch

Zitat- komplette definition des Moduls mit den gesetzten attr

sondern ein Text, mit dem ich nicht wirklich etwas anfangen kann, und ich habe ihn mittlerweile diverse male gelesen.
Liefere bitte die gewünschten Informationen um die man Dich bittet, und bevor Du eine Antwort sendest, denke daran, dass der gegenüber im Normalfall kein Gedankenleser ist. Bitte versuche das ganze so zu strukturieren, das auch jemand, der nicht in Deinen Gedanken sitzt, das ganze versteht. Für Halbsätze ist Piet Klocke zuständig.

Gruß Joachim

1. das Ändern von state ist in aller Regel kein wirklicher Event und Änderungen an state werden von fhem komplett anders gehandhabt als alle anderen Readings. Deshalb macht ein Triggern auf state keinen Sinn. Wie schon mehrfach geschrieben wurde, kann jederzeit stateFormat verwendet werden, um im clone einen STATE in der gewünschten Form zu erzeugen. Bitte nicht immer state und STATE verwechseln ;) Das Reading state gehört immer zum definierten Device selbst und das ist hier der Clone und nicht das Originaldevice irgendwo anders.

2. das automatische Anlegen eines cloneDummys wäre eine Aufgabe des autocreate-Moduls, das müsste dann Rudi übernehmen. Das müsste dann am sinnvollsten über ein Attribut von fhem2fhem und/oder autocreate gesteuert werden.

Hallo Joachim,

klasse Umsetzung, genau dieses Modul brauche ich, um meine 1Wire Geräte aus Performancegründen nicht mehr über OWServer, an meiner Hauptinstanz betreiben zu müssen.

Das absetzen von Befehlen von der Hauptinstanz an die Slaveinstanzen wäre natürlich Klasse, scheint aber derzeit out of scope zu sein :)

Funktioniert longpoll eigentlich für den State, welcher via stateformat generiert wird? Bei mir funktioniert es derzeit leider nicht.

Greetz
Eldrik

Joachim,

alles was Du an Informationen brauchst, findest Du bereits in der letzten Antwort:

Die Wetterstation sendet cyclic Messages (inform on):

CUL_HM WetterStation T: 7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42


ein cloneDummy device erzeugt:

"T" "7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"

stateFormat T: T liefert dann:

"7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 427.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"


ein dummy device erzeugt:

"T" "7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"
"state" "T: 7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"


stateFormat wird hier nicht benötigt:

"state" "T: 7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"


Gleiches Problem stellt sich bei Heizkörpern und Thermometern mit cyclic Messages:

Event:

"CUL_HM HK_Kueche T: 23.5 desired: 22.0 valve: 70"

wird portiert nach

"T" "23.5 desired: 22.0 valve: 70"


Event:

CUL_HM HygroMeter T: 23.5 H: 65

wird portiert nach

"T" "23.5 desired: 22.0 valve: 70"


Ich erwarte hier keine Lösung von Dir, aber mit einem einzelnen "T" reading kann ich persönlich nichts anfangen.

Groby

@betateilchen

es mag sein, dass es programmiertechnisch einen Unterschied von state & STATE gibt.

Im WEB frontend liefern aber set und setstate das gleiche Ergebnis für mich. set mit Event & setstate ohne...

MfGroby

Ich glaube, Ihr redet grade mächtig aneinander vorbei. Das stateFormat wird nicht im sourceDevice gebraucht, sondern im Clone.

Tipp: Leg Dir mal im Sourcedevice ein userreading an, das genau so aussieht wie state. Dann sollte dieses userreading automatisch auch im Clone auftauchen.

Zitat von: Groby am 23 März 2014, 13:53:05
es mag sein, dass es programmiertechnisch einen Unterschied von state & STATE gibt.

nein, nicht programmtechnisch, sondern optisch.

Zitat von: Groby am 23 März 2014, 13:53:05
Im WEB frontend liefern aber set und setstate das gleiche Ergebnis für mich. set mit Event & setstate ohne...

Das mag für Dich so aussehen es ist aber definitiv nur eine "optische Täuschung" ;)

set und setreading schreiben beides state. STATE kannst du garnicht direkt beschreiben. nur über stateFormat setzen wenn das modul das unterstützt.

den unterschied zwischen state und STATE siehst du bei ReadingsVal und Value. ersteres liest state letzteres STATE.

gruss
  andre

@betateilchen

der "state" der WetterStation ist default ohne "stateFormat" und sollte auch genauso von cloneDummy übernommen werden.

Warum sollte ich als "User" im SourceDevice noch diverse "userreadings" zum "clonen" anlegen???
Oder neue Events generieren per "event-on-change-reading"???

Das macht m.E. überhaupt keinen Sinn. Da kann ich besser wie bisher mit FHEM2FHEM & notifies arbeiten...

MfGroby

state hat leider eine sonderstellung unter den readings und es ist technisch nicht möglich es über notifys und events eindeutig zu erkennen und zu parsen. rudi weiß das hat aber keine Idee wie man das rückwärtskompatibel und ohne overhead ändern kann.

die lösung für dein problem ist wirklich stateFormat für den dummy zu setzen. ich denke das ist immer noch einfacher und klarer als alles selber über events und notifys zu regeln.

gruss
  andre

Moin Groby,
wie soll ich es Dir Erklären, wenn Du nicht das machst, was ich schreibe. >:(
Zum dritten mal:
- aussagekräftigen Auszug aus dem Eventmonitor
der sieht z.B. so aus:

2014-03-21 11:37:20.445 cloneDevice OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:20.445 OWTHERM OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:20.458 cloneDevice OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:20.458 OWTHERM OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:20.470 cloneDevice OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:20.470 OWTHERM OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:48.003 cloneDevice sysmon eth0_diff: RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
2014-03-21 11:37:48.003 SYSMON sysmon eth0_diff: RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
2014-03-21 11:37:48.012 cloneDevice sysmon loadavg: 0.01 0.03 0.00
2014-03-21 11:37:48.012 SYSMON sysmon loadavg: 0.01 0.03 0.00
2014-03-21 11:37:48.021 cloneDevice sysmon stat_cpu_percent: 1.30 0.00 1.12 97.43 0.00 0.02 0.13
2014-03-21 11:37:48.021 SYSMON sysmon stat_cpu_percent: 1.30 0.00 1.12 97.43 0.00 0.02 0.13
2014-03-21 11:37:48.032 cloneDevice sysmon ram: Total: 108.67 MB, Used: 78.54 MB, 72.28 %, Free: 30.13 MB
2014-03-21 11:37:48.032 SYSMON sysmon ram: Total: 108.67 MB, Used: 78.54 MB, 72.28 %, Free: 30.13 MB
2014-03-21 11:37:50.413 cloneDevice OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:50.413 OWTHERM OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:50.427 cloneDevice OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:50.427 OWTHERM OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:50.440 cloneDevice OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:50.440 OWTHERM OWX_28_6119BA030000 Temperatur: 15.88

- komplette definition des Moduls mit den gesetzten attr

cloneDummy kann nur auf die Events zugreifen, die z.B. FHEM2FHEM liefert. diese findest Du im Eventmonitor!
Hier steht weder ein state noch ein STATE drinnen. Das bedeutet, der Nutzer von cloneDummy muss über das stateFormat dem Device cloneDummy <name> mitteilen, was im STATE stehen soll
Als Beispiel:
define Bad cloneDummy FS_Bad
attr Bad room Bad
attr Bad stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",ReadingsVal("Bad","Temperatur",0), ReadingsVal("Bad","Feuchte",0), ReadingsVal("Bad","dewpoint",0), ReadingsVal("Bad","absFeuchte",0))}


Gruß Joachim

Moin eldrik,
danke für Deine Rückmeldung.

Zitat
Das absetzen von Befehlen von der Hauptinstanz an die Slaveinstanzen wäre natürlich Klasse, scheint aber derzeit out of scope zu sein

wie ich schon geschrieben habe, mein Perl ist nicht besonders, auch wenn selfhtml wirklich gut hilft.
Deshalb ist meine Agenda:
- ersteinmal selber ausführlich mit dem Modul spielen, sehen was geht, was wäre wünschenswert.
- vorsichtig die ersten Änderungen ausprobieren, dabei auf "useabelity achten, und Faulheit unterstützen (sowenig wie möglich ins define)
- FHEM2FHEM Anbindung herstellen, wenn Rudi mitspielt. (seperates attr in FHEM2FHEM welche devices direkt an cloneDummy gehen, damit diese nicht doppelt als reading auftauchen, ggf in Verbindung mit autocreate.
- Rückkanalfähigkeit erstellen.
das alles wird aber dauern, es sei denn es liefert wer einen fertigen patch.

ZitatFunktioniert longpoll eigentlich für den State, welcher via stateformat generiert wird? Bei mir funktioniert es derzeit leider nicht.

habe ich noch nicht probiert, bin noch beim Portieren meine 1-Wire installation auf die FB7390

Gruß Joachim

Zitat von: justme1968 am 23 März 2014, 14:51:40
state hat leider eine sonderstellung unter den readings und es ist technisch nicht möglich es über notifys und events eindeutig zu erkennen und zu parsen.

Jetzt sind wir schon drei, die versuchen, groby diese Tatsache klarzumachen :P

schön das man hier der Meinung ist mir etwas erklären zu müssen...

Es ändert aber nichts an der Tatsache das es so nicht funktioniert. Die WetterStation verwendet kein "stateFormat" und liefert nur diesen SammelEvent alle 2 - 3 Minuten:

2014-03-23 22:44:50.061 CUL_HM WetterStation T: 3.5 H: 85 W: 4.8 R: 164.315 IR: 0 WD: 35 WDR: 45 S: 7 B: 9
2014-03-23 22:47:20.079 CUL_HM WetterStation T: 3.1 H: 85 W: 0 R: 164.315 IR: 0 WD: 0 WDR: 67.5 S: 7 B: 9
2014-03-23 22:49:36.125 CUL_HM WetterStation T: 2.8 H: 85 W: 0 R: 164.315 IR: 0 WD: 35 WDR: 67.5 S: 7 B: 9

Dieser wird mit cloneDummy in ein "T" reading kopiert:

"T"                 "3.5 H: 85 W: 4.8 R: 164.315 IR: 0 WD: 35 WDR: 45 S: 7 B: 9"


D.h. es gibt keinen "temperature" Event und auch keine weiteren. Das geclonte "T" reading kann man aber nicht mit "stateFomat T: T" wieder hinbiegen - Jedenfalls nicht ohne irgendwelche Kunstgriffe...

Wie Andre in seinem vorherigen Beitrag bereits erwähnt hat - gibt es keine Möglichkeit state Events eindeutig zu erkennen. Deshalb ist cloneDummy für diese Art von Events z. Zt. unbrauchbar. Dies betrifft alle Devices die per Default mit Multireadings im state arbeiten:

HKThermostat    T: xx desired: xx valve: xx
Wetterstation     siehe oben
Thermometer     T: xx H: xx


Um diese Events also sinnvoll zu verarbeiten muss das Modulpro cloneDevice wisssen, welche readings wie identifiziert bzw. gesplittet werden sollen (evtl. per attribut):

attr cloneDevice Wetterstation,T,H,W...
attr cloneDevice HKThermostat,T,desired,valve


Ein einzelnes "T"-reading hilft hier nicht...

Deswegen verwende ich weiterhin auf fhem2 einen notify der mir "state" Events in multiple readings splittet - ob das sinnvoll nicht oder nicht ist mir als Anwender ziemlich egal - denn es funktioniert...

Du brauchst nicht zum 728. Mal beschreiben, dass der ankommende Eintrag unbrauchbar gesplittet wird. WIR haben das immerhin längst verstanden.

Um welchen Typ Homematic-Wetterstation geht es eigentlich?

KS550|KS888|HM-WDS100-C6-O sind laut Coding in der 10_CUL_HM.pm sehr wohl in der Lage, auch einzelne Readings mit Wetterdaten zu liefern, die sich dann problemlos in ein userReading oder per stateFormat verarbeiten lassen. Kann es sein, dass Du die Erzeugung der einzelnen Readings mit event-on-change deaktiviert hast?

Komisch. Irgendwie klingelt mir immer noch die Frage nach Event-Logs und defines im Ohr...

HM-WDS100-C6-O

Zitat von: Groby am 24 März 2014, 05:35:16
HM-WDS100-C6-O

Die kann defintiv Einzelreadings liefern.

Edit: wie es der Zufall will, hat hier sogar grade jemand ein Beispiel gepostet  8) http://forum.fhem.de/index.php/topic,21762.msg152250.html#msg152250

Schön das Du es nachschauen musstest - frag mich doch einfach  :P
Das weiss ich selber, wie sollte ich sonst Regenmengen usw. berechnen???

Der Lösungsvorschlag hat bei mir leider einen Schönheitfehler, denn wenn ich alle Einzelreadings meiner Battery Devices aktiviere, kommen die beiden FB7390 aus dem Tritt und quittieren es mit regelmässigen HML disconnects - natürlich nicht alleine wegen Events...

Jetzt kommt sicher wieder: "Dann nimm doch einen rpi oder bbb." Will ich aber nicht!!!

Somit ist das Modul für mich keine Hilfe und ich bleibe bei meiner fhem2fhem/notify Lösung, wo ich mit den vorhandenen Events klarkomme...

Allerdings ist es ein komischer Lösungsansatz am Source mehr Evebts zu generieren, um eine Lösung zu bekommen. Es sollten doch alle Events ausgewertet und geklont werden.

Wenn state für eine WetterStation dann nicht funktionert, dann gehört es auch nicht in ein "T" reading...

Ich bin raus - trotzdem Danke für die Hilfe...

Moin Groby,

Reisende soll man nicht aufhalten!

Du solltest mal gründlich Deine Anspruchshaltung überprüfen
Wie ich mehrfach betont habe, bin auch ich Perl Anfänger, und habe um etwas Zeit gebeten.
FHEM ist openSource, und jeder hier macht das freiwillig, da ist Deine Art dann schon sehr aufdringlich, schliesslich sind wir hier in einem Forum, und wenn dann kurz nach erstellung eines Modules der Autor gleich mit PM's vollgemüllt wird, finde zumindest Ich das aufdringlich.
Wenn man Dir Helfen will, und dann eine konkrete Bitte geäßert wird

ZitatMoin Groby,
Seit heute mogen sollte das Modul im regulären Update sein.
Dabei ist die standart Einstellung, dass der state von initialized nach active wechselt.
Ein stateFormat funktioniert bei mir einwandfrei, wenn Du dabei Probleme hast, dann brauche ich mehr Informationen.
- aussagekräftigen Auszug aus dem Eventmonitor
- komplette definition des Moduls mit den gesetzten attr

Gruß Joachim

und diese 3x ignoriert wird, schlimmer noch, die Antwort auch noch dumme Kommentare enthält:

Zitatalles was Du an Informationen brauchst, findest Du bereits in der letzten Antwort:

stimmt mich das ein etwas säuerlich.
Wenn man versucht, Dir zu Erklären, was Du offensichtlich noch nicht verstanden hast, gibt es auch wieder Dumme Kommentare:

Zitates mag sein, dass es programmiertechnisch einen Unterschied von state & STATE gibt.

Im WEB frontend liefern aber set und setstate das gleiche Ergebnis für mich. set mit Event & setstate ohne...

Zitatschön das man hier der Meinung ist mir etwas erklären zu müssen...

Viel Spass mit Deinen Notify's

Gruß von einem ziemlich angesäuerten Modulentwickler

@Joachim: Lass Dich nicht ärgern. Das Problem mit dem falsch gesplitteten Reading kriegen wir auch noch in den Griff, ich bin da schon am Testen ;)

moin @betateilchen,

ich auch, und deshalb brauche mal Hilfe von meinem "Modulpaten", bin halt Perlanfänger und habe eine Denkblockade.
Um das Problem mit dem state zu lösen habe folgendes versucht:

package main;

use strict;
use warnings;

sub cloneDummy_Initialize($) {
my ($hash) = @_;

$hash->{DefFn}     = "cloneDummy_Define";
$hash->{NotifyFn}  = "cloneDummy_Notify";
$hash->{AttrList}  = $readingFnAttributes;
}

sub cloneDummy_Define($$) {
my ($hash, $def) = @_;
my @a = split("[ \t][ \t]*", $def);
  return "Wrong syntax: use define <name> cloneDummy <sourceDevice> <optional STATE>" if((int(@a) < 3)) ;
return "Wrong syntax: use define <name> cloneDummy <sourceDevice> <optional STATE>" if((int(@a) > 4)) ;
  return "Wrong syntax: <name> must different to <sourceDevice>" if($a[0] eq $a[2]) ;

$hash->{NOTIFYDEV} = $a[2];
$hash->{NOTIFYSTATE} = $a[3] if(defined($a[3]));                 #<----- zusätzlich eingefügt
readingsSingleUpdate($hash,'state','defined',1);
Log3($hash,4,"cloneDummy: $a[0] defined for source $a[2]");
return undef;
}

sub cloneDummy_Notify($$) {
my ($hash, $dev) = @_;
my $dn      = $dev->{NAME};
my $hn      = $hash->{NAME};
my $hs      = $hash->{NOTIFYSTATE};
my $reading = $dev->{CHANGED}[0];
$reading = "" if(!defined($reading));
Log3($hash,4, "cloneDummy: $hn D: $dn R: $reading");

my ($rname,$rval) = split(/ /,$reading,2);
$rname = substr($rname,0,length($rname)-1);

my $state = "active";                                  #<----- zusätzlich eingefügt

if (($hs ne "") && ($rname eq $hs) ){                    #<----- zusätzlich eingefügt
Log3($hash,3, "hash: $hn state: $hs rname: $rname ");    #<----- zusätzlich eingefügt
        $state = $reading;                                       #<----- zusätzlich eingefügt
  }

readingsBeginUpdate($hash);
readingsBulkUpdate($hash, $rname, $rval);
readingsBulkUpdate($hash,'state', $state);               #<----- geändert
readingsEndUpdate($hash, 1);

return;
}

1;


dann 3 cloneDummys definiert:

define clon_sysmon cloneDummy sysmon ram
attr clon_sysmon room Sysmon

define clon1_sysmon cloneDummy sysmon loadavg
attr clon1_sysmon room Sysmon

define Bad cloneDummy TS_Bad
attr Bad room Sysmon
attr Bad stateFormat {sprintf("%.1f",ReadingsVal("Bad","Temperatur",0))." °C"}
Auszug Logfile:

2014.03.24 12:12:25.701 3: hash: clon1_sysmon state: loadavg rname: loadavg
2014.03.24 12:12:25.754 3: hash: clon_sysmon state: ram rname: ram

Beim ersten und letzten cloneDummy ist alles so, wie es sein soll, nur bei clon1_sysmon geht es nicht, und ich weiß nicht warum, kannst Du mir einen Tipp geben.

Danke Joachim

Mir ist nicht ganz klar, was Du damit bewirken willst?
Ich würde keinen neuen Parameter einführen, sondern die Sache viel pragmatischer lösen ;)

Lass uns das mal per email diskutieren.

Und nochmal - ganz wichtig - das Reading state gehört dem cloneDummy Device und niemandem anders!

Joachim,

wenn Dir eine PM mit der Anfrage ob Du Hilfe beim Testen brauchst aufdringlich erscheint und Dein Postfach zumüllt - dann hast Du eine komische Sicht der Dinge die ich zum Glück nicht teilen muss...

Wenn Du aufmerksam gelesen hättest, hättest Du sicherlich bemerkt, dass ich nicht erwarte habe das Du das sofort und nur für mich "fixt". Ich habe lediglich versucht klarzumachen was ich damit versuche umzusetzen. Aber das ist Dir sicher nur durchgerutscht...

So ist ein Softwaretest nunmal. Da tauchen Fehler auf - die einen kann man fixen, die anderen eben nicht. Die einen will der Developer lösen - die anderen nicht. Aber zum Thema Softwaretest / Development brauche ich sicher keine Belehrungen...

Mehr werde ich zu diesem Thema nicht beitragen...

MfGroby

Habe mit CloneDummy die Werte einer entfernten SYSMON-Instanz auf den Haupt-FHEM geholt. Funktioniert sehr gut! Danke für das nützliche Modul ;)

Grüße,

Alexander

Moin @ Alexander,

Wenn Du dabei ein stateFormat definiert hast, wie hast Du es definiert?

Danke Joachim

manchmal ist es echt frustierend, gegen Windmühlen zu kämpfen und sich scheinbar mit der Wand zu unterhalten...

@betateilchen,

Zitatmanchmal ist es echt frustierend, gegen Windmühlen zu kämpfen und sich scheinbar mit der Wand zu unterhalten...

wie meinst Du das?
Ich versuche doch gerade, das was Du mir per E-Mail geschrieben hast zu begreifen und umzusetzen.

Gruß Joachim

ZitatWenn Du dabei ein stateFormat definiert hast, wie hast Du es definiert?

SYSMON liefert alle Informationen in eigenen Readings. In State stehen keine wichtigen Informationen. StateFormat habe ich auch keinen. Oder wie hast Du Deine Frage gemeint?

Grüße,

Alexander

er meint die Windmühlen *g*

bei Dir ist also die Anzeige von cloneDummy wie im angehängten Bild von clon1_sysmon,
und nicht wie von clon_sysmon?

Gruß Joachim

je nach anwendungsfall ist SYSSTAT eventuell besser geeignet um ein remote system abzufragen.

gruss
  andre

andre, prinzipiell hast Du recht, hier soll aber kein remote System  "abgefragt" (im klassischen Sinn) werden ;)

Bitte nicht noch mehr Verwirrung hier reinbringen.

bin ja schon still ...

Zitat von: Joachim am 24 März 2014, 14:27:18
bei Dir ist also die Anzeige von cloneDummy wie im angehängten Bild von clon1_sysmon,
und nicht wie von clon_sysmon?

ja, da steht nur "active". Reicht  das jemanden nicht? ;) Man könnte bestimmt auch hier mit StateFormat ansetzen...

Zitat von: justme1968 am 24 März 2014, 14:44:55
je nach anwendungsfall ist SYSSTAT eventuell besser geeignet um ein remote system abzufragen.

sehe ich auch ein ;)
nehme zum Testen trotdem gerne SYSMON :P

@hexenmeister,

Zitat
ja, da steht nur "active". Reicht  das jemanden nicht? ;) Man könnte bestimmt auch hier mit StateFormat ansetzen...

Genau darum ging es mir, Und mit stateFormat gibt es das Problem, dass die fhem.pl versucht mitzudenken und den ersten Eintrag (also z.B. das ram) klaut. Auf jedenfall habe ich da keine Möglichkeit gefunden.
Habe da eventuell zwar schon eine Lösung, aber die muss erst noch auf Nebenwirkungen getestet werden.

Danke für Deine Rückmeldung.

Gruß Joachim

Hallo Joachim,

erstmal vielen Dank für das tolle Modul. Es sollte bald möglichst in der commandref von FHEM2FHEM erwähnt werden, dass es eine der dort angegebenen Einschränkungen beseitigt.

Ich hätte aber noch eine wichtige Bitte. Es ist leider nicht möglich, das Reading "state" eines Gerätes zu übergeben. Wäre es möglich, dies im Code zu berücksichtigen. Derzeit schneidet es ja nur vom ersten state-Wort ein Zeichen ab und legt es als Reading ab.
So wird aus:
2014.03.25 09:02:09 3: cloneDummy: RPi_Heizung D: Heizung R: Waermepumpe steht seit 02:59:39 - Keine Anforderung
das Reading "Waermepump" (ohne e) mit dem Wert "steht seit 02:59:39 - Keine Anforderung"
Besser wäre in diesem Fall (fehlender Doppelpunkt), ein separates "cloneState"-Reading anzulegen.

Noch eine Empfehlung: Vielleicht wäre es sinnvoll, die eingelesenen Werte nur im Verbose-Level 4 zu loggen anstatt wie jetzt im Level 3.
Vielen Dank nochmal für das Modul.

Tupol

Das Thema "state" wurde hier im Thread bereits seitenlang diskutiert.  "state" ist kein normales Reading und kann deshalb auch nicht so behandelt werden.

Aber eigentlich gibt es eine sehr einfache Lösung, die jeder User selbst umsetzen kann:

• Definiere im sourceDevice ein userReading _state:

attr <sourceDevice> userReadings _state:.* {ReadingsVal('<sourceDevice','state','')}[/li]
[li]Definiere im clone ein stateFormat: [/li][/list]attr <cloneDevice> stateFormat _state[/code[/li]
[/list]

Das userReading "_state" wird bei jedem Event (des sourceDevices) als normales Reading in das cloneDevice übertragen, dort schlägt das stateFormat zu und schreibt den Wert nach STATE.

Das sollte bereits die allermeisten Anwendungsfälle abdecken.


Hallo Betateilchen,

danke für den Hinweis. Über userreadings geht es natürlich auch. Allerdings wäre es einfacher, cloneState mit wenigen Codezeilen im Modul selbst zu implementieren. Dann habe ich auch kein abgeschnittenes "Waermepump"-Reading.

Gruß
tupol

jaja, wir arbeiten an den abgeschnittenen Readings. Aber wie gesagt: "state" ist sehr speziell.

ZitatEs sollte bald möglichst in der commandref von FHEM2FHEM erwähnt werden, dass es eine der dort angegebenen Einschränkungen beseitigt.

Bin dagegen.
- erstens finde ich nicht wirklich, dass es eine FHEM2FHEM "Einschraenkung" behebt, eher dass es damit sinnvoll kombinierbar ist.
- zweitens ist das commandref fuer solche Tipps&Tricks nicht der richtige Ort, das sollte eher in der Wiki beschrieben werden. Commandref konzentriert sich auf die Beschreibung einzelner Module, und beschreibt keine "Kochrezepte", wie man die Zutaten mischen soll.

*unterschreib*

noch dazu, wo die Funktionalität von cloneDummy keineswegs auf FHEM2FHEM beschränkt ist.

Moin tupol,

Ersteinmal Danke für Deine Rückmeldung.
Zu deinen Anmerkungen:
In Antwort 45 habe ich mal grob meinen gewünschten Fahrplan aufgeschrieben, in dieser Agenda steht das Portieren eines gewünschten Wertes in den STATE ganz oben. Wie betateilche schon geschrieben hat, ist das nicht so ganz einfach, das sauber hinzubekommen, da arbeiten wir dran, kann aber noch ein paar Tage dauern.
Das Problem mit dem Loggen war ein Fehler von mir beim Einchecken, ist auf jeden Fall in der nächsten Version draussen.

Gruß Joachim

Moin@all,

Es hat zwar einige Tage gedauert, einiges an Mühe gekostet, und SVN und ich sind auch noch nicht wirklich Freunde, aber das wird noch kommen.
Ich kann Euch allerdings mitteilen, dass eine neue Version vom cloneDummy im SVN liegt, bzw. morgen über das Update kommt.

Es gibt zwei Änderungen:

1.) das define wurde um einen Parameter erweitert, das neue define ist nun so:
define <name> cloneDummy <quellDevice> [reading]
in dem optionalen reading kann definiert werden, welches reading im State dargestellt werden soll. Damit sollten abgeschnittene readings der Vergangenheit angehören.

2.) es gibt ein Attribut, mit dem man readings ausschliessen kann, die auszuschliessenden readings müssen durch Kommata voneinander getrennt werden, wenn mehr als ein reading angegeben wird:
attr <name> cloneIgnore <reading1,reading2,...,readingX>

Im Anhang ein Beispielbild.

Viel Spass mit den Erweiterungen.
Rückmeldungen bitte in diesem Tread posten.

Gruß Joachim


P.S: Auch diesesmal habe ich wieder viel Hilfe von Betateilchen bekommen, bei dem ich mich dafür nocheinmal herzlich bedanke.

Hallo Joachim,

klasse Erweiterung und das doch in einem sensationellen Zeitrahmen :)

Ich hab noch kein Update durchgeführt, wurde auch das Logging von verbose 3 auf 4 umgestellt?

Gruß
Jens

Moin eldrik,

Danke für Deine Rückmeldung.

Und ja, das Logging ist auf verbose 4 gestellt.

Gruß Joachim

hihihi... das Logging war eigentlich von Anfang an und aus gutem Grund auf 4, aber irgendjemand hatte da eine 3 draus gemacht ...

Knurr, ja ich wars,
weil ich beim testen sehen wollte was passiert. und dann habe ich vergessen es vor dem ersten einchecken zurückzustellen.

Gruß Joachim

Zitat von: Joachim am 28 März 2014, 08:30:31
weil ich beim testen sehen wollte was passiert.

Tipp: Für Entwicklungstests nächstes Mal den verbose Level Deines laufenden fhem auf 4 stellen, nicht das Logging selbst ;)

Ja,ja
das wird mir nicht wieder passieren, Lerneffekt ist eingetreten.
Bin halt Anfänger.

Kannst Du mal bitte in der englischen commandref die folgende Zeile korrigieren:

<b>Important: You MUST use different names for cloneDevice and sourceDevice!</b><br/>

Da fehlt im Modul momentan das schliessende b-Tag.

Kann ich machen, aber erst heute abend, wenn ich Feierabend hab.

Gruß Joachim

ja, ist nicht dramatisch.

Ich hatte mich nur gewundert, warum die komplette commandref ab einer bestimmten Stelle plötzlich fettgedruckt ist und mich auf die Suche nach der Ursache gemacht  8)

Eingecheckt

Tipp: nächstes Mal bitte einen Eintrag in dem Comment-Feld eingeben, damit die Änderung mit Inhalt angezeigt wird.

(http://up.picr.de/17792098ou.png)

Hab das <b> Tag zum Pruefen in commandref_join.pl hinzugefuegt. cloneDummy ist ja jetzt gefixed, aber Martin sammelt dadurch noch mehr rote Punkte. Weiss jemand, ob auf dem aktuellen Sourceforge-Platform svn-pre-commit-hooks angeboten werden? Ich bin weder durch eine google-Suche noch durch Stoebern auf der sourceforge-Seite schlau geworden.

????
@ rudi,
was meinst Du?
Ich stehe mit SVN und der Übermittlung noch auf Kriegsfuss, abe ich hatte gesten abend das </b> schon hinzugefügt,

@ betateilchen,
es ist mir nicht gelungen,  einen Kommenttar hizuzufügen.
Das habe ich noch nicht verstanden.
Ich nutze TortoiseSVN.

Gruß Joachim

Meine Frage war eher fuer die subversion Experten gedacht.

Im Tortoise gibt es beim Einchecken ein leeres Feld (Message:, unter den Knopf "Recent Messages") bereit, wo man Text eingeben kann. Das muss man komplett ausfuellen, bevor man auf den OK Knopf drueckt.

Danke Rudi,
da hatte ich mich nicht getraut, was reinzuschreiben, da ich immer nach comment oder Kommentar gesucht habe.

Gruß Joachim

Zitat von: Joachim am 29 März 2014, 08:10:27
es ist mir nicht gelungen,  einen Kommenttar hizuzufügen.
Das habe ich noch nicht verstanden.
Ich nutze TortoiseSVN.

Wenn Du in TortoiseSVN auf "Übertragen" gehst, öffnet sich doch ein Fenster mit einem Eingabefeld. Dort gibst Du einfach den Kommentar ein, bevor Du auf OK klickst.
Bei Bedarf kann ich am Montag einen Screenshot machen, wenn ich im Büro bin. Hier zu Hause nutze ich Tortoise nicht.

Moin betateilchen,

der Tipp von Rudi hat, glaube ich, geholfen, habe vorhin nocheinmal eine leicht veränderte Version eingecheckt, und es hat scheinbar funktioniert.

Danke für Dein Angebot.

Gruß Jaochim

Danke für dieses praktische modul hat mir sehr geholfen meine 1wire Sensoren zu "clonen" :)

Dafür nicht.
Ich bitte um Rückmeldungen, wenn es Problene gibt.

Gruß Joachim

Mit der neu eingeführten Möglichkeit, dass auch "state" einen event erzeugt, sollte man vielleicht nochmal darüber nachdenken, wie man das hier nutzbar machen kann.

Moin Betateilchen,
habe ich heute auch schon gelesen, bin aber jetzt erst von der Arbeit zurück, und kann erst jetzt damit herumexperimentieren.
Wenn ich das richtig verstanden habe, erzeugt "STATE" einen Event, und der müsste jetzt schon mit dem optionalen reading Parameter abgreifbar sein.
Werde mir das mal ansehen.

Gruß Joachim

Zitat von: Joachim am 06 April 2014, 18:42:52
Wenn ich das richtig verstanden habe, erzeugt "STATE" einen Event,

nein, state sollte einen Event erzeugen, nicht STATE.

Hi,

ich hätte da noch einen Erweiterungsvorschlag für 98_cloneDummy.pm

Durch die ständig wechselnden Empfangsbedingungen betreibe ich neben meiner Haupt-fhem-Installation noch zwei kleinere fhem-Installationen auf RPis mit JeeLink USB-Stick. Zusammen ergeben die beiden 100% Empfangsabdeckung, wobei einige wenige Devices mal von einem, mal vom anderen empfangen werden, manche auch von beiden gleichzeitig.

Damit die Daten an zentraler Stelle wieder zusammengeführt werden können, heißen die Devices in beiden Instanzen gleich und erzeugen mithin identische Events, die per FHEM2FHEM dann in der Haupt-fhem-Installation und letztlich bei den cloneDummy Instanzen landen.

Soweit funktioniert das auch ganz gut, nur dass eben bei doppeltem Empfang auch jeweils zwei Events publiziert und ausgewertet werden. Für manche Readings läßt sich das gut mit event-on-change unterdrücken, bei Readings mit event-on-update werden aber weiterhin doppelte Events erzeugt, die in der Folge zu unnötigem Overhead in der Verarbeitung (notify, FileLOG, etc) führen.

Mein Vorschlag ist deshalb, cloneDummy dahingehend zu erweitern:

• Neues Attribut 'suppress-duplicates' -> Maximale Anzahl von Dupletten, die unterdrückt werden sollen (entspräche im Beispiel der Zahl von FHEM2FHEM Instanzen, die identische Readings liefern können)
• Neues Attribut 'duplicate-timeframe' -> Zeit in sec, innerhalb derer doppelte Readings unerwünscht sind (entspräche im Beispiel der typischen Zeit zwischen zwei vom Sensor ausgehenden Readings)
• Unterdücken eines Readings unter der Voraussetzung, dass
  
  
  
  • es zuvor ein nicht unterdrücktes Reading gleichen Namens und Wertes gab, dessen Zeitstempel nicht um mehr als 'duplicate-timeframe' abweicht, und
  • nicht bereits 'suppress-duplicates' solche Readings unterdrückt wurden

Wie seht Ihr diesen Vorschlag? Gibt es evtl elegante Möglichkeiten, das Gleiche mit fhem-Bordmitteln zu erreichen?

Bei Zustimmung würde ich mich gern an der Umsetzung versuchen und hier einen Vorschlag posten.

Grüße,
Andy.

es gibt in fhem einen zentralen mechanismus um doppelte nachrichten die durch rf wiederholungen z.b. bei fs20 entstehen zu unterdrücken.

vielleicht lässt sich hier direkt etwas wiederverwenden.

wenn du in fhem.pl und den modulen mal nach duplicate suchst findest du es.

gruss
  andre

Danke für den Tipp, das sieht in der Tat auf den ersten Blick schon ganz gut aus.

Grüße,
Andy.

Moin gandy,
Da ich das so z.Z. nicht testen kann, habe ich auch nichts gegen einen Patch.
Wenn ich Dich richtig verstanden habe, wird teilweise eine Nachricht von mehreren Empfängern empfangen, dann müsste der Zeitstempel ja sehr dicht beieinanderliegen, also sollte es reichen, Nachrichten in einem kurzen Zeitfenster, die doppelt sind zu filtern. Die Idee von andre klingt gut. Wenn das nicht auf die Performance schlägt, könnte man es fest einbauen, ansonsten per Attribut.
Werde mir auch mal Gedanken machen.

Gruß Joachim

Hi Joachim,

stimmt, die Zeitstempel liegen recht dicht beieinander und der Tipp von Andre war Gold wert (Danke, Andre!), im Grunde ist die Sache mit einer Zeile zu erledigen. Im Anhang mein Vorschlag als komplettes Modul, hier die Ausgabe des Logs für verschiedene Instanzen des Moduls:


2014.05.05 21:34:11.977 2: cloneDummy: publish unique <EC3kMM> <PowerMeterMM> <consumption: 10.661>
2014.05.05 21:34:11.992 2: cloneDummy: drop duplicate <EC3kMM> <PowerMeterMM> <consumption: 10.661> ***
2014.05.05 21:34:11.995 2: cloneDummy: publish unique <EC3kMM> <PowerMeterMM> <power: 52.7>
2014.05.05 21:34:12.011 2: cloneDummy: publish unique <EC3kMM> <PowerMeterMM> <powerMax: 90.9>
2014.05.05 21:34:12.015 2: cloneDummy: publish unique <EC3kMM> <PowerMeterMM> <52.7>
2014.05.05 21:34:12.398 2: cloneDummy: publish unique <EC3kTM> <PowerMeterTM> <consumption: 43.393>
2014.05.05 21:34:12.413 2: cloneDummy: drop duplicate <EC3kTM> <PowerMeterTM> <consumption: 43.393> ***
2014.05.05 21:34:12.415 2: cloneDummy: publish unique <EC3kTM> <PowerMeterTM> <power: 167.9>
2014.05.05 21:34:12.421 2: cloneDummy: publish unique <EC3kTM> <PowerMeterTM> <powerMax: 271>
2014.05.05 21:34:12.423 2: cloneDummy: publish unique <EC3kTM> <PowerMeterTM> <167.9>
2014.05.05 21:34:12.741 2: cloneDummy: publish unique <EC3kKS> <PowerMeterKS> <consumption: 31.297>
2014.05.05 21:34:12.745 2: cloneDummy: publish unique <EC3kKS> <PowerMeterKS> <power: 70.7>
2014.05.05 21:34:12.749 2: cloneDummy: publish unique <EC3kKS> <PowerMeterKS> <powerMax: 597.3>
2014.05.05 21:34:12.757 2: cloneDummy: publish unique <EC3kKS> <PowerMeterKS> <70.7>
2014.05.05 21:34:14.304 2: cloneDummy: publish unique <EC3kGS> <PowerMeterGS> <consumption: 47.43>
2014.05.05 21:34:14.306 2: cloneDummy: publish unique <EC3kGS> <PowerMeterGS> <power: 0>
2014.05.05 21:34:14.309 2: cloneDummy: publish unique <EC3kGS> <PowerMeterGS> <powerMax: 2164.9>
2014.05.05 21:34:14.397 2: cloneDummy: publish unique <EC3k02> <PowerMeter02> <consumption: 1.554>
2014.05.05 21:34:14.410 2: cloneDummy: drop duplicate <EC3k02> <PowerMeter02> <consumption: 1.554> ***
2014.05.05 21:34:14.412 2: cloneDummy: publish unique <EC3k02> <PowerMeter02> <power: 0>
2014.05.05 21:34:14.416 2: cloneDummy: publish unique <EC3k02> <PowerMeter02> <powerMax: 91.7>
2014.05.05 21:34:14.596 2: cloneDummy: publish unique <EC3k01> <PowerMeter01> <consumption: 16.311>
2014.05.05 21:34:14.609 2: cloneDummy: drop duplicate <EC3k01> <PowerMeter01> <consumption: 16.311> ***
2014.05.05 21:34:14.611 2: cloneDummy: publish unique <EC3k01> <PowerMeter01> <power: 5.2>
2014.05.05 21:34:14.617 2: cloneDummy: publish unique <EC3k01> <PowerMeter01> <powerMax: 30.3>
2014.05.05 21:34:14.620 2: cloneDummy: publish unique <EC3k01> <PowerMeter01> <5.2>
2014.05.05 21:34:14.749 2: cloneDummy: publish unique <EC3kWK> <PowerMeterWK> <consumption: 15.241>
2014.05.05 21:34:14.752 2: cloneDummy: publish unique <EC3kWK> <PowerMeterWK> <power: 0>
2014.05.05 21:34:14.755 2: cloneDummy: publish unique <EC3kWK> <PowerMeterWK> <powerMax: 1564.7>
2014.05.05 21:34:16.147 2: cloneDummy: publish unique <EC3kWM> <PowerMeterWM> <consumption: 22.885>
2014.05.05 21:34:16.149 2: cloneDummy: publish unique <EC3kWM> <PowerMeterWM> <power: 0>
2014.05.05 21:34:16.150 2: cloneDummy: publish unique <EC3kWM> <PowerMeterWM> <powerMax: 2090>


Wie weit die Duplikate zeitlich auseinander liegen dürfen, um als solche erkannt zu werden, wird über das global attribut dupTimeout (in sec., default 0,5) gesteuert. Das Modul läuft gerade im Dauertest, die ersten paar Stunden habe ich aber noch keine Probleme feststellen können.

Grüße,
Andy.

Edit: Anhang gemäß Nachricht #117 entfernt

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

Gruß joachim

Hi Joachim,

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

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...

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

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

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

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.

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

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.

@ gandy,

ZitatSo 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

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.

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

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

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

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.

hi joachim,

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

danke

Moin chris1284,
der Thread ist bei mir schon offen, und ich mache mir Gedanken.

Das Problem hängt mit der Sonderbehandlung von "state" und "STATE" zusammen.
Workaround fürs erste, mit stateFormat arbeiten, oder den optionalen Parameter "reading" füllen.
DEVTYPE und DEVFAMILY sind auch im Arbeit, hängt mit Antwort 117 zusammen.

Wenn ich eine Lösung habe, melde ich mich in dem Thread.

Gruß Joachim

schau mal hier: http://forum.fhem.de/index.php/topic,22029.msg156274.html#msg156274 (http://forum.fhem.de/index.php/topic,22029.msg156274.html#msg156274)

gruss
  andrfe

Moin andre,

genau da bin ich schon bei.
Da ich leider keine Ahnung vom Programmieren habe, dauert das alles bei mir etwas länger, habe mir aber schon die entsprechenden Zeilen aus notify geklaut, und versuche es jetzt nebenwirkungsfrei einzubinden.

Gruß Joachim

dann ist alles gut. das bekommst du hin.

gruss
  andre

Da bin ich ganz zuversichtlich.
Darf ich Dich danach als "Versuchskaninchen" mißbrauchen? ;D
Dann würde ich die geänderte Version zum testen und zur "Codeüberprüfung"  hier anhängen.

Gruß Joachim

klar schau ich es mir an.

gruss
  andre

@ all,
im Anhang mal eine neue Testversion vom cloneDummy.
Wenn ich keine Fehler eingebaut habe, sollte sie jetzt folgendes zusätzlich können:
- alle Readings des Devices übernehmen, und nicht nur das erste Gefundene.
- den Originalstate des Devices übernehmen, wenn addStateEvent gesetzt ist. Das geht z.Z. allerdings nur, wenn das zu clonende Device und cloneDummy auf dem gleichen FHEM laufen (FHEM2FHEM geht nicht, da ich noch nicht weiss, wie ich das original state dort bekomme).

Bitte testen, über den Code sehen und Rückmeldung geben.

Danke, gruß Joachim

Anhang entfernt, da fehlerhaft

das mit den mehrfach redings schaut gut aus. da hat jetzt bei mir alles funktioniert wie es soll.

mit state habe ich aber noch probleme gehabt:

- laut code sollte state in _state des cloneDummy landen. das war bei mir nicht der fall
- STATE stand plötzlich auf _state

gruss
  andre

Hallo andre,

da hat sich noch ein Fehler eingeschlichen, den ich suchen muss.
Danke ersteinmal für die Rückmeldung.

Gruß Joachim

So, Fehler eingekreist,
die Lösung gibt es aber nicht mehr heute (Fernsehzeit).

Gruß Joachim

Moin @ all,
Ich hoffe, die Fehler sind nun beseitigt, deshalb in der Anlage eine neue Testversion.
Wie oben schon angekündigt, sollte jetzt folgendes zusätzlich funktionieren:
- es sollen alle Readings des geklonten Devices übernommen werden
- es ist zusätzlich möglich, den Original "state" des geklonten Devices zu übernehmen (geht bei FHEM2FHEM noch nicht)

Die Rangfolge für "STATE" ist:
- wenn keine Vorgabe gemacht wurde, dann die Meldung von cloneDummy (initialized, active)
- wenn addStateEvent gesetzt ist, dann der "state" vom geklonten Device (dann kein "state" mehr vom cloneDummy)
- wenn das optionale reading im define gesetzt ist, dann der Wert davon (überstimmt die beiden vorherigen Zeilen)
- wenn stateFormat als attr gesetzt ist, toppt das alles

Gruß Joachim


Anhang entfernt, da die Änderungen im regulären Update sind

hi,

habe es seit gestern abend mal geteste und wie ich finde hat sich zu vorher nichts geändert :-)
aus dem original state des devices wird immer noch ein neues "unbrauchbares" reading T (siehe screenshot) welches das original garnicht hat

Zitat- wenn addStateEvent gesetzt ist, dann der "state" vom geklonten Device (dann kein "state" mehr vom cloneDummy)

kannst du dies bitte das hier näher erklären? was heißt 1 und was heißt 0. ich habe mal eine weile 1 und mal eine weile 0 gesetzt und es macht keinen unterschied ob 1, 0 oder attr addStateEvent gar nicht gesetzt.

der clone ist noch keine richtiges spiegelbild des originals:
vom ks300 wird avg_day schön im clone geschrieben, avg_month, cum_day, cum_month leider nicht (hier mal betateilchen fragen!?). Das readings die seit einsatz cloneDummy nicht im original geändert wurden auch nicht im clone geändert werden ist klar.

gruß
christian

Zitatder clone ist noch keine richtiges spiegelbild des originals: vom ks300 wird avg_day schön im clone geschrieben, avg_month, cum_day, cum_month leider nicht

Liegt daran, dass diese Werte zwar aktualisiert, aber nicht per Event verteilt werden. avg_month wird zwar einmal im Monat verteilt, das hast Du aber vermutlich nicht abgewartet. cum* sind Hilfsvariablen, und sollten nicht beachtet werden.

Zitat von: rudolfkoenig am 15 Mai 2014, 09:21:44
t, aber nicht per Event verteilt werden. avg_month wird zwar einmal im Monat verteilt, das hast Du aber vermutlich nicht abgewartet.

siehe scrennshot, avg_month wurde im original heute morgen aktualisiert.... zumindest laut timestamp 15.05.2014 (heute) 05:13:20

Zitat von: rudolfkoenig am 15 Mai 2014, 09:21:44cum* sind Hilfsvariablen, und sollten nicht beachtet werden

warum? für was werden sie benötigt und warum sollte man sie nicht beachten? wenn zb. hilfsmodule wie rain diese verwenden (weis ich nicht) wäre es toll diese im clone auf einem anderen system zu haben um dort evtl diese hilfsmodule zu nutzen.

ich hole mit zur zeit noch alle werte per notify und eigenem  "remote-module" ins 2. fhem system. und habe 1:1 das device als dummy (übrigens auch state 1:1 ) toll wäre es nun halt auf die notifys zu verzichten und alles über clone zu machen.

wie ich das sehe sollt genau das clone machen -> ein device dublizieren, nicht nur teile. und die krönung wäre natürlich wenn man einen klon im 2. system genau so verwursten könnte wie das original. sollte das nicht das ziel von clone sein muss ich das nur wissen, dann würde ich mich ausklinken.

Zitatsiehe scrennshot, avg_month wurde im original heute morgen aktualisiert

Du solltest mir mehr Glauben schenken, ich hab das Zeug programmiert.
Aktualisiert ja, verteilt nein, schliesslich will ich nicht taeglich ein avg_month in meinem Logfile haben.

Zitatfür was werden sie benötigt und warum sollte man sie nicht beachten?

Weil das private Hilfsvariablen fuer die Durschnitssberechnung (avg_*) sind.

Zitatwenn zb. hilfsmodule wie rain diese verwenden

Dann haben sie Pech, wie gesagt, es sind _private_ Variablen.

Zitat von: rudolfkoenig am 15 Mai 2014, 09:49:42
Du solltest mir mehr Glauben schenken, ich hab das Zeug programmiert.
Aktualisiert ja, verteilt nein

des wegen frag ich ja, nur du weist ob es nur "aktualisert" oder auch wirklich ein event auslöst welches cloneDummy abarbeiten kann.
der zeitstempel heist für mich erstmal -> reading aktualisiert-> event auf das man reagieren kann.

Zitat von: rudolfkoenig am 15 Mai 2014, 09:49:42
Weil das private Hilfsvariablen fuer die Durschnitssberechnung (avg_*) sind... Dann haben sie Pech, wie gesagt, es sind _private_ Variablen.

danke für die nähere erleuterung, dann ist das so.

offtopic: schade das man gewisse readings nicht "verstecken" kann... würde auch bei sysmon zb die übersicht individueller gestaltbar machen. sicher auch was für andere module --> verbesserungsidee? -> ähnlich wie bei der raumauswahl ein fenster mit anzuzeigenden readings erfinden

Zitatschade das man gewisse readings nicht "verstecken" kann.

Der Entwickler kann sie, indem sie mit "." am Anfang benennt, genauso wie Attribute oder "interne" Werte.
Die cum_* Readings sind aelter als dieser Feature, und ich habe bisher noch nicht dran gedacht, sie zu aendern.

Zitatwürde auch bei sysmon zb die übersicht individueller gestaltbar machen.

Bin schon dabei für sysmon eine solche Möglichkeit zu implementieren. Eine globale Feature wäre natürlich noch besser.

Edit:
Wenn es Dir nur um die Darstellung geht, kannst Du jetzt schon mit einem WebLink und einer Methode im Sysmon (s. Commandref) die Readings für die Anzeige frei bestimmen.

Moin chris1284,

danke erst einmal fürs testen.

jetzt zu Deinen Anmerkungen:

Zitataus dem original state des devices wird immer noch ein neues "unbrauchbares" reading T (siehe screenshot) welches das original garnicht hat

Da ich keine Glaskugel habe, werden hier weitere Informationen benötigt:
- definition vom clone (ist das optionale reading T im define gesetzt?)
- läuft der clone auf dem gleichen FHEM (der original "state" geht bei FHEM2FHEM nicht!)

folgende Einträge sind als def und attr möglich:

define <name> cloneDummy <quellDevice> [reading]
attr <name> cloneIgnore <reading1,reading2,...,readingX>
attr <name> addStateEvent 1 # 0 ist Vorgabe

wobei
[reading] das Reading ist, welches in den "STATE" geschrieben wird, wenn es gesetzt ist
und addStateEvent 1 den "state" des originaldevices übernimmt (nicht bei FHEM2FHEM)
zur Rangfollge:

Zitat
Die Rangfolge für "STATE" ist:
- wenn keine Vorgabe gemacht wurde, dann die Meldung von cloneDummy (initialized, active)
- wenn addStateEvent gesetzt ist, dann der "state" vom geklonten Device (dann kein "state" mehr vom cloneDummy)
- wenn das optionale reading im define gesetzt ist, dann der Wert davon (überstimmt die beiden vorherigen Zeilen)
- wenn stateFormat als attr gesetzt ist, toppt das alles

ansonsten ist es z.Z. noch so, dass ich nur das abgreifen kann, was durch FHEM bzw. FHEM2FHEM an Daten zu verfügung gestellt wird. (so wie Rudi schon geschrieben hat.)
Irgendwann in weiter Ferne soll cloneDummy wirklich ein Device komplett clonen können, aber dahin ist es für mich mangels Perl Kenntnissen noch ein weiter Weg, es sei denn Perl und FHEM Wissende helfen hier tatkräftig.
Der aktuelle Anhang soll wie in Antwort 130 geschrieben, folgendes können:

Zitat- es sollen alle Readings des geklonten Devices übernommen werden
- es ist zusätzlich möglich, den Original "state" des geklonten Devices zu übernehmen (geht bei FHEM2FHEM noch nicht)

und das sollte getestet werden.

@ Rudi,
habe ich Dich richtig verstanden, dass nicht alles, was im original Device als reading gelistet ist, auch wirklich als event herausgegeben wird?
Das würde ich als unglücklich empfinden, da es m.M.n der Systematik widerspricht.
Hilfsvariablen gehören nach Internals.

Gruß Joachim

Zitathabe ich Dich richtig verstanden, dass nicht alles, was im original Device als reading gelistet ist, auch wirklich als event herausgegeben wird?

Richtig, Parameter 4 bei readings*Update

ZitatHilfsvariablen gehören nach Internals.

Diese werden nicht gespeichert.

grrrrrr >:(

Zitat von: Joachim am 15 Mai 2014, 11:52:36
Moin chris1284,
- definition vom clone (ist das optionale reading T im define gesetzt?)
- läuft der clone auf dem gleichen FHEM (der original "state" geht bei FHEM2FHEM nicht!)

hi,

zu 1. nein. hier die definition define KS300Clone cloneDummy KS3000
zu 2.  clone läuft auf einer anderen instanz als das original device, verbunden mit fhem2fhem im log-modus

clone dummy nimmt das reading state des originals

Zitat
namereading                  wert                                      timestamp
state                       T:8.1 H: 81 W: 0.8 R: 0.0              2014-123456

schneidet das wort "state" raus, nimmt schienbar an das T: die bezeichnung für das reading ist und nimmt den rest dahinter als value

raus kommt im clone ein neue reading mit namen "T" und value "8.1 H: 81 W: 0.8 R: 0.0"  (sehr gut in den screenshots zu erkennen, nun mal farblich markiert). ich dnek hier wird state vom original nur falsch zerlegt

define KS300Clone cloneDummy KS3000 T

und nein,

Zitat
clone dummy nimmt das reading state des originals
Zitat

    namereading                  wert                                      timestamp
    state                       T:8.1 H: 81 W: 0.8 R: 0.0              2014-123456


schneidet das wort "state" raus, nimmt schienbar an das T: die bezeichnung für das reading ist und nimmt den rest dahinter als value

es wird von FHEM nur ungeschickt übergeben, die Information "STATE" wird garnicht mitgeliefert.

cloneDummy kann nur die Readings abgreifen, die Du auch im Eventmonitor, auf dem das Original Device läutf sehen kannst.

Gruß Joachim

Zitat von: Joachim am 15 Mai 2014, 12:26:14
define KS300Clone cloneDummy KS3000 T

funktioniert soweit das er nun den state sauber übernimmt und und in _state anzeigt , daumen hoch
das reading T wir dennoch angelegt... habe ich aber mit "cloneIgnore T" unterdrücken können, funktioniert und sieht wieder sauber aus.


gibt es einen bestimmten grund warum du "_state" anlegst und nicht einfach state überschreibst wenn so definiert?
ich würde einfach state mit dem im define vorgegebenen wert überschreiben. _state extra anzulegen...

habe dein modul dahingehend bei mir geändert :

zeile 43 auskommentiert   #$attr{$hn}{stateFormat} = "_state" if(defined($a[3]));
zeile 59 auskommentiert   #readingsSingleUpdate($hash,"state", "active",1);
zeile 74 auskommentiert   #readingsBulkUpdate($hash,"_state", $reading); und

ZitatreadingsBulkUpdate($hash,"state", $reading);

hinzugefügt
danach ein

  elsif($hs eq "")
  {
readingsBulkUpdate($hash,"state", "active");
  }

jetzt haben meine clonedummys auch den state 1:1 wie das original und kein _state mehr. devices für die kein state im define vorgegeben sind bleiben weiterhin "active" / "defined"

evtl nimmst du die änderung ja auf. der ASH2200Clone ist ein beispiel mit meinen änderungen wenn kein state-reading definiert ist, der ks300 eines mit T als state definiert.
und das angepasste modul auch mal angehängt, zum testen muss das clonedevice ggf neu definiert werden / attr stateformat gelöscht. damit sieht es dem original-device zum verwechseln ähnlich ;-)

Moin chris1284,
wenn Du diesen Tread noch nicht von Anfang an gelesen hast, dann lese ihn bitte mal von Anfang an, danach sollte Deine Frage

Zitat
gibt es einen bestimmten grund warum du "_state" anlegst und nicht einfach state überschreibst wenn so definiert?

Beantwortet sein.
Was Du in dem Modul für Dich änderst, ist mir egal.

Gruß Joachim

Zitat von: Joachim am 15 Mai 2014, 19:31:18
Moin chris1284,
wenn Du diesen Tread noch nicht von Anfang an gelesen hast, dann lese ihn bitte mal von Anfang an, danach sollte Deine Frage Beantwortet sein.
Gruß Joachim

habe ich mir angesehen (ich denke du meinst Antwort #71 vom betateilchen). und finde das meine eingriffe damit nicht auf kriegsfuss stehen.

EDIT: evtl durch mich falsch aufgefasst

Moin chris1284,
Ich wollte  Dich auch nicht angreifen, nur ich war diese Diskussion um "state" "STATE" sowas von satt, dass ich da nicht wirklich Lust hatte, das Thema nocheinmal anzugehen, es war schon schwierig genug, diesen Kompromiss zu finden, und als nichtProgrammierer war das das Beste, was herauszuholen war.
Natürlich war und ist es mein endgültiges Ziel, echte Klone von entfernten Devices zu schaffen, inclusive dem gleichen Namen, und mit allen Möglichkeiten, die das Originals hergibt. Das übersteigt allerdings z.Z. meine Möglichkeiten bezüglich Wissen und Zeit. Dein Ansatz mit RFHEM hilft mir da schoneinmal gewaltig.
Wenn Du interesse hast, kann man sich da sicherlich zusammentun.
RFHEM als Backendmodul und cloneDummy als Frontend.

Gruß Joachim

Moin @ all
die Testversion wurde 10 mal heruntergeladen, 2 mal gab es Feedback, ich gehe davon aus, dass es so läuft, wie es soll,
von daher ist ab 8:00 geänderte Version im Update.

Änderungen:

Neues Attribut addStateEvent hinzugefügt, vorgabe ist 0, wenn auf 1 gesetzt, dann wird der STATE des geklonten Devices als STATE übernommen. Achtung, das geht noch nicht wenn cloneDummy ein Device über FHEM2FHEM klont.

Es werden alle Readings des originalDevices, die auch im EventMonitor zu sehen sind geklont.

Die Rangfolge für "STATE" ist:
- wenn keine Vorgabe gemacht wurde, dann die Meldung von cloneDummy (initialized, active)
- wenn addStateEvent gesetzt ist, dann der "state" vom geklonten Device (dann kein "state" mehr vom cloneDummy)
- wenn das optionale reading im define gesetzt ist, dann der Wert davon (überstimmt die beiden vorherigen Zeilen)
- wenn stateFormat als attr gesetzt ist, toppt das alles

viel Spass damit.

@ andre,

Zum Thema zusammenführen von cloneDummy und readingsProxi.
Ich werde mich jetzt mal mit readingsProxi befassen, und dann mal einen Vorschlag in diesem Thread machen.
Mein gedanklicher Fahrplan für cloneDummy ist:
cloneDummy Stück für Stück in die Richtung weiterzuentwickeln, dass es einen kompletten Klon eines Devices erstellen kann, inclusive Rückkanalfähigkeit bei FHEM2FHEM Verbindung. Dabei sollen wahlweise einzelne oder alle Informationen des original Devices in den Klon übernommen werden können.

Gruß Joachim

Hallo Joachim,

ich habe hier
http://forum.fhem.de/index.php/topic,24579.0.html (http://forum.fhem.de/index.php/topic,24579.0.html)
erstmal im Anfängerbereich meine Frage gestellt und groby hat mir einen Workaround geliefert.

Nun zu meinem eigentlichen "Problem".
Ich benutze cloneDummy noch nicht lange daher bitte um Nachsicht wenn ich was falsch konfiguriert habe.
Ich habe auf einem RasPi FHEM mit FHEM2FHEM an meine Hauptinstallation gekoppelt und mit cloneDummy 2 Geräte auf die entfernte Installation geklont.
Das hat auch einwandfrei geklappt und ich kann die Readings wunderbar auswerten.
Nur liefert mir $now in einem notify auf eines der geklonten Geräte nur Müll und ich habe absolut keine Ahnung woran das liegt.

So sind die beiden Geräte eingebunden:
define WetterstationEingang_extern cloneDummy Wetterstation_Eingang
attr WetterstationEingang_extern addStateEvent 1
define EG_Terrasse_extern cloneDummy EG_Terrasse
attr EG_Terrasse_extern addStateEvent 1

Wetterstation_Eingang ist eine KS300
EG_Terrasse ist ein HM-WDS10-TH-O

Mit diesem Code (eines lokal erzeugten Dummy):
Dummy1:(Ein|Aus) {
my $now=sprintf("%02d:%02d",$hour,$min);
  Log(3,"$now");
}
erhalte ich im Logfile

Zitat2014.06.15 11:37:08 3: 11:37

Mit diesem Code (der auf die beiden entfernten und per cloneDummy eingebundenen Geräte reagiert resp. auf deren Reading temperature):
(EG_Terrasse_extern|WetterstationEingang_extern):temperature.* {
  my $now=sprintf("%02d:%02d",$hour,$min);
  my $temp_terrasse = ReadingsVal("EG_Terrasse_extern","temperature",38);
  my $wind=ReadingsVal("WetterstationEingang_extern","wind",52);
  my $temp_wetterstation=ReadingsVal("WetterstationEingang_extern","temperature",78);
  Log(3,"$now");
  Log(3,"$temp_terrasse");
  Log(3,"$wind");
  Log(3,"$temp_wetterstation");
}
erhalte ich diese Ausgabe:

Zitat2014.06.15 11:39:09 3: temperature: 19.302d:temperature: 19.302d
2014.06.15 11:39:09 3: 21.3
2014.06.15 11:39:09 3: 0.0
2014.06.15 11:39:09 3: 19.3

Als Wert wird hier anscheinend $EVENT "fehl-"interpretiert.

cloneDummy hat diese Version:

Zitat# $Id: 98_cloneDummy.pm 5919 2014-05-21 05:03:48Z joachim09876 $

Ein update check liefert mir keine neuere Version für cloneDummy.

Wenn du noch was benötigst (und davon gehe ich mal aus) dann nur her damit.
Ich werde versuchen dir die gewünschten Daten zu liefern.

Wenn mein "Problem" aber nichts mit cloneDummy zu tun hat dann kannst du meinen Beitrag hier bitte gerne löschen.

Grüße

Edith: Der einzige Unterschied zwischen beiden Code-teilen ist einmal ein lokal existierender Dummy und einmal die 2 Geräte per cloneDummy.
Ein anderer Unterschied fällt mir im Moment nicht auf/ein.

Moin Puschel,
der cloneDummy verarbeitet nur das, was man auch im Eventmonitor sieht.
schicke bitte mal den passenden Auszug aus dem Eventmonitor.
Ich sehe mir das morgen an, heute schaffe ich das nicht mehr.

Gruß Joachim

Hallo Joachim,

hier mal der EventMonitor vom KS300:

Zitat2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern T: 21.1 H: 41 W: 0.0 R: 18.9 IR: no Wi: 0
2014-06-15 20:20:12 KS300 Wetterstation_Eingang T: 21.1 H: 41 W: 0.0 R: 18.9 IR: no Wi: 0
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern rain: 18.9
2014-06-15 20:20:12 KS300 Wetterstation_Eingang rain: 18.9
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern wind: 0.0
2014-06-15 20:20:12 KS300 Wetterstation_Eingang wind: 0.0
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern humidity: 41
2014-06-15 20:20:12 KS300 Wetterstation_Eingang humidity: 41
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern temperature: 21.1
2014-06-15 20:20:12 KS300 Wetterstation_Eingang temperature: 21.1
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern israining: no
2014-06-15 20:20:12 KS300 Wetterstation_Eingang israining: no
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern statRain: Hour: 0.0 Day: 2.3 Month: 3.1 Year: 3.1 (since: 2014-06-09 )
2014-06-15 20:20:12 KS300 Wetterstation_Eingang statRain: Hour: 0.0 Day: 2.3 Month: 3.1 Year: 3.1 (since: 2014-06-09 )
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 KS300 Wetterstation_Eingang statRain: Hour: 0.0 Day: 2.3 Month: 3.1 Year: 3.1 (since: 2014-06-09 )
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern statTemperature: Hour: -0.5 Day: 3.3 Month: 0.1 Year: 0.1 (since: 2014-06-09 )
2014-06-15 20:20:12 KS300 Wetterstation_Eingang statTemperature: Hour: -0.5 Day: 3.3 Month: 0.1 Year: 0.1 (since: 2014-06-09 )
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:12 cloneDummy WetterstationEingang_extern dewpoint: 7.3
2014-06-15 20:20:12 KS300 Wetterstation_Eingang dewpoint: 7.3
2014-06-15 20:20:13 cloneDummy WetterstationEingang_extern active
2014-06-15 20:20:13 cloneDummy WetterstationEingang_extern absFeuchte: 6.6
2014-06-15 20:20:13 KS300 Wetterstation_Eingang absFeuchte: 6.6

ZitatIch sehe mir das morgen an, heute schaffe ich das nicht mehr.

Kein Problem.
Es ist jetzt nicht dringend da mir ja der Workaround von groby hilft die Uhrzeit in eine Variable zu bekommen.
Mich wundert nur das sich irgendwas beim formatieren der Uhrzeit in die Quere kommt.

Wie gesagt: Device lokal angelegt und per notify drauf triggern ermittelt die richtige Uhrzeit.
Nur bei einem Event eines cloneDummy klappt das nicht.

Aber danke schonmal.

Grüße

Hi,

ich habe ein reproduzierbares Problem, mit cloneDummy und zwar werden userreadings, welche die Funktion differential verwenden nicht gefüllt.

Als Beispiel aus dem Wiki:

http://www.fhemwiki.de/wiki/Heizleistung_und_Gasverbrauch

gasleistung differential { gasenergie('C_GASZAEHLER',ReadingsVal("C_GASZAEHLER","counters.A",0));;}

Hole ich mir den 1Wire Counter via clonedummy über fhem2fhem in meine fhem Hauptinstanz werden alle das Wikibeispiel betreffende Werte, bis auf das userreading mit differential, korrekt gefüllt.

Ich würde meine fhem2fhem Instanzen gerne frei von irgendwelchen Berechnungen halten und diese Zentral, in meiner 99_myUtils.pm der Hauptinstanz pflegen, wahrscheinlich ist dies mit cloneDummy jedoch nicht möglich oder?

Greetz
Eldrik

Ich habe hierzu eine Frage:
Bei mir erscheinen die Readings doppelt, und ein Eintrag jeweils 1 Zeichen verkürzt.
Woran liegt das? Wie kann man es beheben?


define VaillantSystemdruckWertVomHeizraum cloneDummy VaillantSystemdruck Systemdruck
attr VaillantSystemdruckWertVomHeizraum room Vaillant



Readings
Systemdruc Status: ok 2015-01-01 21:38:02
Systemdruck 2.63 Bar 2015-01-01 21:38:02
VaillantSystemdruc Systemdruck 2.63 Bar, Systemdruck Status ok 2015-01-01 21:38:02
VaillantSystemdruck Systemdruck 2.63 Bar, Systemdruck Status ok 2015-01-01 21:38:02
_state Systemdruck: 2.63 Bar 2015-01-01 21:38:02
state active 2015-01-01 21:38:02


Viele Grüße,
Heiko

Was ich bemerkt habe:

Bei clonedummy von zb "SYSSTAT" von meiner Synology haut er zb diese Readings rein:
Denke komm vom State. weil der 0.3 0.35 0.25 wäre

0.3                              0.35 0.25 2015-08-08 12:01:16
0.4                              1.57 0.88 2015-08-08 10:23:11
0.5                              0.39 0.28 2015-08-08 12:03:16
ca 50 einträge so^^

Dann zb beim Unwetter (UWZ) löscht er keine Readings, wenn die nicht mehr im Orginal vorhanden sind. Im Dummy bleiben diese aber noch.


"- es ist zusätzlich möglich, den Original "state" des geklonten Devices zu übernehmen (geht bei FHEM2FHEM noch nicht)"  Wäre super wenn das irgendwann geht^^

Vlt hat ja einer eine idee wie man das hinbekommt.

MfG

Andy

Hallo Joachim,

ich bin gerade dabei Dein Modul zu nutzen und habe eine Frage zum Attribut cloneignore. Kann ich dort mit regex Ausdrücken arbeiten und wenn ja wie? Habe versucht Readings mit demselben Startstring durch mac.* zu filtern. Leider ohne das gewünschte Ergebnis.

Beste Grüße
Torsten