- √ - Bus stürzt ab hängt sich auf

[zalva]

abgemacht.
Bis morgen früh dann.

Gruss
Salvatore

[Norbe]

eine Drossel hat keine GA...

...

Das ist soweit schon richtig, aber ich hatte tatsächlich schon den Fall, dass eine defekte Sapnnungsversorgung mir den Bus mit irgendwelchem undefinierten Telegrammschrott zugemüllt hat, was ich ohne EIB-Doktor und abklemmen aller Geräte der Linie auch nicht gefunden hätte.
Ich würde die Möglichkeit daher zumindest nicht ausschliessen.

[klaus407]

Hallo,
ist das Problem gelöst?

[zalva]

ist das Problem gelöst?

Hallo Klaus,

nein gelöst noch nicht. Konnte durch ändern der Pollingwerte die Wahrscheinlichkeit verringern eine Ueberlast zu bekommen.
Kurzum, der Verkehr ist weniger, dadurch habe ich im Moment (nur) noch ein-zwei mal am Tag einen Hänger.

An den Herstellern von Wiregate und Miniserver (loxlive) meinen allerherzlichsten Dank für den schnellen und super Support.

Mit Makkis Hilfe konnten viele potentielle Fehlerquellen ausgeschlossen werden und festgestellt werden, dass bei den Hängern mit einem Schwung (zu)viele? Telegramme in kurzer Zeit auf den Bus kommen.

Florian von Loxone hat sich sofort bei mir gemeldet, habe meine Konfiguration hingeschickt diese wird jetzt auseinandergenommen und ich stehe mit Herrn Nader (Entwickler) in Kontakt.

Sobald die Ursache gefunden wurde und die Lösung kommt werde ich diese hier posten

Gruss
Salvatore

[rb84]

Eine Drossel oder ein "Wackelkontakt" kann durchaus eine "Datenübertragung" verursachen!

Das kann JEDER Teilnehmer verursachen, sowie JEDE Klemme und es kann auch passieren, wenn das Kabel neben einem anderen Kabel liegt und der Schirm ein Problem hat.

Die Spezifikation ist nicht offen, so kann ich kein Beispiel vorrechnen.
Aus einem anderen Bus-Projekt: Das passierte tatsächlich, durch ein Schirmproblem wurden Signale in den Bus induziert.

Nach Transformation in Binärcode kam dann eben etwas wie "0110 0111" raus, wobei hier (Beispiel) das erste Byte als Adresse und das zweite Byte als Daten zu werden war!

Der Witz war allerdings noch schlimmer: Nehmen wir noch ein weiteres Bit dazu, welches eine Checksumme darstellen soll.
Statistisch gesehen kann man sagen, dass in JEDEM Fall die Checksumme falsch sein wird. Auf jede Checksumme reagierten die Teilnehmer mit Nachfragen -> Das System "stürzte ab".

Man muss dazu noch sagen: Wenn auf einem Bus wie EIB Kollisionen auftreten (zwei Teilnehmer senden gleichzeitig) dann wird ein Verfahren zur Lösung des Problems genutzt: z.B. schweigen die Teilnehmer für eine zufallsbasierte Zeit und wiederholen dann ihr Diagramm.

Das wird jedoch bei einem Hardwareschaden IMMER fehlschlagen (der "Gestörte" sendet ja permanent)! Der Bus stürzt ab!

[SebastianFey]

so geheim ist die sache nun auch wieder nicht...

http://freebus.org/images/stories/do...rammaufbau.pdf

[rb84]

so geheim ist die sache nun auch wieder nicht...

http://freebus.org/images/stories/do...rammaufbau.pdf

Ja, das ist der Aufbau des Telegramms.
Das hilft in so einem Fall wenig weiter.

Mehr Sinn macht eine exakte Systembeschreibung. Ok, klar, man kann das schon "rausfinden".
Ich finde es aber bequemer, wenn Diagramme, Formeln usw. zusammengestellt vorliegen, die die Schicht 1 + 2 beschreiben...

[Loxone]

Hallo,

