KNX/EIB Allgemein verbindliches Zeitlimit für Antworten auf Leseanfragen?

[JoeHorn]

Hallo,

da es ja schon so manches Mal als Ursache für Visu-Probleme erkannt wurde:

Gibt es bei KNX einen verbindlich einzuhaltenden zeitlichen Mindestabstand für aufeinanderfolgende Anfragen an das gleiche bzw. an verschiedene Geräte? Ich meine über die Summe der Zeiten hinaus, die Frage und Antwort rein für die Übertragung auf dem Bus brauchen.

Gibt es bei KNX ein verbindliches Maximum an Zeit, die sich ein Modul für die Antwort auf eine Leseanfrage lassen darf? Oder darf es sich im Prinzip beliebig lange Zeit nehmen, weil das nirgends spezifiziert ist?

Gibt es wenigstens einen offiziellen Richtwert für die Abfragerate einer Visu?
Try and Error mag ja für den ambitionierten "Hobby-Konfigurierer" noch angehen, aber was machen Gewerbliche? Einfach riesige Sicher-ist-sicher-Abstände und es dauert viele Minuten nach einem Reset? Das darf doch eigentlich nicht sein - das müßte doch eigentlich definiert worden sein...
oder doch nicht?

[meudenbach]

...Frage und Antwort rein für die Übertragung auf dem Bus brauchen

soviel ich weiss, ist das nie richtig definiert worden und ergibt sich aus den physikalischen Grenzen...

Gibt es bei KNX ein verbindliches Maximum an Zeit, die sich ein Modul....

Diese Zeit wird allein durch den Empfanger bestimmt und ist eigentlich nur "höheren" Plattformen vorbehalten. Also auch hier keine eindeutige Spezifikation.

Gibt es wenigstens einen offiziellen Richtwert für die Abfragerate einer Visu?

Mike macht das mit 3 Telegrammen/s auch in hoch belasteten Anlagen jedoch sollten die Flag's sauber programmiert sein und die Abfragen selektiert. Dies wird auch so als Richtwert genannt...

...

LG

[Uwe!]

also ich musste bei meinem Infoterminal die Verzögerung zwischen Statusabfragen auf 250 ms erhöhen. Mit weniger kamen einige Aktoren manchmal nicht hinterher und haben einige Leseanfragen unbeantwortet gelassen. Wären also 4/s. Das ist wohl nahe am Limit.

[meudenbach]

Hi Uwe,

wie bereits erwähnt... eine Abfrage generiert ja mind. 2 Telegramme (Abfrage und Antwort). Es sollte natürlich sichergestellt sein, dass eben eine Abfrage auch nur eine Antwort zur Folge hat !!! Sowie keine weiteren Störungen vorhanden sind.... Ergo, eine sauber programmierte Anlage ;-)

Dann geht uU auch mehr. Ich denke bei Deinen Problemen war es aber eher das Info Terminal, welches den Speed nicht verarbeiten konnte... schlecht wirken sich auch Systeme mit Anbindung über klassische RS232 aus, da kann es auch bei 3Telegrammen/s zu Problemen kommen...

Wir arbeiten idR aber so, dass Abfragen gar nicht erst nötig sind. Bei Grossanlagen senden wir wichtige Meldungen zyklisch, so dass sich sämtliche Systeme eben nach kurzer Zeit selbst aktualisieren. Ferner werden Datenpunkte mit geringer Priorität, wie zB eine simple Leuchte, ggf. bei Bedarf abgefragt, also dann wenn sich die Seite öffnet, wo der Datenpunkt vorhanden ist...

Man könnte natürlich auch ein Prozessabbild speichern, aber das macht wenig Sinn, da je nach Art und Dauer der Störung das Abbild schnell verfälscht ist....

Ich mein, wir verfahren so bei Anlagen mit Datenpunkten im 6stelligen Bereich... bei Anwendung vernünftiger Strategieen und ordentlicher Hardware ist das überhaupt kein Problem.

LG

[JoeHorn]

1. soviel ich weiss, ist das nie richtig definiert worden

2. und ergibt sich aus den physikalischen Grenzen...

3.Diese Zeit wird allein durch den Empfänger bestimmt und ist eigentlich nur "höheren" Plattformen vorbehalten.

