WERBUNG: Erfahrungsbericht Timberwolf Server 950Q

[StefanW]

Hallo Volker,

Mein Kritik ist sicherlich dadurch beeinflusst, daß die sichtbare Eigenleistung des "Herstellers" dürftig ausfällt und das Gesamtpaket weit hinter dem zurücksteht, was in den schönen bunten Prospekten beschrieben ist.

Es ist recht offenkundig, dass Du den Server gar nicht kennst. KEIN Kunde, niemand der den Server wirklich kennt würde auch nur ansatzweise von "dürftiger Eigenleistung" sprechen. Wir haben 25 bis 30 Mannjahre und drei Millionen Euro in die Entwicklung gesteckt. Das ist nicht dürftig.

Wir haben einen Plan vorgelegt, wie wir uns die Entwicklung des Servers vorstellen. Dann haben uns unsere Kunden gesagt, dass sie einen anderen Zuschnitt wünschen und diese und jenen Funktionen - die so nie geplant waren - vorgezogen werden sollen. Was sollten wir machen? Uns stur an unseren Plan halten oder den Wünschen der Kunden nachkommen?

Wir haben uns für die Kunden entschieden und haben deren Wünsche in unseren Plan integriert. Damit wurden viele Funktionen im Detail realisiert die gewünscht waren, dafür andere nach hinten geschoben. Das ist normal für eine agile Entwicklung, die Kundschaft bestimmt letztlich den Weg.

Außenstehende mögen sich daran mokieren, unsere Kunden sind mit der Vorgehensweise überwiegend glücklich. Das ist was zählt.

Das Problem bei den fremden Komponenten ist, daß man als Serverhersteller über deren Zukunft keine Kontrolle hat.

Nein, aber wir haben uns die Source-Codes gesichert und kompilieren bei Bedarf selbst. Wir liefern über eigene Repositories aus, nichts wird vom Hersteller geladen.

Damit haben wir uns so unabhängig wie nur möglich gemacht.

Die Dauerbaustelle TWS muß erst noch zeigen, daß sie irgendwann dahin kommt.

Es gibt keine Dauerbaustelle. Die Software wurde nach langem Beta-Test (so wie sich das gehört) in der Hauptversion V 1.5 veröffentlicht.

Künftige Releases werden ebenfalls einem Beta-Test unterzogen und erst freigegeben, wenn es keinen bekannten Fehler mehr gibt. Das haben wir beim Wiregate Server ab PL38 schon so gemacht und das hat sich bewährt.

Ja, gutes Beispiel. Die als Feature schon lange versprochene Visu fehlt weiterhin.

Im Katalog stellen wir auf den Seiten 214 bis 222 das vor, was wir als Visualisierung anbieten:

1. Zeitserien und grafische Darstellung (Seite 216 / 217)
2. CometVisu (Seite 218 / 219)
3. Visualisierung mit Grafana (Seite 220 bis 222)

==> Alles das was dort ausführlich erläutert ist, wurde ausgeliefert und funktioniert.

Darüber hinaus kann man die Visu von OpenHAB und EDOMI auf dem Timberwolf Server nutzen. In unserer Knowlege Base gibt es Anleitungen zur Installation.

Die 4. geplante Visu, die Instant Visu haben wir zugunsten anderer Themen nach hinten geschoben.

Aber wen kümmern bei einem kommerziellen Produkt schon die beworbenen Features, wenn man als Workaround auf eine Uralte Freeware verweisen kann.

Bitte was ist Uralt?

• Die im TWS installierte Version der CometVisu ist die Version 0.11 vom März 2019
• Die im TWS installierte Version von Grafana ist die Version 6.4.4 vom 6. November 2019

Sorry Volker, ich will Dich ja gerne erst nehmen und mit Dir Diskutieren, aber ein bisschen fundierter darf die Gesprächsgrundlage schon sein.

Der Unterschied zum TWS ist dann, daß das Gesamtpaket dort bereits fertig ist und keine Baustelle mit ungewissem Zeitplan und ungewissem Ausgang.

Wie gesagt. Keine Baustelle. Die Software ist released und hat einen respektablen Funktionsumfang. Verspätet, aber dafür besser geworden als geplant. Die Kunden sind sehr zufrieden damit. Fragt Sie einfach.

lg

Stefan

[lidl]

Das könnt ihr doch gar nicht beurteilen. Die Hardware für eine DMX-Schnittstelle kostet so gut wie nix. Das Gleiche gilt sicher für die anderen Schnittstellen.
Die Kosten kommen aus der Software und dem Support.

