1-Wire Update

[Prof. Dr. Peter A. Henning]

Hallo Liste,

mal wieder etwas Neues betreffend die FHEM-Module zum direkten Anschluss eines 1-Wire Bus an FHEM.

1. Immer noch _nicht_ gefixt: Passive Adapter bzw. aktive Adapter an einem USB/Seriell-Umsetzer ohne eigene Spannungsversorgung. Betrifft also die Adapter DS9097 und DS9097U. Hier muss ich noch etwas in der Ansteuerung ändern, damit die parasitär versorgen Sensoren auchgenügend Power bekommen.

2. Aktive Adapter, die eine ordentliche Stromversorgung für die Sensoren bereitstellen, laufen gut - also etwa der USB 9097, oder ein DS2490

3. Es gibt ein paar Updates bei den Modulen 00_OWX.pm (direkter Anschluss 1-Wire an FHEM), sowie 21_OWTEMP.pm (läuft sowohl mit dem direkten Anschluss, als auch mit dem ALTEN OWFS). Steht im contrib.

4. Es gibt ein neues Modul 21_OWAD.pm - derzeit nur zum direkten Anschluss an FHEM, nicht mit OWFS (ginge aber einfach zu machen). Mit diesem Modul wird ein 4-Kanal A/D-Wandler DS2450 gesteuert und abgefragt. Damit kann man - mit entsprechendem Spannungsteiler - beliebige Gleichspannungen messen und (dank der eingebauten Schwellen) auch überwachen. Nett an dem DS2450 ist auch, dass seine vier Eingänge wahlweise auch als Ausgang funktionieren können - und somit auch als Schalter benutzt werden können. Zusammen mit einem Honeywell-Feuchtesensor mit analogem Ausgang (ca. 18 €) lässt sich also damit ein Feuchtesensor für FHEM aufbauen - der auch gleich den Aktor lokal bedienen kann. Oder gleich ein Multisensor, der auch noch die Temperatur misst (einfach ein DS1820 mit drauf). Oder ein Helligkeitssensor. Oder ein Schallpegelmessgerät. Anwendungen ohne Ende...

Neues Modul steht im contrib.

LG

pah

[Georg]

Hallo Peter,

spannend, danke! Werden inzwischen weitere Sensoren bzw. sogar Aktoren
unterstützt? Bislang waren es ja nur Temperatursensoren, so dass ich
meine Zähler (gepufferte, entprellte GP1-Module mit DS2423+DS2406) und
Aktoren (DS2406) immer per eingebetteter OWServer-Abfrage angesprochen
habe. Nicht schlimm, wenn's nicht so ist, meine Lösung läuft ja.

Viele Grüße
Georg

[Prof. Dr. Peter A. Henning]

Ich habe neue Versionen der 1-Wire-Module ins SVN gestellt.

1. Die Module sind inzwischen getestet mit den Adaptern
          DS9097 (+ USB-Serial-Konverter) = passiver Adapter, besteht nur aus ein paar Dioden (*)
          DS9097U-009 (+ USB-Serial-Konverter) = aktiver Adapter, enthält einen DS2480 Busmaster und einen DS2502-ROM (*)
          USB9097 = aktiver Adapter (**)
          DS2480 Busmaster an FTDI-Chip FT232RL (Eigenbau) (**)

2. Worin unterscheiden sich diese Adapter ? Die mit (*) Versehenen geben den 1-Wire-Devices keine Spannungsversorgung, so dass diese
sich parasitär aus der Datenleitung versorgen. Das sorgt dafür, dass die Termperaturmessung wesentlich langsamer ist: bei jedem Sensor  muss ca. 1 Sekunde gewartet werden, bis er die Messung abgeschlossen hat. A/D-Wandler wie z.B. der DS2450 funktionieren damit gar nicht (gut). Die mit (**) versehenen Adapter stellen 5 V Spannung zur Verfügung => schnellere Abfrage, auch A/D Konverter arbeiten problemlos. Mein Tipp daher: So schön diese parasitäre Versorgung klingt, aus Performance-Gründen sollte man lieber das Kabel mit einer weiteren Ader ausrüsten.

3. Was für Module gibt es ?
00_OWX.pm ist das eigentliche Interface, das den USB-Port bedient.
21_OWTEMP.pm ist das Modul für die Temperatursensoren, und  es läuft auch mit dem "alten" OWFS-Modul.
21_OWAD.pm ist das Modul für den A/D-Wandler (derzeit getestet mit einem DS2450). Witz dabei: alle vier Kanäle können separat benannt und mit Offset und Faktor versehen werden. Es ist also gar kein Problem, an diesen A/D Wandler einen analogen Feuchtesensor oder einen Fototransistor anzuschließen. Auch die käuflich erwerbbaren "Multisensoren" sollten mit diesem Modul laufen.
21_OWID.pm ist das Modul für alle "unbekannten" 1-Wire Devices.

4. Noch ein Hinweis zur Hardware: Die 6-poligen RJ11-Stecker ("dicke Westernstecker" oder "dünne Netzwerkstecker") der käuflich erwerbbaren 1-Wire-Hardware habe ich bei meiner Sensorik durch 3.5 mm Klinkenstecker ersetzt. Diese sind wesentlich besser handhabbar, schlanker, stabiler - und auch leicht sicherbar...

5. Wie geht es jetzt weiter ? Erst einmal Pause, nächste Woche beginnt bei uns wieder das Semester. Über kurz oder lang werde ich aber noch weitere Module implementieren. Jeder Interessent ist aufgerufen, den relativ gut dokumentierten Code zu erweitern. Meine genauen Pläne kann ich aber schon verraten, bei mir liegen derzeit herum
- DS2438 "Multisensor" (Spannung und Temperatur, z.B. für Akkuüberwachung)
- DS2417 8-fach I/O Baustein
- Analoger Feuchtesensor => Ziel ist, eine temperaturkompensierte (!) Feuchtemessung zu bauen.
- Bluetooth- Sender und Empfänger: 1-Wire hat mir immer noch ein paar Drähte zuviel. Ziel ist, per USB (oder 1-Wire ?) verkabelt an Ort X zu gehen - und von dort aus die letzten 5 m per Bluetooth auf den kabel- und stromlosen 1-Wire Sensor.

LG

pah

[bernhard]

Hallo,
sieht nicht schlecht aus, gibt aber noch ein paar Problemchen.
Erkannt wird:

2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_F86971010800 defined.
2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_D6C871010800 defined.
2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_AE0F3F010800 defined.
2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_ED3560010800 defined.
2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_879471010800 defined.
2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_67814C010800 defined.
2012.03.06 11:35:15 3: OWTEMP: Device OWX_10_FFBC54010800 defined.
Use of uninitialized value in hash element at /home/1wire/fhem.pl line
1601.
2012.03.06 11:35:15 3: Unknown attribute IODev, choose one of room
comment alias icon webCmd eventMap or use attr global userattr IODev
Use of uninitialized value in hash element at /home/1wire/fhem.pl line
1601.
2012.03.06 11:35:15 0: Strange call for typeless OWX_22_EEC11A000000:
AttrFn
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 477.
Use of uninitialized value in hash element at /home/1wire/fhem.pl line
1601.
2012.03.06 11:35:16 3: Unknown attribute IODev, choose one of room
comment alias icon webCmd eventMap or use attr global userattr IODev
Use of uninitialized value in hash element at /home/1wire/fhem.pl line
1601.
2012.03.06 11:35:16 0: Strange call for typeless OWX_22_69A31A000000:
AttrFn
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 477.
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 477.
Use of uninitialized value in hash element at /home/1wire/fhem.pl line
1601.
2012.03.06 11:35:16 3: Unknown attribute IODev, choose one of room
comment alias icon webCmd eventMap or use attr global userattr IODev
Use of uninitialized value in hash element at /home/1wire/fhem.pl line
1601.
2012.03.06 11:35:16 0: Strange call for typeless OWX_09_5B6D03050000:
AttrFn
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 521.
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 521.
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 521.
2012.03.06 11:35:16 1: OWX: 1-Wire devices found
(OWX_10_F86971010800,OWX_10_D6C871010800,OWX_10_AE0F3F010800,OWX_10_ED3560010800,OWX_10_879471010800,OWX_10_67814C010800,OWX_10_FFBC54010800,OWX_22_EEC11A000000,OWX_22_69A31A000000,OWX_09_5B6D03050000)
Use of uninitialized value $t in string eq at ./FHEM/01_FHEMWEB.pm
line 613.
Use of uninitialized value $t in hash element at ./FHEM/01_FHEMWEB.pm
line 614.
Use of uninitialized value $t in string eq at ./FHEM/01_FHEMWEB.pm
line 613.
Use of uninitialized value $t in hash element at ./FHEM/01_FHEMWEB.pm
line 614.
....
....
Auf der Oberfläche sind die 10-er zu finden, die 22-er nicht, und die
09-er scheint ja der Adapter zu sein.

Gruß
Bernhard

[bernhard]

Weiter,

die 09-er und 22-er sind mit "list" zu sehen .

Für die 10er steht überall tempLow=70, tempHigh=85, temperature=85,
STATE=Alarmed

Und Interval müsste kleine 10 Sekunden möglich sein.


Bernhard

[Prof. Dr. Peter A. Henning]

Na, es wird doch...

Die 22er sind bitte welche Modelle ?

Was steht als Attribut in der fhem.cfg ?

Mit den Temperaturangaben stimmt es auch: 70/75 sind die default-Werte der DS1820er für die Alarmschwellen, 85 kommt heraus, wenn noch keine Temperaturmessung vorgenommen wurde. Die startet mit den Defaulwerten erstamla nach 5 Minuten - man kann aber vorher schon mit "get <name> temperature" eine Messung initiieren.

Wieso sollen die Temperaturen so oft gemessen werden ?

LG

pah

[bernhard]

Hallo,

> Die 22er sind bitte welche Modelle ?

Sensoren-Typen/-Beschreibung lt OneWireViewer:

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.



