WERBUNG: Erfahrungsbericht Timberwolf Server 950Q

[StefanW]

Hallo Pierre,

Setzen nicht mittlerweile alle auf 64-bit wegen der Zukunftsfähigkeit?

Nein. Im KNX Bereich (die Geräte) sind 8 oder 16 Bit üblich. Normale Appliances, Smarthome-Hubs usw. sind in 16 oder 32 Bit ausgeführt. Das ist in dem Bereich völlig ausreichend, da im Smarthome Bereich eher langsame Protokolle verwendet werden.

2038 ist doch Schluss, oder hab ich da was falsch verstanden?

Nein. Da läuft die Unix-Time über, sofern diese als 32 Bit Ganzzahl im Programm definiert ist. In modernen Betriebssystemen wird diese als 64 Bit Ganzzahl implementiert und diese kann auf jedem Rechner gerechnet werden.


Hinsichtlich der 32 vs 64 Bit geht es eigentlich ansich um den adressierbaren Hauptspeicher. Bei 32 Bit können 4 GB adressiert werden. Wenn man diese nicht nutzt, dann benötigt man auch keine CPU die mehr RAM adressieren kann. Mit der Leistungsfähigkeit hat es direkt nichts zu tun, allerdings sind 64 Bit Prozessoren meist moderner.


BTW: Unsere 32-Bit Prozessor rechnet intern mit 64 Bit Registern.

lg

Stefan

[Dragonos2000]

[...]da hilft auch kein Vergleich mit zugegeben schwachbrüstigen KNX-Servern anderer Anbieter, aber die wollen auch nur das sein, ein KNX-Server.

Hab' ich was verpasst? Was will der TWS anderes sein, als ein KNX-Server?

[danik]

Super Beispiel, läuft das denn auf dem Timberwolf mit der ausgelieferten Software? Auch dein Kosten-Thema: Wenn schon alles so teuer ist (KNX) kann auch der Server was kosten, egal was er kann?!

Nein, war ja auch nur ein Beispiel (und wohl gerade das falsche, da ja Hue auch wo erwähnt ist im Katalog). Kosten: Wie gesagt, für mich stimmt die Kosten-/Nutzenbetrachtung.

[crewo]

Die in allen PCs verwendeten Prozessoren, selbst der modernste Core i9, basiert auf der Architektur AMD64. Und die ist von 2003.

Ja, und die basieren sogar auf der x86-Generation von 1978 - wäre das nicht eindrucksvoller gewesen?

Wie schon mehrfach erwähnt, sind unsere Modelle außerordentlich leistungsfähig. Die gleiche ARM Cortex A9 Prozessorfamilie wurde von Apple im iPad 2 verbaut, dort jedoch nur mit zwei Kernen und 512 MB RAM. Im Timberwolf Server haben wir jedoch vier Kerne und 2 GB RAM. Wir bieten also eine beträchtliche Performance auf, die es auch - insbesondere durch die Multiprozessoren - es erlaubt, diese vielen tollen Leistungsmerkmale auch in beachtlicher Geschwindigkeit zu bedienen.

Und genau diese CPU-Generation, dieser Typ ist halt nunmal alt. In CPU-Zeit sogar steinalt. Niemand würde meckern, würdest du nicht ständig schreiben das alles überdimensioniert ist, da hilft auch kein Vergleich mit zugegeben schwachbrüstigen KNX-Servern anderer Anbieter, aber die wollen auch nur das sein, ein einfacher KNX-Server. Wenigstens können die eine eigene Visu darstellen.

[StefanW]

Hallo Volker,

kennst Du den:

Der Kreml organisiert ein Wettrennen zwischen Breschnew und Nixon. Nixon erreichte die Ziellinie als erster, Breschnew wird Zweiter. Am nächsten Morgen meldet die Nachrichtenagentur Tass: "Gestern fand im Kreml ein Wettrennen statt. Der Genosse Breschnew wurde Zweiter, Nixon Vorletzter."

