Hi JustMe
(Angabe des Vornamens wäre nett, nicht zwingend aber fühlt sich besser an)
JustMe hat geschrieben: ↑Sa Jul 04, 2020 8:28 pmvielen Dank für die ausführlichen Antworten. Ich habe irendwo mal gelesen, dass ihr keine genauen Zeitpunkte mehr angebt um Kunden nicht zu enttäuschen, falls es doch zu Verzögerungen kommen sollte.
Wir sind vorsichtig geworden, weil wir haben uns in der Anfangszeit der Timberwolf Entwicklung leider massiv im Realisierungsaufwand getäuscht.
Der Grund für die falsche Einschätzung war, dass wir zwar durchaus Vorstellungen hatten, welche grundlegenden Merkmale die Software erfüllen soll, aber zu einem großen Teil stand die nötige Technologie noch nicht zur Verfügung (kompakte & bezahlbare Prozessorleistung mit geringer Verlustleistung, kompakter Flash) bzw. war so brandneu, dass es keinen Entwickler gab, der sich damit bereits auskannte.
Wir mussten also insbesondere zu Anfang mehr Forschung- als Entwicklungsarbeit unternehmen, bis wir herausgearbeitet hatten, mit welchen Technologien die Architektur aufgebaut wird, wie man diese dann auch debugged und testet, wie man es dokumentiert und wie man es leistungsfähig, ressourceneffizient und vor allem auch skalierbar aufbaut.
Zudem war eine komplette grafische Oberfläche zu erstellen, die auch eine Administration erlaubt. Ein bisschen ist das wie Windows und Office. Das Windows selbst kann nicht viel, "nur" die Hardware und die grundlegenden Einstellungen verwalten. Aber seine Arbeit kann man nur mit Windows nicht erledigen. Dazu braucht es erst die Applikation wie Office, Browser und andere spezielle Programme für die Aufgaben, die wiederum das Windows als Basis brauchen.
Beim Timberwolf Server mussten wir die Grundlage für die grafische Oberfläche und vor allem auch für dies Live-Verbindung zur Overfläche zunächst entwickeln. Wir verwenden kein PHP das für jedes Update der Seite neu geladen werden muss (womit der Browser dann jedesmal "blinzelt"), sondern alle Ein- und Ausgaben werden im Browser berechnet und nur die reinen Daten mit dem Backend ausgetauscht. Das sieht sehr selbstverständlich und normal aus, aber tatsächlich ist das eine recht komplexes Client-Server-Modell im Browser mit einer Menge an Live Daten.
Zudem wollten wir, dass alle Engines im laufenden Betrieb neue Regeln, Logiken usw. akzeptieren ohne neu gestartet werden zu müssen. Alleine dieses einfache kleine Leistungsmerkmal, das man als selbstverständlich hinnimmt bedeutet den zehnfachen Aufwand, gegenüber der üblichen Technik, dass nach einer Rekonfiguration von Regeln und Einstellungen alles neu gestartet werden muss. Negativbeispiel hierfür ist der Homeserver. Wenn man da eine Änderung in der Logik vornimmt, muss diese erst übertragen werden und anschließend der Homeserver neu gestartet werden. Dieser Neustart dauert zwischen 5 und bis zu 40 Minuten, in denen der Server gar nicht zur Verfügung steht und wenn man sich dann vertan hat, dann beginnt das peil von vorne. Das ist tatsächlich Stand der Technik, der verkauft wird.
Bei unserer Logikengine ist das so, dass wenn man eine Logik ändert oder neu erstellt und auf Speichern drückt, dann ist diese Logik etwa 1/20 Sekunde später aktiv. Ohne dass andere Logiken davon betroffen sind. Da wird nix aufwändig "übertragen" und auch nicht neu gestartet.
Unsere Nutzer nehmen das als "normal" hin (und ist es auch für ein Produkt aus 2020) weil es ist auch so selbstverständlich für unseren Anspruch an Qualität und Benutzerführung. Tatsächlich ist eine solche Vorgabe aber alles andere als leicht umzusetzen. Eine solche Bedienweise mit "Änderungen-sofort aktivieren" haben wir praktisch im gesamten Produkt realisiert. Also neben der Logik auch in bei 1-Wire, bei allen Verknüpfungen zwischen den technologien, bei ekey und wir werden dies auch bei den neuen Protokollen wie Modus, DMX, MQTT usw. umsetzen. Wir haben uns da wirklich eine sehr feine Technik erarbeitet und nutzen das nun konsequent.
Dieser ganze Aufwand, dass wir zunächst viel mehr erforschen mussten als angenommen, dass die Programmierung der Architektur ("unser Windows") sehr Aufwändig war und dass wir uns so hohe Ansprüche an den Bedienungskomfort vorgenommen hatten, hat uns um die ursprünglich avisierten Termine gebracht. Dazu kommt, dass wir noch viele guten Ideen hatten, die wir unbedingt unterbringen wollten und dann kamen noch sehr viel Wünsche unserer Kunden dazu. In der Gesamtheit haben wir den Aufwand damals im Team heftig unterschätzt. Auf der anderen Seite sind wir sehr glücklich mit dem was daraus entstanden ist.
Aus der Erfahrung heraus sind wir einfach vorsichtig geworden mit frühzeitigen Angaben zu genauen Terminen. Wir meinen, es ist uns allen mehr gedient mit wirklich guter Qualität und Zuverlässigkeit, als zwar termingerecht aber hinsichtlich der Qualität verfrüht auszuliefern. Weil letzteres frisst dann viel Zeit im Support, frustriert und alle und ist nicht wirklich zielführend. Besser ein paar Monate etwas länger reifen zu lassen und ausgereift auszuliefern. Hat man auch als Kunde sehr viel mehr davon.
Ich bitte um Verständnis, dass wir zwar gerne eine Reihenfolge veröffentlichen, in der wir an neuen Leistungsmerkmalen arbeiten, aber genaue Zeitpunkte schwierig sind. Dafür gibt es aber eben auch die neue Roadmap Garantie, damit der Kunde zumindest sicher sein kann, dass er das Leistungsmerkmal, sollte es sich verspäten, auf jeden Fall ohne Kosten zur Verfügung gestellt bekommt, wenn es ausgerollt wird.
JustMe hat geschrieben: ↑Sa Jul 04, 2020 8:28 pmIch muss trotzdem fragen, ob es eine ungefähres Timing dazu gibt O:-) . Gerade was die Modbus Thematik angeht wäre ich tatsächlich zumindest auf eine grobe zeitliche Einschränkung angewiesen.. =)
Klar, das ist auch eine legitime Frage. Schließlich verkaufen wir ein Produkt mit einem ziemlich heftigen Upgrade Versprechen und da wollen die Kunden das schon genauer wissen.
Da wir hinsichtlich der Modbus Implementierung auch schon sehr weit sind, kann ich dazu auch gerne Auskunft geben.
Die Modbus Implementierung besteht aus fünf großen (und ein paar kleinen) Modulen.
Modul "Modbus Schnittstellenverwaltung": Hier werden die Modbus Schnittstellen für "Modbus TCP" und "Modbus RTU" verwaltetet.
Denn - je nach Servermodell - werden wir eine größere Anzahl an Schnittstellen gleichzeitig unterstützen. Das ist ein starkes Alleinstellungsmerkmal, weil die meisten Server des Mitbewerbes, können, sofern sie überhaupt Modbus unterstützen, nur die eine eingebaute lokale Schnittstelle. Hat man zwei Busse, braucht man einen weiteren Server. Beim Timberwolf Server kann man fast beliebig viele externe Schnittstellen anstecken und diese nicht nur mit den internen Schnittstellen benutzen, man kann auch die darauf gebundenen Funktionen mit drei Klicks (von denen zwei nur der Sicherheit dienen) beliebig zwischen den Schnittstellen "umziehen", etwa wenn man einen Fehler in Bus / Schnittstelle sucht. Es gibt dann auch gute und klare Rückmeldungen zum Funktionsstatus und es ist komplett Plug´n´Play. Genau so einfach, wie wenn man an Windows eine neue Maus ansteckt und diese sofort funktioniert, geht das auch bei unseren Extensions. Bei allen übrigens ist das so einfach.
==> Dieses Modul ist weitestgehend fertig und funktioniert gut. Sowohl für Modbus RTU als auch für Modbus TCP und auch mit mehreren Interfaces.
Modul "Modbus Stack": Das ist der Kommunikationsstack für die eigentliche Modbus Kommunikation
Hiervon werden mehrere Instanzen gestartet, für jede konfigurierte Schnittstelle eine und hier wird der ganze Datenaustausch, das Protokollhandling, Timings usw. gesteuert.
==> Auch dieses Modul ist sehr weit fortgeschritten, läuft stabil und funktioniert recht gut. Es kann sein, dass wir hier noch das ein oder andere Tuning brauchen, aber das sehen wir dann erst bei den Test mit den "Insidern" in der Praxis.
Modul "Modbus Scheduler": Dies ist der zentrale Prozess, der die Aufträge sortiert uns vom Stack ausführen lässt
Das ist die zentrale Modbus Kontrolle im System. Hier werden aus dem vom Kunden eingestellten Regeln die jeweiligen Aufträge verwaltet, die dann vom Modbus Stack ausgeführt werden (jede Regel kann ein eigenes Intervall und ein eigenes Timing haben, das von allen anderen Regeln unabhängig ist, es sind also durchaus mehrere tausende individuelle und gleichzeitig nebeneinander existierende "Fahrpläne" für die verschiedenen Modbus Register möglich - mit jeweils individuellen Settings für Berechnungen, Weiterleitungsfiltern und Regeln).
==> Dieses Modul funktioniert im Prinzip bereits. Die ein oder andere Erweiterung wird mit dem Regeleditor noch kommen.
Modul "Modbus Applikationseditor": Dies ist der Editor, mit dem man die Fähigkeiten der Modbus Geräte als "Applikation" anlegt.
Ein sehr zentrales (und geniales) Konzept von KNX ist, dass es zwar 8000 kompatible Geräte gibt, aber diese mit nur EINER Software parametrisiert werden kann: Der ETS. Damit das fiunktioniert, stellen die Hersteller die jeweiligen Applikationen zum Download zur Verfügung, die man nun in die ETS einliest und mit der man dann das entsprechende KNX Gerät parametrisieren kann. Damit die Hersteller diese Applikation erstellen können, wird den Herstellern von der KNX Association gegen den Einwurf kleiner (und größerer) Münzen eine Software zur Verfügung gestellt, die als "Manufacturer Tool" bezeichnet wird.
Bei Modbus gibt es das leider nicht. Jeder Hersteller eines Modbus Gerätes gibt nur ein (mehr oder weniger schlechtes) Datenblatt heraus, indem die Parameter drin stehen, welche vom System unterstützt werden. Das muss dann jeder Nutzer in seinen jeweiligen Modbus Master implementieren. Das ist nicht gerade effizient.
Darum haben wir nun einen solchen Standard für den Austausch einer solchen Modbus-Spezifikation entwickelt und einen Editor dazu entwickelt, mit dem diese Spezifikation eingegeben werden kann. Diese kann geteilt werden, so dass das aufwändige Anlegen der Fähigkeiten der Modbus Geräte nur noch einmal vorgenommen werden muss. Gerade bei den Wechselrichtern sind durchaus hunderte von Parametern nutzbar und es ist ein Irrsinn, wenn das nun jeder Kunde individuell anlegen muss.
Daher machen wir das nun beim Timberwolf Server wie bei der ETS: Es gibt eine (vorinstallierten) Applikationseditor und damit legt der Nutzer die Applikation zunächst an. Der Clou ist: Diese Definition lässt sich teilen und das soll dafür sorgen, dass nur ein Nutzer es anlegen muss uns alle anderen können das nutzen. Das soll die Implementierung massiv vereinfachen und ganz erheblich Zeit und Aufwand verkürzen.
Der Editor unterstützt dabei einen Live-Check, d.h. man kann damit bereits beim Eintippen mit dem Device kommunizieren und die richtigen Einstellungen damit interaktiv austesten.
==> Auch dieses Modul funktioniert bereits und wird derzeit gefinished.
Modul "Modbus Geräte-Editor": Dies ist derjenige Editor, mit dem der Kunde die Regeln anlegt.
Wir oben bereits aufgezeigt, geben wir dem Nutzer maximale Freiheiten. Für jedes Register lassen sich beliebig viele und auch unterschiedliche Regeln hinsichtlich Intervall, Berechnungen, Filter und Weiterleitungen anlegen. Alles Live und sofort aktiv nach dem Speichern.
Hier ist der Stand, dass dieser Editor noch vor der Entwicklung steht, weil dieser die Funktion der anderen Module benötigt. Das ist also die noch fehlende und umzusetzende Komponente.
Wir sind also schon sehr weit und beginnen in einigen Wochen, die Modbus Software - abgesehen vom Regeleditor - auszurollen mit der Insider Preview 1 für die version 2.0. Damit kann man dann die Applikation definieren und komplett austesten. Während die Insider diesen Teil ausrollen, werden wir den noch fehlenden Modbus Geräteeditor ausrollen. Dieser orientiert sich an der Funktionalität des 1-Wire Editors und ich schätze, dass wir hier zwischen zwei und vier Monaten benötigen werden.
Kurz: Zum Ende des Sommers / Anfang Herbst sollte die Modbus Implementierung für Insider zur Verfügung stehen. Wie lange es dann dauert, bis diese Version dann als freigegebene Hauptversion zur Verfügung steht, wird davon abhängen, ob sich beim Test durch die Insider noch Probleme herausstellen oder nicht. Das kann man schlecht vorhersehen. Bei uns im Labor und einigen Testhäusern läuft das schon alles, aber es ist dann nochmal was anderes, wenn es bei hunderten Insidern mit bislang unbekannten Modbus Geräten laufen soll.
Ich hoffe die Angaben sind für Dich und Dein Projekt ausreichend
lg
Stefan
.