WireGate Server New Generation heißt nun Timberwolf Server

[Emarc]

Hallo Stefan,

stimmt, bei der Hardware kann ich es zu 100 % nachvollziehen, aber nicht bei der Software.
Und hier fragt StefanW auch regelmäßig was man denn so gerne hätte um priorisieren zu können.
Nicht jedes Software-Feature hängt auch direkt mit Hardware zusammen.
Das meinte ich eigentlich. Sorry wenn es schlecht formuliert war.

Gruß,
Marc

[Hups]

Ich finde die Umfrage gut.
Für uns Kunden, wie auch für Wiregate.

Ich denke es hilft dabei eine Sackgasse zu vermeiden die Ressourcen bindet, die man besser nutzen könnte um einen wichtigeren Kundenwunsch zu befriedigen.
Eine Software ist in ständiger Entwicklung....

find ich halt =)

SG!
Hups

[gbglace]

Es geht bei der Software auch um Zusatzfunktionen wie z.B. die DMX Steuerung, grundsätzlich gibt es natürlich eine / zwei RS485 Schnitsttellen am Timberwolf-Server, Stefan hat aber auch bereits angekündigt das noch nicht alle Features zum Start fertig und verfügbar sein werden. Mit der Umfrage soll eben auch der Bedarf an solche Features genauer ermittelt werden um dann die weitere Entwicklung steuern zu können.

Ich denke mal das was der Server grundsätzlich leisten muss wird auch äußerst sorgfältig getestet worden sein (1-wire handling und KNX-handling usw.).

Ich würde mich natürlich auch darüber freuen wenn DMX z.B. doch schon von Start an als Überraschung dabei wäre.

[StefanW]

Ui, schon wieder eine Menge passiert hier,

da komme ich kaum noch nach. Aber erst der Reihe nach, hier ist noch eine Frage offen von Jochen:

Mal eine -eher allgemeine und vermutlich auch banale- Frage an die WG-Gemeinde, da ich selber noch keines habe: Kann das WG und künftig der Timberwolf auf Read-Requests vom KNX reagieren

Ja.

Das ist ein wichtiges Feature für Visu und beim Start einer Anlage

und kann ich das Verhalten auch für einzelne KO einstellen.

Ja, über das 'R' Flag in der ETS. Hierbei ist darauf zu achten, dass dies nur bei einem Device pro Gruppenadresse gesetzt wird, damit nicht mehrere Devices auf den selben Read-Request antworten.

Unser Stack ist KNX zertifiziert und damit muss er das auch alles können.

lg

Stefan

[Dragonos2000]

Ok, danke. Alles andere wäre ein K.O. für mich. Es gibt ja diesbezüglich durchaus eigenwillige Implementierungen, daher die Frage.

Und ja, insbesondere wegen Initialisierung nach Start hatte ich gefragt.

Gruß
Jochen.

[StefanW]

Hallo Marc,

Bitte korrigiert mich, aber für mich hat die regelmäßige Fragerei nach den gewünschten Software-Features einen komischen Beigeschmack. Kann es sein, dass der Server noch mitten in der Entwickung ist und damit noch weit entfernt von einem stabilen, auf Herz und Nieren getestem System?

Das haben wir gerne. System, Softwaretechnik und unsere Fragen zwar nicht kennen, aber einfach mal pauschal Vermutungen anstellen.

Nun, ich kann es durchaus verstehen, ich habe mir beim Schreiben schon gedacht, hoffentlich interpretiert das keiner falsch... Also werde ich es erklären.

Wenn wir die Software wie ein monolithisches System aufgebaut hätten, dann würde ich Dir rechtgeben. Wenn man da etwas verändert, muss man wieder von vorne anfangen mit Testen usw. Aber so haben wir das nicht gemacht.


Reaktive Software beim Timberwolf Server:

Heutezutage werden Systeme "reaktiv" gebaut. Dies bedeutet, sie verfügen über die folgenden "reaktiven" Eigenschaften:

• Antwortbereit: Das System antwortet unter allen Umständen zeitgerecht.
• Widerstandsfähig: Das System bleibt auch bei Ausfällen von Hard- oder Software antwortbereit (die verbleibenden Komponenten)
• Elastisch: Das System bleibt auch unter sich ändernden Lastbedingungen antwortbereit. Dies wird durch Verteilung und Replizierung von Funktionen erreicht. Natürlich setzt die jeweilige Hardware dem Grenzen.
• Nachrichtenorientiert: Das System verwendet eine asynchrone Nachrichtenübermittlung zwischen den Komponenten. Damit werden die Module entkoppelt und voneinander isoliert. Damit wird auch eine gewisse Ortsunabhängigkeit der Komponenten ermöglicht.

