WERBUNG: Erfahrungsbericht Timberwolf Server 950Q

[Beleuchtfix]

IP-Symcon ist auch aus einer reinen, immer wieder erweiterten Softwarelösung entstanden, die Symbox gibt es erst seit kurzem. Damit war der Einstieg natürlich etwas ganz anders als beim WG/TWS. Und 2005 war das, was an Softwarelösungen angeboten waren, etwas ganz anderes. So konnten die noch vorsichtig einsteigen und sich langsam entwickeln, heute wird das wesentlich schwieriger sein.
Gruß Florian

[Gast1961]

Ich wollte jetzt gar nicht IPS bewerben (das hat auch seine Punkte, die mir nicht gefallen) sondern das Konzept diskutieren, wie man so eine umfangreiche Aufgabe zwischen einem kommerziellen Hersteller und der Community aufteilt, und es dabei trotzdem ein integriertes Produkt bleibt.

[gbglace]

Verständnisfrage: Ich hatte bisher verstanden, daß Anwender beim TWS eben keine Module programmieren können, die innerhalb der TWS-Oberfläche laufen und direkt mit dem TWS-Kern kommunizieren können?

Hi Volker,

die Wundertüte im TWS ist der DOS, "Dispatcher Object Selector".
Der TWS stellt für die unterstützten Protokolle eine Schnittstelle zur Verfügung. Die jeweilige Schnittstelle findet man quasi im Objekteditor. Denn der TWS stellt zu jeder Technologie interne TWS-Objekte zur Verfügung. Diese können dann fast beliebig (sowas wie Datentypen müssen halt irgendwie zueinander passen) kombiniert werden. Der Dos ist da quasi nur ein pop-up wenn man einen Input oder Output sucht. Geht man da drinnen in die Auswahllisten ist auch schon alles auf kompatible Objekte gefiltert, man kommt also auch nicht in die Verlegenheit nen Tempsensor mit einem 1bit KO im KNX zu verbinden.

Wer also so leicht schmutzige Pseudoszenen im KNX an der ETS vorbei wie 1 Schalt GA führt zu synchronen Auslösungen auf x anderen GA machen will, nimmt einfach den DOS und klickt diese Verbindungen an einander. Da braucht es nicht mal nen LE-Modul für. Das kommt dann erst wenn es irgendwie invertiert oder verzögert werden soll. Dazu reicht dann aber auch ein Modul für eine solche Aktion mit x Zielen.

Im 1-wire Umfeld werden die Objekte quasi plug and play erzeugt sofern ein neues Gerät am Bus detektiert wird. Dazu lassen sich dann auch direkt am Gerät x Regeln zur Sensorauswertung definieren. Jeder Regel-Output ist dann quasi ein TWS-Objekt. Auf der Seite KNX macht man es eben via der ETS die Objekte zu generieren. Im DOS ist es dann nur noch ein Zusammenführen der Objekte. 1-wire Sensorwert als AVG z.B. auf ein KNX-KO welches dann per GA versendet wird, alles ohne DB-Eintrag oder Rechenlogik.

Sollen mit den Objekten mehr Intelligenz und Abhängigkeiten generiert werden, dann macht es eben der LE, ob ich da nun aber auf einen Tempwert aus 1-wire oder eine Temp aus KNX zurückgreife ist dem LE egal und wo es dann hingeht ist auch wieder egal.

Aktuell sind quasi 1-wire, KNX und DMX (Hutschiene) in der Form angebunden.
Zum DMX wird es aber eben auch noch eine bessere Sub-Oberfläche zur Objektverwaltung geben. Und statt einer Customlogik zur Definition von Dimm- und Schaltevents wird es auch noch eine eigene Maske geben um es nicht alles in LE-Code machen zu müssen. Daher ist das DMX Feature an der Stelle noch Beta.

Der Docker ist gerade das Übergangskonstrukt um die Lücken der Protokolle zu füllen (IP-Welt usw. via. z.B. Node Red >> KNX >> TWS).
So wie weitere Protokolle quasi nativ unterstützt werden geht das auch alles am Docker vorbei.

