Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
eigentlich: 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
auchmit 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 damit
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äufliche erwerbbaren
1-Wire-Hardware habe ich bei meiner Sensorik durch 3.5 mm Klinkenstecker
ersetzt. 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 schin
verraten: bei mir liegen derzeit schon 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Uff, die Tippfehler bitte ich zu entschuldigen - sollte jetzt zu schnell
gehen ...
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
temperature" eine Messung initiieren.
Wieso sollen die Temperaturen so oft gemessen werden ?
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ja, es scheint zu funktionieren (bis auf 09-er, das schau ich aber
später )
Danke, Bernhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
09er ist der ID-Chip im 9097.
Kann derzeit nur als "vorhanden" abgefragt werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 6 Mrz., 19:55, "Prof. Dr. Peter A. Henning"
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 :
1: define: OWID: OWX_09_5B6D03050000 ID 5B6D03050000
invalid, specify a 12 digit value
ein paar Zeilen später
0: Strange call for typeless OWX_09_5B6D03050000: AttrFn
Use of uninitialized value in substr at 00_OWX.pm line 525
Bernhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> @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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
danke pah für die Erläuterungen. Das Ziel, die Zusammenführung ist
sehr spannend.
Ich werde abwarten und weiterlesen.
besten dank
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Stimmte leider noch nicht ganz - ich hatt enunfü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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
wäre ja schon die Komfort-Version ;)
Bernhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Morgen.
Wie bereits einen Post vorher mitgeteilt,
hatt 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.
Die Lösung für das oben geschilderte Problem sehe ich auch - poste ich
nachher, muss erst einmal frühstücken .
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Muss ich testen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 °C
2012-03-15_18:11:04 1W.T_Zirko tempHigh 60
2012-03-15_18:21:04 1W.T_Zirko temperature: 42.88 °C
2012-03-15_18:26:05 1W.T_Zirko temperature: 46.00 °C
2012-03-15_18:35:10 1W.T_Zirko temperature: 50.88 °C
2012-03-15_18:40:11 1W.T_Zirko temperature: 53.00 °C
2012-03-15_18:45:10 1W.T_Zirko temperature: 57.38 °C
2012-03-15_19:30:15 1W.T_Gartenhaus temperature: 10.12 °C
2012-03-15_19:35:14 1W.T_Gartenhaus temperature: 10.00 °C
2012-03-15_19:40:14 1W.T_Gartenhaus temperature: 9.88 °C
2012-03-15_19:45:14 1W.T_Gartenhaus temperature: 9.75 °C
2012-03-15_19:50:14 1W.T_Gartenhaus temperature: 9.62 °C
2012-03-15_19:55:14 1W.T_Gartenhaus temperature: 9.50 °C
2012-03-15_20:00:14 1W.T_Gartenhaus temperature: 9.38 °C
2012-03-15_20:05:14 1W.T_Gartenhaus temperature: 9.25 °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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
1. Grafiken:
- Dazu müsste ich wissen, was in der fhem.cfg für das Abfangen der
Log-Einträge steht (also im "define FileLog" Kommando für die Devices). Es
kann sein, dass hier die bisherige regexp über die neuen Ausgaben (mit
ordentlicher Einheit Grad Celsius !) stolpert. Kann man ausprobieren, indem
man mal die Temperaturskala auf Kelvin umstellt (geht ohen Neustart von
FHEM mit dem Attributwert tempScale -> Kelvin)
- Zweitens wäre interessant zu wissen, ob in das Logfile nunmehr wirklich
geschrieben wird - und dann erst kann man nachsehen, ob das plotfile dafür
auch ok ist.
2. Alarm-Flags:
Aber ja. Die Anzeige ist derzeit für das "normale" Webfrontend optimiert -
da sieht man die "kleinen roten Dreiecke", wenn die Alarmflags gesetzt
sind. Das kann man aber per Attribut auf einen beliebigen String
umschießen. Ich müsste wissen, in welcher Weise das Flooplan-Modul die
Variable hash->{STATE} auswertet, dann kann man auch das noch hinbekommen.
Aber heute nicht mehr - habe jetzt 6 Stunden Vorlesung.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 stateAL "string" einen bliebigen String eingeben, der bei
"kaltem" Alarm angezeigt wird, im Default "style=\"color:red\">▾";
attr stateAH "string" ist natürlich das Zeichen für "heißen"
Alarm, also im Default "▴".
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
OK, dank für den Hinweis.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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. :(
Am Samstag, 17. März 2012 05:15:03 UTC+1 schrieb 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
>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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... :(
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com