Hallo,
vielleicht gibt es hier in dieser Community jemanden, der mir zu dieser speziellen Problematik eine Hilfestellung geben kann:
Ich lese unter Linux mehrere Temperatursensoren des Typs DS1820/DS18S20 via 'cat' aus der Linux-Verzeichnisstruktur '/sys/bus/w1/device/xx-xxxxxxxxxxxx/w1_slave' aus und parse die Ergebnisse mit grep/awk/cut.
Im Zuge eines größeren Projektes möchte ich mit dem DS2438 eine Batterie überwachen (Spannung/Temperatur), evtl. Grenzwertüber- und unterschreitungen sollen gemeldet werden.
Nun zum Problem:
Der DS2438 den ich hier vorliegen habe und versuche auszulesen integriert kein 'w1_slave'-Verzeichnis in obige Verzeichnisstruktur. Er ist ansprechbar, unter '/sys/bus/w1/device/' ist auch ein Verzeichnis mit der Seriennummer ('26-000xxxxxxxxx') vorhanden, allerdings fehlt zum Auslesen der Werte mittels 'cat' das Verzeichnis 'w1_slave'!
Die anderen 'normalen' Verzeichnisse sind vorhanden: 'driver', 'id', 'name', 'power', 'subsystem' und 'uevent'.
Nach tagelangem googlen und intensiven Studiums diverser PDFs, Datasheets etc. sehe ich keine Erklärung dafür.
Hat jemand hier bereits Erfahrungen gesammelt? Kennt jemand einen DS2438 der dieses 'w1_slave'-Verzeichnis bereits geboten hat (und demzufolge mein IC hier defekt sein könnte)? gibt es möglicherweise unterschiedliche Typen dieses ICs?
Bin für jeden Hinweis dankbar ...
Ansonsten ein schönes Wochenende!
Ein Sensor kann kein Verzeichnis erzeugen - dazu braucht es mindestens ein Interface zum 1-Wire-Bus und ein Kernelmodul. Welche sind das, und kann diese Software den DS2438 abfragen ?
LG
pah
Hallo Yodiwan
Ich denke Du ließt Deine Temp.-Sensoren Über das w1-Kernelmodul aus, das kann meines Wissens nur DS1820.
Dein "Freund" wäre z.B. OWFS. Die Software kann mit Deinem DS2438.
CK
Hallo Yodiwan und le66ck,
wie es aussieht benutzt Du die 1-Wire-Kernel-Module des RPi,
leider ist darin eben der DS2438 noch nicht enthalten.
Das würde ich sehr begrüßen,
aber leider scheinen die Gurus dafür noch nicht die Zeit (oder Lust?) gefunden zu haben.
Drin sind u.a.:
- Temp.-Sensoren
- DS2423 Counter
- DS2408 8xPIO (lesen und schreiben)
- und einige andere, neuere Sensoren zur Batterieüberwachung !!!
FHEM kann mit dem 58_GPIO.pm-Modul (von mir) jetzt neben den Temp. Sensoren auch den DS2423 und DS2408 auslesen.
-> Link (http://forum.fhem.de/index.php?topic=11142.msg75319#msg75319)
Gruß RoBue
Hallo,
wie von Prof.Dr.Henning schon vermutet und von RoBue treffend formuliert, benutze ich die Kernelmodule w1_gpio und w1_term vom RasPi.
Danke für die Hinweise! In dieser Ecke (die Kernelmodule) hatte ich meine Probleme nicht vermutet.
@RoBue: Leider habe ich nach Deinem Hinweis auf die mangelnde Unterstützung der Kernelmodule keine Hinweise darauf gefunden, wie genau der Enwicklungsstand hier ist bzw. keine Liste der unterstützten ICs gefunden. Dein Hinweis "- und einige andere, neuere Sensoren zur Batterieüberwachung !!!" lässt mich hoffen, ich bin keineswegs auf einem DS2438 fixiert, wenn ich eine ähnliche Funktionalität auch wo anders bekomme. Hast Du da nen Link für mich?
@le66ck: Ich hatte OWFS schon installiert, aber irgendwie komme ich damit nicht klar. Hätte ich definitiv auf dem RasPi damit ne Chance, besagten IC sauber auszulesen?
Allen einen herzlichen Dank und einen sonnigen Sonntag!
Ja, das geht mit OWFS.
LG
pah
Soweit ich das bisher nachlesen konnte, arbeitet owfs aber nicht mit den GPIOs vom RasPi zusammen. Dort sind aber meine Sensoren angeschlossen.
Zumindest konnte ich bis jetzt keine vernünftigen Werte auslesen, die Fake-Sensoren habe ich bereits deaktiviert. Das ist etwas frustrierend.
cu ...
Na ja, darum hatte ich ja mehrfach nach dem Interface gefragt...
OWFS kann nach meinem Wissen die GPIO-Ports des RPi nicht ansteuern. OWFS ist auch nicht primär für den RPi gedacht, das wäre etwas viel verlangt.
Die Wiki-Seite zum Thema RPi und 1-Wire ist immer noch in Arbeit, weil ich gegenwärtig etwas zuviel andere Dinge zu tun habe. http://www.fhemwiki.de/wiki/Raspberry_Pi_und_1-Wire (//www.fhemwiki.de/wiki/Raspberry_Pi_und_1-Wire)
Ich halte ehrlich gesagt auch nicht viel davon, das ganze 1-Wire-Bus-Timing der Raspberry CPU zu überlassen. Besser sollte man an den I2C-Bus oder den USB ein dezidiertes Businterface anschließen, das kostet nur ein paar Euro. Was ich auch noch nicht getestet habe, ist der direkte Anschluss eines DS2480 Busmaster an den UART des RPi.
LG
pah
Hallo Yodiwan,
hier die genauere Info aus dem Kernel-Programm,
welche Sensoren direkt am RPi funktionieren:
#define W1_FAMILY_SMEM_01 0x01
#define W1_FAMILY_SMEM_81 0x81
#define W1_THERM_DS18S20 0x10
#define W1_COUNTER_DS2423 0x1D
#define W1_THERM_DS1822 0x22
#define W1_EEPROM_DS2433 0x23
#define W1_THERM_DS18B20 0x28
#define W1_FAMILY_DS2408 0x29
#define W1_EEPROM_DS2431 0x2D
#define W1_FAMILY_DS2760 0x30
#define W1_FAMILY_DS2780 0x32
#define W1_THERM_DS28EA00 0x42
DS2760/80 gehen wohl in die Richtung eines DS2438 (?)
- soweit ich das beim Überfliegen verstanden habe.
Irgendwo habe ich sogar gelesen,
dass der DS2413 schon mal in irgendeinem Patch drin ist.
Gruß, RoBue
PS: Hab gerade noch diesen Link gefunden:
-> http://www.emdebian.org/~zumbi/efika/FreeScaleKernel/linux-kernel/drivers/w1/slaves/ (//www.emdebian.org/~zumbi/efika/FreeScaleKernel/linux-kernel/drivers/w1/slaves/)
Die Frage ist, wer sich genug auskennt, um dieses Modul in den RPi noch reinzupacken!
Ich leider nicht!
Trotzdem wäre es super!
Vielen Dank für alle Infos.
Ich werde möglicherweise beide Wege parallel verfolgen:
den RPI2 werde ich mir als Busmaster zulegen (der RPI1 arbeitet mit dem GPIO4 des RPi, so wie ich es jetzt beschaltet habe), aber ich werde auch versuchen ein Kerneltreiber zu kompilieren (@RoBue: DANKE für den Klasse-Link mit den Treibern, Anleitungen gibt es genügend im Netz). Wobei mir die Hardware-Variante etwas unkomplizierter erscheint ;-)
Leider sind die ICs DS2760/2780 im Internet nicht bekommen. Das hat schon etwas gemeines an sich ...
Allen Beteiligten wünsche ich eine tolle Woche!
Hallo Yodiwan,
ich bin noch auf einen weiteren Treiber (Patch) gestoßen (DS2413):
-> https://patchwork.kernel.org/patch/1922031/ (//patchwork.kernel.org/patch/1922031/)
Wenn es Dir gelingen sollte, diese beiden zu integrieren,
wäre das klasse
und zumindest meine Dankbarkeit und meine Bewunderung hättest Du sicher.
Ich finde die GPIO4-Lösung für kleine Systeme durchaus für sinnvoll.
OWFS ist m.E. schon wieder zu groß und zu mächtig.
Bitte stelle dann die Kernel-Module hier ein.
Ich bin gern bereit, die fhem-Anpassung vorzunehmen (58_GPIO4.pm).
Liebe Grüße und viel Erfolg,
RoBue
OWFS ist "mächtig", das stimmt schon. Da haben auch viele Leute über Jahre hinweg dran mitgewirkt, wichtiger noch: mit Unterstützung von Dallas/Maxim. Darin sind also allerhand Probleme wie reconnects, timing etc. gelöst worden - und das wird mit steigender Komplexität der Devices nicht einfacher.
Eigentlich ist also der beste Weg für eine GPIO-Anbindung, ein Kernelmodul zu entwickeln, welches eine von OWFS und anderen (!) Programmen verwendbare Schnittstelle zum 1-Wire Bus schafft, z.B. als tty-Device. Die Auswertung der binären Daten könnte man dann darauf setzen.
LG
pah
Hallo
Mein Englisch ist nicht gut..., aktuell kann OWFS mit dem "w1-Kernelmodul" umgehen.
Im Netz z.B. mal "owfs w1" schauen.
Sollte ich falsch liegen, wie gesagt mein Eng....!
Hier wird auch 2 mal w1 mit aufgeführt
http://www.fhemwiki.de/wiki/OWServer_%26_OWDevice (//www.fhemwiki.de/wiki/OWServer_%26_OWDevice)
Oder als Idee einen I2C zu 1Wire IC nehmen, einen DS2482!
CK
Hallo RoBue,Yodiwan
Ich hatte zu viel Zeit und hab mal einen neuen Kernel mit den obigen Patch compiliert.
Die gute Nachricht mein RPi läuft noch, die Schlechte ich kann momentan damit noch nichts anfangen und es dauert
ca. 6 Stunden. Meine SD Karte war 4Gb groß, als Info!
Anleitung von hier http://www.gtkdb.de/index_7_2186.html (//www.gtkdb.de/index_7_2186.html)
Wobei das Patchen ... ich keine Ahnung!!!
Ich hab einfach 2 mal sudo patch < ~/w1_family.patch in die beiden Verzeichnisse .../drivers/wi und .../drivers/wi/slaves ausgeführt,
wobei ich den Patch w1_family.patch genannt hatte.
Vielleicht kann einer mit einem weiteren Horizont..., den "besseren, richtigeren" Patch-Befehl, mal posten!
Ich glaub, nach "make oldconfig" wurde die Änderung erkannt und gefragt als was es compiliert werden soll, also m wie Modul.
CK
Hmmmm ...
ich hätte jetzt nicht gleich den ganzen Kernel neu übersetzt ... das Modul würde reichen, denke ich. Der Link von RoBue war da (jedenfalls für mich) genau richtig, weil da der Quellcode für den DS2438 dabei war.
Mittlerweile bin ich mangels Zeit auf eine andere Alternative gestoßen (Mein Linux-Wissen ist selbst für eine Modul-Kompilation zu wenig, ich wüsste ganz gern, was ich da meinem RPi antue):
http://raspberrypi.homelabs.org.uk/i2c-connected-1-wire-masters/ (//raspberrypi.homelabs.org.uk/i2c-connected-1-wire-masters/)
Wie Prof.Dr.Henning schon erwähnte, ist es - gerade bei den Multi-Sensoren - oftmals mit dem Timing problematisch. Da tut ein Busmaster sicher gute Dienste. Im Zusammenhang mit OWFS kann ich dann die Sensoren ebenfalls mit "cat" auslesen und die Ergebnisse parsen. Is halt nur schwer an die Teile ran zu kommen. Glücklicherweise hab ich bei Reichelt welche gefunden.
Schönes WE!
ZitatIs halt nur schwer an die Teile ran zu kommen. Glücklicherweise hab ich bei Reichelt welche gefunden.
An welche Teile kommt man schwer ran und was hast Du bei Reichelt gefunden? Kennst Du das hier: Link (http://forum.fhem.de/index.php?topic=10785.0)?
Hallo Uwe,
ja, das hab ich schon gesehen. Ich bin aber ein "Selbermacher", für mich ist fast immer der Weg das Ziel. Auf diese Weise lerne ich das System kennen und erwarte auch in deren Folge komplexere Aufgaben lösen zu können. Das "Teil" bei Reichelt ist ein DS2482-100S. Den gibts meines Wissens nicht mal in der Bucht ...
Ferner: ich benutze an der RPi auch ein LCD-Display und einige andere GPIOs, so dass Deine Lösung leider die Konnektivität einschränken würde.
Danke für den Hinweis und ein schönes WE!
Huch, das Reichelt den DS2482 hat, war mir entgangen. Lange kann das aber noch nicht sein und er ist in "begrenzter Stückzahl" erhältlich. fuchs-shop.com vertreibt alternativ diese Bauteile in D.
Welche GPIOs nutzt Du? Ich frage deswegen, weil ich eine neue Version des I2C-Interfaces aufgelegt habe, bei der zwei GPIOs über Optokoppler rausgeführt werden.
Hi,
für das Display sind es die GPIOs: 7,8,18,23,24,25. Es ist KEIN I2C-LCD.
Hast Du den Schaltplan für Dein Interface selbst entwickelt? Ich habe eine Beschaltung für den DS2482-100 gefunden, die ohne weitere passive Bauteile auskommt. Auf Deiner Platine entdecke ich aber einige davon ... So kann ich den DS2438 direkt auf einer kleinen SMD-Platine mit dem Controller verbauen.
Gruß,
der Yodi.
ZitatHast Du den Schaltplan für Dein Interface selbst entwickelt?
Da braucht's in diesem Fall keine große Entwicklung... ;-) Ein Blick in's Datenblatt sagt schon fast alles.
ZitatIch habe eine Beschaltung für den DS2482-100 gefunden, die ohne weitere passive Bauteile auskommt.
Klar, sicher möglich. Aber schon die Grundbeschaltung aus dem Datenblatt (und das ist Herstellerempfehlung!) benötigt 4 externe Bauteile. Wenn man dann noch ein paar bekannte Probleme abfangen möchte, sieht's dann schon so aus (derzeitige Testversion):
(siehe Anhang / see attachement)
Dazu kommen dann (bei der Nachfolgeversion) noch die Bauteile für die GPIOs...die Platine wird voll :)
Hallo kan man jetzt schon was mit einem DS2438 anfangen am GPIO
Verzeichnis wir ja anscheinend erstellt :/sys/devices/w1_bus_master1/26-000001922cfe/
Nur im Fhem kann ich ihn nicht einbinden ?
GPIO4: device family 26 not supported
Gibts da ne andere lösung ?
Gruß otto
Natürlich. OWMULTI mit OWX, OWX_ASYNC oder Owserver
LG
pah
Direkt am GPIO4 ?
Gruß otto
Natürlich nicht ::)
Gefragt war doch nach einer "anderen" Lösung.
pah