Hallo,
ich arbeite derzeit an der Einbindung eines Gerätes, das digitale Signale erkennt und zur Verarbeitung an FHEM sendet.
Das Gerät basiert auf einem Arduino, der Teil funktioniert auch schon recht gut.
Perl ist nicht gerade mein Zuhause und ich bin gerade etwas am überlegen wie ich die Integration in FHEM möglichst flexibel gestalte.
Der grundlegende Aufbau von Modulen für pyhsische Geräte und logische Module ist mir klar, wenn ich auch nicht alle Details verstanden habe.
Folgend der Grundaufbau:
Arduino <-> FHEM <-> pyhisches Modul <--> Logisches Modul 1
|-> Logisches Modul 2 ... n
Soweit nichts besonderes. Die Logischen Module werden ja zum einen über die clientlist eingebunden und über die Matchlist mir Daten versorgt.
Frage 1: Die Clientliste wird üblicherweise im Define gesetzt.
sub
modul_Define {
..
$hash->{Clients} = $clients;
$hash->{MatchList} = \%matchList;
..
}
Ich stelle mir vor, dass man die Clientliste über ein Attribut modifiziert.
Hat das schon mal gemacht? Auf Attribute kann ich ja vermutlich noch nicht zugreifen, wenn die define sub aufgerufen wird und in der Funktion X_Attr steht die Geräteinstanz nicht zur Verfügung.
Wir könnte ich so etwas bewerkstelligen?
Frage 2:
Ich möchte einen Hash im physischen Modul speichern, woraus Werte an den Arduino übermittelt werden.
Soweit kein Problem:
package main;
my %ProtocoolListModulname
Ich gehe davon aus, dass diese Variable global definiert ist, da sich alles in package main befindet und somit in allen Modulen verwendet werden kann?
Soweit ich verstanden habe, bindet FHEM ein Logisches Modul erst ein, wenn es sich in einer clientList befindet und wenn die Matchlist auf die eingehenden Daten passt.
Alternativ könnte ich auch die Variable in ein eigens package verfrachten und dann gezielt von den logischen modulen mittels use einbinden. Richtig?
Gibt es eine Möglichkeit, dass sich das logische Modul beim physischen sozusagen registriert?
Vom Ablauf her habe ich mir das in etwa so vorgestellt:
1. Anwender definiert ein physisches Gerät
2. FHEM lädt das Modul dazu
3. Anwender setzt als Attribut die submodule, welche er verwenden möchte
4. FHEM lädt mit Hilfe des phyischen Modules die submodule
5. FHEM ruft um submodul, sofern dieser dort vorhanden ist, eine subroutine auf.
6. Subroutine registriert sich am phyischen Modul damit Nachrichten anschließend am Submodul ankommen können
Vermutlich hört sich das jetzt ziemlich abenteuerlich an.
Auf die Idee bin ich aus folgendem Grund gekommen. Ich möchte das Modul für das physische Gerät möglichst flexibel gestalten und auch bestehende Module fest einbinden.
Andere Entwickler, sollen aber sehr einfach ihre logischen Module einbinden können. Am liebsten, ohne den code im phyischen Modul anpassen zu müssen.
Quasi, soll sich das logische Modul beim physischen anmelden und dem phyischen mitteilen, welche Daten es gerne hätte.
Grüße Sidey
schau dir mal das JeeLink modul an das hat Clients und MatchList attribute (und initCommands) über die sich beides zur laufzeit frei konfigurieren lassen. auch im CUL modul wird beides abhängig vom rfmode attribut dynamsich geändert. das ist also nicht so besonders als das es nicht schon gemacht würde.
um in deinem modul das setzen des attributs mitzubekommen gibt es die AttrFn.
gruss
andre
ja nach dem was du im physischen modul alles vor hast ist vielleicht sogar das JeeLink modul schon das was du brauchst und musst nur noch die logischen module entwickeln.
gruss
andre
Hallo Sidey,
alternativ nimmst Du ECMD/ECMDDevice und kannst damit ganz ohne programmieren zu müssen nur mit regulären Ausdrücken passend zum vom Arduino mit FHEM gesprochenen Protokoll vermutlich schon sehr viel erledigen.
Viele Grüße
Boris
Es ist zwar moeglich vom logischen Modul auf die privaten Daten des physikalischen Moduls zuzugreifen (geht sehr einfach ueber $hash->{IODev}, globale Variablen sind nicht noetig), allerdings funktioniert bei einem direkten Zugriff sowas wie FHEM2FHEM:RAW nicht mehr. Der empfohlene Weg ist nur IOWrite bzw. Dispatch zur Kommunikation zu verwenden.
Zitat von: Dr. Boris Neubert am 05 April 2015, 19:42:33
alternativ nimmst Du ECMD/ECMDDevice und kannst damit ganz ohne programmieren zu müssen nur mit regulären Ausdrücken passend zum vom Arduino mit FHEM gesprochenen Protokoll vermutlich schon sehr viel erledigen.
Hallo Boris,
das Modul ist interessant. Auch wenn ich das Modul für das physische Device schon recht weit habe, das würde mir doch so einiges abnehmen.
Wenn ich die Anleitung korrekt verstanden habe, kann ich Daten, welche unaufgefordert vom Arduino kommen mittels
"reading <reading> match "<regex>" empfangen und mittels reading <reading> postproc { <perl special> } verarbeiten.
Der perl Code kann sich ja bestimmt über mehrere Zeilen erstrecken denke ich mal.
Jetzt kommt natürlich eine neue Frage. Ich möchte nicht alles neu erfinden müssen.
Habe ich hier eine Chance mittels dispatch Daten z.B. an das Modul CUL_TX zu übergeben oder halt irgend ein anderes?
Die Module befinden sich ja nicht in der Clientlist und vermutlich kann ich die auch nicht im postproc des ECMDDevices mit aufnehmen, oder?
Grüße Sidey
Zitat von: Sidey am 05 April 2015, 20:53:52
Wenn ich die Anleitung korrekt verstanden habe, kann ich Daten, welche unaufgefordert vom Arduino kommen mittels
"reading <reading> match "<regex>" empfangen und mittels reading <reading> postproc { <perl special> } verarbeiten.
Der perl Code kann sich ja bestimmt über mehrere Zeilen erstrecken denke ich mal.
Korrekt. Fortsetzungszeilen mit \ beenden.
Zitat
Jetzt kommt natürlich eine neue Frage. Ich möchte nicht alles neu erfinden müssen.
Habe ich hier eine Chance mittels dispatch Daten z.B. an das Modul CUL_TX zu übergeben oder halt irgend ein anderes?
Die Module befinden sich ja nicht in der Clientlist und vermutlich kann ich die auch nicht im postproc des ECMDDevices mit aufnehmen, oder?
Du kannst die Daten nicht aus dem Modul heraus an andere Module übergeben.
Viele Grüße
Boris
Hallo Boris,
Zitat von: Dr. Boris Neubert am 06 April 2015, 17:56:05
Du kannst die Daten nicht aus dem Modul heraus an andere Module übergeben.
vielen Dank für die Info. Ich habe es schon befürchtet, dass es nicht geht.
Dein Modul ist top, habe mich gestern noch ein wenig damit beschäftigt. Daten empfangen und verarbeiten hat gut geklappt.
Wenn es nicht schon eine Menge Code gäbe der Signale auswertet usw. wäre es der beste Ansatz den ich bislang finden konnte.
Allerdings möchte ich unbedingt bestehende Module einbinden. An deinem Modul rumfrickeln, damit das möglich wird, möchte ich jetzt auch nicht.
Ich werde erst mal mit einem eigenen phyischen Modulen weitermachen und die Erweiterung der Clientliste über Attribute oder einen Set Befehl in Angriff nehmen.
Grüße Sidey