ElabNET Technik Forum

Naja alle drei Logiken fußen auf dem Status des Schlüsselbrettes, das wird ja irgendwie mit dem i-Button zusammen hängen. wahrscheinlich bekommt die Logiken auch die Unmengen gesendeter i-Button Signale ab und rechnet permanent was neues aus und schreibt auf die übrigen GA aus den Logiken.

Irgendetwas stimmt also mit dem i-button nicht und der TWS wiederum schüttet die Logiken zu, die dann den Bus und das wiregate auf Vollauslastung treibt.

Die Änderung auf nur bei Änderung senden sollte das Problem lösen.
Deine einstellung war ja 1x je sec je ibutton x3 x4 (von der logic) =12/sec

Robert

verstehe aber nicht warum der Timberwolf immer noch so häufig auf die 5/2/11 und 5/2/12 senden, obwohl es keine Änderungen gibt. Zwei Dinge sind mir noch aufgefallen:
- Was bedeutet das ES=2 in der Spalte "Flags" (zweite Spalte) im Busmonitor? Sind das vielleicht keine Schreib- sondern Lesetelegramme von Timberwolf weil der Cache in der Regel vom I-Button auf 0,25 steht. Kenne aber die Bedeutungen der einzelnen Einträge noch nicht. Vielleicht sehe ich das auch falsch.





Hinzugefügt nach 13 Minuten 56 Sekunden:
mist, mein Fehler. Ich hatte "nur bei Änderung" bei den I-Buttons eingestellt, wusste aber nicht, dass man auf speichern klicken muss.
Peinlich, sorry...

Beobachte es mal noch, dann nehmen wir das Problemattribut weg.

Nur zur Ergänzuung:
GroupValueWrite => Schreiben
GroupValueRead => Lesen

Robert

Izeman hat geschrieben: ↑Do Jan 24, 2019 10:33 pmmist, mein Fehler. Ich hatte "nur bei Änderung" bei den I-Buttons eingestellt, wusste aber nicht, dass man auf speichern klicken muss.

Wir werden sehen, dass wir den Speichern-Butten besser hervorheben während einer Änderung und solange noch nicht gespeichert wurde

Stefan

Hinzugefügt nach 6 Minuten 17 Sekunden:

Robert_Mini hat geschrieben: ↑Do Jan 24, 2019 9:58 pmDie Änderung auf nur bei Änderung senden sollte das Problem lösen.

Richtig, das war der zentrale Tipp. "Senden bei Wertänderung" einstellen (und von mir aus alle 10 Minuten den Status).

Weil wenn man bei einem 1-Wire Device mit kurzem Intervall einstellt, dann jeweils ein Telegramm auszulösen, dann kann man schon den halben Bus fluten.

==> Wir überlegen für solche Fälle (also Intervall utner 10 Sekunden und Sendetrigger "alles") einen Warnhinweis einzublenden.

Bitte darauf achten: Den Wolf kann man schon auch "falsch" einstellen. Wir glauben an die Intelligenz unserer Kunden und erlauben daher eine recht breite Einstellungsmöglichkeit, man sollte sich also bewusst sein was man tut.


lg

Stefan

StefanW hat geschrieben: ↑Fr Jan 25, 2019 11:56 am Wir werden sehen, dass wir den Speichern-Butten besser hervorheben während einer Änderung und solange noch nicht gespeichert wurde

Stefan

Hallo Stafan,
es ist wie mit vielen Sachen, ich musste halt erstmal mit dem "Material" warm werden. Ihr solltet euch nicht verpflichtet fühlen daswegen etwas zu unternehmen. Auf der anderen Seite wäre es, wenn nich zu aufwändig, eine schöne Sache, wenn noch einmal so ein Hinweis kommen würde. Das hat es ja auch beim Wiregate schon gegeben (gelbe Zeile am oberen Rand des Bildschirms "es gibt nichtgespeicherte Änderungen"). Vielleicht kann man die Zeile die noch nicht gespeichert ist im Timberwolf gelb hinterlegen.

StefanW hat geschrieben: ↑Fr Jan 25, 2019 11:56 am Richtig, das war der zentrale Tipp. "Senden bei Wertänderung" einstellen (und von mir aus alle 10 Minuten den Status).

Weil wenn man bei einem 1-Wire Device mit kurzem Intervall einstellt, dann jeweils ein Telegramm auszulösen, dann kann man schon den halben Bus fluten.

==> Wir überlegen für solche Fälle (also Intervall utner 10 Sekunden und Sendetrigger "alles") einen Warnhinweis einzublenden.

Irgendwie hatte ich glaube auch schon bemerkt, dass auf "alles senden" stand. Ich konnte mir allerdings nicht erklären, warum so viel gesendet wird, ohnedass es Änderungen gibt. Somit habe ich mir eingebildet, dass ich mit "nur bei Änderung senden" die Wirkung bekämpfe, aber die Ursache nicht herausfinde. Un das das ja alles original vom Wiregate eingelesen war, wollte ich nicht eifach mal dran rumfummeln und dadurch was kaputtmachen. Sowas bleibt dann wielleicht Jahre so und fällt nicht auf.

gbglace hat geschrieben: ↑Do Jan 24, 2019 8:48 pm Es gibt da einen schnellen Link für GA Statistik, da generiert der TWs ein Grafana chart aus dem man schnell sehen kann welche GA überproportional aktiv sind.

Der Tipp von Göran war wirklich klasse. Ich habe aufgrund der GA-Statistich auch noch mehrere andere GA's auf ihre Sendehäufigkeit überprüft und die KNX-Geräte mit sinnvolleren Sendeintervallen programmiert.
Mittlerweile ist das jetzt schon richtig geil (sorry, hoffe das wird durch die Zensur nicht gestrichen). Ich habe gestern noch drei neue Multisensoren in Betrieb genommen. Alle wurden direkt erkannt, die Sensoren gruppiert und Regeln angelegt, der Hitt!!! Ich bin sehr strukturiert, und durch den Timberwolf das alles nun mal aufzuräumen und auf ne solide Basis zu stellen ist echt cool (schon wieder Gefahr der Zensur). Das es da in der letzten Woche die ein oder andere Nacht etwas später geworden ist, ist dabei nicht schlimm. Hauptsache es kommt in vertretbarer Zeit auch mal nen Erfolgserlebnis, und das hat es ja nun gegeben.

Ich danke euch sehr, dass wir das gemeinsam erarbeitet haben!

Eine Sache kann ich vielleicht noch weitergeben. Ich wollte ursprünglich das Wiregate für DMX und die Ligiken vollig unverändert weiterlaufen lassen. Das hat sich allerdings nicht als gut herausgestellt. Mann sollte die Sensoren, die nun nicht mehr am Wiregate hängen, löschen, da es sonst auch noch irgendwelche Reedrequests vom Wiregate gibt, die der Timberwolf dann 1x (plus 3 Wiederholungen) versucht zu beantworten.

Ganz liebe Grüße
Bernd