Hallo zusammen,
Ich habe ein neues Modul Entwickelt um die I2C-Sensoren BMP180 und BMP085 am Raspberry Pi auszulesen.
Der BMP085 und sein Nachfolger BMP180 sind Luftdruck-Sensoen welche über den I2C Bus ausgelesen werden können.
Zur Kommunikation mkit dem I2C-Bus werden hier die Perl-Module HiPi::Device::I2C und HiPi::BCM2835::I2C verwendet.
Für die Schnelle Installation der Perl-Module:wget http://raspberry.znix.com/hipifiles/hipi-install
perl hipi-install
Die I2C-Kernelmodule müssen natürlich noch geladen werden:sudo modprobe i2c-bcm2708
sudo modprobe i2c-dev
Um das persistent zu bekommen, also damit die Module bereits beim Booten geladen werden, müssen diese beiden Zeilen ans Ende von /etc/modules kopiert werden:i2c-bcm2708
i2c-dev
Ein Beispiel für die Configuration des FHEM-Moduls:define BMP180 i2cBMP180 /dev/i2c-0
attr BMP180 oversampling_settings 1
attr BMP180 poll_interval 5
attr BMP180 route_i2c0_to_p5 1
attr BMP180 altitute 220
Dieses Beispiel und der Test läuft bei mir derzeit hier mit:
Link (http://forum.fhem.de/index.php?topic=13771.msg85901#msg85901)
Mit dem hier beschriebenen Modul sollte das aber auch funktionieren:
Link (http://forum.fhem.de/index.php?topic=13179.0)
Das FHEM-Modul würde ich derzeit als Beta einstufen. Und daher hoffe ich auf Feedback.
Gruß
Dirk
Edit: altes Modul entfernt.
Das Modul ist mittlerweile Bestandteil von FHEM (51_I2C_BMP180.pm)
Hallo Dirk,
die Namenswahl für Dein Modul finde ich etwas unglücklich, da gemischte klein- und Großbuchstaben nicht wirklich eine intuitive Benutzung ermöglichen.
Zu Deiner Micro-Luftdruckmeß-Platine ist bei mir am Wochenende noch die Frage aufgetaucht, wie zuverlässig die (auch temperaturabhängigen) Meßwerte sind, wenn man die Platine auf den Raspberry auflötet und den dann in ein Gehäuse einbaut. Noch dazu, wo die Zusatzplatine an der Unterseite sitzt, wo je nach Gehäusetyp ohnehin nahezu keine Luftzirkulation stattfinden kann. Hast Du dazu schon Erfahrungen gesammelt?
Also die Temp ist bei mir um die 42 Grad, also völlig daneben klar, aber der Luftdruck stimmt bis jetzt so ziemlich genau mit dem überein was meine Wetterstation sagt.
Btw. das mit dem neuen Modul werd ich gleich mal ausprobieren. Allerdings wird mir das nicht viel bringen da ich den über FHEM2FHEm abfragen müsste.
/Daniel
Die Temperatur ist natürlich nur eingeschränkt nutzbar, da im eingebauten Zustand wohl die Gehäusetemperatur gemessen und angezeigt wird.
Ansonsten müsste der Sensor über ein kleines Kabel aus dem Gehäuse geführt werden.
Wenn dein Gehäuse und der Raum in dem sich das Gehäuse befindet nicht hermetisch abgeschlossen ist, dann funktioniert die Luftdruckanzeige.
Gruß
Dirk
Zitat von: betateilchen schrieb am Mo, 22 Juli 2013 10:25die Namenswahl für Dein Modul finde ich etwas unglücklich, da gemischte klein- und Großbuchstaben nicht wirklich eine intuitive Benutzung ermöglichen.
Inwiefern beeinflusst die Modulschreibweise die intuitive Benutzung?
Aber auch am Modulnamen halte ich nicht fest. Daher bin ich hier für Vorschläge offen :)
Zitat... wie zuverlässig die (auch temperaturabhängigen) Meßwerte sind, wenn man die Platine auf den Raspberry auflötet und den dann in ein Gehäuse einbaut. Noch dazu, wo die Zusatzplatine an der Unterseite sitzt, wo je nach Gehäusetyp ohnehin nahezu keine Luftzirkulation stattfinden kann. Hast Du dazu schon Erfahrungen gesammelt
Die Temperaturmessung stand bei dem Luftdruckmodul, zu mindest bei mir, erstmal im Hintergrund. Tempertursensoren für FHEM gibt es ja fast wie Sand am Meer. Bei bezahlbaren Luftdrucksensoren sieht das ganze hier etwas anders aus. Daher ist die Temperaturmessung hier eher "Beiwerk".
Zum Luftdruckmessen braucht es auch keinen Zirkulation. Wichtig ist, dass das Gehäuse nicht Luftdicht ist. Die zu messende Luftsäule erreicht den Sensor auch über ein kleines Loch oder Spalt.
Gruß
Dirk
Hallo,
ZitatDie zu messende Luftsäule erreicht den Sensor auch über ein kleines Loch oder Spalt.
Und dazu reicht beim RasPi bereits der Spalt für die SD-Karte völlig aus.
Und so extreme Luftdruckschwankungen in kürzester Zeit wird es nicht geben das der Sensor nicht hinter her kommen wird.
Es sei den der RasPi ist in einem Wirbelsturm (aber da hätte ich andere Sorgen als meine Luftdruckmessung ;-) ).
Grüße
Zitat von: Dirk schrieb am Mo, 22 Juli 2013 12:59Inwiefern beeinflusst die Modulschreibweise die intuitive Benutzung?
ganz einfach: bisher ist es so, dass die allermeisten Gerätemodule in Grossbuchstaben angegeben werden, die ganzen Helpermodule (at dummy notify structure...) fast immer in Kleinbuchstaben. Ich weiss zwar nicht, ob das in den fhem-Developer-Guidelines so festgeschrieben steht, aber ich finde diese Logik nicht die schlechteste.
Vorab: die alternative Lösung mit dem Adafruit python Skript funktioniert nach der Hardwareinstallation und liefert plausible Werte.
Das Modul bekam ich aber nicht ohne weiteres zum Laufen.
aktueller Status:
Inzwischen habe ich die HiPi nochmal installiert.
das Install-Skript legt die generierten Dateien alle nach /usr/local/lib/perl ab.
ich habe sie alle in die richtigen Verzeichnisse nach /usr/lib/perl kopiert.
der Versuch, den define Befehl abzusetzen, führt zu einem komplette Absturz von fhem es scheint noch irgendein Berechtigungsproblem zu sein:
open error on /dev/i2c-0: Keine Berechtigung
also ein sudo chown fhem:root /dev/i2c-0 abgesetzt.
Und siehe da:
(http://up.picr.de/15266291po.png)a
(die beiden Attribute sind von Haus aus gesetzt?)
Aber dann wieder ein Totalabsturz beim Versuch, die oben angebenen weiteren Attribute zu setzen.
bcm2835_init: Unable to open /dev/mem: Keine Berechtigung
Failed to initialise libbcm2835 at ./FHEM/51_i2cBMP180.pm line 151
Also als "Beta" würde ich das Ganze noch nicht einstufen - eher als Alpha. Wobei ich mir noch nicht sicher bin, ob es wirklich am Modul liegt, oder an der Inbetriebnahmeanleitung.
@Dirk hast Du Dein fhem als root laufen? Solche Probleme hätten doch eigentlich schon vorher auffallen müssen.
Der Absturz wird definitiv von diesem Attribut verursacht:
attr BMP180 route_i2c0_to_p5 1
Ist das der Ersatz für das HiPi Umschalten? Ich kann nämlich aus dem Sensor die Werte problemlos auslesen, wenn ich diesen Befehl weglasse.
Hallo zusammen,
Zitat... oder an der Inbetriebnahmeanleitung.
Naja, bei dem Korrekturleser kann das schon mal vorkommen ;-)
Ich habe aber dasselbe Problem mit
open error on /dev/i2c-0: Keine Berechtigunghabe das aber auf meinen mangelnden Speicherplatz (SD Karte fast zu 100 % voll) geschoben. Habe die BMP180 Zeilen auskommentiert und der
fhem Server startete wieder. Leider werde ich diese Woche nicht dazukommen, das Modul weiter zu testen, daher warte ich mal auf Eure Infos, sorry.
Gruß PeMue
Zitat@Dirk hast Du Dein fhem als root laufen? Solche Probleme hätten doch eigentlich schon vorher auffallen müssen.
Äh, mist. Meine Entwicklungsumgebung läuft hier tatsächlich als root. Dann setze ich mir hier noch mal ran un da eine Lösung zu finden.
Ok, das Problem liegt hier dran:
"Because HiPi::BCM2835 accesses the SOC registers directly via /dev/mem, it must run with the necessary root privileges to gain access to /dev/mem."
Allerdings wird der Aufruf nur zum Umrouten des I2C-Busses auf den P5 benötigt.
Also Entweder FHEM als Root laufen lassen, was ich nicht gut finde. Allerdings gibt es auch eine Möglichkeit die Berechtigungen wieder zu kappen:
ZitatHiPi::Utils::drop_permissions_name($user, $group);
Oder Das Umrouten des I2C-Busses vor dem Starten von FHEM seperat auszuführen.
Hat jemand noch eine andere Idee?
Dirk
ei ei ei... da ist aber noch eine Menge zu tun.
- Man muss vor jedem Lesen der Messwerte ein set BMP180 readValues absetzen, die Werte werden nicht automatisch aktualisiert.
Ich habe die beiden Zeilen
hipi-i2c e 0 1
chown fhem:root /dev/i2c-0
in das fhem-Startskript eingebaut. Jetzt werde ich mal schauen, ob das auch nach einem Raspi-Reboot noch funktioniert.
ZitatIch habe die beiden Zeilen
hipi-i2c e 0 1
chown fhem:root /dev/i2c-0
in das fhem-Startskript eingebaut. Jetzt werde ich mal schauen, ob das auch nach einem Raspi-Reboot noch funktioniert.
Das währe der aktuelle Workaround.
Ich habe im Moment auch keine andere Idee wie das sonst zu lösen währ.
Zitat- Man muss vor jedem Lesen der Messwerte ein set BMP180 readValues absetzen, die Werte werden nicht automatisch aktualisiert.
Das macht das Modul aber selber. Man muss den Sensor halt pollen.
mit
set BMP180 readValues kann man die Werte zusätzlich manuell anfordern. Ansonsten pollt das Modul selbständig im eingestellten Intervall.
was ist denn die Einheit für das Intervall? MInuten oder Sekunden? (vielleicht hab ich das irgendwo überlesen)
so klappts auch mit dem Startskript (/etc/init.d/fhem)
case "$1" in
'start')
sudo hipi-i2c e 0 1
sudo chown fhem:root /dev/i2c-0
...
Zitatwas ist denn die Einheit für das Intervall? MInuten oder Sekunden? (vielleicht hab ich das irgendwo überlesen)
Das steht aber in der Moduldokumentation.
poll_interval
Set the polling interval in minutes to query the sensor for new measured values.
Default: 5, valid values: 1, 2, 5, 10, 20, 30
Du hast ja recht. Ich hatte mein mögliches Überlesen ja vorhin schon eingeräumt.
Für die Wunschliste:
- ein Attribut, um die Luftdruckwerte als Integer (ohne Nachkommastellen) zu erhalten.
Die Variante mit dem modifizeirten Startskript hat nun mehrere Reboots überstanden. Ich lass das jetzt erstmal so.
Ich mache dann noch folgende Änderungen am Modul:
- Das Attribute route_i2c0_to_p5 lass ich fallen, da hier FHEM als root laufen müsste.
- Den Hinweis auf das Setzen der Rechte von /dev/i2cX und das Ausführen von hipi-i2c im Startscript von FHEM kommt mit in die Modul-Doku
- Umbenennen des Moduls in I2C_BMP180 wegen "intuitive Benutzung"
- ein Attribut, um die Luftdruckwerte als Integer (ohne Nachkommastellen) zu erhalten.
- Fehlerbehandlung falls z.B. die I2C Module nicht geladen sind usw.
Sonst noch Ideen und Wünsche?
Gruß
Dirk
Für heute war es das erstmal. Aber mir fällt bestimmt noch was ein.
Jetzt lass ich das mal eine Weile laufen und schau mir die Stabilität an. Dann brauch ich die Luftdruckmessung mit dem AVR-NET-IO nicht mehr.
Danke für Deine Unterstützung und das Modul :)
--------------
achja - EINEN hab ich doch noch. Die altitude sollte als optionaler Parameter bei der Definition angegeben werden können, nicht als Attribut.
Vielleicht bekommt FHEM ja irgendwann die Altitude auch als globales Attribut. Den Wunsch hatte ich ja schonmal hier (http://forum.fhem.de/index.php?topic=13722.0) geäußert. Da bräuchte ich noch Unterstützer für den "Antrag" *lach*
Ich mach heute bestimmt auch nix mehr.
Ich danke dir für dein Testing.
Gruß
Dirk
hab oben noch was ergänzt ;)
und nochwas: bitte keine Komma und eine Einheiten im state
Gute Nacht.
Zitatbitte keine Komma und eine Einheiten im state
Du meinst das so hier?
attr BMP180 stateFormat Temp: temperature Pressure: pressureSo kannst du dir jedes Gewünschte State-Format zusammen bauen.
Ich weiß, was stateFormat kann.
In den Development Guidelines steht:
(http://up.picr.de/15267582cn.png)
Man beachte den letzten Satz :)
Mir ist durchaus bewusst, dass dies noch nicht in allen Modulen durchgängig so gehandhabt wird.
Aber wenn man jetzt ein neues Modul baut, kann man das ja auch gleich berücksichtigen.
Und der Wunsch "ohne Komma" hat was mit der Definition für FileLog und Plotten zu tun, da werden die "Spalten" nur durch Leerzeichen getrennt.
ZitatMan beachte den letzten Satz :)
Dann verstehe ich dich grade nicht richtig.
Die Readings haben hier keine Einheiten.
2013-07-22_00:12:32 BMP180 temperature: 42.7
2013-07-22_00:12:32 BMP180 pressure: 996.3
2013-07-22_00:12:32 BMP180 pressure-nn: 1022.2Lediglich im Default-State stehen die drin. Und diese kann man über das StateFormat überschreiben.
Zitat von: Dirk schrieb am Mo, 22 Juli 2013 22:23Oder Das Umrouten des I2C-Busses vor dem Starten von FHEM seperat auszuführen.
Hat jemand noch eine andere Idee?
jepp, hab ich :)
Ich werde das heute abend mit einer udev Regel testen. Die sind ja genau dafür geschaffen, solche Probleme mit Benutzerrechten zu umgehen. Damit sollte zumindest das "sudo" im fhem-Startskript nicht mehr nötig sein.
SUBSYSTEM=="i2c-dev", MODE="0666"
Und wenn das nicht funktioniert, ist der nächste Versuch: Das Device /dev/i2c-0 statisch anlegen und mit entsprechenden Zugriffsrechten ausstatten.
achja - moin :)
Guten Morgen.
udev währ noch eine Idee. Zumindest für die Rechte von /dev/i2c-x.
hipi-i2c brauchts im Startscript dann trotzdem wenn man den P5 nutzen möchte
ZitatDamit sollte zumindest das "sudo" im fhem-Startskript nicht mehr nötig sein.
Das Startscript wird in der Regel doch selber mit sudo bzw. als root ausgeführt. daher sollte sodo hier überflüssig sein.
Zwischenzeitlich gibt's ne neue Version.
<li> Das Modul heisst nun "I2C_BMP180"<li> Das Attribute route_i2c0_to_p5 ist entfallen. "hipi-i2c e 0 1" muss bei bedarf vor dem Start von FHEM z.B. im Startscript ausgeführt werden.<li> Das Attribute "altitute" ist sei vorhin als global Attribute verfügbar, daher wird dieses genutzt. Bitte ggf. die FHEM-Version aus dem SVN auschecken. Morgen sollte die Änderung aber auch per Update verteilt werden<li> es gibt zwei neue Attribute roundPressureDecimal und roundTemperatureDecimal. Damit kann die Genauigkeit der Temperatur- und Luftdruckreadings eingestellt werden.
Gruß
Dirk
Edit: altes Modul entfernt.
Das Modul ist mittlerweile Bestandteil von FHEM (51_I2C_BMP180.pm)
Zitat von: Dirk schrieb am Di, 23 Juli 2013 09:30udev wär noch eine Idee. Zumindest für die Rechte von /dev/i2c-x.
hipi-i2c brauchts im Startscript dann trotzdem wenn man den P5 nutzen möchte
[...]
Das Startscript wird in der Regel doch selber mit sudo bzw. als root ausgeführt. daher sollte sodo hier überflüssig sein.
Hat bei mir gestern nicht ohne sudo funktioniert, darum hatte ich es ja im zweiten Versuch extra eingebaut.
Aber man kann das vermutlich auch über einen Eintrag in /etc/sudoers abfangen:
fhem ALL=NOPASSWD: hipi*Eventuell lässt sich damit sogar das /dev/mem Problem abfangen, wenn man genau weiß, das da aufgerufen wird.
Aktion 1: udev-Regel anlegen = funktioniert
/etc/udev/rules.d/98_i2c.rules enthält:
SUBSYSTEM=="i2c-dev", MODE="0666"
Um das sudo beim Umschalten des I2C Bus im Startskript kommt man allerdings nicht rum.
Ich habe noch eine Idee fürs Modul - ich habe allerdings die neue Version noch nicht installiert: Nach einem fhem-Neustart macht das Modul keinen Poll direkt nach dem Geladenwerden, sondern erst, wenn das Poll-Intervall einmal rum ist.
Na Prima.
Ich teste das die Tage auch mal und nehme das mit in die Moduldoku auf.
Nach einem fhem-Neustart macht das Modul keinen Poll direkt nach dem Geladenwerden, sondern erst, wenn das Poll-Intervall einmal rum ist.Das ist mir auch schon negativ aufgefallen :)
Das werde ich wohl noch umdrehen.
Gruß
Dirk
Deine neue Version habe ich noch gar nicht getestet...
Hallo Dirk,
habe mir mal die aktuelle Version Deines Moduls ausgedruckt zum Lernen. Wie bekomme ich die (vom Modul gepollten Daten) in eine Logdatei? Da müsste doch noch so etwas kommen wie
define Luftdruck_log FileLog ./log/luftdruck-%Y-%m.log BMP180:pressure.*Kommt das hin? Oder kann ich alle drei Werte in eine Datei loggen? Dann würde ich aber die Bezeichnungen etwas kürzer wählen wollen wegen Speicherverbrauch ...
Danke + Gruß
PeMue
Edit:
Das Modul zeigt Grundreflexe:
(siehe Anhang / see attachement)
Vorgehen auf der Konsole:
sudo modprobe i2c-bcm2708
sudo modprobe i2c-dev
sudo hipi-i2c e 0 1
sudo chown fhem.root /dev/i2c-0
Natürlich muss ich das Ganze noch reboot fest machen ...
Allerdings ist mir (als C-Programmierer) überhaupt noch nicht klar, was da im Einzelnen passiert ...
Hi PeMue,
Ich habe das so gemacht:define log_ALL FileLog /opt/fhem/logs/bmp180.log BMP180:(temperature|pressure|pressure-nn):.*Damit landen alle Werte in einem Logfile. Ggf. kann man pressure noch weglassen wenn man nur den höhenkorrigierten Luftdruck loggen möchte.
Ich denke 5 Min. für den Luftdruck reicht vollkommen aus. Vermutlich auch 10 oder 20 Minuten.
Edit:
Die Gehäuseinnentemperatur wirst du wahrscheinlich auch nicht loggen wollen. Daher war deine Version schon ausreichend.
Du kannst den Luftdruck aber z.B. auch in das Logfile eines Temperatursensors loggen. Dann kannst du eine kombinierte Grafik erzeugen.
Gruß
Dirk
ich habe eine Logdatei mit allen Klimadaten
./log/out_Balkon-%Y-%m-%d.log (out_Balkon|Luftdruck|BMP180|Helligkeit)
out_Balkon liefert Außentemperatur und Luftfeuchtigkeit und kommt von einem Homematic-Temperatursensor Outdoor
Luftdruck kommt von einem MPX4100A, angeschlossen an ein AVR-NetIO (fällt demnächst weg)
BMP180 kommt vom BMP180 :)
Helligkeit kommt von einem Sensor, ebenfalls am AVR-NetIO
Alles in einem Logfile und das Plotten kann ich dann machen wie ich will und brauche nur eine einzige Logdatei dafür.
Hallo Dirk,
wahrscheinlich habe ich es überlesen, bei mir kommt nur
2013-07-23 21:53:06 I2C_BMP180 BMP180 temperature: 36.8
2013-07-23 21:53:06 I2C_BMP180 BMP180 pressure: 988.7Vermutlich muss ich das pressure_nn erst noch irgendwie einstellen.
Weitere doofe Frage: Was bedeutet die
NR 96 aus meinem letzten Post, diese ändert sich nämlich nicht ...
Bezüglich Logdateien: Da wird vermutlich mit Datum und <sensorname> der Wert in eine Zeile geschrieben und man parst dann beim Plotten nach den einzelnen Sensornamen. Mir ist es eigentlich lieber, dass ich eine Zeile mit allen Werten habe, aber das geht wegen der zeitlichen Zuordnung der einzelnen Quellen wohl nicht ...
Danke + Gruß
PeMue
ich bin gerade dabei das neue altitude attribute auch für meinen panstamp luftdruck sensor zu verwenden. dabei hätte ich zwei vorschläge:
- als default wert bei nicht gesetztem reading 0 verwenden statt -1. bei höhe 0 über nn fällt der korrekturfaktor ganz natürlich einfach weg.
- auch altitude < 0 zulassen. sogar in deutschland soll es das geben.
gruss
andre
Hi PeMue,
ZitatVermutlich muss ich das pressure_nn erst noch irgendwie einstellen.
Ja, entweder in der älteren Version vom Modul durch
attr BMP180 altitute 220oder in der letzten Version durch
attr global altitute 220Dafür musst du FHEM aber aktualisieren, da das Global altitut erst seit heute im FHEM drinn ist. Daher per SVN auschecken, oder bis morgen warten wenn das per Update kommt.
Zitataus meinem letzten Post, diese ändert sich nämlich nicht ...
Ich hatte den Post irgendwie überlesen.
Die Nr 96 sollte die Nummer des define sein. Quasi so eine Arte fortlaufende Nummerierung der Definitionen.
ZitatDa wird vermutlich mit Datum und <sensorname> der Wert in eine Zeile geschrieben und man parst dann beim Plotten nach den einzelnen Sensornamen.
Ja, so wird das dann gemacht.
Gruß
Dirk
Hi Andre,
Zitat von: justme1968 schrieb am Di, 23 Juli 2013 22:15- auch altitude < 0 zulassen. sogar in deutschland soll es das geben
Da hast du natürlich recht. Da hab ich nicht dran gedacht. Ich werde das im Modul korrigieren.
Zitat- als default wert bei nicht gesetztem reading 0 verwenden statt -1. bei höhe 0 über nn fällt der korrekturfaktor ganz natürlich einfach weg.
Stimmt.
Man könnte sich auch überlegen bzgl. des Geo-Moduls eine eine globale barometrische Höhenformel zu benutzen. Dann muss das nicht jeder selber berechnen.
Gruß
Dirk
Hallo Dirk,
ich hoffe, dass in der eingecheckten Version dann altitude korrekt geschrieben ist ;-)
Vielen Dank noch mal.
Gute Nacht.
PeMue
Mist,
altitute muss natürlich altitude heissen.
Rudi hat es aber ohne "aufsehen" korrigiert :)
Dafür fehlt aber in fhem.pl derzeit ein Leerzeichen hinter altitude. Betateilchen hat ihn darauf aber schon hingewiesen. Daher wird er das sicher noch zeitnah fixen.
Gruß
Dirk
Hallo,
so, das nun hoffentlich vorläufig letzte Update:
Die Werte werden nun auch gleich nach dem Start von FHEM bzw. nach dem Define geholt und nicht erst nach dem Ablaufen des ersten Poll-Intervall. Ein paar kleiner Bugs hab ich auch noch gefixt. Und die Doku vervollständigt.
So kommt die Version heute abend auch ins SVN wenn es keine Einwände gibt.
Gruß
Dirk
Edit: altes Modul entfernt.
Das Modul ist mittlerweile Bestandteil von FHEM (51_I2C_BMP180.pm)
Hallo Dirk,
ich habe noch ein paar (Verständnis)-Fragen:
- Ersetzt der Eintrag in .../udev/... das manuelle chown des Ports?
- Warum zwei Zeilen im Startskript? Oder ist das ... auch eine Zeile (mit welcher Bedeutung)?
- Wie verhält sich das Ändern des Startskriptes bezüglich Updates? Oder werden da nur die Perl Module aktualisiert und Perl selber und die Startroutinen bleiben?
Und vermutlich die dümmste Frage von allen:
- Wie kann ich den HTML (?) Code am Anfang und am Ende des Moduls lesen (nur reinladen in Browser geht nicht)?
Danke + Gruß
PeMue
Zitat- Ersetzt der Eintrag in .../udev/... das manuelle chown des Ports?
Genau
- Warum zwei Zeilen im Startskript? Oder ist das ... auch eine Zeile (mit welcher Bedeutung)?Es ist nur eine Zeile:
sudo hipi-i2c e 0 1Die anderen Zeilen sollten nur die Insertposition veranschaulichen.
Zitat- Wie verhält sich das Ändern des Startskriptes bezüglich Updates? Oder werden da nur die Perl Module aktualisiert und Perl selber und die Startroutinen bleiben?
Das ist eine gute Frage. Das werde ich nochmal testen.
Zitat- Wie kann ich den HTML (?) Code am Anfang und am Ende des Moduls lesen (nur reinladen in Browser geht nicht)?
aus dem FHEM-Verzeichniss einmal
./contrib/commandref_join.plaufrufen. Damit wird die lokale commandref.html aktualisiert. Und damit findest du den Code vom I2C_BMP180 Modul dann auch dort.
Gruß
Dirk
Hallo Dirk,
ich warte, bis das Modul im SVN steht (bzw. dort die commandref.html aktualisiert wird), weil bei mir folgende Fehlermeldung kommt (aus der Konsole in fhem):
Unknown command ./contrib/commandref_join.pl, try help
Was mich gerade noch irritiert:
BMP180 ReadValues gibt
STATE: Temp: 36.0 °C , Pressure: 987.6 hPa in 240 m, Pressure-NN: 1015.8 hPa
Im Logfile kommt
2013-07-26_17:50:04 BMP180 temperature: 36.0
2013-07-26_17:50:04 BMP180 pressure: 987.6 (Groß-/kleinschreibung).
Damit die Logdateien nicht zu groß werden, würde ich sowieso die Variablen als p, pNN bzw. T definieren, aber das ist meine private Meinung ...
Gruß PeMue
Edit:
Sieht doch hübsch aus, oder?
(siehe Anhang / see attachement)
Jetzt weiß ich auch warum meine bessere Hälfte Kopfschmerzen hat ...
Zitat von: Dirk schrieb am Fr, 26 Juli 2013 17:22contrib/commandref_join.plaufrufen. Damit wird die lokale commandref.html aktualisiert. Und damit findest du den Code vom I2C_BMP180 Modul dann auch dort.
Hallo Dirk, das funktioniert beim "normalen" User nicht, weil das perl-Skript in fertigen Installationspaketen nicht enthalten ist, sondern nur nach einem kompletten SVN auschecken.
Die commandref wird beim täglichen Update automatisch aktualisiert, sobald Dein Modul im SVN eingecheckt ist, der Anwender muss sich damit nicht auseinandersetzen.
Gleiches Verhalten beim Startskript: das wird bei einem "update" aus fhem heraus nicht angetastet.
Zitat von: PeMue schrieb am Fr, 26 Juli 2013 17:55Was mich gerade noch irritiert:
BMP180 ReadValues gibt
STATE: Temp: 36.0 °C , Pressure: 987.6 hPa in 240 m, Pressure-NN: 1015.8 hPa
Im Logfile kommt
2013-07-26_17:50:04 BMP180 temperature: 36.0
2013-07-26_17:50:04 BMP180 pressure: 987.6 (Groß-/kleinschreibung).
Also im State steht das ganze "Menschen lesbar". Den State kann man ja auch per stateFormat selber definieren.
ZitatDamit die Logdateien nicht zu groß werden, würde ich sowieso die Variablen als p, pNN bzw. T definieren, aber das ist meine private Meinung ...
Hm, vielleicht noch ein Attribut damit das jeder selber entscheiden kann?
Zitat von: betateilchen schrieb am Fr, 26 Juli 2013 19:09Zitat von: Dirk schrieb am Fr, 26 Juli 2013 17:22contrib/commandref_join.plaufrufen. Damit wird die lokale commandref.html aktualisiert. Und damit findest du den Code vom I2C_BMP180 Modul dann auch dort.
... das funktioniert beim "normalen" User nicht, weil das perl-Skript in fertigen Installationspaketen nicht enthalten ist, sondern nur nach einem kompletten SVN auschecken.
Mist, jetzt weiss jeder das ich nur SVN benutze :)
Ok. Wieder was gelernt.
ZitatGleiches Verhalten beim Startskript: das wird bei einem "update" aus fhem heraus nicht angetastet.
Also beantwortet das auch die Frage von PeMue
Zitat- Wie verhält sich das Ändern des Startskriptes bezüglich Updates?
eigene Änderungen am Startscript gehen bei einem Update
nicht verloren?
Gruß
Dirk
Zitat von: Dirk schrieb am Fr, 26 Juli 2013 19:42eigene Änderungen am Startscript gehen bei einem Update nicht verloren?
solange Du kein Paketupdate auf Distributionsupdate machst, nicht.
Hallo zusammen,
ich habe folgendes gemacht:
- udev Regel angelegt (eine Zeile, gleiche Rechte wie die anderen Regeln)
(siehe Anhang / see attachement)
- die Treiber reingeschrieben
- das Startskript geändert
Der I2C Bus hat folgende Rechte:
crw-rw---T 1 i2c 89, 0 Jul 26 20:09 i2c-0
crw-rw---T 1 i2c 89, 1 Jul 26 20:09 i2c-1
Wenn ich fhem starte kommt trotzdem
RPi$ sudo /etc/init.d/fhem start
Enabling I2C on P5
1
Starting fhem...
open error on /dev/i2c-0: Keine Berechtigung at ./FHEM/51_I2C_BMP180.pm line 119
sudo i2cdetect -y 0findet den BMP180.
Habt ihr Ideen, an was es hängen könnte?
Nach
sudo chown fhem.root /dev/i2c-0
fährt fhem anstandslos hoch.
@Dirk:
Wenn Du in der Moduldokumentation schon zwei Zeilen erwähnst, dann würde ich folgende nehmen:
'start')
echo "Enabling I2C on P5 ..."
sudo hipi-i2c e 0 1
Gruß PeMue
Zitatcrw-rw---T 1 i2c 89, 0 Jul 26 20:09 i2c-0
Das sieht mir irgendwie danach aus, dass die UDEV-Regel nicht greift.
Das sollte so aussehen:
crw-rw-rwT 1 root i2c 89, 0 Jul 26 19:12 /dev/i2c-0
crw-rw-rwT 1 root i2c 89, 1 Jul 26 19:12 /dev/i2c-1Läuft bei dir vielleicht kein udev?
Was sagt denn
/etc/init.d/udev statusAnsonsten kannst du auch die Zeile
Zitatsudo chown fhem.root /dev/i2c-0
auch mit in das Startscript packen.
Gruß
Dirk
Hallo Dirk,
$ /etc/init.d/udev status
[ ok ] udevd is running.udev scheint zu laufen. Jetzt schaue ich noch einmal nach Tippfehlern ...
Oder ich gehe in den Keller und hole mir ein Bier (//www.wehavemorefun.de/fritzbox/Bier_holen).
Gruß PeMue
Edit:
Was hat es eigentlich mit der
/etc/modprobe.d/raspi-blacklist.conf und dem Auskommentieren von
blacklist i2c-bcm2708 auf sich? Brauche ich das?
ZitatOder ich gehe in den Keller und hole mir ein Bier (//www.wehavemorefun.de/fritzbox/Bier_holen).
Cool, den kannte ich noch gar nicht.
ZitatWas hat es eigentlich mit der
/etc/modprobe.d/raspi-blacklist.conf und dem Auskommentieren von
blacklist i2c-bcm2708 auf sich? Brauche ich das?
Das hab ich so gelassen wie es war.
Hallo,
das Modul ist übrigens seit gestern abend im SVN und somit auch per Update verfügbar.
Zitat von: PeMue schrieb am Fr, 26 Juli 2013 17:55Damit die Logdateien nicht zu groß werden, würde ich sowieso die Variablen als p, pNN bzw. T
Ich werde mir das nochmal ansehen. Ich hab da noch ne Idee. Dann wird sich das Logformat nochmal ändern.
Gruß
Dirk
Hallo PeMue,
ich habe die Events noch mal geändert:
Es wird zusätzlich noch der state als Event generiert:2013-07-27 15:34:57 I2C_BMP180 BMP180 T: 47.7 P: 985.6 P-NN: 1011.5
Somit kann man jetzt auch nur diese Zeile wegloggen:define log_BMP180 FileLog /opt/fhem/logs/bmp180.log BMP180:(T|P):.*
Damit man jetzt einen "schönen" lesbaren STATE bekommt muss man diesen nur per stateFormat setzen:attr BMP180 stateFormat Temperatur: temperatur, Luftdruck (altitude m ü.NN): pressure hPa, Luftdruck reduziert (NN): pressure-nn hPa
wenn keine Einwände mehr kommen, würde ich das heute abend wieder ins SVN packen.
Gruß
Dirk
Edit: altes Modul entfernt.
Das Modul ist mittlerweile Bestandteil von FHEM (51_I2C_BMP180.pm)
Hi,
sagt mal kann mir einer sagen wo ich hier was falsch mache, ich bekomme den Luftdruck nicht gezeichnet.
Gruß
Daniel
Hi Daniel,
bei mir sieht es so aus:
(siehe Anhang / see attachement)
Die Ranges kannst du auch leer lassen.
Gruß
Dirk
Ahh danke, misst jetzt hab ich mein Fehler gefunden, da stand ja noch ne 3 bei mir oO
Danke!
Hallo Dirk,
da solltest Du vielleicht nochmal nachschauen:
Prototype mismatch: sub main::finally (&;@) vs (&) at ./FHEM/51_I2C_BMP180.pm line 39
Prototype mismatch: sub main::try (&;@) vs (&;$) at ./FHEM/51_I2C_BMP180.pm line 39
Viele Grüße
Udo
Hi Udo,
liegt das vielleicht an deiner Perl Version?
Welche Version hast du?
Bei welcher Aktion bekommst du den Fehler?
Gruß
Dirk
Hallo Dirk,
perl Version = 5.14.2
Die Meldung kommt immer dann, wenn Dein Modul geladen wird (also beim Start von fhem oder bei einem reload)
Ich hatte ähnliche Probleme mit meinem 98_openweathermap. Hast Du schonmal probiert, mit Try::Tiny anstatt mit Error zu arbeiten?
Viele Grüße
Udo
HI Udo,
ich habs mal auf Try::Tiny umgebaut.
Trotzdem komisch das der Fehler scheinbar nur bei dir kam.
Kannst du das bei dir nochmal testen.
Hier läuft es auch mit dieser Version.
Gruß
Dirk
Edit: altes Modul entfernt.
Das Modul ist mittlerweile Bestandteil von FHEM (51_I2C_BMP180.pm)
Ich hab hier den gleichen Fehler in meinem Modul und bin auch schon seit Stunden auf der Suche nach der Ursache.
Die Meldung bewirkt nicht irgendwelche Probleme, sie sieht halt nur unschön aus.
Bei mir hängt es definitiv mit dem try/catch/finally zusammen, das ich im Coding verwende. Werde mir Deine Version mal anschauen.
Ich habe in meinem Modul das Thema jetzt dadurch gelöst, dass ich überhaupt nicht mehr mit try/catch arbeite, sondern mit eval {}.
Hallo zusammen,
ich verstehe noch immer nicht, warum meine udev Regel nicht funktioniert.
Das
SUBSYSTEM=="i2c-dev" definiert doch, mit welchem Gerät etwas zu tun ist und MODE="0666"gibt doch rw Zugriff für owner, group und world. Oder könnte ich auch OWNER="fhem" bzw. GROUP="root" arbeiten? Dann könnte ich aber gleich das chown ... von oben verwenden ...
Oder wäre der Parameter NAME=i2c-0 (//wiki.ubuntuusers.de/udev) besser geeignet?
Muss ich mal nach und nach probieren. Allerdings wartet das Display immer noch auf die Inbetriebnahme, es funktioniert noch weniger mit dem kurzen Verbinder ...
Gruß PeMue
die korrekte Zeile für die rules Datei besteht nur aus den zwei Teilen
SUBSYSTEM=="i2c-dev", MODE="0666"
Bitte in udev keine Experimente machen, wenn Du nicht genau weißt/verstehst, was Du da tust!
Wichtig ist:
1.) die Datei an der richtigen Stelle anlegen! Die muss in das Verzeichnis /etc/udev/rules.d
2.) den owner auf root:root setzen
3.) am Ende der Zeile den Zeilenumbruch nicht vergessen
ok, das Ding heißt
-rw-r--r-- 1 root 34 Jul 30 21:45 98-i2c.rules
und der Inhalt ist
SUBSYSTEM=="i2-dev", MODE="0666"
(Zeilenumbruch hat gefehlt, Regelname war mit Unterstrich).
Aber es tut leider immer noch nicht.
Ich lasse jetzt das chmown im fhem Startskript, aus basta!
Die udev Regel habe ich in /opt/fhem/backup verschoben für alle Fälle ...
Gruß PeMue
Ob Unterstrich oder Bindestrich im Regelname ist egal, die kann auch Friedrich heissen...
so sieht das bei mir aus: -rw-r--r-- 1 root root 34 Jul 23 18:08 98_i2c.rules
Hast Du den udev Dämon nach der Änderung auhc wirklich neu gestartet?
/etc/init.d/udev restart
Alternativ: den raspi neustarten
Also die Leerzeile am Ende der Datei ist zumindest bei mir unrelevant, da nicht vorhanden und trotzdem funktioniert die Regel bei mir.
Kannst du mal im Syslog schauen ob es da irgendwelche Hinweise dazu gibt.
ZitatAllerdings wartet das Display immer noch auf die Inbetriebnahme, es funktioniert noch weniger mit dem kurzen Verbinder ...
Was bedeuted das? Was für ein Fehlerbild?
Gruß
Dirk
Zitat von: Dirk schrieb am Di, 30 Juli 2013 22:11Also die Leerzeile am Ende der Datei ist zumindest bei mir unrelevant,
das KANN schon sein, aber ich würde bei Konfigurationsdateien unter Linux diesbezüglich nie die Hand ins Feuer legen.
Hallo zusammen,
so, nun habe ich das neue Modul mal installiert. Die Plot Definition bekomme ich auch umdefiniert. Meinetwegen auch mit sed temperatur durch T usw. ersetzt. Aber wie bekomme ich bitte die zwei Zeilen per shell script in eine Zeile rein?
alt:
2013-08-09_20:10:24 BMP180 temperature: 33.2
2013-08-09_20:10:24 BMP180 pressure: 994.9
neu:
2013-08-09_20:19:48 BMP180 T: 33.2 P: 994.9 P-NN: 1023.1Geht das überhaupt? Und ja, im oberen fehlt der Luftdruck NN (da war einfach altitude noch nicht definiert). Für Vorschläge bin ich dankbar ...
Edit2:
google (//spielwiese.la-evento.com/xelasblog/archives/1-sed-fuegt-Zeilen-zusammen.html) ist mein Freund:
cat rpi* | sed 'N;s/\n/ /g' | sed 's/pressure/P/g' | sed 's/temperature/T/g'Allerdings muss ich in der zweiten Zeile noch das Datum und BMP180 wegbringen ...
Korrekterweise sollte aber das stateformat Attribut so
attr BMP180 stateFormat Temperatur: temperature °C, Luftdruck (altitude m ü. NN): pressure hPa, Luftdruck (NN): pressure-nn hPaheißen ...
Allerdings geht das Ersetzen von ° durch ° nicht, ist das bei html nicht notwendig?
Edit1:
Folgende Fehlermeldung kommt auf der Konsole:
Character in 'C' format wrapped in pack at /usr/local/lib/perl/5.14.2/HiPi/Device/I2C.pm line 270.
Und die bisher coolste (Fehlermeldung auf der Konsole):
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for fhem:Könnte das mit den für I2C notwendigen root Rechten zusammenhängen?
Gruß PeMue
ZitatUnd die bisher coolste (Fehlermeldung auf der Konsole):
Die habe ich auch noch nicht gesehen. Bei welcher Aktion kommt die?
so
cat rpi* | sed 's/.*pressure/P/g' | sed 'N;s/\n/ /g' | sed 's/temperature/T/g' > /tmp/rpi* geht es.
Erklärung:
das erste sed: sucht in einer Zeile alle Zeichen vor pressure (.*) und ersetzt dieses durch P, alles was danach kommt, bleibt
das zweite sed: nimmt zwei Zeilen, sucht nach dem Zeilenende und ersetzt das durch ein Leerzeichen
das dritte sed: sucht wiederum in einer Zeile temperature durch T
Gruß PeMue
Zitat von: Dirk schrieb am Fr, 09 August 2013 22:20ZitatUnd die bisher coolste (Fehlermeldung auf der Konsole):
Die habe ich auch noch nicht gesehen. Bei welcher Aktion kommt die?
Das ist eine ganz normale Standardmeldung aus sudo, wenn sudo nicht korrekt konfiguriert ist oder der aktuelle Benutzer keine sudo Rechte hat.
https://wiki.debian.org/sudo---
Zitat... oder der aktuelle Benutzer keine sudo Rechte hat.
Das würde aber dann doch heißen
- der user fhem braucht für eine Funktion sudo Rechte und
- er hat diese nicht.
Korrekt?
Gruß PeMue
ich hab doch keine Ahnung, was Du da tun willst
... und ich möchte doch nur wissen, warum bei mir diese Fehlermeldung kommt.
Moin
Brauche eure Hilfe.
Ich bekomme den BMP180(085) nicht richtig zum laufen.
Habe alles nach dieser Anleitung (Raspberry+Pi+Mini-Luftdrucksensor+BMP180+%2842%29) gemacht.
(siehe Anhang / see attachement)
Beim ersten suchen bekomme ich keine Adresse.
Scheinbar bekomme ich von P5 keine Antwort.
Und wenn ich das in Fhem eintrage :
define BMP180 I2C_BMP180 /dev/i2c-0
attr BMP180 oversampling_settings 1
attr BMP180 poll_interval 5
attr BMP180 route_i2c0_to_p5 1
stürtzt Fhem ab.
Habe schon alles versucht was hier im Forum auf taucht.
Bitte um Hilfe
Hallo Michael,
deine Ausgabe von i2cdetect -y 0 sieht eigntentlich gut aus.
Auf Adresse 0x77 wird der Sensor gefunden.
Kannst du mal in den Log schauen warum FHEM abstürzt. Und den entsprechenden Teil hier posten.
Gruß
Dirk
Hallo Dirk
Im Logfile finde ich nur eine Meldung ( DS: CUL ) die ich nicht kenne.
Alle anderen Meldung sind mir bekannt und auch keine Fehler.
Ach so, das ist die Fhem Version:
(version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3660 2013-08-10 08:51:31Z rudolfkoenig $, pid 1965)
PS. Wenn ich das (define BMP180 I2C_BMP180 /dev/i2c-0) alleine in die Fhem.cfg eintrage
und save Drücke bekomme ich die Meldung das die Webseite nicht reichbar ist.
Hallo Michael,
das liegt vermutlich an den fehlenden root Rechten auf dem I2C Bus. Bei mir funtioniert aus mir noch nicht bekannten Gründen die udev Regel nicht.
Pack mal folgendes in /etc/init.d/fhem (Zeile 2 bis 4) rein
case "$1" in
'start')
echo "Enabling I2C on P5 ..."
sudo hipi-i2c e 0 1
sudo chown fhem:root /dev/i2c-0
echo "Starting fhem..."
perl fhem.pl fhem.cfg
RETVAL=$?
;;
Viel Erfolg
Gruß PeMue
Hallo PeMue
Danke[/color]
Das war 's.
Zitat von: betateilchen schrieb am Di, 30 Juli 2013 21:42die korrekte Zeile für die rules Datei besteht nur aus den zwei Teilen
SUBSYSTEM=="i2c-dev", MODE="0666"
Bitte in udev keine Experimente machen, wenn Du nicht genau weißt/verstehst, was Du da tust!
Wichtig ist:
1.) die Datei an der richtigen Stelle anlegen! Die muss in das Verzeichnis /etc/udev/rules.d
2.) den owner auf root:root setzen
3.) am Ende der Zeile den Zeilenumbruch nicht vergessen
Ich habe gerade mal wieder die Spur aufgenommen....
Also ich habe diese udev-Regeln für meinen BMP180 überhaupt nicht angelegt. Bei Raspian wird mit der Installation der I2C-Tools (per apt-get) eine udev-Regel automatisch angelegt:
-rw-r--r-- 1 root root 47 Jul 26 2012 /lib/udev/rules.d/60-i2c-tools.rules mit folgendem Inhalt:
KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"Ich habe nur die User "pi" und natürlich "fhem" in die Groupe "i2c" aufgenommen:
sudo adduser pi i2cUm sicher zu gehen, dass die Gruppenzugehörigkeit greift, sollte mal zwischendurch gebootet werden (oder zumindest ab- und anmelden).
Nochwas: für die Zukunft wäre es evtl. sinnvoll die Board-Revision und die Distribution mit in die Signatur aufzunehmen.
Cheers
Helmut A.
Zitat von: C64Emulator schrieb am Mi, 14 August 2013 00:22Ich habe gerade mal wieder die Spur aufgenommen....
Also ich habe diese udev-Regeln für meinen BMP180 überhaupt nicht angelegt. Bei Raspian wird mit der Installation der I2C-Tools (per apt-get) eine udev-Regel automatisch angelegt:
Stimmt. Aber das ist offenbar abhängig von der raspbian Version. Meine "alte" Version, die ich regelmäßig per upgrade gepflegt hatte, hat diese udev-Regel nicht angelegt.
Als ich diese Woche ein fhem-System auf einem raspberry für den Export nach Serbien
neu aufgesetzt habe, ist mir das mit der vorhandenen Regel auch aufgefallen.
Und inzwischen funktioniert auch das Auflöten des BMP180 Platinchens im Schlaf :)
-----
Hallo Udo,
ZitatAber das ist offenbar abhängig von der raspbian Version.
Wie bekomme ich diese heraus?
uname -aUnd was ist der Unterschied zwischen Deinen beiden Versionen?
Das wäre ein Feature für die RPi_utils.pm ...
Gruß PeMue
Keine Ahnung wo die Unterschiede liegen. Der Unterschied bei mir ist einfach der, dass der eine Raspi (bei dem die Regel fehlte) letztes Jahr bereits installiert und dann regelmäßig mit apt-get upgrade aktualisiert wurde und der zweite Raspi mit einem frischen, aktuellen raspbian neu aufgesetzt wurde.
Ich denke, dass beim ersten Gerät einfach irgendein postprocess-Skript nach einem Update nicht richtig funktioniert hat.
uname -a liefert bei beiden Geräten die selbe Antwort, damit bekommst Du die Information über die raspbian(-Image) Version nicht raus:
Linux rasp-nas 3.6.11+ #474 PREEMPT Thu Jun 13 17:14:42 BST 2013 armv6l GNU/Linux
Linux fhem-rs 3.6.11+ #474 PREEMPT Thu Jun 13 17:14:42 BST 2013 armv6l GNU/Linux
-----
Zitat von: betateilchen schrieb am Sa, 17 August 2013 21:52Keine Ahnung wo die Unterschiede liegen. Der Unterschied bei mir ist einfach der, dass der eine Raspi (bei dem die Regel fehlte) letztes Jahr bereits installiert und dann regelmäßig mit apt-get upgrade aktualisiert wurde
Ab und zu ist auch ein Firmware-Update mit
rpi-updatesinnvoll.
ZitatIch denke, dass beim ersten Gerät einfach irgendein postprocess-Skript nach einem Update nicht richtig funktioniert hat.
Dann hätte es eine
Fehlermeldung gegeben, oder?
Zitatuname -a liefert bei beiden Geräten die selbe Antwort, damit bekommst Du die Information über die raspbian(-Image) Version nicht raus:
Linux rasp-nas 3.6.11+ #474 PREEMPT Thu Jun 13 17:14:42 BST 2013 armv6l GNU/Linux
Linux fhem-rs 3.6.11+ #474 PREEMPT Thu Jun 13 17:14:42 BST 2013 armv6l GNU/Linux
Damit kannst Du höchstens die Kernel-Version erfahren. Es gibt im etc-Verzeichnis der meisten Distributionen eine Text-Datei, die die Version beinhaltet. Was sagt denn
l /etc/*release*und ein
l /etc/*version*Hast Du die Package-Versionen der i2c-tools mal verglichen? Was sagt denn
sudo apt-cache show i2c-toolsIch habe die Version 3.1.0-2, das ist die aktuellste.
Hoffe, geholfen zu haben.
Helmut
Zitat von: C64Emulator schrieb am Mo, 19 August 2013 19:21Hoffe, geholfen zu haben.
Nein, hast Du nicht. Weil ich gar nix gefragt hatte, wobei Du hättest helfen können.
@Udo: *grins*
Bei mir ist haben die i2c Tools die Version
Package: i2c-tools
Version: 3.1.0-2
also aktuell. Aber dann werde ich das Paket nochmal installieren und schauen, was für eine Fehlermeldung kommt (ich meinte aber, es wäre das letzte Mal sauber durchgelaufen).
@Helmut: Deine Info hat mir auf jeden Fall mal gezeigt, wo ich suchen könnte (obwohl ich nicht gefragt habe :-)).
Gruß PeMue
Jetzt hab ich die Installation des Sensors schon dreimal völlig problemlos umgesetzt. Und jetzt beim vierten Versuch klappt das Umschalten des I2C ums Verrecken nicht. Der Sensor wird immer nur auf Bus 1 gefunden. Es ist zum Ko...
Hi betateilchen,
jetzt geht es Dir wie bei uns beim ersten Mal. Aber sei froh über die ersten drei positiven Erfahrungen. Bei mir tut die udev Regel übrigens immer noch nicht (ich habe auch nicht mehr weiter geschaut), aber das kommt dann im Winter ...
Gruß PeMue
Bei mir läuft es jetzt auch beim vierten Mal einwandfrei.
Ich weiß inzwischen auch, wo das Problem (reproduzierbar) herkam/-kommt, aber das lässt sich nicht in einem einzelnen Satz erklären. Vereinfacht gesagt, kommt es auf die exakte Reihenfolge bei der Installation aller Softwarekomponenten und deren Updates an - beginnend beim Betriebssystem. Wenn man da nicht aufpaßt, überschreiben sich im Laufe der Installation einfach bestimmte Komponenten, vor allem, wenn man mit einem vorbereiteten Image arbeitet und nicht "from scratch" beginnt.
Hallo betateilchen,
gilt die Aussage auch für das Raspbian Image? Ich habe das vom Februar glaube ich genommen und dann alles sukzessive installiert (vcontrold, fhem und alles was danach kam, allerdings habe ich auf die Reihenfolge nicht geachtet, ich könnte sie aber rekonstruieren).
Gruß PeMue
Gehen wir der Einfachheit halber von folgenden Dingen aus:
1. wir verwenden das Image von busware (mein Lieblingsimage, weil die Ansteuerung des COC da schon mit drinsteckt und weil es ein hervorragendes Startskript für fhem mitbringt)
2. wir haben einen Raspberry mit aufgelötetem Drucksensor
3. wir haben eine leere SD-Karte mit 4GB Kapazität
Hier kommt eine Schritt-für-Schritt-Anleitung zum erfolgreichen Aufsetzen eines kompletten Systems, vom Betriebssystem bis zur Definition des Sensors in fhem. DIese Anleitung wurde von mir eben "in echt" so erarbeitet und dokumentiert. Sie funktioniert. (Bitte auch die Hinweise am Ende des Beitrags beachten)
Schritt 1: SD Karte erzeugen
dd bs=1m if=2013-02-09-wheezy-raspbian-fhem.img of=/dev/<NameDerSdKarte>
Schritt 2: SD Karte in Raspberry booten
Schritt 3: per SSH auf Raspberry verbinden und raspi-config ausführen,
vor allem wichtig: expand_rootfs, change_locale, change_timezone
danach reboot
Die folgenden beiden Schritte gelten nur für vorgefertigte Images, z.B. das von busware.de:
Schritt 4: /opt/fhem entfernen
sudo rm -rf /opt/fhem
Schritt 5: Raspberry aktualisieren
sudo apt-get update
sudo apt-get upgrade
(Bitte auf keinen Fall ein apt-get dist-upgrade machen!)
sudo reboot
Schritt 6: midnight-commander installieren
(erleichtert das editieren von Konfigurationsdateien und kopieren von Dateien und Verzeichnissen)
sudo apt-get install mc
Schritt 7: i2c-tools installieren
sudo apt-get install i2c-tools
Schritt 8: Datei /etc/modules editieren, folgende Zeilen einfügen:
i2c-bcm2708
i2c-dev
Schritt 9: hipi tools installieren (ohne grafische tools!)
cd /opt
sudo wget http://raspberry.znix.com/hipifiles/hipi-install
sudo perl hipi-install --hipi-wx=0
(jetzt ist genug Zeit, sich einen Kaffee zu holen, denn das Installieren dauert...)
(die Warnungen wegen fehlendem autoconf und automake können ignoriert werden)
Schritt 10: die erzeugten Module an die richtige Stelle kopieren
Den kompletten Inhalt von /usr/local/lib/perl nach /usr/lib/perl kopieren
(hier empfiehlt sich wieder der oben installierte midnight-commander mc)
Schritt 11: Verzeichnis /var/log/fhem anlegen und mit Rechten versehen
sudo mkdir /var/log/fhem
sudo chown -R fhem:root /var/log/fhem
Schritt 12: Datei /etc/rc.local editieren
Vor die Zeile "exit 0" einfügen:
/usr/local/bin/hipi-i2c e 0 1
Schritt 13: Datei /etc/udev/rules.d/98_i2c.rules anlegen und folgende Zeile eintragen:
SUBSYSTEM=="i2c-dev", MODE="0666"
Schritt 14: sudo reboot
Schritt 15: nach dem Reboot testen, ob der Senosr korrekt gefunden wird:
(Test bitte OHNE root ausführen, um zu sehen, ob auch die udev Regel greift!)
i2cdetect -y 0
Die letzte Zeile der Ausgabe muss so aussehen:
70: -- -- -- -- -- -- -- 77
Wenn die bisherigen Schritte erfolgreich waren: HERZLICHEN GLÜCKWUNSCH, das Schwierigeste ist geschafft, weiter zu Schritt 16.
Wenn nicht: Schade. Rücke vor auf Los, ziehe keine 4000 Mark ein...
Schritt 16: fhem nach /opt installieren:
cd /opt
sudo wget http://fhem.de/fhem-5.4.tar.gz
sudo tar xvf fhem-5.4.tar.gz
sudo chown -R fhem:root fhem-5.4
sudo ln -s fhem-5.4 fhem
sudo rm fhem-5.4.tar.gz
Schritt 17: fhem starten (eine der genannten Varianten auswählen)
17a: sudo reboot (wer wie hier im Beisipiel das Image von busware verwendet hat, dort ist ein Startscript enthalten)
17b: wer from scratch arbeitet, sollte sich ein Startskript anlegen
17c: manuell starten
Schritt 18: fhem updaten (auf die Statistik- und Bestätigungsorgie im Frontend gehe ich nicht weiter ein, die ist selbsterklärend)
Schritt 19: Sensor in fhem definieren
define test I2C_BMP180 /dev/i2c-0
et voila:
Internals:
CFGFN
DEF /dev/i2c-0
NAME test
NR 36
STATE T: 30.9 P: 1007.9 P-NN: 1007.9
TYPE I2C_BMP180
Readings:
2013-09-20 10:51:39 altitude 0
2013-09-20 10:51:39 pressure 1007.9
2013-09-20 10:51:39 pressure-nn 1007.9
2013-09-20 10:51:39 state T: 30.9 P: 1007.9 P-NN: 1007.9
2013-09-20 10:51:39 temperature 30.9
Calibrationdata:
ac1 6362
ac2 -1031
ac3 -14717
ac4 32753
ac5 24853
ac6 17550
b1 6515
b2 34
b5 4932.04565739624
mb -32768
mc -11786
md 2909
Attributes:
oversampling_settings 3
poll_interval 5
Die Vorgehensweise ist grundsätzlich auch für eine Installation ohne vorgefertigtes Image gültig. Entsprechende Abweichungen wurden in der Anleitung aufgeführt. Bei Punkt 17 muss man dann nach eigenem Gusto handeln, was das Startskript betrifft. Das habe ich bewusst nicht beschrieben, weil es da einfach zu viele Möglichkeiten gibt.
Da schon Nachfragen kamen:
1. Die SD Karte darf natürlich auch größer als 4GB sein. Kleiner würde ich aber nicht verwenden, sonst wirds zwischendurch ganz schön eng bei der Installation
2. Alle zusätzlichen Komponenten sollten NACH den beschriebenen Schritten installiert werden (z.B. hmland o.ä.)
3. Wenn ich Zeit finde, mache ich vielleicht auch noch eine Installationsanleitung "from scratch" also ausgehend von einem nackten raspbian Image.
Zitat von: betateilchen schrieb am Fr, 20 September 2013 11:483. Wenn ich Zeit finde, mache ich vielleicht auch noch eine Installationsanleitung "from scratch" also ausgehend von einem nackten raspbian Image.
Was Du heute kannst besorgen...
Schritt 1: aktuelles raspbian Image von www.raspberrypi.org laden
Schritt 2: SD Karte erzeugen
dd bs=1m if=2013-09-10-wheezy-raspbian.img of=/dev/<NameDerSdKarte>
Schritt 3: SD Karte in Raspberry booten
Schritt 4: per SSH auf Raspberry verbinden und raspi-config ausführen,
vor allem wichtig: expand_rootfs, change_locale, change_timezone
danach reboot
Schritt 5: Raspberry aktualisieren
sudo apt-get update
sudo apt-get upgrade
sudo reboot
(reboot ist nur notwendig, wenn bei upgrade Pakete aktualisiert wurden)
Schritt 6: midnight-commander installieren
(erleichtert das editieren von Konfigurationsdateien und kopieren von Dateien und Verzeichnissen)
sudo apt-get install mc
Schritt 7: i2c-tools installieren
sudo apt-get install i2c-tools
Schritt 8: Datei /etc/modules editieren, folgende Zeilen einfügen:
i2c-bcm2708
i2c-dev
Schritt 9: zusätzliche Perl-Pakete installieren:
sudo apt-get install libwww-perl
Schritt 10: hipi tools installieren (ohne grafische tools!)
cd /opt
sudo wget http://raspberry.znix.com/hipifiles/hipi-install
sudo perl hipi-install --hipi-wx=0
(jetzt ist genug Zeit, sich einen Kaffee zu holen, denn das Installieren dauert...)
(die Warnungen wegen fehlendem autoconf und automake können ignoriert werden)
Schritt 11: Datei /etc/rc.local editieren
Vor die Zeile "exit 0" einfügen:
/usr/local/bin/hipi-i2c e 0 1
cd /opt/fhem
perl fhem.pl fhem.cfg &
Schritt 12: Datei /etc/udev/rules.d/98_i2c.rules anlegen und folgende Zeile eintragen:
SUBSYSTEM=="i2c-dev", MODE="0666"
Schritt 13: sudo reboot
Schritt 14: nach dem Reboot testen, ob der Senosr korrekt gefunden wird:
(Test bitte OHNE root ausführen, um zu sehen, ob auch die udev Regel greift!)
i2cdetect -y 0
Die letzte Zeile der Ausgabe muss so aussehen:
70: -- -- -- -- -- -- -- 77
Wenn die bisherigen Schritte erfolgreich waren: HERZLICHEN GLÜCKWUNSCH, das Schwierigeste ist geschafft, weiter zu Schritt 15.
Wenn nicht: Schade. Rücke vor auf Los, ziehe keine 4000 Mark ein...
Schritt 15: fhem nach /opt installieren:
cd /opt
sudo wget http://fhem.de/fhem-5.4.tar.gz
sudo tar xvf fhem-5.4.tar.gz
sudo ln -s fhem-5.4 fhem
sudo rm fhem-5.4.tar.gz
Schritt 16: sudo reboot
(nach dem reboot sollte fhem korrekt laufen)
Schritt 17: fhem updaten (auf die Statistik- und Bestätigungsorgie im Frontend gehe ich nicht weiter ein, die ist selbsterklärend)
Schritt 18: Sensor in fhem definieren
define test I2C_BMP180 /dev/i2c-0
Und wer es noch bequemer haben will:
1. SD Karte mit nacktem raspbian installieren und raspi-config ausführen
2. das angehängte Skript auf den laufenden Raspi kopieren, mit "sudo su" root werden und das Skript starten
3. nach dem automatischen reboot sind alle notwendigen Treiber installiert, alle Konfigurationsdateien bearbeitet und fhem läuft
Dann muss nur noch das fhem-update manuell ausgeführt werden, danach kann der Luftdrucksensor definiert werden.
(In der Auslieferungsversion von fhem ist das BMP180 Modul noch nicht enthalten!)
rm /etc/rc.local
cd /opt
apt-get -y install i2c-tools libwww-perl
wget http://raspberry.znix.com/hipifiles/hipi-install
perl hipi-install --hipi-wx=0
rm hipi-install
echo i2c-bcm2708 >> /etc/modules
echo i2c-dev >> /etc/modules
echo /usr/local/bin/hipi-i2c e 0 1 >> /etc/rc.local
echo 'SUBSYSTEM=="i2c-dev", MODE="0666"' > /etc/udev/rules.d/98_i2c.rules
apt-get -y upgrade
wget http://fhem.de/fhem-5.4.tar.gz
tar xvf fhem-5.4.tar.gz
ln -s fhem-5.4 fhem
rm fhem-5.4.tar.gz
echo cd /opt/fhem >> /etc/rc.local
echo "perl fhem.pl fhem.cfg &" >> /etc/rc.local
echo exit 0 >> /etc/rc.local
chmod a+x /etc/rc.local
reboot
Hallo betateilchen,
cool. Vielen dank für das script.
Ich werde die nächsten Tage auch mal das IMAGE Image für die CSM/LCD-Platine (http://forum.fhem.de/index.php?topic=12854.0) aktualisieren. Dann nehme ich die entsprechenden Treiber mit auf.
Gruß
Dirk
Hallo Dirk,
kannst Du mir mal bitte per email die "relevanten" Daten zu dem LCD Modul schicken?
Viele Grüße
Udo
Hallo betateilchen,
ich habe fhem mit dem Debian Image installiert. Der Start geht bei mir über einen Startskript in /etc/init.d.
Du startest in Deinem Skript fhem über einen Eintrag in /etc/rc.local.
Habe ich das soweit korrekt verstanden?
Warum das in den verschieden Varianten von fhem (*.tar.gz bzw. *.deb) unterschiedlich ist, traue ich mich erst gar nicht zu fragen ...
Gruß PeMue
weil das einfach davon abhängt, was sich der Künstler, der das Paket geschnürt hat, dabei gedacht hat. Feste Regeln gibts dafür nicht.
Die Vorgehensweise in meinem Skript ist eigentlich die einzige, die man sich NICHT merken sollte - da wird nämlich rc.local erstmal komplett gelöscht und dann neu geschrieben. Das sollte man nur machen, wenn man sicher sein kann, dass dort noch niemand etwas wichtiges eingetragen hat. Und direkt nach einer nackten raspbian Installation steht da definitiv nichts drin, was erhalten werden müsste. Deshalb habe ich diesen pragmatischen Weg gewählt.
und nun wünsche ich mir so eine kleine Aufsteckplatine passend für beaglebone black ...
hm, der hat aber eine recht weit verstreute Pinbelegung (//www.disk91.com/wp-content/uploads/2013/06/photo1.jpg), und der Luftdrucksensor käme dann direkt unter das Bohrloch. Oder ist auf der Rückseite neben dem Stecker noch Platz?
Was hat denn der Beaglebone Black für einen Stromverbrauch?
Gruß PeMue
Zitat von: PeMue schrieb am Mi, 25 September 2013 12:07hm, der hat aber eine recht weit verstreute Pinbelegung,
Die I2C pins liegen ganz gut zusammen.
Zitat von: PeMue schrieb am Mi, 25 September 2013 12:07und der Luftdrucksensor käme dann direkt unter das Bohrloch.
Oberhalb der Steckerleiste gibt es kein Bohrloch, da ist nur freier Himmel.
Zitat von: PeMue schrieb am Mi, 25 September 2013 12:07Oder ist auf der Rückseite neben dem Stecker noch Platz?
Ich sprach von Aufsteckplatine, nicht von Auflötplatine.
Zitat von: PeMue schrieb am Mi, 25 September 2013 12:07Was hat denn der Beaglebone Black für einen Stromverbrauch
Hab ich noch nicht gemessen, er entwickelt auf jeden Fall weniger Abwärme als der Raspi, der Verbrauch müsste also geringer sein.
Laut Datenblatt je nach Verwendung unter 1 Watt.
ZitatDie I2C pins liegen ganz gut zusammen.
Aber die Spannungsversorgung liegt im Vergleich zum Raspberry Pi weiter weg:
(siehe Anhang / see attachement)
Daher geht mit Dirk's bestehender Platine ohne Löten nicht viel.
Ich würde die Platine eher wieder als Lötplatine auf der Unterseite (Sensor neben dem Stecker) layouten. Dann wäre der Stecker für andere Dinge frei. Aber jeder wie er mag ...
Mir gefällt am BeagleBone black, dass er gleich einen A/D Wandler drauf hat.
Gruß PeMue
Du hast ja recht... aber wünschen darf ich mir das doch trotzdem :)
http://circuitco.com/support/index.php?title=BMP_on_the_Beagle_Bone_Black (//circuitco.com/support/index.php?title=BMP_on_the_Beagle_Bone_Black)
Wenn ich eine neue Platinenbestellung losschicke kann ich da ja mal ein Layout mit machen.
Und dann auch gleich noch eine LCD-Version zum Aufstecken :)
Gruß
Dirk
Zitathttp://circuitco.com/support/index.php?title=BMP_on_the_Beagle_Bone_Black (//circuitco.com/support/index.php?title=BMP_on_the_Beagle_Bone_Black)
Da passt ja gar kein Pin ins Raster und den Preis finde ich auch relativ hoch. Vermutlich ist da noch ein Spannungsregler und Transistor (wozu auch immer?) drauf ...
Gruß PeMue
Zitat von: PeMue schrieb am Mi, 25 September 2013 16:43Da passt ja gar kein Pin ins Raster und den Preis finde ich auch relativ hoch.
das hast Du völlig mißverstanden - mir ging es nicht um eine Produktempfehlung, sondern darum, dass sich schonmal jemand über das Thema Gedanken gemacht hat. Mehr nicht.
@Dirk: dann pack auch gleich einen einen Helligkeitsssensor mit drauf. Die Sache mit dem LCD finde ich gut - aber bitte ohne Funkhardware.
ZitatDie Sache mit dem LCD finde ich gut - aber bitte ohne Funkhardware.
Daher ist die Funkhardware ja optional. Das CSM muss nicht bestückt werden :)
Alternativ kann man die Platine derzeit auch mit einen RS485 Tranceiver bestücken.
Gruß
Dirk
Hi Betateilchen,
ich mache mir gerade Gedanken über einen Helligkeitssensor. Ich würde gerne die Beleuchtungstärke (//de.wikipedia.org/wiki/Beleuchtungsst%C3%A4rke) messen (z.B. zur Steuerung von Markisen, Rollläden, etc.) mit einem TSL2561 (//www.ams.com/eng/Products/Light-Sensors/Light-to-Digital/TSL2561). Für meine Photovoltaikanlage wäre aber die Globalstrahlung (//de.wikipedia.org/wiki/Globalstrahlung) interessanter. Da suche ich aber noch einen vernünftigen Sensor (AMS/Taos sollte da aber was haben). Gehäuse bzw. Funkstrecke ähnlich wie bei diesem (//www.busware.de/tiki-index.php?page=CPM-BS), aber vermutlich folgenden Änderungen (Antenne auf der Leiterplatte, Messung von Spannung und Temperatur, ggf. Integration von Prozessor und CC1101 wegen Preis CSM, ...). Aber wie gesagt momentan nur als Idee ... Und das gehört dann auch in die Bastelecke.
Gruß PeMue
Zitat von: PeMue schrieb am Do, 26 September 2013 06:18Für meine Photovoltaikanlage wäre aber die Globalstrahlung interessanter. Da suche ich aber noch einen vernünftigen Sensor
Das Thema wurde aber doch schon hier im Forum in epischer Breite diskutiert und samt Berechnungsformeln gelöst.
Link
Danke für den Hinweis, habe ich noch nicht gesehen. Aber den TSL250 bzw. TSL260 hatte ich auch im Visier.
Gruß PeMue
Hallo,
ich habe da ein paar Fragen:
Mit hipi-i2c wird der zweite I2C-0 Port auf den RPi's Rev.2 (Connector P5) aktiviert. Wenn ich nun einen RPi Rev.1 habe und das i2cBMP Modul auf den P1 manuell verdrahte, müsste doch hipi-i2c überflüssig sein, da dieser I2C Port bereits aktiviert ist. Ist das so?
Im Forum steht, dass das i2cBMP Modul mit dem COC Modul zusammen funktioniert. Ist dies auch mit dem RPi Rev.1 der Fall, da auf dem I2C-0 dann beiden Module liegen?
Und erkennt das 51_i2cBMP180.pm Programm den Anschluss des Moduls an einem "alten" RPi und verwendet dann gegebenenfalls nicht das pihi-i2c Programm?
Achim
Hi Achim,
hipi-i2c wird beim RPi Rev.2 benutz um den 2. I2C-Bus vom Kamera-Connector zum P5 umzurouten.
Wenn du den I2C-Bus am P1 benutzt sollte das überflüssig sein. Egal ob Rev.1 oder Rev.2.
Lediglich beim Define muss das richtige I2C-Device angegeben werden.
Beim Rpi Rev.1 sollte das /dev/i2c-0 sein.
Gruß
Dirk
Hat eigentlich schonmal jemand versucht, so eine Platine von einem RaspberryPi wieder runterzulöten? Ich habs aufgegeben... Mir ist ein Raspberry abgeraucht und ich wollte wenigstens die Sensorplatine retten, was sich als ziemlich unmögliches Unterfangen erwiesen hat :(
Hi betateilchen,
wenn es deinen Raspberry zerlegt hat, dann Nimm eine Heißluftpistole (Wenn vorhanden) und heize von unten ordentlich ein.
So habe ich auch schon andere Bauteile von Platinen retten können.
Gruß
Dirk
P.s. Was hat deinen Raspberry denn umgebracht?
Zitat von: Dirk schrieb am Mi, 09 Oktober 2013 20:37P.s. Was hat deinen Raspberry denn umgebracht?
nicht was? sondern wer? => meine Putzfrau
Habe neue Modulversion mit Unterstützung für die physical. I2C Module eingecheckt.
Damit kann es auch auf anderen Systemen (FRM, CubieBoard, BeagleBoard) genutzt werden.
Die neue Version funktioniert weiterhin alternativ standalone mit der HiPi Bibliothek.
Infos zu den physical. I2C Modulen gibt es hier:
http://forum.fhem.de/index.php/topic,20452.0.html (http://forum.fhem.de/index.php/topic,20452.0.html)
http://forum.fhem.de/index.php/topic,19797.0.html (http://forum.fhem.de/index.php/topic,19797.0.html)
Hallo zusammen,
ich habe die Installation nach betateilchens skript ausgeführt.
Auf der Raspberry Pi (Typ B) Konsole kommt folgendes:
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: -- -- -- -- -- -- -- 77
dito für die Ausgabe in der fhem Kommandozeile
{ qx(i2cdetect -y 0) }
Nur wenn ich jetzt mit
define BMP180 I2C_BMP180 /dev/i2c-0
den Sensor definiere, kommt folgendes:
$name error: HiPi library not installed
Ich dachte, es läge an den Rechten, aber die udev Regel greift.
Langsam gehen mir etwas die Ideen aus.
Danke + Gruß
PeMue
Edit:
Und auf der Raspberry Pi Konsole kommt:
sudo hipi-upgrade
Latest version of HiPi Perl Modules is already installed
Zitat von: PeMue am 14 Oktober 2014, 19:58:50
Langsam gehen mir etwas die Ideen aus.
hast du die RPII2C Variante mal getestet?
Grüße
Klaus
Hallo Klaus,
danke für den Hinweis. Die Variante mit RPII2C funktioniert. Ich habe auch mal die grafischen HiPi Tools installiert, aber irgendwie findet fhem die Hi-Pi Tools nicht. Manche Dinge muss man nicht verstehen ;)
Danke + Gruß
Peter
Hallo
im Modul ist noch ein Fehler, der den I2C Betrieb über FRM verhindert:
In der Funktion sub I2C_BMP180_i2cwrite($$$) wird beim Aufruf von I2CWrtFn für i2cwrite eine falsche Parameterliste übergeben: Das Register darf nicht als eigener Hash "reg" geführt werden
CallFn($iodev->{NAME}, "I2CWrtFn", $iodev, {
direction => "i2cwrite",
i2caddress => $hash->{I2C_Address},
reg => $reg,
data => join (' ',@data),
});
sondern muss als erster Wert im "data" Hash enthalten sein:
CallFn($iodev->{NAME}, "I2CWrtFn", $iodev, {
direction => "i2cwrite",
i2caddress => $hash->{I2C_Address},
data => $reg.' '.join (' ',@data),
});
Als Folge liefert der Sensor nur 0 als Daten zurück, was als 903.4 mBar und 70° C Temperatur interpretiert wird.
Richtig sieht die Funktion so aus:
sub I2C_BMP180_i2cwrite($$$) {
my ($hash, $reg, @data) = @_;
if ($hash->{HiPi_used}) {
eval {
$hash->{devBPM180}->bus_write($reg, join (' ',@data));
I2C_BMP180_I2CRec($hash, {
direction => "i2cwrite",
i2caddress => $hash->{I2C_Address},
reg => $reg,
data => join (' ',@data),
});
};
Log3 ($hash, 1, $hash->{NAME} . ': ' . I2C_BMP180_Catch($@)) if $@;;
} else {
if (defined (my $iodev = $hash->{IODev})) {
CallFn($iodev->{NAME}, "I2CWrtFn", $iodev, {
direction => "i2cwrite",
i2caddress => $hash->{I2C_Address},
data => $reg.' '.join (' ',@data),
});
} else {
return "no IODev assigned to '$hash->{NAME}'";
}
}
}
Zitat von: MEitelwein am 11 November 2014, 00:15:50
im Modul ist noch ein Fehler, der den I2C Betrieb über FRM verhindert:
In der Funktion sub I2C_BMP180_i2cwrite($$$) wird beim Aufruf von I2CWrtFn für i2cwrite eine falsche Parameterliste übergeben: Das Register darf nicht als eigener Hash "reg" geführt werden
falsch ist relativ
Für RPII2C und NetzerI2C ist "reg" notwendig da sonst nicht zwischen Register und Daten unterschieden werden kann.
ich habe vergessen, ob es einen Grund gibt, dass in FRM bei der I2CWriteFn beim i2cwrite das reg nicht ausgewertet wird - sinnvoll ist das nicht. Das sollte man dann aber nicht in den I2C-client-modulen abfangen (das geht ja völlig am Sinn einer hardwareunabhängigen API vorbei), sondern im FRM ändern.
EDIT: Auf der niedrigsten Ebene spezifieziert das I2C-protokoll eigentlich keine Register-addressen, das sind (aus Sicht des Protokolls) einfach Daten. Hängt vom addressierten Chip ab, ob er das erste Byte (oder die ersten Bytes) als Registeraddresse interpretiert oder nicht. Damit gehört es der reinen Lehre nach eigentlich ins Client-modul. Beim Lesen ist das etwas anderes, da muss die (optionale) Register-addresse ja erst auf den I2C-Bus geschrieben werden, bevor auf Lesen umgeschaltet wird. Aber unabhängig davon istl natürlich einfacher dem FRM das Berücksichtigen eines (optionalen) reg-wertes beim i2cwrite hinzuzufügen. Schränkt die Nutzung für Chips die das nicht brauchen ja nicht ein.
Zitat von: klausw am 11 November 2014, 00:48:42
falsch ist relativ
Für RPII2C und NetzerI2C ist "reg" notwendig da sonst nicht zwischen Register und Daten unterschieden werden kann.
In 10_FRM.pm ist die i2c_write Funktion so definiert:
COMMANDHANDLER: {
$package->{direction} eq "i2cwrite" and do {
$firmata->i2c_write($package->{i2caddress},split(" ",$package->{data}));
last;
};
Das Hash reg wird also gar nicht ausgewertet und der Write funktioniert erst, wenn das reg als erstes Byte in Data steht. Liegt der Fehler dann also hier, wenn andere i2c_write Implementierungen über 3 Parameter (i2caddress, reg, data) angesteuert werden? Ich bin nicht der Perl Experte und konnte den Code hinter $firmata->i2c_write nicht finden - in welchem Modul ist das eigentlich implementiert?
Noch eine Anregung (und grundsätzlich mal DANKE für dieses Modul!), um netteren Log-Output für das Debugging zu erzeugen:
sub I2C_BMP180_GetCal ($$) {
my ($hash, $rawdata) = @_;
my @raw = split(" ",$rawdata);
my $n = 0;
my $name = $hash->{NAME};
$hash->{calibrationData}{ac1} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{ac2} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{ac3} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{ac4} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++], 0);
$hash->{calibrationData}{ac5} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++], 0);
$hash->{calibrationData}{ac6} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++], 0);
$hash->{calibrationData}{b1} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{b2} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{mb} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{mc} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{calibrationData}{md} = I2C_BMP180_GetCalVar($raw[$n++], $raw[$n++]);
$hash->{STATE} = 'Initialized';
Log3 $hash, 5, "$name Gelesene Kalibrierungswerte:";
Log3 $hash, 5, "$name AC1: $hash->{calibrationData}{ac1}";
Log3 $hash, 5, "$name AC2: $hash->{calibrationData}{ac2}";
Log3 $hash, 5, "$name AC3: $hash->{calibrationData}{ac3}";
Log3 $hash, 5, "$name AC4: $hash->{calibrationData}{ac4}";
Log3 $hash, 5, "$name AC5: $hash->{calibrationData}{ac5}";
Log3 $hash, 5, "$name AC6: $hash->{calibrationData}{ac6}";
Log3 $hash, 5, "$name B1 : $hash->{calibrationData}{b1}";
Log3 $hash, 5, "$name B2 : $hash->{calibrationData}{b2}";
Log3 $hash, 5, "$name MB : $hash->{calibrationData}{mb}";
Log3 $hash, 5, "$name MC : $hash->{calibrationData}{mc}";
Log3 $hash, 5, "$name MD : $hash->{calibrationData}{md}";
return
}
Zitat von: MEitelwein am 11 November 2014, 07:51:49
$firmata->i2c_write nicht finden - in welchem Modul ist das eigentlich implementiert?
Device/Firmata/Platform.pm (https://github.com/ntruchsess/fhem-mirror/blob/I2C/fhem/FHEM/lib/Device/Firmata/Platform.pm#L575)
-> fixed (http://sourceforge.net/p/fhem/code/6946/)
Zitat von: ntruchsess am 11 November 2014, 08:34:15
-> fixed (http://sourceforge.net/p/fhem/code/6946/)
das ging schnell ;D
Beim i2cwrite wird aber unter Umständen auch ein Register übertragen. Habe ich das im 10_FRM.pm übersehen?
Nochmal zur Erklärung, wieso das reg im hash überhaupt existiert.
Bei I2C devices welche mehrere Register besitzen, wird im Fall des Lesens erstmal eine Schreiboperation mit der Registeradresse ausgeführt. Um Lese- und Schreibvorgang einigermaßen homogen zu halten wird das reg in beiden Fällen abgespalten (ausserdem erwarten viele i2c hardwaretreiber ein separates register). Im Nachhinein (also im physical Modul) ist es nicht mehr möglich herauszufinden, ob ein logisches Modul auf Registern basiert (z.B. PCA9532) oder eben nicht (z.B. PCF8574). Daher sollte dies im logischen Modul erfolgen und an das physikalische weitergegeben werden.
Zitat von: klausw am 11 November 2014, 09:46:57
Habe ich das im 10_FRM.pm übersehen?
Ist doch egal, wer das übersehen hat, wir hatten das halt nicht auf dem Radar, dass das im 10_FRM i2cwrite halt ursprünglich ohne register war als wir das Interface abgestimmt haben. Ist ja jetzt nachgezogen.
Gruß,
Norbert
Ich meinte in Deiner aktuellen Änderung.
Du hast nur das read angepasst und nicht das write, richtig?
Das write müsste auch ein reg verarbeiten können.
kann es doch? (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L672)
Zitat von: ntruchsess am 11 November 2014, 12:33:12
kann es doch? (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L672)
hmm, das meinte ich mit übersehen 8)
danke für den hinweis
Danke für die schnelle Reaktion :)
Ich hoffe ich bin hier richtig es geht um das Modul "i2c_BMP180" Ich setze den poll-interval auf 1 und speichere die Config ab. Nach jedem "shutdown restart" wird poll-interval aber wieder auf 5 gesetzt. Das sehe ich daran das neben dem "Save Config" button ein rotes Frage Zeichen zusehen ist klicke ich drauf erscheint die Meldung:
Last 10 structural changes:
attr BMP180 poll_interval 5
Ich denke das könnte ein BUG sein !?
MFG, Daniel Joachims
jop ist nen Bug
werde es evtl. heute noch beheben
Hallo,
Ich hätte da auch ein Problem siehe
http://forum.fhem.de/index.php/topic,40927.msg334842.html#msg334842
Nach jedem "shutdown restart" wird auch attr oversampling_settings auf 3 zurückgedreht.
Bei mir muss ich oversampling_settings auf 0 setzen, da es in Verbindung von FRM und dem Arduino nano mit ENC28J60 sonst zu fehlerhaften Messwerten beim Luftdruck kommt (vermutlich Timingprobleme).
@klausw: Kannst Du da analog zu poll-interval mal nachsehen?
Zitat von: thymjan am 22 September 2015, 04:13:01
Nach jedem "shutdown restart" wird auch attr oversampling_settings auf 3 zurückgedreht.
Bei mir muss ich oversampling_settings auf 0 setzen, da es in Verbindung von FRM und dem Arduino nano mit ENC28J60 sonst zu fehlerhaften Messwerten beim Luftdruck kommt (vermutlich Timingprobleme).
@klausw: Kannst Du da analog zu poll-interval mal nachsehen?
Na toll, habe auch nen Fehler eingebaut:
Zeile 139 von:
if (AttrVal($name, '', '?') eq '?') { nach
if (AttrVal($name, 'oversampling_settings', '?') eq '?') { ändern.
Baue es heute ein, wenn ich Zeit habe
Zitat von: Edi77 am 20 September 2015, 22:24:28
Hallo,
Ich hätte da auch ein Problem siehe
http://forum.fhem.de/index.php/topic,40927.msg334842.html#msg334842
mit FRM kenne ich mich leider überhaupt nicht aus
aber du hast ja kompetente Hilfe ;)
Sind BMP085 und BMP180 von der Ansteuerung her identisch?
Im Modul scheint das entsprechende Attribut keine Auswirkung zu haben.
Gute Frage,
Ein BMP180 für 5E ist auf dem Weg zu mir, dann kann ich das mal testen
Jetzt läuft es mal, Temperatur stimmt, aber
2015-09-22_13:10:17 BMP085 T: 22.0 P: 497.9 P-NN: 528.3
2015-09-22_13:15:17 BMP085 T: 22.0 P: 498.0 P-NN: 528.4
2015-09-22_13:20:17 BMP085 T: 22.1 P: 498.1 P-NN: 528.5
2015-09-22_13:30:17 BMP085 T: 22.0 P: 498.0 P-NN: 528.4
2015-09-22_13:35:17 BMP085 T: 22.1 P: 498.1 P-NN: 528.5
2015-09-22_13:40:17 BMP085 T: 22.0 P: 498.0 P-NN: 528.4
Bei manchen Messungen sieht man im Modul I2C_BMP180 (in Verbindung mit FRM) unter Internals die Variable uncompTemp. Ein paar Messungen weiter verschwindet diese wieder.
Eigentlich wird ja in der Subroutine I2C_BMP180_GetPress bei jedem Durchgang die Variable aus dem hash gelöscht.
Wie kann es dann sein, das sie gelegentlich angezeigt wird?
Hallo zusammen,
gerade gefunden:
https://developer-blog.net/hardware/raspberrypi/raspberry-pi-luftdruck-sensor-bmp180/
Der BMP180 sollte genauso wie der BMP085 angesteuert werden können.
Gruß PeMue
Zitat von: PeMue am 23 September 2015, 10:22:01
Der BMP180 sollte genauso wie der BMP085 angesteuert werden können.
Diese Erkenntnis ist aber definitiv nicht neu :)
Hallo zusammen,
ich probiere gerade einen BMP180 in Betrieb zu nehmen. Leider wirft die Installation des HiPi Perl Moduls ein Problem aus. Bei dem Schritt
perl hipi-install
scheitert die Installation von "libopengl-perl":
The following packages have unmet dependencies:
libopengl-perl : Depends: freeglut3 but it is not going to be installed
Depends: libglu1-mesa but it is not going to be installed or
libglu1
perl-modules : Breaks: libthread-queue-perl (< 3.05)
Obwohl ich manuell "freeglut3" und "libglu1-mesa" bzw. "libglu1" installiert habe, bleibt der Fehler der Gleiche.
Hat jemand eine Idee?
Versuche mal die Anbindung ohne HiPi (alter Weg) mit dem RPII2C-Modul (neuere einfachere Möglichkeit).
Der Raspi sollte für I2C so vorbereitet sein:
http://forum.fhem.de/index.php/topic,40927.msg334204.html#msg334204 (http://forum.fhem.de/index.php/topic,40927.msg334204.html#msg334204)
Danke für den Tipp! Damit hat es geklappt und ich kann den Luftdruck jetzt anzeigen/loggen! :D