1-Wire noch einmal

[Guest]

Originally posted by: <email address deleted>

Ich habe heute die ersten öffentlichen Versionen der Module für das
1-Wire-System ins SVN eingestellt, unter contrib/1-Wire.

00_OWX.pm ist das Modul für die direkte Anbindung des 1-Wire Bus via
serielle Schnittstelle oder USB.

Achtung: Die käuflichen USB-1Wire Konverter funktionieren an der Fritzbox
wegen fehlender Treiber nicht. Dazu muss man etwas spezieller vorgehen, und
zwar einen USB-Seriell-Konverter mit FTDI Chip zusammen mit einem
Seriell-1Wire-Konverter einsetzen. Um das zu vereinfachen, habe ich in dem
Verzeichnis auch drei Schaltpläne abgelegt, mit deren Hilfe man sich
entweder einen Seriell-1Wire Konverter oder einen USB-1-Wire Konverter mit
FTDI Chip selbst zusammenlöten kann (Kosten ca. 20 €).

21_OWTEMP.pm ist das Modul, welches 1-Wire-Temperatursensoren (DS1820 etc.)
mit dem Interface-Modul verbindet.

Achtung: Dieses Modul ist namensgleich mit dem Modul 21_OWX.pm von Martin
Fischer. Es enthält auch dessen Funktionalität, kann also auch mit dem OWFS
(1-Wire Filesystem) verwendet werden. Im Idealfalll sollte man das also
einfach austauschen können, ohne von der bisherigen Funktionalität des OWFS
irgendetwas einzubüßen. Zumindest hat das bei mir im mehrwöchigen Test mit
beiden Interface-Typen keine Probleme erzeugt.

Diese Idee (von Martin Fischer und Olaf Droegehorn), verschiedene 1-Wire
Devices (Temperatursensoren, Schalter etc.) über gemeinsame Module an
unterschiedliche Interfaces (direkt, via OWFS und via CUNO) anzubinden,
wird konsequent weiter verfolgt.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,
sehr schön!
OneWire an ner Fritzbox würd mich auch interessieren.  Löten hab ich
aufgegeben seitdem ich bei nem Bausatz mal nen Widerstand
durchgeschmort hab beim 3ten Nachlöten wg kalter Lötstellen...
Kurz: Gibt's sowas fertig zu kaufen? Demnächst bei Dir? Oder bei
busware?
Gruß, Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

guter Witz, das mit dem Bausatz ...Bei mir sicher nicht - aber ich kann ja
mal meine Studenten fragen.

Mein Tipp als Alternative A:
- USB-Seriell Konverter mit FTDI-Chipsatz als Fertiggerät
- Passiven DS9097 Seriell-1-Wire Konverter.
Problem dürfte sein, dass ggf. dieser passive Adapter eine zusätzliche
Stromversorgung braucht.

Mein Tipp als Alternative B:
- USB 9097U- USB-1-Wire-Konverter, un dein für Deine FritzBox compiliertes
Kernelmodul, das diesen erkennt. Sollte auch nicht schwer sein.

Alternative C:
Es gibt immer die etwas ältere Möglichkeit, auf der FB mit Freetz + OWFS zu
arbeiten, oder einen CUNO zu verwenden.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Zwiebel]

                                                 

Hi,

ich bin gerade dabei das modul zu testen. An meiner FritzBox hängt ein
usb zu serial Wandler mit ftdi chip.
nach einem
modprobe usbserial
modprobe ftdi_sio

hab ich dann ein neues device bekommen.
/dev/ttyUSB0

in FHEM hab ich das OWX so definiert.
define serialtemp OWX /dev/ttyUSB0

fhem> list serialtemp
Internals:
   CFGFN
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0
   INTERFACE  DS9097
   NAME       serialtemp
   NR         302
   ROM_ID     FF
   STATE      Active
   TYPE       OWX
   interval   60
Attributes:
   room       OWX
   temp-scale C

fhem> get serialtemp devices
OWX: No devices found

das steht im log:
2012.02.21 20:16:27 1: OWX: Search CRC failed
2012.02.21 20:24:29 3: OWX: DS9097 block failure
2012.02.21 20:24:29 3: OWX: Failure in temperature conversion


leider bekomm ich meine 1-wire Temperatursensoren nicht ans laufen.

Hier der output von digitem (einzeln angesteckt hat auch funktioniert)
1:
10008A30000800B3 : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 10008A30000800B3
2:
10106AE3000800BB : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 10106AE3000800BB
3:
1083643000080078 : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 1083643000080078

