Timberwolf Server (aka "New Generation") grober Termin?

[seppm]

Nun möchte ich schon Ende September gern einen Funktionierenden 1Wire Bus haben mit einem WiregateNG welches die Temperaturen etc. dem Bus zur Verfügung stellt. So könnte der SI die Grundkonfiguration der KNX Komponenten abschließen. Mehr muss das WGNG erstmal noch nicht können. Wäre es realistisch bis dahin eins zu haben ?

Hi Chris,

wenn Du nicht grad Estrichsensoren verbaut hast um das Ausheizen zu überwachen ist es gut verschmerzbar. Je nach Witterung wirst im September eh kaum heizen. Und es zwingt den Eli (oder Dich) den hydraulischen Abgleich sorgfältig vorzunehmen da die ERR noch nicht läuft. Und der Abgleich ist eh die Basis die korrekt sein sollte.

Ich glaub da kannst Dich entspannen und in Ruhe der Dinge harren die da kommen.

Cheers Sepp

[derBert]

Zwar kann ich die Frage an Stefan nicht beantworten (wenn ich mir seine Antwort auch ungefähr denken kann), aber zwei Gedanken: Zum einen würde ich immer damit rechnen, dass bei Hard-/Software im Entwicklungsstatus noch etwas dazwischen kommen kann. Zum anderen aber: Wäre es wirklich so schlimm, wenn die Temperaturen für zwei-drei Monate nicht auf dem Bus wären? Wenn es um die Heizung geht sollte im heutigen (gut gedämmten, trägen) Neubau eine gut hydraulisch abgeglichene Anlage auch so brauchbar funktionieren. Ggf. stellt man halt manuell an den Heizkreisventilen rum. Das ist nicht schön, wäre aber IMHO kein Showstopper wenn zeitlich überschaubar.

[r3dbull]

Hallo StefanW

Ich frage mal ganz frech ob es schon Neuigkeiten zum Release des neuen Wiregate gibt. Nein ich möchte keinen Stress machen

Allerdings startet nun aktuell bei uns die Planung für unser 2 Familienhaus Renovierungsprojekt welches im September durchgeführt werden soll. Nun ist wie schon mal gesagt der SI eher auf der Seite "ohne" 1Wire+Wiregate. Ich möchte das Projekt lieber mit euren Komponenten durchführen. Der SI hat allerdings keine Erfahrung mit 1Wire und ist Zeitlich aktuell so eingespannt (wie derzeit scheinbar alle Gewerke) das er sich dort nicht in die Materie einarbeiten kann. Ergo würde das an mir hängen bleiben.

Nun möchte ich schon Ende September gern einen Funktionierenden 1Wire Bus haben mit einem WiregateNG welches die Temperaturen etc. dem Bus zur Verfügung stellt. So könnte der SI die Grundkonfiguration der KNX Komponenten abschließen. Mehr muss das WGNG erstmal noch nicht können. Wäre es realistisch bis dahin eins zu haben ?

Gruß
Chris

[StefanW]

Hallo Jürgen,

wie sieht es mit Sensoren aus die jetzt mittels Plugin funktionieren 0-10V Ausgang. .... Die sollten doch funktionieren?

wir machen hier wirklich eine komplett neue Software, da wird keine Codezeile wiederverwendet. Was nicht auf der Liste der zu unterstützenden Sensoren steht, wird auch nicht berücksichtigt.

Was wer irgendwo mit einem Plugin gemacht hat, ist bei uns nicht verzeichnet und damit einfach sehr schwer zu berücksichtigen. Da allerdings das OWFS im Kern geblieben ist, sollten Plugins, welche das OWFS direkt aufrufen auch weiterhin funktionieren (zumindest wenn OWFS aus dem Docker Container aufrufbar ist - was ich prüfen lasse).

