platformübergreifende I2C Module

[klausw]

Hallo zusammen,

die Idee ist, für verschiedene I2C komponenten (LCD-Display, Portextender, Servomodul, Drucksensor, etc.), eine 2 level Lösung zu erarbeiten.
Also ein physikalisches Modul, welches sich um die Kommunikation mit der Hardware kümmert.
Und ein logisches Modul, das die Funktionen für die I2C Komponente zur Verfügung stellt.
So würden sich leicht neue Hardwaresysteme einbinden lassen und alle existierenden logischen Module sind sofort nutzbar.

da die Diskussion im Firmata Thread losging und dort nicht reingehört beginne ich einen neuen Thread.

hier die ursprünglichen Beiträge:
http://forum.fhem.de/index.php/topic,10540.msg133318.html#msg133318

[klausw]

Man legt die I2C-Addresse wärend define im Client-hash ab. Anschließend assoziiert man den Client-hash per AssignIODev mit seinem physikalischen Modul.

Meinst du:  AssignIoPort?

Hierbei wird der der Client-hash im '.clientArray' des physikalischen Moduls abgelegt. Wenn man die I2C-response an den Client zurückschicken will, iteriert man (so wie in der Dispatch-funktion) über alle Clients aus '.clientArray' des physikalischen Devices bis man den Client-hash findet, der die passende I2C-addresse enthält.

Folgendes habe ich ausprobiert:

Code Auswählen Erweitern


my $module = $modules{$hash->{TYPE}};
my $clientArray = $hash->{".clientArray"};
#Log3 $hash, 1, "array: " . @{$hash->{".clientArray"}};
foreach my $m (@{$clientArray}) {
   foreach my $devname (devspec2array("TYPE=$m")) {
  my $chash = $defs{$devname};
      Log3 $hash, 1, "Hash: $hash, Name: $name, ClientType: $m ClientName: $devname, ClientHash: $chash";
  if (defined($chash->{I2C_ADDR}) && $chash->{I2C_ADDR} eq $dev) {
    Log3 $hash, 1, "$devname I2CAddr passt: $dev";
    CallFn($devname, "I2CRecFn", $chash, "funktioniert");
  }
}
}


Meintest Du das in etwa so?

der I2CReceiveFn sollte auch einen Parameter 'success' mitgeben, damit das Modul erfährt, ob ein Schreibvorgang erfolgreich war.

Da würde ich einfach die Botschaft zurück an den Client senden. So könnte man nach einem erfolgreichen senden die Readings anpassen

ein Sende- oder Leseinterval ist natürlich nur für I2C-module sinnvoll, aus denen man einen veränderlichen Wert auslesen kann - z.B. einen A/D-wandler oder eine Echtzeituhr. Weil das naturgemäß spezifisch für das jeweilige I2C-Device ist, muss das im Client-modul definiert sein.

achso, darum muss sich dann jeder im Client selbst kümmern. Ich hatte es so verstanden das Du z.B. zwischen den Botschaftenan das LCD eine feste Pause haben möchtest.

FRM_I2C ist übrigens ein generisches I2C-Client-modul, das eigentlich nur dazu taugt in einem regelmäßigen Intervall ein I2C-Device auszulesen. Das physikalische Modul dazu ist FRM selbst. FRM_LCD setzt direkt auf FRM auf und hat sonst keine Verbindung mit FRM_I2C.

das FRM_I2C meinte ich auch nicht sonder ausschließlich das FRM_LCD. Zum auslesen/schreiben von Rohdaten auf dem I2C Bus würde ich in den Master dafür Set und GetFn einbauen. Aber vielleicht kannst Du das FRM_I2C auch als physical auslegen. Dann könnten die Module auch für Firmata genutzt werden.

... Wir sollten für das I2C-thema einen eigenen Thread aufmachen, das führt von Arduino/Firmata jetzt ganz schön weit weg

hier isser

Grüße
Klaus

[rudolfkoenig]

Ich habe das jetzt nicht in aller Tiefe gelesen/verstanden, wollte nur wegen I2CReceiveFn bemerken, dass falls zwei Module fuer die Inter-Modul-Kommunikation ausser Dispatch und IOWrite noch andere Funktionen verwenden, dann funktioniert FHEM2FHEM in Raw-Modus nicht fuer diesen Anwendungsfall.

[klausw]

