Wie analysiert man: "ErrMsg: Unbekannter Fehler" ?

[MIT]

Guten Morgen,

ich bekomme bei meiner Installation sporadisch ffg. Fehler:

2016-03-04 06:50:04	636614	KNX	1494	ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 0610042000140401d8002900b05011f0000000c2

Dieser Fehler tritt pro Tag ca 50-80 mal (geschätzt) auf. Wie kann ich herausfinden was er bedeutet bzw. an welcher Stelle kann ich Änderungen durchführen, die dazu führen, dass das Problem nicht mehr auftritt. Ich setze edomi 1.21 mit WireGate als Zugang zum KNX ein.

Besten Dank für Ideen!

VG
Thorsten

Edit: Oder kann/soll/darf ich den Fehler einfach ignorieren? Er ist nur im Error-Log zu finden; nicht in der Auflistung der KO-Aktivitäten.

[MIT]

Ich hole das noch einmal nach oben ... hat niemand eine Idee?
Braucht Ihr mehr Infos? - Wenn ja, was genau?

@gaert: Christian, kannst Du mir ggf. helfen? - DANKE!

[gaert]

Ich kann Dir auf die Schnelle nur soviel sagen:
Es handelt sich um einen Tunneling_Request (so weit so gut), der allerdings fehlerhaft ist - am Ende wird der Fehlercode xC2 empfangen (die Länge der Nutzdaten beträgt ausserdem 0 Bytes...).

Vielleicht ein nicht unterstützter DPT-Typ?!

Sorry für's fett-gedruckte - ließ sich irgendwie nicht abändern

0610
0420: Tunneling Request
0014
04
01 d8 00
2900 b050: Auch nicht so unbedingt normal (diverse Flags)
11 f0 00 00
00: Länge der "Nutzdaten" = 0 Bytes...
c2: Fehlercode xC2

[MIT]

Danke dir für deine Antwort!
Das bedeutet also, dass ich mir - so lange bisher alles soweit funktioniert - keine Sorgen machen muss (da nur DPT falsch), oder?
Momentan habe ich auch erst ein Logikmodul (Terminreminder) und eine MiniVisu (Startseite quasi) installiert. Gibt es ggf. die Möglichkeit herauszufinden, welche GA/en den/die falschen DPT/s zugewiesen hat? Oder merke ich das quasi erst dann, wenn ich sie verwende und somit das falsche Format in der Visu bzw. bei Berechnungen auftaucht?
Noch eine Idee: Ich habe für alle 1-Wire-GAen in der ETS virtuelle Geräte angelegt und diese auch miteinander via GA-Kommunikation verbunden. Das ist natürlich alles nur virtuell und wird auch immer so bleiben... Grund für diese "Maloche" war edomi bzw. dessen striktes Fehler-Message-System; denn ich hatte es satt ständig "xxx fehlende/unbekannte GA" in edomi lesen zu müssen. Das Problem ist nun dadurch auch weg. Allerdings: Könnte das o.g. Problem daher rühren, dass diese virtuellen Geräte bzw. quasi virtuellen GAen (vermutlich) falsche DPTs haben?
(1-Wire nutze ich für meine Temperaturerfassung und als Reedkontakte für die Fenster/Türen)

DANKE!

[gaert]

Eigentlich ist es ganz einfach: EDOMI unterstützt alle DPTs, die Du in der KO-Konfiguration vorfindest. Alle anderen DPT werden (noch) nicht unterstützt. Bezüglich Deiner Fehlermeldung wäre es nur ein Vermutung(!) von mir, dass Du versuchst eine GA unbekannten Typs mit einem Wert zu versehen (write) oder abzufragen (read). Das muss aber nicht unbedingt der Fall sein - genauso gut könnte irgendein Busteilnehmer bei Dir "Müll" senden, oder deine Schnittstelle irgendetwas nicht verstehen, oder oder oder Letzteres erscheint mir sogar relativ plausibel, denn Deine Konfiguration ist ja nicht gerade gewöhnlich...

[MIT]

ZITAT: " [...] deine Schnittstelle irgendetwas nicht verstehen, oder oder oder Letzteres erscheint mir sogar relativ plausibel, denn Deine Konfiguration ist ja nicht gerade gewöhnlich... "

Meine Schnittstelle ist Standard-WireGate mit EIBD (auch von ElabNet); d.h. Standardkost, wie es vermutlich ganz viele hier haben. Und meine Konfiguration (zumindest bzgl. der Hardware) ist ebenfalls Standard (WireGate für Temp & Reed, MDT Heizungsaktoren, etc.)

==> Wie machen es diejenigen hier, die diesen Standard ebenfalls haben mit den GAen, die nur für WireGate (und Visu) verwendet werden?

[gaert]

Dazu kann ich nichts beitragen... Ich habe seit eh und je einen billigen IP-Router im Einsatz und ich kenne diese ganzen Probleme die hier schon diskutiert wurden überhaupt nicht. In dieser Hinsicht meinte ich "ungewöhnlich"... Eibd ist ein (gutes) Stückchen Software, das leider total veraltet ist und nich mehr weiterentwickelt wird. Ich würde mein Haus damit nicht steuern wollen...

