Darf's ein bisschen schneller sein?

[StefanW]

Guten Morgen,

@StefanW: bitte überlegt doch mal, ob ihr diese Änderungen nicht in den Hauptentwicklungszweig des wiregated.pl übernehmt.

Ich habe das just gestern mit den Entwicklern besprochen, dass diese drei Änderungen sowie auch der Logikprozessor übernommen werden sollen.

Ich danke Dir für Deine hervorragende Arbeit, die Anwender werden ein beschleunigtes WireGate sicher zu schätzen wissen.

Allerdings müssen wir zuvor auch noch ein paar Bug-Fixes bzw. erweiterte Möglichkeiten um den Umgebungslichtsensor herausbringen, so dass ich noch nicht sicher sagen kann, ob wir Deine Vorschläge mit dem nächsten oder dem übernächsten PL herausbringen.

Ich denke, wir kommen evt. mit der ein oder anderen Frage noch auf Dich zu.

lg

Stefan

[Fry]

Lieber Stefan,
gerne.

Falls ihr das wünscht, sehe ich gerne über den Code drüber. Es gab ja auch hier und da anderes Verbesserungspotenzial, und ein paar kleinere Featureerweiterungen (zB die Möglichkeit, Lesetelegramme abzusetzen ohne auf die Antwort zu warten). Ganz abgesehen davon ist der Code des wiregated.pl ja mit der Zeit gewachsen und streckenweise auch ein wenig unleserlich.

Insgesamt bin ich vom Wiregate nach wie vor begeistert. Ich betreibe aktuell nicht nur ca. 50 Temperatursensoren, sondern auch >600 Logiken, >100 Szenen, die CometVisu, einen Heizungsregler mit Ebus-Anbindung, eine einfache Alarmanlage (non-VDS), ein elektronisches Schluesselbrett mit Audio-Ansagen ("Fenster offen im Schlafzimmer", "neue Post", "bitte Papiermüll rausstellen"), eine Russound C5 und eine Alphatech-Türstation mit täglich wechselnden Zutrittscodes über das Wiregate, das damit ein Herzstück der Hausanlage geworden ist. Demnächst probiere ich dann noch die Anwesenheitssimulation aus. Alle Fäden laufen beim Wiregate zusammen, und dieses ist auch noch nie ausgefallen (ich rechne auch nicht wirklich damit, denn es sind keine beweglichen Teile darin). Dennoch: sollte es mal ausfallen, ist die Grundfunktionalität der Haustechnik (außer der Heizung, die hängt von den 1-wire-Tempsensoren ab) immer noch gegeben.

Unterm Strich hat das Wiregate meine Möglichkeiten rund um das Smart Home deutlich erweitert. KNX und 1wire machen erst mit dem Wiregate so richtig Spaß. (zumal ich bekanntermaßen nicht so sehr der ETS-Freund bin)

Viele Grüße,
Fry

[XueSheng]

Ich habe das just gestern mit den Entwicklern besprochen, dass diese drei Änderungen sowie auch der Logikprozessor übernommen werden sollen.

Kannst Du in diesem Zusammenhang auch noch den plugin_subscribe patch von JuMi aufnehmen? https://knx-user-forum.de/forum/supp...wiregate/27297

Auch dies bringt wesentliche Vorteile, um zum einen die Häufigkeit von Plugin Starts zu reduzieren, zum anderen den Code der einzelnen Plugins einfach zu halten (unnötiges Abfangen von nicht gewolltem Plugin Aufruf).

[StefanW]

Hallo Michael,

Kannst Du in diesem Zusammenhang auch noch den plugin_subscribe patch von JuMi aufnehmen? https://knx-user-forum.de/forum/supp...wiregate/27297

jep, kommt auf die Liste (wenn er nicht eh schon drauf ist).

Danke für den Hinweis!

lg

Stefan

[JuMi2006]

Dann machen die Zeilen im Code ja auch nichts mehr aus:
https://knx-user-forum.de/forum/supp...wiregate/25541

Funktioniert so seit Januar ... von ARM bis x86.

[jensgulow]

