FHEM Forum

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

Zitat von: ntruchsess am 04 Februar 2014, 22:17:06
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:

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?

Zitatder 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

Zitatein 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.

ZitatFRM_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.

Zitat... 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

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.

Zitat von: rudolfkoenig am 05 Februar 2014, 15:56:11
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

ZitatIm 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:
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:
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?

Zitat von: klausw am 05 Februar 2014, 15:08:43
Meinst du:  AssignIoPort?

ja klar, Schreibfehler.

Zitat von: klausw am 05 Februar 2014, 15:08:43
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 (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L377) ganz einfach gelöst (jetzt erinnere ich mich auch daran, warum ich das .clientArray nicht benutz habe).

Zitat von: klausw am 05 Februar 2014, 15:08:43
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.

Zitat von: klausw am 05 Februar 2014, 15:08:43Du 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.

Zitat von: rudolfkoenig am 05 Februar 2014, 15:56:11Ich 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.

Zitat von: klausw am 05 Februar 2014, 18:49:41Ok, 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

Zitat von: ntruchsess am 05 Februar 2014, 19:22:46
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.

Zitat von: ntruchsess am 05 Februar 2014, 19:22:46
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.

Zitat von: ntruchsess am 05 Februar 2014, 19:22:46
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.

Zitat von: klausw am 06 Februar 2014, 17:10:12Deine Methode schickt die Botschaft an alle Clients, richtig? Das heisst sie müsste nur um eine Abfrage nach der I2C adresse erweitert werden.

genau.

Zitat von: klausw am 06 Februar 2014, 17:10:12sorgt das & am Anfang dafür, die Variable $fn als Funktionsaufruf zu definieren?

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

Zitat von: klausw am 06 Februar 2014, 17:10:12Von 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.

Zitat von: klausw am 06 Februar 2014, 17:10:12das 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).

Zitat von: klausw am 06 Februar 2014, 17:10:12Du 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.

Zitat von: klausw am 06 Februar 2014, 17:10:12Kö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

Zitat von: ntruchsess am 06 Februar 2014, 17:58:53
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.