Jeder mit etwas technischem Verständnis und Erfahrung weiß, dass mehr Funktionalität mehr Aufwand und damit höheren Ressourcen und Kostenaufwand bedeutet. Und zwar nicht nur in der initialen Entwicklung sondern über den kompletten Lebenszyklus. Und ja, auch wenn meinentwegen die Hardware kostenlos auf der Platine wächst, die SW-Entwicklung, wie du selbst auch zugibst, verursacht kosten, welche über die Subscription bezahlt wird.

Das Geschäftsmodell ma funktionieren, für mich ist das nichts.

[StefanW]

Liebe Foristen,

ich bitte um Geduld, falls ich den Faden etwas zerreiße, weil ich noch auf Beiträge antworte, die zwei Seiten zurückliegen, aber es wäre unhöflich, nicht darauf einzugehen.


Hallo Volker,

Verstanden, aber so ein Logikblatt wo K1003 mit K1234 verodert wird und K6789 herauskommt ist eben nicht sehr übersichtlich. Ich möchte sagen, da blickt ziemlich schnell niemand mehr durch.

So schlimm ist es bei uns nicht, das kann man auf den statischen Screenshots nur nicht gut erkennen.

1. Objekte sind frei benennbar (bis auf KNX Objekte): Die Logik kann mit allen Objekten aller Bussysteme verknüpft werden. Also ein Eingang von KNX, einer 1-Wire usw. Ausgänge ebenfalls. Bis auf KNX kann man im Timberwolf Server alle Objekte anderer Systeme frei uns selbst benennen.
   Bei KNX werden die Objekte durch von der ETS durchnummeriert, hier würde es ein Durcheinander geben, wenn wir eine freie Benennung der KNX_Objekte erlauben würden, daher ist es dort gesperrt.
2. Anzeige aller Infos auf Klick: Mit Klick auf die verknüpften Objekte am Ein- oder Ausgang öffnet sich ein Dialog mit vielen weitere Informationen zum Objekt.

Deine Kritik ist aber berechtigt, das kann man besser machen. Daher gibt es auch seit gestern einen Feature Request dazu. Der beinhaltet folgendes:

• Die Zusatzinformationen (bei KNX:welche GAs verknüpft und DPT, Bezeichnung, Beschreibung, Einheit, letzter Wert mit Uhrzeit) soll als Mouse-Over zur Verfügung gestellt werden, das spart den Klick (Tablett- und Smartphone User müssen dann eben tippen)
• Wir fügen im Logikeditor die Option "GA anzeigen" hinzu, dann werden - bei KNX-Objekten - anstatt der Objektnummern die GAs angezeigt. Damit kann man die Anzeige auch hin- und her-toggeln.

Der betreffende FR wurde auf Basis Deiner Kritik erstellt und befindet sich hier: https://forum.timberwolf.io/viewtopic.php?f=9&t=1813

Das in die ETS zurückschreiben zu können - wahlweise - ist sicherlich fein. Mit Blick auf die Performanceproblem eurer Lösung sollte der Anwender mMn aber die Wahl haben. Viele Objekte ("Weltrekord") sieht gut aus für die Werbung, aber was nutzt das wenn der Anwender darunter leidet, weil es die ETS ausbremst?

Anmerkung: Das ist Geschichte. Die Performance-Probleme bei der Applikation mit den 2000 Universalobjekten wurden von der KNXA mit Version 5.7.3 fast vollständig beseitigt.

Wir gehen davon aus, dass mit einer der nächsten ETS Versionen auch die angestrebte Applikation mit den 8000 Universalobjekten ohne Probleme genutzt werden kann. Die KNXA hat uns hierzu einen "Turbo" versprochen. Der wird auch sicher eintreten. Die bisherige Applikation nach alter Programmierweise ist mit den 2.000 Objekten ganze 6 MByte groß. Eine Applikation mit den gleichen 2000 Objekten als "modulare Applikation" ("MAP") mit MT 5.7.4 erzeugt hat dann nur noch 95 kByte. Eine mit 8000 Objekten wird vermutlich nur wenige KB größer sein. Nur die ETS 5.7.3 verschluckt sich hier noch. Ich bin überzeugt, dass die KNXA auch das in ordnung bringen wird.

Es geht natürlich auch ohne Flags. Bei meinem IP-Symcon-Server (ohne ETS-Applikation) lege ich einfach per Häkchen zu jeder GA fest, ob Leseanfragen beantwortet werden oder nicht. Und auch mit dem X1 hatte ich bei diesem Thema noch nie ein Problem. Nicht eines. Niemals.

