Businstabilitäten bei 20m Kabel

[Tobias]

Hi,
ich habe einen Busmaster sowie einen 1wire-Hub von eservice-online. Am Hub ist mittels Buskabel (2x2x0.8mm) ein Strang mit 20m und 7Devices (DS2406/DS1820) sowie ein Strang mit 5m und 4Devices(DS2408,DS2423,DS2450).
Problem: In unregelmäßigen Abständen, mal nach 2h, mal nach 2Tagen, steigt mit OWX aus mit dem Fehler: "OWX: Reset failure". Wenn ich OWServer nutze steigt mir dieser ebenfalls aus. Als der 20m Bus noch 40mlang war, gab es noch viiiiel häufiger in kürzeren Zeitabständen den Fehler.

Kann das sein das der Busmaster dasselbe Problem wie hier beschrieben hat?
Ich bin extra vom polnischen MP00202 auf die Produkte von eservice-online umgestiegen um einen superstabilen Bus über Jahre hinweg zu haben, aber das scheint noch galaxien weit entfernt zu sein.

Gibts von Euch Erfahrungen zu dieser Busmaster/Hub Kombination?

[det.]

Hallo Tobias,
trifft nicht ganz Deine Frage, aber bei mir folgende Erfahrungen mit OWX / Buslänge / Abfragehäufigkeit:
Seit ich mein 1-wire am RPI auf zwei lineare Stränge mit je einem USB Busmaster aufgeteilt habe - läuft der längere (ca. 40m - 11 Device) absolut stabil ohne eine RC Filter Schaltung nach dem Busmaster.
Der kürzere mit 13 Device und RC Filter zeigt die gleichen Fehlersymptome wie bei Dir. Ich denke, es liegt zum Teil an der Abfragehäufigkeit der Sensoren. An dem instabilen Bus habe ich u.a. einen OWID zur Türüberwachung dran mit 15s Takt, als ich gestern test-weise den OWSWITCH Heizung/Fenster auch auf 15s gestellt hatte und vergessen wieder auf 300s zurückzustellen - heute früh die Überraschung "OWX: Reset failure" im Log alle paar Sekunden und FHEM lahm gelegt.
Die Sensoren auf dem stabilen Strang werden nur aller 300s bis 900s je einmal abgefragt.

[Tobias]

genau so siehts auch bei mir aus, ich habe 5sek Interval bei 5Devices und 60sek bei 4Devices.
Da nach einem fhem-Neustart alles wieder funktioniert liegt die Vermutung nahe, das man im OWX-Modul darauf reagieren könnte um so ev. neu zu initialisieren? Ev. kommt es zu Kollisionen im Bus durch die hohe Kommunikation? Könnte das ein Fehler im OWX-Modul sein?

Wenn bei dieser Konstellation das Intervall von 5sek zu klein ist, stellt sich mir 1wire überhaupt in Frage bei Tür/Fensterkontakten

Das Ganze wär entspannter wenn 1wire Komponenten per Push-Prinzip Events selbstständig melden könnten anstatt Switche regelmäßig pollen zu müssen.

Edit: Habe bei Maxim folgende AppNote entdeckt:Sense Multiple Pushbuttons Using Only Two Wires
Daher die Frage an pah: unterstützt dein OWX-Modul "conditional search"? Muss ich das extra Konfigurieren? Könnte ich damit die Probleme beseitigen?

[Schorsch]

Problem: In unregelmäßigen Abständen, mal nach 2h, mal nach 2Tagen, steigt mit OWX aus mit dem Fehler: "OWX: Reset failure". Wenn ich OWServer nutze steigt mir dieser ebenfalls aus. Als der 20m Bus noch 40mlang war, gab es noch viiiiel häufiger in kürzeren Zeitabständen den Fehler.

Gibts von Euch Erfahrungen zu dieser Busmaster/Hub Kombination?

Hi,

die Teile (und eine vergleichbare Verkabelung) habe ich auch und vorübergehend hatte ich auch mal Probleme. Bei mir lag es daran, dass ich noch einen parasitär ernährten Zähler im Bus hatte (GP1-Countermodul). So lange ich das hatte, musste ich eine bestimmte Version des OWServers nehmen, damit es durchlief (muss nochmal nach Version schauen wenn wichtig), alle späteren blieben nach einiger Zeit stehen. Ich vermute ein Timing-Problem.
Habe den GP1 dann in Rente geschickt und seither läuft der Bus komplett stabil. Habe derzeit 16 Devices drauf (Typen DS18B20,DS18S20,DS2406,DS2408,DS2423,DS2450).

