ElabNET Technik Forum

Moin,

Vorab: ich habe inzwischen sehr viel zu diesem Thema im Forum gelesen und insbesondere die folgenden Themen sind dabei recht aufschlussreich (das KB im Moment IMO leider noch nicht):

viewtopic.php?f=31&t=145
viewtopic.php?f=31&t=432
viewtopic.php?f=31&t=311
viewtopic.php?f=31&t=703

Die 2 wichtigsten Regeln befolge ich:

• Alter kleiner als Poll-Intervall
• Sende-Intervall gleich oder vielfaches vom Pollintervall

ABER ich bin der Meinung hier ist irgendwo noch der Wurm drin.

Ich möchte einen Estrichtemperaturfühler gerne z.b. im 30 Sekundentakt auslesen (pollen) und dann alle 300s auf den KNX-Bus und in eine TS senden. Bei Wertänderung um >5% auch früher. Das Ganze habe ich auch schon mit intervall(i10/a9) und Senden (fester intervall i10) und vielen anderen "agressieveren Einstellungen ausprobiert. Meine Regel sieht im Moment wie folgt aus:


Aber die Werte werden merkwürdiger Weise immer eher mit 200 und 400 Sekunden gesendet! Ich habe das einmal über die letzten 24h ausgewertet:


Mein Busmasterkanal

ist mit 42 Slaves (ausschließlich 10bit Temp-, Feuchte- und VOC-Fühler) recht voll, aber die Qualität und Historie ist 5 Balken bzw. 100% und die Auslastung soll laut Anzeige lediglich 36% sein und das ist im grünen Bereich. Dies Zweifel ich nach der Lektüre der obigen Themen fast ein wenig an, nachdem ein einzelner 10 bit Wert glaube ich nach wie vor über 0,3s Buszeit (inkl. Kommunikation) in Anspruch nimmt. Alle meine Slaves haben ja mehrere hochbit-Sensoren und Werte.

Meine 1-Wire Geräte werden nach dem Wiregate-Export m.E. alle mit 300Sek. Intervall gepollt, und nur der eine oder zwei Sensoren, an denen ich aktuell teste, polle ich häufiger.

Warum wird der Sensor mit 200 Sekunden oder 400 Sekunden auf den Bus geschrieben?
Mache ich denn wirklich noch was falsch: Sieht jemand einen Fehler in meiner Regel?
Kann es sein, dass mein Bus schon so ausgelastet ist, dass nur noch alle 200Sekunden gepollt werden kann?

VG, Sven

Update: Ich glaube ehrlich gesagt immer mehr an eine Überlastung meines Bus-Kanals. Durch die automatische Übernahme vom Wiregateserver sehen die Regel für meine Multi UP-Multi-Sensoren (davon habe ich immerhin 9 in der Linie + 5 VOC) wie folgt aus:

10 Regeln, einige davon 12bit!


Ich deaktievere jetzt mal fleißig alles, was ich nicht dringend brauche und schau dann mal ob ich die Estrichfühler schneller getaktet bekomme als 200ms.

VG, Sven

Ich habe gestern abend 60 Regeln deaktiviert und den Sendezyklus zum Test runtergeschraubt, nämlich gleichgesetzt mit dem Pollzyklus. (In dem Fall macht das das Senden bei Rel. Unterschied keinen Sinn, ich weiß)



Das Ergebnis macht mich ehrlich gesagt ein wenig ängstlich, denn ich konnte die Zeiten deutlich reduzieren (auf ca. 100 im Schnitt), aber auch das ist immernoch weit weg von dem eingestellten Pollintervall 30 und die Streuung ist enorm. Sie ist zwischen 68 und 144


Merkwürdig sind auch die Ausreisser nach unten (mit Zeiten von 0 und 1, scheint mir ein Doppelsenden auf den KNX-Bus zu sein). Aber das ist mir im moment erstmal egal.

Jetzt werde ich erstmal weiter Regeln deaktivieren bis der Arzt kommt. Es sind ja durch den autoamtischen Import sehr viele Regeln dabei, die ich so überhaupt nicht brauchen kann. Mal sehen wo das hinführt. Aber in jedem Fall ist die Anzeige der Busauslatung auf der Busmasterseite merkwürdig, die steht immer noch auf 36% trotz 60 deaktivierter Regeln.

Ein zwei Feature Request hätte ich nun in der 1-Wire Geräte Übersicht:

• Angabe wie viele Regeln in der aktuellen Auswahl angezeigt werden (oder zumindest eine Möglichkeit die Anzahl der Regeln je Buskanal zu sehen)
• Einen Butten, mit dem man alle angezeigten 1-Wiregeräte auf- und zuklappen kann. Das würde jedem User zugute kommen, der mal die Regeln mehrere Geräte änder will, denn dass ist ein ganz schönes geklicke auf die PLUS zeichen.