Worüber man nachdenken kann, ist, dass die wesentlichen Chips generisch erkannt werden. Nur kennen wir die Schaltungen dazu der anderen Hersteller nicht und können keine Sensorkennlinien / Funktionen hinterlegen.

==> Es ist auf jeden Fall hilfereich, wenn diejenigen, welche die Migration auf das WireGate New Generation ins Auge fassen und irgendwas spezielles im Einsatz haben, dazu uns jeweils schreiben, wie oben dargestellt. Wir können nur über diejenigen Dinge nachdenken, von denen wir wissen. Antworten darauf (wie auch auf Feature Requests) können allerdings auch länger dauern, weil manches wird erst nach längerer Zeit entschieden.

lg

Stefan

[heckmannju]

Hi,
wie sieht es mit Sensoren aus die jetzt mittels Plugin funktionieren 0-10V Ausgang. Diese werden jetzt als Einstellungen 1-Wire 8-fach Digital I/O erkannt. Denn es ja nicht bei eucht gibt oder gab. Die sollten doch funktionieren?
VG
Jürgen

[StefanW]

Werden eigentlich auch andere 1-Wire-Sensoren außer euren erkannt....

Wir konzentrieren uns beim WireGate New Generation auf die Produkte aus unserem Haus.

Nach unserer Kenntnislage sind anderweitige Konstruktionen nur in geringem Umfang bei unseren Kunden im Einsatz. Es dürfte für alle Beteiligten günstiger sein, diesen Kunden ein Migrationsangebot zu unseren Produkten zu unterbreiten, als für die jeweils kleinen Stückzahlen an "Drittprodukten" die Softwareunterstützung zu schreiben, zumal wir diese Drittprodukte nicht im Labor haben. Wir wollen den Softwareaufwand bei der Oberfläche und dem Einphasen in die Logik in einer bezahlbaren Größenordnung halten.

Wer "Drittprodukte" im Einsatz hat, kann sich gerne bereits jetzt für ein Migrationsangebot an uns wenden. Format: "WireGate / Vorname Nachname (Firma): Migrationsangebot für Drittprodukt x mal y" an sales at wiregate dot de.

...oder haben eure einen eigenen Chip zur Erkennung drauf?

Ja, fast alle neueren Produkte haben einen Chip zur genauen Erkennung per Plug´n´play sowie für Lizenz- und Kalibrierdaten darauf.


lg

Stefan

[StefanW]

Hallo Göran,

So wie ich das verstehe gibt es ab Juli keine Chance mehr eine neue Produktdatenbank / Applikation auf Basis ETS3 von der Konnex zertifiziert zu bekommen.

wie von Dir gewohnt ist das leider richtig.

Die KNX hat letzte Woche ein diesbezügliches Erinnerungsschreiben geschickt (wurde ursprünglich Ende 2015 mitgeteilt, hatte nur keiner mehr auf dem Zeiger).

Wir prüfen das noch, aber das wird bitter eng für eine ETS3 Produktdatenbank.

lg

Stefan

[gbglace]

Hallo zusammen,

ich denke das Problem mit der ETS3 Kompatibilität des neuen Wirgates wird sich ganz schnell von selbst erledigen, wenn Die Jungs von Elabnet nicht noch ganz schnell aktiv werden und Stefan noch nen positiven Businesscase rechnet.

Aus dem Thread zum MeTa von enertex:

https://knx-user-forum.de/forum/öffe...784#post954784

So wie ich das verstehe gibt es ab Juli keine Chance mehr eine neue Produktdatenbank / Applikation auf Basis ETS3 von der Konnex zertifiziert zu bekommen.

Grüße
Göran

[SchlaubySchlu]

Hallo Stefan,
auch für mich als noch 1Wire Laien ist bis jetzt jede deiner Beschreibung verständlich gewesen.

Ich kann mangels noch fehlendem Wiregate nichts beitragen, es sei den ihr wolltet testen wie intuitiv sich euer NG Wiregate bedienen, konfigurieren und nutzen lässt.