Aber wenn du darauf bestehst ... Die CPU eurer Hutschienen-Server ist ein Cortex A9, das ist so ziemlich die älteste ARM-Architektur überhaupt.

Ja genau.

Es gibt derzeit acht (8) ARM Architekturen. Von v1 bis v8. Der von uns verbaute ARM Cortex A9 ist Architektur ARMv7, also die zweitaktuellste ARM Architektur. Mithin absolut State-of-the-Art und auch die verbreitetste Architektur. Die "älteste ARM-Architektur überhaupt" wäre ARMv1 von 1985.

Ja, die Architektur ARMv7 ist von 2004. Und weiter? Die in allen PCs verwendeten Prozessoren, selbst der modernste Core i9, basiert auf der Architektur AMD64. Und die ist von 2003. Die Architektur sagt lediglich etwas über den Befehlssatz aus.


Der Prozessor der im am meisten verkauften Smarthome Server verbaut ist ein AT91SAM9G20. Das ist Architekur ARMv5.

Die Unterschiede liegen in anderen Details, Pipeline-Länge, Branch-Prediction, Caches und Anbindungsbreite, Co-Prozessor, Scalar vs. Superscalar, Stromverbrauch. Es entscheidet, was am Ende raus kommt.

Diesen granatenmässigen 32-bit Superprozessor habt ihr verbaut. Total eindrucksvoll.

Jep. Wir schätzen den Unterschied in der Leistung zwischen dem meistverkauften Smarthome Server und dem TWS 950Q auf den Faktor 80.

Ich behaupte, dass wir den leistungsfähigsten Server im REG Gehäuse auf dem Markt haben.


Stefan

[crewo]

Habe zum Bsp. mit EDOMI meine HUE's auch nicht stabil ans laufen bekommen, trotz vorhandenen Bausteinen.

Super Beispiel, läuft das denn auf dem Timberwolf mit der ausgelieferten Software? Auch dein Kosten-Thema: Wenn schon alles so teuer ist (KNX) kann auch der Server was kosten, egal was er kann?!

[danik]

Realitätscheck: Nun scheitern im ersten Jahr nach Auslieferung die Hutschienen-TWS am aktuellen Edomi 2, weil sie keine moderne 64bit-Architektur bieten.

Mir persönlich (als Besitzer eines solchen Gerätes) würde es nicht in den Sinn kommen, auf dem TWS in Docker eine zweite vollständige Hausautomationslösung laufen zu lassen. Wenn ich Edomi, IP-Symcon oder sonst was will lasse ich dies doch sonstwo laufen. Mir zumindest war die 32Bit durchaus bewusst und klar. Ich für mich will ja auch ein System, das möglichst viel meiner Anforderungen Out of the Box bietet (und der TWS deckt schon das meiste ab, und ich bin auch überzeugt dass das für mich fehlende bald verfügbar sein wird), und dann las ich doch das System laufen und gut ist. Und wenn der Hersteller dies supported läuft dies auch in 10 oder 15 Jahren noch, auch mit 32Bit. Ich kann mir nicht vorstellen, das jemand der sich ein Homeserver, ein EIB-Port oder sonst eine Lösung kauft, über solche Sachen Gedanken macht (welche CPU habe ich, läuft diese noch in 10 Jahren). Aber es war wichtig für mich, dass der TWS genügend Reserven hat (was die TWS zweifellos haben), aber wichtig ist ja auch die SW und die Konfiguration des Gesamtsystems. Mit einem eigenen System (SW und HW) kann man dies ideal optimieren, in dem z.B. nur das notwendige im Kernel ist. Aber das Reaktionen auf die vielen Aufzählungen (und immer wieder Hervorhebung der Leistung) von Stefan kommen ist klar.