So ein Systemaufbau führt zu sehr vielen, voneinander abgekapselten Modulen, die über ein Nachrichtensystem asynchron kommunizieren. Damit werden Änderungen propagiert und von jedem Modul empfangen, dass sich dafür interessiert. Für jedes Modul existieren zusätzliche statische und dynamische Tests, die im Rahmen eines Continous Testing bei jedem Einschecken ablaufen und die Gültigkeit der API und der Modulfunktionen automatisiert jedesmal aufs neue beweisen. In dieser Hinsicht gültige Module werden automatisch für die verschiedenen Systemarchitekturen compiliert und paketiert, so dass es auch ein Continous Deployment gibt. Bedeutet, wir haben Nightly Builds und jeden Tag ein aktuelles System für die Tests. Demnächst bekommen das die Beta-Tester-Systeme das auch als Update auf Knopfdruck zur Verfügung gestellt.

Somit besteht der Timberwolf Server aus hunderten Modulen, einem leistungsfähigen Nachrichtensystem und aus Datenbanken. Jedes der Module hat eine feste Aufgabe und ist auch vom Umfang her übersichtlich und in einem leicht lesbaren Codestyle geschrieben. Wir nutzen auch automatische Bewertungssysteme, zu komplexe Kodierung wird mangels Prüfbarkeit abgelehnt.

Die Features nach denen ich fragen werde sind entweder schon fix und fertig vorhanden (und ich gewinne aus den Antworten Informationen daraus, welches Feature gefragt sind, das spielt dann eine Rolle für Handbuchgestaltung, ggfls. Videos und auch Marketing) oder es sind Features die zwar geplant oder bereits begonnen sind und deren Implementierungsreihenfolge und - ausgestaltung angepasst wird. Zudem werden wir aus den Reservierungen erfahren, wie groß das Interesse ist. Bei entsprechend großem Interesse können wir weitere Ressourcen dazu nehmen.


Der lange Weg von der Engine zur Oberfläche:

Die reaktive Programmierung bedeutet auch eine komplette Trennung vom Backend (also den eigentlichen Engines), der Middleware (Kommunikation) und dem Frontend. Selbst für simple Dinge muss alles dreimal geschrieben werden. Das Backend, dass die eigentlichen Berechnungen und Datenverarbeitung ausführt, die Middleware welche über ein Nachrichtensystem vom Backend den Zustand einzelner Prozesse abfrägt und das Frontend, dass widerum über Nachrichtensysteme von der Middleware die aufbereiteten Informationen für die Anzeige erhält oder umgekehrt Kommandos an diese sendet.

Nehmen wir die Funktion "KNXnet/IP Tunneling Schnittstelle". Der Timberwolf Server kann bis zu 100 paralelle Tunnelconnections (das sind 20 mal mehr als der Mitbewerb). Diese Funktion ist im Stack eingebaut und existiert schon seit über einem Jahr. Nun könnte sich durch die Umfrage herausstellen, dass die Kunden gerne eine Auflistung aller laufenden Tunnelconnections hätten. Bisher gibt es das nicht. Um das zu realisieren muss man eine Middleware schreiben, welche die API des KNX-Stacks dahingehend befrägt und ein Frontend, dass diese Informationen zur Anzeige bringt. Dieses Feature läßt sich also "anflanschen" ohne dass die Kern-Software (hier der KNX Stack) beeinflusst wäre. Die Hauptfunktion ist damit (schon lange) fertig gestellt, aber es gibt einen Anzeigewunsch.

Und so geht es uns bei vielen Funktionen. Die Engines sind schon lange fertig, jedoch fehlt es an Middleware uind Frontend. Deshalb kann ich durchaus in der Vorbestellphase noch eine Umfrage machen nach einzelnen Features, so dass wir das ein oder andere, insbesondere in der Darstellung, noch schärfen können. Zudem ist es gut zu wissen, was in der Zukunft gewünscht ist, weil es gibt sicher noch viel zu entwickeln bzw. aktuell zu halten und an den Markt anzupassen.


Gerade auch, weil die schreibende Teilname an Foren weltweit zurück geht, erfahren wir nicht mehr die Wünsche von jedem Interessenten. Darum machen wir die Umfrage, die sich letzlich an alle richten wird.

Der wesentiche Funktionskern ist fertig. Woran besonders intensiv gearbeitet wird sind die Anbindungen zum Frontend, die Unterstützung unserer drei Architekturen, das Ausrollen / Installation, die Plug´n´Play Funktionen, Systemverwaltung, Import vom WireGate Server, Optimierungen, Ausbau der Logikmodule und deren Darstellung im Frontend und viele viele Details, auch Übersetzungen.