Ziel ist es ein Protokoll so anzubinden, dass dieses als fertiges TWS-Objekt zur Verfügung steht um eben sehr einfach damit arbeiten zu können ohne weitere Codierungen.

Wäre der TWS so gestaltet das er die Option Docker nicht ermöglichen würde, wäre hier jedwede Kritik vollkommen berechtigt, weil für den Preis ein KNX / 1-wire GW anzubieten wäre mehr als verwunderlich.

[gbglace]

So konnten die noch vorsichtig einsteigen und sich langsam entwickeln, heute wird das wesentlich schwieriger sein.

Ja dem TWS lastet nun das Schicksal der späten Geburt an, um die heutzutage vielfältigen vom Markt teilweise als obligatorisch geforderten Protokolle zu unterstützen.

[Gast1961]

Hi Göran,

Sollen mit den Objekten mehr Intelligenz und Abhängigkeiten generiert werden, dann macht es eben der LE, ob ich da nun aber auf einen Tempwert aus 1-wire oder eine Temp aus KNX zurückgreife ist dem LE egal und wo es dann hingeht ist auch wieder egal.

Ok, wobei ich bei der Beschreibung sagen würde daß es in bei OpenHAB oder IP-Symcon nicht anders ist. Wenn der TWS da weiter geht wäre das eine detailliertere Beschreibung wert.

Ich meinte was anderes:

Der Docker ist gerade das Übergangskonstrukt um die Lücken der Protokolle zu füllen (IP-Welt usw. via. z.B. Node Red >> KNX >> TWS).
So wie weitere Protokolle quasi nativ unterstützt werden geht das auch alles am Docker vorbei.

Ziel ist es ein Protokoll so anzubinden, dass dieses als fertiges TWS-Objekt zur Verfügung steht um eben sehr einfach damit arbeiten zu können ohne weitere Codierungen.

Was ist mit "Protokoll" gemeint, das ist mein Punkt.

Da ist es in IPS eben so, daß der Hersteller die Basistechnologie anbietet (z.B. diverse Internetprotokolle und Hilfsmittel) und die konkrete Implementierung für Rasenroboter oder für Sonos kann jemand anderes machen. Da muß sich der Hersteller nicht selbst drum kümmern - könnte er bei der Breite der gewünschten Anbindungen vermutlich auch nicht. Und dafür gibt's eben eine Schnittstelle, wo sehr spezialisierte Module eingehängt werden können.

Das ist meine Frage, wie weit Elabnet da alles selbst machen müsste oder das Systemkonzept zulässt, daß Anwender/Community die Lücken mit eigenem Code füllen - was das System insgesamt schneller voranbringt, weil es mehr Entwickler gibt, die in die Breite der Anbindungen gehen.

[Dragonos2000]

Hi Volker,

Du meinst sowas, wie MQTT, REST oder ne eigene API, um direkt auf die Objekte (1-Wire Sensoren, KNX KOs,...) des Backends (TWS) zugreifen zu können?

[Gast1961]

Du meinst sowas, wie MQTT, REST oder ne eigene API, um direkt auf die Objekte (1-Wire Sensoren, KNX KOs,...) des Backends (TWS) zugreifen zu können?

MQTT oder REST würde ich für Anbindung externer Systeme sehen. Wichtige Basistechnologie, um Daten auszutauschen.

Ich meinte für die Module schon eine eigene API, so wie es bei IP-Symcon gelöst ist. Der Anwender wird die Module idR auch konfigurieren müssen und dann braucht's ein Benutzerinterface. Das sollte schon integriert sein mit dem System in gleicher Bedienlogik und gleichem Look & Feel.

Um es am Beispiel zu zeigen, wie so ein Communitymodul sich integriert:

1. Man fügt das Modul hinzu vongithub oder aus dem neuen IPS-Appstore
m.jpg

2. Man konfiguriert die Modulparameter (hier: Standort und welche Daten man sehen möchte)

openweathermap.jpg

Und das war's schon, alle Daten stehen zur Verfügung zur Nutzung in Visu und Logik/Scripten. Alles nahtlos integriert, weil es über die API alles in IPS abläuft, obwohl es ein Community-Modul ist.

