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

1-Wire Polling, wann wird optimiert?

Grundsätzliche Diskussionen zur 1-Wire Topologie, zur Rolle der Busmaster und des Servers.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
Marinux
Reactions:
Beiträge: 125
Registriert: Fr Apr 12, 2019 3:04 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 51 Mal

1-Wire Polling, wann wird optimiert?

#1

Beitrag von Marinux »

Hallo Elabnet,

die Limitierung des 1-Wire pollings, zumindest bei den Hutschienenmodellen, ist ein seit Jahren diskutiertes Thema. Ich frage darüber die Reedkontakte und Glasbruchmelder meiner ca. 30 Fenster im Sekundentakt ab. Die Verzögerung der Meldung bis zu 5 Sekunden ist inakzeptabel und ich überlege ernsthaft auf die Technologie KNX zu wechseln.

Mehrfach wurde bereits in Aussicht gestellt dies zu beheben, allerdings bisher ohne Ergebnis. Das ist sehr lästig, vor allem weil 1-Wire ein Key-Feature in der Vermarktung der TWS spielt. Wenn ich nun die Technologie wechseln muss, dann kommt zusätzlich zu meinem in 2018 bereits getätigten Invest in 1-Wire Komponenten, ein erheblicher Neu-Invest auf mich zu. Das kann doch nicht im Sinne des Erfinders sein?!


Zitiert aus einem Post von vor drei Jahren in 2018
StefanW hat geschrieben: Fr Aug 31, 2018 11:36 amVerbesserungen: 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.
Gruß Markus

TWS 960Q #360, VPN geschlossen, Reboot verboten

Ide71
Reactions:
Beiträge: 40
Registriert: Mo Jan 07, 2019 5:32 pm
Hat sich bedankt: 75 Mal
Danksagung erhalten: 14 Mal

#2

Beitrag von Ide71 »

Danke, Du sprichst mir aus der Seele. Ich warte auch sehnsüchtig darauf, dass diese Schwachstelle endlich beseitigt wird...
TWS 950 ID:467, VPN aktiv, Reboot nur nach Rücksprache

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#3

Beitrag von StefanW »

Hallo Markus,
Marinux hat geschrieben: Di Jul 06, 2021 12:17 pmdie Limitierung des 1-Wire pollings, zumindest bei den Hutschienenmodellen,
Es gibt keine Limitierung bei Hutschienenmodellen. Es gibt da keine Unterschiede zu den Desktop-Modellen.

Marinux hat geschrieben: Di Jul 06, 2021 12:17 pmMehrfach wurde bereits in Aussicht gestellt dies zu beheben, allerdings bisher ohne Ergebnis.
Wir haben bereits Details verbessert und Abläufe optimiert.

Aber, vor etwas über einem halben Jahr gab es eine große Diskussion mit unseren Nutzern und das Ergebnis war, dass wir die Bereitstellung neuer Funktionen gegenüber dem Ausfeilen an Details bestehender Funktionen priorisieren sollen.

Das Ergebnis war, dass wir nach Modbus RTU und Modbus TCP nun auch MQTT bereitgestellt haben, nächste Woche ein weiteres (ziemlich starkes) Leistungsmerkmal in der Konnektivität hinzukommt und in weiteren vier bis sechs Wochen nochmal eines.

Wir haben uns mithin nach der Abstimmung der Nutzer gerichtet und die Konnektivität mit fünf neuen Protokollen in kurzer Zeit stark ausgebaut.

Wie in der eben laufenden Abstimmung zu sehen, werden viele Logikfunktionen gewünscht. Müssen wir sehen, wie wir die Verbesserungen am 1-Wire Polling in Verbindung mit all den anderen Wünschen umsetzen.


Das Thema ist uns wichtig und es gibt zwei identifizierte Verbesserungspotentiale, deren Erschließung aber leider aufwändig ist und vieler Tests bedarf. Letztlich haben wir mit Modbus eine neue Polling-Engine geschaffen und können Erkenntisse daraus auch für 1-Wire daraus ableiten.


lg


Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ide71
Reactions:
Beiträge: 40
Registriert: Mo Jan 07, 2019 5:32 pm
Hat sich bedankt: 75 Mal
Danksagung erhalten: 14 Mal

