Timberwolf Server (aka "New Generation") grober Termin?

[StefanW]

Also ich wäre als Kunde von Wirgate eigentlich enttäuscht wenn ich diesen TP-UART nicht weiterverwenden könnte.

Wollen wir das doch mal festhalten, wir nehmen niemandem etwas weg und keiner muss auf was neues migrieren und kann das bestehende solange Weiterbenutzen wie es funktioniert, also durchaus Jahrzehnte.

Auf dem WG2xxx würdert ihr euch keinen abbrechen wenn ihr den eibd oder knxd da installieren würdert damit Bestandskunden die wechseln müssen oder wollen sich nicht auch noch eine Schnittstelle oder Router kaufen müssten.

Das ist technisch nicht möglich, weil auf dem WireGate New Generation - egal welche technische Serie - weder ein eibd noch ein knxd läuft und nicht einmal ansatzweise etwas ähnliches - und auch nicht geben wird *.

Die Architektur des WireGate New Generation besteht nicht mehr aus einer großen PERL-Schleife die geschickt nacheinander die verschiedenen APIs abklappert, sondern aus einem atomaren System bei dem eigenständige Module vollständig gekapselt und asynchron voneinander ihre Aufgabe erfüllen und dabei über ein flexibel konfigurierbares High-Speed-Software-Bussystem miteinander kommunizieren.

Die KNX-Funktion basiert auf einem eigenen zertifizierten KNX-Stack der per ETS konfiguriert wird. Die Funktionen dieses Stacks sind nicht nur 10 mal größer als beim eibd oder dessen forks, sondern haben eine grundlegend andere API. Da gibt es keinen Groupswrite usw., schon alleine weil die KNX Applikation auf Objekten basiert und nicht auf GAs. Man kann auch sagen, weil das was der eibd macht, eine elegante aber nichtkonforme Abkürzung durch den Standard ist.

Es gibt auch noch ein Dutzend weiterer Gründe, aber es sprengt den Rahmen des Forums und meiner Mitteilungsbereitschaft, jedes Detail unserer Entscheidungen und Implementierung auszuführen.

Die Entscheidung, dass wir die bisherigen TP-UARTS in Zukunft nicht mehr unterstützen können ist am Ende eine finanzielle. Der Aufwand, um unserem Stack die alten TP-UART beizubringen und das ebenfalls zertifizieren zu lassen kostet soviel, dass am Ende die Unterstützung der alten TP-UARTs mehr kosten würde, als diese noch Wert sind. Oder kurz: es macht für die Kunden keinen Sinn, hundert Euro für Kompatibilität auszugeben um eine Hardware zu unterstützen die einen Restwert von ca. 50 EUR hat. Ich denke, das würde Kunden noch mehr enttäuschen, wenn Sie für Kompatibilität zu alter Hardware diesen Aufpreis bezahlen sollten.

Die Entwicklung der neuen Generation ist ohnehin schon so teuer, wir mussten daher, um das Budget einzuhalten, auch ein paar ältere Zöpfe anschneiden. Ich tue das ungern, weil ich für Nachhaltigkeit stehe. Wenn der Ressourcenaufwand allerdings zu hoch ist, kann man nicht alles bekommen was man will.

* Für Docker-Container stellen wir einen eibd zur Verfügung, der hinsichtlich der Client-Schnittstelle auf unseren KNX-Stack aufsetzt. Damit die Plugin-Kompatibilität gegeben ist. Dieser eibd läuft jedoch isoliert in Containern.


Jürgen, ich habe nichts gegen Fragen, aber bitte nicht in dieser Häufigkeit mit diesem kritischem Unterton. Wir sind mehr als viele andere um unsere Kunden bemüht und unsere Entscheidungen sind fundiert und kundenorientiert. Bitte berücksichtige das doch mit Deinem Wording.

Danke für das Verständnis

lg

Stefan

[StefanW]

Hallo Bernhard, manchmal bin ich etwas faul beim schreiben

Ich hätte eher gesagt, der Planinhalt (Backlog für die Kundigen) ist für kurzfristige Ziele (Stories) am präzisesten, was Detaillierung und Implemtierungszeitpunkt betrifft und wird für länger in der Zukunft liegende Ziele immer unschärfer, weil es sich nicht lohnt, Dinge, die man noch nicht so genau weiss, schon zu präzise auszuplanen.

