ElabNET Technik Forum

Ich bin gerade bei der Ersteinrichtung meines neuen Timberwolf 350Q.

Und stehe irgendwie auf Kriegsfuß mit der Einrichtung des KNX-Stacks (nach 2h lesen von Anleitungen, Foreneinträgen, ausprobieren, ... steigt die Müdigkeit und gleichzeitig der Frustlevel. Sowohl die TWS-Applikation als auch der Importer sind bei Erstbenutzung enorme Zeitfresser).

Mich würde interessieren, was denn die Vorteile sind, dass ihr auf eine KNX-App gesetzt habt und dabei dem Kunden einiges bei der Ersteinrichtung abverlangt?

Jedem anderen Server da draußen (?!) reicht der Import einer KNX-Datei ... ihr geht einen anderen Weg mit vielen Hürden für den Nutzer ... was sind die Vorteile, die sich mir daraus ergeben?

Hi
Falls du die "ETS-Inside" App meinst, dann ist diese nur fur diejenigen, die kein ETS Demo, light oder professional nutzen, sondern eben "ETS Inside"

Um deine KNX Datei zu importieren klicke einfach auf Einstellungen, dann KNX, und dort auf den Reiter Projektdatei

Liebe Grüße
Philipp

Nein - ich meine das ETS-Gerät, was ich für den Timberwolf anlegen muss.
Was ich aus einem anderen ETS-Projekt rüberkopieren muss. Wo ich die Objekte freischalten muss. Wo die Erstprogrammierung 10min dauert.

Das Ding hier: app.php/kb/viewarticle?a=11
Ich ändere mal den Titel.

Moin Stefan,
Ja im ersten Augenblick mit dem Wissen der anderen Server im Hinterkopf scheint es verwirrend und aufwändig, mit ein wenig Erfahrung am TWS am Ende deutlich besser.

Ich gebe einfach mal einige Stichworte.

- kein Dummy im Projekt erforderlich (den man auch mühsam händisch pflegen muss)
- über Flags alles sauber in der Buskommunikation einstellbar
- mit der Importer-App ist die GA-Struktur schnell 1:1 in KO des TWS übertragen
- mit der Importer-App sind auch direkt vom TWS Objekte als GA und KO im KNX-Projekt angelegt (gut für 1wire oder alles was der TWS sonst noch so an Objekte generieren wird)

Warum das ganze?
Der TWS ist ein zertifiziertes KNX Gerät in Gänze (nen X1 ist wohl ne zertifizierte Schnittstelle aber dahinter nur noch irgendwas) damit muss er mit KO die Kommunikation zum Bus herstellen, sofern die Signale nicht wirklich über einen Tunnel gesendet werden.

Praktischer Vorteil im Arbeiten mit dem Server ist dann, dass er intern aus den KNX-KOs auch einfach ein TWS-internes Objekt macht welches dann wie alles andere auch via DOS verlinkt werden kann. Derzeit eben ganz frei KO von/zu 1-wire und/oder Logiken.
An der Stelle wird ja noch an vielen Erweiterungen gearbeitet (Modbus, DMX, DALI, MQTT) damit kann dann schon via reiner Verlinkung ohne Code und Logik mit dem KNX kommuniziert werden.

Einen weiteren Vorteil keinen Dummy benutzen zu müssen ergibt sich noch, wenn auch z.b. die Comet-Visu einen Adapter bekommt, um mit den internen TWS-Objekten arbeiten zu können.

Ich selbst finde die Importer-App schon genial, weil es einfach einfach ist das ETS-Projekt in den TWS-Stack zu bekommen.
Der TWS nimmt dann zwar wie alle anderen Server auch gern noch die normale Knxproj in sich auf, das aber im wesentlichen nur für die "Doku" im Busmonitor und Grafana, wo eben auf den reinen Bustraffik zugegriffen wird und quasi nur PA/GA/Value bekannt sind.

Hi Göran,

mit ein wenig Erfahrung am TWS am Ende deutlich besser

Das halte ich aber für sehr problematisch, wenn man am Markt erfolgreich sein will. Es zählt der Ersteindruck für Neukunden massiv - wenn ich von einem Produkt erst nach intensiver Nutzung überzeugt bin, dann gibt es mittelfristig ein Problem.

