EDOMI-Releases/Updates | Aktuell: Version 2.03

[crewo]

gaert an dieser Stelle weil es hier auch ein wenig passt: Ich beschäftige mich gerade etwas intensiver mit edomi und bin etwas verwundert wie viele LBS umgesetzt sind. Eventuell kannst du hier etwas dazu sagen, vermutlich mache ich mir da umsonst sorgen:

Einige LBS arbeiten mit Schleifen, welche über Zwangspausen (z.B. usleep) "ressourcenschonend" getrimmt werden. Hier laufen ständig PHP-Prozesse ohne das etwas konkret zu tun ist, besonders ist mir das aufgefallen bei dem UDP-Listener und dem Sonos-LBS. Letzterer fragt auch noch ständig die API über das Netzwerk ab. Mal davon abgesehen, dass man das auch eventuell anders lösen kann, klingt dieses Vorgehen für mich nicht logisch. Muss man hier so vorgehen bei der LBS-Programmierung alles in einer Schleife immer wieder ablaufen zu lassen? Gibt es in edomi keine Möglichkeiten Daten ausserhalb KNX per Push zu bekommen innerhalb des LBS darauf zu reagieren? Was sagst du zu solchen Lösungen, wirkt sich auch unter Umständen auf die "gefühlte" Qualität von edomi aus.

[jonofe]

gaert an dieser Stelle weil es hier auch ein wenig passt: Ich beschäftige mich gerade etwas intensiver mit edomi und bin etwas verwundert wie viele LBS umgesetzt sind. Eventuell kannst du hier etwas dazu sagen, vermutlich mache ich mir da umsonst sorgen:

Einige LBS arbeiten mit Schleifen, welche über Zwangspausen (z.B. usleep) "ressourcenschonend" getrimmt werden. Hier laufen ständig PHP-Prozesse ohne das etwas konkret zu tun ist, besonders ist mir das aufgefallen bei dem UDP-Listener und dem Sonos-LBS. Letzterer fragt auch noch ständig die API über das Netzwerk ab. Mal davon abgesehen, dass man das auch eventuell anders lösen kann, klingt dieses Vorgehen für mich nicht logisch. Muss man hier so vorgehen bei der LBS-Programmierung alles in einer Schleife immer wieder ablaufen zu lassen? Gibt es in edomi keine Möglichkeiten Daten ausserhalb KNX per Push zu bekommen innerhalb des LBS darauf zu reagieren? Was sagst du zu solchen Lösungen, wirkt sich auch unter Umständen auf die "gefühlte" Qualität von edomi aus.

Es hängt immer vom entsprechenden Device ab, wie man eine Anbindung realisieren kann. Wenn z.B. UDP Telegramme empfangen werden sollen, dann muss halt irgendwo ein Listener laufen, der diese Telegramm empfängt. Die HUE Bridge von Philips bietet z.B. keine Event Schnittstelle an, so dass man Änderungen nur über ein Polling der HUE-Bridge mitbekommt.

Aus meiner Sicht ist es nur wichtig, dass es außerhalb der EDOMI Logikschleife passiert, damit es asynchron ist und keine Einfluss auf die EDOMI Performance hat. In geringem Maße hat es natürlich Einfluss, da man sich dieselben Ressourcen teilt. Ein usleep bedeutet dabei, dass keine Prozessorzeit verwendet wird und ist der richtige Ansatz bei solchen Anbindungen. Ich habe z.B. 15 HUE Devices aktiv. Jedes hat einen eigenen php-Prozess. Die Clients sind dabei allerdings in einem blockierenden Wartezustand, bis ein Befehl ausgelöst wird oder die Bridge neue Daten für dieses Device empfängt. Ich habe keine wirklich wahrnehmbaren Performanceeinbußen. Prozessorlast bei einem NUC 2820 liegt bei mir zwischen 8 und 12%. Also noch genug Reserven.

Es ist natürlich auch möglich, dass LBS enorme Performance Probleme auslösen, weil z.B. kein usleep verwendet wird oder die EDOMI Logikschleife belastet wird. Aber hier hat ja jeder die Wahl, welche LBS man einsetzt und die Community gibt da auch ziemlich schnell Feedback, um dann auch solche Probleme zu identifizieren und zu beheben.

Ich würde mir da also eher keine Sorgen machen.

EDIT: Sorry Christian, die Frage ging ja eher an Dich, aber ich wollte auch mal meinen Senf dazugeben

[Winni]

Also zu meinem UDP-Baustein:
Der läuft nicht in einer Dauer-Poll-Schleife, er wartet auf UDP-Pakete. Das usleep ist drin, damit auch andere Prozesse Zeit bekommen, wenn laufend UDP-Pakete reinkommen.
Wenn ich das als php-Neuling falsch interpretiere, bitte ich um Aufklärung.

Bei manchen Schnittstellen gibt's aber kein Push von extern, da muss man sich mit einem Poll zufriedengeben oder die Anbindung sein lassen.

[SeatSLF]

Mir scheint ich habe den Fehler gefunden, ich werde diesbezüglich mal mit Wintermute sprechen, da es diesen Baustein betrifft.
Vielleicht hat sich da zufälligerweiße was getan.

Und es kam mit dem Update von Edomi und dem Baustein etwas durcheinander.

[wintermute]

Was? Ich? Unmoeglich

[crewo]