Danke, Du drückst das wesentlich besser aus als ich. Der Unterschied liegt im Detaillierungsgrad der kurzfristigen, mittelfristigen und langfristigen Planungen.

Eine ungefähre Roadmap für das kommende halbe Jahr bis Jahr dürfte es aber auch bei Euch geben, oder?

Richtig, es gibt selbstverständlich eine grobe Planung und Reihenfolge bis Ende 2017 und auch Vorstellungen darüber hinaus.

Die Ziele für die nächsten ca. 2 Monate habe ich bei den Beta-Stages weiter oben auch schon beschrieben. Danach werden die Themen implementiert, für die es spezielle Interfaces gibt, also DMX usw. Die Reihenfolge wird sich, außer nach technischen Gesichtspunkten, vor allem nach dem Kunden richten, weil wir bauen das System für die Kunden, nicht für uns. Finden die Kunden bestimmte Features wichtiger, kann das schon zur Priorisierung führen.


Meine ganz intensive Bitte: Wir können nur Wünsche berücksichtigen von denen wir wissen, selbst wenn es sich um banale Dinge handeln mag, schreibt uns bitte an support at wiregate dot de mit "WireGate / Vorname Nachname: Feature Request WG-NG zu ........."

lg

Stefan

[Cepheus73]

Eine Liste, was wann ganz genau dran kommt, die gibt es so nicht, weil wir arbeiten nach agilen Methoden. Da gibt es keinen genauen Plan (der nur viel Arbeit macht), dafür eine Vision, einer Story, der man folgt. Das ist unter dem Strich schneller, weil die Planungsarbeit kürzer ausfällt.

OT: Ui, Stefan, der Agile-Unkundige Leser könnte nun auf die Idee kommen, dass das WG NG ganz ohne Planung, also sozusagen nach Chaos entwickelt würde.
Ich hätte eher gesagt, der Planinhalt (Backlog für die Kundigen) ist für kurzfristige Ziele (Stories) am präzisesten, was Detaillierung und Implemtierungszeitpunkt betrifft und wird für länger in der Zukunft liegende Ziele immer unschärfer, weil es sich nicht lohnt, Dinge, die man noch nicht so genau weiss, schon zu präzise auszuplanen. Eine ungefähre Roadmap für das kommende halbe Jahr bis Jahr dürfte es aber auch bei Euch geben, oder?

Viele Grüße, Bernhard

[heckmannju]

Hab ich was verpasst? Ich denke, dass alle Varianten des WG NewGen eine zertifizierte Knx Schnittstelle haben, da entfällt das Tpuart dann.
Lg Robert

Gugst du
http://shop.wiregate.de/download/Wir...log_I_2016.pdf
Seite 12 ich sehe da keine KNX Busklemme.

[Robert_Mini]

Also ich wäre als Kunde von Wirgate eigentlich enttäuscht wenn ich diesen TP-UART nicht weiterverwenden könnte. Auf dem WG2xxx würdert ihr euch keinen abbrechen wenn ihr den eibd oder knxd da installieren würdert damit Bestandskunden die wechseln müssen oder wollen sich nicht auch noch eine Schnittstelle oder Router kaufen müssten.

Hab ich was verpasst? Ich denke, dass alle Varianten des WG NewGen eine zertifizierte Knx Schnittstelle haben, da entfällt das Tpuart dann.
Lg Robert

[heckmannju]

Hinsichtlich des "alten" TP-UART. Gemäß bisheriger Implementierung unseres KNX Stacks wird der alte Chipsatz nicht mehr unterstützt. Ob sich eine Rücknahme rechnet, werden wir noch überlegen.

Also ich wäre als Kunde von Wirgate eigentlich enttäuscht wenn ich diesen TP-UART nicht weiterverwenden könnte. Auf dem WG2xxx würdert ihr euch keinen abbrechen wenn ihr den eibd oder knxd da installieren würdert damit Bestandskunden die wechseln müssen oder wollen sich nicht auch noch eine Schnittstelle oder Router kaufen müssten.

[derBert]

Die Zielgruppe für das WireGate New Generation sind diejenigen 95% der Nutzer, die ...

Tatsächlich gibt es sehr viele Interessenten, die sich das alles sehr viel einfacher wünschen,