Habe zum Bsp. mit EDOMI meine HUE's auch nicht stabil ans laufen bekommen, trotz vorhandenen Bausteinen. Bin dann für diesen Teil halt auf Node Red ausgewichen. Es gibt halt wohl 2 Ansätze: sich in der HW-Beschränken die man ansteuern will, oder sich mit verschiedenen SW-Systemen auseinandersetzen. Und da finde ich dann Docker wieder gut, wo z.B. für spezielle Ansteuerungen Programme laufen können. Und wenn ich als Kunde viele solcher "fremder" SW in Docker laufen lassen will, sollte mir bewusst sein, dass ich auf ein TWS Desktop-Modell setzen muss (kommt meines Wissens auch aus dem Katalog hervor).

Noch mein Senf zum Preis und zum Care: Mit einer KNX-Installation fallen doch recht hohe Kosten an. In der CH kosten z.B. die Feller-KNX-Taster gegen CHF 350.- (wohlgemerkt, ein Taster, und bin mir auch bewusst dass es in DE andere mit CH-Rahmen gibt). Wenn ich all die Geräte die ich habe zusammenrechen bin ich wohl locker bei einem 5-stelligen Betrag (und jemand der sich KNX im ganze Haus machen lässt sicher einiges höher). Da sind für mich die Kosten (Kauf Gerät + abgeschlossener Care, den ich als Anfangsinvestition angesehen habe) doch völlig ok und im Verhältnis (und ggf. später auch mal eine jährliche Gebühr von 10 - 20% des Gerätepreises). Aber klar, jeder hat da andere Vorstellungen. Wenn ich ein Gerät eines anderen Herstellers nehme oder Edomi verwende, weiss ich auch nicht was in einem Jahr ist.

Gruss
Dani

[bkr]

Folgende Ideen:

A: Alle Updates & Upgrades sind die ersten beiden Jahre nach dem Kauf immer frei enthalten - ohne separaten Vertrag. Danach hat der Kunde die freie Wahl, ob er weitere Updates / Upgrades möchte und kauft diese einzeln oder als laufende Lieferung.

B: Alle Updates sind ewig frei, funktionale Upgrades (also Unterstützung für Protokoll X, Y, Z kann man einzeln kaufen, wenn diese zur Verfügung stehen) Keine Vorauszahlung, kein Risiko.

C: Vertrauen zurückgewinnen durch eine bindende Implementierungsroadmap während des Care Zeitraums mit Geld zurück Garantie

[crewo]

Also mir fällt kein Anwendungsfall ein, bei dem ich DMX einer DALI oder nativen KNX-Steuerung vorziehen sollte. Selbst im hochwertigsten privaten Bauvorhaben nicht, ich wills ja nicht schnell blinken lassen, Farbverläufe synchron im ganzen Haus oder Timing-Korrekte Lichtblitze erzeugen. Oder ich kenn mich nicht genug aus, ich kenne DMX nur aus dem Bühnenbau. Und: Im privaten Umfeld ist doch auch die Auswahl an DALI-Leuchten begrenzt, DMX kommt einem noch seltener unter.

[ewfwd]

DMX braucht aber niemand im EFH, somit.

Würde ich so nicht sagen. Es mangelt da einfach bis dato eher an einem gescheiten gateway mit dem passenden funktionsumfang zu einem attraktiven Preis.
Vorallem wenn man wirklich sehr sehr viele LED Kanäle hat/haben will und wo man definitv alles per Hand, also KNX Taster bedienen will.
So ein Gateway was vielleicht sogar optional direkt KNX IP kann wäre durchaus nicht gänzlich uninteresant.
Dali ist bei den meisten Gateways soweit ich weiß auch nur eingeschränkt nutzbar in der farbsteuerung außerhalb der 16 Dali Gruppen.
Wobei die meisten dann wohl eher ein dediziertes Gerät dafür haben wollen würden eher weniger "etwas" was DMX dann nebenbei kann.