Ich habe das jetzt nicht in aller Tiefe gelesen/verstanden, wollte nur wegen I2CReceiveFn bemerken, dass falls zwei Module fuer die Inter-Modul-Kommunikation ausser Dispatch und IOWrite noch andere Funktionen verwenden, dann funktioniert FHEM2FHEM in Raw-Modus nicht fuer diesen Anwendungsfall.

Ok, das spricht gegen eine eigene ReceiveFn

[klausw]

Im Prinzip würde ich sagen, dass das prinzipiell passt, wobei ich die parameter nicht als einen einzigen String, sondern als einzelne Parameter übergeben würde. Der Aufruf der WriteFn erlaubt das. Eventuell in einen Hash der Art { direction => i2cwrite, id => <..>, i2caddress => <...>, data => <...> } gepackt - wenn man optionale Parameter hat, können die im Hash einfach weggelassen werden, bei positionalen Parametern muss man sie explizit als undef mit angeben (und in einem zu parsenden String müsste man einen Platzhalter für ungesetzte Parameter vereinbaren).

Da komme ich nicht weiter, folgendes habe ich testweise in die Clienten SetFn eingebaut:

Code Auswählen Erweitern

my %sendpackage = ( direction => "i2cwrite", id => (defined( $hash->{ID} )? $hash->{ID} : "00"), i2caddress => $hash->{I2C_ADDR}, data => $msg );
IOWrite($hash, \%sendpackage);

In der WriteFn des Physical als erstes:

Code Auswählen Erweitern

my ($hash, $clientmsg) = @_;

Dummerweise steht in der $clientmsg nur das i2cwrite aus dem assoziativen Array drin.
Müsste da nicht eine Referenz auf %sendpackage drin sein?

Wie bekomme ich %sendpackage in die WriteFn rüber?

[ntruchsess]

Meinst du:  AssignIoPort?

ja klar, Schreibfehler.

Hierbei wird der der Client-hash im '.clientArray' des physikalischen Moduls abgelegt. Wenn man die I2C-response an den Client zurückschicken will, iteriert man (so wie in der Dispatch-funktion) über alle Clients aus '.clientArray' des physikalischen Devices bis man den Client-hash findet, der die passende I2C-addresse enthält.

Hab grade noch mal reingeschaut, wie das .clientArray aufgebaut wird - da stehen ja nur die Modultypen drin, nicht die Device-hashes, das ist unnötig kompliziert, weil die IODev->Client-beziehung ja nicht erst ermittelt werden muss, sondern zu dem Zeitpunkt ja schon feststeht. Ich habe das in meiner FRM_forall_Clients-methode ganz einfach gelöst (jetzt erinnere ich mich auch daran, warum ich das .clientArray nicht benutz habe).

So könnte man nach einem erfolgreichen senden die Readings anpassen.
achso, darum muss sich dann jeder im Client selbst kümmern.

klar, wo sonst.

Du das FRM_I2C auch als physical auslegen. Dann könnten die Module auch für Firmata genutzt werden.

Eigentlich wäre das physikalische Interface vieleicht sogar besser direkt im FRM aufgehoben. Es gibt eh noch keinen Arduino mit mehr als einem I2C-port. Dann sollte man allerding nicht die IOWrite-funktion benutzen sondern eine eigene I2CWrite funktion definieren. (FRM ist ja physikalisches Device für einiges mehr...). Dann eventuell doch besser als abgesetztes FRM_I2C-modul.

Ich habe das jetzt nicht in aller Tiefe gelesen/verstanden, wollte nur wegen I2CReceiveFn bemerken, dass falls zwei Module fuer die Inter-Modul-Kommunikation ausser Dispatch und IOWrite noch andere Funktionen verwenden, dann funktioniert FHEM2FHEM in Raw-Modus nicht fuer diesen Anwendungsfall.

Ok, das spricht gegen eine eigene ReceiveFn

hmm... muss man mal drüber nachdenken. Die Frage ist, ob FHEM2FHEM zur Remote-Anbindung eines I2C-devices von den Einschränkungen beim Timing so geeignet ist, aber das hängt sowieso vom I2C-gerät ab und das müsste man mal praktisch ausprobieren. Eine I2CReceiveFn könnte man ja einfach mit einer ParseFn für den FHEM2FHEM-fall und lokal die effizientere Variante benutzen.

- Norbert

[klausw]

