KNX/EIB Bus-Startverhalten: best practise für Geräteanlaufzeiten?

[dreamy1]

Hallo zusammen,

gibt es eigentlich sowas wie ein "best practise" für die eingestellten Geräte-Anlaufzeiten?

Nach einem Busausfall/Stromausfall ist ja vorteilhaft, möglichst schnell wieder einen "stabilen Zustand" ohne unnötige Schaltvorgänge und ins Leere laufende Telegramme etc. zu haben und auch die Telegrammflut zu begrenzen.

Ich denke da an folgendes "Konzept" bzw. Reihenfolge, ab wann die Teilnehmer auf den Bus senden (=Geräteanlaufzeit) bzw. aktiv werden:

1) KNX-SV (falls intelligent)
2) Linien-/Bereichskoppler
3) Aktoren (falls "letzter Zustand halten" eingestellt ist, ggf. individuell auf "Aus" falls kritisch)
4) Sensoren
5) Logikmodul(e)
6) Visualisierung
7) ???

Macht das so Sinn bzw. wie habt Ihr das gelöst?

[trollvottel]

Finde ich auch schwierig und interessiert mich auch brennend. Gerade Logikmodule und Visu da kommts ja stark drauf an, ob die den (Aktor/Sensor-)Status beim Start aktiv auslesen können oder nicht, da kann ein deutlich früherer Start ebenso Sinn ergeben.

Auch in Bezug auf die Buslast wäre das interessant. Ansonsten ballert alles auf einmal auf den Bus und die Hälfte fällt hinten runter. Eine rote Bus-LED der Diagnose-SV nachm Stromausfall spricht da Bände

[willisurf]

Klingt erstmal sinnvoll.

Im Detail ist es dann z.T. noch komplizierter.

Wenn z.B. Logiken auf valide Ausgangssignale von vorgeschalteten Logiken/Geräten angewiesen sind, muss man das berücksichtigen, wenn zwischendurch nicht undefinierte oder gar falsche Zustände erzeugt werden sollen.

Klingt kompliziert, betrifft aber i.d.R. nur einige wenige Logiken.

[dreamy1]

Also Visu würde ich tatsächlich nach hinten schieben. Beim Logikmodul kann man i.d.R. einstellen, ob dieses erst bei "gültigen" Eingängen eine Logik triggert, deshalb hatte ich das auf den Start *nach* Sensorik/Aktorik geschoben damit dieses ggf. auch aktiv abfragen kann.

[willisurf]

Beim Logikmodul kann man i.d.R. einstellen, ob dieses erst bei "gültigen" Eingängen eine Logik triggert

Ich weiß, wenn man Werte beim Init abfragt, muss man trotzdem die Reihenfolge beachten, falls das Gerät das abgefragt wird, auch bei nicht vollständiger Initialisierung bereits ein ReadRequest beantwortet.

[dreamy1]

Du warst schneller mit Deinem Beitrag oben, die Antwort hatte eigentlich dem Vorposter gegolten :-)

Hast natürlich Recht, da muss man aufpassen. Ich setze ein LM auch nur für "unwichtige" Dinge ein (Fensterstatus auf Visu etc.), sonst wäre das wieder sowas wie eine "zentrale Komponente", die bei einem Ausfall wichtige Funktionen lahmlegt. Sowas vermeide ich. Wenn bei mir der Fensterstatus da erstmal Schrott auf der Visu anzeigen würde bis das zyklische Senden das korrigiert, wäre das für mich kein Problem.

[HomerJayS]

Hallo, der Thread ist ja schon ein paar Tage alt, daher wollte ich nachfragen, ob du dreamy1 zu einer Lösung gekommen bist.
Im ETS-Schnellkurs habe ich die Empfehlung gelesen, Schaltaktoren nach 10 - 20 - 30 etc. Sekunden starten zu lassen und z.B. Dimmaktoren nach 15 - 25 - 35 etc. Sekunden, dass alsso möglichst wenig gleichzeitig startet. Wenn man das fortsetzt würden z.B. LED-Controller nach 11 - 21 - 31 Sekunden starten starten und JAL-Aktoren nach 12 - 22 - 32...? (reicht 1s Abstand?).
Würde mich interessieren, wie du es gelöst hast, vielen Dank!