Hier mal ein Statement von unserer Seite - mir wurde gesagt es wird hier teilweise darauf gewartet einen Übeltäter zu finden.

In unserem Labor wird schon heftig getestet - leider konnten wir den Fehler noch nicht reproduzieren. Wir sind aber in stetigem Kontakt mit zalva, werden den Fehler finden und wenn das Problem in unserer Sphäre liegt werden natürlich auch rasch beheben.

Grüße,
Florian

[Tessi]

Man muss dazu noch sagen: Wenn auf einem Bus wie EIB Kollisionen auftreten (zwei Teilnehmer senden gleichzeitig) dann wird ein Verfahren zur Lösung des Problems genutzt: z.B. schweigen die Teilnehmer für eine zufallsbasierte Zeit und wiederholen dann ihr Diagramm.

Das wird bei Ethernet so gemacht, KNX nutzt wie CAN ein Arbitrierungsverfahren (CSMA/Clarification required. siehe: Carrier Sense Multiple Access/Collision Resolution und Europäischer Installationsbus), bei dem im Konkurrenzfall das Telegramm mit der höheren Priorität unbeschadet übertragen wird, während das andere warten muß.

mir wurde gesagt es wird hier teilweise darauf gewartet einen Übeltäter zu finden.

Das ist jetzt bestimmt nicht persönlich gemeint. Es ist nur so, das bei einem offensichtlich überlasteten Bus logischerweise zuerst jene Geräte untersucht werden, die grundsätzlich gut geeignet sind, dies zu bewirken. Das sind dann Kandidaten wie Miniserver, WireGate, EibPC, HomeServer und ähnliche, vor allem, da sie von Endanwendern programmiert werden und dabei leicht Fehler unterlaufen.
Sicher, bei einem Hardware-Defekt kann jedes Gerät den Bus zumüllen, aber wahrscheinlicher sind halt Konfigurationsfehler und die wiederum bei oben genannten Geräten. Mit Übeltäter ist da ganz sicher nicht der Hersteller gemeint, es soll nur einfach erst einmal die Störquelle lokalisiert werden, danach kann man dann untersuchen, warum sie stört, und dann, aber eben erst dann kann man ggf. noch den Verantwortlichen ermitteln. Und bei oben genannten Geräten ist das nur allzuoft der Betreiber selbst.

[Loxone]

@Tessi - sehe ich genauso - auch ich würde zuerst hier ansetzen. Ich will auch gar nicht ausschließen, dass der Miniserver daran Schuld hat.

Fehler passieren - sie müssen halt schnell ausgemerzt werden.

Grüße,
Florian

[zalva]

Hallo zusammen,

möchte mich diesbezüglich auch wieder zu Wort melden.

Richtig ist, die Ursache ist noch nicht hunderprozentig ermittelt.
a.)
Mit Hilfe von wiregate (makki) konnten Fehlerquellen ausgeschlossen und restliche potentielle Kanditaten ermittelt werden.

b.)
Mit Hilfe von loxone (Florian, Herr Nader) konnten Konfigurationsfehler im Miniserver lokalisiert und eliminiert werden. An manchen Stellen wurde gepollt (Konfigurationsfehler, mea culpa), wo es nicht zwingend notwendig ist und der Status implizit vorliegt.

Tatsache ist allerdings auch, dass das Verkehrsaufkommen zwar nicht zu hoch insgesamt war über den Tag gesehen, aber wenn was kam, dann viel auf einmal. Auf meinem Bus ist jetzt relative Ruhe eingekehrt (im Moment spielt sich eh nur Licht/Steckdosen und die FBH dort ab und der Bus langeweilt sich)

Die Anzahl der Telegramme ist auf rund 5000 (von in der Spitze eher Richtung 80.000) gesunken.
Damit sinkt die Chance auf Überlast in einem kleinem Zeitintervall auch drastisch und damit auch die Wahrscheinlichkeit eines Hängers.

Fakt ist auch, dass seit der Behebung der Konfigurationsfehler beim Miniserver, kein Hängen mehr zu verzeichnen ist.

