[FHZ] Konstruktion neuer Module

[Tommi]

                                                     

Hallo zusammen,
so ganz habe ich noch nicht verstanden, wie ein neues Modul aufgebaut
werden muss, was es implementiren muss und was vom fhem erledigt wird.
Ich arbeite an einem WS2000-Modul auf Basis des ELV-Wetterempfängers
bzw einer "Verlängerung" mittels Xport aud Socket-Basis. Die Daten
werden vom Gerät kontinuierlich gesenden, es ist dazu kein Befehl
notwendig.
Was ich also machen muss:
1. Initialisiert des SerialPorts bzw. des Sockets
2. continuierliches Pollen auf neue Daten
3. Frame dekodieren
4. Daten ausgeben

In einem Standalone-Programm habe ich alles schonmal implementiert.
Jetzt wiil ich daraus ein fhem-Modul machen(87_ws2000.pm).
1. Frage:im ws2000-Datenstrom sind ja die verschiedensten Geräte
(Themperatur/Druck-/Regen usw. und FS10-Daten enthalten. Sollen diese
in ein Sub-Modul ausgelagert werden?
2. Ich denke , ich brauche dann eine WS2000_Define, eine WS2000_Undef,
eine WS200_Get und eine WS2000_Parse-Funktion, richtig?
3. Die ws2000-Get-Funktion würde aber (wie sie jetzt ist)als
Endlosschleife laufen was evtl nicht so toll ist, oder?
Oder macht das FHEM.pl das automatisch? Die Daten kommen jedenfalls
teilweise im seperater Thread oder Prozess?
4. Fehlt noch was?

Vielen Dank!
Tommi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

                                             

Hallo Tommi,

Am Samstag, 3. Mai 2008 schrieb tommi:
> Ich arbeite an einem WS2000-Modul auf Basis des ELV-Wetterempfängers
> bzw einer "Verlängerung" mittels Xport aud Socket-Basis. Die Daten
> werden vom Gerät kontinuierlich gesenden, es ist dazu kein Befehl
> notwendig.

Hört sich an, als funktionierte das Teil analog zu KS300. Schau Dir doch mal
13_KS300.pm als Muster an.

> Was ich also machen muss:
> 1. Initialisiert des SerialPorts bzw. des Sockets

in WS2000_define

> 2. continuierliches Pollen auf neue Daten

WS2000_Parse bekommt den Datenstrom frei Haus geliefert.

> 3. Frame dekodieren

ebenda.

> 4. Daten ausgeben

ebenda.

> 1. Frage:im ws2000-Datenstrom sind ja die verschiedensten Geräte
> (Themperatur/Druck-/Regen usw. und FS10-Daten enthalten. Sollen diese
> in ein Sub-Modul ausgelagert werden?

Bei KS300 spiegeln sich die verschiedenen Sensoren in Datenfeldern
(Temperatur, Windgeschwindigkeit, Regenmenge) desselbe Geräts wieder.

> 2. Ich denke , ich brauche dann eine WS2000_Define, eine WS2000_Undef,
> eine WS200_Get und eine WS2000_Parse-Funktion, richtig?

ja.

> 3. Die ws2000-Get-Funktion würde aber (wie sie jetzt ist)als
> Endlosschleife laufen was evtl nicht so toll ist, oder?
> Oder macht das FHEM.pl das automatisch? Die Daten kommen jedenfalls
> teilweise im > seperater Thread oder Prozess?

FHEM ist ine Art Framework, in  das Du Dein Modul einhängen kannst, und das
Dich dann mit dem Datenstrom versorgt.

Grüße,
Boris





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

[Tommi]

                                                     

Vielen Dank!

Jetzt bin ich ein ganzes Stück weiter. Mein Modul liefert die ersten
Daten.


>
> > 2. continuierliches Pollen auf neue Daten
>
> WS2000_Parse bekommt den Datenstrom frei Haus geliefert.
Allerdings habe ich die ReadFn-Funktion selber implementieren müssen
und rufe von dort die Parse-Funktion auf, da das automatische
Anliefern irgendwie nicht geklappt hat.

>
> > 3. Frame dekodieren
>
> ebenda.
>
gemacht.

> > 4. Daten ausgeben
>
> ebenda.
Gibt es dazu Vorgaben?
Ich habe jetzt unter $hash->{READINGS} die Sensoren angelegt, die
empfangen werden. Ist noch etwas wichtig oder sinnvoll?
Das Ergebnis schreibe ich zur Zeit mit Log 4, $result.

Falls es jemand ausprobieren möchte, kann ich das Modul gerne
einstellen (wohin?)

Viele Grüße
Tommi

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

[Dr. Boris Neubert]

                                             

Hallo Tommi,

Am Montag, 5. Mai 2008 schrieb tommi:
> > > 4. Daten ausgeben
> >
> > ebenda.
>
> Gibt es dazu Vorgaben?
> Ich habe jetzt unter $hash->{READINGS} die Sensoren angelegt, die
> empfangen werden. Ist noch etwas wichtig oder sinnvoll?
> Das Ergebnis schreibe ich zur Zeit mit Log 4, $result.

Loggen nix gut. Der Trick geht so:

  my $tn = TimeNow();
  my $value= wasauchimmerfuernwertduschreibenwillst;

  $hash->{READINGS}{namedessensors}{TIME} = $tn;
  $hash->{READINGS}{namedessensors}{VAL} = $value;

  $hash->{CHANGED}[0]= "namedessensors: $value";

Und schon klappt's auch mit den Events

Am besten versuchst Du mal eines der bestehenden Module zu verstehen.

Grüße,
Boris


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

[rudolfkoenig]

                                                   

> Das Ergebnis schreibe ich zur Zeit mit Log 4, $result.

Wie Boris schreibt, in diesem Fall ist das READINGS und CHANGED hash
das Richtige.
Wenn doch Log, dann am besten, mit GetLogLevel($name,4), damit man es
mit Attributen steuern kann.

> Falls es jemand ausprobieren möchte, kann ich das Modul gerne
> einstellen (wohin?)

Ins CVS oder (wenn gar nicht anders geht mir schicken.

Gruss,
  Rudi

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

[Tommi]

                                                     

Es ist getan!

>Ins CVS oder (wenn gar nicht anders geht mir schicken.
Das Modul ist jetzt im CVS(87_WS2000.pm).
Es kann (ähnlich dem Modul 86_FS10) den ELV-Wetterempfänger auslesen,
braucht aber kein externes Programm dazu. Ich habe auch einen Switch
eingebaut, um auch unter Windows (mit Win32::SerialPort) oder auch mit
einem XPort arbeiten zu können. Dazu habe ich noch eine StandAlone-
Version (ws2000_reader.pl) beigelegt, die aus einem Realen Divice oder
von einem Socket die Daten liest und dekodiert, aber die Originaldaten
gleich als Server für den gleichen Client bereitstellen kann.
Wäre nett, wenn das alles mal jemand testen kann. Leider kämpfe ich da
noch mit der Erkennung der "dead connections".

Wenn das alles irgendwann mal fehlerfrei klappt, würde ich auch gerne
das FHZ-Modul mit der gleichen Logik versehen, da ich eine FHZ z.B.
auch an einem Xport hängen habe und auch unter Windows das Programm
nutzen möchte. Evtl. kann man daraus sogar einen richtigen Diest
machen, z.B.  mit dem ActiveState PDK.

>hash->{READINGS}{namedessensors}{TIME} = $tn;
>$hash->{READINGS}{namedessensors}{VAL} = $value;
> $hash->{CHANGED}[0]= "namedessensors: $value";
->Und schon klappt's auch mit den Events
..war leider nicht alles, erst DoTrigger($hash,undef) tut das richtig
(oder ich habe was falsch gemacht)
Warum gibt es eigentlich in READINGS hashkeys und in CHANGED arrays
(mit der gleichen Info?)?

Noch eine Frage:
Müßte der Shutdown-Befehl nicht auch die {UndefFn}-Funktionen alle
ausführen, bevor er auf exit geht?


Viele Grüße
Tommi


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

[Dr. Boris Neubert]

                                                   

> Ich habe auch einen Switch eingebaut, um auch unter Windows
> (mit Win32::SerialPort) oder auch mit einem XPort arbeiten zu können.

Aah.

> ..war leider nicht alles, erst DoTrigger($hash,undef) tut das richtig
> (oder ich habe was falsch gemacht)

Nein, es ist alles korrekt. der "ReadFn" muss DoTrigger aufrufen
(siehe auch 00_FHZ.pm) und die ParseFn das CHANGED array setzen
(10_FS20.pm)

> Warum gibt es eigentlich in READINGS hashkeys und in CHANGED arrays
> (mit der gleichen Info?)?

Ersteres ist eine Liste, was alles jemals vom device geliefert wurde,
neuere Infos gleicher Art werden ueberschrieben. Ist durch das List
Kommando zugaenglich. Letzteres ist nur fuer die interne Logik, und
wird zum Aufrufen der Trigger (notify / at) verwendet.

> Müßte der Shutdown-Befehl nicht auch die {UndefFn}-Funktionen alle
> ausführen, bevor er auf exit geht?

Eigentlich schon, aber unter einem "normalen" OS (wie Linux wird
beim terminieren eines Prozesses alles vom OS aufgeraeumt.  Unter
Windows gibt es schon mal Probleme, wenn der Socket nicht vom Prozess
geschlossen wird.
Ein "UndefFn" auf alle devices sollten wir wegen ruecksicht auf
seltsame Betriebsysteme beim shutdown machen.

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