Aktiver OW Adapter für RPi ohne USB

joachimm · 04 März 2013, 13:30:56

Hallo,

bevor ich wieder etwas falsch mache bitte ich um Hilfe. Ich habe schon mal einen USB OW Adapter gekauft. Im Nachhinein habe ich dann noch feststellen müssen, das diese Modell von OWX nicht unterstützt wird.

Da ich einen RPi einsetze, will ich nur ungern einen USB Port verwenden. Ich würde mir gerne den aktiven Adapter im fhemwiki nachbauen für die Verwendung an der IO Leiste. Die Bauanleitung ist doch für RS232? Kann ich die ohne weiteres mit einem MAX232 erweitern? Oder gibts das schon? Der Adapter von Busware möchte ich mir nicht leisten.

Auch ich würde auch gerne das tolle Alternativ DS2423 Modul einsetzten wollen.

Danke
Joachim

cassy · 04 März 2013, 18:03:16

Hallo Joachim,

wenn Du den aktiven Adapter hier meinst:

http://www.fhemwiki.de/wiki/Datei:Aktives_Interface.png

dann kannst Du Dir das "Gefummel" mit dem MAX232 gleich ganz sparen, indem Du eine der drei nachfolgenden Lösungen aufbaust / kaufst:

http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html
Link
oder
bei busware Dir den COC kaufen, der ist fertig und Du kannst direkt starten. Die Hardware ist eigentlich die gleiche, mal von Level-Shiftern abgesehen.
Ich habe beide Lösungen im Einsatz, im Echtsystem ist der Fullfeatured-COC allerdings mit der RadioOnly-Firmware in Betrieb, der RasPi macht via I2C und OWServer die 1Wire-Mimik selbst, siehe hierzu die Anpassungen im zweiten Link (Boris)

... und die die 2423-ATtiny-Module, die Du angesprochen hast, laufen daran sehr gut.

Chris <cassy>

Prof. Dr. Peter Henning · 04 März 2013, 19:56:08

Ein aktiver Adapter ist das auf dem Bild

www.fhemwiki.de/wiki/Datei:Aktives_Interface.png

schon. Er kann aber nur sehr wenig für die Stromversorgung der angeschlossenen Sensoren liefern. Insofern empfiehlt sich selbstverständlich, nicht einfach eine RSR232-Buchse anzuschließen, sondern die 5V-Spannung aus dem RPi herauszuführen. Also eher wie im rechten Bild auf

http://www.fhemwiki.de/wiki/Interfaces_f%C3%BCr_1-Wire

Zum COC: nach einigen Monaten Betrieb des COC habe ich jetzt den angeschlossenen 1-Wire Bus abgeklemmt. Es zeigten sich immer wieder Instabilitäten, wenn komplexe Busabfragen erfolgten - oftmals bis zum Ausstieg des COC aus der Kommunikation. Und das ist nicht auf das OWX-Modul zurückzuführen - sondern reproduzierbar auch bei manueller Abfrage mit Hilfe von get COC raw (irgendwas). In der Konsequenz habe ich auch diesen 1-Wire Bus durch ein USB-Interface angebunden.

Insgesamt bedient mein RPi nun drei verschiedene 1-Wire-Busadapter via USB (in drei verschiedenen Stockwerken angebunden über USB-Extender), ferner hängt am USB noch ein USB/Serial Konverter für meinen solaren Wechselrichter. Natürlich mit aktiven Hubs, die eine eigene Stromversorgung haben.

Desweiteren bedient mein FHEM-RPi auch noch einen entfernten zweiten RPi, auf dem OWFS installiert ist. Moit OWServer als Backendmodul und den OW... Modulen als Frontend. Also vier unterschiedliche 1-Wire Bussysteme - und der kleine RPi ist damit ganz happy...

LG

pah

cassy · 04 März 2013, 20:14:17

Hallo pah,

auch bei mir waren die Probleme mit der COC-Firmware (angesprochen die COC raw-Befehle) derart massiv, dass ich kurz überlegt hatte, eine USB-Adapter anzuschließen.
... aber wieder mal hat mich die Neugierde gepackt ...
Im COC hängt der DS2482 direkt am I2C des RasPi (Multimaster-Mode, geshared mit dem 1284p CoPro), und hier liegt die Chance für das COC-Modul.
- den Fullfeatured-COC mit der RadioOnly-FW flashen, somit lässt der 1284p die Finger vom DS2482.
- und dann den RasPi direkt mit dem DS2482 kommunizieren lassen (i2c-libs und Kernel-Module)
Dies funktioniert störungsfrei mit OWFS/OWServer und sollte auch mit OWX laufen.
Mit den marginalen Änderungen der Hardware Link habe ich fortan ein stabiles FHEM-System incl. 1-Wire, das dritte in fünf Jahren (zunächst Linux-Server mit passivem 1W-Adapter, dann virtueller Linux-Server mit Etherrape/Ethersex als 1W/FS20-Frontend, und aktuell RasPi).

