Mögliche Ursachen für Fehler "Das Gerät Antwortet nicht in angemessener Zeit"?

[Oups]

Mit ETS4 und 5 (fast wie bei Firefox: Alle zwei Wochen ein Riesen-Update)

Hmmmm........

Das sehe ich nicht so (ich weiß - klare Themaverfehlung, aber das muss ich an der Stelle los werden).

Für die ETES 4 gibt es seit Erscheinen der ETS 5 gar kein Update mehr. Und bei der ETS 5 gab es am Anfang einige "Unsauberkeiten", welche per Update beseitigt wurden - aber es gab nie Probleme mit einem Update - einfach drüberbügeln - fertig!

Ich bin ETS 2 dabei, und sehe bei jeder neuen ETS klare Vorteile der Vorgängerversion gegenüber.

Ich liebe die ETS 5! Momentan arbeite ich auf Kundenwunsch mit der ETS 4 an einem Projekt - was für ein Rückschritt!
Alles daurt wesentlich länger (SQL), keine automatische Übernahme des GA-Namens usw.....

Ein Gadanke noch zum Hauptthema: in jedem KNX-Telegramm sind viele "Head-Infos" (von wem, an wen, Prioritäten, Routingn usw.). Der eigentliche Informationsgehalt ist da relativ klein. Wenn man nun mehr Information in ein Telgramm packt (die "Head-Infos" bleiben gleich), dann sind die Downloadzeiten eben kürzer (long frames).

@ Klaus: bitte um Korrektur, falls das so nicht ganz stimmt......

lg
Norbert

[Klaus Gütter]

Hallo Norbert,

genau so ist es. Lass uns mal rechnen.

Ein MemoryWrite hat bei short frames maximal 12 byte Nutzdaten. Wie viel Zeit belegt das auf dem Bus?

Das Telegramm selbst ist 23 Byte lang (inklusive Checksumme). Auf dem Bus belegt 1 Byte 13 Bitzeiten (wegen Start- Parity- und Stoppbit), also 299 Bitzeiten. Dann kommt das LinkLayer-Ack des Empfängers von 28 Bitzeiten (15 Bit Pause, dann 13 Bit ACK). Dann 50 Bitzeiten Pause, bevor der Empfänger sein Transport-Layer-ACK schicken darf.
Das TL-ACK ist 8 Byte lang (104 Bitzeiten), dann kommt wieder das LL-ACK (28 Bitzeiten) und nochmal die 50 Bitzeiten Pause.
Insgesamt sind wir jetzt, wenn ich mich verrechnet habe, bei 599 Bitzeiten, also 599 * 1/9600 s = 58 Millisekunden.

Anders ausgedrückt, könnten wir mit short frames unter den besten Umständen 12/58 ms = 206 Bytes pro Sekunde übertragen.

Jetzt long frames, sagen wir mal mit MaxApduLength=40 (die ETS macht im Moment nicht mehr), entsprechend maximal 37 Byte pro MemoryWrite. Das Schreibtelegramm ist jetzt 49 Byte lang, der Rest ist genau so wie vorher. Insgesamt sind wir hier bei 897 Bitzeiten, also 897* 1/9600 s = 93 Millisekunden.

Anders ausgedrückt, könnten wir mit long frames unter den besten Umständen 37/93 ms = 396 Bytes pro Sekunde übertragen - also fast doppelt so viel.

Beim echten Programmiervorgang der ETS ist der Durchsatz geringer. Das liegt einerseits daran, dass im Moment die geschriebenen Daten vom Gerät auch immer nochmal zur Kontrolle zurückgeschickt werden (das halbiert den Durchsatz), andererseits braucht das Gerät zum Schreiben und sonstigen inneren Verarbeitung etwas Zeit, und schließlich gibt es noch Verzögerungen beim Transport (Linienkoppler, Schnittstelle).

Gruß, Klaus

[rosebud]

Um die 29 KB Daten auf gleicher Linie ohne Koppler etc. in einen Smartsensor zu übertragen, ist die ETS etwa 20 Minuten beschäftigt. Die Blocklänge variiert zwischen einem und 256 Byte. Dann wird eine Checksumme ausgetauscht. Ich bin stark der Ansicht, daß das Übertragungsformat herstellerspezifisch ist und sich einen Teufel um die max. 14 Bytes Standard-Framelänge der KNX schert, zumindest, wenn man in derselben Linie bleibt. Ob die Koppler mitspielen und was in den Layern darunter abgeht, entzieht sich meiner Kenntnis. Für 29 kB netto bei 9.600 Baud fallen 37 s an. Der Rest ist overhead und ich kann mir nicht vorstellen, daß man bei longeren frames auf Datensicherung etc. verzichtet.

