platformübergreifende I2C Module

[klausw]

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

[ntruchsess]

Klaus,

eigentlich sollte das doch plattformübergreifend sein, da passt es eigentlich überhaupt nicht rein, dass 51_I2C_BMP180 mit internals des IODevs rumspielt? Die Schnittstelle sollte sich schon auf die vereinbarten Methoden beschränken.

Gruß,

Norbert

[klausw]

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.

[klausw]

Hallo Norbert,

eigentlich sollte das doch plattformübergreifend sein, da passt es eigentlich überhaupt nicht rein, dass 51_I2C_BMP180 mit internals des IODevs 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.

[betateilchen]

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

[betateilchen]

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

[ntruchsess]

Meinst Du $hash->{HiPi_used}?

Nein, ich meine Dinge wie sowas wie $hash->{IODev}->{NAME}."_SENDSTAT", die in der API nicht vereinbart waren.

ohne das funktioniert es nämlich auch mit FRM

Gruß,

Norbert

[klausw]

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

[ntruchsess]

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, schon klappts auch mit den InputPorts vom PCF8574

Gruß,

Norbert

[klausw]

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.

[ntruchsess]

na gut... Ausbauen ist ja leicht

[klausw]

P.P.S: kaum ist es drin, schon klappts auch mit den InputPorts vom PCF8574

Na wenn ich schon irgenwas sinnloses reinbaue dann auch konsequent in alle Module 
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.

[ntruchsess]

Hallo Klaus,

ich habe gesehen, dass Du das modul Error 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 ja fast genauso leicht.

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

Gruß,

Norbert

[klausw]

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

[ntruchsess]

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