[MIT]

"[...] Standard-WireGate mit EIBD (auch von ElabNet); [...]" ==> Ups, da war ich wohl etwas verwirrt.... ;-) .. ich meinte mit TP-UART (RS232) von Elabnet ...

EIBD habe ich nicht im Einsatz.

Und diese Frage:
==> Wie machen es diejenigen hier, die diesen Standard ebenfalls haben mit den GAen, die nur für WireGate (und Visu) verwendet werden?
bezog sich auf die Konfiguration in der ETS.

DANKE!

[MIT]

@gaert: Du schreibst:

[B]Ich kann Dir auf die Schnelle nur soviel sagen:
Es handelt sich um einen Tunneling_Request (so weit so gut), der allerdings fehlerhaft ist - am Ende wird der Fehlercode xC2 empfangen (die Länge der Nutzdaten beträgt ausserdem 0 Bytes...).
[...]
0610
0420: Tunneling Request
0014
04
01 d8 00
2900 b050: Auch nicht so unbedingt normal (diverse Flags)
11 f0 00 00
00: Länge der "Nutzdaten" = 0 Bytes...
c2: Fehlercode xC2

Gibt es eine Quelle, wo ich diese Infos bekomme oder sind das deine "Internas"? Ggf. Error-Codes von PHP?

Denn diese Zeichenfolge ändert sich auch hin und wieder.
Ggf. kann ich irgendwie dem Übel etwas näher kommen?! - DANKE!

[gaert]

Klar - alle Infos findest Du in der KNX-Spezifikation (kostenloser Download auf knx.org). Ist allerdings seeeeeeehr umfänglich...

Diese Rohdaten (0610...) sind nicht meine Erfindung, sondern das sind die Daten, die irgendein KNX-Device bei Dir auf den Bus sendet.

[MIT]

Danke dir!
Um den Schluss von Fehlermeldung zu produzierender GA ziehen zu können, wäre es dazu sinnvoll den GA-Monitor der ETS anzuschmeißen und dein Errorlog zeitlich mit diesem abzugleichen? Oder gibt es auch "effektivere" Tools hierfür? Also so etwas wie: "Errorcode (s.o.) <> Quell-GA <> Ziel-GA" - Kennst Du da was passendes?

Edit: Ggf. eine Anpassung deines Errorlog - Moduls für die Wunschliste?... :-)

[gaert]

Mit Hilfe der Spezifikation kannst Du die GA aus den Rohdaten berechnen - oder zumindest die PA, je nach dem... Ansonsten bliebe tatsächlich nur der zeitliche Abgleich mit der ETS - aber das sollte zu schaffen sein

[MIT]

Ja, ich denke auch. Bin da ganz optimistisch. Danke dir auf jeden Fall!

[MIT]

So ... nun muss ich leider negative Rückmeldung geben, da ich es wohl nur "verschlimmbessert" habe...

Was habe ich probiert:
- ETS mit Analysemonitor um 7.14 Uhr gestartet
- Parallel EDOMI - Adminbereich geöffnet
- Erst um 12.40 Uhr kam der erste Fehler:

2016-03-08 12:40:22

025393

KNX

9235

ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 061004200014040161002900b05011f0000000c2

- In der ETS wurde eine PA angezeigt, die keine Quell- und keine Ziel-GA hatte. Ich erinnerte mich daran, dass ich mal eine alte ZSU vom Bus genommen habe und vermutete, dass die PA nicht sauber getrennt wurde. Also habe ich ein anderes KNX-Gerät (die ZSU ist bereits verkauft .... habe ja nun EDOMI ... ;-) ) auf die alte PA der ZSU programmiert und getestet. Alles sauber ...
- Anschließend habe ich das Test-KNX-Gerät sauber entladen und aus der ETS gelöscht.
- Resultat: Keine Fehlermeldung mehr im ETS-Monitor bzgl. der o.g. PA
- ABER - und nun kommt das Problem - in EDOMI geht es seitdem im Sekundentakt mit Fehlereintragungen ins LOG. Diese finde ich allerdings nicht im Monitor in der ETS wieder. Was nun?
- Der Fehler lautet nun:

2016-03-08 16:57:53

745417

KNX

9235

ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 061004200015040126002900b0c011fe0000010100

=> Die Analyse der KNX-Spezifikation habe ich versucht ... allerdings ohne Erfolg. Leider ging die Spec nicht weit genug in die Tiefe ... oder - was ich eher vermute - ich habe nur das falsche Doc gefunden.

Kann jmd helfen? - DANKE!

EDIT: Nach Aktivierung von edomi ist der Fehler, der im Sekundentakt ins Log geschrieben wurde, erst einmal weg. Ich warte mal ab und gebe später mal Rückmeldung, ob es nun doch funzt.

[gaert]

Im "laufenden Betrieb" die KNX-Konfiguration zu ändern mag EDOMI nicht so gerne Also in Zukunft: EDOMI pausieren, Geräte entfernen/ergänzen, EDOMI starten...