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
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:
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.
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.
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 (https://www.ebay.de/i/171041719472)
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.
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
Nochmal: der Denkovi war OK...
..sorry, hatte ich nicht gerafft, dass der "Verlinkte" = Denkovi ist!
Bis dann,
Christian
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
Hi pah,
nach nem Neustart, steht Folgendes im Log:
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.
2020.01.03 16:53:52 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/21_OWAD.pm line 504.
Christian
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:
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.
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
Zitat von: Prof. Dr. Peter Henning am 05 Januar 2020, 13:16:15
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:
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.
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
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
Natürlich muss man abwarten, bis der Busmaster die Devices gefunden hat.
LG
pah
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
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
Ich tippe auf die Identifikation per serial-by-id.
LG
pah
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 -> ../../ttyUSB0Oder muss ich hier per /dev/ttyUSBx einbinden?
Gruß,
Spartacus
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
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
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 600das
set DS2450 initialize 1 bewirkt, das OWX auf disconnect geht!
:-(
Spartacus
Versuch mal die angehängten Versionen, und lass bei "initialize" den Parameter 1 weg.
LG
pah
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?
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
HI
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
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
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 directoryMir 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!
Hallo,
sorry für meine Zwischenfrage habe versucht meinen Post aus dem Anfängerbereich nach ZWave zu verschieben
und hat wohl irgendwie nicht funktioniert und tangiert auch die Problematik mit dem DS2450.
@Pah sind die angehängten Dateien nur für das spezielle Problem von Spartacus gedacht
oder auch für die Allgemeinheit zum Ausprobieren gedacht?
Wenn ich richtig gelesen habe ist derDS2450 im Timing etwas anspruchsvoll,
ansonsten müsste ich an meiner Bus Topologie noch etwas feilen.
Gruß
Hans-Jürgen
Zitat
@Pah sind die angehängten Dateien nur für das spezielle Problem von Spartacus gedacht
oder auch für die Allgemeinheit zum Ausprobieren gedacht?
Kann man testen, werden demnächst released.
LG
pah
Guten Abend zusammen,
ich möchte abschließend noch einmal eine Zusammenfassung meiner Erfahrungen liefern, da es inzwischen halbwegs vernünftig läuft, wenn man ein paar Dinge beachtet.
Test-Umgebung:
- QNAP TVS 672XT mit Virtualization Station 3.0 und OS 4.51
- RSHTECH USB Hub Aktiv 3.0 mit 36W
- DenkoviUSB to One Wire converter - Virtual Com Port FT232RL based
- DS2450
- DS2438
- fhem auf einer Debian 10 VM
Bedingungen:
- die OW-Dateien von pah einspielen
- 1-Wire Adapter per /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06KCu-if00-port0 rto einbinden. (Was das rto bedeutet, weiß ich nicht, OWX meckert es als ungültigen Parameter im fhem-Logfile an; wenn ich es aber weglasse, läuft der Controller nicht)
- Fhem verzögert starten (nano /etc/systemd/system/fhem.service) (Das ist offenbar nötig, da beim Start der VM das saubere durchreichen der USB Hardware etwas Zeit kostet; zumindest hatteich ohne diese Verzögerung oft das Problem, dass der Denkovi von fhem nicht erkannt wurde /serial)
- 1-Wire Controller im asynchronen Betrieb
- OWAD-Device mit "initialize" nach dem Start initialisieren.
z.B.
defmod initDS250 DOIF ([global:?INITIALIZED]) \
(set GH.au.1W.DS2450 initialize)\
DOELSE
attr initDS250 cmdState done|idle
attr initDS250 wait 30
Mir ist aufgefallen, dass der DS2438 nach einem Neustart des Hosts oder der VM sehr lange benötigt, bis er Daten liefert Das kann bis zu 15min dauern. Warum das so ist, kann ich nicht erklären. Im fhem-Log kann man erkennen, dass das OWX-Device mehrfach auf Daten vom DS2438 wartet (Verbose 5). Solange das OWX-Device auf Daten vom DS2438 wartet, meldet es im state "DISCONNECTED" auch wenn DS2450 bereits Daten liefert.
@pah: Nochmals Besten Dank für Deinen Support!
Gruß,
Spartacus
ZitatMir ist aufgefallen, dass der DS2438 nach einem Neustart des Hosts oder der VM sehr lange benötigt, bis er Daten liefert Das kann bis zu 15min dauern.
k.A. Ist mir neu
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 Januar 2021, 22:07:33
k.A. Ist mir neu
....das gilt nur für die fhem-VM! Bei Verwendung von fhem auf dem pi4, ist das nicht so!
Spartacus
Hallo,
ZitatKann man testen, werden demnächst released.
@Pah habe die Dateien von Dir mal ausgetauscht mit fhem service stop und fhem service start.
Hat an beiden FHEM Sorgenkindern Warnmeldungen im Zusammenhang von DS2450 bei 1Wire
und andere Baustelle ZWave nur die Spirits Thermostate mit no Ack.
Die anderen 1Wire Sensoren laufen Monatelang ohne irgendwelche Meldungen.
Bevor ich mich an den Bus mache habe ich irgendwo etwas vergessen richtig einzustellen?
Log von heute morgen...
2021.01.20 00:00:01 2: Deleting fhem-2021-01-19.log
2021.01.20 00:22:22 2: ZWave: No ACK from Thermostat_Gaestezimmer after 5s for sentset:13050326010f2537
2021.01.20 01:00:00 1: SQL Datenbank geleert
2021.01.20 02:55:23 1: OWXTHERM_BinValues: Abgassensor: invalid CRC, -0.0625 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2021.01.20 04:21:39 1: OWXAD_BinValues: context ds2450.getalarm Wettersensor: invalid CRC 0x00 0xff 0x00 0xff 0x00 0xff 0xb6 0xdb 0x00 0x00
2021.01.20 04:21:39 1: OWXAD_BinValues: context ds2450.getstatus.final Wettersensor: no local error, inheritance = 1 0x00 0x01 0x00 0x01 0x00 0x01 0x00 0x01 0xe0 0xcf
2021.01.20 05:52:08 1: OWXTHERM_BinValues: Abgassensor: invalid CRC, -0.0625 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2021.01.20 07:56:39 1: OWXAD_BinValues: context ds2450.getreading Wettersensor: invalid CRC 0x64 0x22 0x00 0x00 0x5b 0x7c 0x35 0x53 0x00 0x01
2021.01.20 07:56:39 1: OWXAD_BinValues: context ds2450.getalarm Wettersensor: no local error, inheritance = 1 0x00 0xff 0x00 0xff 0x00 0xff 0x00 0xff 0xb6 0xdb
2021.01.20 07:56:40 1: OWXAD_BinValues: context ds2450.getstatus.final Wettersensor: no local error, inheritance = 1 0x00 0x01 0x00 0x01 0x00 0x01 0x00 0x01 0xe0 0xcf
2021.01.20 08:10:45 2: ZWave: No ACK from Thermostat1_UG_WZ after 5s for sentset:1308032601042500
2021.01.20 09:27:38 1: OWXTHERM_BinValues: Abgassensor: invalid CRC, -0.0625 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Gruß und DANKE für Deine Mühe
Hans-Jürgen
Nix zu beachten. CRC-Fehler deuten tatsächlich auf ein Bus-Problem hin.
LG
pah