Schlauerweise bieten die Hersteller von Touch-Screen-Displays das Laden der Anwendung über eine USB-Schnittstelle außerhalb KNX an, sonst wäre das System jedesmal ein paar Stunden tot. Daran wird sich nichts ändern, egal wie long die frames sind.

Übrigens: Was die ETS4 und -5 an zusätzlichen Features präsentieren, hätte sich locker in ein paar Plug-Ins für die ETS3f unterbringen lassen. Dann wäre einem viel Leid erspart gebleiben.

Gruß, Berthold

[Klaus Gütter]

Hallo Berthold,

Der Smart Sensor benutzt zwar zum Download ein Plugin, das dieses spezielle Protokoll mit Blockübertragung und Checksummenprüfung implementiert. Die reine Übertragung ist aber keineswegs herstellerspezifisch, sondern benutzt ganz normale MemoryWrite-Messages in short frames.

Gruß, Klaus

[hjk]

Auch, wenn das Thema hier abgedriftet ist, der Long Frame Support ist sinnvoll und bringt real 30-40% Zeitersparnis.
Das macht sich deutlich bemerkbar. Alle Teilnehmer in der Kette müssen Long Frames Supporten, sonst geht es langsam.
Also ETS5, Interface mit Long Frame Support, und ein Endgerät mit Long Frame Support.
Da gibt es keine Probleme und da funkt auch rkeiner zwischen.
Beim Smart Sensor geht das aber nicht, da er nur Short Frames unterstützt.
Ich kann den Umstieg auf ETS5.5 nur empfehlen. Für neue Geräte wird es keine ETS3 Datenbanken mehr geben, weil viele Funktionen mit ETS3 schlichtweg nicht gehen oder nur mit Einschränkungen.
Die ETS3 Zeit läuft nunmal ab.

Gruß
hjk

[rosebud]

Ich frage mich, was will man mit longen frames anfangen, wenn es um das Einschalten oder Dimmen einer Lampe geht oder das Bewegen einer Jalousie oder das Ansteuern eines Heizventils. Auch mit longen frames wird nie das Bild einer Türklingelkamera über KNX übertragen, ebensowenig wird man Anwendungen für Touchscreendiplays laden. Longe frames wären mit Plugins in ETS3f genausogut zu implementieren gewesen. Nur braucht die kein Mensch. Hier versucht man, etwas in den Markt zu drücken, um eine Existenzberechtigung für ETS5 vista zu generieren.

Der wahre Grund für ETS4 und 5 ist mit Sicherheit ein ganz anderer. Nur traut sich niemand von den ETS-Profis, den zu nennen. Ich bin kein Profi.

[hjk]

Sorry, das hat miteinander überhaupt nichts zu tun. Long Frames haben weder was mit den normalen Gruppenadressen zum Schalten/Dimmen und auch nicht mit dem Bild der Türklingelkamera zu tun. Es werden aber auch Long Frame Gruppentelegramme kommen, die es erlauben mehr als 14Byte Texte zu senden.
Long Frames hätten auch nicht über veraltete Plugins in die ETS3 implementiert werden können, wenn der Gerätetreiber von Falcon das nicht einmal beherscht.

Longframes sind sinnvoll, da sie bei neuen Geräten viel Zeit beim Übertragen der Applikation sparen. Das macht viel Sinn, spart Zeit und Geld.

Man kann natürlich auch mit der ETS3 stehen bleiben. Da steht man dann aber irgendwann auf dem Abstellgleis, wenn man keine alten Geräte mehr bekommt.

Wir benutzen täglich Funktionen in der Entwicklung, die bei ETS3 einfach gefehlt haben.
Es ist eine sinnvolle Weiterentwicklung, auch wenn es einige Stolpersteine gegeben hat.
Moderne Datenbanken wie für den Glastaster II Smart wären mit der ETS3 überhaupt nicht denkbar.
Das Laden der Datenbank unter ETS4 mit Short Frames macht auch keinen Spass, da man dann 40-50% länger als bei der ETS5 braucht.
Die Erfahrung hast du ja beim Smart Sensor gemacht. Würde der mit neuer Technik aufgesetzt, sähe das anders aus.

lg
hjk

[rosebud]