jonofe danke für die Erklärung! Zumindest der Sonos-LBS fragt in Dauerschleife ab und der ein oder andere LBS macht da auch ähnliche Sachen. Abgesehen von Performance auf dem edomi-Server müllt man sich halt das eigene Netzwerk zu. Da ein sinnvoller Einsatz von edomi für mich aber von einigen LBS abhängt, machte ich mir eben Sorgen ob das doch alles so eine gute Idee ist solange es hier keine Code-Guidlines und/oder Qualitätskontrolle gibt

[gaert]

jonofe Dank für die Erläuterungen - spart mir Zeit und Mühe

@crewo
Das Vorgehen dieser besagten LBS (EXEC-LBS) ist genau richtig so - anders geht es auch garnicht, egal in welcher Programmiersprache "Auf etwas warten" bedeutet immer(!) Schleife. Ob man dies nun "Push" oder "Dämon" oder "Dienst" nennt ist vollkommen egal... Auch Event-getriggerte Systeme (Windows, Linux, macOS, etc.) arbeiten im Hintergrund natürlich mit (Warte)Schleifen, auch wenn es nach aussen hin nicht so offensichtlich ist

Was EDOMI betrifft gibt's 2 Typen von LBS:
- solche, die innerhalb der "Logik-Engine" (ja, auch ne Schleife) aufgerufen und verarbeitet werden - diese dürfen keine (großen) Schleifen enthalten (vergleichbar mit einer SPS)
- und solche, die vollkommen unabhängig als eigene Instanz arbeiten (EXEC) - diese können im Grunde machen was sie wollen (natürlich sollten sie nicht zuviele Ressourcen an sich reißen)

Eine Qualitätskontrolle meinerseits gibt es nur sporadisch, z.B. wenn ich einen LBS selbst nutze. Ansonsten gilt: Ich bin nicht Apple Du darfst gerne die LBS-Polizei spielen! Ich habe dafür schlichtweg keine Zeit...

[coliflower]

... Qualitätskontrolle ...

Diese bist du selbst …
Wie schon zuvor geschrieben, du kannst es verwenden, für dich adaptieren oder selber schreiben ...

Das ist der Vorteil eines offenen Systems :-)

[crewo]

Ok verstanden... bin schon ruhig

Wenn ich mehr von PHP verstehen würde, könnte ich das gerne tun... nur ich denke mir geht es hier nicht anders als den meisten edomi-Anwendern, ich kanns halt nicht leisten und muss mich auf die LBS-Macher hier verlassen.

[WagoKlemme]

@crewo
Ich frage mich schon seit dem vorletzten Beitrag von dir was Du eigentlich sagen/erreichen willst ?
Ist es "gut, dass wir darüber geredet haben" oder "gerne wird jemand für dich eine Qualitätskontrolle für Bausteine einführen" ?
Grundsätzlich ist es, in meinen Augen, ein NoGo hier bestimmte LBSen rauszupicken und rumzukritteln. Alle LBS Entwickler opfern (wie gaert) eine beträchtliche Menge an Freizeit. Jeder gibt sein Bestes, halt das was in ihm steckt.
Falls dir ein Baustein nicht gefällt, lass ihn einfach weg und gut.

Nur damit wir uns nicht falsch verstehen. Auch ich achte auf Ressourcenverbrauch. Ich lasse einfach viele Dinge weg...

[crewo]

WagoKlemme Ich hab hier nicht rumgekrittelt sondern eine Verständnisfrage gestellt. Zudem kamen(!) mir manche Lösungsansätze eben seltsam vor und ich wollte es gerne verstehen. Das sich hier viele sehr viel Mühe geben um ein stabiles System abzuliefern bekomme ich durchaus mit - genau deshalb wollte ich einmal kritisch hinterfragen, wie man dies als Anwender identifizieren kann um selbst für sich zu entscheiden ob man einen LBS trotzdem einsetzt oder eben nicht. Dann hat man auch gleich einen Ansatz wenns mal instabil wird.

Das würde ich gerne bezwecken, ich möchte verstehen was ich meiner Installation antue und nebenbei ein bisschen PHP lernen.

Wenn das im Forum ein No-Go ist Verständnisfragen zu stellen (die evtl. auch mal kritisch wirken) fände ich das sehr schade und hoffe, dass das die Mehrheit hier anders sieht. Ich wollte hier sicher niemanden bloßstellen, ich kann mir ja nicht alles ansehen und wollte eben Beispiele nennen, damit man mich besser versteht.

gaert danke dir für die wie gewohnt sachlich fundierte Erklärung!

[gaert]

Im nächsten Update wird's ein überarbeitetes Codeschloss (Visuelement) geben:

• Codeschloss:
  • der Code kann nun auch per Tastatur eingegeben werden (auf das Feld unten links klicken)
  • der Zifferncode kann nun eine beliebige Länge haben
  • der korrekte Code wird nun nicht mehr im HTML-Quelltext der Visuseite offengelegt

[vento66]

gaert wenn Du das Codeschloss geade anfasst, kannst Du das so gestalten, das bei einer Falscheingabe eine 0 gesendet wird?

[gaert]

Wohin senden? Es werden Befehle ausgeführt, wenn der Code korrekt war - andernfalls eben nicht

Aber ich könnte ein 2. KO hinzufügen (so wie bei Dimmer & Co.) und dieses könnte pauschal auf 1/0 gesetzt werden:

1=Codeeingabe ok, 0=Codeeingabe falsch, -1=gesperrt

[vento66]

So etwas in der Richtung, damit kann man Falscheingaben in einer Logik weiterverarbeiten, oder dem Codeschloss einen roten Rahmen verpassen...