vielen dank schon mal
Gruß

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ah, mal sehen was hängt denn an dem USB-to-Serial-Konverter ?
Ein nackter DS9097 ?

Der beschafft sich nämlich die Stromversorgung für die 1-Wire-Sensoren aus
einer parasitären Anzapfung der Handshake-Leitungen der seriellen
Schnittstelle - ist also darauf angewiesen, dass diese auch Sapnnung
liefern. Daran habe ich bei dem 9097 noch etwas "getunt", möglichrweise zu
viel. Führt dann einfach dazu, dass während des etwas länger dauernden
Suchalgorithmus die Spannung in die Knie geht...

Ich kümmere mich um Abhilfe - muss einfach das Handshaking im 9097-Mode
wieder hochfahren. Interimslösung sollte sein: den 1-Wire Bus extern mit 5V
zu versorgen.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Zwiebel]

                                                 

ich hab vor längerer Zeit das hier mal nachgebaut, und im stecker
verstaut.
http://lena.franken.de/hardware/temperaturmessung.html

[FB 7390] ---- [usb zu rs232] ---- [schaltung von oben] ---- [DS1820]

Eine externe Spannung würd ich gern vermeiden.

Gruß
Zwiebel

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

OK: Zwischenresultat: Ich habe es gerade mit meinem passiven DS9097
ausprobiert - und da funktionierte es wunderbar. Weicht aber subtil von
Deinem passiven Adapter ab, siehe das Schaltnild in contrib/1-Wire.

Offenbar sind die diversen bekannten Schaltungen für den DS9097 bei
perl-Ansteuerung etwas kritisch.

Ich werde (morgen) mal so ein Ding zusammenlöten, wie Du es beschrieben
hast.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ah, mal sehen was hängt denn an dem USB-to-Serial-Konverter ?
Ein nackter DS9097 ?

Der beschafft sich nämlich die Stromversorgung für die 1-Wire-Sensoren aus
einer parasitären Anzapfung der Handshake-Leitungen der seriellen
Schnittstelle - ist also darauf angewiesen, dass diese auch Sapnnung
liefern. Daran habe ich bei dem 9097 noch etwas "getunt", möglichrweise zu
viel. Führt dann einfach dazu, dass während des etwas länger dauernden
Suchalgorithmus die Spannung in die Knie geht...

Ich kümmere mich um Abhilfe - muss einfach das Handshaking im 9097-Mode
wieder hochfahren. Interimslösung sollte sein: den 1-Wire Bus extern mit 5V
zu versorgen

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich habe einen DS9097U-009#  9-polig,  weitere Ziffern 0743A
361128    am PC. Die Sensoren werden parasität betrieben.

Dieser Adapter wird als DS2480 erkannt. Weiter geht's dann aber nicht.
Nur noch Fehlermeldungen, wie Reset failed ....

Kann ich irgendwie behilflich sein?

Gruß
Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Uff, das haut mich vom Sockel - mit dem hab eich nämlich getestet....

Den Fehler für den passiven Adapter habe ich gefunden, das wird in Kürz
ebeoben sein. Dann widme ich mich mal Deinem Problem.

LG

pah


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Zwiebel]

                                                 

Ich bin schon total gespannt ob es damit funktioniert.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hier noch die Daten mit $owx_debug=2   :

2012.02.23 10:29:00 3: OWX: opened device /dev/ttyS0
2012.02.23 10:29:01 3: OWX: Sending out 0xc1
2012.02.23 10:29:01 3: OWX: Receiving
2012.02.23 10:29:01 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.23 10:29:01 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.23 10:29:01 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.23 10:29:08 3: OWX: Sending out 0xe3 0xc5
2012.02.23 10:29:08 3: OWX: Receiving 0x81
2012.02.23 10:29:08 3: OWX: Reset failure
2012.02.23 10:29:08 1: OWX: Search reset failed
2012.02.23 10:29:08 3: OWX: Sending out 0xe3 0xc5
2012.02.23 10:29:08 3: OWX: Receiving 0xcd
2012.02.23 10:29:08 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 10:29:08 3: OWX: Receiving 0xcc 0x44 0xa2
2012.02.23 10:29:08 3: OWX_Block: failure, length=3
2012.02.23 10:29:29 3: OWX: Sending out 0xe3 0xc5
2012.02.23 10:29:29 3: OWX: Receiving 0x81
2012.02.23 10:29:29 3: OWX: Reset failure
2012.02.23 10:29:29 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 10:29:30 3: OWX: Receiving 0xcc 0x44


