iButtons verzögert?

[Werner V]

Hi Diego,

danke für deine Antwort

Sowas in der Art dachte ich mir auch schon bzw. war mir auch bewusst. Desto mehr das WG mit anderen Dingen zu tun hat wie Plugins, Fühler etc. desto länger kann es mal dauern. Ich dachte nur eventuell gibt es inzwischen irgend ein Update oder sonstiges womit es eine Art Prioritätenliste gibt und wollte daher mal nachfragen.

lg Werner

[Fry]

Zwei mögliche Ursachen fallen mir ein:

1. Soweit ich Makki und Stefan verstanden habe, werden zwischen Temperaturabfragen (die Zeit kosten, weil mehrere Werte gemessen und dann gemittelt wird) immer ALLE iButtons abgefragt.

--> Es kann daher enorm helfen, wenn du die Genauigkeit der Temperaturmessung in der Sensorkonfiguration herunterdrehst.

2. Außerdem blockieren Plugins die Ausführung des wiregated-Daemons. Plugins brauchen hingegen viel Zeit, wenn (ebenfalls blockierende) knx_read-Requests ausgeführt werden, die nicht aus dem eibd-Cache bedient werden.

--> es kann ebenfalls helfen, bei knx_read-Requests in Plugins grundsätzlich sehr großzügig mit dem Cache-Wert umzugehen. Ich setze den schon mal auf 1000 oder mehr, wenn die Aktualität der Daten nicht überkritisch ist bzw. der jeweilige Busteilnehmer sowieso auf "Senden bei Änderung" eingestellt ist - dann sollte nämlich der aktuelle Wert immer im Cache zu finden sein.

VG,
Fry

PS. Diego - das freut mich aber zu lesen, dass der Logikprozessor bei dir so produktiv ist. Hoffe, es läuft immer alles rund, und wünsche noch viel Freude an KNX.

[Fechter65]

PS. Diego - das freut mich aber zu lesen, dass der Logikprozessor bei dir so produktiv ist. Hoffe, es läuft immer alles rund, und wünsche noch viel Freude an KNX.

Ich bin Dir, wie bereits anderenorts geschrieben, sehr dankbar für dieses Plugin. Im Moment bin ich daran, meine eigenen Plugins abzubauen und durch entsprechende Einträge in Deinem Logikprozessor zu ersetzen. Für mich ist es wesentlich übersichtlicher, alles in einer Datei zu haben, namentlich auch mit Blick auf die Dokumentation für einen Dritten.

Die daraus resultierenden Erkenntnisse werde ich - das habe ich mir fest vorgenommen - gelegentlich in einem entsprechenden Posting publizieren. Wahrscheinlich sollte - sofern Du einverstanden bist - dies ausserhalb des Threads unter Code-Schnipsel erfolgen. Allerdings habe ich im Moment noch Probleme mit Logik-Prozessen mit drei Eingängen, diese arbeiten nicht immer so, wie ich mir dies vorstelle und von meinen eigenen Plugins gewohnt bin.

Nochmals besten Dank und ebensolche Grüsse
Diego

[makki]

Ich versuche es abzukürzen: wenn man darauf angewiesen ist, das iButtons möglichst schnell erkannt werden (wir liegen im Optimalfall bei 8,5- 150ms!) aber man "nebenbei noch 50 Temperatursensoren" hat:
Dann ist exakt das was Diego getan hat die Lösung: ein zweites WG, sep. BM, fertig. Ich kann nicht zaubern und immer nur eins von beidem optimieren..

Makki

[Werner V]

Hi makki,

50 würde ich ja verstehen aber ich hab insgesamt 3 Busmaster am WG hängen, einen mit dem Touch only für die Türöffnung, einen mit vorerst 2 Touch and Hold und einen mit 4 Temperatur Sensoren mit 10 Bit Auflösung. Sensoren, I/O´s noch mehr Touch and Hold werden noch hinzugefügt, aber wenn es jetzt schon paar Sekunden dauert, wirds dann wohl noch länger.

Deswegen auch meine Frage woran das noch liegen könnte bzw. ob hier was geändert wurde, nicht falsch verstehen

lg werner

[makki]

Lass mich mal draufgucken bitte, wg# per email oder PN, ich hab da grad nochmal drastisch was gedreht..

Makki

[Werner V]

Hi,

bin jetzt leider in der Arbeit, PN kommt heute Abend - Danke!

lg Werner

[Fry]

Die daraus resultierenden Erkenntnisse werde ich - das habe ich mir fest vorgenommen - gelegentlich in einem entsprechenden Posting publizieren. Wahrscheinlich sollte - sofern Du einverstanden bist - dies ausserhalb des Threads unter Code-Schnipsel erfolgen. Allerdings habe ich im Moment noch Probleme mit Logik-Prozessen mit drei Eingängen, diese arbeiten nicht immer so, wie ich mir dies vorstelle und von meinen eigenen Plugins gewohnt bin.

Klar bin ich einverstanden.

Zu drei und mehr Eingängen: wenn ich mal unterstelle, dass der Logikprozessor in der Beziehung fehlerfrei arbeitet und auch die Logikdefinition fehlerfrei ist, so bewirken solche Logiken ja immer einen Aufruf der knx_read. Und dann gilt wieder: dafür sorgen, dass die Infos aus dem eibd-Cache kommen! (d.h. den Wert regelmäßig senden lassen und den Cache-Wert hoch genug setzen, dass der letzte zyklische Wert genommen wird).

VG, Fry

PS @Makki: es wäre hilfreich, wenn man im normalen knx_write auch ein Lesetelegramm absetzen könnte, ohne auf die Antwort zu warten. Anwendungsbeispiel: ein KNX-Gerät, das kein zyklisches Schreiben anbietet, wo man aber regelmäßig einen neuen Wert in den eibd-Cache holen will und sonst nichts.