Ich empfinde es als Inkonsistent, wenn mit der ETS dies FLAGs für die Objekte vergeben werden und bei denjenigen Servern, welche auf GA Basis arbeiten, muss man das dort separat und manuell einrichten. Ich finde, dass dies unübersichtlich ist und damit solche wichtigen Informationen nicht mehr im Projektile sind. Server wie dem TWS, die Informationen aus dem KNX Projekt auslesen und diese für Diagnose und Übersicht darstellen haben somit keine Kenntnis, was in anderen "GA-Engines" hinsichtlich der Flags eingestellt wurde.

Ich finde es bemerkenswert, dass der KNX Standard auf der einen Seite so hochgehalten wird und andererseits das Umgehen des KNX Objektkonzeptes so kritiklos hingenommen wird.

Mir scheint, ihr habt da im TWS ein hausgemachtes Problem, wenn der beim Start Leseanfragen falsch beantwortet.

Nein. Wir haben kein Problem. Der TWS arbeitet auf Basis der mit der ETS angelegten Objekte nebst deren Flags einwandfrei.

Ich meinte nur, dass ich gegen eine Hybridlösung bin, mit der parallel auch auf GA BAsis gearbeitet werden kann, weil es dafür keinen Standard gibt, wie die Server nun mit den GAs (z.B. bei Leseanfragen) verfahren sollen. Du sagst, der IPS kann Flags drauf geben (das ist gut so), aber wie macht es der X1? Und wie der Server X? Y? Z?

Ich wollte damit ausdrücken, dass ich dem Verwässern des KNX Standards durch Nutzung von GAs in Servern anstatt dem im Standard vorgegebenen Objektsystem kritisch gegenüberstehe. Aber jeder kann in seiner Installation machen, was er möchte.

Der Doktor-Modus und selektiver Start einzelner Logiken sieht spannend aus.

Ja, das ist es auch.

Ich habe einen Kunden mit HS dazu gefragt "Wie würdest Du den zeitlichen Vorteil pro Änderung bewerten. Also in-situ ohne Übertragung und Neustart gegenüber dem beim HS notwendigen Verfahren?"

Seine Antwort:

Das habe ich heute getestet. Ich habe heute auf der Visu die Textanzeige von Sonnenauf- und Untergangszeit hinzugefügt.

1. Logik aus den Standardlogikbausteinen "Sonnenstand", "Zeitformat", "Text trennen" erstellen - 5 Minuten
2. Hochladen und Neustart des QC - 4 Minuten
3. Kontrolle der Anzeige. Sonnenaufgang wird im QC als "Sonne..." angezeigt. Änderung zu Sonne ↓↑.
4. Hochladen und Neustart des QC - 4 Minuten
5. Kontrolle der Anzeige. Passt.
6. ETS5 aufrufen und Rückmeldungen und Messwerte auslesen (da es, bedingt durch die Sendezeiten der KO manchmal Tage dauert, bis alle Werte wieder aktuell sind) - 3 Minuten.

Summe 4+4+3 = 11 Minuten Wartezeit mehr als im TWS - vorausgesetzt, dass die Logik dort auch sofort funktioniert und auch das leistet

Der ganze Beitrag: https://forum.timberwolf.io/viewtopi...p=13462#p13462

Ob das genauso so stimmt weiß ich nicht, aber das Ausführen einer Logik binnes eines Augenblinzelns durch Klick auf Speichern und ohne Beeinflussung anderer Logiken finden unsere Kunden ein tolles Leistungsmerkmal im TWS.

Dennoch: Was ich beim TWS nicht verstehe ist, daß die Käufer so ein teures Gerät akzeptieren, wo wesentliche Server-Bestandteile mit fremder Freeware gelöst sind. Visu, Datenbank, Diagramme ... alles fremde Freeware

Wir haben geschätzt zwischen 25 und 30 Mannjahre und ca. 3 Millionen Euro in die Entwicklung des Timberwolf Servers gesteckt. Das ist etwa 15 fach umfangreicher als beim WireGate Server.

Selbstverständlich verwenden wir gute freie Software. Genau deshalb wird diese ja von der weltweiten Community zur Verfügung stellt. Man soll diese Verwenden um damit großartige Produkte zu schaffen, die ohne diese freie Software nicht möglich wäre. Wenn die Server der Mitbewerber auch nur annähernd die Leistung unserer Server hätten, dann liefe solche Software auch sicher dort.

