1-Wire Busfehler / CRC

[all_finder]

Hallo beisammen,

vielleicht kennt jemand das Fehlerbild (bzw. die Ursache):
Umbebung
- per OWX
- 2 getrennte 1-Wire Busse, jeweils mit USB/Serialwandler per DS2480B angebunden
- ca. 10 Sensoren / Aktoren
- Sternbustopologie < 100m
- 2 aktive Hubs (5 & 12 V sehen gut aus)

Jetzt der Fehler:
- die DS2480 erkennen alle Busteilnehmer (gut
- alle Module kommen nicht aus dem Init Zustand, beim Auslesen erhalte ich teils keine Reason bzw. CRC Fehler

[Prof. Dr. Peter Henning]

Sterntopologie ?

Das hier beachtet : http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie ?

LG

pah

[all_finder]

jain - ca. 1 Jahr lief der Bus problemlos. Seit dem ich ein zweites Netz aufgebaut (da sind im gesamten ca. 30m dazu gekommen) habe ich die Situation, dass es Anfang ebenfalls problemlos lief, bzw. auch nach einem POR. Irgendwann gehts dann nicht mehr. Verkablung etc. ist gleich geblieben. Nur die Konfig habe ich erweitert, wobei dies nur das 2. Netz betrifft.

Das 1. Netz hat ungefähr 60m (6 Aktoren), das Zweite die besagten 30m (1 Aktor). Würde es mehr nachvollziehen können, wenn das größere nicht liefe. Das Zweite ist ein Standard-Konformer Bus. Über get devices bekomme ich alle Konten richtig zurückgelesen. (von beiden Netzen)

Ein zweites Problem (anderer Thread) ist, dass die Konfig seit einiger Zeit folgende Fehlermeldung zurückgibt:

Code Auswählen Erweitern

configfile: 0
0

vg

[Icinger]

Hardware kannst ausschliessen?
Ursachenforschung betrieben?
Alle abklemmen und einen nach dem anderen wieder anklemmen!

[Prof. Dr. Peter Henning]

Pardon, aber das ist einfach Käse. Es ist doch wohl offensichtlich, dass "nur" eine Änderung in der Konfigurationsdatei ausreicht, um den selbst eingebauten Verkabelungsfehler dann auch auftreten zu lassen.

Wer sich nicht an die empfohlene Topologie hält (3. Bild in http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie), sondern stattdessen glaubt, er käme mit einer Sterntopologie zu Recht, soll es bitte alleine weiter versuchen.

pah

[all_finder]

Habe eine Ursache gefunden:
- durch die springenden ttyUSBx wurden zwar die Buskoppler richtig initialisiert, jedoch sind waren die Sensoren auf den falschen Koppler zugeordent. Warum dies als CRC Fehler anzeigt wird, hört sich doch nach SW an . Zudem habe ich noch nicht die Ursache, warum ca. alle 2 Tage die Fritzbox meint, dass die USB-Teilnehmer neu eingesteckt werden und somit die Ports neu durchnummeriert...

Warum sollte der Bus 1 Jahr funktionieren und durch die Reduktion von Teilnehmer schlechter werden? Die Sterntopologie ist lt. eservice mit ausreichend Repeater / Hubs auch zu betreiben.

Weitere Stänge werde ich dann mit Rückkanal versehen. Jedoch gehe ich davon aus, dass dies nur für den 1-Wire Bus (ein Draht) sinnvoll ist, die Spannungsversorgung und Ground hätte ich weiterhin im Stern angeschlossen?

[Prof. Dr. Peter Henning]

Immer wieder sehr beliebt: Newcomer, die von Softwarefehlern sprechen - obwohl sie einfach nicht verstanden haben, was sie tun. 

CRC-Fehler sind CRC-Fehler, basta. Der Busmaster liefert bei der Abfrage eines nicht existierenden Devices eben nur Datenmüll, und die Tatsache des Datenmülls erkennt man an den CRC-Fehlern. Das ist vollkommen in Ordnung und gewollt.

Fragen zur Fritzbox bitte an deren Hersteller richten.

Portnummerierung: Inwischen sollte sich herumgesprochen haben, wie man bestimmte Buskoppler an Hand ihrer Seriennummer immer denselben Devicenamen zuordnen kann, so dass eine Neuzuordnung durch einen Neustart überhaupt keinen nachteiligen Effekt hat. Wenn nicht: Bitte Suchfunktion nutzen.

Sterntopologie: Bei aller Hochachtung von Andreas Geisler und seinen Produkten sollte man sich doch vielleicht an die Dokumente des Herstellers von 1-Wire Bausteinen halten. Den letzten Satz verstehe ich gar nicht, soll das eine Frage sein ?

LG

pah

[all_finder]

ich wollte sie nicht angreifen, ich habe explizit nicht von einem SW-fehler gesprochen - nur von SW. dennoch sehe ich einen unterschied zwischen frames mit korrupten inhalt und daten bzw. störungen, die nicht als frames zu erkennen sind.

ja, die udev regeln hätte ich gerne angewendet, jedoch bin ich noch am zusammenstellen des freetz images, da ich leider keine schreibrechte auf die rules habe (http://forum.fhem.de/index.php/topic,30884.msg234329.html#msg234329) - für einen tipp bin ich natürlich dankbar, wenn es noch andere möglichkeiten gibt..!

[Rohan]

Hi all_finder,

1. hier wird geduzt

2. du hast mMn zu viele Baustellen gleichzeitig

Also eins ums andere, ok?

Gruß
Thomas

[Prof. Dr. Peter Henning]

dennoch sehe ich einen unterschied zwischen frames mit korrupten inhalt und daten bzw. störungen, die nicht als frames zu erkennen sind.

Soso, jetzt brauchen wir also noch einen Busmaster - oder Software - der/die ebenfalls über diese Intelligenz verfügt. Nur zu, das bisschen Code kann man sicher schnell schreiben.

pah

[all_finder]

@pah: bin fast schon auf den geschmack gekommen - nichts für ungut

@Rohan: der fall CRC ist ja dann schon mal weg. ich bin noch auf der hoffnung für den tipp für die udev regeln. habe nur die möglichkeit per freetz gefunden (dazu suche ich noch nach DER anleitung, habe nur ältere / bzw. nicht für die >= fb 7390 welche gefunden. unter den addons finde ich im freetz conf. nur einen fhem entferner) oder den netten verweis auf ein vollwertiges system umzusteigen (überlege schon)...

[bert]

vielleicht hilft dir das weiter.http://www.fischer-net.de/hausautomation/fhem/27-fhem-und-dynamische-devices.html

[all_finder]

danke für die antwort.. ich scheitere an der fritzbox...: ich habe keine Schreibrechte, die Fehlermeldung:
"61-persisten-1wire.rules" Read-only file system -  hindert mich zu schreiben...

bin sicher nicht der einzige... (z.B. http://forum.fhem.de/index.php?topic=25947.0) nur wie geht das ohne eigenes firmwareabbild..?