Wichtig ist allerdings auch, dass die Stabilität so bleibt, auch wenn ich nach und nach zusätzliche Funktionen implementiere (Logiken, Multiroom ...).

Falls das Problem bzw. die Ursache tatsächlich in der Sphäre Miniserver liegen sollte lösen das die Jungs und es wird z.B. mit einem Patch behoben, dann verbuche ich dass unter Kinderkrankheit in einem sonst sehr guten Produkt.

Für alle die mitlesen bezüglich Wiregate bzw. Miniserver.
Was mich angeht, lasse ich weder über meine Wiregate noch meinem Miniserver was kommen! Die Kombination von Beiden Geräten bezüglich günstiger Temperaturermittlung (Wiregate) und einfach und schnell zu realisiernden Logiken und Visualisierung (ipod/Web/Internet mit Miniserver) zu einem vernünftigen Preis ist IMHO super und (fast) unschlagbar.(Nein weder von Makki, noch von Florian bekomme ich Prozente, was allerdings beide Firmen leisten ist ein sehr schneller, super und unkomplzierten Support). Meine Erfahrungen diesbezüglich ist mit beiden Geräten sehr positiv.

Selbstverständlich bin ich nach wie vor offen für Ideen, welche Ursachen noch möglich sein könnten für Hänger
(auch um know-how weiter aufzubauen) offen und möchte mich hiermit bei allen für die Beiträge hier bedanken.

Liebe Grüsse und ein Schönes Wochende aus Freiburg i.Br.
Salvatore

[Tessi]

Zur Auslastung:
Auf meinem Bus wird viel zyklisch gesendet, da kommen rund 100 Telegramme/min zusammen. In nun über drei Jahren hat das nie zu Problemen geführt.
Soll heißen, 50000 Telegramme/Tag sind nicht (zu) viel...
Und 5000/Tag ist wenig.

[rb84]

Das wird bei Ethernet so gemacht, KNX nutzt wie CAN ein Arbitrierungsverfahren (CSMA/Clarification required. siehe: Carrier Sense Multiple Access/Collision Resolution und Europäischer Installationsbus), bei dem im Konkurrenzfall das Telegramm mit der höheren Priorität unbeschadet übertragen wird, während das andere warten

Das mag richtig sein. Der Effekt istallerdings der selbe: da der Störer ohne jede Rücksicht sendet hast du doch trotzdem Müll im System!

[makki]

Nur am Rande: ich schreibe dazu nichts, bis das Problem im Detail identifiziert ist.
(und danach vielleicht auch nicht )

Meine Schlussfolgerung war: es gibt dort mind. ein defektes oder fehlerhaftes Gerät(*) oder eine bestimmte Kombination derer, die - wie auch immer - dazu führt, das
a) regelmässig, in deterministischen Zeitabständen von 10 Minuten, Telegramme "zerschossen" werden (es ist übrigens CSMA/CA)
b) sich der KNX wirklich dann irgendwann komplett "weghängt", was ich so bis dato nicht gesehen habe.

Woran das nun im Detail liegt kann und wage ich remote nicht ansatzweise zu beurteilen, ich wollte nur erstmal 100% sicherstellen&ausschliessen können, das es am WireGate liegt.


Warum es nach diesem "Absturz" (was auch immer da passiert) bei der TP-UART nicht wie üblich automatisch ohne manuellen Restart weitergeht untersuchen wir hier.

Makki

Edit *: was ich damit sagen will, es ist ja hier auch noch anderes, bisher ungenanntes Material unterwegs, eins davon von einem wissentlich auch recht neuen Hersteller -> es kann alles sein.

[rb84]

Im Übrigen ist so etwas ein Grund für eine Sternverkabelung (bzw. Baum)...

Ich halte es für nicht gut einen RING (offen) pro Etage zu legen: Maximal in jedem RAUM ein Ring und jeden Raum dann direkt zu einer UV führen. Abklemmen eines Raums/Teilnehmers: 10 Sekunden Zeitaufwand.

Bei einem RING nach Fehlern suchen: halber Tag...