[crewo]

lidl sehr gut auf den Punkt gebracht!

[crewo]

Eigentlich wollte ich nichts mehr hinzufügen, aber Stefan schafft es mit ständiger Wiederholung immer der gleichen - mit Verlaub - nicht ganz nachvollziehbaren Argumenten, einen doch immer wieder zu "nötigen".

und ich weiss nach 10 Seiten im im Thread noch immer nicht was der Server aktuell besser kann als der HS oder der Peaknx mit Youvi, viell. ändert sich das in der Zukunft noch wenn weitere Updates kommen aber aktuell hab ich das Gefühl ich kaufe Hardware die spitze ist aber wo es nichts gibt was die Hardware sinnvoll nutzen kann

Hätte ich nicht besser zusammenfassen können - ich nämlich auch nicht. Ich finde es bezeichnend, dass es der Hersteller selbst nicht schafft, die Vorteile seiner Lösungen so zu präsentieren, dass diese auch erkannt werden und den Preis und die Dauerschleife an Eigenlobhudelei als gerechtfertigt erscheinen lassen. Unter diesem Aspekt finde ich die Entscheidung, immer weiter in die Entwicklung statt in Marketing zu investieren, als definitiv falsch. Denn was nützt das beste Produkt, wenn es niemand erkennt, damit nicht kauft und die wenigen die es erkannt haben bald keinen Support mehr haben, weil der Hersteller das Produkt eingestellt hat oder insolvent (...) geht.

Oder: Es gibt einfach keine freien Ressourcen, die sich um solche Themen kümmern, ebenso wie das auf Entwicklerseite vermutlich knapp ist, wenn man sich das Entwicklungstempo ansieht.

StefanW : Da du ja recht offen bist im Umgang mit Zahlen, wieviele Server habt ihr denn bisher verkauft ohne die Einführungsaktion? Ungefähr...

Für einen Maker wie Dich ist so ein "all inclusive" System wie der Timberwolf Server nicht gedacht. Deshalb macht vieles was den Wolf für andere Kundenschichten auszeichnet für Dich absolut keinen Sinn. Das verstehe und akzeptiere ich.

Das ist nett geschrieben, danke. Aber ich bin das wirklich nicht! Ich kenne mich auch mit Linux nicht gut aus. Grafana läuft bei mir als Docker-Image einfach auf der Synology NAS und edomi nach Step-für-Step-Anleitung auf dem APU. Lediglich um die Netzwerksicherheit kümmere ich mich, was aber jeder machen sollte.

Aber wenn du darauf bestehst ... Die CPU eurer Hutschienen-Server ist ein Cortex A9, das ist so ziemlich die älteste ARM-Architektur überhaupt. Eine 32-bit (!) Prozessorarchitektur von 2007, als Quadcore seit 2012 auf dem Markt.

Auch das erspart mir das selbst tippen, kann ich nur zustimmen!

Um das mal Zusammenzufassen:

Die CPUs mir bekannter TWS sind allesamt keinesfalls "granatenmäßig überdimensioniert" wie hier gebetsmühlenartig immer wieder erwähnt, der A9 sowieso (bitte nehmt mal ein iPad 2 zur Hand und nutzt darauf mal paar moderne Applikationen, das fühlt sich wie vor 20 Jahren an, ich möchte kein iPad 2 als Server!) und die CPU des APU (ich nehme an es ist die Version mit GX-412TC mit 1 Ghz) ist auch nicht mehr die jüngste, ich finde die zwar aktuell noch ok, aber in 10 Jahren will ich die nicht mehr haben. Moderne Webanwendungen und die doch recht intensive Datenbanknutzung von Grafana usw. sind schon Applikationen, die eine schnelle CPU durchaus begrüßen. Ebenso ist jeder Docker-Container eine weitere Belastung, hier vermute ich vor allem beim RAM der angebotenen Server schnell eine harte Grenze. Bitte denkt daran, was vor 10 Jahren war und wie die Webanwendungen heute aussehen! Auch der Anspruch an KNX-Server wird weiter steigen und es gibt schon jetzt sehr interessante Tools und Anwendungen, welche nicht mehr zufriedenstellend auf dieser Hardware laufen werden.

