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

Wie bringt man die 1W Sensor auf KNX?

Alles zu 1-Wire im Allgemeinen. Für den Busmaster gibt es ein eigenes Unterforum unter Zubehör
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

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:

#21

Beitrag von StefanW »

Hallo Markus,
KNXMane hat geschrieben: Sa Aug 22, 2020 11:50 pmDanke Stefan für Dein ausführliche Erklärungen.
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.

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.
Womöglich gibt es hier ein Missverständnis.

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.

KNXMane hat geschrieben: So Aug 23, 2020 12:02 amGenau das hab ich gemacht. Mit dem Ergebnis, dass unter anderem mein Projekt in der ETS jetzt mache GA und Mittelgruppen jatzt andere Namen haben...
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.
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.

Ersteller
KNXMane
Reactions:
Beiträge: 83
Registriert: Mo Mai 06, 2019 2:58 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 15 Mal

#22

Beitrag von KNXMane »

Hallo Stefan

Vielen Dank, stelle die I/O auf 1s.

Hab so langsam das Prinzip des TW verstanden. Ich dachte halt es soll ein Ersatz für mein WG mit minimalen Zeitaufwand werden. Da habe ich mich getäuscht. Werde mich halt doch intensiver damit beschäftigen müssen. Nichts für Ungut, war gestern deswegen genervt.

Leider habe ich die KNXprod wieder editiert und überschrieben. Ich habe also nur eine paar Tage alte in der Datensicherung und die jetzt von mir korrigiert. Den Export habe ich noch. Hilft das?

Markus
TWS 350, ID497, VPN offen, Reboot erlaubt;

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:

#23

Beitrag von StefanW »

Hallo Markus,
KNXMane hat geschrieben: So Aug 23, 2020 9:09 pmHab so langsam das Prinzip des TW verstanden.
Fein. Es ist nicht so schwer, aber wenn man es nicht weiß, dann kommt es einem sicher umständlich und eigenartig vor, weil man so ein KNX Gerät noch nicht hatte.

==> Ich habe mir notiert, dass ich dazu einen Abschnitt in den Startanleitungen unterbringe über das Objektsystem

KNXMane hat geschrieben: So Aug 23, 2020 9:09 pmIch dachte halt es soll ein Ersatz für mein WG mit minimalen Zeitaufwand werden.
Eigentlich ist es so auch vorgesehen - im machbaren Rahmen. Leider hat der Migrationsprozess nicht vollständig funktioniert. Normalerweise funktioniert das und dann hat man kaum Arbeit. Lernen müsste man dann das ganze erst bei weiteren Sensoren.

Das was die Sache kompliziert macht ist die Notwendigkeit der Programmierung und das Prozedere mit der ETS und der ETS APP.

Es wurde damals kritisiert, dass der WireGate Server nicht KNX konform ist (so wie es der Gira Homeserver auch nicht ist) und wir haben damals professionelle Kunden verloren, weil der WireGate Server nicht vollständig kompatibel war, insbesondere in größeren Installationen mit mehreren Linien ist ein Nicht-KNX-Gerät ein Problem, weil man dann parallel eine Dummy-Applikation pflegen muss. Da kann man auch gleich eine richtige Applikation pflegen haben wir uns gedacht und ein KNX konformes Gerät entwickelt. Jetzt muss man sich in Bezug auf KNX eben mit den KNX Objekten beschäftigen, die man ansonsten nicht kennt, weil man nur die Bus-Seite der Geräte mit den GAs kennt und nicht deren Objekt-Innenleben.

Wir haben uns hierzu - für die Zukunft - eine mögliche Vereinfachung ausgedacht, die wir "Reverse-Workflow" nennen. Dabei programmiert sich der Server selbst. D.h. man würde nur die gewünschten GAs eingeben müssen und der ganze Rest, also die notwendigen Objekte und die Verknüpfung mit diesen GAs programmiert sich dann der TWS selbst. Es steht ja nicht im KNX Standard, dass dies nur die ETS ein Gerät programmieren darf. Anschließend kann man dies der Ordnung halber auch mit dem ETS-Projekt synchronisieren, das vereinfacht das Handling deutlich, ist aber noch Zukunftsmusik (allerdings gar nicht so schwer umsetzbar).