Auf diesem Wege noch einmal Danke an Alle hier.

Chris <cassy>

Prof. Dr. Peter Henning · 04 März 2013, 21:02:22

Ah, ein Wissender - und das meine ich nicht ironisch !

Sehr erfreulich diese Auskunft, denn ich hatte so eine Kollision schon vermutet. Mir fehlte aber die Zeit, das wirklich im Detail zu untersuchen...

Wichtige Frage: Weiß Dirk Tostmann um diese Lösung ? Denn es hat um die Frage, ob COC und CUNO mit 1-Wire Probleme haben könnten, schon echten Streit gegeben. Was ich mir da alles habe anhören müssen, verschweige ich lieber.

Ich werde mir das bei Gelegenheit mal ansehen, denn ich habe noch eine andere Sache mit dem COC auf der Agenda: In der culfw zu ermöglichen, vom 1-Wire Bus auch ganze Zeichenketten abzuholen. Das Byte-weise Abholen erzeugt nämlich einen enormen Overhead.

Betreffend die nachgebauten DS2423-Zähler: Ich habe eine ganze Menge "echte" DS2423 gekauft, bin daran also eher weniger interessiert. Allerdings erlaubt die Emulation noch ganz andere Sachen, etwa programmierbare Dimmer, Drehzahlregler. Meine 1-Wire Installationen habe ich übrigens auch vor ca. 5 Jahren angefangen, mit einem Parallelport-Adapter.

LG

pah

cassy · 04 März 2013, 21:49:33

Hallo pah,

auf die Gefahr hin, dass wir hier OT werden ...
... aber ich denke, dass es wichtig ist. Die Meinungsverschiedenheiten und Anfeindungen habe ich gelesen. Es ist ja schon fast eine Glaubensfrage geworden, welche OW-pm's man einsetzt. Ich habe beide getestet, beide sind gut. Aber eben nur so gut, wie es die Hardware zulässt. Ich habe mit Dirk Tostmann bereits zum Jahreswechsel Kontakt aufgenommen, hierbei ging es jedoch vorrangig um die Hardwareverbesserungen des COC, die ich ihm vorgeschlagen habe. Diese wurden dann auch umgesetzt bzw. der Öffentlichkeit bekannt gemacht. Auf der Firmwareseite bin in der culfw nicht so tief drin, als dass ich hier kurzfristig eine Lösung hätte sehen können. Deswegen der Workaround mit dem ausgekoppelten DS2482 auf dem COC, und wirklich, so läuft er störungsfrei.
------------------
An den 2423emul hat mich besonders fasziniert, dass ich den Ultraschallsensor SRF02 via I2C an den ATtiny anbinden konnte und FHEM vorgaukelt, ein Zähler zu sein. Ich liebe einfache Lösungen, dass macht das System schlank und flexibel.
------------------
Vielen Dank für das Lob, welches ich in Anerkennung an OWX gerne zurückgebe.
Wir sollten in Kontakt bleiben.

@Joachim: Wie Du siehst, gibt es (wie immer in der OpenSource) viele Wege, die zum Ziel führen. DEN richtigen Weg für SICH zu finden ist das interessante daran.

Chris <cassy>

Prof. Dr. Peter Henning · 04 März 2013, 22:20:18

Hallo,

OT macht mir gar nichts aus...

Für mich ist das keine Glaubensfrage - ich nutze ja selbst OWServer auf dem zweiten RPi und mische das wunderbar mit meinen Modulen.
Dass darunter ein OWFS sitzt, das über Jahre hinweg von vielen Leuten (und mit aktivem Support von Dallas/Maxim) entwickelt wurde, ist den Wenigsten bewusst.

Die Ersteller von OWserver haben bisher auf meine Bitte, die OW... Frontendmodule in die Clientliste von OWServer einzubauen, nicht reagiert. Das entspricht eher der angedeuteten "Glaubensfrage".

