[FHZ] Modulfrage (Zusammenhang ParseFN/Dispatch())

[Guest]

Originally posted by: <email address deleted>

Moin!

Ich sitze grade an meinem SISPM-Modul, habe <20091026184748.GB28353@bzzz.fritz.box>
gelesen und frage mich nun, was ReadFn wo setzen/wie zurückgeben muß, damit
ParseFn eines logischen Gerätes diesen Text bekommt.

Soweit ich das bisher (vgl. 70_WS3600.pm) verstanden habe, wird meine gesetzte
ReadFn aufgerufen, wenn select() sagt, da seien Daten. Bei der WS3600 habe ich
diese ausgelesen, den Hash gefüllt und war fertig. (Naja, fast; da kam noch ein
InternalTimer() dazu, der die Abfrage neu startet.) Aber die WS3600 ist ja auch
ein read-only-Gerät.

SISPM möchte ich eigentlich ähnlich FS20 behandeln, d. h. ein physisches Device
wird definiert und liefert dann die vorhandenen Sockets samt Status zurück.
Diese Werte soll dann ein Modul für logische Geräte auswerten -- und dabei dann
auch von autocreate Gebrauch machen

Für die Trennung physisches/logisches Gerät brauche ich demnach zwei .pm-Dateien,
die für das logische muß in _Initialize() {$hash->{Clients} = ...;} eingetra-
gen werden, ja?

Ich versuche den Ablauf anhand 00_CUL.pm nachzuvollziehen; da wird keine
ParseFN definiert; aus CUL_Read() wird für jede Zeile allerdings die Funk-
tion CUL_Parse($hash, $hash, $name, $rmsg, $initstr) aufgerufen, die letzt-
lich Dispatch($hash, $dmsg, \%addvals) aufruft ...

Also stehe ich wohl vor der Frage, wie ich Dispatch() korrekt füttern muß,
ja? Dispatch() war in der Mail leider nicht beschrieben und reverse engi-
neering ist doof, wenn der Autor doch greifbar ist )

Danke & Ciao,
         kai


--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> Ich versuche den Ablauf anhand 00_CUL.pm nachzuvollziehen; da wird keine
> ParseFN definiert; aus CUL_Read() wird für jede Zeile allerdings die Funk-
> tion CUL_Parse($hash, $hash, $name, $rmsg, $initstr) aufgerufen, die letzt-
> lich Dispatch($hash, $dmsg, \%addvals) aufruft ...

CUL_Parse gibt es nur, damit man es auch aus CUL_RFR aufrufen kann. RFR
Nachrichten sind eigentlich nur mit Prefix versehene CUL Nachrichten.

Wenn select() was bekommt, dann wird ReadFn aufgerufen, der genau _ein_ sysread
absetzt. Wenn die Daten noch nicht komplett sind, dann wird das Bruchstueck
fuers naechste Mal gemerkt. Wenn eine komplette Nachricht vorliegt, dann wird
Dispatch damit aufgerufen.

CUL_Read macht noch einiges zusaetzlich:
- Falls nichts zu lesen ist, das Disconnect/Connect einleiten.
- RSSI abspalten
- FS20/FHT/HMS/KS300 ins bekloppte FHZ format umwandeln, damit wir nicht extra
  Module fuer ueber CUL empfangene Nachrichten bauen muessen

Dispatch wird mit dem iohash und die Nachricht aufgerufen. Optional kommt noch
ein Hash dazu, deren Werte (z.Bsp RSSI) auch bei dem vom Dispatch gefundenen
Device gespeichert werden.

Was ist SIS?

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:

[...]
> Dispatch wird mit dem iohash und die Nachricht aufgerufen. Optional kommt noch
> ein Hash dazu, deren Werte (z.Bsp RSSI) auch bei dem vom Dispatch gefundenen
> Device gespeichert werden.

Ah, und Dispatch ruft dann die passenden Module auf?

> Was ist SIS?

Per USB-Verbindung schaltbare Steckdosenleiste (Amazon s. [1]),
von Linux aus steuerbar [2]. Wird bei mir a) 2 FS20ST freimachen
und b) hoffentlich das Terrarium-Licht zuverlässiger schalten.

Rennt nicht an den 71er Fritzboxen (wg. AVMs Selbstbau-USB-Kram;
72er haben "echtes" USB), wohl aber u. a. auf dem SheevaPlug
Wie man damit seinen Laserdrucker nur einschaltet, wenn cups auch
was zu drucken in der Queue hat, hat ein Kollege skizziert [3] --
und mit der Integration in FHEM kann dann der Druckserver im Kel-
ler auch den Drucker im EG einschalten (Dumm ist nur, daß dann
Windows den Netzwerkdrucker über den Umweg CUPS ansprechen muß;
aber irgendwas ist ja immer.)
         kai

