LBS beschleunigen

[blaky]

Hallo Yves,

das Problem habe ich schon verstanden.. ich habe ja auch nichts gegen eine volle Queue! Schön wäre es nur wenn innerhalb der Queue ein Ereignis Priorität hätte.
Das Rollo kann ja in der Visu ruhig etwas zeitversetzt sich bewegen.. aber der Stop Befehl muss gleich ausgelöst werden.
Ich rede hier ja nicht von tausenden UDP Paketen die innerhalb kürzester Zeit einen KO setzen. Es sind im EFall maximal 50 UDP Pakete/Sek. Klar füllen auch die die Queue und es braucht Zeit bis die Queue abgearbeitet ist. Wenn innerhalb dieser Zeit ein Ereignis ausgelöst wird was Priorität hätte und sich vorn in der Queue einordnen würde wäre das perfekt.

[starwarsfan]

Hi

Also ich will ja nicht päpstlicher sein als der Papst aber nein, Du hast das Problem nicht verstanden! Die volle Queue ist das Problem. Wenn eine Queue voll läuft, gibt es an irgendeiner Stelle Kleinholz wie bspw. verloren gegangene oder fehlerhafte Pakete. Dann einfach die Queue grösser zu machen ist keine Lösung sondern nur ein Workaround. Darum ja die Frage weiter vorn, unter welchen Umständen da so viele UDP-Pakete auflaufen. Es ist ja durchaus möglich, dass es in diesem Fall einfach nicht möglich ist, dem Herr zu werden, da sich die Geschwindigkeiten von Ethernet und KNX-Bus doch sehr stark unterscheiden und das kann man dann nicht mehr "live" handhaben.

Wenn es wirklich periodische Peaks gibt, welche sich dann aber wieder normalisieren, sieht die Sache schon anders aus. Genau das ist aber die Frage: Wie häufig kommt es zu dieser UDP-Flut?

[blaky]

Also ich bin schon der Meinung das ich das Problem verstanden habe.. und ein Queue zu vergrößern ist auch nicht mein Ziel!
Das ich zuviele Pakete bekomme (deren Anzahl ich natürlich bemüht bin so klein wie möglich zu halten) sodas die Logik nicht hinterherkommt ist mir doch bewusst, deshalb wird ja auch die Queue aufgebaut! Das die Geschwindigkeit des Ethernet gegenüber des KNX-Buses dazu beiträgt natürlich auch. Ein "live" wird daher nicht möglich sein weil die Logik hinterherhängt, das ist mir auch klar und nehme ich in Kauf!
Mir geht es doch nur zu erörtert ob es eine Möglichkeit gibt Werte die in die Queue aufgenommen werden nach vorn auf Pos1 der Warteschlange zu setzen.

[coliflower]

À la, Internet der unterschiedlichen Geschwindigkeiten (á la wer bekommt die höhere Priorität um schneller / vorgelassen zu werden) … So habe ich blaky’s Frage verstanden.

[WagoKlemme]

Vielleicht sollte beachtet werden, dass Edomi eine Visu mit (viel) Logik für KNX-Installationen ist und auch als solche gedacht ist.

Ich kenne Deinen (blaky) Aufbau nicht, aber soll Edomi in deinem Fall so eine Art "Parallelsystem" sein welches durch UDP angeboten ist ?
Wenn ja, kann ich Dir sagen vergiss es. Ich musste, in meinem Fall Wago, die Erfahrung machen mit Modbus TCP und/oder auch UDP wird nur wie eine Krücke funktionieren.
Auf beiden Seiten müssen die Daten sackweise hin- und hergeschaufelt werden, mit entsprechenden Engpässen. Ich habe deshalb komplett auf KNX umgestellt und die Wago ausgebaut.
In deinem Fall musst Du dich wohl oder übel auch entscheiden. Nur anderes System oder nur Edomi. Erst dann wirst Du glücklich.

Das Beispiel mit den gleichzeitig fahrenden Rolläden (Gruppensteuerung) ist bei mir umgesetzt mit nur KNX. Das funktioniert super, sowohl was die echte "Gleichzeitigkeit des Fahrens" angeht, als auch das Stoppen. Nämlich stoppt sofort.

