UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

3.6.1 Grundeinstellungen 1-Wire

Beschreibung: Beschreibung zur Bedeutung der einzelen Parameter im Zusammenhang mit 1-wire

Kategorie: Grundwissen, Grundeinrichtung und Inbetriebnahme, Konfiguration

Link zu diesem Beitrag: Alles auswählen

[url=https://forum.timberwolf.io/app.php/kb/viewarticle?a=8&sid=96d4d8faa09d6fd403f0f78709de5f64]Knowledge Base - 3.6.1 Grundeinstellungen 1-Wire[/url]

Der Benutzer kann nun die genauen Abfrageparameter für jeden Sensor bestimmen. Es gibt keinen globalen Zyklus mehr (wie zB. am Wiregate), sondern jeder einzelne Sensor hat seinen eigenen Takt, seinen eigenen Zyklus.

Achtung: Wenn man zuviele Aufgaben in jede Sekunde packt, dann schafft das der Bus und ggf. der Server allerdings nicht mehr, darum bitte Vorsicht bei den Einstellungen.

Bild

Im Detail bedeuten die Einstellungen:

Interval: Das ist der gewünscht Zyklus, mit dem der Sensor vom 1-wire Bus abgefragt wird (polling interval). Ob es eingehalten werden kann, hängt davon ab, wieviele andere Sensoren auch in diesem Zyklus abgefragt werden sollen (und wie lange das dauert). Ein Temperatursensor mit 12 Bit Auflösung braucht schon eine dreiviertel Sekunde für sich.

Cache: Alle Werte, die vom 1-Wire Bus gelesen werden, werden mit Zeitstempel des Lesens vom Bus zwischengespeichert. Unter Alter kann eingestellt werden, wie alt ein Wert sein darf.
Gibt es z.B. mehrere Regeln, die von einem 1-Wire Sensor die Temperatur lesen, so können mehrere Regel diesen Temperaturwert verwenden, wenn er noch nicht zu alt ist.Gerade weil man viele Regeln untereinander für einen Sensor angeben kann, macht es Sinn, dass diese nicht alle am Bus landen, sondern wenn etwas gerade schon abgefragt wurde, es dann aus dem Cache zu nehmen, wenn das für den jeweiligen Zweck ausreichend ist.
So führt dann nur eine Regel zur tatsächlichen Abfrage am Bus und die anderen nehmen dann den Wert aus dem Cache, sofern passend eingestellt. So die Hälfte bis zwei Drittel der Zykluszeit für den Cache ist ein ganz guter Wert. Je größer der Cache, desto weniger Last am Bus.

Change: Der einmal gewonnene Wert wird entsprechend der Regeln weitergesendet. D.h. immer nach jedem Poll oder nur bei Änderung um einen gewissen Betrag.

Das Sendeintervall sollte ein ganzzahliges Vielfache dieses Intervalls sein, da die Regel nur dann durchlaufen wird, wenn ein neuer Wert hereinkommt.

Das heisst:
Ist bei einem IO das Polling Intervall auf 10s gesetzt und das Sendeintervall auf 2s, dann wird der Wert tatsächlich nur alle 10s gesendet. Damit er alle 2s gesendet wird, muss das Polling Intervall auch auf 2s gesetzt werden.

Ob das eingestelle Polling Intervall auch eingehalten werden kann, hängt allerdings von der Anzahl der Regeln und der Länge der einzelnen Intervalle ab.

Im unteren Abschnitt des Menü's werden die Defaultwerte für jeden Sensortyp festgelegt. Damit wird festgelegt, mit welchen Einstellungen für verschiedene Sensoren direkt nach dem Alle Werte, die vom 1-Wire Bus gelesen werden, werden mit Zeitstempel des Lesens vom Bus zwischengespeichert.
Unter Alter kann eingestellt werden, wie alt ein Wert sein darf.
Gibt es z.B. mehrere Regeln, die von einem 1-Wire Sensor die Temperatur lesen, so können mehrere Regel diesen Temperaturwert verwenden, wenn er noch nicht zu alt ist. die Datenaufzeichnung gestartet werden soll.

Bild

Für die Wahl der richtigen Einstellungen stellen sich 2 Fragen:

Welche Zykluszeit ist sinnvoll?
Eine Pauschalantwort für sinnvolle Zyklen ist schwierig, da es von den Anforderungen der Weiterverarbeitung abhängt.
Selbst bei einem Reedkontakt am Fenster: willst man damit sofort den Rolladen auf Lüftungsposition fahren, die Heizung nach x Minuten ausschalten oder einfach nur eine Warnlampe beim Verlassen des Hauses angehen lassen?
So zieht sich das durch ziemlich alle Sensoren. Was machst du mit den Werten (akzeptable Reaktionszeit, nur Aufzeichnung)? Welche Genauigkeit (zB. im Zeitverlauf) wird benötigt?

Wieviele Abfragen schafft der 1-Wire Bus / der PBM / der Server
Es gibt zwei Limitationen:
  • Das hängt vom Sensor ab. Bei Temperatursensoren richtet sich das nach der Auflösung in Bit. Bei 12 Bit braucht der Sensor 750 ms alleine für die Wandlung und drumherum (derzeit) 230 ms, also sind wir hier auf einer Sekunde. Mein Ratschlag: 10 Bit sind ausreichend, das sind dann 187 ms für de Wandlung plus (derzeit) 230 ms für Kommunikation, macht ca. eine halbe Sekunde. Es ist also keine gute Idee, einen Temperatursensor jede Sekunde abzufragen. In der Regel reichen hier Werte im Bereich mehrerer Minuten, weilm sich Temperaturen nicht so schnell ändern.
  • Alle anderen Sensoren / IOs usw. liegen (derzeit) bei ca. 120 ms. Das wird sich aber noch stark verbessern.

    Verbesserungen: Es gibt immer irgendwo einen Flaschenhals. Diesen haben wir derzeit in der Kommunikation zwischen unserem Scheduler (der das Polling vornimmt) und dem OWFS. Hier verlieren wir - pro Buszugriff - gerade 100 ms, was um den Faktor 1000 zuviel ist. Eine Lösung ist ausgedacht, aber noch nicht umgesetzt. D.h. es gibt hier noch Potenzial für einen Turbo, wenn wir den Flaschenhals entfernen.

    Bedeutet: Derzeit liegen die Grenze bei ca. 8 Abrufen pro Sekunde bei IOs (immer zwei IO auf einmal) und nicht Temp-Sensoren und einem oder zwei Temp-Sensoren pro Sekunde. Nach Beseitigung des Bottlenecks soll sich die Rate auf ca. 50 Abrufe pro Sekunde steigern lassen.