[1] http://www.amazon.de/6-fach-Steckdose-Silvershield-programmierbar-%C3%9Cberspannungsschutz/dp/B0010NY8YA/ref=pd_sim_ce_1
[2] http://sispmctl.sourceforge.net/
[3] http://blog.rfc822.org/index.php?/archives/37-cups-notifier-another-overengineered-feature.html

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Hallo Kai,

> Also stehe ich wohl vor der Frage, wie ich Dispatch() korrekt fuettern muss ,ja

Schau dir dochmal 99_GCI_RAWMSG an...hier die Funktion: sub
CGI_RAWMSG_Dispatch($$)
So ab hier # Dummy-Device... da ist auch ein Aufruf für disptach:

$hash->{"${name}_MSGCNT"}++;
$hash->{"${name}_TIME"} = TimeNow();
$hash->{RAWMSG} = $rawmsg;
my %addvals = (RAWMSG => $rawmsg);
my $ret_disp = &Dispatch($hash, $rawmsg, \%addvals);

$hash ist das IODev - Device
%addvals -> Daten werden ins Zeildvice der nachricht geschrieben z.B.
MyCUL_MSGCNT: 99

Vieleicht hilfts ja....


Schöne Grüße

Axel

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Salve,

danke für die Erklärungen soweit, den lesenden Part haben ich hinbe-
kommen ... Nun zum schreibenden, d. h. Interaktion FHEMs "set"-Funk-
tion und das rausschreiben zum Device:

Rudolf Koenig wrote:
> Es gibt zwei Arten von Geraeten, die man (wenn moeglich) nicht zu einem
> zusammenfassen sollte:
> - das Physische, was man also direkt am Rechner anschliesst, z.Bsp. FHZ/CUL
> - das Logische, was ueber das physisch angeschlossene indirekt gesteuert wird
>   (FS20, FHT)
>
> Im Initialize des Moduls spezifiziert man, welche Funktionen man unterstuetzt,
> die sind je nach Art des Geraetes unterschiedlich.
>
> Physische Geraete koennen folgendes setzen:
> - FD:     Filedescriptor, falls man die Daten per select pruefen kann (Unix)
>           Wird natuerlich erst nach dem "define" gesetzt.
> - Readyfn: Zum pollen, ob Daten da sind (Windows), bzw. ob das ausgestoepselte
>           Geraet wieder eingesteckt wurde.
> - ReadFn: Wird verwendet, falls das Geraet Daten meldet per select oder
>           ReadyFn. Holt die Daten ab, und stellt sie dem logischen Geraeten
>           zur Verfuegung, z.Bsp. via dem generischen Dispatch.
> - WriteFn:Wird von den logischen Modulen verwendet, um Daten zu schreiben. Die
>           logischen sind ueber das Attribut IODev mit dem Physikalischen
>           verbunden
> - Clients:Liste der moeglichen logischen Empfaenger. Die Daten werden allen
>            diesen Empfaengern angeboten
> - MatchList:Zuordnung (via regexp) von Nachricht an logisches Modul.
>           Wird verwendet, um eine Nachricht der Sorte:
>           "Unknown XXXX device detected, define one to get detailed
>           information"
>           Die Module selber koennen ja nicht gefragt werden, wenn noch kein
>           Geraet von dieser Sorte definiert wurde.
>
> Logische Geraete koennen folgendes setzen:
> - Match:  Regexp, um eine Nachricht vom Physischen entgegenzunehmen.
> - ParseFn:wird aufgerufen, falls die Nachricht "matched".
>           Liefert zurueck den Namen des betroffenen Geraetes, und setzt in
>           "CHANGED" Feld des betroffenen Geraetes die "neuen" Nachrichten,
>           (diese wird fuers Trigger verwendet und geloescht), bzw. in READINGS
>           verewigt.
>
> Funktionen fuer alle Geraete:
> - DefFn:  wird beim definieren oder umbenennen aufgerufen.
> - UndefFn:wird beim loeschen aufgerufen.
> - GetFn:  Optional, liefert Daten zurueck. Die Usage Meldung ist "stadard",
>           moegliche get Argumente werden z.Bsp von fhemweb hieraus extrahiert.
> - SetFn:  Optional, liefert keine Daten zurueck. Die Usage Meldung ist
>           "stadard", moegliche get Argumente werden z.Bsp von fhemweb hieraus
>           extrahiert.
> - StateFn:Setzt den Status des Geraetes, ohne irgendwelche Aktionen
>           auszufuehren, z.Bsp beim Hochfahren von fhem werden die zuletzt
>           gespeicherten Werte gesetzt.
> - AttrList:Liste der moeglichen Attribute. Nach einem Doppelpunkt folgen die
>           moeglichen Werte.
> - ShutdownFn: wird beim stoppen von fhem aufgerufen.
> - AttrFn: Prueft ob des setzen/loeschen bestimmter Attribute ok ist, bzw.
>           passt Interne werte an.
>
> Beispiel: Beim FS20 wandelt "set Lampe on" in einem langen hexadezimalen
> String um und ruft ueber IOWrite z.Bsp FHZ_Write auf der aus dem Hex
> Binaerdaten baut, und diese ans FHZ direkt schickt.

