Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[gaert]

Ok, ich lade die Datei mal auf GoogleDrive hoch (proc_knx.php.zip) im Ordner "test".

WICHTIG:
Die Datei natürlich zunächst entpacken. Dann die Datei proc_knx.php in folgenden Ordner kopieren: /usr/local/edomi/main/proc (die alte Datei kannst Du ja umbenennen, sonst wird die Datei überschrieben).

WIRKLICH WICHTIG:
Die Übertragung der Datei per FTP muss UNBEDINGT im Binary-Modus erfolgen!! Viele FTP-Clients denken "Ah, eine php-Datei! Also ASCII!" - die Datei ist aber KEINE gewöhnliche PHP-Datei, sondern eine binäre Datei (kompiliert). Eine Übertragung im ASCII-Mode zerstört die Datei und EDOMI startet nicht mehr!

[basaltnischl]

Ich komme leider erst Donnerstag zum testen, da gerade Beruflich unterwegs.

[coliflower]

Bis jetzt scheint es zu laufen … https://knx-user-forum.de/forum/proj...319#post905319

[stefan.gey]

gaert

So läuft es bei mir mit einem Siemens N148/2x seit Jahren ohne Probleme:

...
CEMIConnectionRequest request = new CEMIConnectionRequest(packet.ServiceType, packet.Body);
if(request.ChannelId == this.channelId)
{
    byte received = request.SequenceCounter;
    byte expected = this.receiveSequenceCounter;

    if(received == expected || received == expected - 1)
    {
        byte[] ack = new CEMIConnectionAck(this.connectionTypeInfo.Ack, this.channelId, received, ErrorCode.NoError).ToArray();
        Send(ack);

        if(received == expected)
        {
            this.receiveSequenceCounter++;
            if(this.OnFrameReceived != null)
                this.OnFrameReceived(this, request.Data);
        }
    }
}
...

D.h. mein eigener Counter wird nur erhöht, wenn der empfangene und erwartete gleich sind.

[coliflower]

OK, die erste Fehlermeldung ..

FehlerLog:
2016-01-26 20:48:56 858099 KNX 15063 ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=13, Soll-Wert=14 / Raw: 06100420001704020d002900bce0111503050300800770 ERROR

TraceLog:
2016-01-26 20:48:55 945362 KNX 15063 ROUTER @ DE | TUNNELING_REQUEST:L_Data.ind / Typ: Write / SeqCounter: 13 (13) / PA: 1.1.21 / GA: 0/3/5 = 19.04 / Raw: 06100420001704020d002900bce0111503050300800770 Ok

2016-01-26 20:48:55 945472 KNX 15063 EDOMI @ DE | TUNNELING_ACK / Raw: 06100421000a04020d00 Ok

2016-01-26 20:48:56 857985 KNX 15063 ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=13, Soll-Wert=14 / Raw: 06100420001704020d002900bce0111503050300800770 ERROR

2016-01-26 20:48:56 858266 KNX 15063 EDOMI @ DE | TUNNELING_ACK / Raw: 06100421000a04020d00 Ok

[gaert]

coliflower
So weit so "gut" - Dein Router hat ja offenbar so seine Probleme. Entscheidend ist nun: Was passiert nach dem "Fehler" (der übrigens mehr als Hinweis zu verstehen ist): Geht's normal weiter oder hagelt es Fehler (wie mit dem anderen Stack)?

[gaert]

stefan.gey
Danke für den Tipp! Genau so handhabe ich das in der Testversion(!) auch. Dann werde ich dieses Verhalten wohl auch in der offiziellen Version implementieren. Die Spec schweigt sich hierzu leider aus - oder ich finde den entscheidenden Hinweis nicht.

[coliflower]

gaert
Bis jetzt sind es 3 Fehler, keine 100+
Morgen werde ich es sehen ob es „hagelt“ oder nicht und ob meine einfache LOGIK „alle Lichter AN/AUS“ noch plausibel ist oder nicht … werde berichten.