KNXMane hat geschrieben: So Aug 23, 2020 9:09 pmWerde mich halt doch intensiver damit beschäftigen müssen. Nichts für Ungut, war gestern deswegen genervt.
Ja, ich verstehe das. Neue komplexe Systeme frustrieren anfangs immer ein wenig, weil man schneller weiterkommen will als die Lernkurve das zulässt und in dem Moment ist alles andere Schuld. Das doofe Gerät, die schlechte Doku, technische Unzulänglichkeiten... Nur das Forum und diejenigen die Helfen wollen können nichts dafür und sind mit ein paar flotten Sprüchen schnell vertrieben.

KNXMane hat geschrieben: So Aug 23, 2020 9:09 pmLeider habe ich die KNXprod wieder editiert und überschrieben. Ich habe also nur eine paar Tage alte in der Datensicherung und die jetzt von mir korrigiert. Den Export habe ich noch. Hilft das?
Leider nicht. Um nachzuvollziehen, was da umbenannt wurde und warum, hätte ich gerne das Projekt vorher und nachher gehabt. Die ETS APP "Timberwolf Importer" ist recht mächtig. Die "falschen" Mittelgruppenbezeichnungen hätten vom WireGate sein können, weil man es dort ja doppelt geführt hat.


Ich wünsche viel Glück mit dem Projekt

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.

daniel29
Reactions:
Beiträge: 42
Registriert: Sa Jul 13, 2019 12:20 pm
Hat sich bedankt: 18 Mal
Danksagung erhalten: 7 Mal

#24

Beitrag von daniel29 »

Moin Stefan,

seit der Migration auf den TW2600 hab ich die letzten Monate/Jahr leider nichts mehr am System verändert.

Jetzt ist die Sauna ins Haus "eingezogen" und muss entsprechend mit neuen Sensoren ausgestattet werden. Die wurden auch von euch heute schon verschickt. Zum Test hatte ich noch einen Temp Sensor genommen den ich noch rumliegen hatte von euch und hab den mit dem 1wire Bus verbunden bevor ich das Objekt erstellt hatte. Da ich es auch dachte es wäre noch so wie beim Wiregate.

Ich habe dann jetzt in der ETS die neuen Objekte angelegt und die GAs verknüpft und den TW über die ETS programmiert. Danach konnte ich im TW über die Weborberfläche auch den Sensor mit dem K objekt verbinden. Aber irgendwie wurde im Interval nichts gesendet. Jetzt habe ich noch ein TS Objekt/Ziel angelegt. Nun schein irgendwie zumidnest irgendwas zu passieren.
Aber im Busmonitor kommt nichts und wenn ich das Objekt manuell lese wird nur 0.0 angezeigt.

Der TW hat 1.0.252. DER HS Dummy liegt auf 3.1.1 auf IP Linie
Es sieht aber irgendwie alles so aus wie meine ganzen anderen Sensoren. Auch den IP Router 1.0.0. habe ich schon programmiert

Irgendwer eine Idee?
Danke und Grüße
Daniel
Timberwolf 2600 #332, VPN offen, Reboot bitte nur nach Absprache

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:

#25

Beitrag von StefanW »

Hallo Daniel,

bitte nicht an bestehende Threads dranhängen, weil oft sind die Ursachen für mögliche Probleme anders und vor allem auch oft der Softwarestand. Einem späteren Leser hilft das nicht.

Darum meine Bitte:

1. Neuen Thread aufmachen
2. SW Version in den Threadtitel nach Forenstandard reinschreiben (IMMER)
3. Sofern Du nicht auf der aktuellen Version V 1.6 RC4 bist, bitte erst updaten

Wenn ein neuer Sensor eingebunden wird und an KNX usw. senden soll, dann immer abwarten bis auch die Bedingungen der Regel (Intervall, Funktion, Sendefilter) auch erfüllt sind. Bei KNX Objekten auf die Flags achten.

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

Zurück zu „1-Wire“