Und genau da liegt mein Problem -- ich kenne außer FS20 derzeit gar
keine anderen Geräte, die von FHEM gesteuert werden, und FS20 nutzt
nun grade *nicht* die WriteFn z. B. von 00_CUL.pm

Bislang ist alles schön modular aufgebaut; wie komme ich in einem
SIS_PM_Set() denn nun vom $hash des logischen Gerätes zur WriteFn
des zugehörigen IODev? Ich dachte/hoffte, das managed fhem.pl ir-
gendwie intern, aber bei 10_FS20.pm wird ja direkt IOWrite (woher
auch immer diese Funktion stammen mag) aufgerufen

Was ich habe ist:

fhem> list SIS_PMS_01_01_77_ff_98.2
Internals:
    Arbeit_PMS_MSGCNT 58
    Arbeit_PMS_TIME 2010-01-16 11:77:12
    DEF        01:01:77:ff:98 2
    IODev      Arbeit_PMS
    LASTIODev  Arbeit_PMS
    MSGCNT     58
    NAME       SIS_PMS_01_01_77_ff_98.2
    NR         94
    SERIAL     01:01:77:ff:98
    SOCKET     2
    STATE      off
    TYPE       SIS_PMS
    Prev:
      STATE      off
    Readings:
      2010-01-16 10:56:57   PREVSTATE       undefined
      2010-01-16 11:38:12   STATE           off
Attributes:
    room       SIS_PMS

fhem> list Arbeit_PMS
Internals:
    DEF        /usr/bin/sispmctl
    DeviceName /usr/bin/sispmctl
    NAME       Arbeit_PMS
    NR         6
    NumPMs     1
    STATE      querying
    TYPE       SISPM
    Timer      30
    pipeopentime 1263638620
    Units:
      0:
        SERIAL     01:01:77:ff:98
        USB        045
Attributes:
    room       Arbeit

Jetzt möchte ich "set SIS_PMS_01_01_77_ff_98.2 on" sagen können, dazu wird
dann die SIS_PMS.pm-SetFN aufgerufen, so weit, so schön. Aus SetFN müßte ich
nun aber dem IOdev Arbeit_PMS (gesteuert von 70_SISPM.pm) mitteilen, daß es
bitte Socket 2 der Power Manager-Leiste mit der "serial" 01:01:77:ff:98 auf
"on" schaltet (=> system("/usr/bin/sispmctl -d 0 -o 2")). HowTo?
         kai

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> Und genau da liegt mein Problem -- ich kenne außer FS20 derzeit gar
> keine anderen Geräte, die von FHEM gesteuert werden, und FS20 nutzt
> nun grade *nicht* die WriteFn z. B. von 00_CUL.pm

Es nutzt IOWrite, der est prueft, ob der Auftrag ignoriert werden soll
(ignore/dummy), und wenn nicht ruft den richtigen (IODev) WriteFn auf.  Ein
direkter Aufruf von CUL_WriteFn waere ja auch nicht korrekt, da sonst FHZ nicht
mehr FS20 faehig waere.


> gendwie intern, aber bei 10_FS20.pm wird ja direkt IOWrite (woher
> auch immer diese Funktion stammen mag) aufgerufen

Ein grep haette geholfen -> fhem.pl


> Aus SetFN müßte ich
> nun aber dem IOdev Arbeit_PMS (gesteuert von 70_SISPM.pm) mitteilen, daß es
> bitte Socket 2 der Power Manager-Leiste mit der "serial" 01:01:77:ff:98 auf
> "on" schaltet (=> system("/usr/bin/sispmctl -d 0 -o 2")). HowTo?

SIS_PMS_SetFn muss die Nachricht formulieren, und es via IOWrite auf dem
Weg schicken. SISPM_WriteFn schickt es raus (syswrite).

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> Und genau da liegt mein Problem -- ich kenne außer FS20 derzeit gar
>> keine anderen Geräte, die von FHEM gesteuert werden, und FS20 nutzt
>> nun grade *nicht* die WriteFn z. B. von 00_CUL.pm
>
> Es nutzt IOWrite, der est prueft, ob der Auftrag ignoriert werden soll

Ja, anhand von X10 und Blick in fhem.pl auch nachvollzogen. IOWrite stand
nur nicht in Deiner Beschreibung der Funktionen (26.10.09, Thread "Eigene
Module"), jedenfalls nicht als generisch für Module relevant.

(Definitiv Wiki-Thema )

> SIS_PMS_SetFn muss die Nachricht formulieren, und es via IOWrite auf dem
> Weg schicken. SISPM_WriteFn schickt es raus (syswrite).

Ack; 1. Argument, welches WriteFN bekommt, ist der Hash des IODev, danach
kommen die in SetFN übergebenen Variablen => rockt
         kai

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.