platformübergreifende I2C Module

[klausw]

Was macht eigentlich 'I2C_LCD_Catch' so ganz verstehe ich das nicht

[ntruchsess]

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.

[ntruchsess]

Muss ich da etwas im RPII2C Modul ändern?

Wenn die Client-module in der DefineFn die InitFn nur aufrufen wenn init_done==1 ist, dann muss ins RPII2C-modul ein Aufruf rein, der diesen Aufruf der InitFn nachholt. Dazu brauchst RPII2C eine NotifyFn (siehe hier, in der DefineFn sollte man das NotifyDef auf global eingrenzen. Aus der NotifyFn ruft man dann für alle Clients die InitFn auf (das passiert in FRM indirekt aus der FRM_DoInit-methode heraus, die DevIo_OpenDev 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

[klausw]

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?

[ntruchsess]

hier ist der I2C-Branch

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

[klausw]

Hallo Norbert,

ich habe die InitFn Zusätze in die 00_RPII2C.pm eingebaut und die InitFn testweise in die  52_I2C_SHT21.pm 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 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

[ntruchsess]

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.

[,,,]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. 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 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 / FRM_OUT) definieren, da könnten noch einige andere Module davon profitieren. Die Lösung mit 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

[ntruchsess]

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

[klausw]

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

[klausw]

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

[klausw]

Für soche GPIO-devices sollte man mal ein hardwareunabhängigs Interface zu SubDevices (a la FRM_IN / FRM_OUT) definieren, da könnten noch einige andere Module davon profitieren. Die Lösung mit 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.

[ntruchsess]

Klaus, bitte nicht direkt in den master committen!!!, das macht mir unnötig Arbeit beim SVN<->Git-sync. Entweder direkt ins SVN, oder in den I2C-branch.

Nur 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

[klausw]

Klaus, bitte nicht direkt in den master committen!!!, 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
richtig?

Zum IODev:
kann es sein, das über FRM_Client_AssignIOPort das IODev definiert wird? Dann würde ich aber nicht verstehen, wo der clienthash herkommt.

Grüße
Klaus

[ntruchsess]

Dazu müsste ich erstmal wissen was ich tue
Habe mich bisher nicht mit Versionierungstools beschäftigt.
-> Verschoben

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.

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.

[klausw]

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?