Features hinzuzufügenb bedeutet also vor allem neue Logikmodule und die Oberfläche dazu. Die Kernfunktionen, nämlich die Programmierung der Objekte durch die ETS, die Annahme der Datenpakete aus dem KNX müssen da nicht geändert werden, die Änderungen betreffen ja die Anwendungsschicht. Somit wird an den Kernfunktionen dann auch nichts mehr geändert. Lediglich ein neues weiteres Modul hört am Nachrichtensystem mit, ob eine Objekt angesprochen worden ist und aktiviert sich entsprechend.


Ich hoffe das war soweit verständlich, dass der Aufbau der Software im Timberwolf Server den aktuellsten technischen Kriterien entspricht, in Schichten und Modulen realisieret, die im höchsten Maße getrennt voneinander sind. Nur weil wir noch einiges anflanschen können, bedeutet es nicht, dass dabei jedesmal der Kern überarbeitet werden muss.

lg

Stefan

[starwarsfan]

Hallo Stefan,

schicke Beschreibung, vielen Dank dafür!

Das gehört jetzt zwar nicht so recht hierher, aber wenn Du schon so am beschreiben eures CI-/CD-Vorgehens bist und ein paar Minuten Zeit dafür erübrigen kannst: Mich als Softwareentwickler würden ein paar Details von "hinter den Kulissen" interessieren. Also so Sachen wie welches CI-System ihr einsetzt oder mit welchen Tools bzw. Entwicklungsumgebungen ihr arbeitet...

[StefanW]

schicke Beschreibung, vielen Dank dafür!

Bitte gerne.

Ich hoffe Du bist nicht der einzige, dem diese Info gefallen hat. Gab gerade mal 2 Likes. Dafür dass man sich stundenlang hinsetzt um etwas zu beschreiben ist die Response schon dünn. Kann ich meine Abende auch anders gestalten.

Das gehört jetzt zwar nicht so recht hierher, aber wenn Du schon so am beschreiben eures CI-/CD-Vorgehens bist und ein paar Minuten Zeit dafür erübrigen kannst: Mich als Softwareentwickler würden ein paar Details von "hinter den Kulissen" interessieren. Also so Sachen wie welches CI-System ihr einsetzt oder mit welchen Tools bzw. Entwicklungsumgebungen ihr arbeitet...

Verstehe ich, aber es steckt auch viel Know-How drin. Ein Tool ist nur ein Werkzeug, wie man das genau einsetzt und wie man das konfiguriert und auch alle Entwickler zur Mitarbeit bringt, ist der eigentlich Punkt. Tatsächlich kann ich derzeit nicht "ein paar Minuten" erübrigen.

Vorschlag: Es wird irgendwann im Frühjahr bei uns eine "Meet & Greet" Veranstaltung geben, oder nennen wir es auch den Münchner Stammtisch für Endkunden (das Münchner Symposium besteht von den Besuchern her eigentlich zu 70% aus Mitarbeitern lokaler Elektroinstallationsbetrieben und hat einen anderen Fokus), dort kann dann ein interessierter Softwareentwickler wie Du sich etwas hinter den Kulissen zeigen lassen.

Für Interessierte an Veranstaltungen bei und mit uns: Wird im Newsletter stehen und unter Veranstaltungen auf Facebook

mfg

Stefan

[Jockel]

Ich hoffe Du bist nicht der einzige, dem diese Info gefallen hat. Gab gerade mal 2 Likes. Dafür dass man sich stundenlang hinsetzt um etwas zu beschreiben ist die Response schon dünn. Kann ich meine Abende auch anders gestalten.

Dann melde ich mich auch mal. Hat mit auch sehr gut gefallen und einige Hintergründe sehr gut erläutert. Für so etwas wie "likes" bin ich aber offensichtlich zu alt, dass ist außerhalb meiner Erfahrungswelt...

[StefanW]

Dann melde ich mich auch mal. Hat mit auch sehr gut gefallen und einige Hintergründe sehr gut erläutert.

Merci

Für so etwas wie "likes" bin ich aber offensichtlich zu alt, dass ist außerhalb meiner Erfahrungswelt...

Verstehe ich. Ich mochte das früher auch nicht.


@all: Die "Likes" sind ein einfaches System um zu sagen, ob etwas gefällt / verstanden ist. Ich beschreibe hier immerhin Arbeitsergebnisse, Erkenntnisse und Designprinzipien aus 10 Mannjahren Arbeit. Es ist nicht üblich, dass Hersteller solche Angaben öffentlich machen.