Ich sehe in deinem Post ein paar konkrete Gründe (Dummy-Objekt, interne TWS Objekte) und aus Design-Entscheidungen hervorgegangen Workarounds (voll zertifiziertes KNX Gerät statt 'nur' Schnittstelle, Importer-App).
Aber ergänzt gerne noch ein bißchen mehr.

Zu ein paar Punkten:

Praktischer Vorteil im Arbeiten mit dem Server ist dann, dass er intern aus den KNX-KOs auch einfach ein TWS-internes Objekt macht

Die TWS-internen Objekte hätte man aber auch mit 'nem .knxproj Import erstellen / zuordnen / mappen können.
Dann hätte es den Importer (deutlich einfacher) als Webanwendung direkt im TWS gegeben, der am Ende genau das gleiche deutlich performanter hinbekommt.

Der Importer macht ja derzeit nix anderes, als GAs auf interne Objektnummern zu mappen und den Typ festzulegen.
Das alles in einer Umgebung, die leidlich Probleme mit 2000 Objekten hat.

Ich selbst finde die Importer-App schon genial,

Ich schreibe später mal zusammen, welche Stöcke sie mir zwischen die Beine geworfen hat

kein Dummy im Projekt erforderlich (den man auch mühsam händisch pflegen muss)

habe ich tatsächlich super lange (2 Jahre?) bei allen anderen Lösungen nie benötigt! Alle wichtigen GAs sind doch verknüpft und brauchen kein Dummy Objekt. Darüber hinaus ist ein 'Dummy' Objekt ein wohldokumentierter Workaround, mit dem sich 'jeder' in der KNX-Welt auskennt.

Nur für die später hinzukommenden GAs (z.B. virtuelle Schalter in der Visu, deutlich seltener Logik-GAs), ist doch das Dummy-Objekt nötig.
Auch eher selten, die meisten Variablen von Logiken bleiben intern, die braucht es auch nicht auf 'nem Dummy Objekt.

Ich habe gerade mal geguckt: mein bisheriges Dummy-Objekt hat 16 (!) Einträge. Meist damit das alte Wiregate halt ein paar wenige zusätzlich Logik/Visu GAs kennt. Das Timberwolf-Gerät hat nun nach Wiregate-Import 121 Einträge. Zum Glück nicht manuell gepflegt.

Guten Morgen,

bluegaspode hat geschrieben: ↑So Nov 10, 2019 12:10 amUnd stehe irgendwie auf Kriegsfuß mit der Einrichtung des KNX-Stacks (nach 2h lesen von Anleitungen, Foreneinträgen, ausprobieren, ... steigt die Müdigkeit und gleichzeitig der Frustlevel. Sowohl die TWS-Applikation als auch der Importer sind bei Erstbenutzung enorme Zeitfresser).

Sollte eigentlich nicht so lange dauern.

• Wir bieten die Applikation des TWS zum direkten Download vom TWS an, da muss man nicht lange auf der Webseite des Herstellers suchen, wie woanders.
• Die Applikation - derzeit noch als Projekt - sollte in wenigen Minuten in das eigene Projekt kopiert worden sein. Ich habe erst diese Woche wieder einen TWS Server in Betrieb genommen. Vom Anschließen bis zur Vergabe der physialischen Adresse und der ersten vier Objekte hat das keine 10 Minuten gedauert.
• Die Installation der "Timberwolf Importer" App ist gar nicht notwendig. Es ist lediglich ein (sehr) hilfreiches Tool, wenn man vom WireGate Server migrieren möchte oder wenn man eine große Anzahl von Objekten freischalten möchte, etwa weil man sämtliche GA der ETS als Objekte haben möchte. In diesem Fall saprt die "Timberwolf App" bei 1000 GA zu Objekten um die 10 Arbeitsstunden. Für das normale Anlegen einzelner Objekte benötigt man die APP nicht.

bluegaspode hat geschrieben: ↑So Nov 10, 2019 12:10 amMich würde interessieren, was denn die Vorteile sind, dass ihr auf eine KNX-App gesetzt habt und dabei dem Kunden einiges bei der Ersteinrichtung abverlangt?