Selbstverständlich haben wir nicht weitere 100.000 Mannjahre Arbeit in Kernel und Betriebssystem gesteckt, weil es diesen getestet und geprüft und stabil zum Download gibt. Trotzdem haben wir mit einem viertel Mannjahr Aufwand den Kernel beim Hutschienenmodell auf die Hardware anpassen müssen. Das gleiche gilt für die Integration der verwendeten Datenbanken usw. Würden wir die gesamte Software des Timberwolf Servers komplett selbst geschrieben haben, hätten wir wohl eine Milliarde Euro ausgeben müssen und würden in 30 Jahren fertig werden.

Uns Vorzuwerfen, dass wir gute freie (und vor allem ausgetestete) Software einsetzen, die für solche Zwecke veröffentlicht wurde, kann ich echt nicht nachvollziehen.

Gerade der Einsatz dieser grandiosen Softwaremodule macht den Server so leistungsstark. Damit realisieren wir Leistungsmerkmale die auf anderen Systeme gar nicht möglich sind, weil niemand die Entwicklung solcher Module ansonsten bezahlen würde. Wir integrieren diese zum Nutzen der Kunden. Das geht auch nur, weil wir so eine starke Hardwarebasis haben.

Neben der Integrationsarbeit haben wir hunderte von Modulen geschrieben. Die wesentlichen sind

• Benutzeroberfläche mit 31 zum teils recht komplexen Editoren und Anzeigen, sowie die dazugehörige Middleware
• Der zertifizierte KNX Stack für 8000 Universalobjekte und 16.000 GA-Assoziation
• 1-Wire Scheduler sowie das 1-Wire Plug´n´Play System
• Zentraler Dispatcher, welche von allen Subsystemen die Objekte verwaltet und deren Verknüpfung ausführt. Es ist das Kernstück des Objektsystemes
• Die Logik-Engine mit Persistenz und Simulation der voneinander separat instanzierten Logikzellen
• Logging und Busmonitor, Verwaltung der Zeitserien

und alles mögliche Sonstige läuft irgendwo im Docker um dem Gesamtsystem überhaupt zur Funktion zu verhelfen.

Nein. Out of the Box läut da gar nichts von der Timberwolf Server in einem Docker Container. Wir haben da ein sehr sauber aufgebautes System.

Wir bieten dem Kunden an, die Möglichkeiten des Servers nach belieben zu erweitern. Dafür können Sie eigene Docker Container installieren oder aus den einer kleinen Auswahl sich diese auswählen. Wir nennen letzteres APPs und es funktioniert genauso einfach wie bei einem Smartphone. Man klickt darauf und es wird installiert und inkl. aller Ports und auch dem Reverse-Proxy fertig eingerichtet.

Derzeit bieten wir folgende APPs an:

- ETS Inside (wird im System, nicht als Docker installiert)
- Die CometVisu. Hiervon können auch mehrere Instanzen gestartet werden
- Der WireGate Plugin Container, das nutzen unsere Kunden, um WireGate Plugin auf dem TWS laufen zu lassen

2019-12-27_APPs.jpg


lg

Stefan

[GLT]

Subscription -> bezahl für Dinge, die wir beim Verkauf zwar versprochen, aber nicht hinbekommen haben?

Aber bei der digitalen multiplen Sklerose rege ich mich über deren Arschschurenz noch mehr auf

[trollvottel]

Wäre das nicht der TWS 760q?

Den gibt es doch nur auf dem Papier.

Aktuell kann man sich auch gern einen TWS 350 kaufen, das die gleiche HW wie beim 950 es werden die Schnittstellen dann halt von der Software unterdrückt

Jaja aber für 1085€ plus Subscription? Nönö lass mal stecken.

[gbglace]

Ja die Importer-App ist was für die ETS-Pro. In der Inside ist es dann halt Handarbeit die KO des TWS mit GA usw. zu belegen. Der geneigte Hobby-KNX-ler hat da ja eher das notwendige Zeitbudget. Die Integratoren könne ja auch mit der Pro ein umfangreiches Projekt mit dem TWS synchronisieren und dann auch wieder das Inside-Projekt auf dem Kundenserver in Synch bringen, das ist wahrscheinlich effizienter für den Integrator / Elektriker.

[Gast1961]

fast, das hybride ist das man auch von Seiten des TWS eine Stack-Programmierung erreicht und das dann auch bis in das ETS-projekt exportiert bekommt. Weil es im Workflow manchmal einfach einfacher ist schnell mal im Server das Objekt mit GA anzulegen. Im Nachgang bringt man es dann noch in die ETS, eine GA die nur am TWS-KO hängt und aktiv sendend genutzt wird, macht ja nur bedingt Sinn.