Stelle ich als FR in einem neuen Threat ein.

VG, Sven

Hinzugefügt nach 20 Minuten 43 Sekunden:

Robosoc hat geschrieben: ↑So Mai 26, 2019 8:08 am Einen Butten, mit dem man alle angezeigten 1-Wiregeräte auf- und zuklappen kann. Das würde jedem User zugute kommen, der mal die Regeln mehrere Geräte änder will, denn dass ist ein ganz schönes geklicke auf die PLUS zeichen.

Habe die Funktion gefunden
Man klicke auf den kleinen Diagonalen Vergrößerungspfeil ganz links oben in der Überschriftenzeile der Tabelle!

Ich habe weitere Versuche gemacht und scheitere weiterhin an einer Erklärung:

Ich habe inzwischen über 70 Regeln deaktiviert, gelöscht oder durch Zusammenfassen (Schreiben in TS und KNX-Bus aus einer Regel) reduziert.Auch habe ich zwischendurch mal versucht eine Reihe von Sensoren im Bus abzuklemmen.

Alles bringt gefühlt mal ein wenig und mal nix und wie man unten sieht mal Verschlechterung auf anderen Bus-Kanälen(!). Unterm Strich komme ich nicht entscheidend voran, außer, dass ich mich inzwischen besser in Grafana und der TWS-Oberfläche auskenne, dass ist ja auch schon mal was.

Hier jetzt noch einmal ein neuer Ansatz:

Ich habe einen TWS950, also mit inkludiertem PBM, der 3 Kanäle hat:


Ich gehe davon aus, dass alle drei Kanäle grundsätzlich die gleiche Performance haben. Den ersten Kanal habe ich, wie man sehen kann, auf bis 80 Slaves erweitert. Das wird aber vermutlich die reine Busperformance nicht verbessern, sondern nur lizenztechnisch die Möglichkeit einräumen mehr Slaves anzuschließen.

Mein Kanal 2 ist der, den ich am wenigsten nutze. Hier sind nur 10/40 Slaves angeschlossen und die verteilen sich auf gerade einmal 6 Geräte, davon 3 reine 1bit IO Geräte! Ich würde behaupten das ist nicht viel.

• 1x Mulitsenor (Aussenluft und Feuchte)
• 2x Hülsentemperatursensoren
• 3x 1-Wire Multi IO / Adv. Multi-IO
• + die Topologie ist hier recht vorschriftsmäßig und sollte keine Probleme bereiten

Zum Vergleich: Mein Kanal 1 hat

• 6x VOC
• 9x Multi-Sensoren (Temp und Feucht)
• 15x Hülsentemperatursensoren
• - die Topologie ist sehr ungünstig mit vergleichsweise langen Stern-Leitungswegen. Hier habe ich schon zu Wiregatezeiten zu kämpfen gehabt und habe deshalb inzwischen nicht mehr alle Sensoren verbaut, die ich gekauft und geplant hatte. Ich warte hier auf die Can-Bus- Erweiterungsmöglichkeit. Aber so wie es jetzt angeschlossen ist, hatte ich 2 Jahre keine Busaussetzer mehr.

Da würde ich sagen, dass ist schon recht ordentlich.