Und noch einmal wegen dem Vergleich mit anderen Visu-Systemen:

Jemand hat hier geschrieben, dass der Vergleich TWS und edomi hinkt, ja logisch macht er das! Das hatte ich ja auch mehrfach geschrieben. Das eine ist Software, das andere eine Komplettlösung (TWS). Aber nehme ich edomi und Grafana und einen APU, dann kann ich doch vergleichen! Da habe ich mit den vielen LBS und den großartigem Funktionsumfang von Logik-Editor und Visu eine sogar wesentlich mächtigere Lösung und das schon jetzt mit edomi - sofort - ohne Update-Abo (ja, es ist ein ein ABO, da kann man die Definition noch so oft verdrehen!).

Abschließend bleibt für mich aktuell nur die vielzahl der Schnittstellen, DMX braucht aber niemand im EFH, somit... leider weiter nichts was für den TWS spricht.

[lidl]

Ich habe die Geschichte des TWS ja auch damals im Herstellerforum mitverfolgt.

Die alte Produktpalette war ja jetzt nicht wegen Ihrer technischen Meisterleistung eine Erfolgsgeschichte, sondern viel eher, weil sie eine Marktnische bediente.

Mit dem TWS wollte Stefan eine technisch einwandfreie, solide und saubere Lösung schaffen. Anforderungsanalyse, Spezifikation, Architektur sollten professionell behandelt werden. Da hat man bei ElabNet aber komplett neues Terrain betreten. Theoretisch geht das ja... man besorgt sich "The Big Blue Book" (Domain-Driven Design by Eric Evans) und "Red Book" (Implementing Domain-Driven Design by Vaughn Vemon) und fährt sofort Erfolge ein. Erstmals geht es strukturiert zu, es wird zuerst geplant, man überblickt das gesamte Projekt. Der Überblick lässt das Projekt kleiner erscheinen, was dann zum Verhängnis wird - weil "es ist ja alles nicht so viel Arbeit, wir sind bald fertig, der Großteil ist schon fertig..." ... Ja, theoretisch, aber implementiert muss es dann ja doch noch werden und dort kann es dann eben doch auch noch Rückschläge geben.
Für mich ist obiges eine Erklärung für die Entwicklungsgeschichte des TWS. Man hat die Entwicklung auf neue Beine gestellt, das Team teilweise ausgetauscht und da eben typische Fehler begangen.

Ich gehe jetzt mal davon aus, dass die Architektur sauber ist. Nur gibt es jetzt halt (noch immer) "Herausforderungen" anderer Sorte.