Stimmt, die Rückführung der Objekte in die ETS wäre dann beim TWS eine Besonderheit.

Wie ist das eigentlich mit dieser Timberwolf Importer App - Stefan bewirbt so gerne die vorinstallierte ETS Inside, aber die kann doch AFAIk gar nicht mit ETS Apps umgehen?

[gbglace]

ein Hybridmodell, wie es nun auch für den TWS geplant ist.

fast, das hybride ist das man auch von Seiten des TWS eine Stack-Programmierung erreicht und das dann auch bis in das ETS-projekt exportiert bekommt. Weil es im Workflow manchmal einfach einfacher ist schnell mal im Server das Objekt mit GA anzulegen. Im Nachgang bringt man es dann noch in die ETS, eine GA die nur am TWS-KO hängt und aktiv sendend genutzt wird, macht ja nur bedingt Sinn.

[StefanW]

Hallo Matthias,

Fischvergleiche, mal was anderes. Liegt vielleicht am Weihnachtskarpfen. Und man merkt, das Auto verliert an Bedeutung.

Yeah, einer Deiner besten Beiträge, habe Tränen gelacht. Danke.

Ich denke allerdings, dass es mittelfristig nicht sinnvoll ist, wenn sich die Goldfischlein in ihrem Mini-Teich an den Flösslein fassen und hamonietrunken im Kreis schwimmen, sich für den mächtigsten Fisch und ihren Teich für den Ozean halten.

Eine schöne Metapher.

Wir haben - durchaus zurecht - in der Vergangenheit Prügel bekommen, haben uns zurückgezogen, an unserem Produkt gearbeitet und jetzt ist es Zeit zum Haifischbecken zurückzukehren und zu zeigen, was wir geschafft haben. Hier sind wir nun.

Sicher bekommen wir nun wieder Prügel. Nur zu. Für sachliche Kritik bin ich sehr empfänglich, weil wir wollen uns und das Produkt verbessern. Also lasst uns darüber reden und sagt mir was Ihr an Funktionen braucht und welche Ideen ihr immer schon umgesetzte haben wolltet. Ich höre sehr gerne zu und ich diskutiere das auch mit Euch.

Der Obergoldfisch weiß genau, dass er hinaus muss zu den Großen. Denn ohne eine breite Basis geht auch den Goldfischen schnell das Futter aus. Ich wünsche ihm und uns natürlich sehr, dass er auch hier Erfolg hat. Das wird nicht leicht, weil hier der Seewind rauher bläst. Hoffentlich wurde gelernt in der Zwischenzeit, da souveräner und weniger empfindlich zu reagieren, auch wenn es mal in der Schwanzflosse aka Wade zwickt.

Keine Sorge, der Obergoldfisch ist anpassungsfähig. Leicht habe ich es mir noch nie gemacht. Ich freue mich auf jede sachliche Diskussion.

Ich bitte um Fairness und Abwesenheit von Polemik - weil es uns nicht vorwärts bringt.

Persönliche Meinung: Ich habe den TWS in der jetzigen Form offensichtlich noch nicht verstanden, bzw. erkannt, ob das ein Lachs oder ein Stör ist. Liegt vielleicht daran, dass ich 1-wire im professionell errichteten Smarthome niemals einsetzen würde.

Es geht nicht (mehr) um 1-Wire!

Im Fokus unserer Geschäftstätigkeit steht KNX mit unseren TWS Servern (sowie Wartung & Support) dazu. Drei für die Zukunft geplante Servermodelle werden weder 1-Wire Interfaces inkludiert haben noch sind diese um 1-Wire erweiterbar.

Selbstverständlich wird 1-Wire weiterhin unterstützt, weiter entwickelt und im Verkauf sein, schließlich gibt es ca. 10.000 Smarthomes die damit ausgestattet sind (es funktioniert sehr viel besser als der Ruf hier ist, aber ich akzeptiere Deine und Eure Ablehnung).

Aber im Kern der Entwicklung und des Geschäftsmodelles steht der Timberwolf Server mit dem Fokus auf KNX.

Dann ist da eine nette Logikengine und ein paar Container für Dinge, die auch auf einem NAS laufen könnten. Kann mir einer in wenigen (!) Sätzen ohne Sepia-Tinte erklären, was den TWS jetzt (!) so einzigartig macht? Ich würde das wirklich gerne verstehen.