Viel Erfolg!
Georg

PS: Nur um sicher zu gehen - Du hast die 20m nicht am Terminal ohne Längenkompensation angeschlossen, oder? Eins ist ja für kurze Strecken (nutze ich im Schaltschrank).

PPS: Ich frage nur alle 30-60s ab. Wieso machst Du bei 5s keinen Alarmsearch? Belastet weniger (sollte es überhaupt an den 5s liegen...)

[Tobias]

Hi Schorsch,

die 5m sowie die 20m sind am 1wireHub jeweils am Port 2 und 3 angeschlossen. Port 1 ist für kurze Strecken innerhalb des Schaltschrankes. Daher denke ich das ich es korrekt verklabelt habe, zumindestens am Hub.

Laut Aussage pah unterstützen die Switche keinen Alarmsearch

[Prof. Dr. Peter Henning]

Achtung, das darf man nicht durcheinander bringen.

Die switches (muss mal nachsehen, ich glaube, nicht alle...) unterstützen sehr wohl einen conditional search - da muss man aber vorher die Suchbedingungen setzen.

Was die wenigsten devices unterstützen ist eine Alarmsignalisierung nach dem Reset-Puls.

Betreffend die Probleme: Ich denke auch, dass es sich hier um ein Timing-Problem handelt. Denn ein Reset failure wird vom Busmaster nur dann gemeldet, wenn er den Bus eben nicht zurücksetzen kann - wenn also z.B. irgendein Device noch sendet. Allerdings kann es auch sein, dass die Versorgungsspannung am Ende des 20m-Kabels nicht mehr stimmt, und dass auf Grund des langen Kabels das Ziehen des Bus auf 0 V am End eeben nicht als "Null" ankommt.

Welchen ohmschen Widerstand pro Meter weist dieses Kabel auf ?

Kann man notfalls auch aus dem Kabelquerschnitt berechnen.

LG

pah

[Tobias]

den conditional Search unterstützen deine Module aber noch nicht, oder?

Welchen ohmschen Widerstand pro Meter weist dieses Kabel auf ?
Kann man notfalls auch aus dem Kabelquerschnitt berechnen.

Puhh, wenn ich das nächste mal vor Ort bin messe ich das. Wie kann man das am besten messen? zb. alles stromlos machen, dann auf der einen seite 5v bzw 1wire und Gnd zusammenknoten ;)
 und auf der anderen Seiten den Widerstand der beiden Kabelenden mit einem Ohmmeter messen??

Ich benutze durchgängig 2x2x0.8mm auf einer Länge von exakt 20m. Und überall verstreut auf dieser Länge sind die Devices. Dann habe ich ich gestern nach den 20m einen 1wire Repeater eingesetzt und dann kommen nochmal 27m mit verstreuten Devices.
Wenn ich jetzt immer noch fehler habe erstze ich testweise den eservice-online Buskoppler mal mit dem Polenadapter. Zu der Zeit als dieser dran war (mit 3k3 und 220uF) hatte ich nie(!) einen Resetfehler mit durchgängig 39m Kabel

[Schorsch]

Welchen ohmschen Widerstand pro Meter weist dieses Kabel auf ?

Puhh, wenn ich das nächste mal vor Ort bin messe ich das. Wie kann man das am besten messen? zb. alles stromlos machen, dann auf der einen seite 5v bzw 1wire und Gnd zusammenknoten ;)
 und auf der anderen Seiten den Widerstand der beiden Kabelenden mit einem Ohmmeter messen??
Ich benutze durchgängig 2x2x0.8mm

Hm - Widerstand ja. Aber kannst Du am Busende nicht einfach die Spannungen gegen Masse messen und schauen, wieviel noch ankommt?

2x2x0.8mm sollte eigentlich echt reichen, das nutze ich auch.

Testweise anderer Adapter ist evtl. keine dumme Idee, wenn der dann den Fehler auch / nicht produziert, deutet das ja auch Kabel / sService Bus.

Was mir noch einfällt: Welchen 1-wire Controller nutzt Du? Bei den Abfrageintervallen sollte es ja vermutlich langsam ein DS2490R sein, oder? Ich habe noch immer meinen DS9007U (aktiv aber lahm) im Einsatz.

[Prof. Dr. Peter Henning]

Conditional search: Nö, noch nicht... ist aber in Planung.

Die Messung des Kabelwiderstandes geht übrigens ganz einfach, man braucht noch nicht einmal die Sensoren abzuklemmen.