Hier!

[StefanW]

Nun, Jürgen, es geht nicht um Dich, Sepp oder um mich, sondern darum was der Mehrzahl der Kunden und insbesondere unserer angepeilten Zielgruppe gefällt.

Wir haben das Feature in einer Vorab-Version auf der Messe gezeigt und es wurde von hunderten Besuchern, die sich das haben zeigen lassen, als ganz herausragend befürwortet. Eben weil den Kunden die bisherigen Möglichkeiten nicht gelangt haben.

Die Zielgruppe für das WireGate New Generation sind diejenigen 95% der Nutzer, die mit Linux praktisch nicht umgehen können, die keine Programmiersprache beherrschen, deren Hobby nicht das Selbstentwickeln oder herumwerkeln am Bus ist. Die Zielgruppe sind also diejenigen, die einen Smarthome Server suchen, der so einfach wie ein Smartphone zu bedienen ist. Zur Zielgruppe gehören insbesondere auch SI und Elektriker, die in immer komplexeren Anlagen Fehler suchen müssen und die sich nicht für alles eben ein Script programmieren können. Deshalb werden 9/10 der Entwicklungskosten in die Oberfläche und die leichte Bedienbarkeit gesteckt.
Die Mehrzahl dieser Interessenten traut sich leider nicht hier mitzuschreiben, weil die Experten sich die Meinungshoheit nehmen. Die teils sehr hochtrabenden Diskussionen im Forum haben mit den Problemen in der Praxis oft wenig gemein. Tatsächlich gibt es sehr viele Interessenten, die sich das alles sehr viel einfacher wünschen, wie ich aus Gesprächen, vielen Telefonaten und eMails gelernt habe.

Ich würde anhand Deiner Fähigkeiten abschätzen, dass Du solche aufwändigen, schicken und benutzerleichten Oberflächen als Crack nicht brauchst und daher auch vermutlich nicht zur Zielgruppe gehörst. Insofern sind Deine Anmerkungen für die tatsächliche Zielgruppe möglicherweise wenig hilfreich. Ich bitte Dich daher bei Themen zum Bedienungskonzept und damit zusammenhängenden Features sowie bei Berichten von Beta-Testern um Zurückhaltung.

Ich danke für das Verständnis

Stefan

[heckmannju]

Für mich war das nie realistisch brauchbar.

Hi das Feature vom Wiregate reicht für 95% aller Fälle meine Meinung und ich halte es für gut genug um Fehler zu finden. Ich finde nicht das unbrauchbar ist.

[StefanW]

Hallo Robert, ich sehe, da ist noch eine Frage von Dir offen:

Ich hätte noch eine dringende Frage zur Kompatibilität der WG1 Plugins, nachdem ich gerade eine defekte Wetterstation tauschen muss und überlege die gesamte Beschattungslogik auf das WG zu schieben und nur mehr die Messwerte Helligkeit, Temperatur etc. von der Wetterstation auszuwerten.

Gerne. Du hast eine ähnliche Frage auch im anderen Thread (Old Generation), ich hoffe es ist ok, wenn ich es hier beantworte.

Wie wird das mit den Dockern funktionieren?

Docker ist quasi das Framework um Container zu kontrollieren. In den Containern - das ist ein virtuelles Betriebssystem - befinden sich ein oder mehrere Applikationen inklusive der notwendigen Laufzeitumgebung (manchmal bis hin zu anderen linuxoiden Betriebssystemen als auf dem Host). Durch die Container werden diese Apps voneinander weitestgehend isoliert.

Dabei verwendet Docker hierzu Funktionen des Linuxkernel für die Isolation. Das Abbild eines Containers ist das Image, das einfach weitergegeben werden kann.

Wir stellen eine Basis Image zur Verfügung, dass die für Plugins grundsätzlich wichtige Laufzeitumgebung enthält. Also eibd, wiregated (abgespeckt) und PERL und ein paar Libs dazu. Über die Console kann man dann ein oder mehrere Plugins pro Container starten. Ein oder mehrere Plugins deswegen, falls sich zwei Plugins Daten aus dem gleichen Namespace teilen.

Konkret zB: Für den Sonnenstand das Paket: libastro-satpass-perl? Gehen die Alt-Plugins mit solch Paketen auch am WG NewGen?

