Die aktuellen Frontendmodule 21_OW* sind schon seit einiger Zeit umgestellt, sie laufen mit dem "alten" OWX-Backend, mit OWX_ASYNC und mit OWServer.
HEUTE habe ich 00_OWX.pm durch die seit mehr als einem Jahr in der Entwicklung befindliche Version ersetzt, bei der man zwischen dem "alten" synchronen und dem neuen asynchronen Betrieb wählen kann. Dazu gehören die Interfacemodule 11_OWX.*
Ausgetestet ist das System jetzt seit einigen Monaten - dennoch sind unerwünschte Effekte nicht auszuschließen. In diesem Fall bitte 00_OWX.pm durch die vorherige Version ersetzen.
LG
pah
Hallo Prof. Dr. Peter Henning,
hatte gerade den Versuch gestartet bekomme aber dies im Log
2017.10.29 18:59:43 1 : open ./FHEM/00_OWX.pm failed: Permission denied, trying to restore the previous version and aborting the update
Gruß
Hans-Jürgen
Hi pah,
habe nun alle während der Beta-Phase aus dem Thread gesammelten Module auf meinem Testsystem durch die heutigen (Version=7.01) ersetzt: Nach einem shutdown restart fallen zwei Dinge auf:
Im Log eine Perl-Warnung:
2017.10.29 19:36:11 3: Opening OWio1 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE0010g-if00-port0
2017.10.29 19:36:11 3: OWio1 device opened
2017.10.29 19:36:11 3: OWX_SER: opened serial device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE0010g-if00-port0: Illegal seek
2017.10.29 19:36:24 3: OWAD: Device umweltsensor defined.
2017.10.29 19:36:32 3: OWTHERM: Device t_Dach_Sued defined.
2017.10.29 19:36:33 0: Featurelevel: 5.8
2017.10.29 19:36:33 0: Server started with 21 defined entities (fhem.pl:15294/2017-10-20 perl:5.020002 os:linux user:fhem pid:2139)
2017.10.29 19:37:44 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_OWX.pm line 1561.
Außerdem zeigt VDD eine um gut 0.1 Volt niedrige Spannung an, obwohl ich - wie gesagt - nur logisch neu gestartet habe - Raspberry und der USB-Busmaster liefen durch.
Herzliche Grüße und Congrats für den Zieleinlauf dieses großen Projektes
Christian
hallo pah,
alles wie erwartet perfekt. Keine Überraschungen gegenüber der Testphase. Vielen Dank für die super Arbeit!
Moin pah,
Update hat problemlos geklappt. Alle Sensoren arbeiten wie bisher nur jetzt ASYNCHRONOUS. Im Log habe ich einzelne Warnungen. Die sind aber bei Verbose 0 auch weg 8)
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_OWX.pm line 1561.
Wenn ich "Device specific help" im OWX Device anklicken, kommt die Erklärung zu "YAAHM"....
Bisher also nur kleine optische Schoenheitsfehler, aber das wichtigste ist, es tut. Vielen Dank dafür.
Gruss
Enno
So, mein Testsystem läuft jetzt auch auf der NG.
Nach Update und Neustart folgendes im Log:
2017.10.30 11:22:52 3: Opening 1wire device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0
2017.10.30 11:22:52 3: 1wire device opened
2017.10.30 11:22:52 3: OWX_SER: opened serial device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0: Illegal seek
2017.10.30 11:23:01 3: OWTHERM: Device OWX_28_B10A5F070000 defined.
2017.10.30 11:23:01 3: OWTHERM: Device OWX_28_BD3E60070000 defined.
2017.10.30 11:23:11 3: OWMULTI: Device OWX_26_F6752B010000 defined.
2017.10.30 11:23:11 3: OWMULTI: Device OWX_26_3D8780010000 defined.
2017.10.30 11:24:23 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_OWX.pm line 1561.
ZitatWenn ich "Device specific help" im OWX Device anklicken, kommt die Erklärung zu "YAAHM"....
Äh - ja. Copy & Paste, ist in Version 7.02 behoben.
Problem mit der Zeile 1561 finde ich auf die Schnelle nicht, ist aber nur ein Schönheitsfehler.
LG
pah
Zitat von: Deckoffizier am 29 Oktober 2017, 19:01:49
Hallo Prof. Dr. Peter Henning,
hatte gerade den Versuch gestartet bekomme aber dies im Log
2017.10.29 18:59:43 1 : open ./FHEM/00_OWX.pm failed: Permission denied, trying to restore the previous version and aborting the update
Gruß
Hans-Jürgen
hier würde ich mal schauen, ob die Rechte auf Unixebene den Dateien entsprechen, die er vor dem update-Abbruch updaten wollte (in /opt/fhem/FHEM, Schreib-Leserechte sind üblicherweise 0666 und owner ist die Gruppe Fhem)
Christian
Hallo Christian,
Danke für Deine Hilfe habe es hinbekommen.
Hätte doch vor dem posten hier Tante Google bemühen sollen. Berechtigungen und Benutzer ,Gruppen eigentlich eine Urschleimgeschichte unter Linux.
Ein großes Danke auch an pah für seine Fleißarbeit läuft zur Zeit alles ohne Probleme.
Gruß
Hans-Jürgen
Hallo pah,
nach dem Update kommet folgende Fehlermeldung:
Messages collected while initializing FHEM:
configfile: OWX: unknown attribute IODev. Type 'attr OWX ?' for a detailed list.
OWX2: unknown attribute IODev. Type 'attr OWX2 ?' for a detailed list.
Daraus ergibt sich folgende Fehlermeldung:
OWX2 error initializing: Device 'OWX' allready defined for pin 9
Klar, wenn fhem beim falschen IODev sucht.
Anschließend ist fhem extrem langsam, bis es letztlich abstürzt.
OWX ist ein Arduino mit DS2482-100 (USB)
OWX2 ist ein Arduino (LAN)
Gruß Jens
p.s. Habe die Verbindungen zu den Arduinos getrennt, so dass fhem im Notbetrieb, ohne FRM-Devices (owx,i2c,in,out,pwm, etc.) stabil läuft...
Hm, das muss ich mal versuchen nachzustellen.
Allerdings hält sich mein Mitleid in Grenzen - als ich nämlich nach Testern für das neue Firmata-Interface gesucht habe, war gähnende Leere. Habe ich mir also selber eins eingerichtet, fein, aber eben nur Eines.
LG
pah
Weiterhin in Arbeit.
Ich hatte mich angeboten aber auf meine Beiträge keine Antworten bzw. barsche Abfuhren erhalten...
Übrigens hatte ich das Problem mit dem fehlenden IODev für OWX bereits am 3.10. gepostet.
Zitat von: dirigent am 03 Oktober 2017, 21:23:59
Hi, beim Start erscheint folgende Meldung:
Die IODev für das OWX-Interface sind verschwunden und "attr OWX2 IODev Saeule" ist nicht mehr möglich.
Beide OWX finden bei "get OWX devices" nichts. Angeschlossen sind DS18B20, DS2408 und DS2413.
Gruß Jens
Nach der Installation des Fixes stürzt fhem mit folgender Meldung ab:
Can't use string ("OWX") as a HASH ref while "strict refs" in use at ./FHEM/11_OWX_FRM.pm line 402
Sorry für den Absturz - muss noch mal drüber nachdenken.
Aber noch einmal: IODev ist KEIN ATTRIBUT, und wird es auch für das OWX-Backend niemals sein. Das IODev ist Bestandteil der Definition.
Was vorher war, ist ziemlich inkonsistent gewesen (und nicht von mir ...)
LG
pah
Sorry, vorher war IODev drin und funktionierte einwandfrei.
Gruß Jens
Noch einmal: Diese Inkonsistenz ist herausgeflogen - ab sofort ist das Firmata-Device Bestandteil der Busdefinition.
Also NICHT
define OWBUS OWX PIN
attr OWBUS IODev FIRMATADEVICE
SONDERN
define OWBUS OWX FIRMATADEVICE:PIN
LG
pah
Anbei die beiden Dateien, mit denen es endgültig funktiomieren sollte.
Danke für die schnelle Reaktion.
Ist Buspower auch raus?
OWX: unknown attribute buspower. Type 'attr OWX ?' for a detailed list.
Der USB-Arduino mit einem DS2482-100 wurde früher auf dem i2c-Pin definiert. Das scheint jetzt auch anders zu sein.
pin '20' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 784.
Nach der Meldung stürzt fhem ab.
Gruß Jens
Daran habe ich aber nichts geändert - das scheint ein Firmata-Problem zu sein. Was sagt das Log ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2017, 21:36:14
Noch einmal: Diese Inkonsistenz ist herausgeflogen - ab sofort ist das Firmata-Device Bestandteil der Busdefinition.
Also NICHT
define OWBUS OWX PIN
attr OWBUS IODev FIRMATADEVICE
SONDERN
define OWBUS OWX FIRMATADEVICE:PIN
LG
pah
Anbei die beiden Dateien, mit denen es endgültig funktiomieren sollte.
Moin,
habe die aktuellen Dateien eingespielt (7.0.3) und grundsätzlich funktioniert es auch.
Die Devices werden über die Firmata gefunden.
Allerdings bleibt das Problem das die Devices (DS2411) nicht aktualisiert werden. Sie bleiben auf "present 0" obwohl ein "get devices" die Sensoren findet.
Siehe https://forum.fhem.de/index.php/topic,60460.msg707212.html#msg707212 (https://forum.fhem.de/index.php/topic,60460.msg707212.html#msg707212)
Die Logeinträge bleiben auch: (Hier mal ein "get devices" mit Verbose 5)
2017.11.01 08:25:58 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:25:58 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:25:58 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:25:58 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:25:59 1: OWX_Discover: 1-Wire devices found on bus OWX7 (OWX_01_BCA5D0100000,KEL_Lager_Fenstersensor,KEL_Vorrat_Fenstersensor,KEL_Waschen_Fenstersensor)
2017.11.01 08:26:02 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:26:02 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:26:02 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:26:02 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:26:02 3: OWX_Verify called while interface OWX7 not opened
2017.11.01 08:26:02 3: OWX_Verify called while interface OWX7 not openedHier mal ein List vom BM:
Internals:
ALARMED 0
ASYNCHRONOUS 1
DEF FRM_0:9
FRM_OWX_CORRELATIONID 0
HWDEVICE FRM_0
INITDONE 1
INTERFACE firmata
IODev FRM_0
NAME OWX7
NR 72
PARTIAL
PIN 9
PRESENT 1
ROM_ID FF
STATE Initialized
TYPE OWX
interval 300
timeout 2
version 7.03
DEVHASH:
KEL_Lager_Fenstersensor 01.4247CF100000.77
KEL_Vorrat_Fenstersensor 01.FE60CF100000.A4
KEL_Waschen_Fenstersensor 01.6753CF100000.49
OWX7 Busmaster
OWX_01_BCA5D0100000 01.BCA5D0100000.ED
DEVS:
01.BCA5D0100000.ED
01.4247CF100000.77
01.FE60CF100000.A4
01.6753CF100000.49
FRM_OWX_REPLIES:
READINGS:
2017-11-01 07:47:11 state disconnected
Attributes:
asynchronous 1
verbose 5 Wo kann ich noch ansetzen oder helfen?
grtz
CmdA
Ich muss versuchen, das nachzustellen. Das Problem ist, dass Verify nicht asynchron laufen kann - weil es eine (teilweise) Bussuche durchführt. Deshalb wird dabei der asynchrone Modus außer Kraft gesetzt.
Welchen Wert hat denn das Attribut "asynchronous" ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 November 2017, 09:15:36
Ich muss versuchen, das nachzustellen. Das Problem ist, dass Verify nicht asynchron laufen kann - weil es eine (teilweise) Bussuche durchführt. Deshalb wird dabei der asynchrone Modus außer Kraft gesetzt.
Welchen Wert hat denn das Attribut "asynchronous" ?
LG
pah
asynchronous ist 1.
Habe es nun mal auf 0 gesetzt, das Verhalten ist aber identisch.
grtz
CmdA
Hallo pah,
danke für die heutige Anpassung der commandref in Bezug auf die Definition von OWX-Devices. Da hast du bestimmt noch Einiges zu ändern.
Anbei die Firmata-Daten. Der Arduino ist mit den Dateien aus der, in der Wiki verlinkten Version zum DS2482 geflasht und laut Wiki eingerichtet. Bisher hat das auch funtioniert. Nun bin ich auf die Neuerungen gespannt.
Gruß Jens
Zitatdanke für die heutige Anpassung der commandref in Bezug auf die Definition von OWX-Devices. Da hast du bestimmt noch Einiges zu ändern.
Die Änderung war gestern - und was hätte ich noch zu ändern ? Funlktioniert doch so, oder nicht ?
LG
pah
Ok, dann warst du länger wach als ich :).
"attr <name> IODev" steht noch drin und buspower fehlt. Im Wikiartikel https://wiki.fhem.de/wiki/Arduino_mit_OneWireFirmata (https://wiki.fhem.de/wiki/Arduino_mit_OneWireFirmata) steht noch die alte Definition.
Ob es geht kann ich nicht sagen. Fhem stürzt (mit DS2482) zu schnell ab.
Gruß Jens
kurze Rückmeldung, sieht gut aus. Nachdem ich das Device neu definiert habe mit "define 1wire OWX firmata:14" und das alte attr IODev entfernt habe läuft mein Bus wieder. Div. Temp Sensoren DS1820 und DS2413 als Fenstersensor werden erkannt.
Besten Dank für den schnellen Support.
Grüße
Lars
Moin,
mir ist noch etwas aufgefallen:
Nach einem Neustart wird bei den Sensoren am Firmata-Bus jedesmal das attr IODev neu geschrieben obwohl dies ja nicht mehr vorhanden sein soll.
Eingetragen wird dann ein BM der kein Firmata-Busmaster ist. (Habe noch 2 weitere BM, USB/WLAN von locotus).
Ich habe außerdem noch einen DS2423 allein an einem Firmata-BM, der läuft einwandfrei. (Trotz falschem attr IODev welches gesetzt wird).
Das DS2411 (OWID) Problem bleibt weiterhin bestehen. Es kommen keine Stati bei den Devices an (present 0|1) obwohl der BM die Devices findet.
Wenn ich etwas Zeit habe werde ich mal einen einzelnen DS2411 an die Firmata klemmen um einen Fehler am Bus selbst sicher auszuschliessen.
grtz
CmdA
Das Schreiben eines Attributes IODev für ein OWX-Firmata-Device kommt nicht aus meinen Modulen.
LG
pah
P.S. Nix für ungut, aber die Mehrzahl von Status ist Status
Hallo pah,
konnte meine Logdatei Aufschluss zum Absturzverhalten (DS2482 am Arduino) geben?
Wäre es ratsamer, auf den i2C-Busmaster zu verzichten und ArduinoOneWire direkt zu nutzen?
Gruß Jens
Zitat von: Prof. Dr. Peter Henning am 02 November 2017, 18:45:13
Das Schreiben eines Attributes IODev für ein OWX-Firmata-Device kommt nicht aus meinen Modulen.
LG
pah
Ok, danke für die Info.
Ist vermutlich ja auch nicht das Problem da zumindest der DS2423 ja funktioniert.
Sollte nur ein Hinweis sein.
Bleibt die Sache mit den DS2411 und OWID.
Zitat
P.S. Nix für ungut, aber die Mehrzahl von Status ist Status
Danke für den Hinweis.
Grtz
CmdA
@dirigent:
Zitatkonnte meine Logdatei Aufschluss zum Absturzverhalten (DS2482 am Arduino) geben?
Könnte. Sicher.
Zitat
Wäre es ratsamer, auf den i2C-Busmaster zu verzichten und ArduinoOneWire direkt zu nutzen?
Kann ich nicht beantworten, da meine Kristallkugel gerade in der Werkstatt ist.
LG
pah
Danke. >:(
Support nach Belieben zu geben, scheint mir recht unprofessionell...
Sollte der DS2482 am Arduino künftig nicht mehr unterstützt werden, bitte ich um Löschung der irreführenden Einträge in commandref und Wiki.
Gruß Jens
Mal die Luft anhalten - "professionellen" Support biete ich gerne an, aber mein Stundensatz ist ziemlich hoch.
pah
Hallo,
nach gerade durchgeführtem Update habe ich das Problem, dass fhem direkt nach einem
define OWBUS7 OWX FIRMATA7:17
mit
Can't locate ./FHEM/11_OWX_I2C.pm at ./FHEM/00_OWX.pm line 187.
abschmiert.
Das 11_OWX_I2C.pm habe ich nicht und kann ich auch im SVN nicht finden.
LG Chris
Ah, OK - da habe ich noch einen Fehler im Modul, weil "FIRMATA7:17" als I2C-Device interpretiert wird.
Werde ich schnellstmöglich ausbessern - aber heute nicht mehr.
Workaround: Bitte temporär das FIRMATA7 umbenennen in etwas, das nur Buchstaben enthält - von mir aus FIRMATASIEBEN.
Oder: Selbst in der Datei 00_OWX.pm in Zeile 186 ein Caret ("Dach") in die Regexp einsetzen, also
m|^\d\:\d\d|
LG
pah
Moin, das
m|^\d\:\d\d|
hat es gebracht. Vielen Dank für den schnellen und professionellen Support ;)
;D
Ich habe keine Ziffern im Arduino Namen und erhalte:
OWX: COC/CUNO device FIRMATA:19 not defined
define Pool OWX FIRMATA:19
Hi, hast Du ein define für den Arduino gemacht? Erst danach kannst Du OWX definieren.
Ist auch schön im Wiki erklärt.
Chris
Hallo,
wie sich zeigt, habe ich doch noch ein Problem bei mehreren Arduinos mit Firmata.
define frm7.owx15 OWX FIRMATA7:15
funktioniert und Geräte werden auf dem Bus gefunden:
list frm7.owx15
Internals:
ALARMED 0
ASYNCHRONOUS 0
CFGFN
DEF FIRMATA7:15
FRM_OWX_CORRELATIONID 0
HWDEVICE FIRMATA7
INITDONE 1
INTERFACE firmata
IODev FIRMATA7
NAME frm7.owx15
NR 6099
PARTIAL
PIN 15
PRESENT 1
ROM_ID FF
STATE Initialized
TYPE OWX
interval 300
timeout 2
version 7.03
DEVHASH:
OWX_28_FFCCFC671403 28.FFCCFC671403.C2
frm7.owx15 Busmaster
DEVS:
28.FFCCFC671403.C2
FRM_OWX_REPLIES:
Attributes:
IODev FIRMATA7
(Das Attribut IODev habe ich nicht von Hand gesetzt)
Nach einem Fhem restart drängelt sich dann ein anderes Firmata Device vor und auf dem Bus werden keine Geräte mehr gefunden:
list frm7.owx15
Internals:
ALARMED 0
ASYNCHRONOUS 0
DEF FIRMATA7:15
FRM_OWX_CORRELATIONID 0
HWDEVICE FIRMATA7
INITDONE 1
INTERFACE firmata
IODev FIRMATA2
NAME frm7.owx15
NR 1172
PARTIAL
PIN 15
PRESENT 1
ROM_ID FF
STATE Initialized
TYPE OWX
interval 300
timeout 2
version 7.03
DEVHASH:
frm7.owx15 Busmaster
DEVS:
FRM_OWX_REPLIES:
Attributes:
IODev FIRMATA2
Nach dem löschen von dem Attibut IODev bleibt das Internal IODev bei dem fehlerhaften "FIRMATA2"
Chris
Das kann ich so nicht nachvollziehen - denn das System sollte ohne ein Attribut IODev für die OWX-Firmata gestartet werden. Und im OWX Code ist keine Zeile außerhalb der Definition, die das IODev setzen kann.
LG
pah
Hallo,
das Problem ist reproduzierbar. Wenn das Internal IODev auf der definierten Firmata steht werden auf dem Bus Geräte gefunden - gut so.
Nach einem Neustart von Fhem stimmt dann aber das Internal IODev nicht mehr mit dem Define überein und ich habe ein Attribut IODev, dass es doch imho gar nicht mehr geben dürfte.
Das Attr IODev kann ich nicht ändern und ein löschen hat keine Auswirkung auf das Internal.
Andere scheinen ja nicht dieses Problem zu haben. Hast Du noch einen Hinweis, wo ich da ansetzen kann?
Ich habe die Devices und Fhem auf verbose 5 gesetzt und dabei das hier gefunden, kann das aber nicht bewerten:
2017.11.05 21:44:33 5: Loading ./FHEM/21_OWTHERM.pm
2017.11.05 21:44:36 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at C:/fhem/fhem.pl line 2041, <$fh> line 1333.
2017.11.05 21:44:36 1: stacktrace:
2017.11.05 21:44:36 1: main::__ANON__ called by C:/fhem/fhem.pl (2041)
2017.11.05 21:44:36 1: main::AssignIoPort called by ./FHEM/21_OWTHERM.pm (205)
2017.11.05 21:44:36 1: main::OWTHERM_Define called by C:/fhem/fhem.pl (3497)
2017.11.05 21:44:36 1: main::CallFn called by C:/fhem/fhem.pl (1943)
2017.11.05 21:44:36 1: main::CommandDefine called by C:/fhem/fhem.pl (1182)
2017.11.05 21:44:36 1: main::AnalyzeCommand called by C:/fhem/fhem.pl (1035)
2017.11.05 21:44:36 1: main::AnalyzeCommandChain called by C:/fhem/fhem.pl (1317)
2017.11.05 21:44:36 1: main::CommandInclude called by C:/fhem/fhem.pl (544)
Bye Chris
Hallo,
ich habe seit Anfang Oktober OWX im Einatz. Prinzipiell mit großer Freude, da ich endlich owfs und OWSERVER ablösen kann mit einer Lösung, die robust läuft. Vielen Dank dafür!! Diese Konstellation läuft problemlos:
File Rev Last Change
21_OWCOUNT.pm 15339 2017-10-29 08:14:07Z phenning
21_OWID.pm 15339 2017-10-29 08:14:07Z phenning
21_OWMULTI.pm 15339 2017-10-29 08:14:07Z phenning
21_OWTHERM.pm 15339 2017-10-29 08:14:07Z phenning
00_OWX.pm 15159 2017-10-01 10:02:28Z phenning
Mit der aktuellen Version von OWX (00_OWX.pm 15392 2017-11-05 06:46:46Z phenning). Gibt es Probleme. Die Counter geben die folgende Fehlermeldung:
OWCOUNT: get <device> counters failed, reason: OWCOUNT: Could not get values from device <device>, reason: 1D.42F60F000000.78 has returned invalid data of length 2OWCOUNT: Could not get values from device <device>, reason: 1D.42F60F000000.78 not accessible in reading page 15
(<device> steht für den device-Namen)
OWMULTIs fuktionieren sporadisch und geben im Fehlerfall folgendes zurück:
OWMULTI: Could not get values from device <device>, reason 26.E59A40010000.e2 has returned invalid data
OWTHERMs funktionieren anscheinend. Alles ist noch im Synchron-Betrieb.
Der Busmaster-eigene OWID wird nicht erkannt. Als Busmaster ist ein LinkUSBi im Einsatz.
Gerne kann ich Auszüge aus dem log mit verschiedenen Verbositäten liefern.
Viele Grüße,
Daniel
edit: Typos
Bitte mal im OWX-Device verbose=5 setzen.
SAußerdem kann man das timeout-Attribut etwas hochsetzen.
LG
pah
Danke für die schnelle Antwort. Folgende Info: ich lasse im Folgenden das OWX-device "OWID_LinkUSB" mit der aktuellen Version von 00_OWX.pm und verbose=5 jeweils einen OWTHERM, einen OWMULTI und einen OWCOUNT abfragen. Nach Start von fhem war OWID_LinkUSB übrigens nicht aktiv (disconnected) und wurde von mir manuell gestartet (reopen). Das Attribut timeout habe ich noch noch nicht angefasst.
OWTHERM: Abfrage hat einen Wert zurückgegeben.
Log:
2017.11.07 19:26:56 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:26:56 5: SW: e3c5
2017.11.07 19:26:56 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:26:56 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:26:56 1: OWX_SER::Complex sending 0x55 0x28 0x35 0xfb 0x8b 0x03 0x00 0x00 0x67 0x44
2017.11.07 19:26:56 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x28 0x35 0xfb 0x8b 0x03 0x00 0x00 0x67 0x44
2017.11.07 19:26:56 5: SW: e1552835fb8b0300006744
2017.11.07 19:26:56 1: OWX_SER::Query OWX_LinkUSB: 0 of 10 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:26:56 1: OWX_SER::Complex receiving
2017.11.07 19:26:57 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:26:57 5: SW: e3c5
2017.11.07 19:26:57 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:26:57 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:26:57 1: OWX_SER::Complex sending 0x55 0x28 0x35 0xfb 0x8b 0x03 0x00 0x00 0x67 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:26:57 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x28 0x35 0xfb 0x8b 0x03 0x00 0x00 0x67 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:26:57 5: SW: e1552835fb8b03000067beffffffffffffffffff
2017.11.07 19:26:57 1: OWX_SER::Query OWX_LinkUSB: 0 of 19 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:26:57 1: OWX_SER::Complex receiving
2017.11.07 19:26:57 1: OWTHERM: Temp_WWSpeicher has returned invalid data of length 0
2017.11.07 19:26:57 1: OWXTHERM_BinValues: Temp_WWSpeicher: invalid data length, 0 instead of 9 bytes, 0
OWMULTI: Abfragen gaben nur sporadisch iO-Werte zurück.
log nach iO-Rückgabe:
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x09
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x09
2017.11.07 19:18:39 5: SW: e15526d949230100007a4e0009
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 12 of 12 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x09
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:18:39 5: SW: e15526d949230100007a4800
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 11 of 11 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x44
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x44
2017.11.07 19:18:39 5: SW: e15526d949230100007a44
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 10 of 10 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x44
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0xff
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0xff
2017.11.07 19:18:39 5: SW: e15526d949230100007ab4ff
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 11 of 11 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0x00
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:18:39 5: SW: e15526d949230100007ab800ff
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 12 of 12 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:18:39 5: SW: e15526d949230100007abe00ffffffffffffffffff
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 20 of 20 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0x09 0x90 0x06 0xc5 0x01 0xcc 0xff 0x00 0xa1
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x01
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x01
2017.11.07 19:18:39 5: SW: e15526d949230100007a4e0001
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 12 of 12 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x01
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:18:39 5: SW: e15526d949230100007a4800
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 11 of 11 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:39 5: SW: e3c5
2017.11.07 19:18:39 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:39 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0xff
2017.11.07 19:18:39 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0xff
2017.11.07 19:18:39 5: SW: e15526d949230100007ab4ff
2017.11.07 19:18:40 4: OWX_SER::Query OWX_LinkUSB: 11 of 11 bytes in first attempt and state opened
2017.11.07 19:18:40 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0x00
2017.11.07 19:18:40 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:40 5: SW: e3c5
2017.11.07 19:18:40 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:40 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:18:40 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:18:40 5: SW: e15526d949230100007ab800ff
2017.11.07 19:18:40 4: OWX_SER::Query OWX_LinkUSB: 12 of 12 bytes in first attempt and state opened
2017.11.07 19:18:40 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:18:40 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:18:40 5: SW: e3c5
2017.11.07 19:18:40 4: OWX_SER::Query OWX_LinkUSB: 1 of 1 bytes in first attempt and state opened
2017.11.07 19:18:40 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:18:40 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:18:40 5: SW: e15526d949230100007abe00ffffffffffffffffff
2017.11.07 19:18:40 4: OWX_SER::Query OWX_LinkUSB: 20 of 20 bytes in first attempt and state opened
2017.11.07 19:18:40 1: OWX_SER::Complex receiving 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0x01 0x90 0x06 0x50 0x01 0xed 0xff 0x00 0xd1
niO-Rückgabe im log:
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:21:46 5: SW: e3c5
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:21:46 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x09
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x4e 0x00 0x09
2017.11.07 19:21:46 5: SW: e15526d949230100007a4e0009
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 12 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Complex receiving
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:21:46 5: SW: e3c5
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:21:46 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x48 0x00
2017.11.07 19:21:46 5: SW: e15526d949230100007a4800
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 11 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Complex receiving
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:21:46 5: SW: e3c5
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:21:46 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x44
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0x44
2017.11.07 19:21:46 5: SW: e15526d949230100007a44
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 10 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Complex receiving
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:21:46 5: SW: e3c5
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:21:46 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0xff
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb4 0xff
2017.11.07 19:21:46 5: SW: e15526d949230100007ab4ff
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 11 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Complex receiving
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:21:46 5: SW: e3c5
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:21:46 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xb8 0x00 0xff
2017.11.07 19:21:46 5: SW: e15526d949230100007ab800ff
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 12 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Complex receiving
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:21:46 5: SW: e3c5
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:21:46 1: OWX_SER::Complex sending 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x26 0xd9 0x49 0x23 0x01 0x00 0x00 0x7a 0xbe 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:21:46 5: SW: e15526d949230100007abe00ffffffffffffffffff
2017.11.07 19:21:46 1: OWX_SER::Query OWX_LinkUSB: 0 of 20 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:21:46 1: OWX_SER::Complex receiving
OWCOUNT hat nie funktioniert, hier das log:
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:22:42 5: SW: e3c5
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:22:42 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:22:42 1: OWX_SER::Complex sending 0x55 0x1d 0x42 0xf6 0x0f 0x00 0x00 0x00 0x78 0xa5 0xc0 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x1d 0x42 0xf6 0x0f 0x00 0x00 0x00 0x78 0xa5 0xc0 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:22:42 5: SW: e1551d42f60f00000078a5c001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: 0 of 54 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:22:42 1: OWX_SER::Complex receiving
2017.11.07 19:22:42 1: OWX_SER::Complex sending
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1
2017.11.07 19:22:42 5: SW: e1
2017.11.07 19:22:42 4: OWX_SER::Query OWX_LinkUSB: 0 of 0 bytes in first attempt and state opened
2017.11.07 19:22:42 1: OWX_SER::Complex receiving
2017.11.07 19:22:42 1: OWX_SER::Complex sending
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1
2017.11.07 19:22:42 5: SW: e1
2017.11.07 19:22:42 4: OWX_SER::Query OWX_LinkUSB: 0 of 0 bytes in first attempt and state opened
2017.11.07 19:22:42 1: OWX_SER::Complex receiving
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:22:42 5: SW: e3c5
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:22:42 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:22:42 5: SW: e3c5
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:22:42 1: OWX_SER::Reset failure on bus OWX_LinkUSB
2017.11.07 19:22:42 1: OWX_SER::Complex sending 0x55 0x1d 0x42 0xf6 0x0f 0x00 0x00 0x00 0x78 0xa5 0xe0 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1 0x55 0x1d 0x42 0xf6 0x0f 0x00 0x00 0x00 0x78 0xa5 0xe0 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2017.11.07 19:22:42 5: SW: e1551d42f60f00000078a5e001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: 0 of 54 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:22:42 1: OWX_SER::Complex receiving
2017.11.07 19:22:42 1: OWX_SER::Complex sending
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1
2017.11.07 19:22:42 5: SW: e1
2017.11.07 19:22:42 4: OWX_SER::Query OWX_LinkUSB: 0 of 0 bytes in first attempt and state opened
2017.11.07 19:22:42 1: OWX_SER::Complex receiving
2017.11.07 19:22:42 1: OWX_SER::Complex sending
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe1
2017.11.07 19:22:42 5: SW: e1
2017.11.07 19:22:42 4: OWX_SER::Query OWX_LinkUSB: 0 of 0 bytes in first attempt and state opened
2017.11.07 19:22:42 1: OWX_SER::Complex receiving
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: Sending out0xe3 0xc5
2017.11.07 19:22:42 5: SW: e3c5
2017.11.07 19:22:42 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.11.07 19:22:42 1: OWX_SER::Reset failure on bus OWX_LinkUSB
niO: nicht in Ordnung
iO: in Ordnung
Hoffe, das hilft! Gerne kann ich weitere Infos liefern. Ich werde noch timeout ändern und über die Ergebnisse berichten.
Grüße und Dank,
Daniel
edit: typos
nach timeout=9:
OWCOUNTs funktionieren immer noch nicht und disconnecten den OWX. Die anderen Sensoren funktionieren.
Alles war bisher synchronous.
Guten Abend, ich habe Fhem gerade nochmal aktualisiert, OWX hat jetzt Version 7.05.
Nach einem Fhem restart kommt 29x diese Meldung:
2017.11.07 20:37:17 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at C:/fhem/fhem.pl line 2041, <$fh> line 1337.
2017.11.07 20:37:17 1: stacktrace:
2017.11.07 20:37:17 1: main::__ANON__ called by C:/fhem/fhem.pl (2041)
2017.11.07 20:37:17 1: main::AssignIoPort called by ./FHEM/21_OWTHERM.pm (205)
2017.11.07 20:37:17 1: main::OWTHERM_Define called by C:/fhem/fhem.pl (3497)
2017.11.07 20:37:17 1: main::CallFn called by C:/fhem/fhem.pl (1943)
2017.11.07 20:37:17 1: main::CommandDefine called by C:/fhem/fhem.pl (1182)
2017.11.07 20:37:17 1: main::AnalyzeCommand called by C:/fhem/fhem.pl (1035)
2017.11.07 20:37:17 1: main::AnalyzeCommandChain called by C:/fhem/fhem.pl (1317)
2017.11.07 20:37:17 1: main::CommandInclude called by C:/fhem/fhem.pl (544)
und dann:
2017.11.07 20:37:17 1: Including ./log/fhem.save
2017.11.07 20:37:17 1: configfile: frm6.owx19: unknown attribute IODev. Type 'attr frm6.owx19 ?' for a detailed list.
frm7.owx15: unknown attribute IODev. Type 'attr frm7.owx15 ?' for a detailed list.
2017.11.07 20:37:17 1: Error: >FIRMATA6:19< has no TYPE, but following keys: ><
2017.11.07 20:37:17 1: Error: >FIRMATA7:15< has no TYPE, but following keys: ><
2017.11.07 20:37:20 0: Featurelevel: 5.8
2017.11.07 20:37:28 1: PERL WARNING: Character in 'C' format wrapped in pack at FHEM/lib/Device/Firmata/Protocol.pm line 407.
2017.11.07 20:37:28 1: stacktrace:
2017.11.07 20:37:28 1: main::__ANON__ called by FHEM/lib/Device/Firmata/Protocol.pm (407)
2017.11.07 20:37:28 1: Device::Firmata::Protocol::packet_sysex_command called by FHEM/lib/Device/Firmata/Protocol.pm (569)
2017.11.07 20:37:28 1: Device::Firmata::Protocol::packet_sampling_interval called by FHEM/lib/Device/Firmata/Platform.pm (569)
2017.11.07 20:37:28 1: Device::Firmata::Platform::sampling_interval called by ./FHEM/10_FRM.pm (335)
2017.11.07 20:37:28 1: main::FRM_apply_attribute called by ./FHEM/10_FRM.pm (466)
2017.11.07 20:37:28 1: main::FRM_DoInit called by ./FHEM/10_FRM.pm (260)
2017.11.07 20:37:28 1: main::FRM_Read called by C:/fhem/fhem.pl (3497)
2017.11.07 20:37:28 1: main::CallFn called by C:/fhem/fhem.pl (700)
2017.11.07 20:37:31 4: OWX_Qomplex: Added dev 28FFCCFC671403C2 to queue frm7.owx15 context=writesp
2017.11.07 20:37:31 1: OWX_FRM::Write attempted to undefined device frm7.owx15
2017.11.07 20:37:31 1: queue frm7.owx15 contains 1 entries after insertion
2017.11.07 20:37:31 1: => 28FFCCFC671403C2 context writesp expecting 3 bytes, active
2017.11.07 20:37:31 1: ----------------------------------------------
2017.11.07 20:37:31 1: OWX_Qomplex: Added dev 28FFCCFC671403C2 to queue frm7.owx15 numread=1
2017.11.07 20:37:31 1: queue frm7.owx15 contains 2 entries after insertion
2017.11.07 20:37:31 1: => 28FFCCFC671403C2 context writesp expecting 3 bytes, active
2017.11.07 20:37:31 1: => 28FFCCFC671403C2 context convert expecting 1 bytes, waiting
2017.11.07 20:37:31 1: ----------------------------------------------
2017.11.07 20:37:31 1: OWX_Qomplex: Added dev 28FFCCFC671403C2 to queue frm7.owx15 numread=19
2017.11.07 20:37:31 1: queue frm7.owx15 contains 3 entries after insertion
2017.11.07 20:37:31 1: => 28FFCCFC671403C2 context writesp expecting 3 bytes, active
2017.11.07 20:37:31 1: => 28FFCCFC671403C2 context convert expecting 1 bytes, waiting
2017.11.07 20:37:31 1: => 28FFCCFC671403C2 context readsp expecting 19 bytes, waiting
2017.11.07 20:37:31 1: ----------------------------------------------
2017.11.07 20:37:31 4: OWX_Qomplex: Added dev 28FFFD8F46160305 to queue frm6.owx19 context=writesp
2017.11.07 20:37:31 1: OWX_FRM::Write attempted to undefined device frm6.owx19
2017.11.07 20:37:31 1: queue frm6.owx19 contains 1 entries after insertion
2017.11.07 20:37:31 1: => 28FFFD8F46160305 context writesp expecting 3 bytes, active
2017.11.07 20:37:31 1: ----------------------------------------------
2017.11.07 20:37:31 1: OWX_Qomplex: Added dev 28FFFD8F46160305 to queue frm6.owx19 numread=1
2017.11.07 20:37:31 1: queue frm6.owx19 contains 2 entries after insertion
2017.11.07 20:37:31 1: => 28FFFD8F46160305 context writesp expecting 3 bytes, active
2017.11.07 20:37:31 1: => 28FFFD8F46160305 context convert expecting 1 bytes, waiting
2017.11.07 20:37:31 1: ----------------------------------------------
2017.11.07 20:37:31 1: OWX_Qomplex: Added dev 28FFFD8F46160305 to queue frm6.owx19 numread=19
2017.11.07 20:37:31 1: queue frm6.owx19 contains 3 entries after insertion
2017.11.07 20:37:31 1: => 28FFFD8F46160305 context writesp expecting 3 bytes, active
2017.11.07 20:37:31 1: => 28FFFD8F46160305 context convert expecting 1 bytes, waiting
2017.11.07 20:37:31 1: => 28FFFD8F46160305 context readsp expecting 19 bytes, waiting
2017.11.07 20:37:31 1: ----------------------------------------------
2017.11.07 20:37:41 1: OWX_FRM::Write attempted to undefined device frm7.owx15
2017.11.07 20:37:41 1: OWX_FRM::Write attempted to undefined device frm6.owx19
2017.11.07 20:37:43 1: OWX_FRM::Write attempted to undefined device frm7.owx15
2017.11.07 20:37:43 1: OWX_FRM::Write attempted to undefined device frm6.owx19
2017.11.07 20:38:14 1: OWX_Init called for bus frm6.owx19 with interface state Initialized, now going for detect
2017.11.07 20:38:14 1: OWX: 1-Wire bus frm6.owx19: interface Firmata detected in FIRMATA2
2017.11.07 20:38:14 1: OWX_Discover: 1-Wire devices found on bus frm6.owx19 ()
2017.11.07 20:38:17 1: OWX_Init called for bus frm7.owx15 with interface state Initialized, now going for detect
2017.11.07 20:38:17 1: OWX: 1-Wire bus frm7.owx15: interface Firmata detected in FIRMATA2
2017.11.07 20:38:17 1: OWX_Discover: Device OWX_28_FFCCFC671403 of type OWTHERM is unused, consider deletion !
2017.11.07 20:38:17 1: OWX_Discover: 1-Wire devices found on bus frm7.owx15 ()
2017.11.07 20:38:19 1: OWX_Discover: 1-Wire devices found on bus frm6.owx19 ()
2017.11.07 20:38:24 1: OWX_Discover: Device OWX_28_FFCCFC671403 of type OWTHERM is unused, consider deletion !
2017.11.07 20:38:24 1: OWX_Discover: 1-Wire devices found on bus frm7.owx15 ()
Und hier noch das List der zwei OWX-Devices:
list frm6.owx19
Internals:
ALARMED 0
ASYNCHRONOUS 1
BUSY 0
DEF FIRMATA6:19
DeviceName FIRMATA6:19
FRM_OWX_CORRELATIONID 0
HWDEVICE FIRMATA6
INITDONE 1
INTERFACE firmata
IODev FIRMATA2
LASTSEND 1510083463.02729
NAME frm6.owx19
NR 1168
PARTIAL
PIN 19
PRESENT 1
ROM_ID FF
STATE Initialized
TYPE OWX
interval 300
timeout 9
version 7.05
DEVHASH:
frm6.owx19 Busmaster
DEVS:
FRM_OWX_REPLIES:
QUEUE:
READINGS:
2017-11-07 20:37:31 queue 2
Attributes:
IODev FIRMATA2
asynchronous 1
room OWX
timeout 9
verbose 5
#
list frm7.owx15
Internals:
ALARMED 0
ASYNCHRONOUS 1
BUSY 0
DEF FIRMATA7:15
DeviceName FIRMATA7:15
FRM_OWX_CORRELATIONID 0
HWDEVICE FIRMATA7
INITDONE 1
INTERFACE firmata
IODev FIRMATA2
LASTSEND 1510083463.027
NAME frm7.owx15
NR 1171
PARTIAL
PIN 15
PRESENT 1
ROM_ID FF
STATE Initialized
TYPE OWX
interval 300
timeout 9
version 7.05
DEVHASH:
frm7.owx15 Busmaster
DEVS:
FRM_OWX_REPLIES:
QUEUE:
READINGS:
2017-11-07 20:37:31 queue 2
Attributes:
IODev FIRMATA2
asynchronous 1
room OWX
timeout 9
verbose 5
Bye Chris
@synaps-o-dan: Hm - welche Counter hängen da dran ? Sind das originale DS2423
@cberl: Kann ich nicht nachvollziehen, bei mir läuft das Firmata-Interface prima, bei Anderen auch. Bitte mal testweise andere Devicenamen verwenden als "FIRMATA6" und "frm7.owx15".
LG
pah
Zitat von: Prof. Dr. Peter Henning am 08 November 2017, 08:02:17
@synaps-o-dan: Hm - welche Counter hängen da dran ? Sind das originale DS2423
@cberl: Kann ich nicht nachvollziehen, bei mir läuft das Firmata-Interface prima, bei Anderen auch. Bitte mal testweise andere Devicenamen verwenden als "FIRMATA6" und "frm7.owx15".
LG
pah
Hallo,
es handelt sich insgesamt um drei Counter.
- Zwei Stück GP1 Counter vom Fuchs-Shop (wahrscheinlich die letzten verfügbaren) mit DS2423. Datenblatt siehe Anhang.
- Ein Dual S0 Zählermodul von Esera (ehemals E-Service), Link (https://www.esera.de/shop/1-wire-smart-home/1-wire-digital-eingang-1-wire-digital-ausgang/8/1-wire-dual-s0-zaehler-17mm)
Hier ein list device eines der beiden GP1:
Internals:
ASYNC 0
DEF DS2423 42F60F000000
ERRCOUNT 0
INTERVAL 300
IODev OWX_LinkUSB
IODevName myOWX
NAME Counter_Gasuhr
NOTIFYDEV global
NR 606
NTFY_ORDER 50-Counter_Gasuhr
OW_FAMILY 1D
OW_ID 42F60F000000
PRESENT 1
ROM_ID 1D.42F60F000000.78
STATE count: 878575
TYPE OWCOUNT
DATA:
memory 2017-11-07 midnight 8.00
READINGS:
2017-11-08 20:08:02 A 878575
2017-11-08 20:08:02 A_rate 48
2017-11-08 20:08:02 B 8
2017-11-08 20:08:02 B_rate 0
2017-11-08 20:08:02 counters.A 878575
2017-11-08 20:08:02 memory 2017-11-07 midnight 8.00
2017-11-08 20:08:02 statStateDay A:_877751.00__cts_A_r:__0.00__cts/h_B:__8.00__cts_B_r:__0.00__cts/h: 05:33:07 A:_877751.00__cts_A_r:__0.00__cts/h_B:__8.00__cts_B_r:__0.00__cts/h_Count: 1
(hier steht ziemlich rum vom Statistik-Modul, muss man mal aufräumen.)
2017-11-08 20:08:02 state A: 878575.00 cts A_r: 48.00 cts/h B: 8.00 cts B_r: 0.00 cts/h
helper:
_98_statistics Stat_Counter
owg_midnight:
877751
8
owg_str:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
2017-11-07 midnight 877751.00
2017-11-07 midnight 8.00
owg_val:
878575
8
Attributes:
IODev myOWX
model DS2423
room OWX
stateFormat count: counters.A
userReadings counters.A {ReadingsVal($name,"A",0)}
Analog dazu ein list device des Esera-Moduls:
Internals:
ASYNC 0
DEF DS2423 73880F000000
ERRCOUNT 0
INTERVAL 300
IODev OWX_LinkUSB
IODevName myOWX
NAME Counter_Hauptzaehler
NOTIFYDEV global
NR 607
NTFY_ORDER 50-Counter_Hauptzaehler
OW_FAMILY 1D
OW_ID 73880F000000
PRESENT 1
ROM_ID 1D.73880F000000.6D
STATE count: 388765
TYPE OWCOUNT
DATA:
memory 2017-11-07 midnight 83886897.00
READINGS:
2017-11-08 20:08:06 A 388765
2017-11-08 20:08:06 A_rate 120
2017-11-08 20:08:06 B 83886897
2017-11-08 20:08:06 B_rate 0
2017-11-08 20:08:06 counters.A 388765
2017-11-08 20:08:06 memory 2017-11-07 midnight 83886897.00
2017-11-08 20:08:06 statStateDay
2017-11-08 20:08:06 state A: 388765.00 cts A_r: 120.00 cts/h B: 83886897.00 cts B_r: 0.00 cts/h
(auch hier viel rausgelöscht vom Statistikmodul)
helper:
_98_statistics Stat_Counter
owg_midnight:
387841.92
83886897
owg_str:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
2017-11-07 midnight 387841.92
2017-11-07 midnight 83886897.00
owg_val:
388765
83886897
Attributes:
IODev myOWX
model DS2423
room OWX
stateFormat count: counters.A
userReadings counters.A {ReadingsVal($name,"A",0)}
LG,
Daniel
Hallo,
hat sich diese "define <device-name> OWX <arduino-pin>" Syntax geändert? Wenn ich jedenfalls das Device so anlegen will wie sonst immer bekomme ich nur eine Fehlermeldung.
OWX: Define failed, unable to identify interface type <device-name> <arduino-pin>
Benutze einen Arduino Uno mit ComfirmableFirmata v2.06 über TCP.
Lg.
Es ist doch wirklich nicht schwer, die Commandref zu lesen. Darum schreibe ich sie nämlich.
LG
pah
Das hat nichts mit lesen zu tun, es funktioniert einfach nicht.
Es ist schon erst einmal positiv Fhem ist nicht abgestürzt. OneWire Devices findet er trotz dem nicht.
Die Arduino Zuordnung klappt gar nicht.
Ich habe einmal FIRMATA und einmal FIRMATA_II. Fhem trennt dies immer korrekt.
Definiert habe ich OWX FIRMATA:19. ER will sich lt. Error Meldung aber mit dem schon belegten PIN19 aus FIRMATA_II verbinden, auf dem
define Terrasse FRM_OUT 19
attr Terrasse IODev FIRMATA_II
konfiguriert ist.
OWX trifft hier eine willkürliche Zuordnung, obwohl eindeutig definiert wurde.
OWX trifft gar keine willkürliche Zuordnung, das ist einfach Unsinn.
Bitte mal nach Zeile 195 in 11_OWX_FRM eine zusätzliche Log-Zeile einfügen:
$hash->{IODev} = $main::defs{$hash->{HWDEVICE}};
main::Log 1,"===========> Initializing Firmata with IODev=".$hash->{IODev}->{NAME}." and args ".join(",",@args);
my $ret = main::FRM_Init_Pin_Client($hash,\@args,PIN_ONEWIRE);
und einen Restart machen. Und das Ergebnis dieser Log-Zeile hier posten.
LG
pah
Diese Einträge wurden geschrieben:
2017.11.11 21:28:48 1: OWX_FRM::Init Error Device 'Terrasse' allready defined for pin 19
2017.11.11 21:28:53 1: OWX_Init called for bus OWX_Pool with interface state error initializing: Device 'Terrasse' allready defined for pin 19, now going for detect
2017.11.11 21:28:53 1: OWX: 1-Wire bus OWX_Pool: interface not associated to any FRM device
2017.11.11 21:26:16 1: PERL WARNING: "my" variable $ret masks earlier declaration in same scope at ./FHEM/11_OWX_FRM.pm line 200, <$fh> line 2107.
Global symbol "@args" requires explicit package name at ./FHEM/11_OWX_FRM.pm line 195, <$fh> line 2107.
Global symbol "@args" requires explicit package name at ./FHEM/11_OWX_FRM.pm line 196, <$fh> line 2107.
Compilation failed in require at ./FHEM/00_OWX.pm line 198, <$fh> line 2107.
Die define sieht so aus :
define OWX_Pool OWX FIRMATA:19
und für die Terrasse so:
define Terrasse FRM_OUT 19
attr Terrasse IODev FIRMATA_II
Man könnte das passend uminstallieren oder die Namen ändern... Die Ursache wäre damit nicht beseitigt.
Nun, diese Fehler gibt es in der korrekten 11_OWX_FRM.pm NICHT. In der wird nämlich in Zeile 194 das Array @args definiert.
Bitte NUR die Log-Zeile einfügen ::)
pah
2017.11.12 00:32:10 1: Error: >FIRMATA:19< has no TYPE, but following keys: ><
2017.11.12 00:32:51 1: ===========> Initializing Firmata with IODev=FIRMATA and args 19
2017.11.12 00:32:51 1: OWX_FRM::Init Error Device 'Terrasse' allready defined for pin 19
2017.11.12 00:32:56 1: OWX_Init called for bus OWX_Pool with interface state error initializing: Device 'Terrasse' allready defined for pin 19, now going for detect
2017.11.12 00:32:56 1: OWX: 1-Wire bus OWX_Pool: interface not associated to any FRM device
Et voilá, damit haben wir es. Das OWX trifft keine "willkürliche Zuordnung" (bitte einen solchen Unsinn nicht noch einmal zu behaupten !), sondern ruft die Funktion FRM_Init_Pin_Client aus dem Modul 10_FRM.pm ganz korrekt auf, nämlich mit dem Wert
$hash->{IODev} = <Hash von FIRMATA>
Der Fehler befindet sich im Modul 10_FRM.pm, und zwar in der Funktion FRM_Client_AssignIOPort($@). Diese trifft die fehlerhafte Behauptung, dass DIESES Firmata-Device identisch mit dem ANDEREN Firmata-Device sei, produziert die Fehlermeldung und bricht den Initialisierungsvorgang ab.
Also: Sorry, nicht meine Baustelle - bitte an den Maintainer von 10_FRM.pm wenden.
Einen Workaround kann ich anbieten - allerdings ohne Garantie, und ohne ihn zu testen. Dazu muss man diesen Fehler umgehen, und die Funktionalität von FRM_Init_Pin_Client aus dem Modul 10_FRM.pm nachbilden, also in 11_OWX_FRM.pm die Zeile
my $ret = main::FRM_Init_Pin_Client($hash,\@args,PIN_ONEWIRE);
ersetzen durch
#-- 10_FRM.pm is broken
#my $ret = main::FRM_Init_Pin_Client($hash,\@args,PIN_ONEWIRE);
#-- possible workaround for broken 10_FRM.pm
main::AssignIoPort($hash);
my $ret = main::FRM_Client_FirmataDevice($hash)->pin_mode($pin,PIN_ONEWIRE);
Noch einmal: Das ist ungetesteter Code.
Eine zweite Möglichkeit - ebenfalls ungetestet: Diese betreffende Zeile ersetzen durch
#-- 10_FRM.pm is broken
#-- possible workaround
$main::attr{$name}{IODev}=$hash->{IODev}->{NAME};
my $ret = main::FRM_Init_Pin_Client($hash,\@args,PIN_ONEWIRE);
Dabei wird die Funktionalität nicht umgangen, sondern fälschlicherweise behauptet, wir hätten ein Attribut IODev.
LG
pah
Variante1, es passiert nichts:
2017.11.12 10:19:08 1: ===========> Initializing Firmata with IODev=FIRMATA and args 19
2017.11.12 10:19:08 1: OWX_FRM::Init Error 1
2017.11.12 10:19:13 1: OWX_Init called for bus OWX_Pool with interface state error initializing: Device 'Terrasse' allready defined for pin 19, now going for detect
2017.11.12 10:19:13 1: OWX: 1-Wire bus OWX_Pool: interface Firmata detected in FIRMATA_II
2017.11.12 10:19:15 1: OWX_Discover: 1-Wire devices found on bus OWX_Pool ()
2017.11.12 10:20:58 1: ====> REOPENING DEVICE
2017.11.12 10:21:58 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 10:22:58 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 10:23:49 1: OWX_Discover: 1-Wire devices found on bus OWX_Pool ()
2017.11.12 10:23:58 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 10:24:58 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
Variante 2, OneWire Sensoren werden gefunden und angelegt, aber nur einmal aktualisiert. Mit get ... devices werden sie angezeigt. STATE ist immer "disconnected"
2017.11.12 11:36:44 1: OWX_Complex called while interface OWX_Pool disconnected
2017.11.12 11:36:45 1: OWX_Complex called while interface OWX_Pool disconnected
2017.11.12 11:37:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:38:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:39:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:40:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:41:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:41:44 1: OWX_Complex called while interface OWX_Pool disconnected
2017.11.12 11:41:45 1: OWX_Complex called while interface OWX_Pool disconnected
2017.11.12 11:42:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:43:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:44:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:45:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:46:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:46:44 1: OWX_Complex called while interface OWX_Pool disconnected
2017.11.12 11:46:45 1: OWX_Complex called while interface OWX_Pool disconnected
2017.11.12 11:47:08 1: ====> REOPENING DEVICE
2017.11.12 11:47:44 1: OWX_FRM::Ready function called for bus OWX_Pool. STATE=disconnected
2017.11.12 11:47:51 1: ====> REOPENING DEVICE
2017.11.12 11:47:58 1: OWX_Discover: 1-Wire devices found on bus OWX_Pool (OWX_28_FFAA54631603,OWX_28_FF965F631603)
2017.11.12 11:48:08 1: OWX_Discover: 1-Wire devices found on bus OWX_Pool (OWX_28_FFAA54631603,OWX_28_FF965F631603)
Scheint ein tiefer liegendes Problem von Firmata zu sein - ich habe aber nicht die zeitlichen Ressourcen, da tiefer gehende Ursachenforschung zu betreiben.
LG
pah
Hallo,
ich habe meinen OW System mal an ein Testsystem gehängt:
- OWX in Version 7.05
- Debina Stretch, alles aktuell (das Produktivsystem läuft noch unter Jessie, noch keine Zeit fürs upgrade gehabt)
- Raspberry Pi 2B (Produktivsystem: 3)
- Eclo 1Wire USB Adapter (Produktivsystem: LinkUSBi), beide aus dem Fuchs Shop
Im Testsystem findet OWX kein einziges OW device, noch nicht einmal den OWID. Folgende Logmeldung (verbose=5) für ein get devices:
2017.11.12 14:52:52 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2017.11.12 14:52:52 5: SW: e3c5
2017.11.12 14:52:52 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2017.11.12 14:52:52 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe1 0xf0 0xe3 0xb5
2017.11.12 14:52:52 5: SW: e1f0e3b5
2017.11.12 14:52:53 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2017.11.12 14:52:53 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe1 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe3 0xa5
2017.11.12 14:52:53 5: SW: e100000000000000000000000000000000e3a5
2017.11.12 14:52:53 4: OWX_SER::Query OWX_EcloOWUSB: 16 of 16 bytes in first attempt and state opened
2017.11.12 14:52:53 1: OWX_SER::Search CRC failed on bus OWX_EcloOWUSB
2017.11.12 14:52:53 1: OWX_Discover: 1-Wire devices found on bus OWX_EcloOWUSB ()Gerne kann ich weitere Infos / Logs liefern.
VG,
Daniel
OK, damit sind wir einen Schritt weiter. Das Interface wird also gefunden, gibt auch die richtigen Codes zurück in der Query (das war bisher, wenn ich das richtig im Kopf habe, nicht so). Allerdings steigt jetzt die Bussuche aus - obwohl sie eigentlich nichts Anderes macht, als im alten OWX.
Folgender Test bitte: In der Datei 11_OWX_SER.pm steht in Zeile 785
select(undef,undef,undef,0.05);
Das ist eine Verzögerung von 50 ms. Im alten OWX lag diese bei sagenhaften 500 ms, und blockierte währenddessen FHEM. Auf den normalen USB-Adaptern machte es keine Probleme, das auf 50 ms herunterzusetzen - aber vielleicht ist der LinkUSB da kritisch.
Also bitte mal testweise die 0.05 durch 0.5 ersetzen.
LG
pah
Moin,
ich habe jetzt endlich auch mein OWX auf Async umgestellt. Ich merke eigentlich keinen Unterschied, nur die iButtons spinnen irgendwie etwas. Der present state geht ab und an mal auf 1 obwohl kein iButton steckt.
Im Log finde ich häufig diese Meldung:
2017.11.13 10:55:35 1: OWX_SER::Search reset failed on bus MP00202
Ich frage die iButton alle 5 Sekunden ab. In summe sind das 3 iButtons.
/Daniel
Das Problem bei den iButtons ist, dass diese keine "Abfrage" erlauben - sondern per (langsamer) Bus-Suche gefunden werden müssen. Also bringt der asynchrone Betrieb gar nichts, weil diese Bussuche eben synchron ablaufen muss.
Also einfach asynchronous=0 lassen, und damit sollten auch die Fehler beim dauernden Aktivieren/Deaktivieren der Warteschlange verschwinden.
LG
pah
OK sprich auch wenn an dem Bus andere Geräte hängen macht es kein Sinn?
Ich sehe schon, das mit den iButtons ist ein Problem. Das sollte man wirklich auf ein AVR auslagern und dann irgendwie an FHEM weiterreichen.
/Daniel
Na ja,
für die anderen Geräte macht das schon Sinn. Aber jedesmal bei einer "verify"-Abfrage der iButtons (und das eben bei Dir alle 5 Sekunden) wird der asynchrone Ablauf gestoppt. Daher kommen auch diese Fehlermeldungen.
Ich habe dieses Interface (mit eingebautem DS2401) auch an zwei Stellen im Betrieb, frage aber dieses OWID-Device nur 1x pro Stunde ab (alle anderen auf diesem Bus 1x pro Minute). Dennoch produziert das auf dem ansonsten asynchron laufenden Bus alle paar Tage mal einen Fehler, so dass ich schon überlege, die OWID-Abfrage komplett sein zu lassen.
LG
pah
Mhh naja ich nutz das eben als Schlüsselbrett. Klar ist nicht unbedingt Sinnvoll. Aber gut, ich werd mir mal Gedanken machen das irgendwie auf ein AVR auszulagern und dann in irgend einer Form an FHEM zu senden. Damit umgehe ich dann das ganze Thema mit diesen iButtons. Irgendwie ist das OWID Konstrukt ja immer wieder Ursache für Probleme.
Lassen sich die I/O 1-Wire Module besser abfragen? Dann lese ich meine 3 iButtons mit einem AVR aus und auf der anderen "Seite" bediene ich ein 4 Port I/O Modul. Klar neue Seriennummern müsste ich dann direkt im AVR programmieren aber das macht man ja in der Regel nur einmal.
/Daniel
Ich benutze für meine Türöffner an inzwischen 3 Stellen einen Arduino Micro, mit einer Polling-Zeit von 250 ms.
Elegant wäre (da denke ich schon länger drüber nach), einen Arduino als Busmaster (für den iButton-Bus) und gleichzeitig als Client für den "nach oben" verlaufenden 1-Wire Bus zu nehmen. Dafür könnten wir eine eigene Family ID nehmen, und sagen wir 8 verschiedene Buttons mit ID im Arduino hinterlegen. Eine Abfrage per "nach oben" gehendem Bus würde dann ein Byte zurückliefern, in dem für jeden präsenten iButton ein Bit gesetzt wird. Ein Modul für so etwas ist schnell geschrieben.
LG
pah
Hallo pah,
die Doku habe ich so verstanden, OWX mit dem attr dokick 1 eigentlich bei dem Temperatur-Devices das attr tempConv onkick erfordert. Richtig?
Wenn ich dies mache, werden die Readings nicht mehr aktualisiert (aber sie werden neu geschrieben, der Zeitstempel werden aktualisiert).
Die Kombi attr dokick 1 bei OWX und attr tempConv onread bei den Temp-Devices funktioniert bei mir inzwischen seit vielen Wochen sehr störungsfrei.
Herzliche Gruß
Christian
Muss ich überprüfen.
LG
pah
Hallo,
nach gestrigem update (Stand vorher ca eine Woche alt) steigen meine 1-wire Sensoren komplett aus:
05 06:44:20.053 1: OWX_Init called for bus 1wire with interface state opened, now going for detect
2017.12.05 06:44:20.108 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A502I1M8-if00-port0 disconnected, waiting to reappear (1wire)
2017.12.05 06:44:20.135 1: OWX_SER::Query 1wire: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2017.12.05 06:45:18.002 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:18.003 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.002 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.003 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.004 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.004 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.005 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.005 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.006 1: OWX_Complex called while interface 1wire disconnected
2017.12.05 06:45:19.006 1: OWX_Complex called while interface 1wire disconnected
Genauere Hintergründe kann ich mir erst heute Abend anschauen. Definitionen sind seit Jahren unverändert.
Schöne Grüße
Jo
Keine Änderungen seit Wochen.
LG
pah
vielleicht nach dem Uodate den "shutdown restart" vergessen?
Da kann es dann immer mal komische Effekte geben.
Hallo,
ok, danke für die Info. Neustart habe ich natürlich gemacht. Dann ist vielleicht doch etwas mit der Hardware nicht ganz in Ordnung. Werde mal testen.
Schöne Grüße
Jo
Nachtrag: Nach einem update der Linux-Pakete scheint es wieder zu laufen. Ich beobachte mal weiter.
Hallo,
ich habe soeben ein Update von FHEM gemacht und danach war das OWX Modul nicht mehr lauffähig. - Fehlerbild wie bei Jojo11.
aber mal etwas genauer:
Update das bei mir bis vor 1 Stunden aktiv war ist vom 2.10.2017
Update heute 21:00 und es ging nichts mehr (29.12.2017)
1Wire ist bei mir über das Ethernet-Modul + 2xDS2480 angebunden und läuft seit 3 Jahren fehlerfrei. Aufbau ist exakt wie im Wiki beschrieben https://wiki.fhem.de/wiki/1W-IF-ETH
letzte Änderung am Bussystem: 2 Jahre her.
Bus lief bis zum FHEM Update fehlerfrei.
FHEM Log nach Update:
2017.12.29 21:39:18 0: Server shutdown
2017.12.29 21:39:20 1: Including fhem.cfg
2017.12.29 21:39:22 1: OWID: Device fbhPi_OWID_ch1 defined.
2017.12.29 21:39:22 1: OWID: Device fbhPi_OWID_ch2 defined.
2017.12.29 21:39:34 1: Including ./log/fhem.save
2017.12.29 21:39:34 1: usb create starting
2017.12.29 21:39:40 1: usb create end
2017.12.29 21:39:40 0: Featurelevel: 5.8
2017.12.29 21:39:40 0: Server started with 83 defined entities (fhem.pl:15710/2017-12-27 perl:5.020002 os:linux user:fhem pid:1147)
2017.12.29 21:39:45 1: /dev/vmodem1 disconnected, waiting to reappear (LAN_1wire_2)
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/11_OWX_SER.pm line 462.
2017.12.29 21:39:46 1: OWX_SER::Query LAN_1wire_2: 16 of 19 bytes in last attempt and state opened, this is an unrecoverable error
2017.12.29 21:39:46 1: OWTHERM: fbhPi_OWX_EssZ_VL has returned invalid data of length 0
2017.12.29 21:39:46 1: PERL WARNING: substr outside of string at ./FHEM/21_OWTHERM.pm line 877.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $res in numeric eq (==) at ./FHEM/21_OWTHERM.pm line 890.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $res in split at ./FHEM/21_OWTHERM.pm line 893.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $data[0] in ord at ./FHEM/21_OWTHERM.pm line 937.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $data[1] in ord at ./FHEM/21_OWTHERM.pm line 938.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $data[1] in ord at ./FHEM/21_OWTHERM.pm line 939.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $data[2] in ord at ./FHEM/21_OWTHERM.pm line 951.
2017.12.29 21:39:46 1: PERL WARNING: Use of uninitialized value $data[3] in ord at ./FHEM/21_OWTHERM.pm line 952.
2017.12.29 21:39:46 1: OWXTHERM_BinValues: fbhPi_OWX_EssZ_VL: invalid data length, 0 instead of 9 bytes, 0
2017.12.29 21:39:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:39:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:39:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:39:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:39:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:39:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:40:04 1: PERL WARNING: Use of uninitialized value $value in numeric eq (==) at ./FHEM/21_OWID.pm line 406.
2017.12.29 21:40:04 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at ./FHEM/21_OWID.pm line 412.
2017.12.29 21:40:20 1: OWX_Init called for bus LAN_1wire_1 with interface state opened, now going for detect
2017.12.29 21:40:20 1: OWX_Discover: 1-Wire devices found on bus LAN_1wire_1 (fbhPi_OWID_ch1)
2017.12.29 21:44:44 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:44:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:44:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:44:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:44:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:44:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:44:46 1: OWX_Complex called while interface LAN_1wire_2 disconnected
2017.12.29 21:45:27 0: Server shutdown
/dev/vmodem0 + /dev/vmodem1 wird auf die DS2480 durchverbunden und funktionierte wie gesagt jahrelang einwandfrei.
zur Info: ich nutze socat um die Verbindung zu dem 1-wire Gateway aufzubauen. Wenn das device-file /dev/vmodem0 bzw 1 geschlossen wird, beendet sich der socat Prozess. aktuell starte und beende ich die notwendigen socat Prozesse bei "/etc/init.d/fhem start bzw stop"
Definition der OWX Devices (zur Übersichtlichkeit reduziert auf die Deinition des OWX + ein OWID je Bus):
define LAN_1wire_1 OWX /dev/vmodem0
attr LAN_1wire_1 room OWX
define fbhPi_OWID_ch1 OWID 01 170130180000
attr fbhPi_OWID_ch1 IODev LAN_1wire_1
attr fbhPi_OWID_ch1 event-min-interval present:1800
attr fbhPi_OWID_ch1 model DS2401
attr fbhPi_OWID_ch1 room OWX
attr fbhPi_OWID_ch1 stateFormat {ReadingsVal($name,"present",0) ? "present" : "not present"}
define LAN_1wire_2 OWX /dev/vmodem1
attr LAN_1wire_2 room OWX
define fbhPi_OWID_ch2 OWID 01 DAC730180000
attr fbhPi_OWID_ch2 IODev LAN_1wire_2
attr fbhPi_OWID_ch2 event-on-update-reading present
attr fbhPi_OWID_ch2 model DS2401
attr fbhPi_OWID_ch2 room OWX
attr fbhPi_OWID_ch2 stateFormat {ReadingsVal($name,"present",0) ? "present" : "not present"}
@Prof. Dr. Peter Henning: welche weiteren Infos brauchst du für die Analyse?
ich werde liefern was ich kann :-)
als Workaround habe ich die "FHEM/00_OWX.pm" durch die Version vom 2.10.2017 ersetzt und jetzt geht wieder alles.
alte Version der "FHEM/00_OWX.pm" die bei mir funktioniert:
Final version 6.314 before switching to asynchronous IO
$Id: 00_OWX.pm 15159 2017-10-01 10:02:28Z phenning $
schöne Grüße
Alex
Hallo pah,
könntest Du bitte bei Gelegenheit Telekatz' patch (https://forum.fhem.de/index.php/topic,60458.msg749330.html#msg749330) für 00_OWX.pm für den mapleCUx übernehmen?
Danke + Gruß
PeMue
Done.
LG
pah
Hallo,
ich melde mich nochmals in Sache LinkUSBi und OWX. Leider läuft die aktuelle Version von OWX ($Id: 00_OWX.pm 15904 2018-01-16 09:19:19Z phenning $) nicht mit meinem System, bestehend aus einem LinkUSBi als Busmaster und mehreren Sensoren (4 x OWTHERM, 4 x OWMULT, 3 x OWCOUNT, 1 x OWID im LinkUSBi) nicht. Verwende ich eine alte Version von OWX ($Id: 00_OWX.pm 15159 2017-10-01 10:02:28Z phenning $), so läuft das System, allerdings nur synchron. Sorry, meine ursprüngliche Anfrage ist schon etwas älter, aus beruflichen Gründen konnte ich mich nicht eher melden.
Der letzte Stand war dieser hier:
Zitat von: Prof. Dr. Peter Henning am 12 November 2017, 15:22:25
OK, damit sind wir einen Schritt weiter. Das Interface wird also gefunden, gibt auch die richtigen Codes zurück in der Query (das war bisher, wenn ich das richtig im Kopf habe, nicht so). Allerdings steigt jetzt die Bussuche aus - obwohl sie eigentlich nichts Anderes macht, als im alten OWX.
Folgender Test bitte: In der Datei 11_OWX_SER.pm steht in Zeile 785
select(undef,undef,undef,0.05);
Das ist eine Verzögerung von 50 ms. Im alten OWX lag diese bei sagenhaften 500 ms, und blockierte währenddessen FHEM. Auf den normalen USB-Adaptern machte es keine Probleme, das auf 50 ms herunterzusetzen - aber vielleicht ist der LinkUSB da kritisch.
Also bitte mal testweise die 0.05 durch 0.5 ersetzen.
LG
pah
Ich habe die Änderung durchgeführt, allerdings ohne Erfolg:
- Die OWTHERM und OWMULT laufen
- Der OWID wird nicht erkannt
- Die OWCOUNT liefern eine Fehlermeldug, wenn ich manuell ein "get counters" ausführe
Die Änderung der Verzögerung in Zeile 785 führt dazu, dass der LinkUSBi nicht mehr disconnected wird, aber Werte gibt es trotzdem keine.
Hier die Fehlermeldung der OWCOUNT (Name des device: "Counter_Hauptzaehler):
OWCOUNT: get Counter_Hauptzaehler counters failed, reason: OWCOUNT: Could not get values from device Counter_Hauptzaehler, reason: 1D.73880F000000.6D has returned invalid data of length 2OWCOUNT: Could not get values from device Counter_Hauptzaehler, reason: 1D.73880F000000.6D not accessible in reading page 15Im log führt dies zu diesem Eintrag:
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 54 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:52 1: OWX_SER::Query OWX_LinkUSB: 0 of 54 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:52 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable errorDer OWX ist noch synchron eingestellt. Gibt es Hoffnung?
Liebe Grüße,
Daniel
Seit ein paar Tagen erscheint wieder eine Fehlermeldung:
ERROR:
OWX_Pool: unknown attribute IODev. Type 'attr OWX_Pool ?' for a detailed list.
defmod OWX_Pool OWX FIRMATA_II:19
attr OWX_Pool IODev FIRMATA_II
Das Modul funktioniert, nur die Meldung ist lästig. Entferne ich das attr IODev wird es beim nächsten Start wieder eingetragen. Lt. Meldung ist das attr unbekannt wied aber automatisch wieder eingetragen. Also ein Widerspruch!
Wie bekomme ich die Meldung weg?
Hallo stefan-dd,
ein update sollte helfen. Es gibt einige Neuerungen bei OWX und FRM.
Das Attribut IODev anschließend per Hand in der fhem.cfg löschen.
Gruß Jens
Ich habe die aktuellen Updates eingespielt. Der Fehler ist erst danach, vor ein paar Tagen gekommen.
Wie bereits geschrieben kann ich das Attribut löschen, Wird aber wieder neu eingetragen, und der Fehler dazu.
Eine Arduino Zuordnung ist logischerweise notwendig, Woher soll die Definition sonst wissen welchen Arduino sie ansprechen soll.
Irgend etwas würde wieder kaputt geändert?
ZitatIrgend etwas würde wieder kaputt geändert?
Unsinn, aber hoch drei.
11_OWX_FRM wurde gepatcht, siehe den entsprechenden Thread.
pah
Hallo,
gibt es zu dem Problem in meiner fhem-Installation Hoffnung?
Viele Grüße,
Daniel
Zitat von: synaps-o-dan am 28 Januar 2018, 14:12:43
Hallo,
ich melde mich nochmals in Sache LinkUSBi und OWX. Leider läuft die aktuelle Version von OWX ($Id: 00_OWX.pm 15904 2018-01-16 09:19:19Z phenning $) nicht mit meinem System, bestehend aus einem LinkUSBi als Busmaster und mehreren Sensoren (4 x OWTHERM, 4 x OWMULT, 3 x OWCOUNT, 1 x OWID im LinkUSBi) nicht. Verwende ich eine alte Version von OWX ($Id: 00_OWX.pm 15159 2017-10-01 10:02:28Z phenning $), so läuft das System, allerdings nur synchron. Sorry, meine ursprüngliche Anfrage ist schon etwas älter, aus beruflichen Gründen konnte ich mich nicht eher melden.
Der letzte Stand war dieser hier:
Ich habe die Änderung durchgeführt, allerdings ohne Erfolg:
- Die OWTHERM und OWMULT laufen
- Der OWID wird nicht erkannt
- Die OWCOUNT liefern eine Fehlermeldug, wenn ich manuell ein "get counters" ausführe
Die Änderung der Verzögerung in Zeile 785 führt dazu, dass der LinkUSBi nicht mehr disconnected wird, aber Werte gibt es trotzdem keine.
Hier die Fehlermeldung der OWCOUNT (Name des device: "Counter_Hauptzaehler):
OWCOUNT: get Counter_Hauptzaehler counters failed, reason: OWCOUNT: Could not get values from device Counter_Hauptzaehler, reason: 1D.73880F000000.6D has returned invalid data of length 2OWCOUNT: Could not get values from device Counter_Hauptzaehler, reason: 1D.73880F000000.6D not accessible in reading page 15
Im log führt dies zu diesem Eintrag:
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 54 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:51 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:52 1: OWX_SER::Query OWX_LinkUSB: 0 of 54 bytes in last attempt and state opened, this is an unrecoverable error
2018.01.28 14:08:52 1: OWX_SER::Query OWX_LinkUSB: 0 of 1 bytes in last attempt and state opened, this is an unrecoverable error
Der OWX ist noch synchron eingestellt. Gibt es Hoffnung?
Liebe Grüße,
Daniel
Hoffnung gibt es immer.
Das Problem ist aber, dass ich selbst keinen LinkUSB habe und insofern immer nur raten kann.
Vorschlag: Wir fangen noch mal von vorne an.
1. OWX und zugehörigen Module aus dem aktuellen SVN
2. Nur ein Thermometer dran.
LG
pah
Danke für die Antort. Werde ich machen - Schritt für Schritt ein System aufbauen, beginnend mit einem DS18b20. Und dann schrittweise erweitern, bis der Fehler auftritt. Ich melde mich wieder, wenn es zeitlich geklappt hat.
lg
Daniel
hallo pah,
seit dem heutigen Update kommt einmal im Log für jeden Busmaster
OWX_SER::Define warning: version 7.05 not identical to OWX version 7.08
hast Du geplant das demnächst mal mit anzupassen?
Ja, irgendwann mal. Kann getrost ignoriert werden.
LG
pah
Hallo,
so, Schritt 1 ist getan: ich habe im Testsystem einen Busmaster angeschlossen. Leider nicht genau den LinkUSBi (http://www.fuchs-shop.com/de/shop/17/1/13372210/) (der muss im Produktivsystem bleiben), sondern als Ersatz einen COM to 1-Wire USB Adapter (http://www.fuchs-shop.com/de/shop/17/1/13372111/), der sich aber identisch verhalten sollte. Im Testsystem habe ich dann ein OWX angelegt. Am Busmaster hängt ein einzelner Temperatursensor, Leitunslänge ca. 10cm, fliegende Verkabelung. Hier das Listing des Busmasters:
Internals:
ALARMED 1
ASYNCHRONOUS 0
BLOCK 0
BUSY 0
CFGFN
DEF /dev/EcloOWUSB
DeviceName /dev/EcloOWUSB
FD 10
INITDONE 1
INTERFACE DS2480
LASTSEND 1519157756.91621
NAME OWX_EcloOWUSB
NR 49
PARTIAL
PRESENT 1
ROM_ID FF
STATE opened
TYPE OWX
interval 300
timeout 2
version 7.05
DEVHASH:
OWID_EcloOWUSB 01.FDCE58150000.3E
OWX_EcloOWUSB Busmaster
Temperatur_Test 28.3FA602040000.E1
DEVS:
28.3FA602040000.E1
01.FDCE58150000.3E
READINGS:
2018-02-20 21:16:14 queue 0
2018-02-20 21:16:18 state opened
Attributes:
asynchronous 0
room OWXHier das Listing des Temperatursensors:
Internals:
ALARM 1
ASYNC 0
CFGFN
DEF DS18B20 3FA602040000
ERRCOUNT 0
INTERVAL 300
IODev OWX_EcloOWUSB
NAME Temperatur_Test
NOTIFYDEV global
NR 63
NTFY_ORDER 50-OWX_28_3FA602040000
OW_FAMILY 28
OW_ID 3FA602040000
PRESENT 1
ROM_ID 28.3FA602040000.E1
STATE T: 22.12 °C ↓
TYPE OWTHERM
owg_temp 22.125
owg_th 75
owg_tl 70
READINGS:
2018-02-20 21:16:26 state T: 22.12 °C ↓
2018-02-20 21:16:26 temperature 22.125
tempf:
factor 1
offset 0
Attributes:
IODev OWX_EcloOWUSB
model DS18B20
room OWX
tempHigh 75
tempLow 70
verbose 0Temperatur-Readings kommen problemlos rein und erscheinen sinvoll.
Jetzt Umstellung auf asynchron, es kommt nur noch 85°C als Temperatur (also Fehler). Verbosität des Sensors auf 5 hochgedreht, es erscheint die folgende Meldung im log:
2018.02.20 21:14:17 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.20 21:14:17 1: OWXTHERM_BinValues: Temperatur_Test: no error, 85 0x50 0x05 0x4b 0x46 0x7f 0xff 0x0c 0x10 0x1c Dazu die korrelierenden Einträge des Busmasters, wenn der auf verbose 5 gesetzt ist (Zeitstempel passen nicht, da ich die Abfragen nacheinander getätigt habe):
2018.02.20 21:23:01 4: OWX_Qomplex: Added dev 283FA602040000E1 to queue OWX_EcloOWUSB context=convert
2018.02.20 21:23:01 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:23:01 5: SW: e3c5
2018.02.20 21:23:01 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:23:01 1: OWX_SER::Write Sending out 0xe1 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0x44 0xff
2018.02.20 21:23:01 5: SW: e155283fa602040000e144ff
2018.02.20 21:23:01 1: queue OWX_EcloOWUSB contains 1 entries after insertion
2018.02.20 21:23:01 1: => 283FA602040000E1 context convert expecting 1 bytes, active
2018.02.20 21:23:01 1: ----------------------------------------------
2018.02.20 21:23:01 1: OWX_Qomplex: Added dev 283FA602040000E1 to queue OWX_EcloOWUSB numread=19
2018.02.20 21:23:01 1: queue OWX_EcloOWUSB contains 2 entries after insertion
2018.02.20 21:23:01 1: => 283FA602040000E1 context convert expecting 1 bytes, active
2018.02.20 21:23:01 1: => 283FA602040000E1 context readsp expecting 19 bytes, waiting
2018.02.20 21:23:01 1: ----------------------------------------------
2018.02.20 21:23:01 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:23:01 5: SW: e3c5
2018.02.20 21:23:01 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:23:02 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:23:02 5: SW: e3c5
2018.02.20 21:23:02 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:23:02 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.20 21:23:02 5: SW: e155283fa602040000e1beffffffffffffffffffffffffffffffffffffff
2018.02.20 21:23:02 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:23:02 5: SW: e3c5
2018.02.20 21:23:02 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state openedAlle Module sind aktuell. Keine Änderngen im Quellcode.
Ich hoffe, das hilft. Ansonsten kann ich gerne weitere Infos liefern.
Liebe Grüße,
Daniel
edit: ich habe nochmal den Busmaster und den Temperatursensor auf verbose=5 gesetzt und im asynchronen Modus die Temperatur abgefragt. Hier die Einträge im log:
2018.02.20 21:28:01 4: OWX_Qomplex: Added dev 283FA602040000E1 to queue OWX_EcloOWUSB context=convert
2018.02.20 21:28:01 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:28:01 5: SW: e3c5
2018.02.20 21:28:01 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:28:01 1: OWX_SER::Write Sending out 0xe1 0x55 0x28 0x3f 0xa6 0x02 0x04 0x00 0x00 0xe1 0x44 0xff
2018.02.20 21:28:01 5: SW: e155283fa602040000e144ff
2018.02.20 21:28:01 1: queue OWX_EcloOWUSB contains 1 entries after insertion
2018.02.20 21:28:01 1: => 283FA602040000E1 context convert expecting 1 bytes, active
2018.02.20 21:28:01 1: ----------------------------------------------
2018.02.20 21:28:01 1: OWX_Qomplex: Added dev 283FA602040000E1 to queue OWX_EcloOWUSB numread=19
2018.02.20 21:28:01 1: queue OWX_EcloOWUSB contains 2 entries after insertion
2018.02.20 21:28:01 1: => 283FA602040000E1 context convert expecting 1 bytes, active
2018.02.20 21:28:01 1: => 283FA602040000E1 context readsp expecting 19 bytes, waiting
2018.02.20 21:28:01 1: ----------------------------------------------
2018.02.20 21:28:01 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:28:01 5: SW: e3c5
2018.02.20 21:28:01 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:28:02 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:28:02 5: SW: e3c5
2018.02.20 21:28:02 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:28:02 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.20 21:28:02 5: SW: e155283fa602040000e1beffffffffffffffffffffffffffffffffffffff
2018.02.20 21:28:02 1: OWX_SER::Query OWX_EcloOWUSB: Sending out0xe3 0xc5
2018.02.20 21:28:02 5: SW: e3c5
2018.02.20 21:28:02 4: OWX_SER::Query OWX_EcloOWUSB: 1 of 1 bytes in first attempt and state opened
2018.02.20 21:28:02 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.20 21:28:02 1: OWXTHERM_BinValues: Temperatur_Test: no error, 85 0x50 0x05 0x4b 0x46 0x7f 0xff 0x0c 0x10 0x1cZitat von: synaps-o-dan am 11 Februar 2018, 20:28:06
Danke für die Antort. Werde ich machen - Schritt für Schritt ein System aufbauen, beginnend mit einem DS18b20. Und dann schrittweise erweitern, bis der Fehler auftritt. Ich melde mich wieder, wenn es zeitlich geklappt hat.
lg
Daniel
Hallo synaps-o-dan,
habe nicht weiter das Problem/Thema verfolgt aber benenne mal eventuell Deinen
Temp Sensor um im List als DEF DS18B20 3FA602040000
in 28.3FA602040000 180
Die 180 am Ende ist die Abfragezeit in Sekunden nur als Beispiel.
Gruß
Hans-Jürgen
Ja, und ? Das läuft doch astrein, die Log-Meldung "no error" besagt, dass die Daten vom Sensor ohne Probleme gelesen werden (CRC-Code stimmt)
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2018, 04:39:02
Ja, und ? Das läuft doch astrein, die Log-Meldung "no error" besagt, dass die Daten vom Sensor ohne Probleme gelesen werden (CRC-Code stimmt)
LG
pah
OK, aber der Sensor ist ein DS18B20. Teilt der über das Reading ,,85" nicht einen Fehler mit? Das Reading 85 taucht wie gesagt nur im asynchronen Fall auf, im synchronen Fall ist alles in Ordnung.
Gerne kann ich einen Busmater (LinkUSBi oder den Eclo USB) zum Testen leihweise zur Verfügung stellen, wenn das hilft.
Lg
Daniel
Gesendet von iPhone mit Tapatalk
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
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
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_TestIch 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_TestIch 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
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
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
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
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
@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 (http://www.fuchs-shop.com/de/shop/6/1/13372059/) 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 (http://www.fuchs-shop.com/de/shop/17/1/13372186/)? 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
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
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
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
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
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
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
Bitte die angehängte Version einspielen und entweder manuell laden oder FHEM restart.
LG
pah
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 ESPEasyFalls es nützlich ist, kann ich auch einen normalen DS1820B dranhängen und testen.
Danke + Gruß
Peter
Ö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
Hi,
ich habe ein DS2482S-100 1-Wire Interface an einen MAX!CUBe angeschlossen. Dieser ist mit der gleichen a-culfw@arm Firmware von Telekatz wie der mapleCUN geflasht, da darin 1-Wire direkt vorgesehen ist.
Als Version gibt der CUBE dies aus: V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_C3 (F-Band: 868MHz)
Im 00_OWX.pm (Ver. 16437) habe die den CUBE so wie den mapleCUN mit eingefügt; dann wird er erkannt:
193: }elsif( $defs{$dev} && $defs{$dev}->{VERSION} && $defs{$dev}->{VERSION} =~ m/CSM|CUNO|CUBE|MapleCUN...(4|5|6|7|C|D|E|F)/ ){
so ist er in FHEM (Update erst heute) definiert:
define CUBEX CUL 192.168.69.145:2323 1536
define define CUBE_1W OWX CUBEX
Es wird auch per autocreate der erste 1-Wire-Sensor DS1820 angelegt und gibt auch die Temperatur aus, aber das Log gibt noch dann folgendes aus bis zum fhem-Crash:
2018.04.16 21:46:40 1: OWX_CCC::Define COC/CUNO device CUBEX defined
2018.04.16 21:47:16 1: OWX_Discover: 1-Wire devices found on bus CUBE_1W (OWX_10_C6A253020800)
2018.04.16 21:47:27 1: PERL WARNING: Use of uninitialized value $err in concatenation (.) or string at ./FHEM/11_OWX_CCC.pm line 426.
2018.04.16 21:47:27 1: OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x06 0x10 0x49
2018.04.16 21:47:40 1: OWX_Init called for bus CUBE_1W with interface state opened, now going for detect
2018.04.16 21:47:42 1: OWX_CCC::Detect: 1-Wire bus CUBE_1W interface in CUBEX could not be addressed, return was V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_C3 (F-Band: 868MHz)
2018.04.16 21:52:27 1: OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x06 0x10 0x49
2018.04.16 21:57:27 1: OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x06 0x10 0x49
2018.04.16 22:02:27 1: OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x07 0x10 0x8d
2018.04.16 22:05:55 0: Server shutdown
2018.04.16 22:05:55 1: Shutdown executed
2
Kurz darauf darauf startet der fhem service neu !? (sieht ähnlich aus wie in der obigen Nachricht an PeMue)
Unklar ist mir auch wie in 11_OWX_CCC (und ggf. anderen OWX_...) der CUBE eingefügt werden kann, um die Meldung "... CUBEX could not be addressed ..." zu vermeiden.
Gruß Phantom
Mir auch, denn ich kann keine Hardware testen, über die ich nicht verfüge.
LG
pah
Hi pah,
OK, ohne CUBE oder mapleCUN ist das problematisch. Ich habe noch etwas weiter getestet und folgendes herausgefunden:
a) Der FHEM-Crash/Restart nach kurzer Laufzeit passiert nur wenn ein zweiter Test-FHEM den gleichen CUBE auf der gleichen IP-Adresse anspricht.
Dies sollte man natürlich nicht so machen ... :P
b) Dann habe ich in 11_OWX_CCC.pm mal den CUBE wie den CUNO mit eingefügt:
88c88
< my $msg = "OWX_CCC::Define COC/CUNO/CUBE device $dev";
---
> my $msg = "OWX_CCC::Define COC/CUNO device $dev";
101c101
< $hash->{INTERFACE} = "COC/CUNO/CUBE";
---
> $hash->{INTERFACE} = "COC/CUNO";
163,167d162
< #-- CUBE
< }elsif( $ob =~ m/.*CUBE.*/){
< $interface="CUBE";
< $ress .= "DS2482 / CUBE detected in $hwdevice->{NAME}";
< $ret=1;
649,650c644
< =end html_DE
< =cut
---
> =end html_DE
\ Kein Zeilenumbruch am Dateiende.
Damit wäre die Fehlermeldung "... could not be addressed ..." auch erledigt. (das =cut am Ende ist für die Optik beim diff ;) )
c) Nur eine (vermeintliche?) Fehlermeldung in 11_OWX_CCC.pm wird mir nicht klar :
2018.04.17 12:41:13 1: PERL WARNING: Use of uninitialized value $err in concatenation (.) or string at ./FHEM/11_OWX_CCC.pm line 431.
2018.04.17 12:41:13 1: OWX_CCC::Read from CUNO with error=: 0xff 0xff 0xff
2018.04.17 12:41:15 1: OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x04 0x10 0xd8
2018.04.17 12:41:15 1: OWXTHERM_BinValues: OWX_10_C6A253020800: no error, 24.5 0x31 0x00 0x4b 0x46 0xff 0xff 0x04 0x10 0xd8
2018.04.17 12:42:02 1: OWX_Init called for bus CUBEX_1W with interface state opened, now going for detect
2018.04.17 12:42:04 1: OWX_CCC::Detect: 1-Wire bus CUBEX_1W interface DS2482 / CUBE detected in CUBEX
2018.04.17 12:42:04 1: OWX_Discover: 1-Wire devices found on bus CUBEX_1W (OWX_10_C6A253020800)
2018.04.17 12:46:14 1: OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x04 0x10 0xd8
2018.04.17 12:46:14 1: OWXTHERM_BinValues: OWX_10_C6A253020800: no error, 24.5 0x31 0x00 0x4b 0x46 0xff 0xff 0x04 0x10 0xd8
In Zeile 431 wird beim zweiten (um 12:41:15) und allen weiteren Read's eine Fehlermeldung für eigentlich korrekte Daten ausgegeben:
OWX_CCC::Read from CUNO with error=: 0x31 0x00 0x4b 0x46 0xff 0xff 0x05 0x10 0x1c
Dies ist eine korrekte Temperatur vom DS1820, die OWXTHERM auch verarbeitet.
Der erste Read-Error mit "0xff 0xff 0xff" kommt nur einmalig beim Start vor.
Ggf. ließe sich die PERL WARNING und die folgenden Error's bei eigentlich korrekten Daten noch "optimieren".
Das ganze dürfte auch für den MapleCUN von Interesse sein...
Gruß Phantom
OK, danke für die Zuarbeit.
Maßgeblich ist
ZitatOWXTHERM_BinValues: OWX_10_C6A253020800: no error, 24.5 0x31 0x00 0x4b 0x46 0xff 0xff 0x04 0x10 0xd8
Die andere Meldung könnte ein Überbleibsel aus einer Testphase sein, die kann man eigentlich komplett herauswerfen.
LG
pah
Gerne !
wenn mal Zeit da sein sollte, könnten der CUBE, der =cut und die "Fehlermeldung" in die nächste Überarbeitung des Moduls mit einfließen.
Bis dahin werde ich die Meldung auf Loglevel verbose=5 setzen. Die Module laufen, ja nun mit dem MAX!CUBE und 1-Wire.
Gruß Phantom