1. Messung: Am Kabeleingang messen des Widerstandes sowohl der 5V-Leitung als auch der Signalleitung gegen Masse (Achtung, natürlich vorher vom Busmastertrennen) => "Leckwiderstand" Rl (sollte idealerweise hoch sein ...)
2. Am KabelENDE sowohl 5V-Leitung als auch Signalleitung mit Masse verbinden.
3. Messungen von 1. widerholen, Ergebnis sei Rm. Widerstand des Kabels ist dann (gemeint pro Ader, daher der Faktor 0.5; und natürlich Berechnung getrennt für 5V und Signalleitung)

Rk = 0.5/ ( 1/Rm - 1/Rl)
LG

pah

[Tobias]

Hi,
zur Info. Ich habe jetzt alle Switche auf einem Abfrageintervall von 300sek, alle TempSensoren auf 60sek. Nach 20m einen Repeater, dann nochmal 30m. Nach 2 Tagen hatte ich schon wieder den "Reset failure".
Nächste Aktivitäten:
- Kabelwiderstand messen
- Busmaster austauschen -> MP00202 mit 3k3 und 100uF Stabilisator
- Längenkompensationsschaltung (nach cassy/dougie -> 150Ohm+4700pF) einbauen.

Solange noch Ideen da sind habe ich die Hoffnung noch nicht aufgegeben...

[det.]

Hallo Tobias,
Versuch doch mal (siehe mein Post weiter oben) die 1-wire Installation auf mehrere Busmaster aufzuteilen. Seit diese Woche noch der  von PCSensors gekommen ist, hab ich am RPI insgesamt 3 Stück davon friedlich nebeneinander laufen. Das Problem trat seit meinem letzten Post hier nicht mehr auf. Noch sicherer ist es MMn, die zeitkritischen SWITCH Abfragen auf ein extra FHEM z.B. auf einem RPI auszulagern. Dann geht Dir nicht die komplette Haussteuerung wegen der Sache ein.

[Prof. Dr. Peter Henning]

Ich habe zwar selbst insgesamt 4 Busmaster laufen und kann deren problemloses Miteinander nur bestätigen. Doch wäre es trotzdem sinnvoll, die auftretenden Probleme weiter zu analysieren.

Auch halte ich es für verfrüht, irgendwelche so genannten "Kompensationsschaltungen" einzubauen - denn damit wird der Grund der Störungen auch nicht erkennbar.

Ein weiterer Schritt vorher könnte darin bestehen, den Repeater herauszunehmen. Denn eigentlich sollte der Bus mit dieser Leitungslänge problemlos funktionieren. Hintergrund dieser Überlegung: Das Hardware-Device, das den Busmaster bedient, wird von der Software (egal ob OWX oder OWFS) immer so angesteuert, als ob alle 1-Wire-Devices ohne Zeitverzögerung erreichbar sind. Wenn aber der Repeater ein paar Millisekunden Latenz verursacht, kann dies möglicherweise nicht stimmen => Reset failure.

LG

pah

[Tobias]

