1-Wire Busmaster DS2480B fällt sporadisch aus.

[Spartacus]

Hallo,
seit einigen Wochen betreibe ich den o.a. Busmaster, den ich für kleines Geld by EBAY als USB-Stick erworben hatte. Ich komme vom 9490R, der jahrelang mit diversen Sensoren einem DS2450 und einen DS2438 lief. Da ich mein fhem nun auf eine neue HW (pi4b) gepackt habe, bin ich auch gleich auf den anderen BUSMASTER umgestiegen, da er wesentlich einfacher einzubinden ist.

Aber irgendwie läuft das Ganze nicht mehr stabil.

Mein DS2450 wird sporadisch nicht erkannt und liefert dann auch keine Readings. Erst eine Abfrage mit  "get Devices" reaktiviert ihn wieder; der DS2438 läuft am selben BUS stabil. Das ist ziemlich Käse, da man das nicht merkt und ständig kontrollieren muss.  Ich habe auch die Variante mit dem 4k7 zwischen Data und 5V probiert (beim DS9490R niemals benötigt). Das ändert leider nichts und jetzt ist mir auch noch die Feder dieser doofen Anschlussklemme abgebrochen und ich musste die Kabel direkt anlöten. Da der Entwickler den "Billig-WAGO"-Klemmsockel auf die Platine geklebt hat, kann ich ihn nicht austauschen. Also brauche ich Ersatz.

Frage:
Kennt jemand ein solides, halbwegs bezahlbares Fertiggerät (am Besten was man direkt ins LAN hängen kann)? Ich muss das schnell wieder in einen stabilen Zustand kriegen und den 9490R möchte ich eigentlich nicht mehr reaktivieren...

Danke und Gruß,
Christian

[Spartacus]

Hallo,
hier noch einmal mein Hilferuf! Der 1-Wire Sensor hat immer nach einem fhem-Neustart das Problem, dass er initialisiert wird.

Aktueller Workaround nach fhem-Neustart/Reboot:
- "get readings" beim DS2450
- "repopen" beim OWX-Server

Danach läuft das OWAD-Device wieder sauber und aktualisiert auch regelmäßig automatisch seine Readings.
Wie gesagt, der DS2438 läuft ohne Probleme am selben BUS.

Wenn hier niemand eine Idee hat, was ich noch testen könnte, dann bleibt mir wohl nix anderes übrig, als den OWX an den Nagel zu hängen und mir wieder einen separaten PI mit OWSERVER und DS9490R aufzubauen.

Hier mal die Konfig vom OWX-server:

Code Auswählen Erweitern

defmod 1Wire OWX /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
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 2020-01-04 08:30:16 queue 0
setstate 1Wire 2020-01-04 08:30:16 state opened

Spartacus.

[Beta-User]

Der supplier hat nicht nur an den Wagos gespart, sondern sich am USB-Seriell-Wandler.
Gibt es weitere USB-Geräte?

Hatte mal ein IO von Denkovi, das war mit FTDI.

[Spartacus]

Hallo Beta-User,
danke Dir fürs Feedback. Ja, da hängt noch nen Enocean-Stick und nen Jeelink dran. Der 1-Wire Adapter ist dann quasi USB-Gerät Nr.3 an dm Pi4
Tja, dann kann ich das Billig-Dingen wohl in die Tonne kloppen!

Ich hatte schon überlegt, ob ich einen ausgemusterten Pi2 nehme, und wieder OWSERVER drauf packe. Das lief ja ziemlich stabil und war damals mittles fhem2fhem gekoppelt. Fhem2Fhem will ich aber nicht mehr. Die Frage ist dann nur, wie man die 1-wire Sensoren dann von einem Fhem-server einbindet, wenn sie auf einem anderen Pi bereitgestellt werden!"

Eigentlich wollte ich für meine zwei 1-Wire Meßstellen eine einfache solide Lösung, aber so wie es aussieht, wird es doch komplizierter.
Schade!

Christian

NACHTRAG:
Was ist denn mit diesem Dingen hier? Wäre das eine Alternative?
https://www.ebay.de/i/171041719472

[Beta-User]

Den verlinkten hatte ich gehabt.

Einen separaten Pi dafür (und dann noch mit GPIO) halte ich für Overkill und die falsche Lösung, ich habe das (bzgl. DS18B20) auf MySensors umgebaut. Wenn du nur 2 DS18B20 hast, kannst du die auch an einen (FTDI!) Arduino hängen und z.B. mit Firmata arbeiten (ich würde allerdings einen eigenen Sketch empfehlen, das ist aber sehr viel schwieriger).
Was auch geht: Einen ESP8266 als Busmaster verwenden (ist aber auch nicht meine bevorzugte Lösung für wichtige Sensorik und Aktoren, da WLAN und vergleichsweise stromhungrig). Im Wiki sollten  ggf. noch weitere Alternativen zu finden sein.