Jetzt: Der TWS ist ein KNX Server mit IP-Schnittstelle, ETS Inside, OpenVPN, Logging, grafische Analyse, Logik, Visu, Proxy und Security und unterstützt zudem DMX (und 1-Wire). Der Kunde kann die Funktionalität über Docker-Container erweitern. ES stehen sechs Basismodelle zur Verfügung (plus drei spezielle Versionen für Integratoren und drei für die Industrie). Alle Modelle sind lieferbar. Die Software ist freigegeben ("Hauptversion 1.5 - Razors Edge").

Besonderheit: Hohe Leistung, wenig Limitationen, gute Funktionalität, persistente Logik mit Live-Simulation, erweiterbare Architektur, sehr einfache Oberfläche, reine Browserbedienung, praktisch alles passiert in Echtzeit, hilfreiche Werkzeuge für die Analyse, eingebauter Backup-Flash, Top-Support, Erweiterbar mit APPs, Erweiterbar durch Kunden mit Containern, kontinuierliche Entwicklung mit Update auf Knopfdruck und vor allem die Beachtung vieler vieler Details.

Tatsächlich ist das "einzigartige" am TWS schwierig zu beschreiben. Mit fallen hundert Details ein, das bekomme ich in wenigen Sätzen nicht unter. Rückmeldungen der Kunden betonen die einfache Bedienung, die Detailvielfalt, den tollen Überblick den man über sein KNX System gewinnt, den intensiven Support sowie die rasche Umsetzung von Wünschen. Ein Integrator hat mir vor einem Monat gesagt: "Ich habe den TWS total unterschätzt, ich bin mehr als positiv überrascht, ihr seid allen anderen um Lichtjahre voraus".

Künftig: Der Server ist stark überdimensioniert, damit kann die Software umfangreich erweitert werden. Entsprechend werden wir Leistungsmerkmale ausbauen und die Unterstützung weiterer Bus-Systeme und Protokolle zur Verfügung stellen Ziel ist es, neben KNX viele weitere gängigen Bus-Systeme zu unterstützen und zwischen diesen zu übersetzen. Für denjenigen der das nicht benötigt, gibt es auch Server nur für KNX.


Für alle die ein wenig mehr Details lesen möchten:

1. KNX ist das primäre Bussystem, ETS Inside vorinstalliert
   Alle unsere Server unterstützen den Betrieb an KNX mit einem zertifizierten KNX Stack bis 8000 Universalobjekte. Bei allen (bis auf einem) ist ein KNX-TP Interface bereits eingebaut. Über dieses unterstützen wir zudem 25 gleichzeitige KNXnet/IP Tunnel. Die Konfiguration der (derzeit nutzbaren 2000) Universalobjekte erfolgt konform über die ETS. Universalobjekt bedeutet, dass für jedes Objekt der DPT definiert werden kann (diese sind also nicht durch die Applikation vorgegeben).
   Die ETS Inside (derzeit in Version 1.4) ist vorinstalliert und auf Knopfdruck bereit. Lizenz ist bei der KNXA zu beschaffen, Dongle dann am Server einstecken.
2. Einfache Integration weiterer Systeme wie DMX (und künftig Modbus, MQTT usw.)
   KNX kann viel, aber es hat nicht in jedem Bereich seine Stärke. Mit dem Timberwolf Server bieten wir einen KNX Server an, der weitere Bussysteme und Protokolle unterstützt bzw. unterstützen wird. Derzeit sind es 1-Wire und DMX.
   Für das erste Halbjahr 2020 haben wir uns vorgenommen Modbus als Server und MQTT zu integrieren. Danach kommen die weiteren gängigen Busse & Protokolle. Die Updates erhält man dann einfach auf Knopfdruck im laufenden Betrieb.
3. Sehr einfache Bedienung mit dem Browser
   Wir streben lange Benutzbarkeit des Servers an. Niemand kann sagen, welche heutigen Programme auf einem Windows in 2035 noch laufen. Sofern es dann überhaupt noch PC gibt. Darum setzen wir u.a. auf komplette Browserbedienung. Damit kann auch ein Tablett oder Handy genutzt werden. Es handelt sich um eine Websocket-Appliaktion, die Einstellungen und Werte der Admin-Oberfläche werden live hin und hergeschickt, es muss kein Update der Weboberfläche gemacht werden. Das bei (herkömlichen) Weboberflächen nötige Reload (und das damit verbundene Flackern) zum Update eines Wertes gibt es mit dem TWS Admin Tool nicht. Es ist immer alles Instant und aktuell.