Die Docker-Images lassen sich erweitern. Man loggt sich dort ein, hat quasi containerweite Root-Rechte und kann sich die Pakete installieren.

Mit Docker kann man darüber hinaus sehr viel mehr machen, darin dürfte so ziemlich alles laufen, was derzeit an Projekten verfügbar ist (2xxx Server): Smarthome.py, OpenHab, Edomi.

Das ist dann Thema der Community, wir stellen das Gerät und die Möglichkeiten, ihr könnt das nutzen. Damit ist es auch viel einfacher, seine Entwicklung zu teilen, weil wenn die im eigenen Container läuft, dann braucht man den nur exportieren und über den noch zu schaffenden Hub (oder den offiziellen Docker Hub) zu laden und fertig. Es geht nicht ganz soviel wie bei Virtualisierungen, weil das hier "nur" Isolation ist, aber das geht schon sehr weit und kostet keine drei Prozent an Ressourcen. Die Möglichkeiten sind ziemlich groß.

Robert, Du bist wegen der vielen Plugins ohnehin für einen Test eingeplant, ich komme dann noch auf Dich zu. Außerdem haben wir noch das Hall of Fame Projekt, das wir machen müssen.

lg

Stefan

[Dragonos2000]

Ok, danke StefanW für Aufklärung. Bin echt gespannt auf euer Produkt

[StefanW]

Ich habe eine Bitte,

der Beta-Test ist derzeit im Stadium "nicht öffentlich", d.h. es gibt Regularien, über was berichtet werden darf. Das hat u.a. mit Lizen-, Marken- und Patentrechten zu tun. D.h. bitte Nachfragen gegenüber denjenigen, die sich als Tester outen, nur zu den zuvor veröffentlichten Features stellen.

Details und erste Erfahrungen bezüglich DMX wären für mich auch interessant.

Der WireGate Server der neuen Generation ist umfangreich in seiner Funktionalität und in den Details. Daher - das habe ich weiter oben detailliert beschrieben - findet der Betatest in Stufen und mit wechselnden Testern statt. Nicht jeder ist in jeder Sache kompetent. Wir wollen die im jeweiligen Gebiet kompetentesten Tester bzw. diejenigen und / oder mit der dann umfangreichsten Installation.

==> Hinsichtlich des Beta-Tests befinden wir uns derzeit im nicht öffentlichen Stadium / Stage 1.

Stage 1 bedeutet: Wir testen die Basis wie Netzwerk, Basiseinstellungen, Kompatibilität mit Endgeräten, Oberfläche und Bedienkonzept, KNX Objekteditor, KNX PA Editor, KNX GA Editor und unser Sahnestück: den KNX Gruppenmonitor

Stage 2 soll beinhalten: Übergang zu KNX Multi-Interface, also KNX Interface Editor und alle KNX Tests nochmal, diesmal mit mehreren Interfaces.

Stage 3 ist geplant: "Simple Logic Editor", das ist ein sehr mächtiges, aber einfach bedienbarer Logikeditor, mit dem sich ein großer Teil der 180 vordefinierten Logiken konfigurieren läßt.

Mit jedem Stage wird der Kreis der Tester erweitert bzw. verändert. Erst mit jedem Stage werden die entsprechenden Features freigeschaltet, zum Teil arbeiten wir auch noch daran.

DMX ist also noch nicht dabei, da müsst ihr noch ein wenig Geduld haben. Eine Liste, was wann ganz genau dran kommt, die gibt es so nicht, weil wir arbeiten nach agilen Methoden. Da gibt es keinen genauen Plan (der nur viel Arbeit macht), dafür eine Vision, einer Story, der man folgt. Das ist unter dem Strich schneller, weil die Planungsarbeit kürzer ausfällt.

lg

Stefan

[seppm]

Du weist das das kein neues Feature ist? Also ein WG kann das schon.

Na ja, ungefähr so, wie ein Computer von 1980 und einer von 2016 beides Computer sind :-)