Hab grade noch mal reingeschaut, wie das .clientArray aufgebaut wird - da stehen ja nur die Modultypen drin, nicht die Device-hashes, das ist unnötig kompliziert, weil die IODev->Client-beziehung ja nicht erst ermittelt werden muss, sondern zu dem Zeitpunkt ja schon feststeht. Ich habe das in meiner FRM_forall_Clients-methode ganz einfach gelöst (jetzt erinnere ich mich auch daran, warum ich das .clientArray nicht benutz habe).

Deine Methode schickt die Botschaft an alle Clients, richtig? Das heisst sie müsste nur um eine Abfrage nach der I2C Adresse erweitert werden.

Eigentlich wäre das physikalische Interface vieleicht sogar besser direkt im FRM aufgehoben. Es gibt eh noch keinen Arduino mit mehr als einem I2C-port. Dann sollte man allerding nicht die IOWrite-funktion benutzen sondern eine eigene I2CWrite funktion definieren. (FRM ist ja physikalisches Device für einiges mehr...). Dann eventuell doch besser als abgesetztes FRM_I2C-modul.

Von der Sicht aus, so viele Bordmittel der fhem.pl zu nutzen würde ich gern IOWrite verwenden und keine neue Funktion definieren.

hmm... muss man mal drüber nachdenken. Die Frage ist, ob FHEM2FHEM zur Remote-Anbindung eines I2C-devices von den Einschränkungen beim Timing so geeignet ist, aber das hängt sowieso vom I2C-gerät ab und das müsste man mal praktisch ausprobieren. Eine I2CReceiveFn könnte man ja einfach mit einer ParseFn für den FHEM2FHEM-fall und lokal die effizientere Variante benutzen.

Das Timing ist meiner Meinung nach kein Problem. Da kümmert sich je nach System ein low level Treiber drum. Und das I2C Master Modul in FHEM soll ja das nächste Byte erst raussenden wenn eine Antwort gekommen ist. Die Datenmengen sind auch recht übersichtlich
Du meinst 2 verschiedene Varianten um vom Master auf den Client zuzugreifen (über Dispatch und CallFn) je nachdem ob FHEM2FHEM genutzt wird oder nicht?

Könnte nicht auch die Dispatch Funktion modifiziert werden, das wenn man den Client Hash mitschickt, die Botschaft direkt an ihn gesendet wird?
Wenn kein Client Hash übergeben wird läuft alles wie bisher.

[ntruchsess]

Deine Methode schickt die Botschaft an alle Clients, richtig? Das heisst sie müsste nur um eine Abfrage nach der I2C adresse erweitert werden.

genau.

sorgt das & am Anfang dafür, die Variable $fn als Funktionsaufruf zu definieren?

ja, siehe: http://perldoc.perl.org/perlref.html#Using-References

Von der Sicht aus, so viele Bordmittel der fhem.pl zu nutzen würde ich gern IOWrite verwenden und keine neue Funktion definieren.

Es ist eigentlich immer ein Vorteil ein sauberes Interface mit eindeutiger Signatur zu haben. Das erleichtert die Entwicklung, Test, Fehlersuche und Wartbarkeit. Eine Methode der man einen String übergibt, der in der Methode geparsed wird um die Aufrufparameter zu extrahieren leisted genau das aber nicht.
Wenn alles mit dem spezialisierten Interface sauber funktioniert kann man es für den generischen Aufruf (per IOWrite für FHEM2FHEM) ganz einfach wrappen - dann hat man den eigentlichen funktionalen Code sauber vom Aufbereiten des per generischem Interface übergebenen Strings getrennt und kann bei lokaler Benutzung direkt über das spezialisierte Interface gehen.

das I2C Master Modul in FHEM soll ja das nächste Byte erst raussenden wenn eine Antwort gekommen ist.

einzelne Bytes zu schreiben und immer erst auf eine Antwort zu warten ist äußerst ineffizient wenn man mehrere Bytes in Folge an ein I2C-device-register schicken will. Das Interface sollte einen kompletten Blocktransfer mit einem einzigen Aufruf erlauben. (Das schließt ja nicht aus, dass man auch einzelne Bytes übertragen kann).

Du meinst 2 verschiedene Varianten um vom Master auf den Client zuzugreifen (über Dispatch und CallFn) je nachdem ob FHEM2FHEM genutzt wird oder nicht?

ja, wie vorher schon geschrieben aber auch für den Zugriff auf das physikalische Device.

Könnte nicht auch die Dispatch Funktion modifiziert werden, das wenn man den Client Hash mitschickt, die Botschaft direkt an ihn gesendet wird?

