OWX MAJOR UPDATE

Begonnen von Prof. Dr. Peter Henning, 29 Oktober 2017, 18:52:48

Vorheriges Thema - Nächstes Thema

synaps-o-dan

So, jetzt habe ich noch mal alles (Sensor, OWX und global) auf verbose=5 hochgegreht und eine Temperaturabfrage durchgeführt. Hier die Ergebnisse im log, zunächst synchron (Temperaturwert müsste stimmen):
2018.02.22 19:12:56 5: Cmd: >get Temperatur_Test temperature<
2018.02.22 19:12:56 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.22 19:12:56 5: SW: e3c5
2018.02.22 19:12:56 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.22 19:12:56 1: OWX_SER::Complex sending 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0x44
2018.02.22 19:12:56 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe1 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0x44
2018.02.22 19:12:56 5: SW: e155283fa602040000e144
2018.02.22 19:12:56 4: OWX_SER::Query OWX_EcloOWUSB: 10 of 10 bytes in first attempt and state opened
2018.02.22 19:12:56 1: OWX_SER::Complex receiving 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0x44
2018.02.22 19:12:57 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.22 19:12:57 5: SW: e3c5
2018.02.22 19:12:57 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.22 19:12:57 1: OWX_SER::Complex sending 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.02.22 19:12:57 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe1 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.02.22 19:12:57 5: SW: e155283fa602040000e1beffffffffffffffffff
2018.02.22 19:12:57 4: OWX_SER::Query OWX_EcloOWUSB: 19 of 19 bytes in first attempt and state opened
2018.02.22 19:12:57 1: OWX_SER::Complex receiving 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0xbe 0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49
2018.02.22 19:12:57 1: OWXTHERM_BinValues called for device Temperatur_Test in context getsp with data 0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49
2018.02.22 19:12:57 1: OWXTHERM_BinValues:  Temperatur_Test: no error,  21  0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49
2018.02.22 19:12:57 5: Starting notify loop for Temperatur_Test, 2 event(s), first is temperature: 21
2018.02.22 19:12:57 5: createNotifyHash
2018.02.22 19:12:57 5: End notify loop for Temperatur_Test

Ich sehe hier in der ersten gesendeten Zeile (Zeit: 2018.02.22 19:12:56) ein 0x044.

Jetzt Umschalten auf asynchron, wieder Temperaturreading. Als Ergebnis kommt ein Wert von 85. Hier die Logeinträge:
2018.02.22 19:19:58 4: OWX_Qomplex: Added dev 283FA602040000E1 to queue OWX_EcloOWUSB context=convert
2018.02.22 19:19:58 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.22 19:19:58 5: SW: e3c5
2018.02.22 19:19:58 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.22 19:19:58 1: OWX_SER::Write Sending out 0xe1 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0x44 0xff
2018.02.22 19:19:58 5: SW: e155283fa602040000e144ff
2018.02.22 19:19:58 1:    queue OWX_EcloOWUSB contains 1 entries after insertion
2018.02.22 19:19:58 1:     => 283FA602040000E1 context convert expecting 1 bytes, active
2018.02.22 19:19:58 1: ----------------------------------------------
2018.02.22 19:19:58 1: OWX_Qomplex: Added dev 283FA602040000E1 to queue OWX_EcloOWUSB numread=19
2018.02.22 19:19:58 1:    queue OWX_EcloOWUSB contains 2 entries after insertion
2018.02.22 19:19:58 1:     => 283FA602040000E1 context convert expecting 1 bytes, active
2018.02.22 19:19:58 1:     => 283FA602040000E1 context readsp expecting 19 bytes, waiting
2018.02.22 19:19:58 1: ----------------------------------------------
2018.02.22 19:19:58 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.22 19:19:58 5: SW: e3c5
2018.02.22 19:19:58 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.22 19:19:59 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.22 19:19:59 5: SW: e3c5
2018.02.22 19:19:59 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.22 19:19:59 1: OWX_SER::Write Sending out 0xe1 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.02.22 19:19:59 5: SW: e155283fa602040000e1beffffffffffffffffffffffffffffffffffffff
2018.02.22 19:19:59 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.22 19:19:59 5: SW: e3c5
2018.02.22 19:19:59 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.22 19:19:59 1: OWXTHERM_BinValues called for device Temperatur_Test in context readsp with data 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0xbe 0x50 0x05 0x4b 0x46 0x7f 0xff 0x0c 0x10 0x1c
2018.02.22 19:19:59 1: OWXTHERM_BinValues:  Temperatur_Test: no error,  85  0x50 0x05 0x4b 0x46 0x7f 0xff 0x0c 0x10 0x1c
2018.02.22 19:19:59 5: Starting notify loop for Temperatur_Test, 2 event(s), first is temperature: 85
2018.02.22 19:19:59 5: createNotifyHash
2018.02.22 19:19:59 5: End notify loop for Temperatur_Test