@ StefanW: Wie ist denn hier der Stand der Dinge mit den angesprochenen patches für den wiregated.pl ? Habt ihr vor das in die Hauptentwicklunglinie einzupflegen?

Grüße

[XueSheng]

Ich habe seit einiger Zeit Probleme mit Restarts des wiregated.pl. Meine Vermutung war zunächst, dass die Auslastung des wiregate zu hoch wäre. Alleine das Polling der IOs frisst ja schon einiges an CPU Zeit (load häufig im Grenzbereich zu 2.x). Da ich die IOs nicht brauche, habe ich das Polling einfach deaktiviert und nun i.d.R. einen load < 1.x, Ausnahmen bestätigen die Regel).

Mit mem restarts hatte ich eigentlich nie viele Probleme. Spätestens seit Umstellung auf COMPILE_PLUGIN geht der Speicherverbrauch des wiregated.pl auch nicht mehr über 20MB hinaus.

Meine Vermutung ist nun, dass die Umstellung der Telegrammverarbeitung von "if" auf "while" (wie hier im Thread beschrieben) die Ursache sein könnte.

Der Restart des wiregated.pl geht immer mit folgendem Fehler einher (syslog):

monit[28070]: 'wiregated.alive' timestamp test failed for /tmp/wiregated.alive

Um meine Vermutung zu untermauern, habe ich in wiregated.pl Loggingeinträge für den Aufruf der Schleife "while ($select->can_read(.1))" und das nach der Schleife folgende "touch /tmp/wiregated.alive" eingebaut.

Nun konnte ich beim letzten wiregated.pl restart sehen, dass die While Schleife tatsächlich über zwei Minuten nicht verlassen wurde und daher monit zugeschlagen hatte.

Ist es denn tatsächlich so, dass die While Schleife bei ständig neu anfallenden Telegrammen nicht verlassen wird?
Meine Dali Beleuchtung in Kombination mit der Helligkeitsregelung sorgt für eine Rege Kommunikation der entsprechenden Status Objekte und ist vermutlich die Hauptursache für ständig anfallende Telegramme (worauf ich aber nicht verzichten will ).

Hat jemand schon ähnliche Erfahrungen gemacht? Wäre es nicht sinnvoll, die Abarbeitung der Telegramme auch bei Einsatz einer Schleife zu limitieren?

[JuMi2006]

Ich würde eher monit austricksen und ein 60s Plugin mit Touch machen. Die Load ist trotzdem grauselig.

[XueSheng]

Grundsätzlich hast Du natürlich recht, dass man monit austricksen kann. Aber die "Übergeordnete Schleife" des wiregated.pl wird doch durch das lange Ausführen der Telegrammschleife auch beeinflusst... Unter Umständen könnten doch auch weitere Nebeneffekte auftreten!?

Wie im ersten Thread dargestellt:

* Prüfung, ob ein KNX-Telegramm anliegt (warte auf Timeout), falls ja, wird EIN Telegramm abgearbeitet. Das bedeutet Logging in /var/log/eib.log, evtl. Kommunikation über 1-wire, Management-VPN aus/an, Zeit/Datumsanfrage beantworten, und passendes Plugin ausführen. Es wird aber nur EIN Telegramm so abgearbeitet, dann geht es wie folgt weiter.

* Prüfung, ob irgendein Plugin nach seinem cycle gerade fällig ist

* update_rrd einiger Systemparameter

* Prüfung, ob Daten an einem Socket anliegen (warte auf Timeout)

* falls fällig, Zeit/Datum versenden

* Dann wieder zurück nach oben (Endlosschleife)

Der Kommentar zum load war mehr ein Seitenhieb Richtung Wiregate, richtig? Ich wüsste jetzt nicht, wie ich den weiter senken könnte. Bin ja froh, dass er überhaupt mal unter 1.x sinkt .

Kurzer Nachtrag:
Ein 60s Plugin wird doch vermutlich gar nicht ausgeführt, wenn die Telegrammschleife nicht verlassen wird!?

[Fry]

