[DISKUSSION] 1-wire Abfrageintervall wertabhängig ändern

[jensgulow]

Hallo,

in letzter Zeit habe ich mir immer häufiger folgendes feature gewünscht:

Könnte man das Abfrageintervall für bestimmte 1-wire-Sensoren an bestimmte Wertebereiche koppeln?

Hintergrund: z.B. Temperatursensoren lese ich nur alle 5 Minuten aus (da diese sich normalerweise nicht wesentlich in kurzer Zeit ändern). Nun habe ich einen in der Sauna - dieser ist ca 95% der Zeit mit dem 5-Minuten-Abfrageintervall auch gut zu monitoren. Wenn nun aber die Sauna angeschalten wird, dann ändern sich die Temperaturwerte natürlich drastisch. Wenn ich nun schnell (oder besser gesagt schneller) auf das Erreichen einer bestimmten Temperatur reagieren will, dann wäre ein kürzeres Abfrageintervall z.B. ab Temp >50 Grad sinnvoll.

Ähnlich z.B. für Füllstandanzeigen (drohender Überlauf oder Leerlauf) ..... oder "Duscherkennung" (Temp-sensor am Warmwasserzulauf)

[StefanW]

Hallo Jens,

solche Gedanken hatten wir schon. Bei Modbus gibt es die Idee (nix versprochen) dass man - ergänzend oder anstatt zu Intervallen - separate Auslöser für das Lesen / Schreiben setzen kann. Damit könnte man dann solch eine Funktion realisieren.

Ich habe das auch für 1-Wire aufgenommen. Es würde mich allerdings interessieren, wer das noch benötigen mag?

Eine Bitte: FRs gibt es immer erst nach einer Diskussion, daher habe ich das zu einer Diskussion geändert.

lg

Stefan

[Didda93]

Mir kommt gerade ein Gedanke zu Abfrageintervallen von Tür/Reedkontankten. Die Umsetzung ist eventuell etwas komplexer (das sag ich jetzt aber nur weil bisher immer alles was im Kopf "glaub ich ganz gut machbar" erschien ziemlich kompliziert wird wenn man sich dann dran macht).
Türkontakte sollten ja sehr häufig abgefragt werden wenn man diese als Trigger für "Licht an" verwendet.
Um den Bus möglichst wenig allgemein zu belasten kann man das Abfrageintervall abhängig davon machen wo eine Person von seinem jetzigen Standort auf eine Tür mit Kontakt Zugriff hat

Bsp:
Keiner zuhause: alle abfrageintervall auf "selten" bis auf Haustür (da einzige Tür, auf die man von außen Zugriff hat)

Anwesenheit im Flur EG: alle Türen, die vom Flur EG aus betreten werden können

Usw.

Damit hätte man den Vorteil, dass man sehr schnelle Reaktionen auf öffnen von Türen hat, ohne dass jede einzelne Tür dauerhaft den Bus zuspamt. Geht natürlich alles nur wenn man davor Anwesenheit von Personen in jedem einzelnen Raum erkennen kann.

Vielleicht ist das doch nicht so einfach realisierbar, aber der Gedanke gefällt mir ganz gut mit anpassbaren Abfrageintervallen bei 1Wire

Lg
Philipp

[StefanW]

Vielleicht ist das doch nicht so einfach realisierbar, aber der Gedanke gefällt mir ganz gut mit anpassbaren Abfrageintervallen bei 1Wire

Jep, das ist richtig gedacht.

Die Idee war durchaus, dass zum Beispiel bei betreten des Bades (Präsenzmelder) der Temperatursensor für die Duscherkennung häufiger abgefragt wird.

Oder, andersherum bei Modbus, dass wenn die Sonne untergegangenen ist, ein Teil des Pollens der Parameter für den PV-Anteil am Wechselrichter, nicht mehr oder seltener abgefragt wird.

Die Frage ist nun, sind solche flexiblen Auslöserkonzepte "überflüssiger Schnickschnack" der uns keine Credits und keine Käufer bringt (weil nicht bewertet) oder bringt es - neben den Kunden - auch das Produkt im Verkauf weiter ?

lg

Stefan

[jensgulow]

Die Frage ist nun, sind solche flexiblen Auslöserkonzepte "überflüssiger Schnickschnack" der uns keine Credits und keine Käufer bringt (weil nicht bewertet) oder bringt es - neben den Kunden - auch das Produkt im Verkauf weiter ?

Also als Schnickschnack würde ich das nicht bezeichnen wollen. Flexible Abfrageintervalle bringen halt solche Systeme, welche nicht aktiv beim Eintreten eines Zustandes senden (1-wire, MODBUS) doch mehr Anwendungsmöglichkeiten. Man könnte diese dann auch dort einsetzen, wo man bisher doch stärkere Bedenken hatte (s. mein Beispiel drohender Überlauf oder Trockenlaufen...).
Wenn solche zusätzlichen features entsprechend kommuniziert werden, dann gibt es bestimmt Käufer, welche sich proaktiv für das System entscheiden, weil halt mehr Anwendungsfälle abgedeckt werden.

justmy2cents

[StefanW]

Hi Jens,

Wenn solche zusätzlichen features entsprechend kommuniziert werden, dann gibt es bestimmt Käufer, welche sich proaktiv für das System entscheiden, weil halt mehr Anwendungsfälle abgedeckt werden.