Was die beiden anderen USB-Geräte angeht: Die sollten sich auf OS-Ebene (by-id) von dem CH340-Gerät (usb-1a86) unterscheiden lassen, aber eben auch "by-id" eingebunden sein.

[Spartacus]

Hallo,
Ich danke Dir für die Ausführungen. Der verlinkte Adapter. Funktioniert das denn damit? Jetzt wieder nen Faß aufmachen und rumbasteln mit Arduino, will ich nicht unbedingt. Ich nutze nen Ds 2450 und den Ds 2438.Das sind zwei Multisensoren, die an dem Bus hängen...die sind hier auch über das Forum bekannt.

Der Jeelink und Enocean Stick sind beide auch by id eingebunden .

Christian

[Beta-User]

Nochmal: der Denkovi war OK...

[Spartacus]

..sorry, hatte ich nicht gerafft, dass der "Verlinkte"  = Denkovi  ist!

Bis dann,
Christian

[Prof. Dr. Peter Henning]

Ich verstehe imme rnoch nicht ganz, was das Problem ist - was genau meldet das OWAD-Device denn im Log, wenn der Fehler auftritt? Der DS2450 ist etwas diffizil im Timing, und muss nach einem kompletten Neustart (=Ausfall der Spannung) auf jeden Fall initialisiert werden.

LG

pah

[Spartacus]

Hi pah,
nach nem Neustart, steht Folgendes im Log:

Code Auswählen Erweitern

2020.01.04 08:30:19 3: OWAD:     Device GH.au.1W.DS2450 defined.

..und das war es dann! Er liefert keine Messwerte. Erst wenn ich den o.a. Workaround zu Fuß durchführe, werden die Messwerte übertragen. Was genau meinst Du mit "...auf jeden Fall initialisieren"?
Ich dachte, das wird nach nem Neustart automatisch durchgeführt?

Unabhängig davon habe ich noch ein Warning im Log, die regelmäßig auftaucht.

Code Auswählen Erweitern

2020.01.03 16:53:52 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/21_OWAD.pm line 504.

Christian

[Prof. Dr. Peter Henning]

OK, damit kann ich schon mehr anfangen.

Neustart ist nicht gleich Neustart. Wenn die Spannung weg war, muss der DS2450 initialisiert werden, d.h. die Werte für Auflösung etc. an ihn übertragen werden. Vielleicht mal ein undokumentiertes Feature ausprobieren:

Code Auswählen Erweitern

set <Devicename> initialize 1

LG

pah

P.S.: Warum undokumentiert? Das ist in der CommandRef nicht drin, ist erst in der letzten noch etwas frickeligen Überarbeitung mit eingebaut worden.

[Spartacus]

Hi pah,
danke Dir, ich werde das beim nächsten "Fehstart" mal testen.
Aber komischerweise hat das nur der 2450 der 2438 klappt super!

Ich habe mir aber trotzdem mal den u.a. USB-Busmaster von Denkovi  bestellt. Vielleicht läuft das Dingen zuverlässiger!

Ich berichte....
Christian

[cwagner]

OK, damit kann ich schon mehr anfangen.

Neustart ist nicht gleich Neustart. Wenn die Spannung weg war, muss der DS2450 initialisiert werden, d.h. die Werte für Auflösung etc. an ihn übertragen werden. Vielleicht mal ein undokumentiertes Feature ausprobieren:

Code Auswählen Erweitern

set <Devicename> initialize 1

Dieses Set für OWAD-Device hatte ich durch Zufall entdeckt und es funktioniert in meinem Fall so gut, dass ich es in meine Neustart-Routine (ein simples DOIF) eingefügt habe. Dort wird es für alle OWAD-Devices grundsätzlich ausgelöst. Seitdem gibt es keinen Ärger mehr mit "eingefrorenen" OWAD-Devices nach Neustarts.

Christian W.

[Prof. Dr. Peter Henning]

OK, im nächsten Release fällt noch die (unnötige) Angabe des Parameters "1" weg. Und dann ist es auch sauber in der CommandRef aufgeführt.

Übrigens benötigt der DS2438 eine solche Voreinstellung eben nicht...

LG

pah

[Spartacus]

Hallo Christian,
danke für den Hinweis. Wie und wann genau initialisierst Du die Devices, wartest Du nach dem Fhem-start noch ab?
Danke und Gruß,
Christian