Device Address: C800080154BCFF10 (10 FF BC 54 01 08 00 C8)

Name: DS1920

Alternate Names: DS18S20

Description: Digital thermometer measures temperatures from -55C to
100C in typically 0.2 seconds. +/- 0.5C Accuracy between 0C and 70C.
0.5C standard resolution, higher resolution through interpolation.
Contains high and low temperature set points for generation of alarm.




Device Address: 9E0000001AA36922 (22 69 A3 1A 00 00 00 9E)

Name: DS1822

Alternate Names:

Description: Digital thermometer measures temperatures from -55C to
125C in 0.75 seconds (max). +/- 2C accuracy between -10C and 85C.
Thermometer resolution is programmable at 9, 10, 11, and 12 bits.

>
> Was steht als Attribut in der fhem.cfg ?
>

abgeleitet aus autocreate

define 1wire OWX /dev/ttyS0
define OWX_10_F86971010800 OWTEMP DS1820 F86971010800
attr OWX_10_F86971010800 IODev 1wire
attr OWX_10_F86971010800 comment Hz_Warmwasser
attr OWX_10_F86971010800 model DS1820
attr OWX_10_F86971010800 room OWX,Heizung,Solaranlage
define OWX_10_D6C871010800 OWTEMP DS1820 D6C871010800

Im 2. Lauf von autocreate erzeugt:

define OWX_22_EEC11A000000 OWID EEC11A000000
attr OWX_22_EEC11A000000 IODev 1wire
attr OWX_22_EEC11A000000 room OWX
define OWX_22_69A31A000000 OWID 69A31A000000
attr OWX_22_69A31A000000 IODev 1wire
attr OWX_22_69A31A000000 room OWX
define OWX_09_5B6D03050000 OWID 5B6D03050000
attr OWX_09_5B6D03050000 IODev 1wire
attr OWX_09_5B6D03050000 room OWX

> Mit den Temperaturangaben stimmt es auch: 70/75 sind die default-Werte der
> DS1820er für die Alarmschwellen, 85 kommt heraus, wenn noch keine
> Temperaturmessung vorgenommen wurde. Die startet mit den Defaulwerten
> erstamla nach 5 Minuten - man kann aber vorher schon mit "get <name>
> temperature" eine Messung initiieren.

war auch nach längerer Zeit nicht geändert

>
> Wieso sollen die Temperaturen so oft gemessen werden ?

Ich habe einen Sensor, den ich schneller auslesen will , da ich von
dessen Temp-Wert Ein/Aus ableite

>


Beim 1. Lauf hatte ich die Sensoren noch mit autocreate :
- nur die Sensor-Familie 10.xxxxx werden angelegt (OWTEMP /
autocreate))

Bei, 2. Lauf :
- define OWTEMP für die 10.xxx ins *.cfg übernommen
jetzt werden OWID angelegt für 09.xxx und 22.xxx


DEF /dev/ttyS0
DeviceName /dev/ttyS0
INTERFACE DS2480
NAME 1wire
NR 118
PRESENT 1
ROM_ID FF
STATE Active
TYPE OWX
interval 60


CFGFN
DEF 5B6D03050000
NAME OWX_09_5B6D03050000
NR 131
OW_FAMILY 9
OW_ID 5B6D03050000
PRESENT 1
ROM_ID 09.5B6D03050000.5A
STATE Initialized
TYPE OWID


CFGFN DEF 69A31A000000
NAME OWX_22_69A31A000000
NR 130
OW_FAMILY 9
OW_ID 69A31A000000
PRESENT 1
ROM_ID 22.69A31A000000.9E
STATE Initialized
TYPE OWID

ALARM 1
DEF DS1820 67814C010800
INTERVAL 300
NAME OWX_10_67814C010800
NR 124
OW_FAMILY 10
OW_ID 67814C010800
PRESENT 1
ROM_ID 10.67814C010800.94
STATE Alarmed
TYPE OWTEMP

tempHigh 75 2012-03-06 14:39:35
tempLow 70 2012-03-06 14:39:35
temperature 85 2012-03-06 14:39:35


Und folgende Fehlermeldung (perl): use of uninitialized value in
string eq at 00_OWX.pm line 608


Und ein Zyklus:

2012.03.06 14:37:36 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:37:37 3: OWX: Receiving 0xcd
2012.03.06 14:38:36 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:38:37 3: OWX: Receiving 0xcd
2012.03.06 14:39:35 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:35 3: OWX: Receiving 0xcd
2012.03.06 14:39:35 3: OWX: Sending out 0xe1 0x55 0x10 0x67 0x81 0x4c
0x01 0x08 0x00 0x94 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:35 3: OWX: Receiving 0x55 0x10 0x67 0x81 0x4c 0x01
0x08 0x00 0x94 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:35 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:35 3: OWX: Receiving 0xcd
2012.03.06 14:39:35 3: OWX: Sending out 0xe1 0x55 0x10 0xf8 0x69 0x71
0x01 0x08 0x00 0x30 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:35 3: OWX: Receiving 0x55 0x10 0xf8 0x69 0x71 0x01
0x08 0x00 0x30 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:35 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:35 3: OWX: Receiving 0xcd
2012.03.06 14:39:35 3: OWX: Sending out 0xe1 0x55 0x10 0xed 0x35 0x60
0x01 0x08 0x00 0x83 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:35 3: OWX: Receiving 0x55 0x10 0xed 0x35 0x60 0x01
0x08 0x00 0x83 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:35 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:35 3: OWX: Receiving 0xcd
2012.03.06 14:39:35 3: OWX: Sending out 0xe1 0x55 0x10 0x87 0x94 0x71
0x01 0x08 0x00 0xc6 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:35 3: OWX: Receiving 0x55 0x10 0x87 0x94 0x71 0x01
0x08 0x00 0xc6 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:36 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:36 3: OWX: Receiving 0xcd
2012.03.06 14:39:36 3: OWX: Sending out 0xe1 0x55 0x10 0xae 0x0f 0x3f
0x01 0x08 0x00 0xd4 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:36 3: OWX: Receiving 0x55 0x10 0xae 0x0f 0x3f 0x01
0x08 0x00 0xd4 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:36 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:36 3: OWX: Receiving 0xcd
2012.03.06 14:39:36 3: OWX: Sending out 0xe1 0x55 0x10 0xd6 0xc8 0x71
0x01 0x08 0x00 0x6b 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:36 3: OWX: Receiving 0x55 0x10 0xd6 0xc8 0x71 0x01
0x08 0x00 0x6b 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:36 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:36 3: OWX: Receiving 0xcd
2012.03.06 14:39:36 3: OWX: Sending out 0xe1 0x55 0x10 0xff 0xbc 0x54
0x01 0x08 0x00 0xc8 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2012.03.06 14:39:36 3: OWX: Receiving 0x55 0x10 0xff 0xbc 0x54 0x01
0x08 0x00 0xc8 0xbe 0xaa 0x00 0x4b 0x46 0xff 0xff 0x0c 0x10 0x87
2012.03.06 14:39:37 3: OWX: Sending out 0xe3 0xc5
2012.03.06 14:39:37 3: OWX: Receiving 0xcd


Vielleicht hilfts weiter ;-)

Bernhard

[bernhard]

Hallo,

Mit der Version von heute Mittag (Rev. 1319) kommen jetzt richtige
Temperaturen

tempHigh 75 2012-03-06 15:34:02
tempLow 70 2012-03-06 15:34:02
temperature 11.75 2012-03-06 15:34:02

Dafür werden die anderen Sensoren/Adapter nicht mehr angelegt, die vom
Lauf vorher ins Save-File geschriebenen
Definitionen werden nicht mehr akzepiert.

2012.03.06 15:29:11 3: OWX: Receiving 0xf0
2012.03.06 15:29:11 3: OWX: Sending out 0xe1 0x02 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe3 0xa5
2012.03.06 15:29:11 3: OWX: Receiving 0x83 0x00 0x8a 0x22 0xa2 0x28
0x0a 0x00 0x22 0x00 0x00 0x00 0x00 0x00 0x88 0x22
2012.03.06 15:29:11 1: define: OWID: OWX_22_EEC11A000000 ID
EEC11A000000 invalid, specify a 12 digit value
2012.03.06 15:29:11 3: Unknown attribute IODev, choose one of room

comment alias icon webCmd eventMap or use attr global userattr IODev

2012.03.06 15:29:11 0: Strange call for typeless OWX_22_EEC11A000000:
AttrFn
2012.03.06 15:29:11 1: define: OWID: OWX_22_69A31A000000 ID
69A31A000000 invalid, specify a 12 digit value
2012.03.06 15:29:11 3: Unknown attribute IODev, choose one of room

comment alias icon webCmd eventMap or use attr global userattr IODev

2012.03.06 15:29:11 0: Strange call for typeless OWX_22_69A31A000000:
AttrFn
2012.03.06 15:29:12 1: define: OWID: OWX_09_5B6D03050000 ID
5B6D03050000 invalid, specify a 12 digit value
2012.03.06 15:29:12 3: Unknown attribute IODev, choose one of room

comment alias icon webCmd eventMap or use attr global userattr IODev

2012.03.06 15:29:12 0: Strange call for typeless OWX_09_5B6D03050000:
AttrFn
2012.03.06 15:29:12 1: OWX: 1-Wire devices found
(OWX_10_F86971010800,OWX_10_D6C871010800,OWX_10_AE0F3F010800,OWX_10_ED3560010800,OWX_10_879471010800,OWX_10_67814C010800,OWX_10_FFBC54010800,OWX_22_EEC11A000000,OWX_22_69A31A000000,OWX_09_5B6D03050000)
2012.03.06 15:29:57 3: OWX: Sending out 0xe3 0xc5
2012.03.06 15:29:57 3: OWX: Receiving 0xcd


Und sowohl in 00_OWX.pm, in fhem.pl und FHEMWEB.pm gibts Fehler
Bernhard

[Prof. Dr. Peter A. Henning]

Ich sage doch, es wird ...

