I2C am BBB

klausw · 19 Februar 2014, 15:14:36

Hallo zusammen,

falls jemand ein BBB hat und irgendein I2C IC, beispielsweise einen Drucksensor angeschlossen währe es super wenn ihr folgendes versucht:

von http://forum.fhem.de/index.php/topic,20452.0.html das Modul 10_RPII2C.pm installieren.
Perl Modul Device::SMBus installieren: sudo cpan Device::SMBus
define name RPII2C 1 (für den i2c-1 Bus)

Jetzt müsste direkt eine Kommunikation über das Modul möglich sein.

Wenn es funktioniert ließen sich einheitliche Module für Raspi und BBB entwickeln.

Grüße
Klaus

betateilchen · 19 Februar 2014, 16:01:46

Wo ist der Nennwert? Wenn ich das so mache, muss ich drei Module benutzen, wenn ich das Drucksensormodul für den BBB nutze, brauche ich nur eines.

det. · 19 Februar 2014, 16:42:07

wenn das auf dem RPI so gehen würde, könnte ich die HipiTools da runterwerfen und der RPI ließe sich über FHEM2FHEM an mein Cubie2 Board ankoppeln. Die HipiTools laufen auf dem Cubie2 nicht und den Drucksensor habe ich am RPI angelötet. Bisher gibt es da wilde Fehlermeldungen auf dem Cubie2.
Dafür würde ich gern mehr als 1 Modul einrichten.

klausw · 19 Februar 2014, 17:16:59

Zitat von: betateilchen am 19 Februar 2014, 16:01:46
Wo ist der Nennwert? Wenn ich das so mache, muss ich drei Module benutzen, wenn ich das Drucksensormodul für den BBB nutze, brauche ich nur eines.

Es sind 2 Module die man in Deinem Fall bräuchte.
Nutzen muss es gar niemand.
Es ist nur ein Vorschlag, wie man die Zahl der Module grundsätzlich reduzieren könnte.
Eine einheitliche Schnittstelle würde auch die Implementierung weiterer I2C Module vereinfachen.
In meinen Augen ist das schon ein Mehrwert.

Aber in diesem Tread ging es auch nur darum, es mal auf dem BBB zu testen. Dann würde ich das Modul auch noch dafür anpassen.
Laut Entwickler sollte es grunsätzlich auf allen Linux Architekturen mit I2C Implementierung funktionieren.

klausw · 19 Februar 2014, 17:18:15

Zitat von: det. am 19 Februar 2014, 16:42:07
Dafür würde ich gern mehr als 1 Modul einrichten.

Was meinst du mit mehr als 1 Modul?

det. · 19 Februar 2014, 18:04:07

Hallo Klaus,
Na eben 2 Module, wie Du im vorigen Post richtig schreibst. Will damit sagen, jede Lösung die das auslöten des Drucksensors aus dem RPI unnötig macht, ist mir recht.

klausw · 19 Februar 2014, 18:17:55

Zitat von: det. am 19 Februar 2014, 18:04:07
Hallo Klaus,
Na eben 2 Module, wie Du im vorigen Post richtig schreibst. Will damit sagen, jede Lösung die das auslöten des Drucksensors aus dem RPI unnötig macht, ist mir recht.

Achso, verstehe

Für FHEM2FHEM muss ich allerdings nochwas einbauen, wie es scheint.
Die Kommunikation zwischen den Modulen läuft über CallFn. Die kann man irgendwie über IOwrite wrappen ...jedenfalls meinte ntruchsess sowas. Sobald ich weiss wie das geht, werde ich hinzufügen.

betateilchen · 19 Februar 2014, 18:40:49

Zitat von: klausw am 19 Februar 2014, 17:16:59
Es sind 2 Module die man in Deinem Fall bräuchte.

kannst Du nicht auf drei zählen?

- Device::SMBus
- 10_RPII2C.pm
- xxx_BMP180.pm