Der Timberwolf Server ist ein Server mit zertifiziertem KNX Stack. Wie jedes andere KNX zertifizierte Gerät muss es mit der ETS programmiert werden. Die physikalische Adresse und dann die Freischaltung einzelner Merkmale / Objekte und dann die Zuweisung der Gruppenadresse. Das ist in KNX eben so vorgesehen und hat man auch, wenn man einen KNX Taster mit einem KNX Aktor verbindet.

Der Timberwolf Server macht hier überhaupt keinen Unterschied gegenüber jedem anderen KNX Device.

bluegaspode hat geschrieben: ↑So Nov 10, 2019 12:10 amJedem anderen Server da draußen (?!) reicht der Import einer KNX-Datei ...

Jeder andere Server da draußen ist nicht KNX zertifiziert (oder höchstens die Tunneling Schnittstelle)!

Jeder andere Server da draußen verstößt - dadurch dass er nicht programmiert wird und die ETS nichts von seiner Existenz weiß - gegen wichtige Prinzipien und Sauberkeiten einer KNX Installation:



Die Filtertabelle - oder wie flute ich nicht den Bus:

• Der KNX Bus ist mit seinen ca. 30 bis 40 Telegrammen pro Sekunde ein relativ langsamer Bus.
• Ist ein Bus nun etwas ausgedehnter oder möchte man aus Sicherheitsgründen oder wegen der Autarkie eine Abschottung (z.B. für die Gartenlinie oder jedes Hotelzimmer oder Licht- von Heizungsanlage) dann wird man weitere Linienkoppler / Bereichskoppler haben
• Damit solche Segmentierungen auch sinnvoll wirken können, sollte sich ein einzelnes Telegramm nicht wie ein systemweiter Broadcast über das gesamte Netz in alle Linien verteilen. Zum einen weil das in größeren Installationen schnell den Bus flutet (und im Fehlerfall dann nochmal mehr) und zum anderen, weil man ja aus Sicherheitsgründen nicht jedes Telegramm überall haben möchte (denken wir wieder an die Gartenlinie, die für einen gedachten Hacker von außen zugänglich ist).
• Um nun dieses auch umzusetzen, müssen in den Linienkopplern und Bereichskopplern Filtertabellen geladen werden, diese Filtern den Verkehr aus und lassen nur das auf die andere Seite was auch auf die andere Seite muss.
• Es ist ein großer Komfort, dass diese Filtertabellen von der ETS berechnet und in den Linienkopplern und den Bereichskopplern dann auch geladen werden.
• Damit die ETS dieses Kunststück fertig bekommt, muss sie die Topologie kennen und was in welcher Linie installiert ist. Daher muss man ja auch die ganzen Linien, Bereichslinien, Hauptlinien und die ganzen Linien- und Bereichskoppler auch anlegen.
• Und genau deshalb, weil der Timberwolf Server eben auch eine richtige Applikation hat und die Objekte angelegt und mit GAs verbunden werden, kann die ETS berechnen, welche Telegramme auch dem Timberwolf Server zuzuleiten sind, je nachdem an welcher Stelle der Topologie er sitzt.

Jeder der anderen Server da draußen unterläuft das, wenn der Kunde nicht eine Dummy-Applikation lädt, an die entsprechende Stelle in der Topologie "hängt" und dann alle verwendeten Gruppenadressen auch mit diesem "nicht KNX Gerät vertreten durch eine Dummy Applikation" assoziiert, damit die ETS die Filteradressen berechnen kann.

Wenn man aber nun, für jeden anderen Server da draußen, sich - um das Projekt ordentlich zu halten - eine Dummy-Applikation besorgen und diese ausfüllen müsste, dann kann man es doch auch gleich richtig machen - so wie beim Timberwolf Server, der damit auch der EINZIGE, wirklich zu KNX vollständig kompatible Server ist.


Die einzigste Software:

Die Filtertabellen sind das eine, ein komplettes ETS-Projekt ist noch das andere. Es ist ja das besondere Wesen einer KNX-Installation, dass es die EINE Software gibt, mit der man alles einstellt. Und das für 8000+ Produkte von 400+ Herstellern. Da kocht keiner ein eigenes Süppchen (von den DALI-Apps usw. mal abgesehen), sondern alles wird mit einer einzigen Software - der ETS - eingerichtet.

DAS ist doch die ganz besondere Stärke des KNX-Systems:

1. Absolute Kompatibilität durch EINEN Standard, nun schon über 30 Jahre, durch Zertifizierung nach sehr intensiven (und teuren) Tests.
2. EINE Software mit der alles eingerichtet werden kann. Über die letzten 28 Jahre und auch die nächsten 25 Jahre.

KEIN anderer Smarthome Standard kann das bieten oder wird das je bieten können!

Man stelle sich vor, für jedes Gerät hätte man eine herstellerspezifische Software um diese einzurichten am Bus. Man stelle sich vor, es bliebe jedem Hersteller überlassen, wie kompatibel er denn ist. Das Ergebnis wäre Chaos und der KNX hätte nicht seinen Standard.

Aber jeden anderen Server da draußen schert das offenbar wenig. Dort wird die Kompatibilität nicht zertifiziert (allenfalls die verwendeten TP-UART-Chips und selbst das nichtmal wie z.B. bei der Loxone die nur ein BitBang Interface hat).


Abhängigkeit vom funktionierenden Projektimport:

Jeder andere Server da draußen ist auf einen funktionierenden Projektimport angewiesen.

Hier darf man nicht übersehen, dass die KNX Assoc. bei der Entwicklung der ETS bei jeder neuen Version (und damit ist die erste Stelle hinter dem Komma gemeint) das Format des Projektfiles ändert. Also wie zuletzt beim Übergang von der ETS 5.6x auf die 5.7 geschehen.

Ohne anschließendes SW-Update gibt es dann aber kein Einlesen mehr. Mag vom Hersteller durchaus nachgeliefert werden, kann aber Wochen - bei "schlechten" Herstellern - auch Monate dauern oder gar nicht mehr passieren, weil das Gerät "End of Support" ist. Was dann? Dann muss Mann / Frau in einem solchen Fall womöglich jeden anderen Server da draußen auf den Müll werfen oder den Rest der Lebensdauer auf das ETS Upgrade verzichten (was nur gelingt, wenn man die alte ETS Version noch installieren kann und auch eine Sicherheitskopie des Projektes vor dem Upgrade hat).

Was dann?

Nun, bei dem einzigen verfügbaren KNX zertifizierten Server kann man - dank der getesteten Kompatibilität der Programmierung - alle Änderungen einfach weiterhin programmieren. Einfach so. Wie bei jedem anderen Schalter und Taster auch. Auch die nächsten 25 Jahre, auch wenn man schon längst nicht mehr die Projektdatei einlesen kann. Weil das Einlesen der Projektdatei beim TWS ist kein muss. Es ist auch möglich, die DPT der GAs usw. von Hand anzulegen im GA-Editor, die Literale ebenfalls (diese Möglichkeit wurde vor allem für Projekte geschaffen, bei denen das KNX Projekt verloren gegangen ist).

Ich denke ALLEINE dieser Punkt, (die mit Sicherheit irgendwann ablaufende Kompatibilität zu ETS Projektdateien) wird die Nutzbarkeit des ETS-programmierbaren Timberwolf Server um das dreifache über jeden anderen anderen Server da draußen heben.

Langlebige IT ist oftmals eine Frage der richtigen Strategie. Daher bitte immer beim Kauf überlegen, mit technischen Ansatz besteht die Möglichkeit einer Nutzung über 10 bis 20 Jahre.

Das streben wir an. Wir wollen Euch NICHT alle paar Jahre ein neues Gerät verkaufen - wie jeder andere Hersteller da draußen - sondern wir wollen, dass der Server 15 bis 20 Jahre genutzt werden kann. Darum gibt es auch den Care-Vertrag, damit wir dann einen solche langen Support auch leisten können.

Ich meine, das ist eine Strategie, die sich am Ende auszahlen wird für den Anwender. Und deshalb KANN man den TWS aus der ETS programmieren.



Wir haben sehr sehr viel Geld ausgegeben, einen zertifizierten 32/64 Bit KNX Stack mit 8000 Objekten (das ist der leistungsfähigste Stack auf dem Weltmarkt) zu entwickeln der - übrigens als einziger - auch die Möglichkeit hat, dass man Universalobjekte mit den DPTs belegen kann und diese bei der Programmierung mitkommen (hat sonst niemand).