openweathermap2.jpg

[gbglace]

Für Protokolle wo Zielsysteme wie so ein Rasenmäher eine wie auch immer geartete Dialektik sprechen, da so ein IP-Telegramm ja individuell aufgebaut werden kann, braucht es dann noch eine Art Sortierebene zwischen der Protokollschnittstelle selbst und den TWS-Objekten. Bisher ist eben nur 1-wire / KNX / DMX mit den sehr standardisierten Protokollen vorhanden. Wie die anderen Protokolle dann eingebunden werden wo das Daten-Telegramm keiner fixen Standardisierung unterliegt werden wir sehen was Elabnet sich da ausdenkt. Es sicher hilfreich wenn dann quasi Format-Vorlagen zur Objektgenerierung einheitlich sind ob und wie sowas auch von der Community dann gebaut werden kann muss man auch sehen. Aber sicher kein schlechter Gedanke das nicht alles auf die eigenen Entwicklerkapazitäten nehmen zu müssen.

Schritt eins ist aber erstmal das Protokoll selbst zu erschließen und dann im Beta die Usability abzurunden und besten falls laienbedienbar zu machen.

[MatthiasS]

die Wundertüte im TWS ist der DOS, "Dispatcher Object Selector .....".

Danke für die Beschreibung. Das war deutlicher als der Großteil der bisherigen Beiträge, leider auch der von StefanW. Du solltest das zukünftig kommentieren, eine vernünftige Bodenhaftung und ehrliche Beschreibung kann dem Produkt nur gut tun.

[773H]

Hallo zusammen. Nachdem es hier durch eine etwas ausgeartete - und IMHO völlig unnötige Diskussion zu Hardwaredetails des TWS - leider etwas unübersichtlich geworden ist und die "Werbeerfahrungsberichte", um die es hier eigentlich doch gehen sollte, etwas in den Hintergrund gerückt sind, anbei mal wieder was zum eigentlichen Thema. Ich schreibe nur über eine (kleine) Auswahl an Sachen, die mir heute aufgefallen sind.

Aus Anwendersicht sehr erfreulich ist am TWS, dass dieser einem viele öfter anfallende Arbeitsschritte so leicht wie möglich macht. Beispielsweise muss man nach dem Anlegen von neuen Gruppenadressen in der ETS dem TWS mitteilen, dass diese angelegt wurden. Dadurch tauchen diese dann mit Klartextnamen im TWS-Busmonitor und an anderen Stellen im TWS auf und können korrekt identifiziert und verwendet werden. Nach dem Programmieren des TWS in der ETS öffnet sich z.B. nach dem Einloggen in den TWS sofort das Fenster "KNX->Projektdatei" und der notwendige Import kann weder vergessen werden, noch muss mal lange nach dem richtigen Pfad suchen.

Zum Kühlkonzept mit dem massiven Aluminiumgehäuse lässt sich sagen, dass die CPU meines Desktop-TWS momentan eine Temperatur von 39°C aufweist - wie auch immer das mit einern passiven Kühlung erreicht werden kann. Das Konzept (und die Liebe zum Technischen Detail) zahlt sich also definitiv in Form von potentieller verlängerter Hardwarelebenszeit aus. Die komplette Systemübersicht zu allen relevanten Systemparametern und laufenden Diensten ist im Übrigen durch einen einzigen Mausklick im Hauptmenü mit einer Verknüpfung aufzurufen.
System Monitor.jpg
Um auf den vorhin erwähnten Busmonitor zurückzukommen. Wie bereits weiter oben erwähnt besteht eigentlich keinerlei Bedarf für den ETS-Busmonitor mehr, wenn man Besitzer eines TWS ist. Das Schlagwortsystem (Tags) in Verbindung mit einfach anzulegenden Filterkriterien und der permanenten Aufzeichnung aller Telegramme ab dem Zeitpunkt der TWS-Erstinbetriebnahme lassen die ETS-Version im Vergleich zum TWS-Busmonitor wirklich "abstinken".
Beispiel: seit geraumer Zeit hatte ich das Probelm, dass sich die manuell gesetzte Sperre meiner Markise aus ungeklärer Ursache unregelmäßig zurückgesetzt hat. In der ETS war die Sperre nur in einer einzigen GA gesetzt und ließ keinerlei Rückschlüsse auf den Urheber zu. Als es mir heute zu bunt wurde und ich etwas Zeit hatte, rief ich den TWS-Busmonitor auf, filterte einen Zeitraum von 3 Monaten nach der Sperradresse und fand heraus, dass während des gesamten vergangenen Urlaubs keinerlei Rücksetzen der Sperre stattgefunden hatte. Diese wichtige Erkenntnis (in Verbindung mit Präsenzmeldern und Szenen im Wohnzimmer) führte mich letztendlich zu einer nicht völlig durchdachten Szene des HS4, die nur gelegentlich nachts gebraucht wurde.
Die Dauerverfügbarkeit von KNX-Telegrammen i.v.m. den Filterfunktionen und der farblichen Differenzierbarkeit durch den TWS ist ein absolutes "Must-Have"!

