Denkovi Busmaster ohne Funktion. Tips?

[tho-mas]

Moin!

Seitr ca. 6 Jahren läuft meine FHEM-Installation mit ca. 20 bis 30 1Wire Sensoren. Vor 3 Tagen habe ich ein Update gemacht (Bullsey/Raspi4 und FHEM ("Update"). Erst kamen keine Werte von den Sensoren, ich habe dann mehrfach neu gestartet (Strom raus - 10 s gewartet - Strom an. Neustart per Menü der RaspPi Oberfläche. Nur USB-Stecker für 10 s vom Master abgezogen). Half alles nichts.

Die genaue Beobachtung der beiden LEDs auf den Busmaster:
Bei Strom an blinken beide LED kurz auf, nach einigen Sekunden noch einmal beide kurz an, dann absolute Stille.

Ich weis das bei normalem Betrieb die LEDs immer nach einiger Zeit (20s? 1 min?) unregelmäßig aufblitzen (Datenverkehr auf dem 1Wire).

Was kann das sein? Wegen Software? Oder Hardware defekt?

Gruß
Thomas

[Frank_Huber]

Bitte mal ein list vom Gerät.

[tho-mas]

Ich hoffe du meinst mit "Gerät" den OWServer. Falls nicht, dann präzesiere die Frage bitte.

Code Auswählen Erweitern

Internals:
   DEF        localhost:4304
   FUUID      61e34760-f33f-1cdf-20d7-b4b55a8aa31e0dce
   LAST_READ_FAILED 0
   NAME       1wire
   NOTIFYDEV  global
   NR         46
   NTFY_ORDER 50a-1wire
   OWNET_VERSION 3.1p5
   STATE      Initialized
   TYPE       OWServer
   eventCount 2
   READINGS:
     2022-12-17 09:12:47   /settings/reopen 0
     2022-12-16 20:40:02   /settings/timeout/directory 60
     2022-12-16 20:40:02   /settings/timeout/ftp 900
     2022-12-16 20:40:02   /settings/timeout/ha7 60
     2022-12-16 20:40:02   /settings/timeout/network 1
     2022-12-16 20:40:02   /settings/timeout/presence 120
     2022-12-16 20:40:02   /settings/timeout/serial 5
     2022-12-16 20:40:02   /settings/timeout/server 10
     2022-12-16 20:40:02   /settings/timeout/stable 300
     2022-12-16 20:40:02   /settings/timeout/uncached 0
     2022-12-16 20:40:02   /settings/timeout/usb 5
     2022-12-16 20:40:02   /settings/timeout/volatile 15
     2022-12-16 20:40:02   /settings/timeout/w1 30
     2022-12-16 20:40:02   /settings/units/pressure_scale mbar
     2022-12-16 20:40:02   /settings/units/temperature_scale C
     2022-12-17 11:04:35   state           Initialized
   fhem:
     protocol   localhost:4304
Attributes:
   nonblocking 1

[Frank_Huber]

Ja, das war schon so gemeint.
Nur bei OWServer bin ich raus. Ich nutze den Denkovi mit dem OWX Modul.

Denke du musst deinen Fehler im OWServer suchen.

[tho-mas]

Wenn ich den Fehler selbst suchen könnte würde ich hier nicht fragen...

[rob]

Wahrscheinlich ist detektivisches Rantasten nötig, weil imho verschiedene Ursachen Infrage kommen.
Hast Du die Möglichkeit nur einen DS18B20 o.ä. direkt am Schraubterminal vom Denkovi anzubringen (anstelle d. kompletten Busses)?
Einmal mit OWServer testen, ob der erkannt wird. Wenn nicht, OWServer stoppen und mit OWX stattdessen testweise einbinden, wie Frank bereits vorschlägt. Wird dann was erkannt? Wenn nein, spräche m.E. viel für den Denkovi als Ursache. Notfalls Testreihe mit anderem DS18B20 wiederholen.
Wie hast Du den Jumper am Denkovi gesetzt - RC-Filter aktiv? Im Zweifel Jumper ändern und Testreihe wiederholen.
Mal schauen ob/ wo etwas "zuckt"  und dann tasten wir weiter

[tho-mas]

Moin!

Rob, vielen Dank für die konstruktiven Ideen. Vieles läßt sich erst nach der Arbeit probieren. Einzelne DS18B20 habe ich noch liegen, Ergebnis eben am Abend. OWServer habe ich vor vielen Jahren nach Anleitung eingerichtet, OWX sagt mir im Moment gar nichts. Den Jumper habe ich testweise schon gestern mal umgesetzt, keine Änderung des Verhaltens.

Gruß vom der Glatteisbahn (NINA warnt schon)

Thomas

[rob]

Moin Thomas.

Lass Dich da draußen bloß nicht aufs Glatteis führen
Scherz beiseite: gerne in Ruhe schauen und Schritt für Schritt ausschließen. Oft gerät man in Panik, ändert viel auf einen Schlag und weiß am Ende nicht mehr was alles. Sollte der Denkovi in einer Situation doch noch tun, wären in dieser ggf. die Nodes und der Bus zu prüfen. Ggf. schwieriger per Ausschlussverfahren, deshalb erst mal am verdächtigen Busmaster starten.

OWX ist ganz easy:

Code Auswählen Erweitern

define <name> OWX <serial-device>
Normalerweise wird Dir per Autocreate dann ein Device für den DS18B20 angelegt (z.B. OWX_10_blablabla).

Wär halt interessant, weil Du ja auch vom Zusammenhang mit dem Update schreibst.
Btw.: Kam nur Bullseye auf die Kiste und es war vorher schon der Raspi4 oder ist der Raspi auch neu? Frag nur, weil es beim USB hier und da Probleme geben soll. Das wäre die nächste Testreihe: längeres USB-Kabel, USB2-Hub usw.

Interessant auch wie der Denkovi konkret eingebunden wird:

Code Auswählen Erweitern

dmesg | grep usb

Code Auswählen Erweitern

ls -lah /dev/serial/by-id

Aber Schritt für Schritt 

VG
rob

[enno]

Moin Thomas,

die Infos für OWX hast du ja schon hier eingesammelt: https://forum.fhem.de/index.php/topic,130974.0.html

Es müsste bei dir dann so heissen:

Code Auswählen Erweitern

define OWX-Device OWX /dev/ttyUSB0

Gruss
  Enno

[tho-mas]

Moin!

So, ein direkt angeklemmter Sensor liefert keine Werte.

Das define von OWX habe ich gemacht (aber nicht USB0, sondern USB1), das "OWX_Device" ist sichtbar, per drop-Down wird mir angezeigt das Geräte da sind. Aber ich sehe sie nicht (FHEM-Webseite). Der Einzelsensor ist sichtbar, nach dem Essen klemme ich die anderen Kabel wieder an.

OWServer stoppen: Da muß ich erst noch mal suche, ich habe den "alten" OWServer erst mal gelöscht.

Der Pi4 ist seit mind. 2 Jahren unverändert in Betrieb, mit Bullenaugen seit mind. Februar 22, letzte Woche kam nur eine Onlineaktualisierung. Warum längeres USB-Kabel? Ein Hub ist nicht dazwischen (es sei denn, der Pi4 hat sowas "eingebaut").

Was mir noch eingefallen ist: Stimmt vielleicht die Zuordnung OWServer zur USB-Schnittstelle nicht mehr? Mir ist so als wäre da vor längerer Zeit was gewesen.

Gruß
Thomas

[TomLee]

Das define von OWX habe ich gemacht, das "OWX_Device" ist sichtbar, per drop-Down wird mir angezegt das Geräte da sind.

Schwer vorstellbar mit

Code Auswählen Erweitern

define OWX-Device OWX /dev/ttyUSB0 nach dem Bild sollte es ttyUSB1 sein.
Besser wär über die Serial-ID einzubinden.

Wäre dann

Code Auswählen Erweitern

define OWX OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0

Wenn der Adapter OK ist, landen die automatisch erkannten Devices Stück für Stück im Raum OWX, schneller gehts mit einem

Code Auswählen Erweitern

get OWX devices

[tho-mas]

TomLee:

Deine Idee mit Serial-ID funktioniert nicht:

Code Auswählen Erweitern

Unknown module /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0

[TomLee]

Wenn du meine gezeigte Definition genauso in der Befehlszeile oben in FHEMWEB eingibst, kann ich mir nicht vorstellen das es zu dieser Meldung kommt, irgendwas (vorne im define) musst du geändert haben, zeig mal.

[tho-mas]

Wenn ich

define OWX OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0


einkopiere kommt erstmal keine Fehlermeldung, aber nach wenigen Minuten ein "disconnect". Und KEINE Meßwerte, obwohl der Busmaster zwischendurch gut blinkte.

Ich hatte zuerst das 2fache OWX für einen Vertipper gehalten und eines davon gelöscht. War wohl zu gut gemeint, da kam die Fehlermeldung.

[TomLee]

Was steht im Log ? Meine das ich das schon richtig von dem Screenshot abgelesen hab, aber zur Sicherheit : Zeig mal was im Log steht nachdem du oben in der Befehlszeile

Code Auswählen Erweitern

"ls -lah /dev/serial/by-id" eingegeben hast.