Ich denke, die Vorteile liegen nun klar auf der Hand.

lg

Stefan

bluegaspode hat geschrieben: ↑So Nov 10, 2019 9:52 amEs zählt der Ersteindruck für Neukunden massiv - wenn ich von einem Produkt erst nach intensiver Nutzung überzeugt bin, dann gibt es mittelfristig ein Problem.

Unsere Zielgruppe ist mittelfristig der Integrator, der die Vorteile einer kompletten KNX Integration von vorneherein auch bewerten kann.

Hierbei ist auch die rechtliche Komponente zu beachten. Der private Anwender kann zuhause machen was er will. Derjenige der dafür bezahlt wird hat für das Werk eine Gewährleistungspflicht und im Falle einer Klage kommt es zur Begutachtung durch einen Gutachter. Da ist der Integrator nur mit zertifizierten Produkten und einer Standard-konformen Arbeitsweise auf der richtigen Seite.

bluegaspode hat geschrieben: ↑So Nov 10, 2019 9:52 amDie TWS-internen Objekte hätte man aber auch mit 'nem .knxproj Import erstellen / zuordnen / mappen können.

Nein. Weil zu einem KNX-Objekt können bis zu 16 GAs zugeordnet werden. Das ist ja genau der SINN der Adressierung von Funktionen über Gruppentelegramme, dass dort Gruppen von Funktionen zusammengefasst werden. Dies soll auch helfen, dass Telegramme eingespart werden, weil sich mit einem Telegramm mehrere Funktionen sich gleichzeitig schalten lassen.

Genau auf diese Weise kann ein KNX Aktor auf seinem Schalt-Objekt die Kommandos von bis zu 16 Gruppen empfangen (weil das Hoflicht eben von vielen Stellen aus mit eingeschaltet werden soll).

Diese Systematik sollte auch in der Logikengine fortsetzbar sein. Man verbindet ein KNX-Objekt mit einem Logikeingang. In der ETS kann man dann bis zu 16 Objekte darauf mappen (wie bei jedem anderen Objekt eines anderen KNX Devices auch).

Nimmt man nun jeden anderen Server auf dem Markt, der nur eine KNXprojekt einlesen kann (wie lange und ob das funktioniert ist ohnehin die Frage) dann BRICHT man diese Systematik und bricht damit auch die eigentliche Sinnhaftigkeit der GAs als Funktionsadressen auf. Denn dann kann man die Logik in einem solchen Server nicht mehr genauso nutzen wie in jedem anderen KNX Device, dem man nur die entsprechenden GAs assoziiert zum Objekt (das mit der Logik verknüpft ist), sondern man müsste dann mehrere GAs auf den Logikeingang mappen. Damit hat man dann aber mehrere Stellen in dem diese Assoziationen eingestellt sind, was die Übersichtlichkeit im Projekt erschwert.

bluegaspode hat geschrieben: ↑So Nov 10, 2019 9:52 amDann hätte es den Importer (deutlich einfacher) als Webanwendung direkt im TWS gegeben, der am Ende genau das gleiche deutlich performanter hinbekommt.

Hier vermag ich nicht zu folgen.

Der "Timberwolf Importer" als APP für die ETS ist ein nicht notwendiges, aber hilfreiches Tool für folgendes:

1. Freischalten der Universalobjekte und Belegung mit einem DPT auf Basis einer Definitionsdatei (also als Massenmodus)
2. Anlegen von GAs und Belegung mit einem DPT auf Basis einer Definitionsdatei (also als Massenmodus)
3. Verknüpfen von GAs mit Objekten auf Basis einer Definitionsdatei (also als Massenmodus)

Anwendungsbereiche:

• Import der Einstellungen vom WireGate Server (weil dieser eine solche Definitionsdatei erzeugt)
• Um das Anlegen vieler Objekte / GAs / Assoziationen aus einer einfachen Excel-Datei zu ermöglichen, also zur Vereinfachung
• Damit man - selbst wenn man sein Projekt verloren hat - aus den (zuvor programmierten Einstellungen) aus dem Timberwolf Server sich eine Defintionsdatei ziehen und wieder einlesen kann. Also nicht nur eine Programmierung hin - sondern auch zurück.