4. "Instant" Logik mit Persistenz und Teil- bis Full-Simulation
   Durch die Bedienung im Browser sind alle Einstellungen und Rückmeldungen sehr interaktiv. Das nutzen wir auch im Logik-Editor. Mit "Speichern" wird eine Logikzelle aktiv, ohne das andere Logikzellen davon betroffen sind, ohne dass ein Service neu zu starten ist. Mit Klick auf den "Doktor-Modus" kann man der Logikzelle nun im Betrieb zusehen. Die eintreffenden und berechneten Werte werden dabei dargestellt und auch aufgezeichnet wie in einem Mixed-Signal-Oszilloskop, auch über Monate hinweg, für eine spätere mögliche Detailanalyse der Logikzelle.
   Für die Simulation kann jedes der Ein- und Ausgangssignale einzeln für sich abgetrennt werden. Die Trennung kann so belassen werden um den letzten Eingangswert zu konservieren oder es wird von Hand ein anderer Wert eingespeist - etwa um die Zelle mit anderen Eingangswerten live zu testen. Die "Simulation" findet nicht im Browser statt sondern live in der Logikengine, welche die Werte von und zum Browser spiegelt.
   Die Kunden betrachten gerade diese Möglichkeiten als sehr mächtig. Schließlich verbringt man mehr Zeit mit dem Austesten einer Logik als mit dem Erstellen und durch diese schnelle Testen und diese praktisch nicht vorhanden Turn-Around-Zeiten für Änderungen in Verbindung mit der grafischen Analyse des Antwortzeitverhaltens wird sehr viel Zeit gespart.
   Jede Logikzelle kann - separat von anderen - in einen Persistenzmodus geschaltet werden. Die Ein- und Ausgangswerte sowie alle inneren Zustände werden gepeichert und stehen nach Restart (etwa nach Stromausfall) wieder zur Verfügung.
   Wem die angebotenen Logikmodule nicht reichen, kann sich aus den Bausteinen auch eine "Custom Logik" bauen, dies ist ein einfaches json File in dem die benötigten Logikbausteine, die Ein- und Ausgänge und die Verbindungen angegeben werden. Diese Definitionsfiles lassen sich ganz einfach kopieren und weitergeben. Die Community hat schon eine Reihe von Bausteinen erzeugt, die in unserem Forum zur Verfügung gestellt werden (oder wo auch immer die Kunden das wollen).
5. Robust & Langlebig
   Das Unternehmen wird von Technikern geführt, nicht von Controllern. Wir entwickeln, bauen und prüfen ordentlich und sauber, es wird nirgends gespart. Soweit wir das beeinflussen können, ist das System auf lange Lebens- und Benutzungsdauer ausgelegt. Das betrifft ordentliche Auslegung, gute Kühlung und Auswahl des richtigen Flash bei gleichzeitiger Schonung. Es ist nicht unser Geschäftsmodell, dem Kunden alle paar Jahre einen neuen Server zu verkaufen, sondern einen möglichst langlebigen Server anzubieten und wir wünschen uns, dass wir dazu lange Updates und Support liefern dürfen.

Es gibt noch eine Reihe mehr Details, hier gehe ich dann im Rahmen der anderen Fragen ein. Danke, dass ich im Ozean mitschwimmen darf, ich nehme die Einladung gerne an.


lg

Stefan

[Gast1961]

Ist doch aber kein Server für die Hutschiene sondern reine SW.

Nö, das ist eine Fehlinformation. Es gibt bei IP-Symcon beides. Als Symbox ist es ein fertiger Hutschienenserver mit eigenem SymOS Betriebssystem.

https://www.symcon.de/shop/#symbox

Unterstützt KNX, M-Bus, Modbus, DMX, 1-Wire, z-Wave, Enocean, MQTT und vieles mehr.

Aber was ich dazu gelesen habe nur ein Teil und irgendwas war dann noch mit einseitig verbundenen GA, auch nicht stabilitätsförderlich, zumindest verwirrend.

Nö, auch das ist eine Fehlinformation.

Der X1 ist in diesem Punkt ein vollwertiger zertifizierter Server, mit ganz normalen Datenpunkten die in der ETS verknüpft werden. Und zusätzlich hat er die Möglichkeit, KNX GA auch direkt anzusprechen - ein Hybridmodell, wie es nun auch für den TWS geplant ist.

[crewo]

Da das immer wieder als Vorteil verkauft wird: Es ist nicht sinnvoll, dass der VPN Server auf der gleichen Maschine läuft welche für das tägliche Leben zuständig ist. Denn dafür muss ich dort Zugriff von Aussen erlauben. Es ist, auch aus Gründen der Stabilität, Verfügbarkeit und Sicherheit immer sinnvoll, dafür dedizierte Hardware zu verwenden! Meinetwegen kombiniert mit Router und Firewall.