#4

Beitrag von Ide71 »

Hallo Stefan,
vermutlich hängt es von der Sichtweise ab, ob man das als "Ausfeilen" versteht. Für mich ist es ein Bug, und das Lösen von Bugs sollte vor allen neuen Features kommen.
Gruß
Markus
TWS 950 ID:467, VPN aktiv, Reboot nur nach Rücksprache

Smart Jeanie
Reactions:
Beiträge: 64
Registriert: Mo Sep 10, 2018 3:10 pm
Hat sich bedankt: 92 Mal
Danksagung erhalten: 68 Mal

#5

Beitrag von Smart Jeanie »

Den Ton hier verstehe ich nicht. Der 1-Wire-Bus ist eher eine Nische. Die muss man schon bewusst gesucht haben. Wenn man sie aber gesucht oder gefunden hat, dann sollte man sich mit den Eigenheiten und Charakter auseinandergesetzt haben. Nach allem, was überall zu lesen ist, ist 1-Wire nicht der Bus, mit dem man seine Reed-Kontakte abfragen sollte - wenngleich das trotzdem möglich ist. Hier wäre KNX die bessere Entscheidung gewesen - und das ist im wesentlichen auch die mehrheitliche Empfehlung. Wenn man das trotzdem anders macht, dann muss man sich mit den derzeit gegebenen Auswirkungen auch abfinden.
Jetzt Stefan dafür so anzugehen, finde ich schon ein wenig schräg.
Zuletzt geändert von Smart Jeanie am Mi Jul 07, 2021 12:57 pm, insgesamt 1-mal geändert.
Markus

TWS 950Q #268, Software-Stand V3.5x, nicht in Verwendung

FabKNX
Reactions:
Beiträge: 478
Registriert: Mi Aug 15, 2018 7:50 pm
Wohnort: LK Heilbronn
Hat sich bedankt: 684 Mal
Danksagung erhalten: 247 Mal

#6

Beitrag von FabKNX »

Naja, angehen ist das ja nicht.

Ich kenne die Diskussion als Wiregateumsteiger auch seit Anfang an.
Im Wiregate server war die 1-wire Abfrage halt auch für Reedkontakte schneller. Deshalb haben es viele bemängelt.
Ich hab es auch so abgespeichert, dass ihr an dem Thema arbeitet. 1-wire ist ja für eure SensorikProdukte essentiell wichtig und damit für euren finanziellen Erfolg. Von daher verstehe ich es auch nicht ganz warum, dass seit 3 Jahren offen ist.
VG Fabian
TWS 2500
timberwolf138, VPN offen, Reboot jederzeit
follow me on Instagram: https://www.instagram.com/meinsommer_diy/

Ide71
Reactions:
Beiträge: 40
Registriert: Mo Jan 07, 2019 5:32 pm
Hat sich bedankt: 75 Mal
Danksagung erhalten: 14 Mal

#7

Beitrag von Ide71 »

Smart Jeanie hat geschrieben: Mi Jul 07, 2021 12:45 pm Den Ton hier verstehe ich nicht. Der 1-Wire-Bus ist eher eine Nische. Die muss man schon bewusst gesucht haben. Wenn man sie aber gesucht oder gefunden hat, dann sollte man sich mit den Eigenheiten und Charakter auseinandergesetzt haben. Nach allem, was überall zu lesen ist, ist 1-Wire nicht der Bus, mit dem man seine Reed-Kontakte abfragen sollte - wenngleich das trotzdem möglich ist. Hier wäre KNX die bessere Entscheidung gewesen - und das ist im wesentlichen auch die mehrheitliche Empfehlung. Wenn man das trotzdem anders macht, dann muss man sich mit den derzeit gegebenen Auswirkungen auch abfinden.
Jetzt Stefan dafür so anzugehen, finde ich schon ein wenig schräg.
Ich habe mich beim Hausbau für 1-Wire entschieden und einige Dinge damit umgesetzt, weil es mit dem Wiregate gut funktioniert hat. Timberwolf ist als Nachfolger des Wiregates angetreten, an der Stelle ist er aber massiv schlechter als das Wiregate. Ich kann jetzt doch nicht die Verkabelung im ganzen Haus rausreißen!? Der Timberwolf soll bei mir zu Hause in erster Linie das Wiregate ersetzen und kann das aber bisher nicht!

