Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Richtig... Ich denke sogar, dass das "vor sich hin oszillieren" (EXEC) am Ende performanter wäre - schließlich entfällt dann der ganze "Overhead" (Eingang => DB => LBS => EXEC....).
Ich kann das auch vom Server triggern lassen... aber da fehlt dann irgendwie das "Optionale". Wenn der Server nen Dutzend Clients bedient merkt man das schon an der Auslastung (auf beiden Seiten) - nicht, dass da was abbrennt oder so, aber ich finds (jedenfalls jetzt noch) charmanter wenn man einen Oszi hat und den dann an die Client Bausteine haengt die man wirklich aktualisiert braucht. So kann recht einfach jeder entscheiden wies fuer ihn am besten ist.
Das ist fuer Nicht-Programmierer einfach einfacher - weil optisch im Logikeditor verstehbar... ich warte erstmal ab, vllt kommen da ja noch Rueckmeldungen zu.
BTW: der (eigentlich) getriggerte Baustein hat keinen EXEC Teil, der ist "klassisch".
für die Abfrage meiner PV-Werte von SMA habe ich wie folgt getriggert:
* Zentraler Oszi minütlich und 5-minütlich. Könnte auch 30sekündlich sein. Nutzbar in beliebig vielen Logiken
* Für meine Diagramme reicht mir 5-minütlich locker; nachts wäre wohl auch 15-minütlich hinreichend.
* Wenn ich auf der Visu-Seite bin, will ich öfter sehen. Wenn ich auf diese Seite wechsle, setze ich ein Flag. In der Abfrage-Logik vor dem Trigger eingang meines LBS habe ich verODERt den 5-minütigen Oszi und verUNDet der Flag-Vergleich und der minütliche Trigger.
* Nachts wäre auch noch eine zusätzliche Logik denkbar.
Ergebnis: Immer so viel Trigger, wie nötig. Wenn ich es nicht sehe, belaste ich das System und den KNX-Bus nicht unnötig
Für Squeezebox wäre das ja ähnlich machbar, wenn ein Client überhaupt an ist UND die Visu-Seite angezeigt wird.
Und: Trigger in Logik ist vielleicht nicht so performant, aber transparent. Wenn man es in den LBS packt, würde ich neben dem Trigger vielleicht ein Frequenz-Eingang (z.B. in Sekunden) mit einem sinnvollen Default-Wert spendieren. Dann ist es auch in der Logik transparent und technisch performant.
Danke
Aber es ist schon so, dass der Trigger auch nur etwas triggert wenn der entsprechende Baustein auch etwas abspielt (bzw der korrespondierende Player, der Baustein selber spielt ja nix ab ). Was aber nix daran aendert, dass der Trigger erstmal da ist und den Baustein triggert. Ob dann daraus irgendetwas entsteht steht dann auf einem anderen Blatt.
Und wer wirklich den Oszi nur dann anschalten will wenn einer der Player grad was abspielt, kann das dann auch mit irgendwelchen Vergleicher-LBS in der Logik selbst bauen, die notwendigen Daten dafuer sind vorhanden - dafuer ist der Logikedtor ja auch vorgesehen...
Man muss auch mal gucken wie weit der LBS gehen soll... sonst hat man hinterher nur noch einen LBS und der heisst "Steuerung-, Haus, v1.0"
naja, ich denke, der getriggerte LBS-Teil ist in jedem Fall unkritisch, wenn man bei "gerade nix zu tun" da wieder raus hüpft. Das trägt nicht auf... Für die Anforderung squeezebox kann ich Deine anders gelagerten Lösungswege nachvollziehen. Gibt halt nicht die eine richtige Lösung. Wär' auch langweilig...
Bei mir wollte ich nur nicht das vergleichsweise teuren POST/GET-Gedöns im EXEC. wenn ich es nicht brauche. Daher finde ich die Idee eines Freuqenz-Eingangs am LBS ganz gut, da man das im LBS Teil lösen könnte. Für mich habe ich einfach den ganzen LBS nicht aufgerufen - mit der Logik oben. Vielleicht finden ja der ein oder andere die Lösung der Last-Sparsamkeit auf diesem Wege ganz charmant, für seine eigenen Logiken oder LBS.
Eine Frage zum Oszillator: ist es aus Performance-Gründen generell empfehlenswert, lieber den System-KO-Trigger anstatt einen Oszillators zu verwenden? Oder ist das egal?
Eine Frage zum Oszillator: ist es aus Performance-Gründen generell empfehlenswert, lieber den System-KO-Trigger anstatt einen Oszillators zu verwenden? Oder ist das egal?
Wenn dir zB die sekuendliche Frequenz gut passt, dann wuerd ich Christians Empfehlung mit dem System-Zeit KO empfehlen - das spart einen Baustein und waere daher performanter. Wenn Du aber eigentlich zB 5 Sekunden brauchst, dann ist es vermutlich sinnvoller einen dedizierten LBS dafuer einzusetzen. Aber auch dabei verweise ich gerne auf Christians Empfehlung besser den Telegrammgenerator zu verwenden, der ist (nicht nur) aus Performance Sicht besser fuer den Zweck geeignet.
Danke für die Infos! Mir ging es insbesondere um die Trigger bei den System-KOs (Täglich, Stündlich, Halb-, Viertelstündlich bis runter auf minütlich). Aber dann werde ich die bevorzugt nehmen, wenn mir diese genügen.
Richtig - die SysKOs werden so oder so im entsprechenden Takt "gesetzt", daher darf man diese getrost nutzen sofern es sinnvoll ist. Jeder LBS braucht natürlich seine Ressourcen (wenn auch relativ wenige - hängt beim Oszillator/Telegrammgenerator von der Frequenz ab).
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Angenommen, ein Baustein soll alle 42s laufen. Was wird da wohl "sparsamer" sein? Den Oszilator zu nehmen und den LBS alle 42s zu triggern oder den System-Sekundentakt zu verwenden und intern einen Zähler zu führen, welcher erst bei erreichen von 42 die eigentlich LBS-Logik ausführt?
So eine "Frequenzteiler"-Logik wäre vermutlich weniger performant als ein Oszi, der alle 42s "etwas macht" - denn dieser Oszi würde von der Logikengine nur alle 42s aufgerufen, während der Frequenzteiler (Zähler) sekündlich "nachdenken" müsste
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Ja klar! Der Oszi wechselt ja zwischen 1/0 - d.h. er generiert quasi die doppelte Anzahl an "Telegrammen", obwohl i.d.R. nur das "1"-Telegramm benötigt wird. Ich schreibe nur immer "Oszi", weils kürzer ist
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar