ElabNET Technik Forum

Hallo Foristen,

es wird nun langsam Zeit, dass wir unsere erste Releaseversion herausbringen.

Die Hauptmodule sind schon lange ausgereift, was man auch daran sieht, dass es kaum noch Fehlermeldungen, aber dafür eine Menge Feature Requests gibt, also der Wunsch nach mehr Funktionen. Das ist ein guter Indikator.

Auch der Logik Editor, obwohl noch nicht freigegeben, wird schon fleißig getestet und einige der Intensivtester haben uns auch schon "nahe Releasereife" bescheinigt, weil es mehr um kosmetische Darstellungsoptimierungen und vor allem Doku geht, als um echte Fehler.

Unser Plan ist es, mit einer Handvoll Schritten nun zur Releaseversion (= Hauptversion) zu kommen. Diese Schritte sind:

1. Finishing des Logik-Editors und Freigabe für alle. (Wer jetzt schon testen will, kann das tun, die URL steht im letzten Post zur Beta 22)

2. VPN-Einwahl für den Kunden mit Portweiterleitung (also OpenVPN-Einwahl auf den Timberwolf Server mit selbstsigniertem Zertifikat).

3. Plugin-Container als APP für die wenigen Alt-Plugin-Anwendung die nach Objekt-Verteilung und Logik-Engine noch bei Euch verblieben sind.

4. Behebung der kleinen Fehler und Probleme die noch offen sind.

Nochwas?

Gibt es aus Eurer Sicht noch ein Thema das unbedingt implementiert werden muss, bevor man der Software die Release-Tauglichkeit bescheinigen kann?


Was passiert nach der Veröffentlichung der Hauptversion?

Nun, es geht munter so weiter. Es gibt alle paar Wochen Developer- und Beta-Versionen und sobald ein neues Feature dann auch Stabilität erreicht hat, gibt es ein neue Hauptversion ("Release"). Jeder Anwender kann frei entscheiden, ob er bei einem Update nur Hauptversionen bekommt oder Beta-Versionen (die, wie ihr wisst, ja schon ganz gute Qualität sind). Für hartgesottene Tester gibt es auch weiterhin die Dev-Versionen.

Das bedeutet. wir bekommen mit der Hauptversion einen neuen Zweig, den man auch "Stable" nennen könnte, also stabile, gut getestete und verlässliche Funktionen. Wer sich dafür entscheidet, liegt immer richtig und genießt beste Qualität und Dokumentation. Für diejenigen, die gerne vornedran mittesten und mitgestalten wollen gibt es - je nach gewünschtem Härtegrad - die Beta- oder Developer. Das wird man (abgesehen von Developer) dann auch selbst einstellen und - im Rahmen der Möglichkeiten - Wechseln können.


Also, ran an die Tasten, schreibt uns, wie Ihr die anstehende Freigabe zur Releaseversion seht und ob wir in der Liste oben etwas wichtiges übersehen haben (DMX, Modbus usw. kommt danach).

lg

Stefan

Hallo Stefan!

Genau so, wobei das Kunden-VPN eigentlich auch nicht zwingend für die Release ist.
Ich persönlich warte auf das VPN via timberwolf.io, eventuell könnte man diese beiden Features auch in 1.6 kombinieren.
macvlan und TWS IP-Interface ist auch noch ein wichtiger Punkt (wie von @tger977 gerade angemerkt), würde ich aber auch in die 1.6 schieben.

Doku wächst ja schon...

lg
Robert

Hallo Stefan,

also mir fehlt noch das macvlan / Netzwerkthema um mit den Containern endlich durchstarten zu können (Zugriff vom host auf die Container mit fester IP, z.B. EDOMI)

Den Plugin Container hast Du ja schon auf der Liste.

Mit diesen zwei Themen kann dann hoffentlich mein (und vmtl. noch einige andere) Wiregate in Ruhestand gehen und man kann entspannter sich auf die noch kommenden features freuen

Ich denke auch das lokale Management der Netzwerkverbindungen in und Um der Docker ist wichtig. Den externen VPN-Zugriff gern später aber dafür eine größeres Roll-out der Zertifikate für .fritz.box statt nur TWS###.local.

Ansonsten Logik + passende Doku dazu fertig und dann raus auf den Ladentisch damit.

Die Optionalität der Releasezyklen ist gut.

Danach machen wir dann Licht, wenn das im Q3 auf Beta ist bin ich noch zu frieden.

Hi Stefan,

die von dir beschriebene Reihenfolge find ich schon ganz ok so. Die TWS-IP-Schnittstelle wäre für mich auch prima.
Der Plugincontainer bzw. ein Basisimage für die fortgeschrittenen Bastler hätte was. Dazu hatten wir ja schon mal einen Thread bei dem ich meinen Arm in die Luft geworfen habe.

Stellt sich die Frage, ob ihr an der für alle lästigen Performancethematik mit dem Recompile noch was drehen könntet.

Beste Grüße
Jens

Hinzugefügt nach 27 Minuten 20 Sekunden:
Ach, da fällt mir noch was ein. Ich finde nach wie vor den Umgang mit Uhrzeitwerten, deren Modifikation über die CometVisu und deren Nutzung in Logiken als optimierungsbedürftig.

Zudem wäre da noch der Persistenzlayer, wobei ich mir da auch mit dem Plugincontainer zu helfen wüsste, aber die Leute die direkt mit Logiken durchstarten wollen und nicht mit der Logik der Wiregate-Plugins vertraut sind wäre das ggf. sehr hilfreich.

Guten Morgen,

gleich ein paar Antworten dazu:

macVLAN: Das wird leider eine anstrengende Sache, weil dazu müssen wir viel ändern. Das dies für viele wichtig ist damit man mit Docker noch mehr machen kann ist klar, aber es kommt eben erst nach der V 1.5, weil das ja auch ein "Expertenfeature" ist.