• Ihr wollt mit einem Produkt die Eierlegenden Wollmichsau erschaffen. Etwas das alles kann, qualitativ auf höchster Stufe, mit bestem Support. Glaubt Ihr wirklich, dass ihr das als Unternehmen eurer Größe gestemmt bekommt? Ihr habt nicht unendlich Zeit, nicht nur wegen eurer Kunden, sondern auch wegen der Technik die sich weiterentwickelt. Bis ihr alle Schnittstellen umgesetzt habt, kann es gut sein, dass das Protokoll auf der ein oder anderen Schnittstelle bereits wieder veraltet ist. Sowas muss auch alles zeitgerecht gewartet und weiterentwickelt werden. Auch von der Kostenseite stelle ich mir das durchaus sportlich vor, da ihr im Vergleich zur Konkurrenz, nicht gerade viele Kunden habt die davon einen Nutzen haben und dafür zahlen werden.
• Ihr bedient jetzt nicht mehr ganz alleine eine kleine Marktnische, sondern Konkurriert mit Unternehmen die zig mal mehr Kapital und Resourcen zur Verfügung haben.
• Die Kaufentscheidung für so ein Produkt ist sicherlich der Funktionsumfang, der Support und der Preis. Für jeden der nur ein klein wenig weiter denkt, steht aber Vertrauen an erster Stelle. Denn ich habe nichts von der besten Architektur, wenn ich nicht weiß ob der Support weiterhin gewährleistet ist, bzw. noch schlimmer ob es das Unternehmen übermorgen überhaupt noch gibt. Zum Vergleich: Wir hatten mal eine Individualentwicklung einem der 4 großen Pharmakonzerne angeboten. Beim Meeting vor Ort ging es 0 um den Funktionsumfang, nicht ums technische und auch nicht ums Budget. Man geht davon aus, dass das passt. Es ging einzig und allein darum, welche Rechtsform unser Unternehmen hat, wieviele Mitarbeiter, Standort usw... (Und nein, wir sind nicht gänzlich unbekannt, unsere Visitenkarten sind mit Logos von Sybase und SAP geschmückt .)
  Nicht nur dass ihr da als kleines Unternehmen ohnehin schon schlechtere Karten habt... Sorry Stefan, ich glaube du hast in der Vergangenheit alles erdenkliche getan um dein Vertrauen komplett zu verspielen. Die ewigen Versprechungen, das ewige und lange "Gutreden"... alles ist so gut, so toll so perfekt und überhaupt... "Ja ich weiß in der Vergangenheit sind Fehler passiert, aber jetzt ist alles noch viel besser". Sogar die Insolvenz war ja laut dir eine super Sache (Weil unter Eigenverwaltung) und "mit dem schlimmsten Punkt sind wir schon wieder über den Berg"... Es ist halt immer das Selbe, immer das Selbe Verhalten, die Selben Floskeln...
  Ich verstehe dich ja auch irgendwo, was sollst du denn auch anderes schreiben. du glaubst es ja sicher auch.

Eins gebe ich aber auch gerne zu: Ich bewundere (nicht beneide!) dich für dein Durchhaltevermögen und deinen Kampfgeist. Mir als Kunden bringt das aber im Endeffekt halt genau nichts.

[vento66]

Realitätscheck: Nun scheitern im ersten Jahr nach Auslieferung die Hutschienen-TWS am aktuellen Edomi 2, weil sie keine moderne 64bit-Architektur bieten.

Wird ja keiner gezwungen so ein neumodisches Zeugs einzusetzen
Aber ja, da bin ich voll bei dir. Man sollte vielleicht doch mal in den Kalender schauen....

[Gast1961]

Setzen nicht mittlerweile alle auf 64-bit wegen der Zukunftsfähigkeit?

Ja, aber eben nicht beim Hutschienen-Timberwolf mit seiner angestaubten 32-bit CPU.

StefanW hatte hier im Thread eine Nutzungsdauer von 10-15 Jahren ausgerufen, wegen der so granatenmässig leistungsstarken und zukunftssicheren Hardware.

Realitätscheck: Nun scheitern im ersten Jahr nach Auslieferung die Hutschienen-TWS am aktuellen Edomi 2, weil sie keine moderne 64bit-Architektur bieten.
Realitätscheck: Auf einem billigen Raspberry würde es laufen, der hat bereits 64-bit und auch sonst eine modernere CPU-Architektur und mehr CPU-Leistung.

Das Problem ist, daß man bei den sich schnell ändernden Protokollen die Software aktuell halten muss. Und der TWS setzt stark auf fremde Software im Docker-Image. Daß man da noch mehr als ein Jahrzehnt mit aktueller Software versorgt werden wird, die auf 32-bit Systemen laufen wird, halte ich für fraglich. Den ersten Problemfall sehen wir bereits - im ersten Jahr nach Erscheinen des Gerätes.