Zitat von: ntruchsess am 06 Februar 2014, 17:58:53
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  ;D
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

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?

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

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

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 (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/52_I2C_LCD.pm#L39), 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.

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' (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/52_I2C_DS1307.pm#L38) 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

Zitat von: ntruchsess am 21 März 2014, 14:07:35
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?

Zitat von: ntruchsess am 21 März 2014, 14:07:35
@Klaus:
das I2C_LCD-modul hat eine InitFn (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/52_I2C_LCD.pm#L39), 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

Zitat von: ntruchsess am 21 März 2014, 14:07:35
...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

Was macht eigentlich 'I2C_LCD_Catch' (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/52_I2C_LCD.pm#L294) so ganz verstehe ich das nicht

I2C_LCD_Catch hüpscht die Fehlermeldung ein bischen auf, indem es den Dateisystempfad (bis zum /FHEM) rausschneidet. Der Pfad kommt rein, weil perl den beim Aufruf von 'die' mit reinhängt.

Zitat von: klausw am 24 März 2014, 14:40:28Muss ich da etwas im RPII2C Modul ändern?

Wenn die Client-module in der DefineFn die InitFn nur aufrufen wenn init_done==1 ist (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/52_I2C_LCD.pm#L57), dann muss ins RPII2C-modul ein Aufruf rein, der diesen Aufruf der InitFn nachholt. Dazu brauchst RPII2C eine NotifyFn (siehe hier (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L148), in der DefineFn sollte man das NotifyDef auf global eingrenzen (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L84). Aus der NotifyFn ruft man dann für alle Clients die InitFn auf (das passiert in FRM indirekt aus der FRM_DoInit (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L449)-methode heraus, die DevIo_OpenDev (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L144) aufruft, wenn die Verbindung zum physikalischen Device erfolgreich hergestellt ist. (In FRM sind mehrere Stellen, die DevIo_OpenDev aufrufen drin. Eine davon in FRM_Start (aufgerufen von der NotifyFn), eine in der ReadyFn (für eine erneute Initialisierung aller Clients nach einem Reconnekt) und eine in der SetFn, wenn man dern Arduino per 'set xxx reset' inklusive der Verbindung zurücksetzt).

Wenn Du willst, dann checke ich das RPII2C-modul mal in einen eigenen Branch in meinem fhem-mirror auf Github ein, dann können wir da leichter zusammenarbeiten, als wenn Du Dateien im Forum anhängst.

Gruß,

Norbert

Zitat von: ntruchsess am 24 März 2014, 16:02:11
Wenn Du willst, dann checke ich das RPII2C-modul mal in einen eigenen Branch in meinem fhem-mirror auf Github ein, dann können wir da leichter zusammenarbeiten, als wenn Du Dateien im Forum anhängst.

oh ja, mach das bitte
Das geht so am schnellsten :)

Ich würde die Clientsliste auf my $clientsI2C = ":I2C_*:"; ändern. Dann sind automatisch alles Module drin.
Es gibt zwar noch eins (I2C_BMP180) das nicht auf die neue Schnittstelle aufsetzt, aber das sollte kein Problem sein, oder?

hier ist der I2C-Branch (https://github.com/ntruchsess/fhem-mirror/commits/I2C/fhem/FHEM)

hast Du auf Github einen Account? Dann kann ich Dich auf dem fhem-mirror schreibberechtigen.
Nur bitte nichts in den master committen, damit kommt der SVN<->Git-sync nicht wirklich zurecht. Gib in dem Fall einfach Bescheid, dann mache ich das so, dass es keine Probleme gibt.

Gruß,

Norbert

Hallo Norbert,

ich habe die InitFn Zusätze in die 00_RPII2C.pm (https://github.com/ntruchsess/fhem-mirror/blob/e991781150a7510f031626046d12fec7835e6927/fhem/FHEM/00_RPII2C.pm) eingebaut und die InitFn testweise in die  52_I2C_SHT21.pm (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/52_I2C_SHT21.pm#L61) Leider funktioniert es nicht. SHT21 bekommt kein IODev zugewiesen. Wenn ich Zeilen 54 und 57 auskomentiere (also die init_done Abfrage) dann geht es.
Kannst Du mir einen Tip geben, was ich übersehen habe?


In 00_RPII2C.pm (https://github.com/ntruchsess/fhem-mirror/blob/e991781150a7510f031626046d12fec7835e6927/fhem/FHEM/00_RPII2C.pm#L286) habe ich noch die Möglichkeit eingebaut mehrere Bytes vom I2C mit einem mal zu lesen (also ohne Registeradresse). Das wird für den SHT benötigt. Baue das bitte noch in Dein FRM Modul ein.
Grüße
Klaus

Zitat von: klausw am 25 März 2014, 00:38:27
SHT21 bekommt kein IODev zugewiesen. Wenn ich Zeilen 54 und 57 auskomentiere (also die init_done Abfrage) dann geht es.
Kannst Du mir einen Tip geben, was ich übersehen habe?

ja, die 'Forall_Clients'-logic zum Aufruf der InitFn funktioniert ja erst, wenn das IODev schon gesetzt ist (Henne-Ei Problem). Muss grad mal kurz in mich gehen, wie das im FRM genau zusammenspielt.

Zitat von: klausw am 25 März 2014, 00:38:27[,,,]mehrere Bytes vom I2C mit einem mal zu lesen (also ohne Registeradresse).[...]Baue das bitte noch in Dein FRM Modul ein.

das ist längst drin (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/10_FRM.pm#L669). Man kann die I2CWrtFn für i2cread sowohl mit, als auch ohne reg und oder nbytes aufrufen. Ohne nbytes wird 1 byte gelesen. Wird in 52_I2C_DS1307.pm (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_DS1307.pm#L302) auch schon benutzt.
Dein I2C_PCF8574 funktioniert mit FRM auch (jedenfalls macht es das, was ich aus Deinem code herauslesen kann...). Für soche GPIO-devices sollte man mal ein hardwareunabhängigs Interface zu SubDevices (a la FRM_IN (http://fhem.de/commandref.html#FRM_IN) / FRM_OUT (http://fhem.de/commandref.html#FRM_OUT)) definieren, da könnten noch einige andere Module davon profitieren. Die Lösung mit readingsProxy (http://fhem.de/commandref.html#readingsProxy) leistet das zwar grundsätzlich auch, erfodert aber als generische Lösung einiges an Verständnis beim Benutzer um es richtig zu konfigurieren.

Gruß,

Norbert

Zitat von: klausw am 24 März 2014, 14:26:55
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.

Ja natürlich. Wobei der Einrichtungsaufwand nur für bestimmte Hardware niedrig ist. Für den Raspberry Pi z.B. gibt es fertige I2C-basierte Erweiterungsplatinen mit DS2482. Benutzer anderer Hardware stecken sich wohl lieber einen USB-basierten Busmaster dran bevor sie selber das Löten anfangen. I2C (bzw. SMBus) ist zwar auf vielen Mainboards vorhanden, aber nur selten so gut wie am Pi zugänglich.

Gruß,

Norbert

Zitat von: ntruchsess am 25 März 2014, 10:14:59
Ja natürlich. Wobei der Einrichtungsaufwand nur für bestimmte Hardware niedrig ist. Für den Raspberry Pi z.B. gibt es fertige I2C-basierte Erweiterungsplatinen mit DS2482. Benutzer anderer Hardware stecken sich wohl lieber einen USB-basierten Busmaster dran bevor sie selber das Löten anfangen. I2C (bzw. SMBus) ist zwar auf vielen Mainboards vorhanden, aber nur selten so gut wie am Pi zugänglich.

Stimmt, aber ich denke , wer Frm nutzt , der lötet auch selbst. Und ich habe hier noch was ähnliches auf Pic Basis liegen ;D

Zitat von: ntruchsess am 25 März 2014, 09:18:33
ja, die 'Forall_Clients'-logic zum Aufruf der InitFn funktioniert ja erst, wenn das IODev schon gesetzt ist (Henne-Ei Problem). Muss grad mal kurz in mich gehen, wie das im FRM genau zusammenspielt.

Ich kann assingnioport ja auch schon mal im define ausführen...Das ist halt nicht gerade sauber

Zitat von: ntruchsess am 25 März 2014, 09:18:33
Für soche GPIO-devices sollte man mal ein hardwareunabhängigs Interface zu SubDevices (a la FRM_IN (http://fhem.de/commandref.html#FRM_IN) / FRM_OUT (http://fhem.de/commandref.html#FRM_OUT)) definieren, da könnten noch einige andere Module davon profitieren. Die Lösung mit readingsProxy (http://fhem.de/commandref.html#readingsProxy) leistet das zwar grundsätzlich auch, erfodert aber als generische Lösung einiges an Verständnis beim Benutzer um es richtig zu konfigurieren.

Die Idee ist nicht schlecht, dann ließen sich alle GPIO Portextender gleich ansprechen. Das ist auch für I2C PWM ICs möglich.
Nur würde da eine dritte Ebene eingeführt. IODEV <-> PCFxxx <-> GPIO_IN.
Die beiden oberen Ebenen müssen auch eine Schnittstelle bekommen.

Klaus, bitte nicht direkt in den master committen!!! (https://github.com/ntruchsess/fhem-mirror/commit/3b914d5189252c8db5173f470b3b8350713685bf), das macht mir unnötig Arbeit beim SVN<->Git-sync. Entweder direkt ins SVN, oder in den I2C-branch.

Zitat von: klausw am 25 März 2014, 11:12:55Nur würde da eine dritte Ebene eingeführt. IODEV <-> PCFxxx <-> GPIO_IN.

Genaus so habe ich mir das auch gedacht. Anders würde das auch keinen Sinn machen.

Gruß,
Norbert

Zitat von: ntruchsess am 25 März 2014, 13:48:16
Klaus, bitte nicht direkt in den master committen!!! (https://github.com/ntruchsess/fhem-mirror/commit/3b914d5189252c8db5173f470b3b8350713685bf), das macht mir unnötig Arbeit beim SVN<->Git-sync. Entweder direkt ins SVN, oder in den I2C-branch.

Dazu müsste ich erstmal wissen was ich tue ;)
Habe mich bisher nicht mit Versionierungstools beschäftigt.
-> Verschoben  (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_SHT21.pm)
richtig?

Zum IODev:
kann es sein, das über FRM_Client_AssignIOPort (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L556) das IODev definiert wird? Dann würde ich aber nicht verstehen, wo der clienthash herkommt.

Grüße
Klaus

Zitat von: klausw am 25 März 2014, 14:16:11
Dazu müsste ich erstmal wissen was ich tue ;)
Habe mich bisher nicht mit Versionierungstools beschäftigt.
-> Verschoben  (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_SHT21.pm)

jo, das isses besser aufgehoben. Ansonsten kein Problem, hab grade den aktuellen Stand im master mit 'git push -force' drübergebügelt ;-)

FRM_Client_AssignIOPort wird vom Client aufgerufen (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/20_FRM_IN.pm#L162).

Hm... ich merke grade, dass das nur funktioniert, wenn man entweder Define manuell (von der WebOberflächer her) aufruft, oder wenn das IODev-attribute beim Neustart schon gesetzt ist (wobei das in Summe nicht so schlimm ist, weil der manuelle Aufruf von Define implizit das gefundene IO-Device mit setzt). Nur wenn man fhem jetzt mit einer fhem.pl ohne IODev-attribute startet, dann findet es auch kein IODev mehr, weil FRM_forall_clients den Client dann ja nicht kennt (die Fehlermeldungen sind dann aber ziemlich eindeutig und wenn man IODev dann manuell setzt, passt alles). Werde ich also erst mal so lassen - Devices ohne explizit zugeordnetes IODev sollte es mit der aktuellen Implementierung von AssignIoPort in Zukunft sowieso nicht mehr geben.

Zitat von: ntruchsess am 25 März 2014, 14:55:52
Devices ohne explizit zugeordnetes IODev sollte es mit der aktuellen Implementierung von AssignIoPort in Zukunft sowieso nicht mehr geben.

Das heisst also, ich muss in Zukunft immer das DevIO Attribut setzen?

Zitat von: klausw am 25 März 2014, 15:19:20
Das heisst also, ich muss in Zukunft immer das DevIO Attribut setzen?

das macht AssignIoPort (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/fhem.pl#L1612) für Dich. Dazu muss 'IODev' in der Liste der Attribute mit aufgeführt sein.

Zitat von: ntruchsess am 25 März 2014, 15:22:06
das macht AssignIoPort (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/fhem.pl#L1612) für Dich. Dazu muss 'IODev' in der Liste der Attribute mit aufgeführt sein.

Genau das meinte ich, ohne diese Attribut wird es also in Zukunft nicht gehen.
Aus diesem Grund funktionierte es sicherlich auch nicht bei mir. Ich habe das Attribut nicht gesetzt.
Dann probiere ich das gleich mal aus ... und vervollständige die commandref diesbezüglich

Eine Kleinigkeit: wir sollten uns darauf einigen die I2C-addresse einheitlich zu interpretieren. Ich habe das bisher dezimal gemacht, Deine Module erwarten hex. Ich wäre dafür das so wie Perl selbst Integer Literale (http://docstore.mik.ua/orelly/perl3/lperl/ch02_02.htm) interpretiert zu machen: führende 0: oktal, 0x/0X hex 0b/0B binaer alles andere dezimal. Also mit ~= /^0.*/ testen ob es mit 0 anfängt - wenn ja, dann 'oct'  benutzen, ansonsten direkt den Wert, so wie er kommt.

Zitat von: ntruchsess am 25 März 2014, 15:46:45
Eine Kleinigkeit: wir sollten uns darauf einigen die I2C-addresse einheitlich zu interpretieren. Ich habe das bisher dezimal gemacht, Deine Module erwarten hex. Ich wäre dafür das so wie Perl selbst Integer Literale (http://docstore.mik.ua/orelly/perl3/lperl/ch02_02.htm) interpretiert zu machen: führende 0: oktal, 0x/0X hex 0b/0B binaer alles andere dezimal. Also mit ~= /^0.*/ testen ob es mit 0 anfängt - wenn ja, dann 'oct'  benutzen, ansonsten direkt den Wert, so wie er kommt.

Gute Idee, ich kopiere es dann aus Deinem Modul :)

bitte schön (https://github.com/ntruchsess/fhem-mirror/commit/1c84ec8c18b16f493c2706d0d52094093edfbd40) :-)

Zitat von: ntruchsess am 25 März 2014, 16:22:04
bitte schön (https://github.com/ntruchsess/fhem-mirror/commit/1c84ec8c18b16f493c2706d0d52094093edfbd40) :-)

Danke :D
Jetzt funktioniert es soweit...falls ich heute Abend dazukomme werde ich es einchecken.

Die Geschichte mir generellen IN/ OUT Modulen muss ich mir noch überlegen. Das ist etwas komplexer.

Bin noch am überlegen, was ich mit dem 52_I2C_BMP180.pm mache.
Der 51_I2C_BMP180.pm wir ja eigentlich obsolete...
Oder ich benenne ihn in 52_I2C_Pressure.pm oder so um.

Zitat von: klausw am 25 März 2014, 17:40:47
Bin noch am überlegen, was ich mit dem 52_I2C_BMP180.pm mache.
Der 51_I2C_BMP180.pm wir ja eigentlich obsolete...
Oder ich benenne ihn in 52_I2C_Pressure.pm oder so um.

Frag doch den Dirk Hoffman, was er dazu sagt.

Für mich ist das bisherige Modul keineswegs obsolet.

@Norbert: kann man in Perl abfragen ob eine Bibliothek existiert und sie dann verwenden?

natürlich kann man: eval {"use blaLibrary"} wahlweise auch mit require statt use.

Wird auch in diversen Modulen so verwendet, z.B. 02_RSS.pm, 32_mailcheck.pm ...

Zitat von: klausw am 25 März 2014, 17:40:47
Bin noch am überlegen, was ich mit dem 52_I2C_BMP180.pm mache.

eine Möglichkeit wäre beides zu mergen und über ein Attribut umschaltbar zu machen, ob man die neue hardwareunabhängige I2C-api (über IODev) oder den direkten Zugriff auf die hardwarespezifische lib (im Modul) benutzen möchte. Der BMP180-spezifische code ist in beiden Fällen ja praktisch der gleiche. Dazu wrapped man am z.B. die neue API in einem Package welches die gleichen benötigten Methoden wie die hardwarespezifische Lib hat. Dann kann man weite Teile des codes unverändert lassen. Wie so ein Wrapper aussehen kann kannst Du z.B. hier im I2C_LCD (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_LCD.pm#L319) modul sehen. Der Wrapper bietet die gleiche i2c_write-methode an, wie die firmata-library, die das Modul vorher verwendet hat und ruft statt dessen die I2CWrtFn im IODev auf. (So ein Objektorientierter Wrapper ist auch sonst nicht schlecht, ich finde er macht den übrigen code durchaus auch lesbarer)

Ach so - am Wochenende würde ich das mal mit meinem Pi ausprobieren. Brauch ich (außer den I2C-kernelmodulen) irgendwelche Hardware, oder kann man die I2C-devices direkt an den GPIO-pins anschließen?

Gruß,

Norbert

Zitat von: ntruchsess am 25 März 2014, 22:21:11
Ach so - am Wochenende würde ich das mal mit meinem Pi ausprobieren. Brauch ich (außer den I2C-kernelmodulen) irgendwelche Hardware, oder kann man die I2C-devices direkt an den GPIO-pins anschließen?

Gruß,

Norbert

Nein, einfach an die Pins anschließen. Auch die Pullups sind schon drauf.
Die Pins sind 3,3V Logik!
Für das Device::SMBus musst du ein paar Stunden einplanen. Der Cpan Kram dauert ewig.

Zitat von: betateilchen am 25 März 2014, 19:48:01
natürlich kann man: eval {"use blaLibrary"} wahlweise auch mit require statt use.

Wird auch in diversen Modulen so verwendet, z.B. 02_RSS.pm, 32_mailcheck.pm ...

an sich leicht verständlich, wenn man die Beispiele sieht ;)
das sollte ich hinbekommen

Zitat von: ntruchsess am 25 März 2014, 22:07:59
Wie so ein Wrapper aussehen kann kannst Du z.B. hier im I2C_LCD (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_LCD.pm#L319) modul sehen. Der Wrapper bietet die gleiche i2c_write-methode an, wie die firmata-library, die das Modul vorher verwendet hat und ruft statt dessen die I2CWrtFn im IODev auf. (So ein Objektorientierter Wrapper ist auch sonst nicht schlecht, ich finde er macht den übrigen code durchaus auch lesbarer)

Irendwie stehe ich auf den Schlauch. Ich kann nur eine i2c_write methode erkennen. Wo ist die von der firmata library?

Zitat von: klausw am 26 März 2014, 10:41:16Ich kann nur eine i2c_write methode erkennen. Wo ist die von der firmata library?

-> hier (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/lib/Device/Firmata/Platform.pm#L575)

Der Witz ist, dass es der LCD-library egal ist (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/lib/LiquidCrystal_I2C.pm#L363), ob sie Device::Firmata::Platform::i2c_write (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/lib/Device/Firmata/Platform.pm#L575) oder I2C_LCD_IO::i2c_write (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_LCD.pm#L328) aufruft, solange sich die beiden gleich benannten Methoden nach außen hin gleich verhalten. Wenn man das Package mit 'bless' als Klasse verwendet (hier (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_LCD.pm#L86) der Aufruf des new (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/52_I2C_LCD.pm#L321)-constructors), dann steckt der Packagename implizit im Objekt, wenn man den methodennamen mit $objekt->methode(..) aufruft.

Grundsätzlich verstehe ich es. Aber ich muss in einer ruhigen Minute mal drüberschauen um es im Detail zu verstehen.

Mir ist noch etwas anderes aufgefallen: Wenn das IODev im Client nicht beim starten von FHEM definiert ist und man es nachträglich hinzufügt, dann wir die InitFn nicht ausgeführt.
Das ist kein riesen Problem, aber schön ist es nicht.
Hast Du eine Idee wie man das beheben kann?

Warum heißt es eigentlich RPII2C aber im Gegensatz dazu RPI_GPIO (mit Unterstrich, wie bei allen anderen zugehörigen/ähnlichen Module auch)?

Finde ich wenig intuitiv.

Zitat von: betateilchen am 28 März 2014, 09:04:08
Warum heißt es eigentlich RPII2C aber im Gegensatz dazu RPI_GPIO

Ein Unterstrich im Master Modul (RPI_I2C) hatte dazu geführt das die Verbindung zwischen den Modulen nicht funktioniert.
Nur RPI finde ich unpassend weil es nicht das einzige Modul für den Pi ist.

Zitat von: klausw am 25 März 2014, 22:27:17
Für das Device::SMBus musst du ein paar Stunden einplanen. Der Cpan Kram dauert ewig.

wieso ein paar Stunden? Ich habe das gerade installiert (allerdings manuell, da die automatische Installation per CPAN bereits beim Entpacken des Modularchivs scheitert)

Erster Schritt (Dauer ca. 10 Sekunden):


root@fhem-dev ~/.cpan/sources/authors/id/S/SH/SHANTANU/Device-SMBus-1.06 # perl Makefile.PL
Checking if your kit is complete...
Looks good
Warning: prerequisite Moose 0 not found.
Writing Makefile for Device::SMBus
Writing MYMETA.yml



Die Warnung bezüglich Moose sollte man ernstnehmen und das fehlende Paket nachinstallieren! (Dauer ca. 1 Minute)



apt-get install libmoose-perl



Nächster Schritt (Dauer ca. 1 Minute)



root@fhem-dev ~/.cpan/sources/authors/id/S/SH/SHANTANU/Device-SMBus-1.06 # make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-compile.t ......... ok   
t/00-report-prereqs.t .. # Prerequisite Report:
#   Version Module               
#   ------- ---------------------
#      1.20 Carp                 
#   6.57_05 ExtUtils::MakeMaker 
#      1.11 Fcntl               
#      1.19 File::Find           
#      3.33 File::Spec::Functions
#      0.22 File::Temp           
#      1.15 IO::File             
#      1.23 List::Util           
#    2.0603 Moose               
#      0.98 Test::More           
#      0.13 XSLoader             
#      1.21 constant             
#      1.04 strict               
#      1.12 warnings             
t/00-report-prereqs.t .. ok   
t/Device-SMBus.t ....... ok   
All tests successful.
Files=3, Tests=3, 17 wallclock secs ( 0.57 usr  0.05 sys + 15.53 cusr  0.50 csys = 16.65 CPU)
Result: PASS



Letzter Schritt (Dauer ca. 8 Sekunden):


root@fhem-dev ~/.cpan/sources/authors/id/S/SH/SHANTANU/Device-SMBus-1.06 # make install
Manifying blib/man3/Device::SMBus.3pm
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /usr/local/lib/perl/5.14.2/auto/Device/SMBus/SMBus.bs
Installing /usr/local/lib/perl/5.14.2/auto/Device/SMBus/SMBus.so
Installing /usr/local/lib/perl/5.14.2/Device/SMBus.pm
Installing /usr/local/man/man3/Device::SMBus.3pm
Appending installation info to /usr/local/lib/perl/5.14.2/perllocal.pod
root@fhem-dev ~/.cpan/sources/authors/id/S/SH/SHANTANU/Device-SMBus-1.06 #


Alles in allem weniger als 5 Minuten.

Danach klappts dann auch mit dem define in fhem (Den Luftdrucksensor habe ich aber trotzdem noch nicht zum Laufen gebracht)

Zitat von: betateilchen am 28 März 2014, 10:15:56
wieso ein paar Stunden? Ich habe das gerade installiert (allerdings manuell, da die automatische Installation per CPAN bereits beim Entpacken des Modularchivs scheitert)

Auch gut, das kann ich noch mit in die commandref aufnehmen. Für manuell war ich zu faul ;)

Zitat von: betateilchen am 28 März 2014, 10:15:56
Danach klappts dann auch mit dem define in fhem (Den Luftdrucksensor habe ich aber trotzdem noch nicht zum Laufen gebracht)

Im RPII2C Module ein read 77 AA bringt einen Wert zurück?

Auf welchem System setzt Du es ein?

Ich nutze die kleine BMP180 Platine von Dirk auf einem Raspberry.

Das Ganze funktioniert nur, wenn ich hardwaremäßig genau so vorgehe, wie bisher auch. Ich muss mit den hipi-tools den I2C Bus umschalten:

hipi-i2c e 0 1

Dann funktioniert es auch mit RPII2C und I2C_BMP180 Aber was habe ich dann eigentlich mit den neuen Modulen gewonnnen? Ich dachte, Sinn und Zweck wäre es, gerade die HiPi-Tools nicht mehr zu brauchen?

(http://up.picr.de/17786090vs.png)

Achja: Könnte man die Adresse in den Internals bitte in hex darstellen (77 statt 119)

wie kommt man denn dahin:
root@fhem-dev ~/.cpan/sources/authors/id/S/SH/SHANTANU/Device-SMBus-1.06 # make install
du hast das Paket nicht runtergeladen, oder?

Zitat von: betateilchen am 28 März 2014, 10:46:47
Ich dachte, Sinn und Zweck wäre es, gerade die HiPi-Tools nicht mehr zu brauchen?

Die HiPi tools brauch man auch nicht mehr. Die sind nur eine Alternative

Gibt es ein Dir in den Internals:
HiPi_exists 1
HiPi_used 1

Dann hast Du vergessen /dev/i2c-1 im define zu entfernen
Ausserdem musst Du das attribut IODev vergeben

Wer lesen kann, ist klar im Vorteil  8)

Ich hatte doch weiter oben schon geschrieben, dass die automatische Installation über CPAN am Entpacken des Modul-Archivs scheitert. Das Archiv-File selbst ist aber nach dem Abbruch im angegebenen Pfad durchaus vorhanden.


root@fhem-dev ~/.cpan/sources/authors/id/S/SH/SHANTANU # ls
insgesamt 148K
drwxr-xr-x 3 root root 4,0K Mär 28 09:54 .
drwxr-xr-x 3 root root 4,0K Mär 28 09:52 ..
-rw-r--r-- 1 root root  71K Mär 28 09:52 CHECKSUMS
drwxr-xr-x 6 pi   pi   4,0K Mär 28 10:02 Device-SMBus-1.06
-rw-r--r-- 1 root root  62K Mär 28 09:52 Device-SMBus-1.06.tar.gz


Dann habe ich das Archiv eben "von Hand" ausgepackt und dann mit der perl-"üblichen" manuellen Installationsvariante weitergemacht, was problemlos funktioniert.

Zitat von: klausw am 28 März 2014, 11:03:52
Die HiPi tools brauch man auch nicht mehr. Die sind nur eine Alternative

Gibt es ein Dir in den Internals:

Du fragst mich lauter Zeugs, das ich längst beantwortet habe. Die Internals siehst Du oben.

Zitat von: betateilchen am 28 März 2014, 11:03:58
Das Archiv-File selbst ist aber nach dem Abbruch im angegebenen Pfad durchaus vorhanden.

Diese Info wäre im obere Post hilfreich gewesen :)

Zitat von: betateilchen am 28 März 2014, 11:04:48
Du fragst mich lauter Zeugs, das ich längst beantwortet habe. Die Internals siehst Du oben.

Eben nicht ... Filtert die Firewall raus.

Dass das Archiv nach dem fehlgeschlagenen Entpacken nicht gelöscht wird, nur weil das Entpacken nicht klappt, ist eigentlich normal und bedarf für mich keiner Erwähnung.

Und ich kann nix für Deine Firewall.


Internals:
   CFGFN     
   HiPi_exists 1
   I2C_Address 119
   I2C_RAWMSG 64
   I2C_SENDSTAT Ok
   IODev      I2C
   NAME       BMP180
   NR         31
   STATE      T: 32.7 P: 1010.8 P-NN: 1020.2
   TYPE       I2C_BMP180
   Readings:
     2014-03-28 11:19:36   _state          T: 32.7 P: 1010.8 P-NN: 1020.2
     2014-03-28 11:19:36   altitude        80
     2014-03-28 11:19:36   pressure        1010.8
     2014-03-28 11:19:36   pressure-nn     1020.2
     2014-03-28 11:19:36   state           T: 32.7 P: 1010.8 P-NN: 1020.2
     2014-03-28 11:19:36   temperature     32.7
   Calibrationdata:
     ac1        8566
     ac2        -1206
     ac3        -14749
     ac4        33641
     ac5        24820
     ac6        20318
     b1         6515
     b2         49
     b5         5224.65443544762
     mb         -32768
     mc         -11786
     md         2929
Attributes:
   IODev      I2C
   oversampling_settings 3
   poll_interval 5
   userReadings _state:.* {ReadingsVal('BMP180','state','')}


Das Problem ist, dass ohne die hipi-tools der Sensor auf Dirks Platine weder auf Bus0 noch auf Bus1 gefunden wird, weil diese Platine auf P5 montiert.

Toll, jetzt funktioniert der Sensor überhaupt nicht mehr.


root@fhem-dev /etc/init.d # i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- UU 


UU statt 77 - so eine Kacke. Hätte ich bloß nicht versucht, irgendwas funktionierendes durch etwas nicht funktionierendes zu ersetzen.

Zitat von: betateilchen am 28 März 2014, 11:25:30
Das Problem ist, dass ohne die hipi-tools der Sensor auf Dirks Platine weder auf Bus0 noch auf Bus1 gefunden wird, weil diese Platine auf P5 montiert.

ah das habe ich bisher übersehen
Beim Raspbian für das Rev2 Board wird I2C0 auf den Header J5 umgeleitet um die Camera zu bedienen.
Die HiPi tools ändern einfach die Konfiguration der entsprechenden GPIOs, das I2C0 auf dem P5 anliegt.
Ich denke mal darüber nach, wie das anderweitig zu bewerkstelligen ist.

Irgendwas geht trotzdem noch fürchterlich schief. Einmal habe ich es bisher geschafft, den Sensor mit Deinen neuen Modulen zu verwenden. Im Moment ist es so, dass immer nur noch ein UU anstatt 77 signalisiert wird. Nur ein komplettes Trennen von der Spannungsversorgung schafft es irgendwann, den Sensor wiederzubeleben.

Schreibst Du irgendwas in den Sensor, das der nicht versteht?

Zitat von: betateilchen am 28 März 2014, 13:38:17
Irgendwas geht trotzdem noch fürchterlich schief. Einmal habe ich es bisher geschafft, den Sensor mit Deinen neuen Modulen zu verwenden. Im Moment ist es so, dass immer nur noch ein UU anstatt 77 signalisiert wird. Nur ein komplettes Trennen von der Spannungsversorgung schafft es irgendwann, den Sensor wiederzubeleben.

Schreibst Du irgendwas in den Sensor, das der nicht versteht?

Nein, ich habe das BMP180 Modul zwar umstrukturieren müssen, da für die master-slave Lösung ein asynchroner Hardwarezugriff benötigt wird und es für die alternative HiPi Anbindung sinnvoll war den Hardwarezugriff generell zu kapseln. Aber an den Botschaften habe ich nichts geändert (habe gerade nochmal geschaut und mit ist nix aufgefallen).
Mit Verbose 5 solltest Du alles sehen was gesendet und Empfangen wird.
Weisst Du was UU bedeutet? Irgendein Fehlercode?
Bei mir läuft es seit 2 Tagen, allerdings auf P1.
Ich habe 2 Devices, eins über RPII2C und eins über HiPi die beide auf den gleichen BMP180 zugreifen.

Mit define BMP180 I2C_BMP180 /dev/i2c-0 sollte es aber immer noch wie bisher mit HiPi und ohne PRII2C laufen.

Zitat von: klausw am 28 März 2014, 13:57:46
Mit

Code Auswählen Erweitern

define BMP180 I2C_BMP180 /dev/i2c-0 sollte es aber immer noch wie bisher mit HiPi und ohne PRII2C laufen.

Wenn ich DAS versuche, stürzt mein fhem komplett ab! Das letzte was ich da im Frontend zu sehen bekomme, ist das hier: Failed to activate address 119 : Das Gerät oder die Ressource ist belegt

Und auf der Konsole:

Can't call method "bus_read" on an undefined value at ./FHEM/51_I2C_BMP180.pm line 421.

Ok, es ist gelöst.

Deine Lösung ist nicht abwärtskompatibel zu bestehenden Installationen mit dem alten Modul I2C_BMP180.

Bisher war die Vorgehensweise beim fhem-Start folgende:


case "$1" in
'start')
        echo "Starting fhem..."
/usr/local/bin/hipi-i2c e 0 1
sudo echo bmp085 0x77 > /sys/class/i2c-adapter/i2c-0/new_device



JETZT muss das so aussehen:


case "$1" in
'start')
        echo "Starting fhem..."
/usr/local/bin/hipi-i2c e 0 1
# sudo echo bmp085 0x77 > /sys/class/i2c-adapter/i2c-0/new_device



Das Umschalten per hipi-i2c ist zwar derzeit immer noch notwendig,
aber das bisher notwendige Instanziieren des Gerätes auf dem I2C Bus darf nicht mehr durchgeführt werden! (gestrichen, da es vermutlich niemanden ausser mir betrifft)

Achja - kannst Du bitte das reading "altitude" wieder entfernen?
Das ist kein Reading das vom Sensor geliefert wird, sondern es wird aus dem globalen Attribut gelesen und hat deshalb in den Readings des Sensors nichts zu suchen (und es bringt mir hier einiges durcheinander).

Sehr schön, also funktionieren bei Dir jetzt beide Varianten?

Der Absturz war aber mein Fehler... den HArdwarezugriff sollte ich noch mit try abfangen. Dann kommt vermutlich nur ne Fehlermeldung.

Das umschalten mit hipi-i2c ist unschön. Aber was ich bisher aus diversen Foren rausgelesen habe ist, das es nicht so einfach geht.

• GPIO0 und 1 (am J5 connector) müssen auf input geschaltet werden.
• GPIO28 und 29 auf ALT0

Das lässt sich mit einem kleinen c programm bewerkstelligen. Ist aber dummerweise auch wieder Aufwand
Oder auch über ein Perlprogramm...das gleiche, denn es muss als root ausgeführt werden

Zitat von: betateilchen am 28 März 2014, 15:55:25
sudo echo bmp085 0x77 > /sys/class/i2c-adapter/i2c-0/new_device

Diese Zeile habe ich nirgendwo gefunden.
Das seltsame ist, das sich am grundsätzlichen Hardwarezugriff nichts geändert haben sollte.

Zitat von: betateilchen am 28 März 2014, 16:08:09
Achja - kannst Du bitte das reading "altitude" wieder entfernen?
Das ist kein Reading das vom Sensor geliefert wird, sondern es wird aus dem globalen Attribut gelesen und hat deshalb in den Readings des Sensors nichts zu suchen (und es bringt mir hier einiges durcheinander).

klar, hatte mich sowieso schon gewundert, wozu es gut sein soll

Zitat von: klausw am 28 März 2014, 16:13:53
Diese Zeile habe ich nirgendwo gefunden.
Das seltsame ist, das sich am grundsätzlichen Hardwarezugriff nichts geändert haben sollte.

Steht in der Installationsanleitung zur Dirks I2C_BMP180.pm sowie in beiden hier im Forum geführten Threads nach Einführung der kleinen Luftdruckmessplatine.

ZitatDas umschalten mit hipi-i2c ist unschön. Aber was ich bisher aus diversen Foren rausgelesen habe ist, das es nicht so einfach geht.

Das war aber abzusehen. Deshalb hatte ich Dir schon vor langer Zeit die Frage gestellt, wo für mich als Anwender der Vorteil sein soll, wenn ich dann anstatt einem Modul plötzlich zwei Module installieren soll, wenn ich doch nicht um die HiPi herumkomme - vielleicht erinnerst Du Dich an die seinerzeitige Diskussion ;)

Du hast jetzt jedenfalls eine Lösung geschaffen, die vermutlich in Kürze hier im Forum viele Fragen aufwerfen wird - nämlich bei allen Leuten, die bisher mit dem alten Modul arbeiten und jetzt plötzlich eine neue Modulversion mit gleichem Namen aufgezwungen bekommen, die danach nicht mehr funktioniert.

Hatte ich nicht vor zwei oder drei Tagen nicht hier im Thread (http://forum.fhem.de/index.php/topic,19797.msg152782.html#msg152782) schon geschrieben, dass die alte Modulversion 51_I2C_BMP180 für mich nicht obsolet ist?

Warum glaubt mir keiner  8)

Zitat von: klausw am 28 März 2014, 16:14:49
klar, hatte mich sowieso schon gewundert, wozu es gut sein soll

Naja, die Höhe wird gebraucht, um den Luftdruck auf Meereshöhe beziehen zu können. Aber bisher gab es das reading überhaupt nicht.

Zitat von: betateilchen am 28 März 2014, 16:22:05
Naja, die Höhe wird gebraucht, um den Luftdruck auf Meereshöhe beziehen zu können. Aber bisher gab es das reading überhaupt nicht.

Das habe ich schon verstanden ;) aber es ist ja nur eine Kopie vom globalen Attribut.
Das reading wurde von Dirk eingeführt: klick (http://sourceforge.net/p/fhem/code/4946/tree/trunk/fhem/FHEM/51_I2C_BMP180.pm)
Daher hatte ich es erstmal drin gelassen.

Zitat von: klausw am 28 März 2014, 16:34:10Das reading wurde von Dirk eingeführt: Daher hatte ich es erstmal drin gelassen.

Dann muss ich das schon die ganze Zeit übersehen haben 8)

Noch eine Info am Rande:

Die automatische Installation von Device::SMBus über CPAN dauert auch weniger als eine Minute.

Vorausgesetzt man hat vorher schon das Moose Paket installiert - und das macht man tunlichst aus einem fertigen Paket seiner jeweiligen Distribution:

apt-get install libmoose-perl

Ansonsten kann es wirklich Stunden dauern, weil CPAN sonst anfängt, alle Abhängigkeiten selbst aufzulösen und die ganzen fehlenden Libraries per Compiling selbst zu erstellen. Die Installation des genannten Paketes per Distributions-Paket dauert maximal zwei Minuten.

(Auf dem Cubietruck ist die Installation testweise problemlos durchgelaufen)

Zitat von: betateilchen am 28 März 2014, 16:21:10
Steht in der Installationsanleitung zur Dirks I2C_BMP180.pm sowie in beiden hier im Forum geführten Threads nach Einführung der kleinen Luftdruckmessplatine.

Bei Dirk im commandref steht nur das: sudo hipi-i2c e 0 1

Die Zeileecho bmp085 0x77 > /sys/class/i2c-adapter/i2c-0/new_device habe ich nur in einem Post von Dir gefunden. Dort beschreibst Du aber, das diese Zeile für einen Kernel mit Kernelmodul BMP085 und Deinem BBB_BMP180 Modul benötigt wird. klick (http://forum.fhem.de/index.php/topic,13771.msg99302.html#msg99302) In diesem Zusammenhang macht es für mich Sinn. Für HiPi ist es doch nicht nötig.
Ist es möglich, das du heute von BBB_BMP180 auf I2C_BMP180 umgeschwenkt bist?

Zitat von: betateilchen am 28 März 2014, 16:21:10
Das war aber abzusehen. Deshalb hatte ich Dir schon vor langer Zeit die Frage gestellt, wo für mich als Anwender der Vorteil sein soll, wenn ich dann anstatt einem Modul plötzlich zwei Module installieren soll, wenn ich doch nicht um die HiPi herumkomme - vielleicht erinnerst Du Dich an die seinerzeitige Diskussion ;)

Gaanz Dunkel :)
Für das BMP Modul ist es kein Vorteil.
Wenn man um HiPi rumkommt, was ich immer noch hoffe ist es aber auch kein riesen Nachteil.
Der Vorteil liegt für mich in den weiteren Modulen auf der Hand, die jetzt alle eine gemeinsame Schnittstelle haben.

Zitat von: betateilchen am 28 März 2014, 16:21:10
Du hast jetzt jedenfalls eine Lösung geschaffen, die vermutlich in Kürze hier im Forum viele Fragen aufwerfen wird - nämlich bei allen Leuten, die bisher mit dem alten Modul arbeiten und jetzt plötzlich eine neue Modulversion mit gleichem Namen aufgezwungen bekommen, die danach nicht mehr funktioniert.

Ja das wäre ärgerlich.

Zitat von: betateilchen am 28 März 2014, 16:21:10
Hatte ich nicht vor zwei oder drei Tagen nicht hier im Thread (http://forum.fhem.de/index.php/topic,19797.msg152782.html#msg152782) schon geschrieben, dass die alte Modulversion 51_I2C_BMP180 für mich nicht obsolet ist?

Warum glaubt mir keiner  8)

Du weisst doch...Ratschläge sind auch Schläge :)

Ich hatte es so verstanden, das Du die HiPi Geschichte weiter drinhaben möchtest...schon allein, das es nach einem update noch läuft. Nur aus diesem Grund habe ich sie eingebaut. Die Probleme mit dem I2C-0 hatte ich leider überhaupt nicht auf dem Schirm. Aber nachher ist man immer schlauer.

Zitat von: betateilchen am 28 März 2014, 16:43:45
Noch eine Info am Rande:

Die automatische Installation von Device::SMBus über CPAN dauert auch weniger als eine Minute.

Vorausgesetzt man hat vorher schon das Moose Paket installiert - und das macht man tunlichst aus einem fertigen Paket seiner jeweiligen Distribution:

Code Auswählen Erweitern

apt-get install libmoose-perl

Ansonsten kann es wirklich Stunden dauern, weil CPAN sonst anfängt, alle Abhängigkeiten selbst aufzulösen und die ganzen fehlenden Libraries per Compiling selbst zu erstellen. Die Installation des genannten Paketes per Distributions-Paket dauert maximal zwei Minuten.

(Auf dem Cubietruck ist die Installation testweise problemlos durchgelaufen)

Ok, dass kommt mit in die Beschreibung rein.
Danke

Klaus,

eigentlich sollte das doch plattformübergreifend sein, da passt es eigentlich überhaupt nicht rein, dass 51_I2C_BMP180 mit internals des IODevs (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/51_I2C_BMP180.pm#L275) rumspielt? Die Schnittstelle sollte sich schon auf die vereinbarten Methoden beschränken.

Gruß,

Norbert

Wenn ich nach dem Reboot gpio readall eingebe, dann sind GPIO28 und 29 bereits auf ALT0 gesetzt. Kann es sein das die aktuellste Version von Raspbian den I2C-0 schon per default auf den P5 Header legt?
Vor Montag komme ich nciht dazu, aber dann werde ich eine neue Version ohne HiPi aufsetzen und den BMP180 an den P5 klemmen.

Hallo Norbert,

Zitat von: ntruchsess am 28 März 2014, 17:41:14
eigentlich sollte das doch plattformübergreifend sein, da passt es eigentlich überhaupt nicht rein, dass 51_I2C_BMP180 mit internals des IODevs (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/51_I2C_BMP180.pm#L275) rumspielt? Die Schnittstelle sollte sich schon auf die vereinbarten Methoden beschränken.

Meinst Du $hash->{HiPi_used}?
Das wird ausschließlich gesetzt wenn die Kommunikation nicht über das IODev geht, sonder Modulintern über die HiPi Bibliothek.
Die Schnittstelle sollte doch trotzdem wie vereinbart funktionieren, da entweder HiPi_used gesetzt ist Oder ein IODev genutzt wird.

Zitat von: klausw am 28 März 2014, 16:56:13Dort beschreibst Du aber, das diese Zeile für einen Kernel mit Kernelmodul BMP085 und Deinem BBB_BMP180 Modul benötigt wird. In diesem Zusammenhang macht es für mich Sinn. Für HiPi ist es doch nicht nötig.
Ist es möglich, das du heute von BBB_BMP180 auf I2C_BMP180 umgeschwenkt bist?

Nein, aber es könnte sein, dass ich irgendwann mal das Startskript vom BBB auf RPi kopiert habe und der Eintrag einfach bisher keine Auswirkung hatte.
Zwischenzeitlich hatte ich auf dem dev-System auch mal einen Raspl-Kernel kompiliert, der die I2C Module mitgebracht hat. Vielleicht einfach ein Überbleibsel aus der frühen Bastelzeit.

Zitat von: klausw am 28 März 2014, 17:42:26Kann es sein das die aktuellste Version von Raspbian den I2C-0 schon per default auf den P5 Header legt?

Vermutlich nicht. Denn dann würde ich ja HiPi nicht mehr zum Umschalten brauchen. Vor dem Umschalten wird auf keinem I2C Bus irgendein Device gefunden.

Zitat von: klausw am 28 März 2014, 17:50:13
Meinst Du $hash->{HiPi_used}?

Nein, ich meine Dinge wie sowas wie $hash->{IODev}->{NAME}."_SENDSTAT" (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/51_I2C_BMP180.pm#L275), die in der API nicht vereinbart waren.

ohne das (https://github.com/ntruchsess/fhem-mirror/blob/I2C_BMP180/fhem/FHEM/51_I2C_BMP180.pm#L267) funktioniert es nämlich auch mit FRM :-)

Gruß,

Norbert

In Post 10 habe ich es aber drin stehen :)
Wie hast du die Überprüfung gemacht ob fehlerfrei übertragen wurde?
An sich kann es wirklich weg

Du hast Recht, in Post 10 steht was dazu. Hatte ich nicht auf dem Schirm. Nur wozu sollte das der Client das alles brauchen? Entweder das Auslesen klappt (ganz oder teilweise), dann ruft das IODev die I2CRecFn auf (ob die Daten vollständig und plausibel sind kann eh nur der Client selbst prüfen), oder es klappt gar nicht, dann braucht man die I2CRecFn eigentlich auch gar nicht erst aufzurufen. Wenn der I2C-Adapter nämlich asynchron über Netzwerk angebunden ist (wie beim FRM der Fall), dann weiß das IODev erst mal nicht, ob überhaupt eine Antwort kommt - Wenn man den Fehlerfall erkennen will, dann muss man alle Kommandos queuen und mit einem Timeout versehen nach dessen Ablauf man dann die Fehlernachricht an den Client sendet. Das ist natürlich grundsätzlich mal möglich, aber gewinnt man dadurch so viel außer die Komplexität der Schnittstelle zu erhöhen?
Wenn man sich trotzdem darauf einigt die I2CRecFn im Fehlerfall aufzurufen, dann finde ich sollte der Name des hash-keys eine Konstante sein und nicht vom Namen des IODevs abhängen.

P.S. ich will da jetzt ja kein Fass aufmachen... ich füge das xxx_SENDSTAT jetzt erst mal mit konstantem Wert 'Ok' dem FRM-modul hinzu. Über die Details der Semantik muss man halt noch mal reden, was denn im Fehlerfall tatsächlich passieren sollte.

P.P.S: kaum ist es drin (https://github.com/ntruchsess/fhem-mirror/commit/7d2b3f981856d10e81e7d57143ee5b129cd008de), schon klappts auch mit den InputPorts vom PCF8574 :-)

Gruß,

Norbert

Stop :))
Du musst nix hinzufügen. Das ist eigentlich eine Altlast vom FS20, was ich als Vorlage verwendet habe. Für den Anfang war es schön zum Debuggen. Aber eigentlich kann es weg.

na gut... Ausbauen ist ja leicht ;-)

Zitat von: ntruchsess am 28 März 2014, 19:39:30
P.P.S: kaum ist es drin (https://github.com/ntruchsess/fhem-mirror/commit/7d2b3f981856d10e81e7d57143ee5b129cd008de), schon klappts auch mit den InputPorts vom PCF8574 :-)

Na wenn ich schon irgenwas sinnloses reinbaue dann auch konsequent in alle Module  8)
Wir können uns aber gern auf eine Konstante einigen.
Ich habe noch ein weiteres physical Modul für einen Pic Controller mit Netzwerkschnittstelle (ist denke ich ähnlich zu FRM)
Da habe ich auch eine Queue eingebaut. Schließlich soll alles schön in Reihenfolge gesendet werden. Einen Timeout habe ich da auch drin. Für das RPII2C Modul macht dies natürlich keinen Sinn da die Hardware direkt dranhängt.

Hallo Klaus,

ich habe gesehen, dass Du das modul Error (https://github.com/ntruchsess/fhem-mirror/commit/9c456dd904a4601761893983ec0f033adf47ca8c) zum ExceptionHandling benutzt. Ich bin ja selber ein großer Beführworter Fehlerbehandlung mit Exceptions zu machen (ich halte es z.B. für sinnvoller schon beim Aufruf eine Exception zu bekommen als immer einen einen SENDSTATE nach dem Empfang des Ergebnisses prüfen zu müssen).
Allerdings ist das Modul Error kein Perl core modul, d.h. man kann nicht davon ausgehen, dass es auf jedem Rechner installiert ist. Bei Modulen zum Hardwarezugriff ist das natürlich in der Regel unvermeidlich, aber wenn es nur um syntaktischen Zucker geht ist das in fhem eher unerwünscht, weil es den User dazu nötigt vermeidbare Module nachzuinstallieren. Geht mit einem einfachen eval (http://perldoc.perl.org/functions/eval.html) ja fast genauso leicht.

Man sollte das in einem eigenen Thread diskutieren, wie die anderen Entwickler das so sehen...

Gruß,

Norbert

Hallo Norbert,

das Modul Error nutze ich, weil es im ursprünglichen BMP180 Modul auch drin war. Ohne Fehlerbehandlung reisst es sonst das ganze FHEM ins Nirvana wenn man den falschen I2C Bus auswählt oder kein Device angeschlossen ist. Eval werde ich mir mal anschauen und wenn es fast genauso leicht geht werde ich es auch hinbekommen es einzubauen.
Ich denke mir leider bei der Nutzung diverser Module nicht soviel. Bei einer Problemlösung schaue ich mir andere FHEM Module an und übernehme Teile von dort. So sieht das Ergebnis dann leider manchmal aus :).
Aber es ist gut, das Du nochmal drüberschaust. Dann habe ich wenigstens die Möglichkeit für Verbesserungen.
In diesem Fall prüfe ich es erst beim SENDSTATE weil ich alles soweit wie möglich in der client-master Struktur lassen wollte und somit auch mit der lokalen Kommunikation über HiPi die gleiche Struktur nutze.
Grüße
Klaus

das 'try' aus Error mach nix anderes als 'eval' (plus ein bischen schlaue Aufbereitung des Fehlers für das catch). Nimm einfach eval + I2C_BMP180_Catch, so wie es an anderen Stellen auch schon verwendet wird.

Wir sollten vereinbaren, dass die I2CWrtFn des IODevs grundsätzlich eine Exception (per 'die') werfen darf und alle Client-module diese mit 'eval' abfangen müssen (und das so im Fhemwiki dokumentieren).
Handhabe ich in meinen FRM-modulen genauso. Auf diese Weise ist es sehr einfach alle fatalen Fehlerzustände im IODev einheitlich zu behandeln.

Gruß,

Norbert

Zitat von: ntruchsess am 29 März 2014, 23:46:41
das 'try' aus Error mach nix anderes als 'eval' (plus ein bischen schlaue Aufbereitung des Fehlers für das catch). Nimm einfach eval + I2C_BMP180_Catch, so wie es an anderen Stellen auch schon verwendet wird.

Ok baue ich so ein.

Zitat von: ntruchsess am 29 März 2014, 23:46:41
Wir sollten vereinbaren, dass die I2CWrtFn des IODevs grundsätzlich eine Exception (per 'die') werfen darf und alle Client-module diese mit 'eval' abfangen müssen (und das so im Fhemwiki dokumentieren).
Handhabe ich in meinen FRM-modulen genauso. Auf diese Weise ist es sehr einfach alle fatalen Fehlerzustände im IODev einheitlich zu behandeln.

Mir erschließt sich der Sinn noch nicht. Master Modul sollte doch alle fatalen Fehlerzustände abfangen. Wieso müssen wir das Ganze auch noch in die Clients weitertragen?

Zitat von: klausw am 29 März 2014, 23:57:10Wieso müssen wir das Ganze auch noch in die Clients weitertragen?

müssen müssen wir gar nix, das ist eine reine Design-entscheidung:

1) Entweder gibt eine Methode Fehlerzustände direkt per return-value zurück (das macht aber eigenentlich nur in rein prozeduralem Code Sinn, wenn die Methode Daten bearbeitet und eingentlich keinen richtigen Rückgabewert hat). Dann kann man so Dinge wie das hier schreiben: return $error if (my $error = doSomeThing(...));

2) Fehlerzustände werden in eine Return-structure mit eingepackt:

sub myMethod()
...
return {
  value => ...,
  status => "ok",
};
...
my $ret = myMethod(...);
return $ret->{status} unless ($ret->{status} eq "ok"));


3) Da der Fehlerzustand ja die Ausnahme ist bleiben die eigentlichen Daten frei von jedem Error-zustand, Fehler werden per Exception propagiert. Das trennt die eigentliche Logik sauber von der Fehlerbehandlung und hat zusätzlich noch den Vorteil, dass man Fehler in verschachtelt aufgerufenen Methoden nicht explizit behandeln und durchreichen muss, sondern diese ganz einfach per Exception ganz außen ankommen:

sub method_A() {
  ...
  dosomething...
  die "Fehler A" if (<errorcondition A>);
  return <richtiger Wert A>;
}

sub method_B() {
  ...
  dosomething...
  die "Fehler B" if (<errorcondition B>);
  return {
    val1 = <richtiger Wert B>,
    val2 = method_A(),
  };
  return;
  return;
}

...
eval {
  ...
  my $value = methodB(...);
  ....
};
if (@_) {
  log "es trat ein Fehler auf: ".@_; #das kann auch 'Fehler A' sein, method_B muss sich darum nicht weiter kümmern.
  return;
};
...


die Klammer mit 'eval{...}' sollte dabei eigentlich möglichst weit 'außen' liegen. D.h. in Fhem in den 'top-level'-methoden der Module (fhem.pl fängt nicht alles per eval ab, da ist weitestgehend o.g. Variante 1) implementiert).
Letztendlich kann man sich mit Variante 3) den ganzen fehlerbehandelnden Code auf den inneren Ebenen inklusive des Weiterreichens nach außen ganz einfach sparen.

Gruß,

Norbert

Zitat von: ntruchsess am 31 März 2014, 16:04:03
müssen müssen wir gar nix, das ist eine reine Design-entscheidung:

schon klar, aber wollen wollen wir und zwar eine sinnvolle Lösung ;)

Wir können gern 3. machen.
Lösung 2 ist ja die Momentane, aber die hatte ich halt ohne großes NAchdenken übernommen.

Aber zum einen habe ich verstanden, das eval den Code zur Laufzeit compiliert. Wird dadurch nicht das System ausgebrems, wenn ich jede Unterroutine mit damit versehe?
Wie bekomme ich im Fall einer exception die Meldung an das Client Modul?

Lies die perldoc von eval (http://perldoc.perl.org/functions/eval.html), 4.Absatz. 'eval BLOCK' wird nur einmal compiliert.

Zitat von: klausw am 31 März 2014, 18:55:19Wie bekomme ich im Fall einer exception die Meldung an das Client Modul?

im einfachsten Fall indem man die Fehlermeldung direkt mit 'die "hier ist dieser Fehler passiert"' als Exception absetzt. Man kann auch typisierte Exceptions programmieren - siehe die (http://perldoc.perl.org/functions/die.html), gegen Ende. Damit kann man dann zwischen unterschiedlichen Exception-typen anhand des Types selbst unterscheiden (z.B. I/0-exceptions vs. Numberformat-exceptions). Das Error-modul erlaubt das recht einfach zu nutzen, aber im Context von fhem braucht man das vermutlich nicht so dringend, da reicht es erst mal festzustellen 'hat nicht geklappt' und die Fehlermeldung in ein 'Error'-reading zu packen. Mit typisierten Exceptions könnte man natürlich richtig fatale Fehler mit einem Abstellen des Moduls quitieren und bei (mutmaßlich) temporären Fehlern einfach weitermachen...

Gruß,

Norbert

Hallo Norbert,

dann lass es uns einfach so machen. Die Anzahl der Module ist im Moment ja noch überschaubar, was die Änderungsarbeit in Grenzen hält.
Typisiert muss denke ich nicht sein, da Fehler sie Ausnahme sein sollten.

Hallo Norbert,

hastDu Dein LCD I2C schon testen können?
Ich habe noch ein C-Control I2C LCD Display daliegen. Das habe ich am Raspberry angeschlossen.
Es basiert auf dem PCF8574. Direkt über RPII2C kann ich Werte schreiben und diese auch zurücklesen. Sprich die Anbindung funktioniert.
Allerdings bekomm ich keinen Text auf das Display.
Mit Display On/Off kann ich manchmal die Hintergrundbeleuchtung toggeln und ein paar Sonderzeichen sind auch schon zu sehen. Aber leider nichts definiertes.

Grüße
Klaus

Zitat von: klausw am 01 April 2014, 00:20:52
hastDu Dein LCD I2C schon testen können?
...
Es basiert auf dem PCF8574.

ja, läuft bei mir (mir FRM). Wenn Deines nicht läuft, kann das aber auch an der Verbindung von PDC8574 und dem eigentlichen Displaycontroller liegen. (Also wenn die Pins anders gemappt sind, als bei meinem). Muss morgen mal das Pinout raussuchen, dann kann man vergleichen.

Gruß,

Norbert

Zitat von: ntruchsess am 01 April 2014, 01:04:45
ja, läuft bei mir (mir FRM). Wenn Deines nicht läuft, kann das aber auch an der Verbindung von PDC8574 und dem eigentlichen Displaycontroller liegen. (Also wenn die Pins anders gemappt sind, als bei meinem). Muss morgen mal das Pinout raussuchen, dann kann man vergleichen.

Hoffentlich ist es das. Das RPII2C funktioniert ja eigentlich.
Lässt sich das Modul ummappen oder muss man ein weiteres erschaffen?

Grüße
Klaus

könnte man im Modul ummappen.

hier mal das Mapping der PCF8574T Pins und LCD bei meinem I2C-LCD-Display mit Adaper von Saintsmart (P0..P7 bezieht sich auf die logischen Portbits des PCF8574, nicht auf die physikalischen Pinsnummern)


LCD:       PCF8574T
1:  VSS
2:  VDD
3:  V0
4:  RS <-> P0
5:  RW <-> P1
6:  E  <-> P2
7:  D0
8:  D1
9:  D2
10: D3
11: D4 <-> P4
12: D5 <-> P5
13: D6 <-> P6
14: D7 <-> P7
15: LED Anode
16: LED Kathode


P3 steuert wohl die LED (Über einen Transistor)

Gruß,

Norbert

Hallo Norbert,

bei meinem Display ist das Mapping anders:

LCD:       PCF8574T
1:  VSS
2:  VDD
3:  V0
4:  RS <-> P5
5:  RW <-> P4
6:  E  <-> P6
7:  D0
8:  D1
9:  D2
10: D3
11: D4 <-> P0
12: D5 <-> P1
13: D6 <-> P2
14: D7 <-> P3
15: LED Anode <-> P7 (über Transistor)

könntest Du das Mapping über die Attribute einstellbar machen?

Grüße
Klaus

mach mal einen Enduser-tauglichen Vorschlag wie das zugehörige Attribut zum Re-mappen syntaktisch aussehen soll, dann baue ich das ein.

Zitat von: ntruchsess am 01 April 2014, 15:18:40
mach mal einen Enduser-tauglichen Vorschlag wie das zugehörige Attribut zum Re-mappen syntaktisch aussehen soll, dann baue ich das ein.

Touché! ;)

Am einfachsten wäre es sicherlich, die Portbits nacheinander mit Leerzeichen dazwischen zu nehmen. In der Commandref ist dazu die Reihenfolge der Pins am LCD beschrieben auf die referenziert wird:
RS | R/W | E | Bel. | D4 | D5 | D6 | D7

das Attribut wäre dann für Deinen Fall:
0 1 2 3 4 5 6 7
und für meinen:
5 4 6 7 0 1 2 3

über einzelne Attribute ist es meiner Meinung nach zu umständlich.

danke, irgendwie startet die Phantasie bei mir manchmal erst, wenn ich einen Vorschlag sehe ;-)

vieleicht sollte man etwas expliziter sein:

RS=0,RW=1,E=2,LED=3,D4=4,D5=5,D6=6,D7=7


was meinst Du? Ich tu mich immer schwer so was zu bewerten, ich bin kein Enduser.

wem sagst du das

es ist genauer, aber dann müsstest Du es als Default Attribut erzeugen.
Dann ist es meiner Meinung nach gut verständlich.
Die Fehlermöglichkeiten sind halt höher wenn man es komplett selbst schreiben muss.

hab mal einen kleinen Parser für das Attribute 'pinMapping' in I2C_LCD eingebaut (https://github.com/ntruchsess/fhem-mirror/commit/7bc1fa3338e34d02e86293bebfdf25764f9324dd). Erst mal nur zum anschauen, die LCD-library kann damit noch nichts anfangen.
Was hälst Du davon?

Super finde ich das! einbauen, einbauen  ;D
Da es schon vorhanden ist und man es nur anpassen muss, ist die Fehlerquelle relativ gering und auch der versierte Enduser sollte damit zurecht kommen.

Ist die LiquidCrystal_I2C hart codiert? Das ist dann auch ein Stück arbeit...

Hallo Norbert,

ich nehme mir gerade die LiquidCrystal_I2C vor.
Mach es Deiner Meinung nach mehr Sinn in expanderWrite die Bits umzusortieren oder
in write4bits und auch die Bitkonstanten anpassen?

Grüße
Klaus

ich habs einfach mal was eingebaut  8)
ist aber noch ungetestet: klick (https://github.com/ntruchsess/fhem-mirror/commit/4392e5673919031b5293aae455defb46658dc35b#diff-8bfd63cdf12d824fe46d1123420e59f9)
edit: getestet -> funktioniert

Sieht auf den ersten Blick gut aus, bin leider noch nicht dazu gekommen es zu testen. Das Asynchrone OWX und OWCOUNT hat mir am Wochenende genug Arbeit gemacht ;-)

Zitat von: ntruchsess am 07 April 2014, 18:26:02
Sieht auf den ersten Blick gut aus, bin leider noch nicht dazu gekommen es zu testen. Das Asynchrone OWX und OWCOUNT hat mir am Wochenende genug Arbeit gemacht ;-)

Naja, für Dein Modul sollte sich auch nix ändern. ;)
Bei mir funktioniert leider nicht alles.
Funktioniert:

set <name> text <text to be displayed>
set <name> clear
set <name> display on|off
set <name> backlight on|off (ist aber invertiert)
set <name> reset
set <name> scroll left|right


Folgende aber nicht:
set <name> home
set <name> cursor <...>
set <name> writeXY x-pos,y-pos,len[,l] <text to be displayed>

set <name> writeXY 1,1,4,4,blah  löscht nur 4 Zeichen in der 2. Zeile ab dem 2. Zeichen

beim Rest passiert nix

Hallo Klaus,

ich hab das PinMapping gerade noch mal sauber überarbeitet (https://github.com/ntruchsess/fhem-mirror/commit/31a8a27283d4bbc48692bbeeebe99430a5bfba29). Die LiquidCrystal.pm (jetzt ohne I2C) ist jetzt unabhängig vom I2C-interface und wäre (mit passender IO-klasse) z.B. auch für LCDs mit UART oder SPI-schnittstelle verwendbar.
Ist allerdings noch ungetestet, komme ich erst heute abend oder so dazu.

Gruß,

Norbert

so, I2C_LCD mit pinMapping-attribute ist jetzt im SVN.

Gruß,

Norbert

Zitat von: klausw am 07 April 2014, 21:11:52
Folgende aber nicht:

Code Auswählen Erweitern

set <name> home
set <name> cursor <...>
set <name> writeXY x-pos,y-pos,len[,l] <text to be displayed>

set <name> writeXY 1,1,4,4,blah  löscht nur 4 Zeichen in der 2. Zeile ab dem 2. Zeichen

der 4. Parameter nach dem writeXY ist ein 'l' oder ein 'r', keine Zahl:

set lcd writeXY 2,3,28,l blah


set cursor muss ich selber mal schauen.

Zitat von: ntruchsess am 09 April 2014, 01:19:16
der 4. Parameter nach dem writeXY ist ein 'l' oder ein 'r', keine Zahl:

Code Auswählen Erweitern


set lcd writeXY 2,3,28,l blah


ah das Leerzeichen hatte ich übersehen.
Ich werde es morgen mal testen, heute komme ich nicht dazu.

Was Du hier (https://github.com/ntruchsess/fhem-mirror/commit/31a8a27283d4bbc48692bbeeebe99430a5bfba29#diff-fc8cbfd5151580557d92f5ad255cdd14R415) gemacht hast verstehe ich aber nicht. Das ist die Sache, die mich an Perl irritiert... alles kann man auf zig verschiedene Weisen schreiben  :o
Hat $orig und $remapped den gleichen Inhalt?

Grüße
Klaus

Hallo Norbert,

Zitat von: ntruchsess am 08 April 2014, 15:49:37
Ist allerdings noch ungetestet, komme ich erst heute abend oder so dazu.

Im I2C_LCD Modul ist noch ein Fehler drin (oder eher in der LCD Library?).

Wenn ich das Attribut pinMapping auf der Detailseite  auswähle und neu schreiben will (egal ob das default Mapping oder ein Neues) kommt folgender Fehler:


cannot set attribute pinMapping to P0=RS,P1=RW,P2=E,P3=LED,P4=D4,P5=D5,P6=D6,P7=D7 for test07: Can't use string ("3") as an ARRAY ref while "strict refs" in use

Einen Verbesserungsvorschlag hätte ich auch noch: eine Überprüfung, ob jedes token und token value nur einmal vorhanden ist.

Grüße
Klaus

in $self->{mapping} ist ein Hash, der zu jedem Pin des GPIO-ports den damit zu verbindenden Pin des LCDs enthält. Die Pins sind als binärzahl (also als eine Bitmask) codiert. So wird z.B. Pin P4 des PCF8584 durch die Zahl 0b00010000 (oder dezimal 32) repräsentiert. Der Hash enthält also die Keys ($orig) 1,2,4,8,16,32,64 und 128, das gleiche gilt für die Values ($remapped). Per default (wenn man kein Mapping angegeben hat) ist $orig gleich $remapped.

$mapped |= $data & $orig ? $remapped : 0;

die Zeile setzt in $mapped für jedes Bit, das in $data gesetzt ist das jeweilige in $remapped angegebene Bit ('|' ist ein 'binäres oder').

Gruß,

Norbert

Zitat von: klausw am 09 April 2014, 12:39:48

Code Auswählen Erweitern


cannot set attribute pinMapping to P0=RS,P1=RW,P2=E,P3=LED,P4=D4,P5=D5,P6=D6,P7=D7 for test07: Can't use string ("3") as an ARRAY ref while "strict refs" in use

ja der Teufel steckt oft im Detail (https://github.com/ntruchsess/fhem-mirror/commit/cb8765c21a07e212a22ed3fb44b4dff94d607937#diff-e2ed3493b6d93d76eec53b9b854acda3L156). (Die eigentlichen, das pinMapping selbst betreffenden Änderungen hatte ich vor dem Einbau separat und erfolgreich Modulgetestet...)

Gruß,

Norbert

Hallo Norbert,

ist es möglich oder besser gesagt mit vertretbarem Aufwand machbar die Unterstützung für DS2482-100 DS2482-800 in das Modul 00_OWX_ASYNC.pm mit einzubauen?
Das würde die Nutzung von I2C am Rpi und anderen Hardwarelösungen sehr vereinfachen.

Grüße
Klaus

klar ist das möglich. Ich habe aber erst dann Zeit dafür, wenn OWX_ASYNC mit allen Devices wirklich stabil läuft. Im Moment arbeite ich noch an einer Lösung für die auftretenden Race-conditions bei 1-Wire-Befehlssequenzen, die sich nicht in einem Rutsch abschicken lassen, weil die Daten sich erst aus den Antworten der Request ergeben.

Zitat von: ntruchsess am 16 April 2014, 15:45:22
klar ist das möglich. Ich habe aber erst dann Zeit dafür, wenn OWX_ASYNC mit allen Devices wirklich stabil läuft. Im Moment arbeite ich noch an einer Lösung für die auftretenden Race-conditions bei 1-Wire-Befehlssequenzen, die sich nicht in einem Rutsch abschicken lassen, weil die Daten sich erst aus den Antworten der Request ergeben.

klar, eins nach dem Anderen  :)

Hallo Klaus,

könntest Du die Information aus diesen Thread

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

bitte in die commandref zu Deinem RPII2C integrieren?

klar doch, müsste ich heute Abend hinbekommen
Weisst du, ob dieser Befehl negative Auswirkungen bei einer älteren Raspbian Version hat?
Wenn nicht würde ich es einfach bei preliminary mit einfügen ohne riesen Text dazu zu schreiben.

Ich würde das eher als Hinweis einbauen, falls jemand auf das beschriebene Problem stößt. Als generelle Voraussetzung finde ich das nicht unbedingt sinnvoll, da es nicht nur raspbian als Betriebssystem für den RaspberryPi gibt.

Zitat von: betateilchen am 03 November 2014, 13:26:44
... da es nicht nur raspbian als Betriebssystem für den RaspberryPi gibt.

stimmt allerdings
Habs hinzugefügt.

Grüße
Klaus