[tobiasr]

Wann kann die ETS denn endlich mal eine Empfehlung für die Startreihenfolge abgeben? Sie kennt doch alle Verknüpfungen und könnte einen entsprechenden Baum erzeugen.

[dreamy1]

Würde mich interessieren, wie du es gelöst hast, vielen Dank!

Ich habe das so wie im ersten Post umgesetzt (noch nicht alle Geräte, mache ich sukzessive). Aber nicht für jedes Gerät individuell, sondern nur pro Gerätegruppe. Ich habe da auch nur 5s Abstand für jede Gruppe genommen, sonst muss ich da noch eine Liste pflegen. Wichtig finde ich die Visu, da die dann auch gerne mal 200 Stati abfragt - ich habe die deshalb ganz ans Ende gelegt, also wenn schon Ruhe eingekehrt ist und alle anderen Geräte sendefähig sind.

Ich würde das auch nicht überbewerten - Buskollisionen werden ja grundsätzlich erkannt und KNX funktioniert auch ohne die o.g. Maßnahme nach einem Stromausfall problemlos (auch wenn da eine Menge los ist). Ich lasse eigentlich auch jeden Sensor zyklisch senden, so dass ggf. auch am Anfang verlorengegangene Telegramme wieder kommen.

[dreamy1]

...die ETS denn endlich mal eine Empfehlung für die Startreihenfolge abgeben? Sie kennt doch alle Verknüpfungen und könnte einen entsprechenden Baum erzeugen.

Stelle ich mir schwierig vor, da Geräte unterschiedlich priorisiert verbaut werden. Beim einen ist das MDT VC Easy nur Visu (darf dauern), beim anderen die einzige Möglichkeit das Licht einzuschalten oder die Alarmanlage auszuschalten oder ähnliches. Oder auch bei Logikmodulen, die können egal oder extrem wichtig sein, also sinnvoll diese früher oder später anzuwerfen.

[tobiasr]

Wieso schwierig? Die genaue Funktion der GA im Gerät ist doch bekannt.

[dreamy1]

Die genaue Funktion der GA im Gerät ist doch bekannt.

Verstehe ich nicht. Beispiel:

Du hast ein Logikmodul, was Deine Fensterkontakte verundet und bei einem offenen Fenster plus Abwesend nach 3 Sekunden die Außensirene über einen Schaltaktor ansteuert.

Du hast ein zweites Logikmodul, was lediglich als Betriebstundenzähler fungiert und bei Überschreitung eine rote Lampe über einen Schaltaktor ansteuert, die den anstehenden Austausch der Kohlebürsten im Gäste-WC-Lüfter signalisiert.

Woher soll jetzt die ETS wissen, was eine "wichtige" GA ist und was nicht und entsprechend die Geräteanlaufzeiten richtig einstellt? KI gibts (zum Glück) bei KNX noch nicht

[Beleuchtfix]

Aber wer entscheidet, was wichtig ist?
Stefan war schneller

[jcd]

Ich denke die Idee ist, dass die ETS die „Signalketten“ kennt und so z.B. weiß, dass die Sirene „nach“ dem Logikmodul kommt, welches vorher die Daten von den Fensterkontakten abrufen muss.

Aber, die Start-Reihenfolge ist ja je Gerät und nicht je KO. Das ist (je nach Komplexizität der Anlage) kein triviales Problem und wird es nicht immer konfliktfreie, eindeutige Reihenfolgen geben.

[dreamy1]

dass die ETS die „Signalketten“ kennt und so z.B. weiß, dass die Sirene „nach“ dem Logikmodul kommt, welches vorher die Daten von den Fensterkontakten abrufen muss.

Das wird beliebig komplex: Ruhe- oder Arbeitsstromprinzip am Aktorkontakt, Verhalten bei Busausfall anders als bei Stromausfall etc....und es könnte ja auch sein, dass der Aktor den Sirenenstatus ans Logikmodul zurückmeldet, weil dieses daraus irgendwelche Sammelstörmeldungen generiert. Wie soll da die ETS wissen, welche Richtung wichtiger ist?

wird es nicht immer konfliktfreie, eindeutige Reihenfolgen geben.

Sehe ich auch so, das wird immer auf eine individuelle Betrachtung hinauslaufen.