Ja, nur WIE kommuniziert man solche speziellen Details, damit ein Käufer angezogen wird?

Viele sagen uns; Macht die Videos kürzer. Nur 3 Minuten und auf die Top-10 konzentrieren, mehr will keiner sehen.

Also wenn ich mich bei der gesamten Funktionalität des Servers auf drei Minuten - von mir aus pro Protokoll - konzentrieren muss, dann kann man solche Spezialitäten nicht bewerben (und schon zwangzig andere tolle Features davor auch nicht mehr). Zumal der geneigte Interessent womöglich erschrickt angesichts der vielen Einstellmöglichkeiten und womöglich fälschlicherweise meint, er müsse das alles von Anbeginn auch gleich verstehen. Weil es ist schon ein Spagat in der Darstellung, dass alles mächtig sein muss aber gleichzeitig auch Easy und Jogurtleicht aussehen muss.

Und was sagen wir denjenigen Kunden die auf Funktionen wie UDP / MQTT / Rest-API / Szenencontroller usw. warten, dass es damit nochmal dauert, weil wir vorher noch die Abfrage in 1-Wire weiter flexibilisieren sollen?

Das ist, was ich mit "Schnickschnack" meinte. Nicht dass die Idee nicht super ist (die wir auch schon hatten), sondern dass das Nutzen- / Kostenverhältnis ein wenig schlecht ist. Ich will das Feature nicht zerreden, finde es auch toll, aber wir dürfen nicht außer acht lassen, dass uns das Erfüllen vieler spezieller Wünsche in der Vergangenheit auch viel Kritik eingebracht hat, weil wir damit vom Fahrplan abgewichen waren.


lg

Stefan

[jensgulow]

@StefanW ich kann Deine Argumentation verstehen. Letztendlich müsst ihr entscheiden, welche Priorisierung ihr präferiert.
Ich habe auch nicht gesagt, dass ihr das machen SOLLT.....es war nur eine Anmerkung/Idee, welche mir als Nutzer des TWS aufgefallen ist.
Also bleibt bei Eurem Fahrplan, damit die versprochenen Features auch zeitgemäß auf den Weg gebracht werden können. Ihr könnt ja solche Anfragen auf Verbesserung vorhandener features auf Eurer "to do Liste" weiter hinten platzieren.

Zum Thema Werbevideo: Ja, 3 Minuten ist die magische Grenze. Darüber hinaus hört sich das wirklich nur ein speziell interessierter Nutzer an. Wenn man neue Kunden erreichen will, dann mit den berühmten "Eye-Catchern"...
Natürlich ist es schwer ein so mächtiges Stück Technik auf die Top10-features und eine 3-Minuten Botschaft "herunterzubrechen" .....Aber Werbung im Fernsehen dauert WESENTLICH kürzer und erreicht trotz allem sein Zielklientel....Die "füttern" halt nur an ....

[terseek]

Hallo Stefan,

das Feature wäre auch für mich interessant, ich frage mich aber, ob es überhaupt noch nötig ist, wenn die folgende Verbesserung vorgenommen wird:

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 wir 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.

[Robert_Mini]

Wenn nun aber die Sauna angeschalten wird, dann ändern sich die Temperaturwerte natürlich drastisch. Wenn ich nun schnell (oder besser gesagt schneller) auf das Erreichen einer bestimmten Temperatur reagieren will, dann wäre ein kürzeres Abfrageintervall z.B. ab Temp >50 Grad sinnvoll.

Ich bin aber etwas überrascht, was ihr das so diskutiert, vielleicht hab ich was flach verstanden.

Man kann ja Abfrageintervall und Sendeintervall parametrieren.

Für obigen Fall würde (habe) ich die Abfrageintervall auf 20-30s gesetzt. Das Sendeintervall steht auf 300sec oder abs. Änderung > 2C.
Damit kommt in der regel alle 5min ein Wert und bei schnellerer Änderung eben öfters. Das genügt doch, oder?

Was anderes ist der Fall, dass man den Bus an seine Intervallgrenzen treibt, dann wäre eine variable Abfrage die Lösung, aber auch nur, wenn nicht gleichzeitig ein 2. Sensor schnelle Werte braucht.

lg
Robert

[Robosoc]

Es würde mich allerdings interessieren, wer das noch benötigen mag?

Ich würde das Feature auf jeden Fall nutzen wollen!
Anwendungsfälle die mir spontan einfallen:

• - einige Temperaturfühler der Solarthermieanlage
  - einige Temperaturfühler der FBH-Etagen-Mischer

Was anderes ist der Fall, dass man den Bus an seine Intervallgrenzen treibt, dann wäre eine variable Abfrage die Lösung, aber auch nur, wenn nicht gleichzeitig ein 2. Sensor schnelle Werte braucht.

Ja, sehe ich exakt wie Du, Robert - und ich bin ziemlich an den Grenzen. Daher würde ich vermutlich viele Abfrageintervalle noch weiter verlängern und dafür bei Bedarf einige wenige bei Bedarf stark verkürzen. Gerade Solarthermine und FBH-Etagenmischer könnte man ggf. recht gut gegen einander aufheben, so dass nur ein Anwendungsfall "vollgas" gibt