Gruß Ralf

[TheDOC]

Also ich finde die Erklärung auch gut. Werden eigentlich auch andere 1-Wire-Sensoren außer euren erkannt oder haben eure einen eigenen Chip zur Erkennung drauf?

[gbglace]

StefanW : ebenso, sehr gut erklärt. Im Handbuch ggf in ein Kapitel technischer Background veschieben, da es Informationen sind die wahrscheinlich nur für Entwickler weiterer Softwaremodule interessant ist. Als privater Endanwender interessiert ja vorwiegend nur das wie mach ichs, nicht das warum funktioniert es eigentlich.
Für alle die im Forum unterwegs sind und sich hier in der Diskussion beteiligen und auch schon den aktuellen wiregate-Server nutzen ist mit Sicherheit letzeres aber von regem Interesse.

Grüße
Göran

[Dragonos2000]

StefanW : Nein, nicht zu kompliziert sondern m.E. gut und verständlich erklärt. Skizze/Erklärung beibehalten

[StefanW]

Keine Reaktion? Ist die Erklärung zu kompliziert?

Ein bisschen Rückmeldung wäre schön, weil dann streiche ich das aus dem Handbuch, wenn die Skizze / Erklärung nicht verständlich ist.

lg

Stefan

[StefanW]

Hallo Christian,

nun muss ich doch nochmal etwas genauer zur ETS5 in Bezug zur Parametrierung des WG-NG fragen.

Gerne. Allerdings musste ich mich korrigieren, wir liefern die Applikation mindestens ab ETS 4 aus (und überlegen ob wir nicht noch eine Applikation ab ETS 3 ausgeben können)

Können zum Beispiel der Zeitversand und das Datum weiterhin über die Weboberfläche des WG-NG einer GA zugewiesen werden oder geht dies dann nur noch mit der ETS5, mit der dann die Verknüpfung der GA´s erfolgt.

Kurze Antwort: Das geht dann nur noch mit der ETS ab Version 4 (evt. ab 3). Weil ein zertifiziertes KNX Gerät in diesem Systemmodell eine Parametrisierung per ETS verlangt.

Ausführliche Antwort:

• Die ETS ist dafür gedacht, einer Gruppe von Objekten jeweils Parameter und Verknüpfungen zu anderen Objekten über GA zuzuordnen und dies dann in die Devices zu programmieren. Darauf basiert das System und das ist so auch gut gemacht.
• Für die Parametrierung komplexer Gateway-Funktionen, also insbesondere Übergängen zu anderen Bussystemen wie DALI, DMX, 1-Wire, Modbus, ZigBee usw. ist die ETS nicht ausgelegt, weil die anderen Bussysteme nicht bekannt sind und auch kein Auslesemechanismus existiert. Die Konfiguration mit der ETS ist überwiegend One-Way.
• Gateway Hersteller müssen nun eine Abbildung zwischen den KNX-Funktionen und denen des / der anderen Bussystem(e/s) erstellen. Bei Aktoren und Licht ist das noch halbwegs einfach, weil die Anzahl der zu übersetzenden Parameter überblickbar ist, bei komplexen Sensornetzwerken sind Einstellungen und Werte dagegen äußerst vielfältig, damit auch umfangreicher.
• Vielfach wurde letzteres mit Plugins usw. oder gar Windows-Programmen vorgenommen, dies ist jedoch auf Sicht von Jahrzehnten nicht sinnvoll, da sich die Kompatibilität alter Programme auf neuen Betriebssystemen über diese Zeiträume nur schwer sicherstellen lässt. Wer einmal ein Spiel aus der Zeit von Windows 95 auf aktuellem OS versucht hat, laufen zu lassen, der weiß, was gemeint ist.
• Wir setzen daher auf eine Systematik, die mit ganz nativen Mitteln funktioniert: ETS ohne Plugins und für die Gateway-Funktionalität eine Weboberfläche in HTML 5.