Was man daran nun in eine Browserbasierte Bedienung in den Timberwolf Server portieren können sollte ist mir schleierhaft. Es geht hier um ein Tool für die ETS und speziell für die ETS und damit möglichen Vereinfachungen. Damit wird dem Kunden ja gerade geholfen, ein klares und sauberes Projekt zu erstellen. Das man beim TWS dann zusätzlich importieren KANN (nicht muss).

bluegaspode hat geschrieben: ↑So Nov 10, 2019 9:52 amDer Importer macht ja derzeit nix anderes, als GAs auf interne Objektnummern zu mappen und den Typ festzulegen.

Dem ist nicht so und dessen Leistung ist auch keinesfalls "nix anderes". Hast Du mal ein Dual-KNX-to-DALI Gateway mit 2450 Objekten mit der ETS programmiert? Da wärst Du froh, wenn der Hersteller hier einen solchen Importer liefern würde, mit dem man das auch aus einem Excel-File einlesen könnte, weil das 10 bis 15 Stunden Klickerei spart, auch wenn das Tool sonst "nix anderes" kann.

bluegaspode hat geschrieben: ↑So Nov 10, 2019 9:52 amDas alles in einer Umgebung, die leidlich Probleme mit 2000 Objekten hat.

Was an der Umgebung liegt. Die ETS ist mit der Zeit immer mehr überfrachtet worden. Insbesondere die KNX Secure Entwicklung hat zu Erweiterungen geführt, die heute die mehrsekündigen Gedankenpausen erzeugen. Die KNX Assoc. ist darüber informiert und arbeitet an einer Lösung.

bluegaspode hat geschrieben: ↑So Nov 10, 2019 9:52 amIch schreibe später mal zusammen, welche Stöcke sie mir zwischen die Beine geworfen hat

Ja, da bin ich schon gespannt. Zumal man sie gar nicht benutzen muss. Man kann auch herkömmlich alles von Hand anlegen, so wie bei jedem anderen KNX Device auch.