Vielleicht hilfts ja weiter
Gruß
Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

noch was: wenn ich nach "define name OWX ...." ein "delete name"
absetze, kommt Fehlermeldung

Use of uninitialized value in delete at ./FHEM/00_OWX.pm line 697.

Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Liste,

diverse Dinge gefixt.

1. Letzter Punkt: delete wurde gefixt - den Fehler habe ich aus dem
alten OWTEMP abgeschrieben (

2. Erster Punkt: Passive Adapter.
Mit denen gibt es tatsächlich Timing-Probleme, die auch jetzt noch nicht
gut gelöst sind. Ich habe den nackten 9097 von Zwiebel nachgebaut (das ist
einfach mein Test-9097 minus 2 Kondensatoren und Dioden, siehe Schaltbild
im contrib/1-Wire). Mit dem funktioniert jetzt das Auffinden aller Devices
auf dem 1-Wire Bus, d.h. der Suchalgorithmus.

Allerdings gibt es bei mir den eher unwitzigen Effekt, dass die
Temperaturen wunderbar gelesen werden, wenn ich das Ding an meinem Laptop
betreibe - und stattdessen die Temperaturen immer 85 Grad Celsius lauten,
wenn ich das - mit denselben Perl-Modulen ! - auf einem stationären Rechner
ablaufen lasse. Ich habe die beiden leicht modifizieren Module trotzdem ins
CVS gestellt, hier muss klar noch mehr getestet werden. Dazu gibt OWTEMP.pm
einen relativ langen String ins Log aus, der den Inhalt des ganzen
Scratchpad = internes Memory des DS1820 darstellt. Gleich das erste
Datenbyte nach dem Auslesebyte 0xBE ist etwas verrückt: Auf einem Rechner
z.B. hexadezimal 0x28 => ca. 20 Grad Celsius, auf dem anderen 0xAA => eben
85 Grad.

Ich bin noch auf der Suche, woran das liegen kann.

3. Zweiter Punkt: Aktiver Adapter DS9097U - die von bernhard gemeldeten
Fehler.

Das Log gibt mir Rätsel auf.

Zur Ablauflogik: Jeder Temperatursensor hat ein eigenes Abfrageintervall
{interval}. Ist dieses abgelaufen, wird das Scratchpad des Sensors gelesen
(alle Werte). Damit dabei nicht jedesmal die Wartesekunde fällig wird
(Temperaturmessung dauert ca. 1 Sekunde), wird diese Temperaturmessung
nicht von OWTEMP initialisiert (in der Routine OWXTEMP_GetValues wird am
Anfang manuell $con=0 gesetzt, so dass das nachfolgende Anstoßen der
Temperaturmessung nicht erfolgt - sondern nur gelesen wird). Das
eigentliche Anstoßen der Temperaturmessung geschieht viel effizienter,
indem das Modul OWX mit seinem eigenen {interval} eine Temperaturmessung
ALLER Sensoren auf dem Bus anstößt. Das spart enorm viel Datentransfer,
weil dabei die ID der Sensoren unterdrückt wird. Bei mir wird das so
eingesetzt, dass die Sensoren 1x pro Minute angestoßen werden, ihre
Temperaturmessung durchzuführen - und dann alle 5 Minuten asynchron der
Wert abgefragt wird. Diese Asynchronität macht das auch wunderbar
kompatibel mit dem OWFS.

Jetzt zum Log

2012.02.23 10:29:08 3: OWX: Sending out 0xe3 0xc5    - setzt den 2480 in
den Kommandomodus und gibt ihm den Reset-Befehl (das kann 0xC1 oder 0xC5
sein)
2012.02.23 10:29:08 3: OWX: Receiving 0x81
2012.02.23 10:29:08 3: OWX: Reset failure                   - verstehe ich
nicht, laut Datenblatt sollte die Rückgabe 0xCD oder 0xED sein

2012.02.23 10:29:08 1: OWX: Search reset failed          - klar, dass dann
diese Meldung kommt

2012.02.23 10:29:08 3: OWX: Sending out 0xe3 0xc5   - hier noch mal die
gleiche Sequenz
2012.02.23 10:29:08 3: OWX: Receiving 0xcd              - et voila,
wunderbarerweise funktioniert es hier ?


2012.02.23 10:29:08 3: OWX: Sending out 0xe1 0xcc 0x44  - jetzt setze den
Adapter in den Datenmodus 0xE1, sende ein "Skip ROM = Ignoriere Adresse"
0xCC und dann einen                                Temperaturmessbefehl
0x44.

2012.02.23 10:29:08 3: OWX: Receiving 0xcc 0x44 0xa2 - verstehe ich wieder
nicht - woher kommt das 3. Byte in der Antwort ?
2012.02.23 10:29:08 3: OWX_Block: failure, length=3     - klar, dass dann
wieder ein Fehler generiert wird.

2012.02.23 10:29:29 3: OWX: Sending out 0xe3 0xc5    - wieder mal ein
Reset-versuch
2012.02.23 10:29:29 3: OWX: Receiving 0x81
2012.02.23 10:29:29 3: OWX: Reset failure

2012.02.23 10:29:29 3: OWX: Sending out 0xe1 0xcc 0x44 - jetzt setze den
Adapter in den Datenmodus 0xE1, sende ein "Skip ROM = Ignoriere Adresse"
0xCC und dann einen                                Temperaturmessbefehl
0x44.
2012.02.23 10:29:30 3: OWX: Receiving 0xcc 0x44 - et voila, auch hier
funktioniert es jetzt beim zweiten Mal richtig !

Etwas undurchsichtig also. Möglicherweise handelt es sich ebenfalls um ein
Timing-Problem. Vielleicht mal zum Ausprobieren in der Routine
OWX_Query_2480 das jeweils letzte Argument der beiden Befehlszeilen
select(undef,undef,undef,0.04) verändern - 0.05, 0.03 etc. Das ist die
Verzögerung in Sekunden, bis es weitergeht (z.B. vom Schreiben zum Lesen).

LG pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Dienstag, 21. Februar 2012, 02:32:16 schrieb Prof. Dr. Peter A. Henning:
> [...]
> 21_OWTEMP.pm ist das Modul, welches 1-Wire-Temperatursensoren (DS1820 etc.)
> mit dem Interface-Modul verbindet.
>
> Achtung: Dieses Modul ist namensgleich mit dem Modul 21_OWX.pm von Martin
> Fischer. Es enthält auch dessen Funktionalität, kann also auch mit dem OWFS
> (1-Wire Filesystem) verwendet werden. Im Idealfalll sollte man das also
> einfach austauschen können, ohne von der bisherigen Funktionalität des OWFS
> irgendetwas einzubüßen. Zumindest hat das bei mir im mehrwöchigen Test mit
> beiden Interface-Typen keine Probleme erzeugt.

Abgesehen von dem Typo (das Modul von mir heisst nicht 21_OWX.pm, sondern
21_OWTEMP.pm) ist die Info von Peter so nicht ganz richtig!

Das Modul 21_OWTEMP.pm ist in der Version (contrib) _definitiv nicht_
lauffähig mit dem vorhandenen OWFS-Modul! Dazu würde man das neue 00_OWFS.pm
Modul benötigen.

Die aktuell in FHEM ausgelieferten und in der SVN Version vorliegenden 1-Wire
Module wurden von mir komplett neu geschrieben und sind so noch nicht
verfügbar! Weder im SVN noch im contrib Verzeichnis. Ausser Olaf und Peter hat
momentan keiner den Quelltext, da wie Peter weiter unten richtig schreibt,
erst die Anbindung an CUNO vollzogen werden soll. In sofern kann jeder
Interessierte zwar das Modul OWX.pm in Verbindung mit 21_OWTEMP.pm (das von
Peter angepasst wurde, jedoch von mir noch nicht auf Funktionalität in
Verbindung mit OWFS:pm getestet wurde) nutzen, wird dann aber aller
Wahrscheinlichkeit nach eine bestehende OWFS Nutzung unmöglich machen.

Aktuell gibt es von mir dazu auch keinen Support, da die Veröffentlichung von
Peter zu früh kommt. Hier ist noch Abstimmung zwischen Olaf, Peter und mir
erforderlich.

> Diese Idee (von Martin Fischer und Olaf Droegehorn), verschiedene 1-Wire
> Devices (Temperatursensoren, Schalter etc.) über gemeinsame Module an
> unterschiedliche Interfaces (direkt, via OWFS und via CUNO) anzubinden,
> wird konsequent weiter verfolgt.

DAS ist widerum richtig, benötigt aber aus diversen Gründen noch etwas Zeit.

Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com