Betreffend die Füllstandsmessung: Ich habe gerade einen kapazitiven Füllstandssensor für Öltanks in der Konstruktion. Ob das klappt, kann ich noch nicht genau sagen, weil die Dielektrizitätskonstante von Heizöl nur ca. 2 beträgt.

LG

pah

om · 05 März 2013, 04:20:53

Hallo
Ich weiß nicht ob du dir die Mühe machen möchtest zu löten
Es gibt von sheepwalk sehr preiswerten i2c Adapter der bei mir am
Rpi sehr gut funktioniert.
Ich hätte noch tolle andere adapterlinks bin allerdings
eben in Lombok und habe die links nicht parat
Gruß
Oliver

Prof. Dr. Peter Henning · 05 März 2013, 07:07:18

http://www.sheepwalkelectronics.co.uk/RPI2.shtml

LG

pah

joachimm · 05 März 2013, 13:08:36

Danke, das habe ich gesucht und bestellt.

Prof. Dr. Peter Henning · 12 März 2013, 09:06:03

Nach meinen Recherchen ist es eigentlich sehr einfach, von Perl aus direkt den i2c-Bus anzusteuern.

Da ich gerade OWX so umbaue, dass die verschiedenen Hardware-Typen der Interfaces in unterschiedlichen Modulen liegen, wird es also ein Leichtes sein, diesen Adapter zu unterstützen.

LG

pah

eldrik · 02 September 2013, 09:39:17

Zitat von: cassy schrieb am Mo, 04 März 2013 20:14Hallo pah,

auch bei mir waren die Probleme mit der COC-Firmware (angesprochen die COC raw-Befehle) derart massiv, dass ich kurz überlegt hatte, eine USB-Adapter anzuschließen.
... aber wieder mal hat mich die Neugierde gepackt ...
Im COC hängt der DS2482 direkt am I2C des RasPi (Multimaster-Mode, geshared mit dem 1284p CoPro), und hier liegt die Chance für das COC-Modul.
- den Fullfeatured-COC mit der RadioOnly-FW flashen, somit lässt der 1284p die Finger vom DS2482.
- und dann den RasPi direkt mit dem DS2482 kommunizieren lassen (i2c-libs und Kernel-Module)
Dies funktioniert störungsfrei mit OWFS/OWServer und sollte auch mit OWX laufen.
Mit den marginalen Änderungen der Hardware Link habe ich fortan ein stabiles FHEM-System incl. 1-Wire, das dritte in fünf Jahren (zunächst Linux-Server mit passivem 1W-Adapter, dann virtueller Linux-Server mit Etherrape/Ethersex als 1W/FS20-Frontend, und aktuell RasPi).

Auf diesem Wege noch einmal Danke an Alle hier.

Chris <cassy>

Hallo cassy,

kannst du den Weg i2c-libs und Kernel- Module etwas genauer beschreiben?

Ich habe auch einen Full-Featured COC und möchte diesen wie von dir beschreiben nutzen, um mehr aus dem 1wire Bus herausholen zu können und vor allem ein stabiles Konstrukt auf die Beine zu stellen.

Kann man bei deiner Methode weiterhin das Busware Raspberry Image verwenden, welches bereits die entsprechenden Vorraussetzungen, für die COC Nutzung, mitbringt? Oder bringt die Kombination Fhem, owserver, i2c-libs und Kernel Module und Busware Image auf lange Sicht Probleme mit sich?

Greetz
Eldrik

eldrik · 05 September 2013, 08:41:17

Hi,

ich antworte mir mal selber :)

Vielleicht hilft es dem ein oder anderen beim googlen...

1. COC mit der RadioOnly Firmware flashen
2. i2c-tools installieren (apt-get install i2c-tools)
3. sudo nano /etc/modprobe.d/raspi-blacklist.conf das Modul blacklist i2c-bcm2708 nach #blacklist i2c-bcm2708 auskommentieren
4. Module beim Systemstart laden --> sudo nano /etc/modules --> snd-bcm2835 und i2c-dev
5. mit i2cdetect -y 0 den i2c Bus 0 durchsuchen i2c Bus 1 ist der COC, für das Abfragen der Temperatursensoren brauchte nach dem RadioOnly flashen i2c 0 (ich haben einen Rev.B Pi mit 512MB)
6. für den owserver ist das File /etc/owfs.conf anzupassen, ich habe folgende Werte eingetragen:
server: device = /dev/i2c-0 # i2c port: DS2482-100
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
Celsius

Greetz
Eldrik