4.Also auch hier keine eindeutige Spezifikation.

5. Mike macht das mit 3 Telegrammen/s auch in hoch belasteten Anlagen jedoch sollten die Flag's sauber programmiert sein und die Abfragen selektiert. Dies wird auch so als Richtwert genannt...

1. Soviel zum Standard...
2. Wessen? Die des Busses? Der sollte im Mittel mehr als 8 Telegramme/s schaffen. (meine Lichtszenen laufen mit 10 Telegrammen/s (1-Byte-Objekte) problemlos) Die der Teilnehmer? In deren Dokumentationen habe ich leider nie Angaben dazu gefunden.
3. Empfänger ist klar, aber was heißt "höhere" Plattform? Das man sich bei der Spezifikation nur auf das Transportprotokoll für einzelne Telegramme auf dem Bus beschränkt hat, und ignoriert, das für eine erfolgreiche Kommunikation auch die höheren Schichten sich einig sein müssen? Der Standard soll doch herstellerübergreifend sein, da müsste alles spezifiziert sein, was nach außen zu "sehen" ist. Dazu gehören auch Reaktionszeiten und "höhere" Protokollschichten.
4. Standard also unvollständig! Ich kann alle Vorgaben einhalten und trotzdem funktioniert ggf. gar nichts!?

1. eine Abfrage generiert ja mind. 2 Telegramme (Abfrage und Antwort).
Es sollte natürlich sichergestellt sein, dass eben eine Abfrage auch nur eine Antwort zur Folge hat !!!
Sowie keine weiteren Störungen vorhanden sind.... Ergo, eine sauber programmierte Anlage ;-)

2.Ich denke bei Deinen Problemen war es aber eher das Info Terminal, welches den Speed nicht verarbeiten konnte...

3. schlecht wirken sich auch Systeme mit Anbindung über klassische RS232 aus, da kann es auch bei 3Telegrammen/s zu Problemen kommen...

4. Wir arbeiten idR aber so, dass Abfragen gar nicht erst nötig sind. Bei Grossanlagen senden wir wichtige Meldungen zyklisch, so dass sich sämtliche Systeme eben nach kurzer Zeit selbst aktualisieren.

5. Ferner werden Datenpunkte mit geringer Priorität, wie zB eine simple Leuchte, ggf. bei Bedarf abgefragt, also dann wenn sich die Seite öffnet, wo der Datenpunkt vorhanden ist...

6.Man könnte natürlich auch ein Prozessabbild speichern, aber das macht wenig Sinn, da je nach Art und Dauer der Störung das Abbild schnell verfälscht ist....

7.Ich mein, wir verfahren so bei Anlagen mit Datenpunkten im 6stelligen Bereich... bei Anwendung vernünftiger Strategieen und ordentlicher Hardware ist das überhaupt kein Problem.

1. Schon klar.
2. Auch dessen maximale Reaktionszeiten sind nicht in dessen Dokumentation zu finden und vermutlich ebenso wenig durch den KNX-Standard definiert, oder?
3. Zum Glück nicht vorhanden.
4. Mache ich, soweit möglich, aber einiges läßt sich nicht auf zyklisch konfigurieren, nur auf "bei Änderung". Ändert sich lange nichts, tappt man im Dunkeln.
5. Währe die von mir am liebsten umgesetzte Lösung, nur kann ein Master Control das nicht (oder ich habe diese Option noch nicht gefunden).
6. Kann meine Visu eh nicht, fände ich auch weniger sinnvoll. Wenn was angezeigt wird, soll es auch aktuell sein.
7. Bin im dreistelligen Bereich - nur ob die HW vernünftig ist??


Fazit:
1. Ich werde es demnächst gemächlich mit 2 Abfragen/s versuchen, dauert dann halt über eine Minute...
2. Da es meistens funktioniert scheinen sich die Hersteller untereinander irgendwie über das zu einigen, was zwingend erforderlich ist, vom Standard aber nicht definiert wird. Und am besten klappt das beim Preis...

[Uwe!]

Ich denke bei Deinen Problemen war es aber eher das Info Terminal, welches den Speed nicht verarbeiten konnte...