1. 22er Sensoren: Ich muss in der Spezi nachsehen, sollten auf die gleiche Weise abfragbar sein, wie die 20er. Wird dann heute nachmittag noch gefixt.

2. OWID Fehler: Das habe ich in der Tat verschlimmbessert - denn in das define statement muss jetzt die family ID mit hinein - damit der Sensor identifizierbar ist. Werde ich dokumentieren in der Datei.

3. Fehler in FHEMWEB kommen aber nicht von mir - denn das liest nur die Log-Dateien. Könnte ich einen Auszug aus der zugehörigen Log-Datei sehen ?

4. Das Limit für die Abfragezeit kann ich auf 1 Sekunde heruntersetzen, kein Problem.

In 30 Minuten gibt es eine neue Datei.

LG

pah

[Prof. Dr. Peter A. Henning]

Hallo,

es hat jetzt doch eine Stunde gedauert - da kommen immer so diverse Dinge dazwischen in meinem Job...

OK, SVN Revision 1322
- OWTEMP sollte auch mit den 1822 Sensoren zu Recht kommen
- OWID wird jetzt benutzt als "define name FAMILY_ID ROM_ID". Ggf. muss man "alte" fhem.save-Dateien löschen.

Ich habe die Module noch einmal getestet, Fehlermeldung habe ich keine (neueste fhem-Version vom SVN). Wenn noch Fehler auftauchen, bitte die Zeilenangaben der fehlermeldung mitliefern.

LG

pah

[bernhard]

> es hat jetzt doch eine Stunde gedauert - da kommen immer so diverse Dinge
> dazwischen in meinem Job...
>

Man sollte die Jobs abschaffen ;-)
Ich bin in meinen über 30 Jahren Datumsverarbeitungszeit auch nie zur
"Arbeit" gekommen und musste sie dann nachts erledigen ;)

So, zum Test komme ich vermutlich erst heute Nacht wieder, auch wenn
ich Ruheständler bin

Bernhard

[bernhard]

Ja, es scheint zu funktionieren (bis auf 09-er, das schau ich aber
später )

Danke, Bernhard

[Prof. Dr. Peter A. Henning]

09er ist der ID-Chip im 9097.

Kann derzeit nur als "vorhanden" abgefragt werden.

[bernhard]

On 6 Mrz., 19:55, "Prof. Dr. Peter A. Henning"

<prof.dr.peter.a.henn...@gmail.com> wrote:
> 09er ist der ID-Chip im 9097.
>
> Kann derzeit nur als "vorhanden" abgefragt werden.

o.k., Sogar 110°C kommen an :-)

dazu gibts noch eine Warnung aus OWID.pm :
<datum zeit> 1: define: OWID: OWX_09_5B6D03050000 ID 5B6D03050000

invalid, specify a 12 digit value

ein paar Zeilen später

<datum zeit> 0: Strange call for typeless OWX_09_5B6D03050000: AttrFn
Use of uninitialized value in substr at 00_OWX.pm line 525

Bernhard

[appi]

Hallo kollegen
Frage: Wieso serielle 1wire interfaces?
Ich habe 3 Cuno und auch ds9490.
Kann ich die Module einfach auf ein anderes device ändern?

Danke und gruss
Remo

[Prof. Dr. Peter A. Henning]

@bernhard, OK, schau ich an. Mein DS9097-U009 ist im Moment lahmgelegt, versuche gerade zu verstehen, welche meiner Umsteckaktionen ihn gekillt hat. Betreffend Deine Messungen in kurzen Abständen: Warum nicht eine Alarmtemperatur setzen, und nur dann Messungen vornehmen, wenn eines der Devices einen Alarm gemeldet hat ? Das wäre wesentlich performanter, als eine Messung pro Sekunde.

@appi: CUNO mappt die 1-Wire-Sensoren auf ein HomeMatic-Interface. Den DS9490 betreibst Du vermutlich über das One-Wire-Filesystem OWFS.

Die neuen Module hingegen arbeiten direkt auf einer seriellen bzw. USB-Schnittstelle OWX, ohne OWFS und ohne CUNO. Speziell das von mir geschriebene Modul OWTEMP.pm  ist als Ersatz für das bestehende OWTEMP gedacht, denn es arbeitet sowohl mit dem OWFS, als auch mit dem neuen direkten Interface.

Martin Fischer, der Autor des OWFS-Moduls, hat auch andere Module in Betrieb, die über OWFS solche Dinge wie Switches und A/D-Konverter ansteuern. Diese Module hat er aber noch nicht veröffentlicht - sonst hätte ich sie ebenfalls mit den meinen zusammengeworfen.

Mittelfristig ist folgendes geplant: die Sensoren und Aktoren werden jeweils über dezidierte Module angebunden, wie etwa OWTEMP, OWAD, OWID etc. In diesen Modulen sind aber Routinen implementiert, die mit jedem der drei möglichen Interfaces zurecht kommen: CUNO, OWFS oder der direkte Anschluss via Modul OWX. Für die OWFS- und CUNO-Teile fühle ich mich aber nicht zuständig, das würde meine Zeit auch nicht erlauben.

Der langen Rede kurzer Sinn: Wer nur Temperatursensoren betreibt, kann derzeit bereits wählen zwischen der Anbindung via OWFS und dem direkten Anschluss via OWX (oder dem Betrieb an CUNO). Wer einen A/D-Konverter betreiben möchte, kann derzeit nur via OWX anschließen (bis Martin Fischer seine Sachen veröffentlicht hat).

LG

pah

 

[bernhard]

> @bernhard, OK, schau ich an. Mein DS9097-U009 ist im Moment lahmgelegt,
> versuche gerade zu verstehen, welche meiner Umsteckaktionen ihn gekillt
> hat. Betreffend Deine Messungen in kurzen Abständen: Warum nicht eine
> Alarmtemperatur setzen, und nur dann Messungen vornehmen, wenn eines der
> Devices einen Alarm gemeldet hat ? Das wäre wesentlich performanter, als
> eine Messung pro Sekunde.

Danke für den Hinweis. Werde ich angucken.
Bisher habe ich die Sensoren mit LogTemp ausgelesen und protokolliert
und den Rest danach errechnet.

Wie und wann werden die Alarme gemeldet/erkannt? Einfach per notify?

Gruß
Bernhard

[Prof. Dr. Peter A. Henning]

Das ist bisher noch nicht ordentlich implementiert (auch im alten OWFS-Modul nicht ...). Problem ist: Werden die Sensoren parasitär versorgt, oder mit Spannung versehen ? Man müsste mal ausprobieren, ob die parasitär versorgten auch von sich aus das Alarm-Flag setzen ohne dass man sie anstößt.

LG

pah

[bernhard]

> OWFS-Modul nicht ...). Problem ist: Werden die Sensoren parasitär versorgt,
> oder mit Spannung versehen ? Man müsste mal ausprobieren, ob die parasitär

parasitär - ganz im Einklang mit mir ;-)

> versorgten auch von sich aus das Alarm-Flag setzen ohne dass man sie
> anstößt.

kann ich dazu etwas beitragen?




Bernhard

[appi]

danke pah für die Erläuterungen. Das Ziel, die Zusammenführung ist
sehr spannend.
Ich werde abwarten und weiterlesen.

besten dank

[bernhard]

So, inhaltlich hatte ich bisher nicht überprüft, einfach die Daten so
genommen, wie waren - (in die Irre geführt, weil ein Sensor
tatsächlich entrsprechende Werte "sehen" könnte").

Die 22-er sensoren (die anderen habe ich noch nicht angesehen) liefern
falsche Werte - vermutlich 1 Bit falsch ausgewertet.
Beispiel.1. Sensor zeigt 118,x °C und pendelt etwas , tatsächliche
Temp um 18°C - aber jetzt nichzt annehmen, dass Komma falsch gesetzt.
2. Sensor läuft bei steigender Temperatur Rückwärts, hat auch kein
Problem mit Über-/Unterläufen (128) und zählt einfach weiter.
Tatsächliche Temperatur im Bereich von ca. 35 ..... 90°C

Es gibt auch irgendwo im Sensor etwas, das erkennen lässt, dass der
normale Messbereich nicht ausreicht und dann längere Wandlungszeiten
benötigt.

Die 10-er-Sensoren schau ich mir noch extra an.

Bernhard

[Prof. Dr. Peter A. Henning]

OK, kann sein, muss ich überprüfen - möglicherweise ein anderer Algorithmus bei den 22er Sensoren. Da ich die selbst nicht benutze, habe ich natürlich gehofft, dass sie auch dieselben Bits liefern wie die 10er. Ist dann aber kein großer Akt, das im Modul einzubauen.

Die 10er sind natürlich geprüft, laufen astrein.

Das Problem mit dem nicht erkannten 09er ist gefixt - da war noch ein logischer Fehler bei der Unterscheidung zwischen Groß- und Kleinschreibung.

[Prof. Dr. Peter A. Henning]

OK, ist gefixt und schon im SVN.

DS1822 hat die gleiche Einteilung des Temperatur-Registers wie der DS18B20 - und mit dem habe ich es getestet.

Damit sind Tests gelaufen mit DS2502, DS18S20, DS18B20, DS2450.

Noch nicht implementiert beim Temperaturmodul: verringerte Auflösung von weniger als 12 Bit. Außerdem werde ich noch ein regelmäßiges Alarm-Polling in OWX.pm einbauen.

LG

pah

[bernhard]

Klasse, jetzt scheint es zu stimmen.


Schön - auch wenn es unverschämt scheint - wenn die Werte jetzt noch
in der Oberfläche auftauchen würden - neben Alarmed ....

Danke.
Bernhard

[Prof. Dr. Peter A. Henning]

Stimmte leider noch nicht ganz - ich hatte nun für die 10er Sensoren noch einen Fehler eingebaut.

"In der Oberfläche" bedeutet hier, in der $hash->{STATE}-Variablen.

Das muss ich erst noch etwas abwägen - denn eigentlich sollte diese den internen Zustand des Sensors widersprigeln. Macht sie aber in vielen anderen FHEM-Modulen auch nicht.

Dazu schwebt mir eher eine frei konfigurierbare Fassung vor, bei der jeder selbst bestimmen kann, was in der STATE-Variablen steht.

LG

pah

[bernhard]

wäre ja schon die Komfort-Version ;)