Nehmen wir das Thema 1-Wire und ETS:

• Bei 1-Wire können sehr einfach und günstig können Hunderte von Sensoren und Aktoren angeschlossen werden.
• Zumindest bei unserem Produkt werden die Sensoren und Aktoren per Plug´n´Play automatisch erkannt.
• Damit ist auf der 1-Wire Seite gar nichts zu konfigurieren. Anstecken würde genügen und die Werte werden gemessen und aufgezeichnet.
• Soweit so gut, jedoch sollen für ein Smart-Home Werte auch aus anderen berechnet, archiviert, weitergeleitet und logisch verknüpft werden
• Nur: Die ETS weiß von all diesen Werten, Verknüpfungen und Möglichkeiten bei 1-Wire, die sich von Sensor zu Sensor unterscheiden, nichts.
• Wir hatten zwei Möglichkeiten. Erste Variante: Wir hätten fertige Objekte für z.B. 50 Temperatursensoren, 50 Multisensoren, 100 IOs, 15 iButtons, 3 LED-Aktoren usw. festgelegt. Hätte jedoch bedeutet, dass der Kunde ab dem 51. Temperatursensor oder dem 16. iButton einen neuen Server bräuchte und wir bei jedem neuen 1-Wire Produkt eine neue Applikation. Dann lägen wir beim Preis gleich bei KNX. Oder die zweite Variante: Wir geben dafür 1000 Objekte völlig flexibel frei und der Installateur muss nun noch über ein zweites Interface - unserem Webinterface - die Objekte zu Funktionen zuordnen. Und bei letzterem nicht nur zu 1-Wire, sondern auch DMX, Logiken und sehr viel mehr, lasst Euch überraschen.

Kurzvergleich "bisheriger" WireGate Server zu dem künftigen WireGate Server der neuen Generation:

• Beim bisherigen WireGate Server waren die möglichen Zuordnungen und viele Parameter fest Code hinterlegt oder konnten nur "generell" eingestellt werden. Es wurden nur "feste" Berechnungen angestellt (Taupunkt), alle Werte unflexibel archiviert und konnten nur einer GA weitergegeben werden. Selbst einfachste Logiken musste man selbst in Perl programmieren.
• Mit dem WireGate der Neuen Generation ist alles flexibel: Zeiten, Intervalle, Archivierungsoptionen, Verknüpfungen und Zuordnungen, Logiken können pro Wert beinahe beliebig angelegt werden. Übrigens egal ob 1-Wire oder KNX oder DMX oder..... Dies nur als Hinweis, um die folgenden Erklärungen besser zu verstehen.

Konzept der Zuordnung von 1-Wire Sensoren zu KNX mit dem WireGate New Generation:

Erklärung der Module anhand der Nummern in der Skizze:

1. 1-Wire Sensoren / Aktoren: Diese werden einfach an die 1-Wire Busleitungen angeschlossen. Es ist nichts zu konfigurieren.
2. 1-Wire Busmaster: Das einzige Systemgerät ist der Busmaster, der die elektrische Signalformung übernimmt. Jeder 1-Wire Bus benötigt seinen Busmaster. Es gibt Multi-Busmaster, die in einem Gehäuse bis zu drei unabhängige Busmaster beinhalten. In manchen Versionen des künftigen WireGate Servers der New Generation wird ein solcher Multi-Busmaster fest eingebaut sein. Weitere sind anschließbar.
3. 1-Wire Scheduler: Dies ist die Softwarekomponente die zusammen mit dem Busmaster die Kommunikation mit den Sensoren übernimmt und für das Plug´n`Play verantwortlich ist. Der Begriff Scheduler kommt daher, dass künftig jeder Sensor / Aktor seinen eigenen Zyklus, seinen eigenen Fahrplan hat. Mithin kann man den einen Sensor häufiger als einen anderen auslesen lassen. Damit kann sich ein jeder das System nach Bedarf optimieren.
4. Logik: Dieser sitzt in der Mitte und besteht aus einem Softwarebus und hunderten von Logikmodulen. Dazu unten ein wenig mehr.
5. KNX Stack: Dies ist eine zertifizierte Komponente, welche sich per ETS konfiguriert wird und natürlich die Kommunikation mit dem Bus - oder mehreren - ausführt.
6. TP-UART: Dies sind die Hardware-Module, welche den zertifizierten Chip enthalten, der die eigentliche Signalformung und Kommunikation auf dem TP durchführt. Es ist ein Chip aus der gleichen Familie, die in geschätzt mehr als der Hälfte aller am Markt befindlichen Geräte verbaut wird.
7. ETS ab Version 4 (im Bild fälschlich als 5.x angegeben): Mit der ETS wird der KNX-Stack und die Objekte programmiert. Entweder per Ethernet mit KNXNet/IP oder per KNX-TP, je nachdem wo was angeschossen ist.
8. Ethernet / WLAN: Alle WireGate Server verfügen über einen Ethernet-Anschluss. An oder in manche wird sich auch WLAN einbauen lassen.
9. KNXnet/IP: Unser KNX Stack beinhaltet auch die Implementierung für KNXnet/IP Tunneling. Hier sind bis zu 100 gleichzeitige Tunnel möglich (abhängig von Gerät und Lizensierung). Routing ist für einen späteren Zeitpunkt vorgesehen.
10. Webadmin API: Die Server der neuen Generation haben eine moderne Schnittstelle zum Webinterface.
11. Web-Admin: Unser neues Admin-Tool funktioniert auf allen Systemen, vom Smartphone bis zum 5k-Mac.

Die Reihenfolge der Zuordnung von 1-Wire Sensoren zu KNX sieht dann in etwa wie folgt aus:

1. Sensoren anstecken und mit der Oberfläche auf Funktion prüfen.
2. Sich Gedanken machen, welche und wieviele Werte an den KNX-Bus übermittelt werden sollen.
3. Die nötigen Objekte mit der ETS im WireGate New Gen. programmieren.
4. Nun die Zuordnungen der Werte und Funktionen / Aktionen zu Objekten per Web-Admin eintragen.
5. Die Punkte 1 bis 5 können mehrmals hintereinander wiederholt werden.

Diese Zuordnungen von 1-Wire to KNX (und einer Datenreihe für Archiv) sehen dann ungefähr so aus:



Aus dieser Beispieltabelle kann man gut die freie Zuordnung erkennen. Ein Wert kann beinahe unbeschränkt auf verschiedenste Weise verknüpft werden. Vieles, für das früher ein Plugin notwendig war, wird in wenigen Sekunden einfach eingetragen. Soweit möglich, wird zu den Objekten die per ETS zugeordneten GAs informativ angezeigt.

Ich hoffe, es ist nun verständlich, dass wir um eine ETS Programmierung für die Objekte nicht herumkommen und auch intern mit den Objekten arbeiten müssen, diese Zuordnung jedoch äußerst einfach und flexibel gelöst werden kann. Wir haben uns natürlich noch einiges mehr gedacht, aber das wird noch nicht verraten.


Ideen? Feature Requests? Schreib!

Wem jetzt ein paar gute Gedanken kommen, darf uns gerne schreiben: "WireGate / Vorname Nachname: Featurerequest WG-NG zu ......" an support at wiregate dot de. Gerne mit konkreten Beispielen und sehr gerne mit Skizzen zur Benutzerführung / Bildschirmseiten.

Bitte nicht ungeduldig werden, falls ich nicht sofort antworte. Es kann manchmal ein paar Wochen dauern bis ich antworten kann. Manche Vorschläge sind so gut, da muss ich länger darüber nachdenken.


lg

Stefan

[derBert]

dito. Aber es gibt ja dann wieder Hoffnung, Yeah! Gute Nachricht für's Wochenende!