Das "Queue-Geplenkel" löst doch das wahre Problem nicht, für mich schaut das eher nach einem (bereits) gescheiterten Versuch aus. Und das liegt nicht an Edomi, sondern an Deinem Aufbau. Es geht eben nicht immer alles, auch wenns schön wäre.

[blaky]

Armin
in der Tat ist es eine Art Paralellsystem.. Als Hauptinteligenz und Schaltzentrale dient ein Loxone Miniserver. Dieser kommuniziert ausschlieslich per UDP mit Edomi. Dies klappte mit meiner eigenen Visu bisher absolut zuverlässig. Da Edomi aber mehr visuelle Möglichkeiten bietet, migriere ich jetz zu Edomi. Kann mich bei den normalen Funktionen auch absolut nicht beschweren.. nur bei ein, zwei zentralen Objekten muss ich halt mit der Logikengine haushalten und eine Queue nehmen.

aber mal ein kurzer Zwischenstand:
nach einer Idee von Winni (Danke nochmal) hab ich den UDP Receiver mal so aufgebohrt das er das filtern der UDP Daten und Werte extrahieren im EXEC Teil gleich mitübernimmt und an seinen Ausgängen zur Verfügung stellt. So kann ich die KO's direkt vom UDP Receiver aus setzen. Dies spart ne Menge Logikkomponenten ein.
Die Queue füllt sich jetzt schon deutlich weniger rein gefühlsmässig. Wenn ich jetzt noch auf Loxone Seite nur jedes "2.Rollo Prozent" nach Edomi schicke, sollte sich die Last ja nochmal halbieren.
Eine Prio innerhalb der Queue wäre aber das nonplusultra

[jonofe]

Armin
in der Tat ist es eine Art Paralellsystem.. Als Hauptinteligenz und Schaltzentrale dient ein Loxone Miniserver. Dieser kommuniziert ausschlieslich per UDP mit Edomi. Dies klappte mit meiner eigenen Visu bisher absolut zuverlässig. Da Edomi aber mehr visuelle Möglichkeiten bietet, migriere ich jetz zu Edomi. Kann mich bei den normalen Funktionen auch absolut nicht beschweren.. nur bei ein, zwei zentralen Objekten muss ich halt mit der Logikengine haushalten und eine Queue nehmen.

aber mal ein kurzer Zwischenstand:
nach einer Idee von Winni (Danke nochmal) hab ich den UDP Receiver mal so aufgebohrt das er das filtern der UDP Daten und Werte extrahieren im EXEC Teil gleich mitübernimmt und an seinen Ausgängen zur Verfügung stellt. So kann ich die KO's direkt vom UDP Receiver aus setzen. Dies spart ne Menge Logikkomponenten ein.
Die Queue füllt sich jetzt schon deutlich weniger rein gefühlsmässig. Wenn ich jetzt noch auf Loxone Seite nur jedes "2.Rollo Prozent" nach Edomi schicke, sollte sich die Last ja nochmal halbieren.
Eine Prio innerhalb der Queue wäre aber das nonplusultra

Ich vestehe immer noch nicht, warum man jedes oder jedes zweite Prozent des Rolladenstatus live in der VISU miterleben muss.
Selbst die KNX Rolladenaktoren senden den Status erst einige Sekunden nachdem die Rolläden gestoppt haben. Ich verstehe den Usecase nicht, warum man diesen Aufwand treibt. Nur damit sich in der VISU etwas bewegt?

[gaert]

Eine (asynchrone) Animation in der Visu täte es doch auch, oder? Zumal die Visu-Aktualisierung vermutlich langsamer ist als 1 Prozent "Verfahrweg" benötigt...

[wintermute]

Meine Aktoren senden beim Fahren alle 10% (oder besser etwa 9.5%) und dann die Hoehe beim Erreichen der Zielposition. Damit bekomme ich in der Visu Werte hin die durchaus "live" aussehen ohne den Bus oder Edomi zu ueberlasten. Reicht das denn nicht aus das derart einzuschraenken?

[blaky]

Ja ich sagte ja ich migriere gerade auf Edomi, hatte im alten halt 1% Schritte, werde im Endeffekt wohl auf 5-10% hochsetzen. Natürlich reicht das noch für die Visu aus.