klausw · 19 Februar 2014, 20:54:11

nochmal zurück zum Grund, weswegen ich den Thread aufgemacht habe:

wenn es jemand mit dem BBB getestet hat bitte Bescheid geben.

betateilchen · 20 Februar 2014, 14:45:41

Zitat von: det. am 19 Februar 2014, 16:42:07Die HipiTools laufen auf dem Cubie2 nicht und den Drucksensor habe ich am RPI angelötet. Bisher gibt es da wilde Fehlermeldungen auf dem Cubie2.

Code Auswählen

attr global autoload_undefined_devices 0

wirkt da Wunder...

det. · 20 Februar 2014, 21:24:00

Zitat von: betateilchen am 20 Februar 2014, 14:45:41
Code Auswählen Erweitern
attr global autoload_undefined_devices 0

wirkt da Wunder...

Danke, das werde ich am Wochenende gleich testen. Klausw - sorry für OT

klausw · 20 Februar 2014, 21:43:00

Zitat von: det. am 20 Februar 2014, 21:24:00
Danke, das werde ich am Wochenende gleich testen. Klausw - sorry für OT

ist doch egal, wenns Dir hilft

War sowieso nur ne fixe Idee.....

det. · 23 Februar 2014, 15:00:55

Hallo klausw, hallo betateilchen,
Tip mit attr global autoload_undefined_devices 0

Code Auswählen

2014.02.23 14:44:07 0: Can't locate HiPi/Device/I2C.pm in @INC (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at ./FHEM/51_I2C_BMP180.pm line 36.
BEGIN failed--compilation aborted at ./FHEM/51_I2C_BMP180.pm line 36.

hat es leider nicht gebracht.
Habe die ganzen Sachen für die i2c Module jetzt auf dem RPI installiert, bekomme die Werte vom Drucksensor aber aus DAU Gründen nicht ausgelesen.

klausw · 23 Februar 2014, 16:07:44

beschreibe bitte mal genauer, was nicht geht?

willst du 51_I2C_BMP180.pm mit 00_RPII2C.pm verwenden?
Das geht nicht.
Dazu müsste das Modul I2C_BMP180 angepasst werden.

det. · 23 Februar 2014, 16:31:43

ok, das war nicht klar ausgedrückt. Mein Plan ist, den BMP180 ohne das Modul 51_I2C_BMP180.pm zu verwenden, da letzteres diese HiPi Tools voraussetzt, welche auf dem Cubie2 nicht laufen. Den CO20 Sensor (auch an dem entfernten RPI angeschlossen) kann ich schon prima auf dem Cubie2 loggen. Das dazu nötige Linux Modul Device::USB läuft auf dem Cubie2 und damit gibt es beim loggen keine Fehlermeldung.
Die erforderlichen Linux Module entsprechend I2C Portextender und PWM IC und physical. Modul für I2C Zugriff mit dem RasPi konnte ich auf dem Cubie installieren, somit fehlt mMn. nur noch das Auslesen des BMP180 angeschlossen an i2c 0 77 und ich könnte die Werte über FHEM2FHEM loggen.

klausw · 23 Februar 2014, 17:15:51

Ok, also ein
get read 77 aa 22
funktioniert?

Dem BMP180 kannst Du nicht einfach einen Druckwert entlocken.
Dieser muss erst berechnet werden. Auch muss vor dem Auslesen der Messvorgang gestartet werden.
Dazu brauchst Du schon ein eigenes Modul.

det. · 23 Februar 2014, 18:18:03

1A 2E FB 7D C6 5E 84 4B 60 9F 48 64 19 73 00 2C 80 00 D1 F6 0B A5 transmission: Ok
Offenbar ja, funktioniert.

klausw · 23 Februar 2014, 19:43:16

Super, dann musst du nur noch warten, bis es ein Modul dafür gibt. Notfalls schreibe ich eins, denn ich habe mir auch einen BMP180 bestellt....der sollte bald kommen

