OWX MAJOR UPDATE

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

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

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

ext23

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
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

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

ext23

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
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

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

cwagner

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
PI 2B+/3B+ Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

Prof. Dr. Peter Henning

Muss ich überprüfen.

LG

pah

Jojo11

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

Prof. Dr. Peter Henning

Keine Änderungen seit Wochen.

LG

pah

Frank_Huber

vielleicht nach dem Uodate den "shutdown restart" vergessen?
Da kann es dann immer mal komische Effekte geben.

Jojo11

#70
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.

PichlAlex

#71
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

PeMue

Hallo pah,

könntest Du bitte bei Gelegenheit Telekatz' patch für 00_OWX.pm für den mapleCUx übernehmen?

Danke + Gruß

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

Prof. Dr. Peter Henning


synaps-o-dan

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