Zyklische Sender mit zufälligem Start?

[NoMercy]

Hallo Zusammen,

ich habe da mal ein kleines Problem... Ich übermittle derzeit zyklisch z.B. die Griffposition von EnOcean-Fenstergriffen auf den KNX-Bus. Dies habe ich im Prinzip über je ein ein AT pro Fenstergriff realisiert, welches alle 5 Minuten ausgelöst wird. Soweit, so gut.

Jetzt habe ich das Problem, daß z.B. beim Start von FHEM oder einem "rereadcfg" alle AT-Devices gleichzeitig gestartet werden. Dies führt zu einer enormen Buslast auf dem KNX-Bus (25 Devices senden zeitgleich ihren Status auf den Bus) und das wiederholt sich ja dann auch alle 5 Minuten 

Gibt es irgendwie eine Möglichkeit, daß AT beim Einlesen der Konfigs oder beim Start von FHEM innerhalb eines Zeitraumes (z.B. innerhalb von 120 Sek nach dem Start) zufällig gestartet werden und ab dann regelmäßig triggern, damit ich die Buslast etwas entzerren kann?

Oder habt Ihr eine andere Idee für eine Lösung?

Gruß,
Michael

[rudolfkoenig]

Code Auswählen Erweitern

define mAt at +*{sprintf("00:%02d:%02d",rand(5),rand(60))} trigger data

[betateilchen]

Oder habt Ihr eine andere Idee für eine Lösung?

mit dem Attribut alignTime die at devices "verteilen"...

[nils_]

ist das zyklische senden wichtig?
auf änderungen reagieren reicht nicht aus?? das ging dann über notify, oder aber - von mir aus - über _ein_ at welches nur die änderungen auswertet und dann überträgt....

[NoMercy]

@ Rudolf: Danke für den Tip. So funzt es

@ betateilchen: Wäre auch eine Möglichkeit. Allerdings ist meine Konfiguration der "Hardware"-Devices und zugehörigen Logiken (DOIFs, AT, etc.) über einen ganzen Haufen verschiedene Dateien verteilt. Diese Dateien generierte ich per ansible und j2-Templates. Da muß ich bei Änderungen nicht immer alle Devices von Hand ändern, sondern brauche nur das zugehörige Template anzupassen. Hier noch zusätzliche Schleifen einzubauen, damit ich unterschiedlichste alignTimes setze, ist ein immenser Aufwand. Die Lösung von Rudolf habe ich schon in den Templates der Fenstergriffe drin und deployed 

@nils_: Ja brauche ich leider. Ich habe eine ältere KNX-PowerLine-Installation als Basis. Selten, aber manchmal, gehen Telegramme auf dem KNX-Powerline-Bus verloren. Das sorgt dann z.B. dafür, daß zwar der Enocean-Fenstergriff seine Funktelegramme an FHEM los wird und FHEM den Status ändert, diese Änderungen aber niemals über den KNX-Bus am RTR ankommen. Dann ist zwar das Fenster zu und FHEM weiß das auch, aber leider der RTR nicht... Und dann bleibt es im Winter im zugehörigen Zimmer kalt  Ich "missbrauche" FHEM also ein bisschen, um einige relevante Telegramme regelmäßig auf den Bus zu schmeißen, und die Tücken der verbauten Hardware auszugleichen

Danke an alle. Ich markiere das ganze jetzt dann als erledigt.