To be continued ...

Gruß
Stephan

[GLT]

To be continued ...

Na hoffentlich nicht - oder wollt ihr jetzt gebetsmühlenartig hier spammen?

Inzwischen ist bekannt, dass der TWS weit hinter den Werbe-PR hinterhinkt u. derzeit nur extrem eingeschränkt brauchbar zu sein scheint.

Und als ultimativer Busmonitor ist er völlig überteuert und marktobsolet.

[henfri]

Ich fand's interessant

[Fisch]

Ich fands auch interessant. Zumindest mehr interessant als so manche andere Beiträge in diesem Thread. Warum sollte man sowas in einem Thread, der auf Werbung geändert wurde, auch nicht schreiben dürfen.

[Didda93]

GLT


Ich stimm dir voll zu, dass die Software momentan noch nicht den Stand hat, den sie hätte haben sollen.
Dieser Fakt ist mittlerweile umfassend bekannt.
Es ändert mMn. jedoch dennoch nichts daran, dass die Funktionen die unsere Wölfe (ja, ich habe auch einen TWS, jedoch bin ich in der ganzen KNX Materie noch relativ neu und beginne erst so langsam meine Wohnung (noch in Bauphase) auszustatten, weshalb ich mich bisher eher aus Diskussionen heraushalte) bisher besitzen nicht zu unterschätzen sind.
Liegt meines Erachtens daran, dass Stefan sich sehr nach den Kunden richtet und dementsprechend viele kleine Details hinzugefügt werden.

Klar, dies sorgt natürlich für Verzögerungen und ja, mir ist ebenfalls sehr deutlich bewusst dass Stefan sich hier keinen guten Ruf gemacht hat.

Ich als Kunde bin dennoch sehr zufrieden, weil ich die Fortschritte direkt miterlebt habe und für mich (!) ist klar, dass sich trotz einiger noch vorhandener Lücken der Timberwolf sehr schnell weiterentwickeln wird.

Außerdem hat es einen ganz gravierenden Vorteil dass ich mir bereits einen 960Q zugelegt habe:
Ich erlebe jeden Schritt der Entwicklung und wenn neue Funktionen released werden wird die Meinung jedes Forenmitgliedes gehört und bei ausreichender Zustimmung der Anderen umgesetzt.

Es fällt mir ziemlich schwer jetzt irgendwelche Vorteile explizit zu nennen, da ich ehrlich gesagt keinen Vergleich habe wie sich andere Server anstellen, nichtsdestotrotz komme ich prima mit meinem Wolf zurecht und weiß auch um Unterstützung in der Forengemeinde, weshalb ich ihn durchaus weiterempfehlen kann (natürlich mit Hinweis darauf, dass noch nicht alles enthalten ist was theoretisch schon hätte released sein sollen)

Grüße
Philipp

Ps: sry für den langen Text, es kam einfach aus mir heraus

[Dragonos2000]

Gast1961 Danke für die Erläuterung Volker, verstanden was Du meinst. Göran hat's ja schon geschrieben: Ist aktuell nicht implementiert oder zumindest nicht offengelegt.