Bitte nicht missverstehen, ich will nicht darum betteln, aber so ohne oder mit wenig Rückmeldung fühlt man sich wie der einsame Rufer in der Wüste und mit der Zeit nagt das an der Motivation. Ihr habt es also selbst in der Hand, jedes Forum verdient sich seinen Content selbst. Das gefällt sicher auch anderen Autoren / Vielschreibern hier, Forenweit.

lg

Stefan

[FabKNX]

Hey Stefan.
Sich über wenige LIKES zu beschweren ist ja nur die eine Seite der Medaille.
Verteilen die andere.

Du reagierst immer sehr ausführlich und zeitnah. Du kümmerst dich um die wehwehchen der wiregate-community. ABER ich hab mir auch Mühe gemacht, um mein Wiregate-Projekt zu veröffentlichen (zugegebener Massen mit sehr viel Freude und nicht uneigennützig), aber geliket haben es nur sehr sehr wenige. Auch du nicht mit dem Button, sondern "nur" schriftlich. ( keine Kritik, nur anmerkung!)

[Hups]

das mit den likes stimmt natürlich..... von allen. wertschätzung ist das was man zu wenig erfährt hier im internet. gerade in einem sachforum in dem man schon zwit investiert und andere nutzen aus dem geschriebenem haben. ich bemüh mich auch meine dankbarkeit in der form zu zeigen, aber man denkt auch nicht wirklich immer dran.... =/

allerdings muß ich auch sagen, dass das wiregate unterforum noch am besten damit umgeht ;o)

SG!

[BadSmiley]

Ich poste nur wegen den Likes, nichts Anderem! Immer! Jedesmal! Jetzt auch!

Was früher die roten Punkte waren, sind jetzt eben die Likes!












und hier sind noch ein paar !!!!! zum verteilen! ha!

[starwarsfan]

Guten Abend Stefan

Ich hoffe Du bist nicht der einzige, dem diese Info gefallen hat. Gab gerade mal 2 Likes. Dafür dass man sich stundenlang hinsetzt um etwas zu beschreiben ist die Response schon dünn. Kann ich meine Abende auch anders gestalten.

Nix für ungut aber auf die Seuche der Like-Buttons klicke ich aus Prinzip nicht. Ich weiss, was man mit den dabei generierten Informationen anstellen kann und so gläsern wie man heutzutage im Netz schon ist, muss ich das nicht auch noch haben.

Verstehe ich, aber es steckt auch viel Know-How drin. Ein Tool ist nur ein Werkzeug, wie man das genau einsetzt und wie man das konfiguriert und auch alle Entwickler zur Mitarbeit bringt, ist der eigentlich Punkt.

Das ist mir klar denn das ist mein täglich Brot...

Vorschlag: Es wird irgendwann im Frühjahr bei uns eine "Meet & Greet" Veranstaltung geben, oder nennen wir es auch den Münchner Stammtisch für Endkunden (das Münchner Symposium besteht von den Besuchern her eigentlich zu 70% aus Mitarbeitern lokaler Elektroinstallationsbetrieben und hat einen anderen Fokus), dort kann dann ein interessierter Softwareentwickler wie Du sich etwas hinter den Kulissen zeigen lassen.

Na das hört sich doch super an! Wenn der Termin rechtzeitig bekannt ist, lässt sich da sicherlich etwas einrichten.

Für Interessierte an Veranstaltungen bei und mit uns: Wird im Newsletter stehen und unter Veranstaltungen auf Facebook

Weil das F-Wort erwähnt wurde: Ich komme sehr gut ohne F-Account aus...

Dass das für ein Unternehmen heutzutage allerdings so gut wie Pflicht ist, kann ich aber auch verstehen.

@all: Die "Likes" sind ein einfaches System um zu sagen, ob etwas gefällt / verstanden ist.

Na soo einfach ist das nun auch wieder nicht. Das was Du da beschreibst ist lediglich das offensichtliche. Viel interessanter ist dabei aber das was dann hinter den Kulissen passiert bzw. möglich ist. Aber um das etwas zu entschärfen würde mich an dieser Stelle brennend interessieren, was im Detail mit einem Like hier im Forum passiert. Wer kann diese Infos auswerten und wie?

Ich beschreibe hier immerhin Arbeitsergebnisse, Erkenntnisse und Designprinzipien aus 10 Mannjahren Arbeit. Es ist nicht üblich, dass Hersteller solche Angaben öffentlich machen.

Und das finde ich extrem hilfreich und bewundernswert, eine super Sache! Nur stehe ich mit der allgemeinen Methodik der Auswertung auf Kriegsfuss...

[Dennis]

Selber habe ich keine Produkte von euch.
Da mein Haus so gut wie Fertig renoviert ist und ich leider zu spät von den ganzen Möglichkeiten erfahren habe lese ich nur still mit.

Bin aber sehr gespannt was von euch noch so alles kommt...