EDOMI-Releases/Updates | Aktuell: Version 2.03

[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

[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.

[gaert]

Passt hier ein wenig hin: Ich habe inzwischen das Timing der Logik-Engine optimiert, d.h. Logiken werden demnächst schneller abgearbeitet (auf Kosten der CPU natürlich, aber der Unterschied ist marginal). Das Prinzip dahinter: Wenn "was los ist" in der Logik-Queue, wird die Abarbeitung beschleunigt, ansonsten "schläft" die Logik-Engine. Dies war bisher auch so, aber das Abarbeiten erfolgt demnächst mit weniger Latenz.

[SeatSLF]

Ich werde es morgen mal testen, heute es zu spät, sonst sinkt der Laune Pegel bei der Frau

[WagoKlemme]

Ich habe jetzt bei mir "LBS Trig" 10 Minuten beobachtet. Ist und bleibt immer 0:
Screenshot - 06_10 004.png

[SeatSLF]

Werde ich morgen mal machen, die Trigger müssen halt von intern kommen, weil sie selbst da sind
wenn nix auf dem Bus da ist.
Ich schließe jetzt einfach mal aus das die Edomi eigenen LBS auf einmal spinnen.

Aber morgen weiß ich mehr.

Edit:

Ist halt komisch, löse ich im Edomi Monitor ein Request aus, wird er in Zeile und der Spalte
"lesen/schreiben" sofort angezeigt, im Monitor kommt dann wieder die Verzögerung.
Das heißt den Request inkl. Antwort sehe ich z.b. 5Sek später.
Z.b. bei einer simplen Mittelwertbildung mit Edomi LBS, kommt dann nochmal 5sek. später
das Ergebniss.

[WagoKlemme]

Na dann... schalte doch auch noch diese ab. Dann weisst Du mehr.
Die 5 Trigger kommen doch nicht von nichts.

[SeatSLF]

Ozsilatoren sind nicht vorhanden, ein timer wird nur gesetzt wenn ein UND und ein ODER Gatter vorher an sind.

Permanent laufende LBS habe ich nur einen Watchdog, die laufenden LBS würde man doch sehen,
da die rot umrandet sind ich hatte mich schon durch sämtliche Logiken geklickt

Zumal das ganze ja bis zum Update ohne jegliches Problem gelaufen ist.

Edit:
Ich werde morgen mal alle Logiken deaktivieren und dann Stück für Stück wieder "zuschalten"

[WagoKlemme]

Was mich verwundert, das in der Systemanzeige ständig und im ca 3 sek. Takt unter "LBS TRIG" eine 5 auftaucht,
wo kann ich schauen was da passiert?

Auch wenn die Community-LBS aus sind, kann, wie der Name LBS Trig schon verrät, nur in der Logik der Hund begraben sein. Oscillator, Timer, Ein-/Ausschaltverzögerung all die in deren LBSen eine Schleife nudelt. 5 habe ich da noch nie gesehen.

[eriche]

seid froh, dass ihr nur so wenig Errors habt - so sieht das bei mir aus 97k in 11 Tagen.
JA ich habe ein kack WLAN Netzwerk, da ich noch nicht mit der Verkabelung fertig bin - aber die Error Spam Flut ist schon a wahnsinn
Edomi_ErrorWahn.jpg

[WagoKlemme]

Kann es sein, dass die neueren Versionen etwas Ressourcen-hungriger sind?
Möglicherweise sollten die Hardware-Mindestvorraussetzung höher geschraubt werden?

Nein, kann nicht sein. Mein Celeron 3150 läuft mit 1-3% bei 1400LBS und 1300KOs. Im Gegenteil an der CPU-Last hat sich bei 1.45 nichts verändert, aber die Projektaktivierung ist bei mir um ca. 1/3 verkürzt durch die Optimierung.
Allerdings habe ich auch von Anfang an auf den Ressourcenverbrauch geachtet, bin dafür auch mehrmals belächelt worden.
Vielleicht bewirkt an einigen Stellen (vor allem Ausgängen) ein SBC ein Ende einer "Endlosschreiberei".
Aber wundern würde es mich bei so manchem Kollegen hier nicht, was da alles an IP-Geschichten reingehängt wird. Da fragt man sich schon soll das eine HAUSsteuerung sein, oder eine Internetbox/Handyersatz.

[gaert]

Kann es sein, dass die neueren Versionen etwas Ressourcen-hungriger sind?
Möglicherweise sollten die Hardware-Mindestvorraussetzung höher geschraubt werden?

Im Gegenteil: Die neueren EDOMI-Versionen sind generell ressourcen-schonender.

[SeatSLF]

Ich glaube, ein Celeron 3150 mit 4GB Ram und 32GB SSD, sollte mit dem ganzen nicht ausgelastet sein.

Die Load ist sehr selten hoch, z.b. beim Backup oder wenn ich schnell durch die Diagramm-Seiten Switche.

Edit: selbst ohne die Community Bausteine tritt das selbe Problem auf

Es scheint als ob sich irgend ein Speicher vollschreibt und sich dann nicht mehr vernünftig leert,
Was mich verwundert, das in der Systemanzeige ständig und im ca 3 sek. Takt unter "LBS TRIG" eine 5 auftaucht,
wo kann ich schauen was da passiert?

In den System Logs finde ich nirgends Fehler und die Community Bausteine sind aus.

In den Logiken finde ich nichts, das einzige was immer läuft ist der "Serien" Watchdog

[NorbertB]

Kann es sein, dass die neueren Versionen etwas Ressourcen-hungriger sind?
Möglicherweise sollten die Hardware-Mindestvorraussetzung höher geschraubt werden?

[SeatSLF]

nein, wettervorhersage, betriebsstundenzähler und cpu statistik im wesentlichen