Es sind uns bisher keine Probleme damitbekannt hatte (außer bei denjenigen, welche die Doku noch nicht gelesen oder den Sinn nicht verstanden haben). Lediglich der Aufwand der Lizensierung ist lästig, aber das ist der offizielle Weg, den die KNX Assoc. so designed hat (und für den wir auch ordentlich zahlen mussten, damit es im Store kostenlos bereitgestellt wurde.

lg

Stefan

OK,

ich merke, du bist komplett von den Vorteilen überzeugt, da will ich gar nicht groß gegendiskutieren, auch wenn ich viele Dinge anders / pragmatischer sehe.

Ich habe nur ein bißchen Angst, dass die Leute evtl. vorher aufgeben, bevor sie von den ganzen Vorteilen profitieren.

Wenn eure Zielgruppe Systemintegratoren sind, dann schnappt euch mal einen, ladet ihn zu euch ein und lasst ihn einen Timberwolf für 20% Rabatt einrichten (dafür, dass er sich die Zeit nimmt vorbeizukommen). Ihr aber bitte in einem zweiten Raum nur per Video zugeschalten, ohne zu helfen, dafür ganz viele Notizen machen und Zwischenzeiten stoppen.
Bonusaufgabe: Blutdruck messen

Oder besucht jemand, der völlig neu sich mit eurem System beschäftigen muss, eure Dokus habt und gebt ihm einfache Aufgaben:
- installiere das System
- bringe den Busmonitor zum laufen
- zeige eine erste Zeitreihe per Grafana an.

Dass du das in 10min schaffst ist definitiv keine Referenz.
Wir machen das auf Arbeit sehr oft, das ist in der Regel sehr deprimierend für uns (viel viel Entwicklungsarbeit gemacht und Nutzer bekommen es trotzdem nicht hin) aber fürs Produkt am Ende unbezahlbar.

Hier meine Notizen von gestern. Achtung: sie sind gefrustet geschrieben worden, da meine Erwartungshaltung eines 'einfachen' Start mit meinem Timberwolf nicht erfüllt worden. In Summe respräsentiert das hier geschriebene ca. 3h Aufwand (viel lesen und der eine oder andere Irrweg) und bei mir läuft der Busmonitor aktuell noch nicht. Bekomme ich aber sicherlich noch hin, das ist die Aufgabe für heute.

Installieren der ETS-App

• Ich muss in der Doku finden wie das geht. In der PDF-Schnellstartanleitung steht es nicht. Im überall für neue User verlinkten Startartikel der Knowledge Base auch nicht. Das ist die KNX-Sektion noch komplett leer app.php/kb/viewarticle?a=75, genau da wo es spannend wird.
• Laune steigt leicht, mit etwas mehr suchen, alternativen Artikel der Knowledge Base (und das Inhaltsverzeichnis der Knowledge Base) gefunden.
  Statt in der ETS zu suchen, muss ich es im Timberwolf runterladen, bekomme ich hin.
• Laune sinkt. Ich muss die App irgendwie manuell kopieren. 2 Projekte in der ETS gleichzeitig öffnen um rüberzukopieren? Habe ich noch nie gemacht.
• Mhhm. Ich habe die ETS 5.7.2 aber es fühlt sich langsam an. ETS friert beim ersten Mal öffnen des Timberwolf Projekts ein (schwarzes Fenster, keine Reaktion)
  Im Forum steht, ETS ist schuld.
  Irgendwann klappt es (Notiz an mich: habe Geduld - warte etwas länger, wenn die Fenster nicht mehr reagieren)
• Na gut ... programmieren wir zum ersten mal. Hmm - ultra langer Fortschrittsbalken. Bin ich zu ungeduldig?
  Oh - nach 10min doch schon fertig

Timberwolf Importer

• Muss mich durch weitere Anleitungen durchlesen, um den Importer zu installieren. Durch 7 überflüssige Schritte zum "Kauf" eines 0€ Tools durchklicken. App runterladen und installieren. Lizenz generieren. Lizenz runterladen. Lizenz aktivieren. Suchen, wo der Importer nun überhaupt auftaucht.
  Frustlevel: auf Tiefpunkt - Anzahl Klicks nichtmehr gezählt.
• OK- loslegen. Yeah - der Importer zeigt meinen Wiregate Export an. "Ausführen" gedrückt.
• Mhmm. Bricht ab. Fehlermeldung.
  
  Klicken auf die Buttons macht nix. ETS abgeschmiert.
• Neu gestartet, nochmal probiert. Überall grüne Häkchen vor den GAs. Dann lauter Fehlermeldungen. In der Importdatei wären keine Objektnummern.
• Nach weiterem Lesen. Mhmm - diese andere Option nehmen? Objektnummer 'neu anlegen'. Import läuft wieder los.
  Überall grüne Häkchen. Bei der letzten GA hängt es. Fortschrittsbalken aber bei 100%.
  Im Timberwolf Gerät keine Änderungen - hier hätte jetzt die Objekte sein müssen?
• Neustart ETS, Kaffee trinken
• Letzter Versuch. Jetzt klappt es - nach endlicher Wartezeit kommt auf einmal ein neuer Fortschrittsbalken "Objekt xyz wird gelesen".
  Mhmm - das ist aber langsam. Ok - noch ein Kaffee ... langsam ...
• Letzter Schritt: ETS-Datei speichern, Im Timberwolf hochladen.
• Nachtrag: Importer interessehalber nochmal mit gleichen Optionen gestartet.
  Ganz viele Error: z.B: "Objekt #122 Objekt 122 DPST-1-1 konnte nicht freigeschaltet werden" oder "Kein aktives Kommunikationsobjekt mit Nummer 122 gefunden, der Import eintrag 0/1/10 EG Essen Lampe Decke schalten wird übersprungen".
  Zum Glück scheint alles richtig, ich verfolge das nicht weiter - habe nur ein bißchen Angst vor dem nächsten Mal, wenn ich alle GAs der ETS noch ergänzen will.

Jetzt magst du für alle diese 'Probleme' darauf hinweisen, dass die ETS die Wurzel allen Übels ist.
Mag sogar sein.
Ein Hersteller, der sich dafür entscheidet alles standardkonform zu machen, obwohl es dann zu schlechter Usability führt, hat das aber bewusst mit beeinflusst und konfrontiert seine Kunden notgedrungen damit.

Ein Erlebnis, dass ich schnell loslegen kann und erste Erfolge feiern kann, habe ich aktuell nicht.
Das soll kein Vorwurf sein, ist aber eine sehr persönliche Beobachtung.

Wie oben geschrieben: ich habe Angst, dass Systemintegratoren dann in Zukunft lieber doch was nehmen, was nicht ganz standardkonform ist aber trotzdem funktioniert (und schnelle erste Erfolge bringt).

Hi Stefan,
Das mit der KB scheint wirklich noch nicht Ideal. Da steht hier auch noch ein Umzug auf eine modernere elektronische Plattform an.

Bei Deinem Beispiel Kunde mit Wiregate-Migration ist es in der Reihenfolge etwas abweichend bzw. Optional als eine Umgebung ohne Wiregate-Server.

In der Version ohne Wiregate hätte ich als erstes versucht den TWS als solches in der ETS zu aktivieren und ohne 1-wire Objekte durch die ETS zu programmieren. Danach hätte ich auch schon einmal die ETS-Projektdatei in den TWS geladen. Damit sollte der Busmonitor und Grafana schonmal vollständig funktionieren auch wenn die 1-wire Werte noch vom Wiregate auf den KNX gegeben werden. Also auch noch ganz ohne Importer-App. Zeitlicher Aufwand dafür halt der Transfer der Applikation vom TWS in die ETS. Ja an der Stelle würde ein Endkunde auch lieber einen Eintrag im Onlinekatalog erwarten. Aber auch die gestandenen Anbieter schaffen Ihre Applikationen auch nicht zum Verkaufsstart da drinnen zu haben. Wobei es dann aber schon ein Unterschied ist eine Projektdatei, statt eines Mini-ETS Projektes zu haben. Das zumindest ist sicher noch ne Hausaufgabe.

Für die Migration des Wiregate kommt dann zum ersten Mal die Importer-App als Werkzeug ins Spiel. Der Lizenzierungsprozess für nen kostenloses Tool ist wahrlich kein ernst zu nehmender Prozess. Was wäre aber aktuell ne Alternative? Eigentlich nur solche anderen Undinge wie ETS-Plugins. Da ist ganz klar die Konnex gefordert den Prozess zur App-Aktivierung zu vereinfachen.

Aber egal Mal weiter. Nach dem das ETS-Projekt dann durch die Importer-App KNX-KOs angelegt und mit GAs verknüpft hat, dann den TWS nochmal programmieren. Hier ist es empfehlenswert den TWS bereits als Schnittstelle für die ETS zu verwenden, das kann das deutlich beschleunigen.

Zu dem Thema kann @StefanW sicher noch was sagen. Mindestens Zeitvorteil ist das Longframe Format und ggf auch der IP-Weg an der grünen Leitung vorbei (Vermutung).

Nach dem nun der TWS quasi alle 1wire Objekte intus hat ist es für den Busmonitor und Grafana wieder angebracht das KNX Projekt in den TWS zu laden.
Dann noch die TWS interne Migration damit auch der 1-wire Bus selbst im TWS läuft.

Für diejenigen die einen hohen Spieltrieb haben und sehr umfangreiche Logiken usw. Ausprobieren, die machen das mit der Importer-App ggf nochmal, indem quasi das gesamte ETS Projekt bzw. Alle GA 1:1 als KNX-KO im TWS angelegt werden. Das ist aber soweit nicht notwendig.

Ein hier im Forum schon Mal angesprochener Grund für diesen Schritt könnte zusätzlich für jene User sein, die quasi Datenfetischisten sind. Der KNX-Busmonitor registriert ja erstmal alles vom Bus. Allerdings gibt es für diesen Speicherbereich der DB eine Speichersystematik als Ringspeicher, das kann irgendwann dann auch einfach voll sein. Bisher ist hier aber von den frühen Kunden noch nichts vollgelaufen / abgeschnitten. Hat man hingegen KOs definiert und legt diese jeweils in eine eigene Timeseries, ist rein die Festplatte der limitierende Faktor.

Da hier noch niemand an ein Speicherlimit gestoßen ist habe ich derzeit auch nur den reinen Busmonitor laufen und noch keine eigenen Timeseries angelegt.
@StefanW an der Stelle Mal ne Frage zur ersten Final-Version. Werden dann auch alle Mengengrenzen gemäß der Lizensierung entsprechend des Kataloges aktiviert sein? Aktuell ist ja glaube noch alles soweit unlimited!?