[gaert]

Dann dürfte der Fall klar sein: Dein Router verheddert sich gelegentlich - bzw. irgendwas klemmt in Deiner KNX-Installation...

Ich werde dann die Testversion der proc_knx beim nächsten Update für alle übernehmen (schaden kann's auch bei anderen Routern nicht).

[coliflower]

Ich werde einmal die Hardware direkt am KNXnet/IP-Router hänge um die komplette LAN Struktur auszuschließen … Der Gira hat ja zwei RJ45

[stefan.gey]

gaert

Bin auch noch mal gerade durch die DIN/Spec geflogen und habe dazu keine eindeutige Aussage gefunden. Aber: In die Situation mit dem Delta von 1 kommt man, wenn der Server (Router/Schnittstelle) auf ein an den Client (EDOMI) gesendetes Paket innerhalb einer bestimmten Zeit kein ACK erhalten hat und er daraufhin das gleiche Paket mit gleicher SeqNumber nochmals an den Client sendet. An dieser Stelle wäre ein Inkrement des eigenen Zählers falsch, da das nächste (neue) Paket vom Server dann mit der richtigen, schon eingestellten SeqNumber kommt. Wenn man ihn trotzdem erhöht, hat man keine Chance ihn jemals wieder in Gleichtakt mit dem Server zu bekommen, d.h. SeqErrors bis zum nächsten Reboot bzw. Aufbau der Verbindung.

Der Default-Wert für den TUNNELING_REQUEST_TIMEOUT ist mit einer (1) Sekunde recht knapp bemessen. Wenn also alle Beteiligten in der Kette (Router/Schnittstelle, LAN, PC, VM, ...) gerade Mittag machen, kann das schon mal zu einer Wiederholung führen und man hat den Salat.

[gaert]

Absolut korrekt! Nur "leider" schreibt die Spec einen Timeout von 1s vor... Klar könnte man den verlängern (edomi.ini) - aber das wäre nicht Spec-Konform. Da ich und offenbar auch alle anderen diese Fehlermeldung niemals erhalten, liegt natürlich der Verdacht nahe, dass bei coliflower's Konstellation irgendwas nicht stimmig ist.

Das Erhöhen der SeqNumber macht so wie Du es beschrieben hast am meisten Sinn - sehe ich genau so. Schade nur, dass die Spec diesen Umstand offenbar nicht eindeutig vermittelt - tausende Seiten Infos und solche Basics haben "die" vergessen? Kaum vorstellbar, aber offenbar wahr...

[Tqm]

Kann es sein wenn man noch andere Visualisierungsgeräte (Homeserver, Raspi mit Cometvisu und Eibd, usw.) am laufen hat dies Edomi hier aus der Bahn wirft?
Hier noch mein Fehler Log (Achtung bei mir kommunizieren auch Geräte über KNX LTE mode)

[gaert]

Eigentlich nicht, denn EDOMI schnappt sich ja einen eigenen Tunnel. Es sei denn, der Router vergibt einen bereits vergebenen Tunnel - aber das sollte eher nicht der Fall sein.

[Fisch]

Hallo,

hatte die selben Fehler im Fehlerlog wie coliflower.
Seit Update 1.09 sind die weg.

Wobei meine Schnittstelle ein Miniserver von den Grünen ist, und ich mit bei denen nicht sicher bin, ob die alles KNX-konform implementiert habe.

Was bei mir aber schon immer so ist (genau seit 1.05), dass die Rückmeldungen ca 2 s verzögert in der Visu angezeigt werden.
Im KNX Monitor von EDOMI ist die Rückmeldung jedoch sofort EDOMI zu sehen.
Design.jpg
Visuelement.jpg


Jedoch bin ich mir sicher, dass es bei meinen Einstellungen, oder an der Loxone liegt.