Ich verstehe auch nicht, was an dem Tonfall unpassend sein soll? Ich habe es nicht unfreundlich geschrieben, und man wird ja doch wohl einmal im Jahr auf diesen Missstand hinweisen dürfen!?

Gruß
Markus
TWS 950 ID:467, VPN aktiv, Reboot nur nach Rücksprache

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#8

Beitrag von gbglace »

FabKNX hat geschrieben: Mi Jul 07, 2021 1:34 pm Ich hab es auch so abgespeichert, dass ihr an dem Thema arbeitet.
Ja weil die Problemursachen so weit analysiert und intern dokumentiert sind.
Das gesamte elabnet-Team aber nun nicht so groß ist das man da Kapazitäten hat die einfach mal so nebenbei gemütlich an was langfristigen basteln.
In der agilen Arbeitsweise werden Tickets auch einfach mal beiseite geschoben wenn sie denn nicht mehr zur Priorisierung gehören.
FabKNX hat geschrieben: Mi Jul 07, 2021 1:34 pm Im Wiregate server war die 1-wire Abfrage halt auch für Reedkontakte schneller. Deshalb haben es viele bemängelt.
Ja da gab es weniger Problem in der Richtung, aber wahrscheinlich passt die Konstruktionn des 1-wire-Pollings aus dem wiregate nicht ind ie Architektur des TWS und womöglich/wahrscheinlich kommt es da dann nun zu den Restriktionen dafür ist die Stabilität erhöht.
FabKNX hat geschrieben: Mi Jul 07, 2021 1:34 pm 1-wire ist ja für eure SensorikProdukte essentiell wichtig und damit für euren finanziellen Erfolg.
Ich hoffe ja das das nicht unbedingt so ist bzw. anhält, denn der TWS ist doch deutlich mehr als nur ein 1-wire Sammler und HW-Margen beim TWS hoffentlich höher. Softwareaufwand ist natürlich gewaltig. Von daher denke ich ist es auch gesünder wenn der Verkaufserfolg des TWS nicht von der Nutzung der 1-wire Sensorik abhängt. Denn da gibt es mittlerweile einen weiteren Nischenanbieter der wohl recht umfangreich 1-wire Komponenten vertreibt.
FabKNX hat geschrieben: Mi Jul 07, 2021 1:34 pm Von daher verstehe ich es auch nicht ganz warum, dass seit 3 Jahren offen ist.
Weil 1-wire in zeitkritischen Umgebungen (Polling im einstelligen Sekundenbereich) passt nicht zum sinnvollen Funktionszielbild.
Die Glasbruchsensoren, OK. Aber Reedkontakte an Fenstern / Türen sehe ich da irgendwie nicht als sinnvollen Anwendungszweck wenn direkt etwas drauf reagieren soll. Bei allen anderen Anwendungen stellt sich auch nicht wirklich das Problem, denn ob meine Tempsensoren im Haus nun alle paar Minuten oder halbe Stunde ausgewertet werden macht funktional auch keinen wirklichen Unterschied.

Insofern ist die Repriorisierung zu den neuen Featuren um Verkaufszahlen für den TWS zu realisieren absolut korrekt.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

terseek
Reactions:
Beiträge: 265
Registriert: Mi Sep 05, 2018 1:09 pm
Hat sich bedankt: 492 Mal
Danksagung erhalten: 119 Mal

#9

Beitrag von terseek »

Smart Jeanie hat geschrieben: Mi Jul 07, 2021 12:45 pm Nach allem, was überall zu lesen ist, ist 1-Wire nicht der Bus, mit dem man seine Reed-Kontakte abfragen sollte - wenngleich das trotzdem möglich ist. Hier wäre KNX die bessere Entscheidung gewesen - und das ist im wesentlichen auch die mehrheitliche Empfehlung. Wenn man das trotzdem anders macht, dann muss man sich mit den derzeit gegebenen Auswirkungen auch abfinden.
Sorry, das kann ich so nicht stehen lassen.

Die 1wire I/Os wurden massiv damit beworben, eine kostengünstige Lösung dafür zu sein, Reedkontakte abzufragen (war wohl etwa 2011 der Fall). Und das hat dann ja auch mit dem Wiregate recht gut funktioniert.