Ich sehe hier wieder bei der Zeit 19:19:58 ein 0x44.
Helfen die logs?
lg
Daniel

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2018, 12:38:11
Nö. Auch im asynchronen Fall wird hier ein Wert vom Sensor zurückgeliefert, mit dem korrekten CRC. Also kein Fehler auf dem Bus, der Sensor antwortet auf die Anfrage korrekt.

Warum also kann der Wert 85 sein ? Höchstens, wenn die Temperaturmessung nicht durchgeführt wurde. Beispielsweise, wenn die Verzögerungszeit für die Messung nicht eingehalten wurde, oder gar kein "convert" = \0x44 gesendet wurde


Bitte mal mit verbose=5 prüfen, ob ca. 1 Sekunde vor der Abfrage irgendwo \0x44 im Log zu finden ist.



LG

pah
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

synaps-o-dan

Hallo Hans-Jürgen,
ich kann Dir zwar bei Deinem Problem nicht helfen, da ich noch viel grundlegendere Probleme lösen muss. Würdest Du mir ein paar Fragen beantworten, die mich interessieren? Ich versuche wie gesagt bislang ohne Erfolg (aber mit Support durch pah), meinen 1wire Bus im asynchronen Modus mit OWX zum Laufen zu bringen.

  • Welche Sensoren (Typen, z.B. DS18B20 oder DS2438 hast Du verbaut?
  • Verschaltung (linear, Stern, gemischt)?
  • Leitungslängen?
  • Besondere Maßnahmen (z.B. Schottky-Diode am Busende)?
Über eine Antwort würde ich mich freuen,
lg
Daniel

Zitat von: Deckoffizier am 21 Februar 2018, 17:54:16
Hallo,

Als Busmaster werkelt bei mir auch ein LinkUSBi.
Habe heute morgen mal probeweise wieder auf asynchron umgestellt und erhalte folgende Warnungen im Log die sonst nicht im synchronen Modus erscheinen.
2018.02.21 08:46:40 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_OWX.pm line 1554.
2018.02.21 08:52:38 1: OWXTHERM_BinValues:  Abgassensor: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.02.21 10:23:14 1: OWXAD_BinValues: context ds2450.getstatus.final    Wettersensor: invalid CRC 0x7f 0x00 0x7f 0x00 0x7f 0x00 0x7f 0x36 0x85 0x00
2018.02.21 11:23:06 1: PERL WARNING: Use of uninitialized value in bitwise and (&) at ./FHEM/00_OWX.pm line 939.

Leider sind meine Kenntnisse nicht ausreichend ob ich weiter nachforschen sollte oder einfach ignorieren und ob ein Zusammenhang mit der Hardware LinkUSB besteht ?

Falls ich lieber ein neues Thema aufmachen sollte und es nicht hierher passt, mache ich dies gern nachträglich.

Anbei ein List vom Busmaster
Internals:
   ALARMED    no
   ASYNCHRONOUS 1
   BUSY       0
   DEF        /dev/ttyUSB0
   DEVS       
   DeviceName /dev/ttyUSB0
   FD         22
   INITDONE   0
   INTERFACE 
   LASTSEND   1519231966.18945
   NAME       OWio1
   NR         254
   PARTIAL   
   PRESENT    0
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   interval   300
   timeout    2
   version    7.05
   DEVHASH:
     OWio1      Busmaster
   QUEUE:
   READINGS:
     2018-02-21 17:52:43   queue           19
     2018-02-17 21:51:12   state           opened
Attributes:
   alias      Busmaster
   asynchronous 1
   comment    Busmaster Gateway
   room       OWX


Gruß
Hans-Jürgen
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

Deckoffizier

Hallo  synaps-o-dan,

zu 1. Sensoren wie  DS18B20 am Pufferspeicher,Heißwasserspeicher diverse Module von tm3d.de  kombiniert für Temp.,Luftfeuchte und Druck sowie ein Modul von dort  für Abgastemp. an meinem Holzvergaser mit Thermoelement.

zu 2. und 3. vom PC(Server für TV und Logitech Media) mit LinkUSBi runter zum Heizraum  mit Netzwerkkabel 10 Meter.
Im Heizraum im extra Verteilerkasten 2 USB 8 fach Verteiler auf Hutschiene mit Push in Klemmen.
Von dort zu den Sensoren mit Leitungslängen von ungefähr jeweils 2 bis 5 Meter.

zu4. besondere Maßnahmen keine...

hmm nur Bauchgefühl LinkUSB ob so das Wahre?
Hatte vorher am PI3 als Busmaster denDS9490R lief Problemlos.
Hatte diesen leider nicht nach nächtelangen Versuchen  am PC zum laufen bekommen.
Anbei OS ist bei mir Linux.

Gruß
Hans-Jürgen

FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Prof. Dr. Peter Henning

Ich verstehe das nicht. Es wird in beiden Fällen eine komplett korrekte Temperaturmessung angestoßen (das ist das 0x44), in einem Fall wird dann nach ca. 1 Sekunde

0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49

und im anderen Fall

0x50 0x05 0x4b 0x46 0x7f 0xff 0x0c 0x10 0x1c

zurückgeliefert. Die "0x50 0x05" entsprechen in der Umrechnung den 85 Grad Celsius, die beiden nächsten Bytes sind die Alarmwerte und 0x7f ist der Inhalt des Konfigurationsregisters. Die Auflösung ist in beiden Fällen gleich (12 Bit), die Messzeit sind 750 ms. Der letzte Wert ist der CRC-Code und damit Garant für eine korrekte Messung.

An der Software kann es auch nicht liegen - denn ich betreibe mehrere DS18B20 an verschiedenen Busmastern im asynchronen Modus ohne irgendeinen solchen Ausreißer.

Kann es sein, dass die Spannungsversorgung nicht stimmt ? Der DS18B10 kann zwar im parasitäten Modus arbeiten, braucht dann aber einen "strong Pullup".

LG

pah






synaps-o-dan

OK danke, das kann es sein. Ich werde der Sache mal auf den Grund gehen, kann mich allerdings erst in einiger Zeit drum kümmern (ab nächster Woche bin ich in China unterwegs). Leider ist bei meinem letzten DS18B20 gerade ein Beinchen im Steckbrett hängen geblieben, daher hat das Testen erst mal ein Ende gefunden. Vielen Dank bis hierhin!
lg
Daniel

Zitat von: Prof. Dr. Peter Henning am 22 Februar 2018, 21:34:32
Ich verstehe das nicht. Es wird in beiden Fällen eine komplett korrekte Temperaturmessung angestoßen (das ist das 0x44), in einem Fall wird dann nach ca. 1 Sekunde

0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49

und im anderen Fall

0x50 0x05 0x4b 0x46 0x7f 0xff 0x0c 0x10 0x1c

zurückgeliefert. Die "0x50 0x05" entsprechen in der Umrechnung den 85 Grad Celsius, die beiden nächsten Bytes sind die Alarmwerte und 0x7f ist der Inhalt des Konfigurationsregisters. Die Auflösung ist in beiden Fällen gleich (12 Bit), die Messzeit sind 750 ms. Der letzte Wert ist der CRC-Code und damit Garant für eine korrekte Messung.

An der Software kann es auch nicht liegen - denn ich betreibe mehrere DS18B20 an verschiedenen Busmastern im asynchronen Modus ohne irgendeinen solchen Ausreißer.

Kann es sein, dass die Spannungsversorgung nicht stimmt ? Der DS18B10 kann zwar im parasitäten Modus arbeiten, braucht dann aber einen "strong Pullup".

LG

pah
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

synaps-o-dan

@pah: Ich befürchte, es liegt an der Stromversorgung bzw. der Verkabelung. Leider habe ich die Verkabelung erstellt, bevor ich auf fhem (und die gute Doku zu 1wire) gestoßen bin. Jetzt liegen bereits einige MS-TH in der Dachdämmung verbaut und messen dort punktuell Temperatur und rel. Luftfeuchtigkeit. Ich komme an diese Sensoren nicht mehr heran. Frage: wird das System robuster als bisher, wenn ich leistungsfähigere Busmaster einsetze? Also so was wie ein HA7net? Gibt es Erfahrungen, welcher der verschiedenen Ethernet-Onewire-Busmaster besonders gut mit suboptimalen Verkabelungen zurecht kommt?
(betreiben würde ich den dann mit einer der Module in fhem, oder ich bastele mit eine Webabfrage)
lg und vielen Dank für eine Tip,
Daniel
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

Prof. Dr. Peter Henning

Wie sieht denn die Verkabelung genau aus ?

Abgesehen davon könnte man, wenn es nur um Temperatur- und Feuchtesensoren geht, problemlos im synchronen Modus bleiben, denn deren Werte ändern sich nicht so schnell.

Ich würde da keinen "leistungsfähigen" Busmaster einsetzen, sondern diesen Teil des Bus einfach mit einem eigenen Busmaster versehen. Der fragt gemütlich die Dinger im Dach ab, ohne dass es zu Kollisionen mit anderen 1-Wire Devices kommt.


Ich betreibe - an einem einzigen Raspberry Pi - 5x USB und  einen Ethernet-Busmaster.


LG

pah


Deckoffizier

Hallo pah,

DANKE  für die Erläuterungen in diesem Thread, die Zusammenhänge hätte ich gerne schon früher mitbekommen.

Habe mal wieder zurück auf synchronen Modus gestellt.
ZitatAbgesehen davon könnte man, wenn es nur um Temperatur- und Feuchtesensoren geht, problemlos im synchronen Modus bleiben, denn deren Werte ändern sich nicht so schnell.
Hmm beim Abgas habe ich schon mal innerhalb von 10 min einen Durchmarsch von 30 Grad bis auf über 200.
Fällt dies noch unter nicht so schnell ?

Aber irgendwas zickt leider immer bei meinem 1Wire.
Im Log vom Abgassensor....
2018.02.24 12:26:19 1: OWXTHERM_BinValues:  Abgassensor: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

Zum Glück macht sich dies nicht im Plot bemerkbar und kann damit leben.

Wenn es gestattet sei, ein kleiner Schwenk vom Abgasrohr zur Brennkammer am Holzvergaser.
Ist es per 1 Wire möglich direkt an der Regelung(Klemmstelle) des Temperaturwiderstands PT1000? muss erst nachsehen, die Werte zu ermitteln abzugreifen.

Mit freundlichen Gruß
Hans-Jürgen




FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Prof. Dr. Peter Henning

Ich habe so etwas hier in Betrieb: Ein DS2450 an einem Ende, ein Pt100 am anderen Ende

https://www.pollin.de/p/bausatz-pt100-messwandler-v2-0-810272

LG

pah

Deckoffizier

Hallo pah,

Messwandler wird das richtige Stichwort sein, bei Temperaturen von über 700 Grad müsste ich nach einem anderen suchen.

Das Hauptproblem ist ja, es soll,muss der Temperaturwiderstand an der Regelung geklemmt bleiben.
Habe ja leider keinen extra Zugang für TempWiderstand oder Thermoelement wie beim Abgasrohr.

Einfach parallel Klemmen ist die schwere Frage, wäre wohl zu einfach?

Gruß Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

synaps-o-dan

Die Verkabelung ist eher nicht wie aus dem Lehrbuch (vorsichtig formuliert): zwei Stränge, die dann sternförmig zu einzelnen Sensoren führen. Teilweise sind die Stränge länger als 5m. Ich habe es jetzt so gelöst, dass ich die beiden Stränge an zwei Busmaster gehängt habe. Da es sich in der Tat nur um Temperatur-/Luftfeuchtesensoren, Temperatursensoren und zwei Counter (Strom und Gas) handelt, können die OWX in der Tat gemütlich vor sich hin werkeln (Intervall ist 300s). Ich werde es jetzt so lassen. Vielen Dank für die Tips!
Eine anschließende Frage: kann ich eine Abfrage der Sensorwerte in einer separaten Funktion (in 99_myXY.pm) als nonBLocking call durchführen? Das würde die Möglichkeit eröffnen, die Werte nach glitches zu untersuchen, bevor sie dann an (Dummy-) Devices übergeben werden, die dann geloggt werden.
lg
Daniel

Zitat von: Prof. Dr. Peter Henning am 24 Februar 2018, 12:37:54
Wie sieht denn die Verkabelung genau aus ?

Abgesehen davon könnte man, wenn es nur um Temperatur- und Feuchtesensoren geht, problemlos im synchronen Modus bleiben, denn deren Werte ändern sich nicht so schnell.

Ich würde da keinen "leistungsfähigen" Busmaster einsetzen, sondern diesen Teil des Bus einfach mit einem eigenen Busmaster versehen. Der fragt gemütlich die Dinger im Dach ab, ohne dass es zu Kollisionen mit anderen 1-Wire Devices kommt.


Ich betreibe - an einem einzigen Raspberry Pi - 5x USB und  einen Ethernet-Busmaster.


LG

pah
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

PeMue

Hallo zusammen,

ich habe vor kurzem bzw. heute ein FHEM update gemacht. Bis dato ist mein 1-wire Busmaster am mapleCUL mit folgender Definition gelaufen:

define PMmapleCUN02a1W OWX PMmapleCUN02a
attr PMmapleCUN02a1W room Radio


bzw. nachfolgend die Definitionen der Sensoren. Ich bekomme nun folgende Fehlermeldung und FHEM stürzt komplett ab:
2018.03.25 17:58:09 1: PERL WARNING: Bareword found where operator expected at ./FHEM/11_OWX_CCC.pm line 347, near "#main::Log3 $name,1,"OWX_CCC::Init"
  (Might be a runaway multi-line "" string starting on line 329)
2018.03.25 17:58:09 1: PERL WARNING: (Missing operator before OWX_CCC::Init?)
2018.03.25 17:58:09 1: PERL WARNING: String found where operator expected at ./FHEM/11_OWX_CCC.pm line 347, near "GetFn", $hwdevice, (""
Global symbol "$self" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 342.
Global symbol "$hash" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 343.
Global symbol "$self" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 343.
Global symbol "$dev" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 344.
Global symbol "$hash" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 344.
Global symbol "$name" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 345.
Global symbol "$hash" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 345.
Global symbol "$name" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 347.
syntax error at ./FHEM/11_OWX_CCC.pm line 347, near "#main::Log3 $name,1,"OWX_CCC::Init called "
Global symbol "$dev" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 347.
Global symbol "$name" requires explicit package name at ./FHEM/11_OWX_CCC.pm line 347.
./FHEM/11_OWX_CCC.pm has too many errors.


Hier die Versionsnummern:
00_OWX.pm:
# $Id: 00_OWX.pm 16437 2018-03-18 18:46:21Z phenning $

OWX_CCC.pm:
# $Id: 11_OWX_CCC.pm 16362 2018-03-09 17:18:43Z phenning $

OWX_FRM.pm:
$Id: 11_OWX_FRM.pm 16404 2018-03-14 04:04:16Z phenning $

Hat mir jemand einen Tipp, wo ich suchen muss?

Danke + Gruß

Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Prof. Dr. Peter Henning

Bitte die angehängte Version einspielen und entweder manuell laden oder FHEM restart.

LG

pah

PeMue

Hallo pah,

Zitat von: Prof. Dr. Peter Henning am 25 März 2018, 21:21:04
Bitte die angehängte Version einspielen und entweder manuell laden oder FHEM restart.
kein Absturz mehr, aber folgende Fehlermeldungen beim Starten:
2018.03.26 17:23:11 1: PERL WARNING: Use of uninitialized value $err in concatenation (.) or string at ./FHEM/11_OWX_CCC.pm line 426.
2018.03.26 17:23:11 1: OWX_CCC::Read from CUNO with error=: 0xff
2018.03.26 17:23:11 1: OWX_CCC::Read from CUNO with error=: 0xff
2018.03.26 17:23:11 1: OWX_CCC::Read from CUNO with error=: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.03.26 17:23:11 1: OWXMULTI_BinValues:  OWX_26_A2D984000005: conversion not complete or data invalid in context ds2438.getvdd 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.03.26 17:23:11 1: OWX_CCC::Read from CUNO with error=: 0xff
2018.03.26 17:23:11 1: OWX_CCC::Read from CUNO with error=: 0xff
2018.03.26 17:23:11 1: OWX_CCC::Read from CUNO with error=: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.03.26 17:23:11 1: OWXMULTI_BinValues:  OWX_26_A2D984000005: conversion not complete or data invalid in context ds2438.getvad 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff


Ich habe die locutus Emulation für Temperatur und Feuchte dranhängen, hier ein List:
Internals:
   ASYNC      0
   DEF        DS2438 A2D984000005
   ERRCOUNT   5
   ERRSTATE   1
   INTERVAL   300
   IODev      PMmapleCUN02a1W
   NAME       OWX_26_A2D984000005
   NOTIFYDEV  global
   NR         657
   NTFY_ORDER 50-OWX_26_A2D984000005
   OW_FAMILY  26
   OW_ID      A2D984000005
   PRESENT    0
   ROM_ID     26.A2D984000005.16
   STATE      initialized
   TYPE       OWMULTI
   READINGS:
     2018-03-26 17:23:11   state           initialized
     2018-03-25 22:42:21   temperature     0
   owg_val:
     -0.00390625
     10.23
     10.23
     0.249755859375
Attributes:
   IODev      PMmapleCUN02a1W
   VFunction  ((V / VDD - 0.16) / 0.0062) / (1.0546 - 0.00216 * T / 256.0)
   VName      relHumidity|rH
   VUnit      percent|%
   model      DS2438
   room       ESPEasy


Falls es nützlich ist, kann ich auch einen normalen DS1820B dranhängen und testen.

Danke + Gruß

Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Prof. Dr. Peter Henning

Öh - an den Dingen ist aber gar nichts geändert worden. Ich hatte nur in die letzte Version des Modules einen trivialen Loging-Fehler eingebaut.

LG

pah