könnte man im Prinzip schon, allerdings ist die Dispatch-funktion halt darauf optimiert den Client erst mal anhand der Message selber zu ermitteln. Wenn man den Client-hash schon hat, dann ist der Aufruf einer Methode mit Übergabe des Client-hashes doch trivial, da ist doch nix mehr zu gewinnen?

Gruß,

Norbert

[klausw]

Es ist eigentlich immer ein Vorteil ein sauberes Interface mit eindeutiger Signatur zu haben. Das erleichtert die Entwicklung, Test, Fehlersuche und Wartbarkeit. Eine Methode der man einen String übergibt, der in der Methode geparsed wird um die Aufrufparameter zu extrahieren leisted genau das aber nicht.
Wenn alles mit dem spezialisierten Interface sauber funktioniert kann man es für den generischen Aufruf (per IOWrite für FHEM2FHEM) ganz einfach wrappen - dann hat man den eigentlichen funktionalen Code sauber vom Aufbereiten des per generischem Interface übergebenen Strings getrennt und kann bei lokaler Benutzung direkt über das spezialisierte Interface gehen.

verstehe
Aber AssignIoPort verwende ich weiterhin, da ich schließlich die Verknüpfung zwischen physical und logical herstellen muss?
Im physical erstelle ich eine I2CWriteFn und im logical eine I2CReadFn (die Namensgebung passt auch) die ich jeweils mit CallFn von anderen Modul aufrufen kann.
Für die Richtung logical zu physical verwende ich $hash->{IODev} und für die Andere Deine  FRM_forall_Clients-methode, die ich etwas anpasse.
Klarer Vorteil ist auch, das es mehrere client Modul-Instanzen mit der gleichen I2C Adresse geben kann (z.B. jeder Port eines Portextenders einzeln) die jedesmal eine Aktualisierung erhalten.

Was Du mit dem wrappen meinst habe ich vom Gedanken her verstanden, habe aber momentan keine Ahnung wie ich das machen soll.
Das hat aber auch Zeit bis der Rest funktioniert.

einzelne Bytes zu schreiben und immer erst auf eine Antwort zu warten ist äußerst ineffizient wenn man mehrere Bytes in Folge an ein I2C-device-register schicken will. Das Interface sollte einen kompletten Blocktransfer mit einem einzigen Aufruf erlauben. (Das schließt ja nicht aus, dass man auch einzelne Bytes übertragen kann).

Naja, stimmt..ich hatte da gerade einen 8bit Portextender im Kopf. Der ist mit einem Byte gut ausgelastet 
Bei Deinem Display sieht das anders aus.
Beim i2cwrite ist das kein Problem. Aber beim lesen muss einfach ein weiterer Wert im Hasharray übergeben werden.

Ich versuche am We die Module entsprechend anzupassen.
Da kommen sicher noch paar Fragen

Soweit schonmal Danke

Grüße
Klaus

[klausw]

Ein master - client Pärchen habe ich relativ stabil am laufen.

im master muss eine I2CWrtFn definiert werden, diese wird vom client mit
CallFn(<mastername>, "I2CWrtFn", <masterhash>, \%sendpackage);
aufgerufen.
Der Master muss mit AssignIoPort() dem Client zugeordnet werden;
%sendpackage muss folgende keys enthalten:

• i2caddress => <xx>
• direction => <i2cwrite|i2cread>
• data => <xx [xx ...] (kann für read leer bleiben)>

der Master fügt zu %sendpackage noch folgende keys hinzu:

• received (durch leerzeichen getrennte 1byte hexwerte)
• mastername_* (alle mit mastername_  beginnenden keys können als internal im client angelegt weden)
• unter anderem: mastername_SENDSTAT (enthält "Ok" wenn Übertragung erfolgreich)

danach ruft er über:
CallFn(<clientname>, "I2CRecFn", <clienthash>, $sendpackage);
die I2CRecFn im client auf. Dort werden die Daten verarbeitet und
im Master wird der Hash sendpackage gelöscht.

Entspricht es so Deiner Idee Norbert?
Wenn ja kannst du es gern in Dein LCD Modul einbauen
Als nächstes schreibe ich dann einen Master für das Raspberry

Wie kann ich die I2CFn's wrappen, das es auch mit FHEM2FHEM geht?

[klausw]

Ich habe die Module hier hochgeladen, da ich mich vorerst aufs RaspberryPi konzentrieren will:

http://forum.fhem.de/index.php/topic,20452.0.html

