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
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
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
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
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
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
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
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
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
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
Ich bin schon total gespannt ob es damit funktioniert.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
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
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
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
Originally posted by: <email address deleted>
Das mit dem Typo ist richtig - gemeint war 21_OWTEMP.pm.
Der Rest ist. pardon, Unsinn: Die im SVN unter contrib/1-Wire stehende
Version von 21_OWTEMP.pm beruht auf dem ALTEN OWTEMP.pm, das zur
FHEM-Distribution gehört - und NICHT auf dem neuen Code. Der ist von
Martinb Fischer noch nicht veröffentlicht worden - und das werde ich
natürlich nicht an seiner Stelle machen.
Infolgedessen läuft das 21_OWTEMP.pm auch mit dem OWFS.pm aus der
Distribution.
LG pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Donnerstag, 23. Februar 2012, 13:52:39 schrieb Prof. Dr. Peter A. Henning:
> Das mit dem Typo ist richtig - gemeint war 21_OWTEMP.pm.
>
> [...]
>
> Infolgedessen läuft das 21_OWTEMP.pm auch mit dem OWFS.pm aus der
> Distribution.
alles klar! dann ist ja "alles in butter"! danke für die aufklärung!
gruß martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Verusch mit select ..... 0,04
2012.02.23 23:04:59 3: OWX: opened device /dev/ttyS0
2012.02.23 23:05:00 3: OWX: Sending out 0xc1
2012.02.23 23:05:00 3: OWX: Receiving
2012.02.23 23:05:00 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.23 23:05:00 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.23 23:05:01 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.23 23:05:18 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:05:18 3: OWX: Receiving 0x81
2012.02.23 23:05:18 3: OWX: Reset failure
2012.02.23 23:05:19 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:05:19 3: OWX: Receiving 0xcc 0x44
2012.02.23 23:05:19 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:05:19 3: OWX: Receiving 0xcd
2012.02.23 23:05:19 3: OWX: Sending out 0xe1 0xf0 0xe3 0xb5
2012.02.23 23:05:19 3: OWX: Receiving 0x81 0xf0
2012.02.23 23:05:19 3: OWX: Sending out 0xe1 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe3 0xa5
2012.02.23 23:05:20 3: OWX: Receiving 0xf0 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.02.23 23:05:20 1: OWX: Search CRC failed
2012.02.23 23:05:20 1: OWX: 1-Wire devices found ()
2012.02.23 23:06:34 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:06:34 3: OWX: Receiving
2012.02.23 23:06:34 3: OWX: Reset failure
2012.02.23 23:06:34 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:06:34 3: OWX: Receiving 0xcc 0x44
2012.02.23 23:07:34 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:07:34 3: OWX: Receiving 0x81
2012.02.23 23:07:34 3: OWX: Reset failure
2012.02.23 23:07:34 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:07:34 3: OWX: Receiving 0xcc 0x44
Versuch mit select ....., 0.05
2012.02.23 23:10:44 3: OWX: opened device /dev/ttyS0
2012.02.23 23:10:45 3: OWX: Sending out 0xc1
2012.02.23 23:10:45 3: OWX: Receiving
2012.02.23 23:10:45 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.23 23:10:45 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.23 23:10:45 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.23 23:10:50 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:10:50 3: OWX: Receiving
2012.02.23 23:10:50 3: OWX: Reset failure
2012.02.23 23:10:50 1: OWX: Search reset failed
2012.02.23 23:10:50 1: OWX: 1-Wire devices found ()
2012.02.23 23:10:50 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:10:50 3: OWX: Receiving 0xcd
2012.02.23 23:10:51 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:10:51 3: OWX: Receiving 0xcc 0x44 0xa2
2012.02.23 23:10:51 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.23 23:10:51 3: OWX: Failure in temperature conversion
2012.02.23 23:11:50 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:11:50 3: OWX: Receiving
2012.02.23 23:11:50 3: OWX: Reset failure
2012.02.23 23:11:51 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:11:51 3: OWX: Receiving 0xcc 0x44
Versuch mit select ..... , 1.0
2012.02.23 23:12:32 3: OWX: opened device /dev/ttyS0
2012.02.23 23:12:33 3: OWX: Sending out 0xc1
2012.02.23 23:12:34 3: OWX: Receiving
2012.02.23 23:12:34 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.23 23:12:34 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.23 23:12:34 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.23 23:12:39 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:12:39 3: OWX: Receiving
2012.02.23 23:12:39 3: OWX: Reset failure
2012.02.23 23:12:39 1: OWX: Search reset failed
2012.02.23 23:12:39 1: OWX: 1-Wire devices found ()
2012.02.23 23:12:39 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:12:39 3: OWX: Receiving 0xcd
2012.02.23 23:12:39 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:12:39 3: OWX: Receiving 0xcc 0x44 0xa2
2012.02.23 23:12:39 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.23 23:12:39 3: OWX: Failure in temperature conversion
2012.02.23 23:12:50 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:12:50 3: OWX: Receiving 0x81
2012.02.23 23:12:51 3: OWX: Reset failure
2012.02.23 23:12:51 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:12:51 3: OWX: Receiving 0xcc 0x44
2012.02.23 23:13:39 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:13:39 3: OWX: Receiving
2012.02.23 23:13:39 3: OWX: Reset failure
2012.02.23 23:13:39 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:13:39 3: OWX: Receiving 0xcc 0x44
2012.02.23 23:13:50 3: OWX: Sending out 0xe3 0xc5
2012.02.23 23:13:50 3: OWX: Receiving 0x81
2012.02.23 23:13:51 3: OWX: Reset failure
2012.02.23 23:13:51 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.23 23:13:51 3: OWX: Receiving 0xcc 0x44
Gruß Bernhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hmmm.
Das sind also keine timing-Fehler, sondern echte Responses von dem
Busmaster. Ich nehme an, das Modell ist dieses hier:
http://datasheets.maxim-ic.com/en/ds/DS9097U-DS9097U-S09.pdf, und zwar MIT
dem ID-Chip.
Bis auf den ID-Chip hat das genau die Schaltung, die ich in meinem aktiven
Adapter habe. "Bis auf" ist eine interessante Sache - denn das kann
möglicherweise genau den Unterschied erklären. Ich habe bisher bei Maxim
aber noch keine Protokollbeschreibung für den DS9097U-009 gefunden, und
verwende daher die für den DS2480B
Ich werde mir also einen solchen DS9097U-009 besorgen, das kann ein paar
Tage dauern. Bis dahin könnte man höchstens noch ein paar Dinge
ausprobieren - vielleicht finden wir ja die Magie, die das zum Laufen
bringt.
Folgendes schlage ich vor:
1. Versuch mit dem Reset-Befehl. Je nachdem, in welche Application Note man
hineinschaut, ist dieser 0xC1 oder 0xC5. Ich habe 0xC5 verwendet, und es
lief. Ersetze doch mal in OWX_Reset_2480 das 0xC5 durch ein 0xC1.
2. Versuch mit dem Reset-Befehl. Offenbar klappt hier jeder 2.
Reset-Befehl. Also könnte man spaßeshalber in der Routine OWX_Reset_2480
die Zeile "my $res =OWX_Query_2480($hash,$cmd);" verdoppeln - das zweite
Mal natürlich ohne "my".
In dem ersten Log oben sah das ja schon ganz gut aus - zufällig klappte der
Reset-Befehl, und der Suchalgorithmus startete mit der Aussendung
2012.02.23 23:05:19 3: OWX: Sending out 0xe1 0xf0 0xe3 0xb5
2012.02.23 23:05:19 3: OWX: Receiving 0x81 0xf0
Das schaltet den DS2480B in den data mode, gibt das search rom Kommando
0xF0, schaltet dann in den command mode mit 0xE3 und startet den
accelerator mode mit 0xB5
2012.02.23 23:05:19 3: OWX: Sending out 0xe1 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe3 0xa5
Das schaltet den DS2480B mit 0xE1 in den data mode und gibt ihm den ersten
Suchstring = 16 Null-Bytes, gefolgt vom Umschalten in den command mode und
Abschalten des accelerator mode.
2012.02.23 23:05:20 3: OWX: Receiving 0xf0 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Das aber ist falsch - denn es führt eben beim Parsen nicht auf eine gültige
ROM-ID, darum der CRC-Fehler. Aber verständlich, denn der "search
rom"-Befehl 0xF0 beim Beginn des Suchalgorithmus gab ja nicht etwa 0xF0
zurück (wie es sein sollte !), sondern wieder den Code 0x81. Der
Suchalgorithmus wird also gar nicht initiiert.
Zum Vergleich: Bei mir sieht das so aus
2012.02.24 06:44:30 3: OWX: Sending out 0xe3 0xc5 - Reset
2012.02.24 06:44:30 3: OWX: Receiving 0xcd - Passt
2012.02.24 06:44:31 3: OWX: Sending out 0xe1 0xf0 0xe3 0xb5 -
Suchalgorithmus starten
2012.02.24 06:44:31 3: OWX: Receiving* 0xf0* - Passt
2012.02.24 06:44:31 3: OWX: Sending out 0xe1 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe3 0xa5 - Sende ersten
Suchstring
2012.02.24 06:44:31 3: OWX: Receiving 0x00 0x02 0x08 0x88 0x82 0xa2 0xa2
0x00 0x00 0x00 0x80 0x00 0x00 0x00 0xaa 0x80 - Erhalte eine Response mit
gültigem ID-Code
2012.02.24 06:44:31 1: OWX: 1-Wire devices found (OWX_10_A2D90D000800) - Et
voila
So - und an der fett markierten Stelle steht bei Dir eben die Rückgabe von
0x81.
Vorschlag - zum Ausprobieren: Auch hier einmal den fehlerhaft übermittelten
Befehl wiederholen. Also in der Routine OWX_Search_2480 die Zeile $sp1
= "\xE1\xF0\xE3\xB5";
ändern in $sp1 = "\xE1\xF0\xE1\xF0\xE3\xB5";
Mehr als diese Bastelvorschläge kann ich vorerst nicht bieten, denn, wie
gesagt, ich muss erst einen Adapter mit ID-Chip besorgen.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Aha, wir kommen der Sache näher.
Mit den parasitär versorgten Temperatursensoren haben wir das Problem, dass
der 1-Wire-Bus während der gesamten Temperaturmessphase auf +5 V gesetzt
werden muss - sonst bekomen die nicht genügend Leistung, um die Wandlung
durchzuführen.
Dazu muss ich also das Konvertierungskommando so umschreiben, dass es eine
Sekunde lang wartet.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hier die Ergebnisse: OWX_Query_2480 select wieder auf 0.04
1. Versuch (Reset 0xC5 -> 0xC1)
2012.02.24 09:50:55 3: OWX: opened device /dev/ttyS0
2012.02.24 09:50:56 3: OWX: Sending out 0xc1
2012.02.24 09:50:56 3: OWX: Receiving
2012.02.24 09:50:56 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.24 09:50:56 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.24 09:50:56 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.24 09:51:04 3: OWX: Sending out 0xe3 0xc1
2012.02.24 09:51:04 3: OWX: Receiving
2012.02.24 09:51:04 3: OWX: Reset failure
2012.02.24 09:51:04 1: OWX: Search reset failed
2012.02.24 09:51:05 1: OWX: 1-Wire devices found ()
2012.02.24 09:51:05 3: OWX: Sending out 0xe3 0xc1
2012.02.24 09:51:05 3: OWX: Receiving 0xe7
2012.02.24 09:51:05 3: OWX: No presence detected
2012.02.24 09:51:05 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 09:51:05 3: OWX: Receiving 0xcd 0xc1
2012.02.24 09:52:05 3: OWX: Sending out 0xe3 0xc1
2012.02.24 09:52:05 3: OWX: Receiving
2012.02.24 09:52:05 3: OWX: Reset failure
2012.02.24 09:52:05 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 09:52:05 3: OWX: Receiving 0xe5 0xc1 0xff
2012.02.24 09:52:05 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.24 09:52:05 3: OWX: Failure in temperature conversion
2012.02.24 09:53:05 3: OWX: Sending out 0xe3 0xc1
2012.02.24 09:53:05 3: OWX: Receiving
2012.02.24 09:53:05 3: OWX: Reset failure
2012.02.24 09:53:05 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 09:53:05 3: OWX: Receiving 0xe7 0xc1 0x7f 0xff
2012.02.24 09:53:05 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.24 09:53:05 3: OWX: Failure in temperature conversion
2012.02.24 09:54:05 3: OWX: Sending out 0xe3 0xc1
2012.02.24 09:54:05 3: OWX: Receiving
2012.02.24 09:54:05 3: OWX: Reset failure
2012.02.24 09:54:05 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 09:54:05 3: OWX: Receiving 0xe7 0xc1 0xff
2012.02.24 09:54:05 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.24 09:54:05 3: OWX: Failure in temperature conversion
2012.02.24 09:55:05 3: OWX: Sending out 0xe3 0xc1
2012.02.24 09:55:05 3: OWX: Receiving
2012.02.24 09:55:05 3: OWX: Reset failure
2012.02.24 09:55:05 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 09:55:05 3: OWX: Receiving 0xe7 0xc1 0xff
2012.02.24 09:55:05 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.24 09:55:05 3: OWX: Failure in temperature conversion
2. Versuch ... $res =OWX_Query_2480($hash,$cmd);" verdoppeln
(zussätzlich)
2012.02.24 10:00:27 3: OWX: opened device /dev/ttyS0
2012.02.24 10:00:28 3: OWX: Sending out 0xc1
2012.02.24 10:00:29 3: OWX: Receiving
2012.02.24 10:00:29 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.24 10:00:29 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.24 10:00:29 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.24 10:00:36 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:00:36 3: OWX: Receiving
2012.02.24 10:00:36 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:00:36 3: OWX: Receiving 0xe7
2012.02.24 10:00:36 3: OWX: No presence detected
2012.02.24 10:00:36 1: OWX: Search reset failed
2012.02.24 10:00:36 1: OWX: 1-Wire devices found ()
2012.02.24 10:00:36 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:00:36 3: OWX: Receiving 0xc0
2012.02.24 10:00:37 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:00:37 3: OWX: Receiving 0xc0
2012.02.24 10:00:37 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 10:00:37 3: OWX: Receiving 0xe7 0xc1 0xff
2012.02.24 10:00:37 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.24 10:00:37 3: OWX: Failure in temperature conversion
2012.02.24 10:01:08 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:01:09 3: OWX: Receiving
2012.02.24 10:01:09 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:01:09 3: OWX: Receiving 0xe7
2012.02.24 10:01:09 3: OWX: No presence detected
2012.02.24 10:01:09 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 10:01:09 3: OWX: Receiving 0xcd 0xc1
2012.02.24 10:01:37 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:01:37 3: OWX: Receiving
2012.02.24 10:01:38 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:01:38 3: OWX: Receiving 0xe7
2012.02.24 10:01:38 3: OWX: No presence detected
2012.02.24 10:01:38 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 10:01:38 3: OWX: Receiving 0xcd 0xc1
3. Versuch OWX_Search_2480 die Zeile $sp1
= "\xE1\xF0\xE3\xB5";
ändern in $sp1 = "\xE1\xF0\xE1\xF0\xE3\xB5";
2012.02.24 10:07:48 3: OWX: opened device /dev/ttyS0
2012.02.24 10:07:50 3: OWX: Sending out 0xc1
2012.02.24 10:07:50 3: OWX: Receiving
2012.02.24 10:07:50 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91
2012.02.24 10:07:50 3: OWX: Receiving 0x16 0x44 0x5a 0x00 0x93
2012.02.24 10:07:50 1: OWX: 1-Wire bus master DS2480 detected for the
first time
2012.02.24 10:07:57 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:07:57 3: OWX: Receiving 0x81
2012.02.24 10:07:57 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:07:58 3: OWX: Receiving
2012.02.24 10:07:58 3: OWX: Reset failure
2012.02.24 10:07:58 1: OWX: Search reset failed
2012.02.24 10:07:58 1: OWX: 1-Wire devices found ()
2012.02.24 10:07:58 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:07:58 3: OWX: Receiving 0xe7
2012.02.24 10:07:58 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:07:58 3: OWX: Receiving
2012.02.24 10:07:58 3: OWX: Reset failure
2012.02.24 10:07:58 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 10:07:58 3: OWX: Receiving 0xe7 0xc1 0xff
2012.02.24 10:07:58 3: OWX_Block: DAS 2480 failure, received 2 bytes
2012.02.24 10:07:58 3: OWX: Failure in temperature conversion
2012.02.24 10:08:58 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:08:58 3: OWX: Receiving 0x81
2012.02.24 10:08:58 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:08:58 3: OWX: Receiving 0xe7
2012.02.24 10:08:58 3: OWX: No presence detected
2012.02.24 10:08:58 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 10:08:58 3: OWX: Receiving 0xcd 0xc1
2012.02.24 10:09:58 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:09:58 3: OWX: Receiving 0x81
2012.02.24 10:09:58 3: OWX: Sending out 0xe3 0xc1
2012.02.24 10:09:58 3: OWX: Receiving 0xe7
2012.02.24 10:09:58 3: OWX: No presence detected
2012.02.24 10:09:58 3: OWX: Sending out 0xe1 0xcc 0x44
2012.02.24 10:09:58 3: OWX: Receiving 0xcd 0xc1
Soll ich noch irgendwas ändern? Wie gesagt, alle Änderungen
gleichzeitig
Gruß
Bernhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Das sind also keine timing-Fehler, sondern echte Responses von dem
> Busmaster. Ich nehme an, das Modell ist dieses hier:http://datasheets.maxim-ic.com/en/ds/DS9097U-DS9097U-S09.pdf, und zwar MIT
> dem ID-Chip.
Wie ich oben schrieb:
ich habe einen DS9097U-009# 9-polig, weitere Ziffern 0743A
361128 am PC. Die Sensoren werden parasität betrieben.
Und der hat nach dem dir verlinkten Dokument einen ID-Chip
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hier noch die Daten, die der OneWireVier ausgibt
Device Address: 5A000005036D5B09 (09 5B 6D 03 05 00 00 5A)
Name: DS1982
Alternate Names: DS2502
Description: 1024 bit Electrically Programmable Read Only Memory
(EPROM) partitioned into four 256 bit pages.Each memory page can be
permanently write-protected to prevent tampering. Architecture allows
software to patch data by supersending a used page in favor of a newly
programmed page.
Gruß
Bernhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
mit freude verfolge ich die bewegung die sich hier ergbit.
ich hab mir die neuen 00_OWX.pmund
21_OWTEMP.pmvon SourceForge runter geladen und im FHEM eingebunden.
define 1wire OWX /dev/ttyUSB0
attr 1wire room 1
define sensor1 OWTEMP DS1820 8A30000800B3
define sensor1 OWTEMP DS1820 6AE3000800BB
define sensor3 OWTEMP DS1820 643000080078
attr sensor1 room 1
attr sensor2 room 1
attr sensor3 room 1
so sehen dann meine logs aus:
2012-03-15_18:00:23
sensor1 temperature: 18.25 °C
2012-03-15_18:05:23 sensor1 temperature: 67.25 °C
2012-03-15_18:10:23 sensor1 temperature: 66.25 °C
2012-03-15_18:15:23 sensor1 temperature: 9.19 °C
2012-03-15_18:20:23 sensor1 temperature: 17.73 °C
2012-03-15_18:25:23 sensor1 temperature: 18.25 °C
2012-03-15_18:30:23 sensor1 temperature: 33.25 °C
2012-03-15_18:35:23 sensor1 temperature: 35.25 °C
2012-03-15_18:40:23 sensor1 temperature: 69.25 °C
2012-03-15_18:45:23 sensor1 temperature: 9.25 °C
Ich vermute mal das es an meiner schaltung liegt.
http://lena.franken.de/hardware/temperaturmessung.html
Wenn die einfach "falsch" ist dann ist das auch schon mal eine info, mit
der ich weiter komme.
Oder habe ich etwas falsch verstanden?
vielen dank gruß
Zwiebel
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hab gerade gesehen es gab ne neue version! Gleich eingespielt. (hm vorher
1.09 jetzt 1.09...)
Jetzt seh ich das in den logs
vorher:
2012.03.15 19:57:08 1: OWX: Write incomplete ne 1
2012.03.15 19:57:08 1: OWX: Write incomplete ne
1
2012.03.15 19:57:08 1: OWX: Write incomplete ne
1
2012.03.15 19:57:52 1: OWX: Write incomplete ne 1
2012.03.15 19:58:52 1: OWX: Write incomplete ne 1
nacher:
2012.03.15 20:02:02 1: OWX: Reset called with unknown interface
2012.03.15 20:02:02 1: OWX: Block called with unknown interface
2012.03.15 20:02:52 1: OWX: Reset called with unknown interface
2012.03.15 20:03:52 1: OWX: Reset called with unknown interface
gruß
Zwiebel
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich fange mal hinten an:
Diese Fehlermeldungen gibt es, wenn das Interface nicht richtig gestartet
ist - kann sein, dass hier noch ein paar Byte sim Buffer hängen. Bitte FHEM
einfach nochmal starten.
Dann oben die Fehler: In Deinen Defines taucht zweimal "sensor1" auf -
beseitige den Fehler doch mal, und schau dann das Log an - das sollte
Einiges verbessern.
Weitere Kommunikation bitte im Thread "1-Wire Update" - ich kann nur schwer
auf beiden Thread saktiv sein.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com