1-Wire Busmaster DS2480B fällt sporadisch aus.

Begonnen von Spartacus, 30 Dezember 2019, 17:44:34

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Natürlich muss man abwarten, bis der Busmaster die Devices gefunden hat.

LG

pah

Spartacus

Hallo,
ich habe immer noch das Problem mit dem Typ OWAD und dem DS2450. Nach einem fhem Neustart und einem kompletten Neustart will der 2450 nicht mehr. Die Werte werden auch nach set initialize 1 nicht automatisch aktualisiert. Eine manuelle Abfrage klappt. Ich habe mir sogar den 1-wire Adapter getauscht und den Denkovi installiert.  Hilft alles nichts! Kann jemand helfen?

Christian.

P.S. die Konfiguration ist unverändert zu den oben geposteten Settings
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Spartacus

Hallo zusammen,
ich setzte gerade mein fhem als VM auf und habe akatuell ein Problem den 1-wire Busmaster an die VM durchzureichen. Ich habe alle USB-Geräte über einen aktiven USB HUB an meinen VM-Server angebunden.

USB0: Rademacher DUOFERN
USB1: der Denkovi 1-Wire Busmaster

Beide Devices laufen in der VM problemlos.


Sobald ich aber meinen JeeLink V3 anbinde, steigt der Denkovi aus; d.h. Die beiden Sensoren DS2438 und DS2450 liefern keine Werte mehr (nur "0"), obwohl das OWX Device den Status "open" anzeigt.