[gbglace]

IP-Symcon ist in dem Punkt extrem flexibel, inzwischen auch mit MQTT.

Ist doch aber kein Server für die Hutschiene sondern reine SW.

X1 war doch immer schwarz.

Ja wie der HS2 von Matthias erwähnt aber die nachfolgenden HS waren eben silber.

Wieso ist ein externes Backup ein einzigartiges Feature?

Weile viele das gar nicht bieten. Kannst mit ner Domovea oder EIB-Port überhaupt nen Backup machen? Und wenn dann ist es intern ja gut aber extern potentiell noch sicherer falls der Server gröber wegen was schaden nimmt.

Ein Beispiel wäre der X1, der hat natürlich längst eine zertifizierte Applikation und man kann die Objekte in der ETS verknüpfen.

Aber was ich dazu gelesen habe nur ein Teil und irgendwas war dann noch mit einseitig verbundenen GA, auch nicht stabilitätsförderlich, zumindest verwirrend.

Man kann im Docker andere Smarthome-Server-Software laufen lassen, die das mitbringen, was dem TWS an Funktionalität fehlt.

Naja die Komik kann ich da nicht erkennen aber ja so ist es. Das der TWS derzeit mit der Software Version erste Vollversion noch einige Lücken hat ist ärgerlich aber er bietet die Ergänzung auf gleicher Plattform ohne zusätzliche HW. Wenn man wieder den X1 belasten will, wirklich fertig wurde er dann offensichtlich auch erst durch die Öffnung als Programmierplattform für die Community.

[skibbi]

Die bunten Kataloge müssen mal inhaltlich auf das IST reduziert werden.

Das sehe ich auch so. Jemand der jetzt z.B. e-Bus-Anbindung braucht, muss sich nach einer anderen Lösung umschauen, für den ist es also kein Kaufargument. Jemand der jetzt einen TWS kauft, wird in Zukunft wahrscheinlich kein e-Bus brauchen. Für den ist es also auch kein Kaufargument.

[vento66]

Er redet vom Homeserver, der war am Anfang schwarz, dann silber.....

[Gast1961]

Möglichkeit "exotische" Komponenten für die Gebäudesteuerung in Dockern auf einer passenden HW laufen lassen zu können ohne ggf. das reine Mutimedia-NAS damit zu befassen. Manch einer mag das gern getrennt betreiben, wobei ich sowas nicht mal habe.

Aber am TWS habe ich problemlos Openhab, EDOMI und die Cometvisu laufen. Ich behaupte mal, alle zusammen in 15min installiert.

Der Beitrag war vermutlich ernst gemeint, aber es entbehrt nicht einer gewissen Komik, wenn das einzigartige Feature eines Smarthome-Servers dieses ist:

Man kann im Docker andere Smarthome-Server-Software laufen lassen, die das mitbringen, was dem TWS an Funktionalität fehlt.

Wenn ich mir Zukunft erlauben darf:
- wenn die KNXA das passende Werkzeug hat, gibt es einen Server mit KNX-Zertifizierung

Auch wenn StefanW behauptet, der TWS sei damit einzigartig: sowas gibt's längst. Ein Beispiel wäre der X1, der hat natürlich längst eine zertifizierte Applikation und man kann die Objekte in der ETS verknüpfen.

- IP-Protokolle ins TWS-Objektsystem integriert, womit man sich dann Logiken mit direktem Zugriff gegen die IoT-Gadgets dieser Welt bauen kann (Reduziert die Notwendigkeit via Docker-basierter Intermediäre und Umweg KNX sich damit zu verbinden).

Wieso ist das ein einzigartiges Feature? Das ist heute schon bei vielen anderen Servern vorhanden. IP-Symcon ist in dem Punkt extrem flexibel, inzwischen auch mit MQTT.

- Backup der Serverdaten auch auf externes Medium

Wieso ist ein externes Backup (welches aktuell fehlt) ein einzigartiges Feature?

Bei Gira ist der X1 ja auch wieder in schwarz, die silbernen Geräte dazwischen scheinen ja aber hier und da mal nen Batterie / Netzteil Tod gestorben zu sein.

???

X1 war doch immer schwarz. Die grauen Geräten waren die alten Logikmodule, wie ich eines habe. Die wurden dann per kostenlosem Firmwareupdate zum L1 (doppelte Anzahl Datenpunkte). Was mir da ausgefallen war, das war das MDT 24V Netzteil welches das Logikmodul versorgt.