Danke, freut mich wenn es sinnhaft war. Weil ich bin derzeit in Urlaub und gestern, anstatt an den Strand zu gehen, habe ich Dir 90 Minuten lang diese Erklärungen runtergetippt.
Womöglich gibt es hier ein Missverständnis.KNXMane hat geschrieben: ↑Sa Aug 22, 2020 11:50 pmEine Frage habe ich noch. Ich muss für die I/O Kontakte ebenfalls ein Abfrageintervall eingeben, gleichzeitig aber kann ich "Senden bei Änderung" einstellen. Genau so sollte es auch sein. Wenn ich nun 5s Sendeinterwall einstell, dauert es auch 5 Sekunden, bis erkannt wird, dass das Fenster geöffnet wurde. Das ist sehr nervig. Warum sendet es nicht einfach bei Änderung? 5s für ein Fentserkontakt ist eigenlich zu wenig, erhöht doch aber die Buslast.
Ein System wie KNX ist ein Multi-Master-System. Alle Geräte sind quasi gleichberechtigt und senden selbständig auf den Bus. So wie das auch mit TCP/IP over Ethernet / WLAN ist, also Hosts die selbständig mit jedem anderen Host im TCP/IP Netz eine Kommunikation aufbauen können. Mithin sendet ein KNX Gerät auch selbständig entsprechend der Einstellungen. Bei einem IO für einen Fensterkontakt würde man also ein "Senden bei Wertänderung" einstellen, GA zuweisen und fertg. Sobald ein Kontakt sich ändert, wird das KNX Gerät das feststellen und ein Telegramm auf den Bus senden. Das geht in der Regel Ruck Zuck. Aber es ist eine aufwändigere Technik, weil man benötigt einen Prozessor, Software, Zertifizierung und für das alles auch entsprechend Energie. Letzteres liegt bei einem 1/8 bis 1/4 Watt pro GNX Gerät und das summiert sich über 15 bis 30 Jahre (als angenommene Lebensdauer) ziemlich.
Bei 1-Wire (und das ist auch bei Modbus, DMX, Rest-API usw so) handelt es sich dagegen ein "Single Master - Multi Slave" System. Das bedeutet es gibt einen Master der die Kommunikation bestimmt, die Slaves antworten nur. Ein solcher Slave kann also nicht selbständig Kommunikation aufbauen. Daher muss ein Master ständig alles "im Kreis" abfragen und prüfen, ob es eine Änderung gibt. Dies hat den Vorteil, dass der technische Aufwand sehr viel geringer ist, es muss nicht oder nicht soviel an den Slaves konfiguriert werden und es wird auch weniger Software (und damit auch Updates) und teils auch weniger Energie benötigt. Ein 1-Wire Temperatursensor funktioniert mit wenigen µW, das ist etwa 25.000 bis 50.000 mal weniger als ein KNX Gerät (also bedeutet, man kann 25 - 50.000 Temperatursensoren mit der gleichen Energie betreiben wie ein KNX Gerät). Der 1-Wire Sensor ist auch technisch leichter aufgebaut, es braucht keine Zertifizierung, weniger Energie und insbesondere keine Softwareupdate, weil dort keine Software läuft. Es sind einfache Chips mit "Logic in Silicon".
Beim WireGate Server gab es zwei Zyklen. Den globalen Zyklus (meist alle 5 Minuten) für die Sensoren und den "Dauerschnellzyklus" mit dem alle IOs und iButtons geprüft wurden. Der Nutzer konnte nur den globalen Zyklus bestimmen, der Rest ging automatisch. Das war sehr einfach und hat für vieles auch gepasst. Aber es wurden auch sehr viele Wünsche an uns herangetragen, dass man das doch selbst bestimmen können möchte, also für jeden Sensor sollte das intervall einstellbar machen.
Diesen Wunsch - und hunderte anderer - haben zur Entwicklung des Timberwolf Servers geführt, weil sich diese vielen Änderungen haben mit der Architektur des Wiregate Servers nicht realisieren kann.
Es wäre aber zu überlegen, ob man bei IOs nicht automatisch den "Dauerschnellzyklus" aufnimmt ohne Einflussnahme durch den Nutzer, weil ohnehin alle auf "so schnell wie möglich stellen".
Zudem kann man auch darüber nachdenken, ob man ein "Easy Mode" und einen "Expertenmodus" anbietet, so dass der Nutzer mit dem Wachsen seiner Lernkurve sich dann erweiterte Funktionen freischaltet. Darüber kann man gerne diskutieren. Allerdings meinen wir, dass es für die Nutzer derzeit wichtig ist, dass der Server mehr Kommunikationsmöglichkeiten bekommt, daher machen wir das zuerst. Wobei wir in der aktuellen Modbus Implementierung daran arbeiten, mehrere Nutzermodi einzubauen, um einen einfachen Einstieg zu ermöglichen.
Wir haben beim Timberwolf Server zwar so viel wie möglich automatisch realisiert, damit der Nutzer weniger Arbeit hat, aber dem Nutzer auch die Macht gegeben, sehr viel einstellen zu können und es gibt sehr sehr viel Diagnoseanzeigen. Das kann einen frischen Nutzer erstmal erschlagen, dass es soviel zu sehen und zu klicken gibt. Es ist eher wie ein komplexes Cockpit bei dem der Nutzer der Kapitän ist. Das macht eine gewisse Lernkurve notwendig, ist aber bei einem Smartphone auch nicht anders. Wo viel funktioniert, gibt es auch viele Menüs und Einstellungen.
Woran wir arbeiten sind bessere und mehr an Fehlermeldungen und Informationen. Wenn Du auf die Seite "Containerverwaltung" kuckst, siehst Du oben eine Hilfeleistung und dort siehst Du unser neues Offline-Hilfesystem, das mit der Zeit auch für alle anderen Module kommen soll, so dass man als neuer Nutzer einen schnelleren Einstieg bekommt.
==> Was Deine IOs betrifft. Einfach auf eine Sekunde stellen (oder eine halbe). Der Busverkehr ist egal, es macht nichts, wenn der Busverkehr 100% beträgt.
Das würden wir uns gerne ansehen.
Hättest Du noch das Projekt davor und danach und dazu auch den Stick? Weil dann alles in ein eMail packen bitte und mit kurzer Beschreibung und auch dem Namen solcher GA / Mittelgruppen an support at wireagate dot de senden, dann sehen wir uns das gerne an.
Eine Sache noch: Der Timberwolf Server kann das Projekt importieren und prüft dabei auch die Konsistenzen zueinander. Dadurch kann es zu sehr vielen Meldungen über falsche DPT usw. kommen. Das ist nicht unnormal, die ETS arbeitet nicht so sauber wie das wünschenswert wäre (bze. erlaubt dem Nutzer eine Reihe von Unsauberkeiten) und der Timberwolf Server kann das anzeigen. Es liegt in der Hand des Nutzers das zu bewerten und ob er damit lebt oder ob er die Einstellungen konsistent machen möchte. Der TWS funktioniert auch so, aber es gibt bei der Fehlersuche schnell Interpretationsschwierigkeiten wegen unterschiedlicher Datenpunkttypen, die für einen Nutzer die Hölle sein können und daher zeigen wir das an.
Manche Nutzer haben das zum Anlass genommen und in Ihrem Projekt erstmal aufgeräumt. Der TWS ist hier nur der Messenger, er ist nicht der Grund für die angezeigten Inkonsistenzen, sondern ein Diagnosetool.