ElabNET Technik Forum

Robosoc hat geschrieben: ↑Mo Mär 15, 2021 4:01 pm - und ich bin ziemlich an den Grenzen.

Hallo Sven,
deinen Vorschlag finde ich auch gut, aber irgendwann kommt man trotzdem an die Grenzen.
Ich denke, was Stefan da geschrieben hat, das ist eine bessere Lösung
Auch die Kunden, die Multi IOs für die Fensterkontakte nutzen, die werden sich sehr freuen

StefanW hat geschrieben: ↑Fr Aug 31, 2018 11:36 am 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.

MfG Juri

Hallo alle zusammen,

ich habe gehofft das wer dieses Thema mal anschneidet
Habe die 2 bereits genannten Anwendungszwecke, Dusche/Badewanne hier soll halbwegs Zeitnah erkannt werden ob geduscht oder gebadet wird -> Lichtstimmung je nachdem.
Und als Zweiten Punkt wären eine handvoll Multi IOs für die Fensterkontakte in der Küche, hier soll man den Dunstabzug erst einschalten können wenn ein Fenster geöffnet bzw. gekippt ist.

LG Mario

1. Ja, das Feature macht in meinen Augen Sinn.
2. Aber: Das alles sollte nicht darüber hinweg täuschen, dass es besser ist, den geeigneten Bus für den betreffenden Verwendungszweck zu wählen. Reedkontakte gehören für mich z.B. nicht an den 1-wire-Bus. Göran erklärt das hier immer mal wieder ganz gut.

Und ehe jetzt daran gearbeitet wird, einen Bus auch dort noch verwenden zu können, wofür er nicht gedacht war, fände ich es besser, es kämen zunächst weitere Protokolle hinzu. Das würde die Not für Workarounds an anderer Stelle auch reduzieren und den TWS noch schneller universell machen. Im zweiten Schritt kann dann gerne an diesem Thema optimiert werden.

Es wäre für den einen oder anderen vermutlich eine Hilfe, wenn er bei der Planung wüsste, was er sinnvollerweise an welchen Bus anschließt. Dazu könnte ich mir ein kurzes Video gut vorstellen.

Naja der Abfragezyklus ist eben in manchen Themen ein kritischer Punkt, weswegen ich halt auch 1-wire so nicht bedenkenlos empfehlen kann.

Mit dem Verbessern der Leistung der allgemeinen Abfrageperformance wäre das natürlich schon mal die wichtigere Funktion.
Danach kommt dann für diejenigen User mit umfangreichem Bus und ggf. Platzproblemen oder reine Übersichtlichkeit beim Loggen der Bedarf an Selektivität gern auch Zustandsabhängig. Was in der einen oder anderen Situation und womöglich auch noch Sensorabhängig der Auslöser für kurzes / langes Intervall ist, ist ja egal. Aber das Intervall justierbar zu machen klingt da nicht schlecht um den Bus zu optimieren.

Gute Beispiele sind ja genannt zur Optimierung des Systemverhaltens durch selektive Intervalle.

Also von der prio her, erstmal grundlegend beschleunigen dann per Objekt justiebar machen. Beim 1-wire.
Beim Modbus ist es ja "nur noch" das Justierobjekt.

gbglace hat geschrieben: ↑Mo Mär 15, 2021 7:44 pm Also von der prio her, erstmal grundlegend beschleunigen dann per Objekt justiebar machen. Beim 1-wire.
Beim Modbus ist es ja "nur noch" das Justierobjekt.

Hi Göran,
genau so sehe ich das auch

MfG Juri

Hallo zusammen,

ich fände eine variable Abfragezeit pro Sensor auch nicht schlecht. Wenn man nun noch die Möglichkeit hat die Abfragezeit durch ein externes Objakt zu beeinflussen wäre natürlich top. Was fallen mir für Anwendungsfälle ein?
Brauchwasserzirkulation, bei mir erfasse ich durch ein anderes Steuerungssystem die Temeratur.Abhängig von einer Zeitschaltuhr wird dann die Pumpe aktivert oder abgeschaltet. (Schwellwert)
Jedliche Art vom Mischern in Heizsystemen.
VOC/Lusftgüte bei einer Lüftungsanlage nach einer Sollwerterhöhung der Lüfterstufe mehr Messungen damit man eine Reaktiongeschwindigkeitsder Lüftung tracken.

Wann und wie das implementiert werden soll? meiner Meinung sollten erstml die anderen Funktionen laufen. Ich denke je mehr Funktionen da sind, desto mehr User wird das generieren/Umsatz erzeugen, und Reichweite generieren und somit auch Cashflow für Entwicklungen bereitstellen.

so long,
auch ein Stephan

SteMo hat geschrieben: ↑Mi Mär 17, 2021 6:50 pm Wann und wie das implementiert werden soll? meiner Meinung sollten erstml die anderen Funktionen laufen. Ich denke je mehr Funktionen da sind, desto mehr User wird das generieren/Umsatz erzeugen, und Reichweite generieren und somit auch Cashflow für Entwicklungen bereitstellen.

Genau so sehe ich das auch ... und desto mehr Input-Geber und Anregungen hier im Forum.

Das Thema der Anpassung von Abfrageintervallen steht glaube schon seit mehr als 2 Jahren im Raum.

Ich finde das würde extern zum 1-wire Bus Entlastung beitragen.
Ich muss meine Türen und Fenster nicht immer auf Minimaler Abfragezeit betreiben. Wenn ich durch Präsenz im Raum unterscheiden kann.
Genauso in meiner Werkstatt, wenn ich da nicht bin, dann müssen die I/O garnicht angefragt werden. Aber wenn ich da bin, dann halt sehr eng.

Genauso bei der Bodenfeuchtigkeit. Wenn es Herbst und Winter ist, dann interessiert der Wert sicher niemanden. Aber wenn es Bewässerungszeit ist, dann schon. Aber man ändert ja an der konfig ja nicht dauernd rum.
Ofen mit Wassertasche interessiert nur wenn Ofen an. Sonst überhaupt nicht.