ls -l /dev/serial/by-id/*
lrwxrwxrwx 1 root root 13 Jan 13  2021 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702GA4R-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jan 13  2021 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 13  2021 /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00S1I0-if00-port0 -> ../../ttyUSB0


Der Jeelink funktioiert in Kombination mit dem DUOFER-Stick ebenfalls sauber, aber der 1-wire Busmaster steigt dann aus!

Definition in fhem:
defmod 1Wire.GW OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 rt0\

attr 1Wire.GW asynchronous 0
attr 1Wire.GW group Gateway
attr 1Wire.GW icon cul
attr 1Wire.GW room 98-Gateway


Hat jemand eine Idee, an welcher Schraube ich drehen kann?
Auf einem rpi4 laufen alle USB-Devices perfekt zusammen.

Jeelink:

defmod Lac.JeeLinkV3 JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702GA4R-if00-port0@57600


alterniv:
defmod JeeLinkV3.GW JeeLink /dev/ttyUSB2@57600


Hat jemand eine Idee?
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Prof. Dr. Peter Henning

Ich tippe auf die Identifikation per serial-by-id.

LG

pah

Spartacus

Hi pah,
Zitat von: Prof. Dr. Peter Henning am 14 Januar 2021, 19:41:07
Ich tippe auf die Identifikation per serial-by-id.

LG

pah
Was genau meinst Du damit? Wird diese ggf. nicht sauber an die VM durchgereicht?
Ich habe jetzt 5 USB-Devices an dem VM-Fhem. Alle funzen korrekt, nur dieser 1-Wire Adapter nicht. Ab un zu, läuft er dann für ein paar Minuten und plötzlich werden dann die OW-Devices nicht mehr ausgelesen...
Hast Du eine Idee, wie man das hier hinbiegen kann?

Auf dem pi hat der Stick diese ID:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 -> ../../ttyUSB0

Oder muss ich hier per /dev/ttyUSBx einbinden?
Gruß,
Spartacus

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Prof. Dr. Peter Henning

ZitatWird diese ggf. nicht sauber an die VM durchgereicht?
Könnte sein. Die Enumeration auf dem Bus wird vom Host vorgenommen. In VirtualBox muss ich auswählen, welche der USB-Geräte an den Guest weitergegeben werden - das kann zu einer ganz anderen Enumeration führen.

Ich würde da aher nach der Seriennummer des Controllers gehen, um feste Device-Adressen zuzweisen.

LG

pah

Spartacus

Hallo pah,
da kann ich bei der Virtualization Station auf der qnap leider nicht viel einstellen (siehe Bild)

lrwxrwxrwx 1 root root 13 Jan 16 14:36 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702GA4R-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 16 14:36 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jan 16 14:36 /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00S1I0-if00-port0 -> ../../ttyUSB1

Ich probiere es noch mal mit  /dev/ttyUSB2

Was heisst eigentlich dieses "rt0" hinter der Portbezeichnung. Die baut fhem offenbar automatisch ein.
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 rt0

Falls ich das Teil nicht ans Fliegen kriege, muss ich auf einen anderen Adapter ausweichen; ggf. etwas was man per LAN anbinden kann. Ich habe nur zwei 1-Wire Sensoren in meinem Gartenhaus Gibt es da ein möglichst fertiges Gerät, was zu empfehlen ist, damit Ruhe ist?
Danke und Gruß
Spartacus

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Spartacus

Hallo pah,
ich habe jetzt den Controller über USB2 (siehe vorherigen Post) angebunden. Soweit scheint das zu laufen.
Nach einem Reboot der VM:

  • OWMULTI ist direkt nachdem OWX sich bekrabbelt hat (ca. 60s), wieder am Start
  • OWD muss manuell mit einem get readings und set intervall 600 zum Leben erweckst werden.
dieser Code allerdings, funktioniert nicht!
defmod FHEMStart notify global:INITIALIZED.* sleep 120; get DS250 reading; set DS2450 interval 600

das set DS2450 initialize 1 bewirkt, das OWX auf disconnect geht!

:-(
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Prof. Dr. Peter Henning

Versuch mal die angehängten Versionen, und lass bei "initialize" den Parameter 1 weg.

LG

pah

Spartacus

#24
Hi pah,
zunächst möchte ich mich bei dir für den erstklassigen Support bedanken. Das ist wirklich toll!

Ich habe deine Dateien eingespielt und der Befehl "initialize" funktioniert perfekt! Es scheint auf den ersten Blick auch so zu sein, dass das per Attribut eingestellt Interval wieder korrekt arbeitet. Das musste ich nach einem Neustart des Rechners immer zu Fuß setzten.

Ich habe dann den Controller vom Host getrennt (stromlos gemacht) und die fhem VM neu gestartet. Das ist dem Controller nicht gut bekommen. OWX hat sich beim ersten Start von fhem nicht automatisch "geöffnet". Nach 3min habe ich dann das OWX-Gerät zu Fuß mit einem reopen aktiviert. Das OWAD-Device war dann auch nach einem "Initialize" direkt wieder am Start, das OWMULTI Device meldet leider keine Werte mehr!

OWMULTI: Could not get values from device GH.in.1W.DS2438, reason 26.09DB84000003.ec has returned invalid data
OWMULTI: GH.in.1W.DS2438.reading => Feuchte:  0.00 % (T:   0.0 °C vs:  0.00 V vs.t:  0.00 Vs)

Die ID kann ich mit einem get sauber auslesen...keine Ahnung, was das Teil jetzt plötzlich hat!
Komischerweise läuft alles perfekt am pi4 mit dem gleichen USB-Kabel. Am USB HUB, der an der qnap hängt, kann es auch nicht liegen, denn wenn ich den Controller an einen anderen freien USB-Port (ohne HUB) der QNAP packe, habe ich das gleiche Problem...

Hast Du noch eine Idee?
Danke und Gruß,
Spartacus

NACHTRAG:
Habe das NAS neu gestartet, den HUB getauscht...OWMULTI kommt nicht mehr ans Fliegen. Stöpsel ich USB an den pi, läuft alles direkt, ohne fhem neu zu starten...ich denke, es ist eine Inkompatibilität des USB Controllers mit der QNAP und damit wohl nicht zu fixen! Schade eigentlich. Da ich den pi ablösen will, muss ich mir wohl eine Alternative suchen. Ich will auf jeden Fall etwas was ich nicht warten muss, sprich Betriebssystem aktualisieren. Gibt es da irgendwas was man sich anschauen könnte?

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Prof. Dr. Peter Henning

Na ja, man könnte noch verbose=5 setzen. Dann gibt es allerdings tonnenweise Daten. Die neuen Fehlermeldungen deuten darauf hin, dass irgendetwas beim Timing auf dem Bus nicht stimmt - es kann natürlich sein, dass die Weiterreichung an die VM hier irgendwelche Latenzen einbaut, beim OWMULTI ist das schon eine ganze Menge Verkehr auf dem Bus.

Ist denn das asynchron-Attribut gesetzt? Ändert sich etwas an dem Problem, wenn der Busmaster synchron oder asynchron betrieben wird?

Und bitte was soll nun ersetzt werden? Die Hauptplattform für FHEM?

LG

pah

Spartacus

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Spartacus

Hi pah,
hm! Jetzt bin ich verwirrt. Wenn ich den OWX auf asynchron stelle (am pi), kann ich die Devices nicht mehr auslesen. Weder den DS2450, noch den DS2438. Ein get reading liefert keine Werte zurück.

Muss ich da noch weitere Parameter setzten?
Meine Konfiguration sieht so aus:
defmod 1Wire OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 -> ../../ttyUSB0\

attr 1Wire asynchronous 0
attr 1Wire group Server,
attr 1Wire icon cul
attr 1Wire room 98-Geräte -> 1-Wire

setstate 1Wire opened
setstate 1Wire 2021-01-17 21:16:08 queue 0
setstate 1Wire 2021-01-17 21:16:14 state opened


defmod GH.in.1W.DS2438 OWMULTI DS2438 09DB84000003
attr GH.in.1W.DS2438 DbLogInclude temperature,Feuchte,Taupunkt,absFeuchte
attr GH.in.1W.DS2438 IODev 1Wire
attr GH.in.1W.DS2438 VFunction (161.29 * V / VDD - 25.8065)/(1.0546 - 0.00216 * T)
attr GH.in.1W.DS2438 VName Feuchte
attr GH.in.1W.DS2438 VUnit %
attr GH.in.1W.DS2438 alias DS2438
attr GH.in.1W.DS2438 comment Sensor: SHT35
attr GH.in.1W.DS2438 event-min-interval .*:600
attr GH.in.1W.DS2438 group Sensoren
attr GH.in.1W.DS2438 icon temperature_humidity
attr GH.in.1W.DS2438 model DS2438
attr GH.in.1W.DS2438 room 98-Geräte -> 1-Wire
attr GH.in.1W.DS2438 stateFormat {sprintf("T: %.2f°C, H: %.2f %%",ReadingsVal("$name","temperature",0),ReadingsVal("$name","Feuchte",0) )}


defmod GH.au.1W.DS2450 OWAD DS2450 F9DA84000003
attr GH.au.1W.DS2450 AHigh 5.1
attr GH.au.1W.DS2450 ALow 0
attr GH.au.1W.DS2450 BHigh 5.1
attr GH.au.1W.DS2450 BLow 0
attr GH.au.1W.DS2450 CHigh 5.1
attr GH.au.1W.DS2450 CLow 0
attr GH.au.1W.DS2450 DHigh 5.1
attr GH.au.1W.DS2450 DLow 0
attr GH.au.1W.DS2450 DbLogInclude Temperatur,Feuchte,absFeuchte,Taupunkt,Helligkeit,Luftdruck
attr GH.au.1W.DS2450 IODev 1Wire
attr GH.au.1W.DS2450 alias DS2450
attr GH.au.1W.DS2450 comment Sensoren:Helligkeit: MAX44009 Feuchte/Temperatur: SHT 21 Luftdruck: BMP280
attr GH.au.1W.DS2450 event-min-interval .*:600
attr GH.au.1W.DS2450 group Sensoren
attr GH.au.1W.DS2450 icon temperature_humidity
attr GH.au.1W.DS2450 model DS2450
attr GH.au.1W.DS2450 room 98-Geräte -> 1-Wire
attr GH.au.1W.DS2450 stateFormat {sprintf("T: %.2f°C, H: %.2f %%",ReadingsVal("$name","Temperatur",0),ReadingsVal("$name","Feuchte",0) )}
attr GH.au.1W.DS2450 userReadings Temperatur {sprintf("%0.2f",(ReadingsNum("$name","A",0)-2.56)*128)},\
Feuchte {sprintf("%0.2f",ReadingsNum("$name","B",0)*128)},\
Helligkeit {sprintf("%0.2f",exp((ReadingsNum("$name","C",0)-2.56)*12.8))} ,\
Luftdruck {sprintf("%.d",ReadingsNum("$name","D",0)*400)}


Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Prof. Dr. Peter Henning

Natürlich liefert das keine Werte zurück - "asynchron" heißt (auch), dass diese nur irgendwann (eben dann, wenn sie geliefert wurden) im Reading auftauchen. Sie werden aber nicht in einem Extra-Fenster angezeigt. Das Modul macht dabei eine sehr komplizierte interne Warteschleife auf.

LG

pah

Spartacus

#29
Hallo pah,
vielen Dank für den Hinweis! Das war mir so nicht klar!

Ich habe es jetzt auf async umgestellt.

  • Das OWX-Device kommt nach einem Reboot nicht selbständig auf die Beine. Ich muss das nach einiger Zeit zu Fuß anstoßen.
  • Der DS2450 ist direkt nach dem initialisieren wieder da.
  • Der DS2428 braucht ewig lange...aber irgendwann liefert auch er Werte.

Ich werde das noch ein wenig austesten um auszuschließen, dass dies keine Zufälle sind und melde mich dann noch mal auf diesem Kanal!

Spartacus

Nachtrag 1:
das OWX-Device kommt nach einem Neustart nicht immer von selbst auf die Beine, wenn ich es per
"/dev/serial/by-id" einbinde.

fhem-Log:
OWX_SER: Can't open serial device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0: No such file or directory
Mir ist aber nicht klar, was hier falsch sein soll, zumal ein "repopen" im Betrieb funktioniert.
Auf der Linux-Ebene ist das Device aber korrekt eingebunden. Ggf. sollte ich fhem mal verzögert starten....

Nachtrag 2:
habe jetzt mal ein Verbose 5 eingebaut. So wie ich es verstehe, scheint das OWX-Modul immer korrekt zu starten, obwohl der state auf "disconnect" steht und erst auf "open" geht, wenn er von den Devices gültige Daten empfängt. Ich dachte, er geht auf "open" wenn er bereit ist!

Man kann im Log sehen, dass er alle 5min den 2438 befragt und Daten erwartet. Irgendwann kommt dann offenbar ein wieder "init" vom OWX und irgendwann antwortet der 2438 auch.
Der 2450 ist nach dem manuellen initialisieren immer immer da, manchmal auch ohne manuelle iIitialisierung.

Was ich nicht verstehe ist, warum es teilweise mehrere Minuten dauert, bis der 2438 antwortet...aber irgendwann ist er halt da!

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R