Die Auslastung von Kanal 1 habe ich inzwischen auf 32% reduziert bekommen, der Kanal 2 zeigt noch 38% an. Das verstehe ich überhaupt nicht, selbst wenn es in die Vergangenheit schaut. Ich habe bei Kanal 2 zwar im Vergleich nur sehr wenig optimiert. Aber warum sollte die Auslastung dort 38 % sein und der Kanal 3, bei dem mehr als 3x so viele Slaves verbaut sind (und dort vor allem wieder viele Integer-Sensoren wie Multi -> Temp und Feuchte bzw. VOC und kein einziger Multi-IO...Und da soll die gleiche Auslastung sein - nie im Leben.

Und es bleibt dabei, dass ich es auf keinem Buskanal hinbekomme einen Schreibintervall von 30 Sekunden zu schaffen! Bei anderen Threats habe ich schon gesehen, dass Jemand nachweislich (Screenshot) 20 Sekunden realisiert hat und Andere haben geschrieben, dass Sie mit 10 oder gar 2 und 1 Sekunde testen (ob das realisiert wurde und geklappt hat konnte man dann im Thread nicht sehen).

Hier jetzt mal ein erstaunliches Bild. Gezeigt wird ein Temperatursensor aus Buskanal 2 in der Auflösung 10bit (ich nutze in Kanal 1 und 2 ausschließlich 10bit Temperaturwerte, in Kanal 3 könnten noch einige 12bit aktiv sein, die nach dem automatischen Import vom Wiregateserver angelegt wurden).

• [A] Ausgangssituation, Einstellung Poll und Write i300 (a75), ich finde den Verlauf vergleichsweise glatt rund um die 300 (wie erwartet)
  [B) Störungen im Kanal 1 (Trennung von Sensorleitungen) hatten scheinbar auch Auswirkungen auf Kanal 2.
  [C] nach Ende der Störung in Kanal 1, wird der Sensorwert in Kanal 2 nur noch sehr grob alle 400 Sekunden geschrieben. Die Regel wurde nicht geändert. Das fand ich sehr merkwürdig. Deshalb habe ich den TWS neu gestartet.
  [D] Nach einem TWS-Neustart ist die durchschnittliche Schreibzeit wieder bei 300 Sekunden, aber mit deutliche größeren Schwankungen als in Abschnitt A. Es wurden bis zu diesem Zeitraum keine Änderung an Regeleinstellungen in einem 1-Wire Objekt der drei Kanäle gemacht!
  [E] Diverse Änderungen in Regeleinstellungen bei Objekten in Kanal 1 und Kanal 2
  [F] Der in diesem Chart betrachtete Sensorwert hat nun die Einstellung Poll und Write i30 (a10). Es wird aber wieder nur i100 realisiert und das nach meinem Gefühl auch mit einer viel zu großen Varianz, also deutlich nicht so glatt wie in Abschnitt A.

Kann mir jemand helfen?

Vielleicht könnte ja jemand mal bei sich in Grafana eine Auswertung für Sensoren anstoßen, die manuell in der Regel geändert wurden. Hier noch ein Screenshot wie das geht:


Oder als skript:

SELECT elapsed("Val", 1s) FROM "TS00170" WHERE $timeFilter

Lieben Dank und sorry für den langen Text, aber ich hoffe damit einfach deutlicher zu machen, dass ich nicht ganz bei A mit meinem Hilferuf anfange.

VG,
Sven

Bin inzwischen ein Stück weiter und sehe inzwischen auch Zeiten unter 100s.

[hsimg]ext/dmzx/imageupload/files/994283c6799f ... d97f07.jpg[/hsimg]

Mein Busmaster sieht nun wie folgt aus:


Der Durchbruch kam mit der radikalen Bearbeitung der über 300 1wire Regeln, die nach dem Import aus dem Wiregate existiert haben. Ich konnte daraus 159 machen ohne auf irgendeinen Wert zu verzichten - hauptsächlich durch zusammenlegen von Schreibregeln in TS und KNX.

Aber zufriedenstellend ist das Ergebnis für mich noch immer nicht.
Ich habe jetzt bei ~ 20 Temperatursensoren ein Poll-Intervall von 30s eingestellt (wenn der Estrich oder Vor- und Rücklaufleitungen von einer eingeschalteten Geothermie Wärme sehen, würde ich dies gerne genauer sehen. In 5 Minuten passiert da schon recht viel. Geschrieben wird dann jeweils in i300 c abs 0.2. Bei diesen 20 Sensoren komme ich wie die Grafana Grafiken oben zeigen auf Aktualisierungszeiten zwischen 20 und 100 Sekunden (20 ist kleiner 30! ??? und ~100 ist etwa 3x 30).

Mein Busmaster zeigt alles in grün an. Die Auslastung scheint nicht kritisch. Dann würde ich erwarten, dass der Busmaster auch die vorgegebenen Poll-Raten schafft. Aber es hat für mich den Anschein, dass er es nicht schafft.

@@StefanW : Könnt Ihr Euch das vielleicht auch einmal mit anschauen?

VG, Sven

Hallo Sven

vielen Dank für deine umfangreichen und genauen Untersuchungen.

Ich habe mich heute auf deinen Timberwolf eingeloggt:
Für einen Temperatursensor, der mit 30s abgefragt wird, werden die Werte zwischen 20s und 100s Sekunden an die 1-Wire Regeln "geschickt".
Kleinere Schwankungen des tatsächlichen Zyklus sind normal, da die polling Zeiten nie exakt eingehalten werden und auch die Dauer der Abfrage von der System- und Buslast abhängt.
Da der nächste Zeitpunkt zur Abfrage eines Sensors nie in die Vergangenheit gelegt wird, müssen (bei Verspätungen > 30s) nicht unbedingt 30s verstreichen.

Die großen Schwankungen kann ich momentan nicht erklären, daher habe ich kurzzeitig ein Logging auf deinem Timberwolf aktiviert.
Die Untersuchung des Logfiles kann aber dauern.
Ich melde mich dann nächste Woche wieder.

Viele Grüße
Gabi

Hallo Sven

Aus deinen letzten Kurven, die die tatsächliche Zykluslänge abhängig von der Zeit zeigen, geht hervor, dass die Zykluslänge über einen Zeitraum von ca. 5 Minuten ansteigt und anschließend wieder steil abfällt.
In den logs sehe ich, dass zwischen zwei Abfragen einer Temperatur, die mit 30s gepollt wird, die Anzahl der Aufträge für andere Werte ebenfalls ansteigt und dann wieder abfällt.

132 Werte werden alle 5 Minuten gepollt. Die nächsten geplanten Startpunkte dieser Abfragen lagen zu einem bestimmten Zeitpunkt in einem Zeitraum von ca. 170 Sekunden.
Der Anstieg der Zykluszeiten für die 18 'temperature10' Werte, die mit 30s gepollt werden, hängt daher vermutlich mit der wachsenden Anzahl der fälligen 5 Minuten Werte zusammen.

Momentan werden die Aufträge zum Pollen der Werte mit einem festen offset in eine "Auftragsschlange" eingefügt. Ich werde diesen offset jetzt "konfigurierbar" machen, fest oder abhängig von der Zykluszeit. Damit würden dann die 5 Minuten Werte über einen größeren Zeitraum verteilt, sodass Werte mit kleineren Zykluszeiten mehr "Lücken" finden.
Der Nachteil ist, dass die ersten Werte nach Neustart des Timberwolf Service später zur Verfügung stehen.

Viele Grüße
Gabi

Hallo Gabi,

ganz herzlichen Dank für die Recherchen und und die Erklärung. Genau sowas in der Art war genau auch meine Vermutung, weshalb ich ja versucht habe die Anzahl der Regeln soweit zu reduzieren wie nur irgendwie möglich.

Aber aus meiner Sicht, ist das Ergebnis auch ein Hinweis darüber, dass die Auslastungsanzeige im Busmaster Menü zumindest noch einmal überdacht oder mit einem Helfertext versehen werden müsste. Aus meiner Sicht muss die Auslastung rot sein, wenn wie am Anfang meines Threads kein einziger PollVersuch für einen bestimmten Sensor innerhalb der gewünschten Zeit (+vielleicht 10% Kulanz oder so) erfolgen kann.

Die Auslastung wäre dann auch gleich ein Hinweis für einen Nutzer, dass er über die von dir in den neu erstellten Option nutzen sollte oder kann. Insgesamt war es für mich auch sehr überrascht, dass die drei Busmasterkanäle sich so stark beeinflussen. Ein 10s Poll läuft bei mir an den zwei eher gering genutzten Kanälen mit exakt den Gleichen Auffälligkeiten wie ein 10 Sekunden Poll auf dem sehr ausgelassen Kanal. Es scheint ja fast so zu sein dass es nur einen Scheduler für alle drei Kanäle gibt. Damit ist die Auslastung eines jeden Kanals von der Auslastung der anderen Kanäle vollständig abhängig, oder?

Eventuell macht dann eher oder zusätzlich eine Anzeige Schedulerauslastung oder so Sinn, den es dann einmal für den gesamten Busmaster gibt. Und der wäre dann der Hinweis für den Nutzer sich intensiv mit seinen Regeln und deiner neuen Option zu beschäftigen.

Ich hatte bis zu diesem Thread keine Ahnung wie 1wire läuft (Sensoren senden werde nur auf Anfrage vom Master) und das wird vielen Nutzern vermutlich auch nicht klar sein. Deshalb denkt ein Nutzer, wie ich, naiv dass der Bus ja nicht ausgelastet sein kann, wenn die maximale Anzahl von erlaubten oder möglichen Slaves nicht annähernd erreicht ist.

Sorry, hatte die Antwort vorhin unterwegs diktiert und nicht nochmal Korrektur gelesen. Jetzt kann ich sie nicht mehr editieren. Tut mir Leid für die vielen Wort und Satzbaufehler. Aber ich denke es ist alles noch gerade so verständlich.

Hallo Sven

Vielen Dank für deine Bemerkungen.
Deinen Vorschlag einer "Schedulerauslastung" werde ich weiterleiten. Nicht nur die Anzahl der angeschlossenen slaves ist wichtig für die Gesamtauslastung, sondern auch die Anzahl der Regeln und deren Polling-Zyklus.

Viele Grüße
Gabi