Nö! Das Info Terminal kann die Abfragen auch deutlicher schneller rausschicken und auch die Antworten dazu verarbeiten, sofern sie denn kommen. Konkret war es der Gira Heizungsaktor, der nachvollziebar auf ca. 15 Abfragen im kurzen Zeitabstand nie auf alle 15 geantwortet hat, sondern immer (andere) 3-5 "vergessen" hat. Nur durch langsames Abfragen schafft der Aktor alle Anfragen zu verarbeiten und darauf zu antworten.

[Uwe!]

4. Mache ich, soweit möglich, aber einiges läßt sich nicht auf zyklisch konfigurieren, nur auf "bei Änderung".

"Einiges" sendet seine Datenpunkte auch ohne Eingriffsmöglichkeit ständig, vollständig und mit maximaler Geschwindigkiet (die in diesem Fall zum Glück eher gemächlich ist) über den Bus!

[JoeHorn]

1. Das Info Terminal kann die Abfragen auch deutlicher schneller rausschicken und auch die Antworten dazu verarbeiten...

2. Konkret war es der Gira Heizungsaktor, der nachvollziebar auf ca. 15 Abfragen im kurzen Zeitabstand nie auf alle 15 geantwortet hat, sondern immer (andere) 3-5 "vergessen" hat.

3. Nur durch langsames Abfragen schafft der Aktor alle Anfragen zu verarbeiten und darauf zu antworten.

2. Bei mir ist ein Berker Heizungsaktor das Sorgenkind. Gemaß "Gira = Berker = INSTA" habe ich dann wohl ein baugleiches Gerat mit vermutlich identischer Software. Und somit das selbe Problem. Ich hatte ihn gerne zyklisch (z.B. alle fünf bis 10 Minuten) senden lassen, nur habe ich nirgends eine Einstellmöglichkeit dafür gefunden!

1.+3. Das ist genau das, was ich meine: Die Gerate sind unterschiedlich schnell, das ist nirgendwo dokumentiert, nicht geregelt und das Verhalten ist noch nicht einmal gleichbleibend.
Das da noch keiner der "Installateure" (ich meine diejenigen, die das standig beruflich konfigurieren müssen) protestiert hat...
Oder hat jemand, und es ist den Herstellern schlicht egal?

"Einiges" sendet seine Datenpunkte auch ohne Eingriffsmöglichkeit standig, vollstandig und mit maximaler Geschwindigkiet

Das ist fast schon ein KO-Kriterium!

[meudenbach]

"Einiges" sendet seine Datenpunkte auch ohne Eingriffsmöglichkeit ständig

Da ist dann aber bestimmt kein EIB/KNX Logo drauf... und was so alles unter "extended Device" auf dem Markt ist, ist schon sportlich....

Denn wer was, wann und wo sendet ist schon eindeutig definiert nur setzten es die Hersteller nicht immer entsprechend um. Derartige Dinge obligen auch alleinig dem Hersteller und gehören nicht zu den zertifizierungs Richtlinien der EIBA/Konnex. Soll heißen, der Hersteller selbst trägt die Verantwortung für die Einhaltung des Standards !!

Nachmal zu den Antwort Zeiten. Wir reden hier ja nicht über ein echtzeitfähiges System. Da sind auch Antwortzeiten fest definiert.

Da jeder Teilnehmer für sich selbständig sendet kann man ja auch nicht sagen, welcher Teilnehmer zu welchen Zeitpunkt an der Reihe ist... folglich varieren die Response Zeiten. Wenn Koppler im Spiel sind, müssen auch die Puffer hinzugerechnet werden, wann der LK das Telegramm auf den Bus bringt.... da können im wurst case einige Sekunden zusammen kommen...

Nun könnte man alle Kriterien zusammenrechnen und Du hast eben Deine maximale Antwortzeit... da hab ich aber keine Lust zu :-) und das meine ich eben mit physikalischen Grenzen...

Andere Systeme wie zB ein OPC Server (höhere Plattform), können so konfiguriert werden, dass eben der Datenpunkt auf "undefiniert" gesetzt wird, sofern keine Antwort oder kein Acknowledge innerhalb eine bestimmten Zeit eingetroffen ist. Ein "gute" Software kann dann zB eine Abfrage wiederholt starten !!

Aber das alles sind Dinge über die ich mir im EFH kein Kopf mache :-) und wir reden auch von Häusen mit 7000 Teilnehmern und 7-8K Gruppenadressen...