VPN: Ja, wir haben das ursprünglich versprochen, darum wollen wir das auch implementieren, aber es ist uns (mittlerweile) klar, dass jeder von Euch schon seine VPN-Lösung hat. Darum wäre eigentlich die indirekte Variante über timberwolf.io sehr viel interessanter, weil das - vor allem für Integratoren, die auf die Fritzbox beim Kundne keine Einfluss haben - eine einfach nutzbare Variante ist. Aber auch hier, das kommt erst nach der V 1.5

IP-Interface: Was meint Ihr damit? Einen KNX IP-Stack? Das ist in der Entwicklung, aber wird sich noch ein wenig ziehen.

blaubaerli hat geschrieben: ↑Mo Jun 03, 2019 10:39 pmStellt sich die Frage, ob ihr an der für alle lästigen Performancethematik mit dem Recompile noch was drehen könntet.

Ist das eine PERL-Thematik? Ich bin mir nicht sicher, ob wir hier so viele Ressourcen reinstecken sollen? Wollen sich noch so viele das alte PERL m it eibd antun? Für micht ist das eine veraltete Technik, da wäre doch eine moderne Objektschnittstelle mit API für moderne Sprachen deutlich besser?

blaubaerli hat geschrieben: ↑Mo Jun 03, 2019 10:39 pmAch, da fällt mir noch was ein. Ich finde nach wie vor den Umgang mit Uhrzeitwerten, deren Modifikation über die CometVisu und deren Nutzung in Logiken als optimierungsbedürftig.

Bitte - in einem separaten Thread erklären.

blaubaerli hat geschrieben: ↑Mo Jun 03, 2019 10:39 pmZudem wäre da noch der Persistenzlayer,

Auch Persistenz ist etwas, das nach V 1.5 kommt, steht auch in der Pipeline und ist anprojektiert. Die Persistenz dabei ist nicht das Problem, sondern die Aufgabenstellung besteht eher darin, wie man diese Objekte wieder - z.B. nach einem Stromausfall / Restart - wieder ins System einspeist.

lg

Stefan

Da habe ich zwei wichtige Punkte für das Release:
1. Ich würde es befürworten, wenn das Thema SSL Zertifikat auch die Beta-Phase verlässt.

Die aktuelle Lösung des Self-Signed Zetifikat mit der Notwendigkeit einem Elabnet Root-CA vertrauen zu müssen ist für eine Beta Version "ok", jedoch hat dies im Release meiner Meinung nach als einzige Lösung wirklich nichts mehr verloren.
Durch den Root-CA von ElabNET erlaube ich (soweit ich sehe) der ElabNET beliebige Zertifikate auszustellen. Eine Kontrolle dazu ist schwierig / unmöglich. Zertifikate großer Hersteller/Webseiten/Banken/Shops etc. könnten mit diesem CA unbemerkt ausgestellt werden. Für mich als Nutzer sind die Risiken einer nicht verschlüsselten Web-Oberfläche im internen LAN daher überschaubarer als die Verschlüsselung über https mit einem Hersteller Root-CA. Auch für Firmen-Rechner ist das Vorgehen untauglich/unmöglich.
Also bitte hier entweder SSL Deaktivierbar oder die Möglichkeit ein eigenes Zertifikat einzugeben.

2. Der Wartungs-VPN
Der Wartungs-VPN sollte jeden Zugriff anzeigen und für mich nachvollziehbar mitloggen. Da die Logs durch den Root Zugriff von ElabNET löschbar sind, sollte zusätzlich unmittelbar beim öffnen des VPN's z.B. eine E-Mail an mich als Kunden geschickt werden.
Es ist aktuell nicht nachvollziehbar ob, wann und was ein Mitarbeiter der ElabNet in meinem KNX/Lan gemacht hat. Das könnte auch ein Haftungsthema werden, da durch Änderungen/Manipulation z.B. über KNX gegebenenfalls auch Schäden angerichtet werden können. Hier solltet Ihr sowohl eine technische Lösung bieten, als auch eine organisatorische (Stichwort dsgvo, wer hat wann bei der ElabNet Zugriff auf die Kunden-Timberwolfs / auf deren Passwörter etc.).

VPN: Ja, wir haben das ursprünglich versprochen, darum wollen wir das auch implementieren, aber es ist uns (mittlerweile) klar, dass jeder von Euch schon seine VPN-Lösung hat

Ich habe noch keine, weil ich gehofft habe, dass mit der Releaseversion eine (mindestens) so einfach einzurichtende Lösung wie für das Wiregate zur Verfügung gestellt wird. Dabei geht es mir persönlich vor allem um den Zugriff auf die CometVisu von außen. Hoffe also weiterhin, dass es mit 1.5 kommt

macVLAN: Das wird leider eine anstrengende Sache

Das verstehe ich. Ich gehöre aber auch zu denen, die sich freuen würden, wenn das Thema "macvlan und TWS IP-Interface" trotzdem nicht allzu lange nach hinten geschoben wird.

Gruß
Matthias

+1 für macVLAN

John hat geschrieben: ↑Di Jun 04, 2019 1:30 pm 2. Der Wartungs-VPN
Der Wartungs-VPN sollte jeden Zugriff anzeigen und für mich nachvollziehbar mitloggen.

Wie machen das die Gira X1 / enertex ENA / ISE-Box?
Bekomme ich da auch ne e-mail wenn der Elektriker sich da drauf schaltet?
Ich würde da jetzt mit ersten Release nicht übertreiben. Aber später eine gewisse Sichtbarkeit/ Nachvollziehbarkeit von Zugriffen wäre interessant.