[ntruchsess]

so, ab jetzt unterstützt FRM das neue Interface. Das FRM_LCD-modul habe ich darauf umgestelt und in I2C_LCD umbenannt.
Testen konnte ich das bisher nur mit Arduino/FRM, ein I2C-Interface für den Pi habe ich nicht.

@Klaus:
das I2C_LCD-modul hat eine InitFn, die das hardware-abhängige Modul aufruft, sobald die Hardware vorhanden und initialisiert ist. Im Gegensatz zur DefFn sind die Attribute zu diesem Zeitpunk schon bekannt und das Modul kann sich (ziemlich) darauf verlassen, dass das physikalische Device schon aktiv und initialisiert ist. Bei einem Reconnect des physikalischen Devices kann die InitFn auch wiederholt aufgerufen werden. Du solltest den Mechanismus in dein RPII2C-modul aufnehmen.

Alle FRM-changes dazu sind schon im SVN.

[ntruchsess]

ich habe gerade ein I2C_DS1307 modul geschrieben, dass die neue I2C-api benutzt. Der DS1307 ist eine Real-time-clock, das Modul pollt im per Attribut 'poll_intervall' eingestellten Takt die Uhrzeit.
(Über die Sinnhaftigkeit eines solchen Moduls kann man natürlich diskutieren, aber vieleicht gibt's noch Systeme ohne eingebaute RTC? Ich hab den Chip halt grade da gehabt und wollte das Zusammenspiel mit FRM über die neue API am lebenden Objekt testen...)

Wegen der Plattformübergreifenden Funktion:

Beim FRM kann man nicht davon ausgehen, dass das Modul schon mit der Physik verbunden ist (das ist systematisch bedingt, ein über Netzwerk angebundener Arduino kann erst initialisiert werden, wenn die FHEM-main-loop schon läuft und die Netzwerkverbindung entgegennimmt).

Ich habe das in meinen Modulen so gelöst, dass es eine 'InitFn' gibt, die von FRM aus aufgerufen wird, sobald FRM die Physik initialisiert hat und einsatzbereit ist.

Wenn man ein FRM-client-modul manuell definiert (dann ist 'init_done==1'), dann wird die InitFn schon direkt beim Define aufgerufen und kann gleich loslegen.

Der Mechanismus über die InitFn erlaubt auch ein sauberes Reinititialisieren alles Client-module, wenn der I2C-adapter (bei FRM der Arduino) zwischendurch mal weg (USB abgezogen, Netzwerk unterbrochen...) ist und sich dann wieder meldet.

Man sollte das in die Plattformübergreifende API aufnehmen und alle I2C-Client-module damit ausrüsten.

Gruß,

Norbert

[klausw]

so, ab jetzt unterstützt FRM das neue Interface. Das FRM_LCD-modul habe ich darauf umgestelt und in I2C_LCD umbenannt.
Testen konnte ich das bisher nur mit Arduino/FRM, ein I2C-Interface für den Pi habe ich nicht.

super, zufällig habe ich solch ein Modul, ich muss nur noch einen Adapter basteln, danach werde ich es testen.
Das heisst, FRM sollte alle bisher geschriebenen I2C Module unterstützen?

@Klaus:
das I2C_LCD-modul hat eine InitFn, die das hardware-abhängige Modul aufruft, sobald die Hardware vorhanden und initialisiert ist. Im Gegensatz zur DefFn sind die Attribute zu diesem Zeitpunk schon bekannt und das Modul kann sich (ziemlich) darauf verlassen, dass das physikalische Device schon aktiv und initialisiert ist. Bei einem Reconnect des physikalischen Devices kann die InitFn auch wiederholt aufgerufen werden. Du solltest den Mechanismus in dein RPII2C-modul aufnehmen.

Das schaue ich mir gleich mal an

@norbert:
Eigentlich müsste sich auf diese Weise auch ein 1-Wire Busmaster einbinden lassen (DS2482). Das würde den Einrichtungsaufwand für 1wire doch auch minimieren.

Grüße
Klaus

[klausw]

...Bei einem Reconnect des physikalischen Devices kann die InitFn auch wiederholt aufgerufen werden. Du solltest den Mechanismus in dein RPII2C-modul aufnehmen.

Muss ich da etwas im RPII2C Modul ändern? Wenn ich es richtig verstanden habe bezieht sich das doch nur auf die Client Module, oder habe ich das was übersehen?

Grüße
Klaus