Bernhard

[B50one]

Seit geraumer Zeit verwende ich den 1Wirebus unter OWFS.
Habe heute einmal versucht meine Temperaturfühler unter
der aktuellen 21_OWTEMP.pm von Peter A. Henning in Betrieb
zu nehmen, fruchtet bei mir leider nicht. Nach Austausch
der Datei von Martin Fischer mit der von Peter A. Henning
kommt es folgender Hinweis ins LOG:

OWTEMP: Parameter [alarminterval] is obsolete now - must be set with I/
O-Device

So wie ich es lesen konnte, kann bei Austausch der beiden Dateien
das OWFS weiter genutzt werden. Hatte die Family ID der alte
Datei von Martin Fischer folgender Maßen angepasst.

"family" => "28",

Habe es auch mit dem neuen Modul 00_OWX.pm versucht, mein Adapter
wird aber nicht initialisiert.

Hier ein Auszug aus meiner FHEM.cfg

define DS9097 OWFS 127.0.0.1:4304 DS9097
attr DS9097 room 1Wire
attr DS9097 temp-scale C

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc.


Was mache ich falsch?

Wie wird der Adapter unter dem neuen Modul 00_OWX.pm richtig
initialisiert?

Nutze übrigens folgenden Adapter: http://www.fuchs-shop.com/de/shop/17/1/13372210/


MfG

Klaus

[Prof. Dr. Peter A. Henning]

Guten Morgen.

Wie bereits einen Post vorher mitgeteilt,

hatte ich beim letzten Hochladen einen Fehler eingebaut - die 10er-Devices wurden nicht erkannt.

Das ist inzwischen gefixt - die aktuellen Module erkennen die Families 09, 10, 20,22 und 28.

Außerdem habe ich etwas an dem Thema "Einheiten", "Alarme"  und "Temperaturskalen" getan - so etwa werden jetzt Alarmzustände der Sensoren sehr schön im STATE angezeigt.

Nun zur Lösung des o.a. Problems:

1. Offenbar hast Du zum Testen nicht mein OWTEMP/OWX der Version 1.07 (oder später) benutzt. Die 28er Sensoren haben eine andere Speicherorganisation als die 10er - und damit nutzt es gar nichts, im Modul von Hand die Family-ID auf 28 zu setzen. Das ist aber in den Versionen ab 1.07 gefixt - nutze bitte die aktuelle Version 1.08, darin sollte das einfach per Austausch von 21_OWTEMP.pm funktionieren.

2. Das "alarminterval" lässt sich zwar in dem alten Modul von Martin Fischer definieren - das ist aber auch Alles. Da das Auslesen der Alarm-Flags nicht "teurer" ist, als die Temperaturabfrage, wird das in meinem Modul gleich richtig miterledigt - der Parameter alarminterval wird einfach ignoriert.

3. Abgesehen davon, dass Dein Adapter kein DS9097 ist, sollten die cfg-Zeile

define DS9097 OWX /dev/ttyUSB0 300
attr DS9097 room 1Wire

das Gewünschte liefern. Falls nicht: Es könnte sei, dass FHEM wegen des Attributs temp-scale aussteigt. Das habe ich nämlich komplett herausgeworfen, weil eine Temperaturskala nicht zum Interface, sondern zum Sensor gehört.

Eine Bitte noch: Ich würde gerne den entsprechenden Abschnitt der Log-Datei sehen, daraus sollte mehr ersichtlich sein.

LG

pah

[B50one]

Hier meine aktuellen Erfahrungswerte.

1.

define DS9097 OWFS 127.0.0.1:4304 DS9097
attr DS9097 room 1Wire

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc.

Alle OK.

2. wie 1. jedoch 21_OWTEMP.pm vom 13.03.2012 06:43

define DS9097 OWFS 127.0.0.1:4304 DS9097
attr DS9097 room 1Wire

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc...

Auszug LOG

2012.03.13 14:39:58 2: FHEMWEB port 8083 opened
2012.03.13 14:39:58 2: FHEMWEB port 8084 opened
2012.03.13 14:39:58 3: Opening CUL device /dev/ttyACM0
2012.03.13 14:39:58 3: CUL device opened
2012.03.13 14:39:59 3: OWFS opening OWFS device 127.0.0.1:4304
2012.03.13 14:39:59 3: OWFS opened 127.0.0.1:4304 for DS9097
2012.03.13 14:39:59 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

Kein Start des FHEM

3.

define DS9097 OWX /dev/ttyUSB0 300
attr DS9097 room 1Wire

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc...

Auszug LOG

2012.03.13 14:49:48 2: FHEMWEB port 8083 opened
2012.03.13 14:49:48 2: FHEMWEB port 8084 opened
2012.03.13 14:49:48 3: Opening CUL device /dev/ttyACM0
2012.03.13 14:49:48 3: CUL device opened
2012.03.13 14:49:48 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.13 14:49:48 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.13 14:49:48 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.13 14:49:48 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.13 14:49:48 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.13 14:49:48 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.13 14:49:48 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.13 14:49:48 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.13 14:49:48 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.13 14:49:48 3: OWTEMP: Device 1W.T_Zirko defined.
2012.03.13 14:49:50 2: Creating interface definitions...
2012.03.13 14:49:50 0: Server started (version =VERS= from =DATE= ($Id
$), pid 1100)

Start des FHEM, jedoch keine Initialisierung des 1Wireadapter und
damit
auch keine Abfrage der Sensoren.

Hinweis:
Es wurden alle Dateien von heute morgen verwandt.
Laut SYSLOG des Dockstar wird der 1Wireadapter unter Debian als
ttyUSB0 initialisiert

MfG

Klaus

[Prof. Dr. Peter A. Henning]

Hallo,

ist gefixt - aktuelle Version ist im SVN.