Das derzeitige WireGate, ich nenn es mal "Classic" hat die Daten in einem Log für einen eingeschränkten Zeitraum – zwei Tage, von halb sieben in der Früh bis zum übernächsten Tag um halb sieben - aufgezeichnet, die dann jeweils gezippt abgelegt wurde. Die Log-Rotation hält sieben solcher Dateien vor und löscht ältere Dateien.
Die Web-Anzeige ist auf den Zeitraum seit der letzten Log-Rotation (bei mir halb sieben, jeden zweiten Tag) begrenzt und hat eine recht eingeschränkte Suche. Heute war so eine Log-Rotation, in der Früh hatte ich also gerade Daten von ein paar Stunden in der Web-Anzeige.
Zum auswerten längerer Zeiträume müsste man die GZs einzeln auf einen Rechner runterladen, entkomprimieren und dann eher mühsam händisch suchen oder diese nach Excel etc. als csv zu importieren und umzuwandeln – pro Datei. Für denjenigen, der nicht mit „grep“ auf Du und Du steht ist das sehr mühsam und gar nicht Endkunden oder Elektrikertauglich. Für mich war das nie realistisch brauchbar.

Beim WireGate New Generation, hab ich festgestellt, muss man sich um Dateien, Download, Entzippen und Zeitpunkt der Log-Rotation gar keine Gedanken machen. Ich geh einfach in die einfach bedienbare Suchmaske, gib Realtime (als Live) oder den gewünschten Zeitraum an, das Interface (man kann ja mehrere anschliessen), gesuchte PAs oder GAs und man kann diese Suche auch direkt benennen um sie später schnell wieder zu nutzen.

Mehrerer solcher Suchen können parallel angelegt werden und gleichzeitig oder selektiv aktiv sein, sind jeweils einfach editierbar und die zur Suche passenden Datensätze lassen sich nach eigenen Vorgaben einfärben. Das geht extrem einfach und intuitiv.

In den Eingabemasken sind beliebige Wildcards, Befehle und Tags möglich, weil jedes Fenster wie ein Suchfenster bei Google funktioniert. Dann klickt man auf die Suchergebnisse um letztlich den Filter auszuwählen.

Das ist schon ganz was anderes als zuvor. Auf der Messe hieß es auch, dass dies – wohl je nach Lizenz und Speicherplatz – bis eine Milliarde Logeinträge möglich ist. Braucht ein Einfamilienhaus nicht, aber ein größeres Office mit zig Linien und komplexen Probleme profitiert sicher davon. Je nach Hardware geht wohl auch noch mehr.

Der Unterschied von „alt“ zu „neu“ liegt weniger in der grundsätzlichen Möglichkeit der Aufzeichnung als – dafür umso erheblicher – in der Menge und dem Handling der Logs, als auch in der extrem einfachen AdHoc-Auswertung der Daten – auch in Realtime. Und das auch auf Tablett und Smartphone, das hab ich bisher nirgends gesehen.
EDIT: Die Oberfläche ist jetzt schon adaptiv, sieht bei mir gut aus und läuft auf iPhone 6+, iPad Air2, 13" Macbook und 5k iMac. Auf einem Win7 mit Chrome auch. Ansonsten nutze ich neben Chrome auch Safari. Nur IE mag es nicht so recht, hab ich aber nur zum Spass probiert da ich den sonst auch nie nehme.

Für mich war das alte faktisch nicht handhabbar, daher ist es für mich jetzt wie neu.

Cheers Sepp

[Dragonos2000]

Details und erste Erfahrungen bezüglich DMX wären für mich auch interessant.

[seppm]

• ...
• ... Derjenige, der dies schon in einem PBM investiert hat, möchte das vermutlich nicht nochmal ausgeben. (Lizenzübertragungen sind zwar denkbar, dürften aber wegen der manuellen Aufwände dafür unrentabel sein, außerdem wäre dann der alte PBM zuerst bei uns abzuliefern um die zu übertragenden Lizenzen zu löschen, was machen dann in der Zeit die Sensoren?) Darum werden viele interessiert sein, den bestehenden PBM weiterzubetreiben. Außerdem muss man dann nur den USB umstecken.
  ...

Mein Plan ist das ich den PBM behalte und nur am USB umstecke. Falls ich mich für den 950 entscheide würde ich den aber incl. der 1-wire Anschlüsse haben wollen. Denn eine Aufteilung der 1-wire Buse ist für mich attraktiv. Weitere Lizenzen kauf ich dann wie eben nötig.

Cheers Sepp