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

Begonnen von Joachim, 21 März 2014, 08:07:34

Vorheriges Thema - Nächstes Thema

Joachim

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>
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

rudolfkoenig

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

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Joachim

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
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

betateilchen

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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

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.

betateilchen

#6
@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)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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 :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Joachim

#8
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
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

betateilchen

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

was meinst Du damit?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Joachim

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
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

rudolfkoenig

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.

betateilchen

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

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Joachim

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
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

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

FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232