1. Im Falle des Einsatzes von 21_OWTEMP.pm mit de altem 20_OWFS.pm war in der Tat noch eine Macke drin - ich habe eine Routine zur Berechnung des CRC-Wertes aufgerufen, die es im OWFS nicht gibt :-((. Dieser Aufruf hat das OWFS.pm gekillt - et voila. Ich habe das gerade noch einmal mit dem OWFS getestet - läuft.

2. Im Falle des Einsatzes von 21_OWTEMP.pm mit 00_OWX.pm liegt der Fehler nicht bei mir. Vermutung: Das OWFS läuft noch, damit wird der USB-Port blockiert und kann vom FHEM nicht geöffnet werden . Bitte also vor dem Start von FHEM mit dem direkten Modul das OWFS abschießen.

LG

pah

[B50one]

Hier ein weiterer Test.

1 - mit OWFS, jedoch mit der 21_OWTEMP.pm vom 13.03.2012 19:21:36

define DS9097 OWFS 127.0.0.1:4304 DS9097
attr DS9097 room 1Wire

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc...

Auszug LOG

2012.03.14 09:55:23 2: FHEMWEB port 8083 opened
2012.03.14 09:55:23 2: FHEMWEB port 8084 opened
2012.03.14 09:55:23 3: Opening CUL device /dev/ttyACM0
2012.03.14 09:55:24 3: CUL device opened
2012.03.14 09:55:24 1: attr global port: Can't open server port at
7072: Address already in use
2012.03.14 09:55:24 3: OWFS opening OWFS device 127.0.0.1:4304
2012.03.14 09:55:29 3: OWFS opened 127.0.0.1:4304 for DS9097
2012.03.14 09:55:29 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 09:55:29 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.14 09:55:29 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 09:55:29 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.14 09:55:29 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 09:55:29 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.14 09:55:29 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 09:55:29 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.14 09:55:29 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 09:55:29 3: OWTEMP: Device 1W.T_Zirko defined.

2 - mit dem Modul OWX jedoch ohne Start des OWFS Servers. Adapter wird
weiterhin nicht installiert.

define DS9097 OWX /dev/ttyUSB0 300
attr DS9097 room 1Wire

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc..

Auszug LOG

2012.03.14 10:03:39 2: FHEMWEB port 8083 opened
2012.03.14 10:03:39 2: FHEMWEB port 8084 opened
2012.03.14 10:03:40 3: Opening CUL device /dev/ttyACM0
2012.03.14 10:03:40 3: CUL device opened
2012.03.14 10:03:40 1: attr global port: Can't open server port at
7072: Address already in use
2012.03.14 10:03:40 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 10:03:40 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.14 10:03:40 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 10:03:40 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.14 10:03:41 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 10:03:41 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.14 10:03:41 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 10:03:41 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.14 10:03:41 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 10:03:41 3: OWTEMP: Device 1W.T_Zirko defined.

2012.03.14 10:08:40 1: OWX: Reset called with unknown interface
2012.03.14 10:08:40 1: OWX: Block called with unknown interface
2012.03.14 10:08:40 1: OWX: Reset called with unknown interface
2012.03.14 10:08:40 1: OWX: Block called with unknown interface
2012.03.14 10:08:41 1: OWX: Reset called with unknown interface
2012.03.14 10:08:41 1: OWX: Block called with unknown interface
2012.03.14 10:08:41 1: OWX: Reset called with unknown interface
2012.03.14 10:08:41 1: OWX: Block called with unknown interface
2012.03.14 10:08:41 1: OWX: Reset called with unknown interface
2012.03.14 10:08:41 1: OWX: Block called with unknown interface

2012.03.14 10:38:40 1: OWX: Reset called with unknown interface
2012.03.14 10:38:40 1: OWX: Block called with unknown interface
2012.03.14 10:38:40 1: OWX: Reset called with unknown interface
2012.03.14 10:38:40 1: OWX: Block called with unknown interface
2012.03.14 10:38:41 1: OWX: Reset called with unknown interface
2012.03.14 10:38:41 1: OWX: Block called with unknown interface
2012.03.14 10:38:41 1: OWX: Reset called with unknown interface
2012.03.14 10:38:41 1: OWX: Block called with unknown interface
2012.03.14 10:38:41 1: OWX: Reset called with unknown interface
2012.03.14 10:38:41 1: OWX: Block called with unknown interface


Gruß Klaus

[Prof. Dr. Peter A. Henning]

Hallo,

na, damit sind wir doch schon weiter.

1. Die Fehlermeldung

2012.03.14 10:03:40 1: attr global port: Can't open server port at
7072: Address already in use

hat gar nicht smit 1-Wire zu tun. Sie kommt nur zu Stande, wenn schon eine  Instanz von FHEM läuft - der laufende FHEM-Server belegt also den Port 7072 schon und das System kann das natürlich mit der neuen Programminstanz nicht ebenfalls machen. Also bitte den ersten FHEM-Server erst abschießen.

2. Die Meldung, dass "alarminterval" obsolet ist, hat keine Bedeutung - ist nur eine Warnung, die Thermometer sollten trotzdem funktionieren. Im oben genannten Testfall "1" - d.h. mit OWFS - sollten also nach 5 Minuten (das ist das engestellte Abfrageintervall) die korrekten Temperaturen angezeigt werden. Es kann aber sein, dass das wegen des noch laufenden zweiten FHEM nicht gut tut, also bitte erst das erste Problem beheben.

3. Der zweite Testfall ist auch verständlich. Denn bei blockiertem Port 7072 steigt der FHEM-Server aus und kommt gar nicht dazu, das Modul OWX.pm zu initialisieren. Denn dieses wird entwedert den USB-Port öffnen können. Dann sieht das - und zwar bei mir korrekt mit genau den von Dir genannten Zeilen im cfg wie folgt aus:

2012.03.13 20:12:33 2: Telnet port 7072 opened
2012.03.13 20:12:33 2: FHEMWEB port 8083 opened
2012.03.13 20:12:33 2: FHEMWEB port 8084 opened
2012.03.13 20:12:33 3: OWX: opened device /dev/ttyUSB0
2012.03.13 20:12:34 1: OWX: 1-Wire bus master DS2480 detected for the first time
2012.03.13 20:12:34 1: OWTEMP: Parameter [alarminterval] is obsolete now - must be set with I/O-Device
2012.03.13 20:12:34 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.13 20:12:34 3: OWAD:   Device OWX_20_724610000000 defined.
2012.03.13 20:12:34 2: Creating interface definitions...
2012.03.13 20:12:34 0: Server started (version 5.2+SVN from 2012-03-04 ($Id: fhem.pl 1313 2012-03-04 12:25:55Z rudolfkoenig $), pid 5148)
2012.03.13 20:12:35 1: OWX: Alarm presence detected
2012.03.13 20:12:41 1: OWX: 1-Wire devices found (OWX_20_724610000000,1W.T_Gartenhaus)

oder es muss eine Fehlermeldung geben, dass OWX den USB-Port nicht öffnen kann. Auch hier es muss erst die "alte" Instanz von FHEM gestoppt werden (damit der Port 7072 frei wird).

LG

pah

[Prof. Dr. Peter A. Henning]

Note added in proof: Welche file permissions hat denn das /dev/ttyUSB0 ?

Bitte mal den Output von ls -l /dev/ttyUSB0 hier posten

LG

pah

[B50one]

Hier der gewünschte Output:

/var/log/fhem$ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Jan 1 1970 /dev/ttyUSB0

FHEM.CFG

define DS9097 OWX /dev/ttyUSB0 300
attr DS9097 room 1Wire

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

Hier der aktuelle Auszug aus der FHEMLOG

2012.03.14 12:31:57 2: Telnet port 7072 opened
2012.03.14 12:31:57 2: FHEMWEB port 8083 opened
2012.03.14 12:31:57 2: FHEMWEB port 8084 opened
2012.03.14 12:31:57 3: Opening CUL device /dev/ttyACM0
2012.03.14 12:31:57 3: CUL device opened
2012.03.14 12:31:58 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 12:31:58 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.14 12:31:58 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 12:31:58 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.14 12:31:58 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 12:31:58 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.14 12:31:58 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 12:31:58 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.14 12:31:58 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 12:31:58 3: OWTEMP: Device 1W.T_Zirko defined.


Hier ein Auszug aus der SYSLOG

Jan 1 01:00:21 debian kernel: [ 14.193716] USB Serial support
registered for FTDI USB Serial Device
Jan 1 01:00:21 debian kernel: [ 14.201041] ftdi_sio 1-1.4:1.0: FTDI
USB Serial Device converter detected
Jan 1 01:00:21 debian kernel: [ 14.208135] usb 1-1.4: Detected
FT232RL
Jan 1 01:00:21 debian kernel: [ 14.211986] usb 1-1.4: Number of
endpoints 2
Jan 1 01:00:21 debian kernel: [ 14.216339] usb 1-1.4: Endpoint 1
MaxPacketSize 64
Jan 1 01:00:21 debian kernel: [ 14.221151] usb 1-1.4: Endpoint 2
MaxPacketSize 64
Jan 1 01:00:21 debian kernel: [ 14.225981] usb 1-1.4: Setting
MaxPacketSize 64
Jan 1 01:00:21 debian kernel: [ 14.234685] usb 1-1.4: FTDI USB
Serial Device converter now attached to ttyUSB0
Jan 1 01:00:21 debian kernel: [ 14.242124] usbcore: registered new
interface driver ftdi_sio
Jan 1 01:00:21 debian kernel: [ 14.247937] ftdi_sio: v1.5.0:USB
FTDI Serial Converters Driver

Gruß Klaus

[Prof. Dr. Peter A. Henning]

Wird immer besser, damit sollten wir es haben.

Das USB-Device muss natürlich von dem Nutzer beschreibbar sein, der FHEM laufen lässt.

Also bitte als root eingeben: chmod 666 /dev/ttyUSB0

Das sollte zunächst einmal Abhilfe schaffen und das Ding zum Laufen bekommen. Selbstverständlich muss man dann auch die entsprechenden udev-Rules ändern, damit diese Rechteänderung von /dev/ttyUSB0 auch permanent im System verankert wird. Ich selbst wiederum muss klären, warum hier keine Fehlermeldung ausgegeben wird - denn die sollte mindestens im Log vorhanden sein. Aus der Abwesenheit von Bemerkungen zu OWFS schließe ich, dass es damit jetzt läuft - hatte ich also Recht mit meiner Vermutung ?

LG

pah

[B50one]

Nach Änderung der Rechte leider keine Änderung

Habe sogar die Rechte für den Test auf 777 gestellt.

/var$ ls -l /dev/ttyUSB0
crwxrwxrwx 1 root dialout 188, 0 Jan 1 1970 /dev/ttyUSB0

2012.03.14 14:38:25 2: Telnet port 7072 opened
2012.03.14 14:38:25 2: FHEMWEB port 8083 opened
2012.03.14 14:38:25 2: FHEMWEB port 8084 opened
2012.03.14 14:38:25 3: Opening CUL device /dev/ttyACM0
2012.03.14 14:38:25 3: CUL device opened
2012.03.14 14:38:25 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 14:38:25 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.14 14:38:25 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 14:38:25 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.14 14:38:25 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 14:38:25 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.14 14:38:25 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 14:38:25 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.14 14:38:25 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 14:38:25 3: OWTEMP: Device 1W.T_Zirko defined.

MfG

Klaus

[Prof. Dr. Peter A. Henning]

Hm, sehr erstaunlich.

An einer fehlenden Fehlermelsung liegt es auch nicht - sperre ich mein /dev/ttyUSB0,  sieht das so aus:

2012.03.14 21:25:37 2: Telnet port 7072 opened
2012.03.14 21:25:37 2: FHEMWEB port 8083 opened
2012.03.14 21:25:37 2: FHEMWEB port 8084 opened
2012.03.14 21:25:37 1: define: OWX: Can't open /dev/ttyUSB0: Datei oder Verzeichnis nicht gefunden

So soll es auch sein. Das bedeutet aber, dass FHEM niemals bis hierher kommt - denn die einzige Alternative an dieser Stelle wäre die Meldung

2012.03.14 21:30:25 2: Telnet port 7072 opened
2012.03.14 21:30:25 2: FHEMWEB port 8083 opened
2012.03.14 21:30:25 2: FHEMWEB port 8084 opened
2012.03.14 21:30:25 3: OWX: opened device /dev/ttyUSB0

Also forschen wir mal tiefer im System: Du hast oben gepostet:

/var/log/fhem$ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Jan  1  1970 /dev/ttyUSB0

Das kann nicht ganz stimmen, denn hier wird normalerweise der Zeitpunkt des letzten Zugriffs angegeben - in meinem Fall, also gerade jetzt,

Projekte/FHEM> ls -l /dev/ttyUSB*
crw-rw-rw- 1 root dialout 188, 0 14. Mär 21:31 /dev/ttyUSB0

In Deinem Post steht aber das Standard-Unix-Datum 1. Januar 1970, auf das Device wurde also niemals zugegriffen

Ich sehe mit Erstaunen, dass der Dockstar auch im Syslog dieses Datum verwendet.

Mal sehen, ob wir noch mehr Informationen sammeln können. Kann man bitte mal einen Test machen ohne eingesteckten CUL ? Bei mir kommen die beiden sich gar nicht ins Gehege - weder auf einem PC-Server, noch auf meiner Fritzbox. Hier aber wundert mich ,dass FHEM überhaupt gar nicht versucht, den USB-Prt zu öffnen.

LG

pah

[B50one]

Das Datum 1. Jan 1970 ist das Startdatum bevor ein Update mit einem
NTP Server erfolgt.
Das würde ja bedeuten, dass kein Zugriff seit der Initialisierung beim
Hochfahren des Dockstar
auf das ttyUSB0 erfolgte.

Hier der LOG Auszug ohne CUL.

2012.03.14 21:54:20 2: FHEMWEB port 8083 opened
2012.03.14 21:54:20 2: FHEMWEB port 8084 opened
2012.03.14 21:54:20 3: Opening CUL device /dev/ttyACM0
2012.03.14 21:54:20 3: Can't open /dev/ttyACM0: No such file or
directory
2012.03.14 21:54:20 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 21:54:20 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.14 21:54:20 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 21:54:20 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.14 21:54:20 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 21:54:20 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.14 21:54:20 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 21:54:20 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.14 21:54:20 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.14 21:54:20 3: OWTEMP: Device 1W.T_Zirko defined.

MfG

Klaus

[Prof. Dr. Peter A. Henning]

Hallo,

Am Mittwoch, 14. März 2012 22:05:23 UTC+1 schrieb B50one:

Das Datum 1. Jan 1970 ist das Startdatum bevor ein Update mit einem
NTP Server erfolgt.  

Das würde ja bedeuten, dass kein Zugriff seit der Initialisierung beim
Hochfahren des Dockstar
auf das ttyUSB0 erfolgte.

So sieht das aus, ja. Schau doch zum Vergleich mal ls -l /dev/ttyACM0 an (natürlich mit eingestecktem CUL).

Warum, so stellen sich die Fachleute also die Frage, liest der FHEM nicht einmal das 00_OWX.pm ein ?

Was sagt denn der Befehl cat /proc/tty/driver/usbserial ?

LG

pah

 

[B50one]

Hier die beiden Ausgaben

/var/log$ ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Mar 14 22:15 /dev/ttyACM0

/var/log$ cat /proc/tty/driver/usbserial
usbserinfo:1.0 driver:2.0
0: module:ftdi_sio name:"FTDI USB Serial Device" vendor:0403 product:
6001 num_ports:1 port:1 path:usb-orion-ehci.0-1.4

MfG

Klaus

[Prof. Dr. Peter A. Henning]

OK, so far, so good: Treiber läuft - aber Port wird nie angesprochen ...

Sonst würde ja auch FHEM eine der beiden oben genannten Fehlermeldungen ausspucken.

Was sagt FHEM denn, wenn der Loglevel auf 5 hochgesetzt wird ?

LG

pah

[B50one]

Hier der gewünschte Auszug aus der LOG Datei mit Level 5

2012.03.15 09:40:49 5: Cmd: >attr global VIEW_CSS<
2012.03.15 09:40:49 3: Unknown attribute VIEW_CSS, choose one of room
comment alias archivecmd allowfrom apiversion archivedir configfile
lastinclude logfile modpath nrarchive pidfilename port statefile title
userattr verbose:1,2,3,4,5 mseclog version nofork logdir holiday2we
autoload_undefined_devices dupTimeout latitude longitude backupdir
fp_Erdgeschoss eventMap or use attr global userattr VIEW_CSS
2012.03.15 09:40:49 5: Cmd: >attr global autoload_undefined_devices 1<
2012.03.15 09:40:49 5: Cmd: >attr global logfile /var/log/fhem/fhem-%Y-
%m.log<
2012.03.15 09:40:49 5: Cmd: >attr global modpath /usr/share/fhem<
2012.03.15 09:40:49 5: Loading /usr/share/fhem/FHEM/99_JsonList.pm
2012.03.15 09:40:49 5: Loading /usr/share/fhem/FHEM/99_SUNRISE_EL.pm
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/99_Utils.pm
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/99_XmlList.pm
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/99_marte.pm
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/99_updatefhem.pm
2012.03.15 09:40:50 5: Cmd: >attr global port 7072 global<
2012.03.15 09:40:50 2: Telnet port 7072 opened
2012.03.15 09:40:50 5: Cmd: >attr global statefile /var/log/fhem/
fhem.save<
2012.03.15 09:40:50 5: Cmd: >attr global userattr fp_Erdgeschoss
fp_Keller fp_Obergeschoss fp_Wetter icon webCmd<
2012.03.15 09:40:50 5: Cmd: >attr global verbose 5<
2012.03.15 09:40:50 5: Cmd: >define WEB FHEMWEB 8083 global<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/01_FHEMWEB.pm
2012.03.15 09:40:50 2: FHEMWEB port 8083 opened
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: Cmd: >attr WEB plotmode SVG<
2012.03.15 09:40:50 5: Cmd: >attr WEB plotsize 800,160<
2012.03.15 09:40:50 5: Cmd: >attr WEB stylesheetPrefix dark<
2012.03.15 09:40:50 5: Cmd: >define WEBS FHEMWEB 8084 global<
2012.03.15 09:40:50 2: FHEMWEB port 8084 opened
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: Cmd: >attr WEBS smallscreen 1<
2012.03.15 09:40:50 5: Cmd: >define autocreate autocreate<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/98_autocreate.pm
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: Cmd: >attr autocreate autosave 1<
2012.03.15 09:40:50 5: Cmd: >attr autocreate device_room %TYPE 1<
2012.03.15 09:40:50 5: Cmd: >attr autocreate filelog /var/log/fhem/
%NAME-%Y.log 1<
2012.03.15 09:40:50 5: Cmd: >attr autocreate weblink 1<
2012.03.15 09:40:50 5: Cmd: >attr autocreate weblink_room Plots 1<
2012.03.15 09:40:50 5: Cmd: >define CUL CUL /dev/ttyACM0 1f00<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/00_CUL.pm
2012.03.15 09:40:50 3: Opening CUL device /dev/ttyACM0
2012.03.15 09:40:50 3: CUL device opened
2012.03.15 09:40:50 5: SW: V
2012.03.15 09:40:50 5: CUL/RAW (ReadAnswer): V 1.42 CUL868

2012.03.15 09:40:50 5: SW: X21
2012.03.15 09:40:50 5: SW: T01
2012.03.15 09:40:50 5: CUL/RAW (ReadAnswer): 1F00

2012.03.15 09:40:50 5: GOT CUL fhtid: 1F00
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >attr CUL room CUL<
2012.03.15 09:40:50 5: Cmd: >define Logfile FileLog /var/log/fhem/fhem-
%Y-%m.log fakelog<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/92_FileLog.pm
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >attr Logfile room CUL<
2012.03.15 09:40:50 5: Cmd: >define Erdgeschoss FLOORPLAN<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/95_FLOORPLAN.pm
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >attr Erdgeschoss commandfield 1<
2012.03.15 09:40:50 5: Cmd: >attr Erdgeschoss fp_arrange 1<
2012.03.15 09:40:50 5: Cmd: >define Obergeschoss FLOORPLAN<
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >attr Obergeschoss commandfield 1<
2012.03.15 09:40:50 5: Cmd: >attr Obergeschoss fp_arrange 1<
2012.03.15 09:40:50 5: Cmd: >define Keller FLOORPLAN<
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >attr Keller commandfield 1<
2012.03.15 09:40:50 5: Cmd: >attr Keller fp_arrange 1<
2012.03.15 09:40:50 5: Cmd: >define Wetter FLOORPLAN<
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >attr Wetter commandfield 1<
2012.03.15 09:40:50 5: Cmd: >attr Wetter fp_arrange 1<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/98_weblink.pm
2012.03.15 09:40:50 5: Triggering global (1 changes)
2012.03.15 09:40:50 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:50 5: global trigger: Checking WEB for notify
2012.03.15 09:40:50 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:50 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:50 5: Cmd: >define DS9097 OWX /dev/ttyUSB0 300<
2012.03.15 09:40:50 5: Loading /usr/share/fhem/FHEM/00_OWX.pm
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr DS9097 room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define 1W.T_Gartenhaus OWTEMP
B75EB4020000 300 180<
2012.03.15 09:40:51 5: Loading /usr/share/fhem/FHEM/21_OWTEMP.pm
2012.03.15 09:40:51 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 09:40:51 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Gartenhaus fp_Erdgeschoss
390,845,1,Gartenhaus<
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Gartenhaus room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define FileLog_1W.T_Gartenhaus FileLog /
var/log/fhem/1W.T_Gartenhaus-%Y.log 1W.T_Gartenhaus<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Gartenhaus logtype
hms:Temp,text<
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Gartenhaus room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define weblink_1W.T_Gartenhaus weblink
fileplot FileLog_1W.T_Gartenhaus:hms:CURRENT<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Gartenhaus label "1W T
Gartenhaus Min $data{min1}, Max $data{max1}, Last $data{currval1}"<
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Gartenhaus room .
1Wire_Temp<
2012.03.15 09:40:51 5: Cmd: >define 1W.T_Dach OWTEMP 6EE8B5020000 300
180<
2012.03.15 09:40:51 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 09:40:51 3: OWTEMP: Device 1W.T_Dach defined.
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Dach room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define FileLog_1W.T_Dach FileLog /var/log/
fhem/1W.T_Dach-%Y.log 1W.T_Dach<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Dach logtype
hms:Temp,text<
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Dach room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define weblink_1W.T_Dach weblink fileplot
FileLog_1W.T_Dach:hms:CURRENT<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Dach label "1W Dach Min
$data{min1}, Max $data{max1}, Last $data{currval1}"<
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Dach room .1Wire_Temp<
2012.03.15 09:40:51 5: Cmd: >define 1W.T_Garage OWTEMP AAD2B5020000
300 180<
2012.03.15 09:40:51 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 09:40:51 3: OWTEMP: Device 1W.T_Garage defined.
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Garage fp_Erdgeschoss
320,355,1,Garage<
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Garage room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define FileLog_1W.T_Garage FileLog /var/
log/fhem/1W.T_Garage-%Y.log 1W.T_Garage<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Garage logtype
hms:Temp,text<
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Garage room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define weblink_1W.T_Garage weblink
fileplot FileLog_1W.T_Garage:hms:CURRENT<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Garage label "1W Garage
Min $data{min1}, Max $data{max1}, Last $data{currval1}"<
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Garage room .
1Wire_Temp<
2012.03.15 09:40:51 5: Cmd: >define 1W.T_Wasser OWTEMP C37ACC020000
300 180<
2012.03.15 09:40:51 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 09:40:51 3: OWTEMP: Device 1W.T_Wasser defined.
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Wasser fp_Obergeschoss
615,705,1,Wasser<
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Wasser room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define FileLog_1W.T_Wasser FileLog /var/
log/fhem/1W.T_Wasser-%Y.log 1W.T_Wasser<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Wasser logtype
hms:Temp,text<
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Wasser room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define weblink_1W.T_Wasser weblink
fileplot FileLog_1W.T_Wasser:hms:CURRENT<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Wasser
for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Wasser label
"1W_Aufbereitung Min $data{min1}, Max $data{max1}, Last
$data{currval1}"<
2012.03.15 09:40:51 5: Cmd: >attr weblink_1W.T_Wasser room .
1Wire_Wasser<
2012.03.15 09:40:51 5: Cmd: >define 1W.T_Zirko OWTEMP E87DCC020000 300
180<
2012.03.15 09:40:51 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 09:40:51 3: OWTEMP: Device 1W.T_Zirko defined.
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Wasser
for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Zirko fp_Obergeschoss
660,720,1,Zirkulation<
2012.03.15 09:40:51 5: Cmd: >attr 1W.T_Zirko room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define FileLog_1W.T_Zirko FileLog /var/
log/fhem/1W.T_Zirko-%Y.log 1W.T_Zirko<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Wasser
for notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Zirko logtype
hms:Temp,text<
2012.03.15 09:40:51 5: Cmd: >attr FileLog_1W.T_Zirko room 1Wire<
2012.03.15 09:40:51 5: Cmd: >define weblink_1W.T_Zirko weblink
fileplot FileLog_1W.T_Zirko:hms:CURRENT<
2012.03.15 09:40:51 5: Triggering global (1 changes)
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Dach for
notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Garage
for notify
2012.03.15 09:40:51 5: global trigger: Checking
FileLog_1W.T_Gartenhaus for notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Wasser
for notify
2012.03.15 09:40:51 5: global trigger: Checking FileLog_1W.T_Zirko for
notify
2012.03.15 09:40:51 5: global trigger: Checking Logfile for notify
2012.03.15 09:40:51 5: global trigger: Checking WEB for notify
2012.03.15 09:40:51 5: global trigger: Checking WEBS for notify
2012.03.15 09:40:51 5: global trigger: Checking autocreate for notify

Gruß Klaus

[Prof. Dr. Peter A. Henning]

Damit ist alles klar - darauf hätte ich ehrlich gesagt auch eher kommen können, sorry für den unnötigen Aufwand.

Du hast in der cfg-Datei stehen:

define DS9097 OWX /dev/ttyUSB0 300

Zum Modul OWX gehört aber gar keine Intervallangabe in der "define"-Zeile !

Ich habe aus irgendeinem Grund (frag mich mal ...) in der gegenwärtigen Version von 00_OWX.pm die Abfrage der Parameteranzahl aus der cfg-Datei intolerant gestaltet - und bisher keine Fehlermeldung implementiert. Das liegt daran, dass die ganze "Alarmiererei" derzeit noch eine Baustelle ist.

Na, und so testet OWX.pm, ob die Parameterzahl drei ist (ist sie in dem Fall nicht, sondern vier) - und verabschiedet sich lautlos :-((.

Konsequenz: Das sollte bei Dir alles laufen, wenn Du einfach die "300" in der define-Zeile für OWX löscht.

Und ich werde dieses in der OWX.pm-Datei toleranter bzw. mit Fehlermeldung gestalten.

LG

pah

[B50one]

Das war es wohl. Sieht gut aus ;-)

Hier der letzte Auszug aus der LOG Datei.

2012.03.15 14:16:15 1: OWX: 1-Wire bus master DS2480 re-detected
2012.03.15 14:16:15 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 14:16:15 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 14:16:15 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 14:16:15 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 14:16:15 1: OWTEMP: Parameter [alarminterval] is obsolete

now - must be set with I/O-Device

2012.03.15 14:16:16 0: Server started (version =VERS= from =DATE= ($Id
$), pid 694)
2012.03.15 14:16:25 1: OWX: Deleting unused 1-Wire device 1W.T_Dach of
type OWTEMP
2012.03.15 14:16:25 1: OWX: Deleting unused 1-Wire device 1W.T_Garage
of type OWTEMP
2012.03.15 14:16:25 1: OWX: Deleting unused 1-Wire device
1W.T_Gartenhaus of type OWTEMP
2012.03.15 14:16:25 1: OWX: Deleting unused 1-Wire device 1W.T_Wasser
of type OWTEMP
2012.03.15 14:16:25 1: OWX: Deleting unused 1-Wire device 1W.T_Zirko
of type OWTEMP
2012.03.15 14:16:25 1: OWX: 1-Wire devices found
(OWX_28_E87DCC020000,OWX_28_AAD2B5020000,OWX_28_6EE8B5020000,OWX_28_C37ACC020000,OWX_28_B75EB4020000,OWX_01_06350E140000)


Gruß Klaus

[Prof. Dr. Peter A. Henning]

Na ja, mal sehen.

- Gibt es auch anständige Temperaturen von den Devices ?

- Wieso werden die _vordefinierten_ wie Devices 1W.T_Zirko gelöscht ? Das passiert nur, wenn OWX sie nicht in seiner Liste findet - gerade das erste Device unter der Meldung 1-Wire devices found ist aber OWX_28_E87DCC020000, das sollte also erkannt werden und 1W.T_Zirko eben nicht gelöscht werden.

OK, ich schau mir das mal an.

LG

pah

[Prof. Dr. Peter A. Henning]

So, auch das ist geklärt:

OWX.pm macht eine automatische Suche aller 1-Wire devices, die angeschlossen sind (diese Suche kannman übrigens jederzeit später neu initiieren, indem man get <Name des Adapters> devices in die FHEM-Kommandozeile eingibt).

Dabei findet er das Gerät 28.E87DCC020000 - also einen DS18B20.

In der Definition steht aber nur define 1W.T_Zirko OWTEMP E87DCC020000.

OWX nimmt also das einfachste OWTEMP-Gerät an, einen DS18S20 mit der Family id 10. Da aber

28.E87DCC020000 ungleich 10.E87DCC020000

ist, findet er das nichtauf dem Bus. Erzeugt demnach ein neues Gerät mit dem FHEM-Namen OWX_28_E87DCC020000 und löscht dafür das "alte" 1W.T_Zirko.

Abhilfe: Die define-Zeile abändern in

define 1W.T_Zirko OWTEMP DS18B20 E87DCC020000

In der nächsten Ausgabe von OWX.pm werde ich dafür sorgen, dass diese Family ID auch dann korrigiert wird, wenn sie in der define-Zeil enicht explizit angegeben wurde.

LG

pah

[B50one]

Hallo Peter,

erst einmal meinen Dank für Dein Engagement in dieser Sache.

Hier ein Teil der jetzigen Plotdateien. Sieht alles ganz gut aus.

2012-03-15_18:10:49 1W.T_Zirko tempLow 35
2012-03-15_18:11:02 1W.T_Zirko temperature: 35.00 &deg;C
2012-03-15_18:11:04 1W.T_Zirko tempHigh 60
2012-03-15_18:21:04 1W.T_Zirko temperature: 42.88 &deg;C
2012-03-15_18:26:05 1W.T_Zirko temperature: 46.00 &deg;C
2012-03-15_18:35:10 1W.T_Zirko temperature: 50.88 &deg;C
2012-03-15_18:40:11 1W.T_Zirko temperature: 53.00 &deg;C
2012-03-15_18:45:10 1W.T_Zirko temperature: 57.38 &deg;C

2012-03-15_19:30:15 1W.T_Gartenhaus temperature: 10.12 &deg;C
2012-03-15_19:35:14 1W.T_Gartenhaus temperature: 10.00 &deg;C
2012-03-15_19:40:14 1W.T_Gartenhaus temperature: 9.88 &deg;C
2012-03-15_19:45:14 1W.T_Gartenhaus temperature: 9.75 &deg;C
2012-03-15_19:50:14 1W.T_Gartenhaus temperature: 9.62 &deg;C
2012-03-15_19:55:14 1W.T_Gartenhaus temperature: 9.50 &deg;C
2012-03-15_20:00:14 1W.T_Gartenhaus temperature: 9.38 &deg;C
2012-03-15_20:05:14 1W.T_Gartenhaus temperature: 9.25 &deg;C

Leider funktionieren meine grafischen Auswertungen (weblink) nicht
mehr.

Bei der OWFS Variante hatte ich folgende Einträge in der FHEM.cfg

define FileLog_1W.T_Gartenhaus FileLog /var/log/fhem/1W.T_Gartenhaus-
%Y.log 1W.T_Gartenhaus

attr FileLog_1W.T_Gartenhaus logtype hms:Temp,text

attr FileLog_1W.T_Gartenhaus room 1Wire

define weblink_1W.T_Gartenhaus weblink fileplot
FileLog_1W.T_Gartenhaus:hms:CURRENT

attr weblink_1W.T_Gartenhaus label "1W T Gartenhaus Min $data{min1},
Max $data{max1}, Last $data{currval1}"

attr weblink_1W.T_Gartenhaus room .1Wire_Temp

Auszug aus der LOG unter OWFS

2012-01-01_00:07:26 1W.T_Gartenhaus warnings: none
2012-01-01_00:10:27 1W.T_Gartenhaus T: 8.6875 L: 5 H: 26 P: 1 A:
0 W: none
2012-01-01_00:10:27 1W.T_Gartenhaus present: 1
2012-01-01_00:10:27 1W.T_Gartenhaus temperature: 8.6875 (Celsius)
2012-01-01_00:10:27 1W.T_Gartenhaus tempraw: 8.6875
2012-01-01_00:10:27 1W.T_Gartenhaus templow: 5
2012-01-01_00:10:27 1W.T_Gartenhaus temphigh: 26
2012-01-01_00:10:27 1W.T_Gartenhaus warnings: none

Hast Du dahingehend eine Idee. Oder verwende ich nur dei falsche gplot
Datei?

Hier noch eine kleine Anmerkung. In der OWFS Version wurde mir im
Floorplan
alle Daten des 1Wire Device angezeigt. Z.B ob das Alarmbit gesetzt
wurde.
Besteht unter OWX auch diese Möglichkeit?

Gruß Klaus

[Prof. Dr. Peter A. Henning]

So, auch das Problem gelöst.

1. Plots - ganz einfach. Das gegenwärtig verwendete Plotfile hms.gplot enthält die Zeilen


#FileLog 4:T\x3a:0:
#FileLog 6:H\x3a:0:

Es sollen also 2 Kurven geplottet werden (Temperatur und Feuchtigkeit - die zweiteZeile kann man also in diesem Falle löschen oder vergessen, stört nur). Allerdings sucht das Fileplot.pm nach dem String "T:" (: = hexadezimal 3a). Das Modul OWTEMP.pm hingegen gibt aus

temperature: 25.81 °C

Lösung also: einfach in der Datei hms.gplot (besser: einer anders benannten Kopie) statt der beiden obigen Zeilen setzen

#FileLog 4:temperature:0:

2. Floorplan

Kann ich nicht nachvollziehen.Die Alarm-Flags sind als kleine rote Dreiecke (nach unten bzw. oben) Bestandteil der {STATE} Variablen und werden wunderbar im Floorplan angezeigt. Wer diese nicht möchte, kann dem Device mit

attr <devicename> stateAL "string" einen bliebigen String eingeben, der bei "kaltem" Alarm angezeigt wird, im Default "<span style=\"color:red\">&#x25BE;</span>";

attr <devicename> stateAH "string" ist natürlich das Zeichen für "heißen" Alarm, also im Default "<span style=\"color:red\">&#x25B4;</span>".

An dieser Stelle könnte übrigens auch problemlos ein HTML-String stehen, der auf eine Bilddatei verweist - sagen wir, einen Eiszapfen für kalten und eine Flamme für heißen Alarm.

LG

pah

[B50one]

Habe ich soweit verstanden und in Teilen positiv getestet. Danke.

Was mir noch aufgefallen ist. Bei Einstellung tempHigh bzw. tempLow
Werte,
wir kurzfristig ein falscher Temperaturwert dem Device zugeordnet.
Nach einem neuen Abfrageintervall steht allerdings wieder der richtige
Wert im Device.

Siehe Bilder separate Mail.

Gruß Klaus

[Prof. Dr. Peter A. Henning]

OK, dank für den Hinweis.

LG

pah

[zwiebel]

Hallo,

ich hab jetzt mal alle OWX und OWTEMP sachen gelöscht und FHEM zwei mal neu gestartet.
Alles gelöscht und neu angelegt.

define 1wire OWX /dev/ttyUSB1
attr 1wire room 1

define sensor1 OWTEMP DS1820 8A30000800B3
attr sensor1 room 1
define FileLog_sensor1 FileLog /var/media/ftp/fhem/log/sensor1-%Y-%m.log sensor1:.*
attr FileLog_sensor1 room 1

das ist in den logs beim hoch fahren:
2012.03.16 19:29:25 3: OWX: opened device /dev/ttyUSB1
2012.03.16 19:29:26 1: OWX: Passive 1-Wire bus interface DS9097 detected
2012.03.16 19:29:40 1: OWX: Search CRC failed
2012.03.16 19:29:40 1: OWX: 1-Wire devices found ()
2012.03.16 19:30:42 3: OWTEMP: Device sensor1 defined.

das wird aufgezeichnet:

2012-03-16_19:35:50 sensor1 temperature: 18.60 °C
2012-03-16_19:40:50 sensor1 temperature:  9.31 °C
2012-03-16_19:45:50 sensor1 temperature: 22.15 °C
2012-03-16_19:50:50 sensor1 temperature:  0.94 °C
2012-03-16_19:55:50 sensor1 temperature: 37.40 °C
2012-03-16_20:00:50 sensor1 temperature: 33.99 °C

die werte stimmen nicht.

[Prof. Dr. Peter A. Henning]

Sieht so aus wie eine unvollständige Messung.

1. Frage: Warum dauert es mehr als eine Minute bis zur Meldung "sensor 1 defined" ? Irgend ein Hinweis, ob dies korrekt ist ?

2. Frage: Welche Temperaturen werden denn erwartet ?

3. Frage: Was liefert der Sensor, wenn man das Frageintervall (Parameter in der Zeile define sensor1) auf z.B. 45 Sekunden heruntersetzt ?

Meine erste Vermutung: Auf dem Bus ist nicht genügend los, um dem Sensor genügend Spannung für die Temperaturumwandlung zu geben. Das könnte man durch Herabsetzen des Intervalls prüfen.

LG

pah

[zwiebel]

das vermute ich auch.

1.  hab erst nach einer mute den sensor definiert.
2. 19.5 - 21.5 etwa
3.  hab jetzt ein interval von 45 versucht...
   Readings:
     2012-03-17 08:09:13   tempHigh        -110
     2012-03-17 08:09:13   tempLow         -118
     2012-03-17 08:09:13   temperature     9.25

   Readings:
     2012-03-17 08:11:28   tempHigh        119
     2012-03-17 08:11:28   tempLow         119
     2012-03-17 08:11:28   temperature     69.4318181818182

ich werd nicht drum herum kommen und meine schaltung abändern. :(

[B50one]

Ich habe da noch eine kleine Frage in Sachen Notify Abfrage.

Es soll ein Schaltvorgang vorgenommen werden, wenn die eingestellte
Höchsttemperatur
erreicht wurde. Dazu habe ich das Device um das Attribut attr
1W.T_Wasser stateAH "Hot"
erweitert. Im STATE steht dann z.B 48.75 °C Hot

Was muss ich nun in meiner Notify Abfrage einbauen damit der
Schaltvorgang ausgelöst wird?

define Temperatur_Wasser_hot notify 1W.T_Wasser ????? {fhem "set L1
on"}

Leider haben meine Bemühungen mit unterschiedlichen Eintragungen nicht
gefruchtet.


MfG

Klaus

[zwiebel]

Guten Abend,

so -  jetzt habe ich meine Schaltung abgeändert mit einer externen Spannungsversorgung (5V).
Noch nicht gelötet aber mal zusammengesteckt.
Schaltplan_Passives_1-Wire_Interface.png  (oben)

define 1wire OWX /dev/ttyUSB0

list 1wire
Internals:
   ALARMED    no
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0
   INTERFACE  DS9097
   NAME       1wire
   NR         230
   PRESENT    1
   ROM_ID     FF
   STATE      Active
   TYPE       OWX
   followAlarms off
   interval   60
Attributes:
   room       1

FHEM neu gestartet:
2012.03.27 19:12:42 3: OWX: opened device /dev/ttyUSB0
2012.03.27 19:12:43 1: OWX: Passive 1-Wire bus interface DS9097 detected
2012.03.27 19:12:58 1: OWX: Search CRC failed
2012.03.27 19:12:58 1: OWX: 1-Wire devices found ()

FritzBox neu gestartet:
2012.03.27 19:22:31 3: OWX: opened device /dev/ttyUSB0
2012.03.27 19:22:31 1: OWX: Passive 1-Wire bus interface DS9097 detected
2012.03.27 19:22:43 1: OWX: Search CRC failed
2012.03.27 19:22:43 1: OWX: 1-Wire devices found ()

im fhem:
get 1wire devices

OWX: 1-Wire devices found ()
 

in den logs
2012.03.27 19:24:59 1: OWX: Search CRC failed
2012.03.27 19:24:59 1: OWX: 1-Wire devices found ()

fhem wird unter boxusr80 gestartet
crw-rw----    1 boxusr80 root      188,   0 Mar 27 19:35 /dev/ttyUSB0

neuer 1wire DS18s20 wurde auch schon versucht.


vielen dank für die Hilfe. Leider komm ich nicht mehr weiter, bzw mir gehen die Ideen aus woran es noch liegen könnte... :(

[Prof. Dr. Peter A. Henning]

Hallo,

es gibt einen neuen Thread 1-Wire Update - dieser hier ist zu unübersichtlich geworden, also bitte bei dem neuen posten.

Zum Problem: Ich habe die Module (Version 1.10) gerade eben mit genau dieser Schaltung noch einmal laufen lassen - und es funktioniert wunderbar:

2012.03.28 07:31:09 3: OWX: opened device /dev/ttyUSB0
2012.03.28 07:31:10 1: OWX: Trying again to detect an interface, answer was 0x81 0x81 0x17 0x0a 0x5b 0x0f 0x02
2012.03.28 07:31:10 1: OWX: Passive 1-Wire bus interface DS9097 detected
2012.03.28 07:31:10 3: OWAD:   Device OWX_AD defined.
2012.03.28 07:31:10 3: OWTEMP: Device OWXTemp6 defined.
..
2012.03.28 07:31:30 1: OWX: Deleting unused 1-Wire device OWX_AD of type OWAD
2012.03.28 07:31:30 1: OWX: 1-Wire devices found (OWXTemp6)

Der CRC-Fehler deutet auf ein Problem mit der Signalleitung hin.

Folgender Vorschlag für den nächsten Schritt: In der Datei 00_OWX.pm stehen ab ca. Zeile 1424 die folgenden Codelines:

  #loop until through all ROM bytes 0-7 
    my $id_bit     = OWX_TouchBit_9097($hash,1);
    my $cmp_id_bit = OWX_TouchBit_9097($hash,1);
    
    #print "id_bit = $id_bit, cmp_id_bit = $cmp_id_bit\n";
    
    if( ($id_bit == 1) && ($cmp_id_bit == 1) ){
      #print "no devices present at id_bit_number=$id_bit_number \n";
      next;
    }

Ersetz bitte zweimal das "#print" durch ein "Log1," - das schreibt die Ausgaben in das Logfile. Und poste das Logfile nach einem erneuten Startversuch.

LG pah