das mit mehrern Busmastern gestaltet sich schwierig da ich nur an einer Stelle die Installtion habe und der Bus als Ring gelegt ist. Heißt, das Ende des Busses kommt wieder vorn am Busmaster an (natürlich nicht angeschlossen).
Ich könnte maximal den Bus in der Mitte aufteilen um dann 2 Busmaster anzuschließen.
Problem 2: ich bin nicht sooft bei der Installtion vor ort, kann also nicht eben mal schnell etwas ausprobieren :(
Morgen bin ich wieder vorort. Da werde ich den Polen-Adapter dranhängen.

Nochetwas bzgl Fehlermeldungen, vieleicht hilft es das einzugrenzen. Seit dem Repeater habe ich nicht mehr "Reset failure" sondern folgende. Das ist wirklich die erste Meldung, davor (ca 2Tage) lief alles ohne Probleme.

Code Auswählen Erweitern

Use of uninitialized value $string_part in concatenation (.) or string at ./FHEM/00_OWX.
pm line 1459.
Use of uninitialized value $m in addition (+) at ./FHEM/00_OWX.pm line 1457.
Diese Fehler habe ich übrigens auch wenn ich den Busmaster kurz vom USB trenne und wieder anstecke (Device bleibt aufgrund udev gleich). Kann das sein das OWX kein automatisches Reconnect macht?

Den Repeater habe ich auch angeklemmt in der Hoffnung der Busfehler auszumerzen.

[Tobias]

Ich habe eine mögliche Fehlerursache entdeckt, und zwar steigt bei mir das USB aus. Der Busmaster wird getrennt (USB0) und wieder neu initialisiert (USB3).
Dem werde ich natürlich nachgehen, aber trotzdem die Frage, ob es geplant ist, das OWX sich nach einer Trennung des Devices wieder neu initialisieren kann?? Das Verhalten bestätigt meine Beobachtung, das ich den selben Fehler habe wenn ich den Busmaster bei laufender FHEM-Instanz vom USB trenne.

Code Auswählen Erweitern

Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: ftdi_set_termios FAILED to set databits/stopbits/parity
Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: ftdi_set_termios urb failed to set baudrate
Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: urb failed to clear flow control
Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: ftdi_set_termios FAILED to set databits/stopbits/parity
Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: ftdi_set_termios urb failed to set baudrate
Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: urb failed to clear flow control
Apr  4 12:59:51 Iconnect kernel: hub 1-1:1.0: port 4 disabled by hub (EMI?), re-enabling...
Apr  4 12:59:51 Iconnect kernel: usb 1-1.4: USB disconnect, address 27
Apr  4 12:59:51 Iconnect kernel: ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3
Apr  4 12:59:51 Iconnect kernel: ftdi_sio 1-1.4:1.0: device disconnected
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: new full speed USB device using orion-ehci and address 28
Apr  4 12:59:52 Iconnect kernel: ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: Detected FT232RL
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: Number of endpoints 2
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: Endpoint 1 MaxPacketSize 64
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: Endpoint 2 MaxPacketSize 64
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: Setting MaxPacketSize 64
Apr  4 12:59:52 Iconnect kernel: usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0


Code Auswählen Erweitern

Apr  5 11:42:01 Iconnect kernel: hub 1-1:1.0: port 4 disabled by hub (EMI?), re-enabling...
Apr  5 11:42:01 Iconnect kernel: usb 1-1.4: USB disconnect, address 28
Apr  5 11:42:01 Iconnect kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Apr  5 11:42:01 Iconnect kernel: ftdi_sio 1-1.4:1.0: device disconnected
Apr  5 11:42:01 Iconnect kernel: usb 1-1.4: new full speed USB device using orion-ehci and address 29
Apr  5 11:42:02 Iconnect kernel: ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Apr  5 11:42:02 Iconnect kernel: usb 1-1.4: Detected FT232RL
Apr  5 11:42:02 Iconnect kernel: usb 1-1.4: Number of endpoints 2
Apr  5 11:42:02 Iconnect kernel: usb 1-1.4: Endpoint 1 MaxPacketSize 64
Apr  5 11:42:02 Iconnect kernel: usb 1-1.4: Endpoint 2 MaxPacketSize 64
Apr  5 11:42:02 Iconnect kernel: usb 1-1.4: Setting MaxPacketSize 64
Apr  5 11:42:02 Iconnect kernel: usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB3


[Prof. Dr. Peter Henning]

Die automatische Neu-Initialisierung von OWX ist in Arbeit. Ich denke aber, dass das an dieser Stelle vermutlich gar nicht nötig ist.

Sinnvoll wäre zunächst, der Kiste beizubringen, dass der 1-Wire-Adapter immer auf dasselbe device gemappt wird.
Dazu mit dmesg | grep -i usb die Seriennummer des Adapters herausfinden. Im Beispiel:

USB Serial support registered for FTDI USB Serial Device
Nov 22 22:17:26 raspberrypi kernel: [   10.600041] ftdi_sio 1-1.3.1.2:1.0: FTDI USB Serial Device converter detected
2: FTDI USB Serial Device converter now attached to ttyUSB0
[    3.572009] usb 1-1.3.1.2: new full-speed USB device number 8 using dwc_otg
[    3.701033] usb 1-1.3.1.2: New USB device found, idVendor=0403, idProduct=6001
[    3.711652] usb 1-1.3.1.2: SerialNumber: FTFK8OHX

Die Seriennummer ist hier FTFK80HX

Dann eintragen in die Datei /lib/udev/rules.d/95-usb.rules

SUBSYSTEMS=="usb", ATTRS{serial}=="FTFK80HX", SYMLINK+="owxog"

Das sorgt dafür, dass bei jedem Neustart des USB-Systems der Adapter immer unter dem symbolischen Link /dev/owxog erreichbar ist.
Der kurze disconnect spielt dann keine Rolle mehr - zumindest läuft das bei mir astrein, obwohl auch bei meinem Rpi immer noch der USB ab und zu abstürzt.

LG

pah