Also bei meinen ca. 110 KNX-Geräten, 2500 GAs und 700 Logiken passiert das nicht.

Zwei Gedanken dazu:
* vielleicht hast du in der KNX-Programmierung, zB in einem Plugin, einer Logik oder auch einem ganz normalen KNX-Gerät, eine "Racing-Condition", d.h. dass das gleiche Telegramm immer wieder gesendet wird. Auch fehlerhafte Linienkoppler oder Kommunikationsfehler können dazu führen, dass ein Telegramm statt einmal gleich fünfmal gesendet wird. Das bitte mal checken.
* Falls o.g. nicht die Ursache ist, dann setze doch in die while-Schleife eine Bedingung, dass maximal X Telegramme (zB X=20) abgearbeitet werden und dann die Schleife verlassen wird, auch wenn weitere Telegramme anstehen. (die ursprüngliche Wiregate-Programmierung war X=1, das war eindeutig zu wenig).

Bitte lass uns wissen, was du rausfindest

VG, Fry

[XueSheng]

Die "Racing-Condition" kann ich ausschließen, da ich gerade dies bei jedem neuen Plugin prüfe. Einen Linienkoppler habe ich nicht im Einsatz. Auch die eib.log ist diesbezüglich unauffällig.

Bei KNX sind doch rund 30 Telegramme pro Sekunde möglich. Alle Busteilnehmer müssen doch hiermit zurecht kommen, auch das Wiregate. Alleine aus diesem Aspekt heraus muss dies doch auch berücksichtigt werden. Nicht zuletzt wollen wir ja auch, dass StefanW den Patch mit in den Standard aufnimmt...

Daher werde ich wohl einen Zähler in die While Schleife einbauen, wie von Fry vorgeschlagen.

[StefanW]

Nicht zuletzt wollen wir ja auch, dass StefanW den Patch mit in den Standard aufnimmt...

Was auch für den nächsten PL auf der Liste steht und derzeit bearbeitet wird vom Entwicklerteam. Ja, ich bin auch der Meinung, dass es lange gedauert hat, aber ich wollte auch, dass es ausreichend und gut vorgetestet ist, was man mittlerweile als solches ansehen kann.

Daher werde ich wohl einen Zähler in die While Schleife einbauen, wie von Fry vorgeschlagen.

Ich hatte auch ein wenig virtuelle Bauchschmerzen mit einer sich nicht selbst beendenden While-Schleife und würde ebenfalls die Bearbeitung von maximal 10 oder 20 Telegrammen pro Durchlauf vorschlagen.

Schreib bitte wie es für Dich gut funktioniert.

Lg und ein gutes neues Jahr 2014

Stefan

[kleinklausi]

Frys Patche im nächsten PL?

Was auch für den nächsten PL auf der Liste steht und derzeit bearbeitet wird vom Entwicklerteam.

Hallo Stefan,
Ein frohes neues Jahr!

Da ich mich die nächste Woche eigentlich mal ransetzen wollte Frys Patche (if/while, "Vorkompilieren" und %plugin_cache) zu testen, klingt Deine Aussage sehr spannend. Kann ich also auf das nächste PL warten, das Du im Zuge vom VOC für Mitte Januar angekündigt hast? Würde mir schon sehr entgegen kommen :-)

Viele Grüße,
Moritz

[StefanW]

Hallo Moritz,

Es steht auf der Liste der Wünsche, tut es allerdings schon länger. Ob die Zeit bei diesem Releaseschritt reicht, diese Wünsche umzusetzen, kann ich nicht fest versprechen. Entwickler kosten Geld und Geld ist eine limitierte Ressource in einem Wirtschaftsunternehmen. Gerade auch noch wenn es um die Verbesserung von Software geht, die sich dann alle kostenlos ziehen. Das rechnet sich wirklich nur sehr bedingt, gerade bei einem so kleinen speziellen Markt.

Lg

Stefan

[kleinklausi]

Hallo Stefan,
Versteh ich und macht Sinn. Dann werde ich mal mein Test um ein paar Wochen verschieben und vielleicht habe ich ja Glück...

Viele Grüße,
Moritz