det. · 23 Februar 2014, 22:13:32

Hallo klausw,
Das ist eine super Idee, einen Tester hast du schon!

klausw · 28 Februar 2014, 21:23:24

Hier gibt's jetzt eine Version für den BMP180 mit dem Raspi I2C Modul:
http://forum.fhem.de/index.php/topic,20452.0.html

RogerBE · 06 März 2014, 22:05:16

Hallo,

habe an meinen CubieA10 auch ein BMP180.
Wenn ich in der Konsole i2cget -y 1 0x77 eingebe, bekomme ich auch Werte zurück. Wenn ich das in dem Modul 00_RPII2C machen, startet FHEM neu.
Beim Loggen sieht man, dass er beim Code neustartet:

Code Auswählen

if (defined($clientmsg->{nbyte}) && defined($clientmsg->{reg}) && defined($clientmsg->{data}) && $clientmsg->{direction} eq "i2cblockwrite") {

Gruß
Roger

det. · 06 März 2014, 23:11:59

Hallo Roger,
Du bist im faschen Treat, lies mal das alles durch: http://forum.fhem.de/index.php/topic,20452.msg143682.html#msg143682
Das zugehörige Basismodul ist im ersten Beitrag. Bei mir geht es auf dem Cubie2, wobei der Drucksensor im RPI eingebaut ist und über FHEM2FHEM mit dem Cubie2 verbunden ist.

klausw · 06 März 2014, 23:36:41

Zitat von: det. am 06 März 2014, 23:11:59
Das zugehörige Basismodul ist im ersten Beitrag. Bei mir geht es auf dem Cubie2, wobei der Drucksensor im RPI eingebaut ist und über FHEM2FHEM mit dem Cubie2 verbunden ist.

Heisst das, bei Dir läuft die 00_RPII2C.pm auf dem RPI und 52_I2C_BMP180.pm auf dem Cubie2?
Scheinbar hatte ich es wirklich nicht richtig verstanden

klausw · 06 März 2014, 23:56:49

Hi Roger,

Mit i2cget -y 1 0x77 solltest Du erstmal nix plausibles zurückbekommen, da Du keine Registeradresse angegeben hast und somit gerade das Register liest, wo der Pointer steht.

Zitat von: RogerBE am 06 März 2014, 22:05:16
Beim Loggen sieht man, dass er beim Code neustartet:
Code Auswählen Erweitern
if (defined($clientmsg->{nbyte}) && defined($clientmsg->{reg}) && defined($clientmsg->{data}) && $clientmsg->{direction} eq "i2cblockwrite") {

Du gibst das direkt im Modul RPII2C unter get ein?

Code Auswählen

get <name> RPII2C read 77 aa 22
sollte z.B. alle Kalibrierwerte auslesen.

Aber: das Modul hatte ich fürs Raspberry geschrieben und es enthält demnach auch einige Besonderheiten. Aber vielleicht lässt es sich ja anpassen.

Läuft denn die wiringpi Bibliothek auf dem CubieA10?
Konntest du Device::SMBus installieren?
Wie hast Du das loggen eingestellt, das du genau diese Zeile geliefert bekommst?
Diese Codezeile ist zwar in der Subroutine, welche die Schnittstelle zur Hardware ist und den I2C Bus bedienen soll, aber Dein geposteter Ausschnitt gehört zu einem Schreibvorgang und du hattest von einem Lesevorgang geschrieben.

det. · 07 März 2014, 00:32:53

Zitat von: klausw am 06 März 2014, 23:36:41
Heisst das, bei Dir läuft die 00_RPII2C.pm auf dem RPI und 52_I2C_BMP180.pm auf dem Cubie2?
Scheinbar hatte ich es wirklich nicht richtig verstanden

Hallo Klaus,
so ist es nicht, die kompletten Module samt Perl Teilen sind auf beiden Geräten installiert. Den Drucksensor hatte ich im RPI eingelötet, bevor das produktiv FHEM aus Geschwindigkeitsgründen auf das Cubie2 Board umgezogen ist. Da der RPI aber noch als AirPrintserver für ein Brotherlaser MFC genutzt wird und so ein CO2 Luftgütesensor dran steckt, macht es Sinn die 2 Sachen über FHEM2FHEM zu koppeln.
Nun ist es offenbar die Eigenart von FHEM2FHEM, das an beiden Geräten die Module vollständig funktionsbereit installiert sein müssen, sonst hagelt es Fehlermeldungen im Log. Dank Dir geht das jetzt und vorher nicht, da es für das Cubieboard kein HiPi gibt.
Auch für den CO2 Sensor musste ich das ganze Zeugs auf beiden Geräten installieren.

klausw · 07 März 2014, 00:40:59

Deine Hardwarekonfiguration hatte ich schon verstanden.
Mit FHEM2FHEM habe ich nur noch nix gemacht.
Das bedeutet, du hast in beiden fhem.cfg die gleichen Einstellungen für beide Module? Das muss ich mir mal genau anschauen.

Dann hat sich für meine Zwecke (Pi mit Fritzbox verbinden) FHEM2FHEM schon erledigt

RogerBE · 08 März 2014, 00:20:09

Hallo Klaus,

Device::SMBus habe ich installiert.
Bei Verbose 5 im RPII2C kommt die Meldung HWaccess I2CAddr: 77
Danach habe ich im Code nach der Ausgabe in jede Zeile Log3,.. eingetragen und gesehen, dass der Log-Eintrag vor der Zeile noch kommt.

WiringPI habe ich grade für CB gefunden. Muss ich noch testen

klausw · 10 März 2014, 10:24:51

Zitat von: RogerBE am 08 März 2014, 00:20:09
Device::SMBus habe ich installiert.
Bei Verbose 5 im RPII2C kommt die Meldung HWaccess I2CAddr: 77
Danach habe ich im Code nach der Ausgabe in jede Zeile Log3,.. eingetragen und gesehen, dass der Log-Eintrag vor der Zeile noch kommt.

achso, ja dann passiert das also in dem if-Block
Gib mit per PN mal Deine Mailadresse, ich werde dir mal was zum testen schicken

Zitat von: RogerBE am 08 März 2014, 00:20:09
WiringPI habe ich grade für CB gefunden. Muss ich noch testen

Wiringpi nutze ich nur, um die Rechte für den I2C Bus anzupassen. Wenn Du I2CGET auf Deinem System auch ohne sudo nutzen kannst, dann benötigst Du es nicht.

klausw · 19 März 2014, 09:47:51

Der Vollständigkeit halber:

es lag an den fehlenden Rechten für die Datei /dev/i2c-*

Zitat von: klausw am 12 März 2014, 23:34:29
Hi Roger,

mit welchen Nutzerrechten läuft FHEM bei Dir?
Dazu suchst Du im Logfile Server started und weiter hinten in der Zeile steht auch der user.
Dieser ist bei mir fhem

und welche Rechte hat der I2C-Bus den Du nutzt?
Das findest Du mit:
Code Auswählen Erweitern
ls -l /dev | grep i2craus

Der FHEM User sollte schreib und leserechte auf den I2C-Bus haben.

Dieses mache ich beim beim Raspberry mit dem gpio utility aus wiringpi.
Bei mir sieht sie Rechtevergabe so aus:
Code Auswählen Erweitern
crw-rw---T 1 fhem dialout 89, 0 Mär 10 18:01 i2c-0 crw-rw---T 1 fhem dialout 89, 1 Mär 10 18:01 i2c-1

wenn fhem und die i2c Dateien nicht den gleichen Besitzer haben, teste bitte folgendes:
Code Auswählen Erweitern
sudo chown fhem /dev/i2c-* sudo chgrp dialout /dev/i2c-* sudo chmod +t /dev/i2c-* sudo chmod 660 /dev/i2c-*