Jetzt sind wir ganz vom Thema des Threads abgekommen. Taucht die Fehlermeldung "Das Gerät..." bei ETS 5 nicht mehr auf? Bei "meiner" Anlage ist sie noch nie vorgekommen, egal, ob ETS 3 oder -4. Ich lade die Smarties allerdings grundsätzlich von derselben Linie, ohne Linienkoppler und -verstärker oder irgendwelches IP-Gerümpel dazwischen.

Nochmal zu longen frames: Das dürfte noch ein paar Jahre und Mio. Euros - wer wird dies bezahlen? - dauern, bis die KNX-Geräte-Hersteller ihre Produktpalette komplett umgestellt haben. Für Erweiterungen in Bestandsanlagen mit geschätzten 20 Jahren Lebensdauer sind longe frames ohnehin kein Thema, weil zuerst alle Linienkoppler auszutauschen sind. Und das, um ein paar Sekunden bei der einmaligen Inbetriebnahme zu sparen? KNX ist jetzt schon überteuert, wenn ich für ein Netzteilchen mit fünf Euro Materialwert ein paar Hunderter hinblättern soll.

Man gewinnt viel mehr, wenn man KNX-Anlagen vernünftig plant und ausführt. Sobald ich in einer Bestandsanlage auch nur einen Linienkoppler finde, der auf Durchzug steht, weiß ich, woran ich bin. Das Sahnehäubchen sind Geräte, deren physikalische Adressen nichts mit der Nummer der Linie zu tun haben, an der sie angeschlossen sind: Eine Baustelle, die mit "Nach mir die Sintflut" der Nachwelt überlassen wurde. Weder in ETS4 noch in -5 wird dies durch Zusatzfunktionen verhindert. Lieber liefere ich mit ETS3 vernünftige Arbeit ab als Murks, den ich mit neuerer Technik rechtfertige.

Leider ist nicht bekannt, wieviel Lizenzen für ETS3f auf dem Markt sind und wieviele für die Nachfolgerversionen. Wieviel Euro muß ich abdrücken für ein Upgrade von drei auf fünf? Wieviel KNX-Geräte, die mit ETS3f nicht machbar sind, muß ich mit ETS5 in Betrieb nehmen, um auf meine Kosten zu kommen? Kompensiere ich diesen Aufwand durch Zusatzfunktionen? Angesichts der Schußfolge, mit der man ETS4 und -5 auf den Markt geworfen hat, kann -6 nicht mehr weit sein und alle Vorgängerversionen werden schlagartig wertlos.

[DirtyHarry]

Wieviel KNX-Geräte, die mit ETS3f nicht machbar sind, muß ich mit ETS5 in Betrieb nehmen, um auf meine Kosten zu kommen? Kompensiere ich diesen Aufwand durch Zusatzfunktionen?

Ich mach auch heute noch gerne Projekte mit der ETS3, sie ist mir von der Bedienung her noch am liebsten (vor allem im Vergleich mit der ETS4). Jedoch habe ich auch schon mehrere Projekte nicht mehr mit der ETS3 weiter machen können, da die neuen Produkte nicht mehr mit der 3er gehen. Somit stellt sich nicht die Frage wieviele Geräte man mit einer neueren ETS in Betrieb nehmen muss um auf die Kosten zu kommen, sondern wie lange kann man es rauszögern, bevor man keine Aufträge mehr annehmen kann, weil man keine neuen Geräte mehr in Betrieb nehmen kann.

Davon abgesehen, ich habe jetzt gerade wieder ein Problem mit der ETS3 in Verbindung mit dem BJ Powertool gehabt (das Powertool startete nur noch leer und hängt sich auf, was aber nicht bei allen Geräten in dem gleichen Projekt der Fall ist). Das Problem übersteht sogar das Löschen aller Powertool-Geräte, exportieren des Projektes und reimportieren in eine neue Datenbank: Beim erneuten Einfügen eines Gerätes ist es wieder da. Die Konvertierung in die ETS4 löste das Problem aber sofort.

[wknx]

Nabend zusammen,

den Exkurs zum Thema LongFrames fand ich durchaus interessant, nehme für mich aber erst mal mit, dass die hier nichts mit dem Problem zu tun haben. Ich habe den Eindruck das Thema ist ganz ähnlich gelagert wie JumboFrames im Ethernet-Bereich

Ich gehe davon aus, dass auch überhaupt nur versucht wird mit LongFrames zu senden wenn in der Gerätedefinition eine Unterstützung deklariert ist. hjk vielleicht kannst Du dazu noch was sagen?