Und Geräte die "krückenhaft" arbeiten, die wird es immer geben.... mit oder ohne Standard...

LG

[Uwe!]

Da ist dann aber bestimmt kein EIB/KNX Logo drauf...

Das PlugIn schmückt sich zumindest mit "Konnex zertifiziert", auf der Hardware hab ich noch nicht nachgeschaut.

zu Punkt 2 von Joe: Die Gira Variante bietet die Möglichkeit zum zyklischen Senden. Oder ist es bei Wertänderung? Das weiß ich jetzt nciht ganz genau, aber eines von beiden geht.

[Klaus Gütter]

Die KNX zertifziert keine Plugins, nur Geräte (Hardware) und Applikationsprogramme.

Gruß, Klaus

[Gaston]

Die KNX zertifziert keine Plugins, nur Geräte (Hardware) und Applikationsprogramme.

Gruß, Klaus

Ja, und genau das ist in meinen Augen eine der grössten Schwächen vom KNX/EIB. Nach aussen hin wird es gerne so dargestellt als g$be es nur ein Standard tool zur Konfiguration was ein grosser Vorteil gegen einigen Konkurenzprodukten ist, die realoit$t ist aber ganz anders, die ETS ist nicht Teil des Standards. Denn die Entwicklungs-ETS kann nur von KNX-Mitgliedern erworben werden und dann wäre der Standard nicht mehr offen.

Was das Timing betrifft gibt es wie Mike schon gesagt hat nur low level timings, wie schnell die Geräte antworten (ausser Bestätigungstelegremme) ist nicht definiert.

Die Mindestdistanz zwischen zwei unterschiedlichen Telegrammen auf KNX/TP ist 76 bits was sich zusammensetzt aus 15 leer bist bis zum ACK, 8 (N)ACK... bits und mindestens 53 leer bits. Bei wiederholten Telegrammen wird dies um 3 bits verkürzt um Ihnen eine implizite Priorität zu geben. Bei einer bitzeit von 104 Mikrosekunden (9600 bit/sec) ergibt sich also eine Mindestdistanz von 7.9ms (bzw. 7.6ms).

Dies bezieht sich dann zumindest auf die Frage des Mindest Zeitabstands zwischen zwei Telegramme an verschiedene Geräte. Bei dem gleichen Gerät könnte dieses natürlich ein BUSY die folge sein.

Meine persönliche Meinung: Geräte tun natürlich gut nach einem empfangenen Telegram spätestens wieder beim 3. darauf folgenden Telegramm Empfangsbereit zu sein,was dennoch wegen überlappung problematisch sein kann, also besser beim nächten. Dabei dürften BCU2 Geräte es einfacher haben dies zu bewerkstelligen als BCU1 Geräte.

Gruss,
Gaston

[Uwe!]

Die KNX zertifziert keine Plugins, nur Geräte (Hardware) und Applikationsprogramme.

ich guck heut Abend mal genau nach, was drauf steht. PlugIn war aber eh ein von mir hier falsch gewählter Begriff. Das Teil hat kein PlugIn, nicht mal Objekte und auch keine Parameter die einzustellen wären. Das einzige was zu tun ist, ist über eine zusätzliche Lasche im Eigenschaften-Dialog (und da steht der Konnex-Hinweis) ein XML-File ins Gerät zu laden.
Sorry für die Verwirrung mit PlugIn

[JoeHorn]

zu Punkt 2 von Joe: Die Gira Variante bietet die Möglichkeit zum zyklischen Senden. Oder ist es bei Wertänderung? Das weiß ich jetzt nciht ganz genau, aber eines von beiden geht.

Bei Berker geht genau eines von beiden: bei Wertänderung.
Tut sich lange nichts, tappt man so lange im Dunkeln.

[Uwe!]

hm, vielleicht ist bei Gira dann auch nur Wertänderung, hab jetzt nicht nachgeschaut. Aber zumindest der interessante Wert Stellgröße ändert sich im Regelfall doch häufiger, oder? Na gut, im Sommer kann er sehr lange bei 0 bleiben.
Ich les bei Neustart jednfalls auch alles erst mal "frisch" ein, eben mit 250ms Abstand.