Der Timberwolfserver wurde als eine verbesserte Ablösung des Wiregates angeboten und sollte damit wenigstens dasselbe bieten.

Die Diskussion, daß KNX besser geeignet sei für die Abfrage der Reedkontakte ist erst in den letzten Jahren geführt worden und kann daher bestenfalls als Argument für Projekte herhalten, die seitdem entstanden sind.
TWS 2600 ID:186 + 3 PBM, VPN offen, Reboot nach Vereinbarung
TWS 3500L ID:895 + 1 PBM, VPN offen, Reboot nach Vereinbarung

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#10

Beitrag von StefanW »

Verehrte Foristen,

beim WireGate Server war es so, dass ein Pollen aller Sensoren nur in einem festen Intervall für alle Sensoren möglich war, das lag bei etwa fünf Minuten. Eine Weiterleitung des Wertes konnte auch nur auf eine einzelne GA erfolgen, weitere Berechnung wie Aggregationen waren nicht möglich.

Der Algorithmus des WireGate Server konnte mithin zwischen diesem fünf Minuten Intervallen mit maximaler Geschwindigkeit pollen und konnte diesbezüglich optimiert werden.

Das hat vielen Nutzern nicht gereicht, man wollte die Sensoren viel häufiger - teils sekündlich - pollen.

Diesen Wunsch haben wir mit dem Timberwolf Server umgesetzt, man kann nun jeden Sensorwert nicht nur mehrmals mit verschiedenen Berechnungen pollen, sondern auch in einem eigenen Pollintervall, die Werte Aggrergieren lassen und mit beliebig vielen Zielen verknüpfen.

Prinzipiell kann sich ein Nutzer damit sehr viel Last am Bus schaffen, was in seinem eigenen Ermessen liegt. Wir haben dazu viele Diskussionen mit Nutzern geführt und auch festgestellt, dass diese Freiheiten der vielfältigen Einstellmöglichkeiten auch ihre Schattenseiten haben. Da war ein einfacher Algorithmus wie beim WireGate Server zwar unflexibel aber die ungünstige Konstellationen konnten auch vermieden werden.


Es ist unser Bestreben, dass die Nutzer des Timberwolf Server zufrieden sind, müssen dies aber in einer sehr großen Bandbreite von Funktionen bewerkstelligen. Ich verstehe, dass dem einzelnen, der die vielen Funktionen gar nicht nutzen möchte, dem aber die eine Funktion dafür besonders wichtig ist, frustriert ist, dass er auf die ihm wichtigen Verbesserungen lange warten muss, weil wir - ElabNET - gerade eine große Hafenrundfahrt über viele Anlegestellen fahren und nur ab und zu für Optimierungen an einem bestimmten Leistungsmerkmal vorbei kommen. Womöglich erfolgen dort dann im gegebenen Zeitbudget andere Optimierungen als man sich das gewünscht hat.

Ich bin auch manchmal frustriert, weil ich wünsche mir auch mehr und schneller Verbesserungen und neue Funktionen. Aber manches dauert nun mal und wir haben ein wirklich phantastisches Team, das über die Gesamtfunktionalität enorme Verbesserungen und Erweiterungen erzielt und wir stellen alle paar Wochen neue Funktionen stabil zur Verfügung.

Wir geben uns auch weiterhin jede Mühe, alle Anliegen so gerecht wie möglich zu bedienen und Verbesserungen an allen bestehenden 65 Funktionsmodulen mit derzeit sechs und bald acht Kommunikationsprotokollen auszuführen und neue Leistungsmerkmale einzuführen.

Wir haben viele Optimierungen in der Vergangenheit durchgeführt und damit Funktionen beschleunigt, wir werden auch bei 1-Wire im Rahmen der Möglichkeiten und der Budgets Verbesserungen umsetzen.


Auch wenn die Geduld mancher strapaziert sein mag, bitte ich weiterhin um Eure Geduld für die Umsetzung Eurer Wünsche


lg

Stefan
Zuletzt geändert von StefanW am Mi Jul 07, 2021 3:34 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Antworten

Zurück zu „1-Wire Topologie, Busmaster & Server“