Ansonsten habe ich leider noch keine Fortschritte erzielen können. Das Problem besteht weiterhin. (Neu)Programmieren der Adresse funktioniert weiterhin wie ich zwischenzeitlich festgestellt habe. Das Problem besteht auch unabhängig davon ob ich das Bedienteil aufgesteckt habe oder nicht. Hatte die Testinstallation zwischendurch auch noch weiter reduziert und nur noch NT, IP-Interface und SmartSensor dran. Keine Änderung.

Habe nun Support-Anfragen bei GIRA und auch KNX laufen. Wenn es etwas neues gibt dann melde ich mich. Bis hierhin erst mal allen beteiligen einen herzlichen Dank für die Vorschläge/Anteilnahme/Diskussion.

Gruß
Wilhelm

[hjk]

Long Frames werden nur benutzt, wenn ETS5 benutzt wird, das Interface und das Gerät es unterstützen. Die max. Länge der Frames ist im Gerät hinterlegt.
Mit deinem Problem hat das gar nichts zu tun.
Die KNX Seite hast du ja schon reduziert. Es könnte aber auch von der IP Seite ein Problem geben. Z.B. wiederholte Telegramme durch Router. Das solltest du im Busmonitor (nicht Gruppenmonitor) sehen können.
Dann kann man in der ETS, ich glaube in Buskommunikation Optionen, eine reduzierte Buskommunikation einstellen. Da wird dann die Pause zwischen den Frames verlängert. Das betrifft aber nur uralte Geräte mit langsamer CPU, die nicht in der Lage sind die Telegramme schnell genug zu verarbeiten.

[wknx]

Was mir zwischenzeitlich noch aufgefallen ist: Wenn ich die Anwendung zum Einstellen der Parameter des SmartSensors öffne erscheint zunächst folgende Fehlermeldung:

Load MainGroups

TEtsGruppenAdressenA::LoadAllMainGroups::Einlesen( ): dwMainGroupAnzahl > MAX_MAIN_GROUP_ANZAHL!

OK

Suche im Internet liefert hierzu keinerlei andere Berichte. rosebud - ist Dir diese Fehlermeldung bekannt oder hast Du eine Idee wonach ich da suchen sollte?

Long Frames werden nur benutzt, wenn ETS5 benutzt wird, das Interface und das Gerät es unterstützen. Die max. Länge der Frames ist im Gerät hinterlegt.
Mit deinem Problem hat das gar nichts zu tun.
Die KNX Seite hast du ja schon reduziert. Es könnte aber auch von der IP Seite ein Problem geben. Z.B. wiederholte Telegramme durch Router. Das solltest du im Busmonitor (nicht Gruppenmonitor) sehen können.
Dann kann man in der ETS, ich glaube in Buskommunikation Optionen, eine reduzierte Buskommunikation einstellen. Da wird dann die Pause zwischen den Frames verlängert. Das betrifft aber nur uralte Geräte mit langsamer CPU, die nicht in der Lage sind die Telegramme schnell genug zu verarbeiten.

Falls Du einen KNX-Router meinst: Ich habe im Netzwerk keine anderen KNX-Komponenten hängen. Ansonsten ist es natürlich ein rein geswitchtes Netzwerk. Monitoring auf dem KNX-Bus hatte ich sogar schon mal laufen, dort ist mir nichts weiteres aufgefallen. Da passiert einfach ziemlich wenig. (Die meisten Zeit nichts).


Ansonsten laufen meine Support-Anfragen weiter.

Gruß
Wilhelm

[Klaus Gütter]

Die Fehlermeldung könnte darauf hindeuten, dass das Plugin keine Hauptgruppenadressen > 15 mag.

[rosebud]

Bisher habe ich den SmartSensor nur mit ETS3f und ETS4 bearbeitet, natürlich mit dem vorgesehenen Plugin. Eine Fehlermeldung wie die genannte ist mir in all den Jahren nie begegnet, egal welche Gruppenadressen benutzt wurden. Vorschlag: Falls verfügbar dieselbe Parametrierung mit ETS3f oder -4 erstellen, um das Problem etwas einzugrenzen. Sollte es damit gehen, ist der Ball im Feld der Connex.

Zum Beitrag #28 von Herrn Gütter: Mir ist vollkommen schleierhaft, wie man mit vier Bits Gruppenadressen definieren will mit einem Hauptteil > 15, wenn man mit 0 beginnt.

[vento66]

rosebud irgendwie scheint es ja doch zu gehen :9 siehe Seite 10 hier:https://www.knx.org/media/docs/Flyer...delines_de.pdf