KNX Data Secure Unterstützung
für KNX Logger und KNX Busmonitor
KNX Diagnose Monitor, Import des ETS Projektes deutlich beschleunigt, Suche in der Navigation
Mehr Informationen dazu hier im Forum
Insider Version 6 zur 4.5 jetzt für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki
[NEUHEIT] ANKÜNDIGUNG: Timberwolf Visu - Das Ende aller Diskussionen
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 4089
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1416 Mal
- Danksagung erhalten: 1901 Mal
Wieso ist es so schwer zu verstehen das Terminangaben immer nur den jeweils aktuellen Stand der Aktivitäten widerspiegeln und kein fix in Stein gemeißelter Termin sind. Klar könnte man jetzt auch ne Visu ausrollen, aber haben wollen tut die dann so auch keiner.
Und gar keine Kommunikation bei den umfangreichen Entwicklungsarbeiten ist auch keine Lösung, weil es dann noch viel viel mehr Diskussionen gibt warum kommt denn da so lange nix.
Und denjenigen die Angst um Ihr laufendes Jahr Featureupgrade haben wo noch gar keines geliefert wurde, denen wurde ja auch schon Beruhigung kommuniziert das die V4 auf jeden Fall für alle dabei sein wird im Rahmen der gekauften Featureleistungsstufen.
Dieses IP-Release kommt gerade wegen eines Bugs der sich früher wo ergeben hat und aktuell bei einigen Usern zu vermehrten Unwohlseinsäußerungen führt. Da war man dann eben soweit und hat die dafür passende Reparatur und einige weitere Verbesserungen die vor und neben der Visu gebaut wurden (Features aus IP1-3) jetzt eben separiert und in die IP4 gepackt und bringt die raus.
Das wird aber alles noch nicht die V4 werden. Betroffene von diesem Bug können dann auch die IP4 ziehen auch wenn sie ggf. mittlerweile nicht mehr Insider User sind, denn die ordentliche Systemtrennung kommt dann eh erst mit der richtigen V4 und da man sich mit einer ggf. "unberechtigt" gezogenen IP1 oder so den Bug eingefangen hat dürfen diese User dann jetzt auch die Reparatur bekommen.
Aber klar ist auch das durch diese zwischen geschobene IP4 sich die IP-Version mit den ersten Visu Paketen jetzt auch etwas verzögert hat. Denn ein solches Release-Paket baut sich auch nicht von allein.
Und wenn etwas plaudern erlaubt ist. Visu selbst ist schon viel fertig und gut aber quasi das Werkzeug eine gute Visu sich im TWS zu bauen, da wird gerade noch dran gebaut. Eine Einheitsbrei-Visu will ja auch niemand haben.
Und gar keine Kommunikation bei den umfangreichen Entwicklungsarbeiten ist auch keine Lösung, weil es dann noch viel viel mehr Diskussionen gibt warum kommt denn da so lange nix.
Und denjenigen die Angst um Ihr laufendes Jahr Featureupgrade haben wo noch gar keines geliefert wurde, denen wurde ja auch schon Beruhigung kommuniziert das die V4 auf jeden Fall für alle dabei sein wird im Rahmen der gekauften Featureleistungsstufen.
Dieses IP-Release kommt gerade wegen eines Bugs der sich früher wo ergeben hat und aktuell bei einigen Usern zu vermehrten Unwohlseinsäußerungen führt. Da war man dann eben soweit und hat die dafür passende Reparatur und einige weitere Verbesserungen die vor und neben der Visu gebaut wurden (Features aus IP1-3) jetzt eben separiert und in die IP4 gepackt und bringt die raus.
Das wird aber alles noch nicht die V4 werden. Betroffene von diesem Bug können dann auch die IP4 ziehen auch wenn sie ggf. mittlerweile nicht mehr Insider User sind, denn die ordentliche Systemtrennung kommt dann eh erst mit der richtigen V4 und da man sich mit einer ggf. "unberechtigt" gezogenen IP1 oder so den Bug eingefangen hat dürfen diese User dann jetzt auch die Reparatur bekommen.
Aber klar ist auch das durch diese zwischen geschobene IP4 sich die IP-Version mit den ersten Visu Paketen jetzt auch etwas verzögert hat. Denn ein solches Release-Paket baut sich auch nicht von allein.
Und wenn etwas plaudern erlaubt ist. Visu selbst ist schon viel fertig und gut aber quasi das Werkzeug eine gute Visu sich im TWS zu bauen, da wird gerade noch dran gebaut. Eine Einheitsbrei-Visu will ja auch niemand haben.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
-
- Reactions:
- Beiträge: 35
- Registriert: So Apr 02, 2023 11:51 am
- Wohnort: Beinwil am See, CH
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 42 Mal
Hallo Göran, warum ist es so schwer zu verstehen, dass Kunden und Integratoren enttäuscht sind, wenn kommunizierte Termine immer wieder um mehrere Wochen / Monate verschoben werden. Es gibt einfach einige, welche auf die Features warten, auch teure Softwarepakete wie Ultra gekauft haben, ohne direkten Mehrwert zu bekommen und gerne mit ihren Home Automatisierungen starten würden. Ich denke Elab sollte Verständnis haben, dass es mitunter frustrierend ist darauf zu warten und die Kunden das auch kundtun. Daher war der Vorschlag schon nicht so schlecht, vielleicht eine andere Kommunikationsmöglichkeit zu finden. Mir würde da z.B. ein Fertigungsgrad-Balken in % und wöchentlich aktualisiertes anvisiertes Go-live Date auf der Seite einfallen. So weiss jeder wo die Entwicklung ungefähr steht und muss nicht nachfragen bzw. wird von mehreren Wochen Verschiebungen überrascht. 
Ich selbst bin ein bisschen frustriert und warte auch darauf, aber verstehe als ITler auch die Schwierigkeiten und Verzögerungen, welche ein solches umfangreiches-Release mit sich bringt. Ich plane meine Umsetzung daher mal auf November / Dezember, wenn draussen das Wetter nicht mehr so toll ist.

Ich selbst bin ein bisschen frustriert und warte auch darauf, aber verstehe als ITler auch die Schwierigkeiten und Verzögerungen, welche ein solches umfangreiches-Release mit sich bringt. Ich plane meine Umsetzung daher mal auf November / Dezember, wenn draussen das Wetter nicht mehr so toll ist.
TWS 3500XL ID:1170, VPN offen, Reboot nach Absprache | KNX, Unify Netzwerk, Shellys, Plenticore 8.5, Open WB Standard+, Miele@Home, Velux, Somfy, Elco, ... 

-
- Reactions:
- Beiträge: 150
- Registriert: Mo Jan 07, 2019 9:27 pm
- Wohnort: Sonnberg
- Hat sich bedankt: 10 Mal
- Danksagung erhalten: 81 Mal
- Kontaktdaten:
Also grundsätzlich verstehe ich beide Seiten. Stefan und sein Team sitzen sicher nicht in der Nase bohrend im Kellerchen und überlegen sich, auf wann sie verschieben können, um die Benutzer möglichst viel zu ärgern. Auf der anderen Seite warten dzt. glaube ich schon viele auf die angekündigte Visu. Mit den Vorankündigungen wurde ja auch schon viel Geschmack darauf gemacht und ja, auch ich warte schon und bin schon fast ein wenig frustriert, weil es immer wieder neue Termine gibt.
So ein Fortschrittsbalken ist mMn. aber auch immer gefährlich. Auf welche Größe macht man den? Zeit kann man kaum abschätzen, geschätzte fertiggestellte Teile auch schwierig, wenn man 10 Teile hat, 1 davon ist extrem umfangreich, die anderen 9 ziemlich klein, ist man schnell mal auf 90% und dann geht nix mehr voran. Was macht man, wenn sich der Umfang während der Programmierung ändert? Den Fortschritt von 70% auf 30% zurückstellen? Die Diskussionen möchte ich mir nicht ausmalen.
Am Ende des Tages ist die Variante, die andere Hersteller machen, wohl gar nicht so verkehrt: Einfach nichts kommunizieren, dann spart man sich die Diskussionen ... wollen wohl auch die Wenigsten.
Für mich persönlich beginnt die Kommunikation einfach oft zu früh. Monatelang bevor es etwas gibt, wird groß angekündigt und dann dauert und dauert und dauert es. Ich verstehe, dass so eine Programmierung viel Aufwand ist, ich verstehe auch, dass die Freude, wenn man sieht, was sich im eigenen Produkt tut, riesig ist und man das in die Welt hinausposaunen möchte. Da wäre aber mMn. oft ein wenig mehr Zurückhaltung besser und dann, wenn es kurz vor Go-Live, oder von mir aus auch Testbeginn ist, alle paar Tage vorbereitete Infos raus hauen und innerhalb von 2-3 Wochen auch was ausliefern.
Ist aber nur meine Meinung und eines ist klar, JEDEM werdet ihr es NIE recht machen können!
So ein Fortschrittsbalken ist mMn. aber auch immer gefährlich. Auf welche Größe macht man den? Zeit kann man kaum abschätzen, geschätzte fertiggestellte Teile auch schwierig, wenn man 10 Teile hat, 1 davon ist extrem umfangreich, die anderen 9 ziemlich klein, ist man schnell mal auf 90% und dann geht nix mehr voran. Was macht man, wenn sich der Umfang während der Programmierung ändert? Den Fortschritt von 70% auf 30% zurückstellen? Die Diskussionen möchte ich mir nicht ausmalen.
Am Ende des Tages ist die Variante, die andere Hersteller machen, wohl gar nicht so verkehrt: Einfach nichts kommunizieren, dann spart man sich die Diskussionen ... wollen wohl auch die Wenigsten.
Für mich persönlich beginnt die Kommunikation einfach oft zu früh. Monatelang bevor es etwas gibt, wird groß angekündigt und dann dauert und dauert und dauert es. Ich verstehe, dass so eine Programmierung viel Aufwand ist, ich verstehe auch, dass die Freude, wenn man sieht, was sich im eigenen Produkt tut, riesig ist und man das in die Welt hinausposaunen möchte. Da wäre aber mMn. oft ein wenig mehr Zurückhaltung besser und dann, wenn es kurz vor Go-Live, oder von mir aus auch Testbeginn ist, alle paar Tage vorbereitete Infos raus hauen und innerhalb von 2-3 Wochen auch was ausliefern.
Ist aber nur meine Meinung und eines ist klar, JEDEM werdet ihr es NIE recht machen können!
TWS 950Q ID:249 <VPN offen, Reboot nach Absprache erlaubt>
Moin zusammen,
das Kernthema ist in Meinung Augen hier die Transparenz. Das Problem lässt sich lösen, wenn man die Roadmap und den aktuellen Stand fortlaufen für die Kunden nach außen hin darstellt/visualisiert. Wir nutzen hierzu z. B. das Tool www.aha.io
In der (agilen) Entwicklung kann dort der Stand eingesehen und auch z.B das Voting für neue Feature kann dort integriert und transparent für die Kunden darstellt werden.
So hat man fortlaufend den Status der aktuellen und zukünftigen Entwicklungspakte.
VG
Dominik
das Kernthema ist in Meinung Augen hier die Transparenz. Das Problem lässt sich lösen, wenn man die Roadmap und den aktuellen Stand fortlaufen für die Kunden nach außen hin darstellt/visualisiert. Wir nutzen hierzu z. B. das Tool www.aha.io
In der (agilen) Entwicklung kann dort der Stand eingesehen und auch z.B das Voting für neue Feature kann dort integriert und transparent für die Kunden darstellt werden.
So hat man fortlaufend den Status der aktuellen und zukünftigen Entwicklungspakte.
VG
Dominik
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 2500 ID:465 (VPN offen, Reboot nach Rücksprache)
-
- Reactions:
- Beiträge: 151
- Registriert: Do Sep 29, 2022 12:52 am
- Hat sich bedankt: 159 Mal
- Danksagung erhalten: 113 Mal
Egal wie man so ein Thema kommuniziert, man wird es nie allen recht machen können.
Ich selber freue mich auch sehr auf die Visu. Genau deshalb wäre es gelogen wenn ich sagen würde ich wäre nicht frustriert, wenn ein Termin wieder verschoben wurde.
Aber die Visu war ja – wenn ich das richtig mitbekommen habe – nie in diesem Umfang geplant gewesen. Da ist es meiner Meinung doch Verständlich, wenn sich das ganze nach hinten verschiebt. Der Umfang ist meiner Auffassung bei so einem Projekt enorm schwer abzuschätzen und dadurch ist eine genaue Zeit Planung kaum möglich ist. Eine halbfertige Visu will ja schließlich auch keiner haben...
Abgesehen davon, hätte ich eine Frage zur Darstellung von Zeitserien in der Visu. Ich habe gelesen das eine einfache Darstellung (z.B. PV Anlagen) möglich sind. Wird es auch die Möglichkeit geben, mehrerer Zeitserien in einem Widget darstellen? Oder kann ich vielleicht sogar Grafana Dashboards anzeigen lassen (über eine Pop-Up Widget oder so...). Hintergrund ist folgender: ich bin gerade dabei, mir in Grafana ein paar Energie Dashboards zu bauen... (verschiedene Stromverbräuche, Spitzenlast, Gas-/Wasserverbrauch, etc.) Natürlich würde ich dies irgendwie gerne in die Visu integrieren. Ist sowas aktuell vorgesehen oder später geplant?
Die Suche hat mir leider kein Ergebnis geliefert und auch kann ich mich beim mitlesen nicht erinnern darüber etwas gelesen zu haben.
VG Sebastian
Wenn man das ganze nicht bzw. später kommuniziert und es durch ein so gewaltiges Update Monate lang keine anderen Updates auf den TWS kommen, dann geht dieselbe Diskussion doch genauso los...mclb hat geschrieben: ↑Fr Sep 01, 2023 9:34 am Für mich persönlich beginnt die Kommunikation einfach oft zu früh. Monatelang bevor es etwas gibt, wird groß angekündigt und dann dauert und dauert und dauert es. Ich verstehe, dass so eine Programmierung viel Aufwand ist, ich verstehe auch, dass die Freude, wenn man sieht, was sich im eigenen Produkt tut, riesig ist und man das in die Welt hinausposaunen möchte. Da wäre aber mMn. oft ein wenig mehr Zurückhaltung besser und dann, wenn es kurz vor Go-Live, oder von mir aus auch Testbeginn ist, alle paar Tage vorbereitete Infos raus hauen und innerhalb von 2-3 Wochen auch was ausliefern.
Ich selber freue mich auch sehr auf die Visu. Genau deshalb wäre es gelogen wenn ich sagen würde ich wäre nicht frustriert, wenn ein Termin wieder verschoben wurde.
Aber die Visu war ja – wenn ich das richtig mitbekommen habe – nie in diesem Umfang geplant gewesen. Da ist es meiner Meinung doch Verständlich, wenn sich das ganze nach hinten verschiebt. Der Umfang ist meiner Auffassung bei so einem Projekt enorm schwer abzuschätzen und dadurch ist eine genaue Zeit Planung kaum möglich ist. Eine halbfertige Visu will ja schließlich auch keiner haben...
Abgesehen davon, hätte ich eine Frage zur Darstellung von Zeitserien in der Visu. Ich habe gelesen das eine einfache Darstellung (z.B. PV Anlagen) möglich sind. Wird es auch die Möglichkeit geben, mehrerer Zeitserien in einem Widget darstellen? Oder kann ich vielleicht sogar Grafana Dashboards anzeigen lassen (über eine Pop-Up Widget oder so...). Hintergrund ist folgender: ich bin gerade dabei, mir in Grafana ein paar Energie Dashboards zu bauen... (verschiedene Stromverbräuche, Spitzenlast, Gas-/Wasserverbrauch, etc.) Natürlich würde ich dies irgendwie gerne in die Visu integrieren. Ist sowas aktuell vorgesehen oder später geplant?
Die Suche hat mir leider kein Ergebnis geliefert und auch kann ich mich beim mitlesen nicht erinnern darüber etwas gelesen zu haben.
VG Sebastian
Grüße
Sebastian
TWS 3500S ID:860, VPN offen, Reboot möglich
Sebastian
TWS 3500S ID:860, VPN offen, Reboot möglich
-
- Elaborated Networks
- Reactions:
- Beiträge: 10713
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5303 Mal
- Danksagung erhalten: 8685 Mal
- Kontaktdaten:
Hallo zusammen,
heute ist mein letzter Tag im Urlaub (vor der zweitätigen Rückfahrt ab morgen), offenbar braucht es noch ein Statement..
Ganz Kurz:
DIE VISU VERZÖGERT SICH NICHT NOCHMAL SIGNIFIKANT
Kurz:
DIE HERAUSGABE DER IP4 OHNE VISU BEDEUTET NICHT, DASS SICH DIE VISU NOCHMAL SIGNIFIKANT VERZÖGERT, SONDERN HAT ANDERE GRÜNDE.
WIR HABEN FEATURE-FREEZE UND FINISHEN GERADE ALLE FUNKTIONEN, ES SIND EINFACH NUR DEREN SEHR VIELE.
==> WIR SIND AUF DER ZIELGERADEN UM DIE VISU AN DIE TESTER AUSZUROLLEN.
Länger:
1. IP4 ohne VISU
Wir haben die IP4 nicht deshalb "vorab" herausgebracht, weil wir einschätzen, das sich die VISU noch umfassend hinauszögern wird. Weil der ein oder andere Frust scheint sich gerade an dieser gedanklichen Vorstellung zu entzünden. Weil wir kommen gerade gut vorran mit der VISU.
Es gibt einen großen und zwei kleine Gründe, warum wir die die anderen Inhalte der IP4 nun ausgerollt haben.
A: Göran hat es schon geschrieben, es gab ein nerviges Problem mit der IP3 und hier sind zuletzt viele Supportfälle entstanden, das belastet uns auch im Tagesgeschäft und das wollten wir damit erledigen.
B: Es gibt eine Menge kleiner Verbesserungen in Logik, MQTT, Rest-API die für einige nicht nur wertvoll sind, sondern die auch von den Insidern getestet werden sollen. Wir hatten ein wenig Sorge, dass wenn wir alles zusammen mit der VISU rausgeben, dass die anderen Goodies nicht mehr getestet werden bzw. das "untergeht".
C: Zudem gibt es im Service häufiger (verständliche) Beschwerden, dass es schon seit längerem keine neue Software mehr gibt und wofür man denn bezahlen würde.
Zwar hatte eine Mehrheit der Insider dafür plädiert, dass wir lieber an der VISU weiterarbeiten sollen, aber wir achten auch auf die Minderheiten und so haben wir entschlossen, dass wir die bereits fertigen Komponenten - und vorallem den Fix für A. - ausrollen. Es hat auch noch den Vorteil, dass die darin enthaltenen Neuigkeiten in den Release Notes beschrieben sind, das spart uns dann die Zeit für die IP mit der VISU, diese anderen neuen Themen nochmal zu erklären. Weil es will auch nicht jeder die VISU.
2. Bisherige Terminschätzungen
Wie Göran auch richtigerweise schon erläutert hat, beziehen sich die jeweiligen Terminschätzungen auf den Kenntnisstand zu dem Zeitpunkt, wenn diese jeweils abgegeben werden. Wir wägen diese im Team ab und schätzen zusammen.
Ich entschuldige mich stellvertretend für das ganze Team, dass wir die jeweils kommunizierten Termine nicht eingehalten haben. Ja, wir verstehen auch die Frusttrationen, weil wir sind auch frustriert darüber. Niemand will in der Öffentlichkeit gerne als Wortbrecher dastehen.
Der Grund für die Verschiebungen sind übrigens keine unerwarteten technischen Schwierigkeiten, weil tatsächlich sind wir auf keine Probleme getroffen, die uns nicht vorher schon klar waren (das hatten wir also richtig eingeschätzt). Sondern der wesentliche Grund für die Verschiebungen ist, dass wir einfach bessere Ideen hatten.
Kurz: Alle Verzögerungen beruhen darauf dass die VISU besser werden kann.
Ein paar Beispiele:
A. "Mach´s nochmal Sam": Als wir die VISU im Video vom Frühjahr vorgestellt hatten, hatten wir eine erste Version des Clients und des Backends. Wir hatten zu dem Zeitpunkt nur rudimentäre Vorstellungen, hinsichtlich der Details des VISU Editors und fast keinen Plan über das VISU Management (weil gar nicht so klar war, dass wir das brauchen werden). Aber mit der Funktionalität mehrerer VISU Instanzen parallel, war das Management dann erforderlich geworden. Also wurde die Oberfläche für ein solches Management programmiert und ich hatte darüber auch schon das Video gedreht und war gerade in der Bearbeitung des Schnitts, als - zack - ein anderer Entwickler aus dem Urlaub kam und eine deutlich bessere Idee hatte wie man das Management ausführen sollte für einen möglichst einfachen Workflow des Benutzers. Schwierige Entscheidungslage, nehmen wir das "fast fertige, aber schlechtere" VISU Management oder implementieren die intuitivere Lösung mit dem besseren Workflow, dafür dauert es aber länger. Schwere Entscheidung, weil wir wollen fertig werden. Ein späterer Umbau mit "Visu V2" wäre eher unmöglich gewesen, weil man die DB dafür eben so oder so baut. Bei späteren Updates mehrere tausend laufende DBs von einem Schema auf ein anderes umbauen wäre sehr zeitintensiv, so dass man das eher läßt. Was tun? Nun, Ihr werdet es erraten, wir haben uns für das deutlich intuitivere Management V2 entschieden. Recht geben werdet Ihr uns später dafür nicht, weil ihr wisst ja nicht, wie es vorher war. Wenn man die neue Version sieht, wird man sagen, ja, ist gut so und klar würde man das so ausführen. Wir sind wirklich gut mit UI, aber es fällt uns nicht immer mit der ersten Realisierung das Optimale ein. Da ein späteres Nachliefern kaum möglich erschien, haben wir uns schweren Herzens (wegen der Verzögerung) dafür entschieden, es nochmal zu machen und damit haben wir das Management zweimal programmiert und denken, das dies die richtige Entscheidung war.
B. "Könnt Ihr nicht noch das?": Wir haben Testvorführungen bei einigen Integratoren und Endanwendern gemacht. Da kamen eine Reihe von Wünschen auf. Schatten hier, Hintergrund dort, Anzeigeoptionen, dies und jenes abschalten, das dort konfigurierbar, das hier umschaltbar, kann man dien Farbe hier auch anders haben. Nun, es entstand eine Liste mit zwei Dutzend weiteren Wünschen. Einiges verschieben wir schon in VISU V2, aber manches beeinflusst auch die Architektur und das nehmen wir dann gleich mit. Das führt dazu, dass der VISU Editor diese Dinge nun auch einstellbar haben muss, das Backend das speicherbar haben und der Client das empfangen und umsetzen muss. Also alles einmal alles in der Kette neu anfassen für solche Wünsche. Damt dies dann bei weiteren Features schneller geht, haben wir weitere Modularisierungen eingebaut und vor allem dass der Editor ein "Super-Json" verarbeiten kann, aus dem er sich für die jeweilgen Fähigkeiten des Widgets selbst dynamisch konfiguriert und auch weiß, was er wie in die Datenbank schreiben muss. Kurz, wir haben uns die Zeit genommen, eine "Konfigurationssprache" zu designen, dass wir künftige Änderungen und Wünsche viel leichter durchschieben können. Die Einstellung der Eigenschaften im VISU Editor ist damit nicht mehr hard codiert. Das war im Frühjahr nicht so dermaßen "rich" geplant. Dafür sind die Möglichkeiten damit nun wirklich toll und es gibt VIEL MEHR Einstellmöglichkeiten, als wir uns das ursprünglich gedacht haben. Das führt auch zu einer Änderung im Konzeot, dass man nicht mehr so viele Widgets anbieten muss, weil diese so mächtig konfiguriert werden kann. Ich denke, das werdet Ihr zu schätzen wissen, insbesondere auch in der Zukunft, weil wir leichter neue Widgets hinzufügen können. Ja, hat Zeit gekostet, aber hat die Architektur und den Editor massiv vorangebracht um bessere Widgets zu bauen und leichter künftige Wünsche erfüllen zu können. Der Mehrwert ist gegenüber der aufgewendeten Zeit beträchtlich und in unseren Augen eine sinnvolle Investition. Kurz, daher jetzt länger, dafür sind andere Wünsche künftig deutlich schneller umsetzbar, da werden sich manche noch die Augen reiben, was damit möglich wird.
C. "Das Haus kann nur so groß werden wie das Fundament" oder "Entweder gescheit machen oder lassen": Als wir das Thema Kameraintegration näher untersucht haben, haben wir festgestellt, dass dies beim Wettbewerb eher schlecht gelöst ist. Manche Kunden bezeichneten uns gegenüber bei Umfragen die Lösungen der Konkurrenz als "Unverschämtheit". So ein Fehler sollte uns nicht passieren und wir haben geprüft, was denn das Problem an der Lösung der Marktbegleiter ist. Kurz, praktisch alle realisieren da so, dass die Visu-Clients sich den Feed direkt von der Kamera holen. Das Problem ist, viele Kameras können nur einen Feed, manche zwei. Da passiert es dann, dass wenn ein weiterer Client dazu kommt, der Feed bei der ersten Visu dann ausfällt. Globale Nutzung geht dann auch nicht. Aufzeichnungen oder Zugriff darauf auch nicht dabei. Unsere Lösung ist, dass die Kamera den Stream an den Server gibt und der diesen dann für alle seine Clients vervielfacht. Geht natürlich auch nur deshalb, weil wir so einen starken Server haben. Aber, das VISU Backend hatte nun tausendfach so große Datenmengen als ursprünglich angedacht. Also haben wir uns dafür entschlossen, das Fundament - die VISU-Engine - dahingehend zu erweitern (unter Berücksichtigung der komplexen MPEG-Lizenzierung) so dass dies später möglich sein wird, wobei die Kameraintegration dann auf V2 verschoben wird. Also hier eine Misch-Entscheidung: Fundament ausbauen, damit es später möglich ist, aber die komplette Realisierung verschieben, damit es die V1 nicht noch länger dauert.
D. Schatz, kann ich das anders haben?: In den vergangenen Monaten haben wir für - unsere eigentlich tolle Modbus Implementierung - viel Kritik bekommen, weil man ein in aktiver Benutzung stehendes Modbus Profil nicht im Betrieb ändern kann und daher ein paar Klicks mehr (beim ein oder anderen ein paar Dutzend mehr Klicks) erforderlich sind. Wir waren hier davon ausgegangen, dass bei Kommunikation mit dritten Geräten ein Profil mit großer Sorgfalt erstellt wird und es eher selten Profiländerungen gibt. Bei der VISU, das war klar, steht nicht die Kompatibilität zu dritten Geräten im Vordergrund, sondern die Anpassung an den Geschmack des Benutzenden. Häufige Änderungen werden an der Tagesordnung sein. Eine Visu, die heute von Oma und Opa genutzt wird, soll morgen womöglich für Oma und Opa anders aussehen - für beide unterschiedlich. Was andere VISUs gar nicht können, also verschiedene VISUs parallel, kostet hier - mit dem besseren genialen VISU Manager - weniger als zehn Klicks. Mit dem ersten Klick wird eine Kopie erzeugt. Mit den anderen ein neue Instanz angelegt und der zweiten Instanz das kopierte Profil zugewiesen. Schon sind die Profile getrennt für OMA und OPA. Im Editor die gewünschten Änderungen an den Widgets geklickt und Fertig. Ok, Oma drückt im Visu Client nun nur noch auf die Instanz "OMA" und OPA... na erratet ihr selbst. Wir haben jegliche Einrichtung und nachträgliche Änderung so dermaßen einfach gemacht, dass ich selbst immer wieder beim Testen davon emotional ergriffen bin, weil es so geil geworden ist. Echt, das ist krass gut geworden.
Bei mechanischen Uhren gibt es den Begriff der Komplikation. Das ist, wenn eine Uhr noch zusätzliche Funktionen bekommt wie Stoppuhr, Counter, Kalender, Mondphasen usw. Schwierig wird es nun für eine Manufaktur, viele solche Komplikationen, die ja alle mechanisch realisiert sind, zusammen in einer Uhr unterzubringen, weil die Komplexität expontentiell zunimmt. Derzeit ist die Schweizer Manufaktur Vacheron Constantin mit der Reference 57260 der Rekordhalter mit unglaublichen 57 Komplikationen in einer Taschenuhr. Kostenpunkt 8 bis 10 Millionen Euro. Ein Einzelstück.
Die Timberwolf VISU hat auch sehr viele solcher "Komplikationen". Jedes einzelne für sich klingt einfach. Die schiere Summe an Einstellbarkeiten und deren Abhängigkeiten untereinander ist heftig in der Timberwolf VISU. Die Architektur darunter ist genial, das Bedienungskonzept finden wir sehr gelungen (ihr sagt uns dann schon noch, ob es dass auch ist). Es sind weit mehr als 57 Komplikationen, dafür ist Software einfacher als hunderte Zahnräder.
Was an dem Vergleich aber bleibt ist, dass der Aufwand mit jeder weiterer ineinandereingreifender Funktionen expontentiell zunimmt. Ich denke, die Software-Profis unter Euch werden, wenn wir das Ergebnis bereitstellen, feststellen, dass wir in der kurzen Zeit ein kleines Wunder hinbekommen haben. Die Software-Laien werden natürlich nur mit den Schultern zucken und sagen "und was bitte daran hat so lange gedauert?". Damit muss man als Entwicklerbude wohl leben.
3. Kommunikation
Es gibt keinen Königsweg.
Am besten wäre natürlich, gar nichts anzukündigen. Das haben wir in der Verhangenheit für das ein oder andere auch gemacht. Keinen Ton gesagt und plötzlich war ein neues Leistungsmerkmal schon verfügbar. Das vereinfacht alles. Aber bei einem Projekt in dieser Größenordnung, an dem das ganze Team zu 90% über ein dreiviertel Jahr arbeitet, können wir kaum die Kommunikation einstellen. Gar nichts zu sagen, woran wir arbeiten, geht da nicht.
Wir arbeiten aber daran, dass wir ein zweites Team haben und dann kann das eine an den großen Dinge im verborgenen arbeiten und ein anderes rollte alle zwei Monate was kleineres aus.
Aktuelle Zeitpläne sind schwierig, weil wir haben hundert JIRA Tickets auf englisch und das würde niemandem wirklich etwas sagen, wenn man das grafisch aufbereiten würde, das führt eher zu mehr nachfragen, fürchte ich.
Ein Kunde hat mir eine PN geschrieben und mir geraten, wir sollen doch die VISU einfach freigeben, wie sie jetzt ist, das wäre doch viel besser. Nein, das wäre es nicht. Solange wir noch bekannte Fehler haben oder einzelne Funktionen noch knirschen bringt es gar nichts, nun hundert Tester daran zu haben, die uns nun schreiben, dass sie die - uns bereits bekannten - Fehler gefunden haben. Weil dann haben wir eine nicht beherrschbare Ticketflut ohne Mehrwert (weil wir kennen die Fehler ja schon).
Darum, wir sind schon lange im Feature-Freeze und finishen derzeit alle Funktionen. Derzeit schließen wir zwei bis fünf Funktionen mit allen Tests ab und kommen dadurch gut vorwärts. Es sind einfach nur hunderte insgesamt und daher wird es noch ein paar Wochen fressen, zumal wir auch Urlaubszeit haben und immer einige der Entwickler gerade im Urlaub.
Ihr müsst also nicht mehr lange warten und die Herausgabe der IP4 ohne VISU erleichtert uns gerade die Supportfront, womit wir womöglich die Zeit, die wir für das Release der IP4 verbraucht haben, wieder hereinholen. Zumindest dann, wenn wir die Diskussion hier eingrenzen können.
Danke, ich schließe hier, weil Familie und ich wollen noch zum Strand. Das letzte Mal.
Stefan
heute ist mein letzter Tag im Urlaub (vor der zweitätigen Rückfahrt ab morgen), offenbar braucht es noch ein Statement..
Ganz Kurz:
DIE VISU VERZÖGERT SICH NICHT NOCHMAL SIGNIFIKANT
Kurz:
DIE HERAUSGABE DER IP4 OHNE VISU BEDEUTET NICHT, DASS SICH DIE VISU NOCHMAL SIGNIFIKANT VERZÖGERT, SONDERN HAT ANDERE GRÜNDE.
WIR HABEN FEATURE-FREEZE UND FINISHEN GERADE ALLE FUNKTIONEN, ES SIND EINFACH NUR DEREN SEHR VIELE.
==> WIR SIND AUF DER ZIELGERADEN UM DIE VISU AN DIE TESTER AUSZUROLLEN.
Länger:
1. IP4 ohne VISU
Wir haben die IP4 nicht deshalb "vorab" herausgebracht, weil wir einschätzen, das sich die VISU noch umfassend hinauszögern wird. Weil der ein oder andere Frust scheint sich gerade an dieser gedanklichen Vorstellung zu entzünden. Weil wir kommen gerade gut vorran mit der VISU.
Es gibt einen großen und zwei kleine Gründe, warum wir die die anderen Inhalte der IP4 nun ausgerollt haben.
A: Göran hat es schon geschrieben, es gab ein nerviges Problem mit der IP3 und hier sind zuletzt viele Supportfälle entstanden, das belastet uns auch im Tagesgeschäft und das wollten wir damit erledigen.
B: Es gibt eine Menge kleiner Verbesserungen in Logik, MQTT, Rest-API die für einige nicht nur wertvoll sind, sondern die auch von den Insidern getestet werden sollen. Wir hatten ein wenig Sorge, dass wenn wir alles zusammen mit der VISU rausgeben, dass die anderen Goodies nicht mehr getestet werden bzw. das "untergeht".
C: Zudem gibt es im Service häufiger (verständliche) Beschwerden, dass es schon seit längerem keine neue Software mehr gibt und wofür man denn bezahlen würde.
Zwar hatte eine Mehrheit der Insider dafür plädiert, dass wir lieber an der VISU weiterarbeiten sollen, aber wir achten auch auf die Minderheiten und so haben wir entschlossen, dass wir die bereits fertigen Komponenten - und vorallem den Fix für A. - ausrollen. Es hat auch noch den Vorteil, dass die darin enthaltenen Neuigkeiten in den Release Notes beschrieben sind, das spart uns dann die Zeit für die IP mit der VISU, diese anderen neuen Themen nochmal zu erklären. Weil es will auch nicht jeder die VISU.
2. Bisherige Terminschätzungen
Wie Göran auch richtigerweise schon erläutert hat, beziehen sich die jeweiligen Terminschätzungen auf den Kenntnisstand zu dem Zeitpunkt, wenn diese jeweils abgegeben werden. Wir wägen diese im Team ab und schätzen zusammen.
Ich entschuldige mich stellvertretend für das ganze Team, dass wir die jeweils kommunizierten Termine nicht eingehalten haben. Ja, wir verstehen auch die Frusttrationen, weil wir sind auch frustriert darüber. Niemand will in der Öffentlichkeit gerne als Wortbrecher dastehen.
Der Grund für die Verschiebungen sind übrigens keine unerwarteten technischen Schwierigkeiten, weil tatsächlich sind wir auf keine Probleme getroffen, die uns nicht vorher schon klar waren (das hatten wir also richtig eingeschätzt). Sondern der wesentliche Grund für die Verschiebungen ist, dass wir einfach bessere Ideen hatten.
Kurz: Alle Verzögerungen beruhen darauf dass die VISU besser werden kann.
Ein paar Beispiele:
A. "Mach´s nochmal Sam": Als wir die VISU im Video vom Frühjahr vorgestellt hatten, hatten wir eine erste Version des Clients und des Backends. Wir hatten zu dem Zeitpunkt nur rudimentäre Vorstellungen, hinsichtlich der Details des VISU Editors und fast keinen Plan über das VISU Management (weil gar nicht so klar war, dass wir das brauchen werden). Aber mit der Funktionalität mehrerer VISU Instanzen parallel, war das Management dann erforderlich geworden. Also wurde die Oberfläche für ein solches Management programmiert und ich hatte darüber auch schon das Video gedreht und war gerade in der Bearbeitung des Schnitts, als - zack - ein anderer Entwickler aus dem Urlaub kam und eine deutlich bessere Idee hatte wie man das Management ausführen sollte für einen möglichst einfachen Workflow des Benutzers. Schwierige Entscheidungslage, nehmen wir das "fast fertige, aber schlechtere" VISU Management oder implementieren die intuitivere Lösung mit dem besseren Workflow, dafür dauert es aber länger. Schwere Entscheidung, weil wir wollen fertig werden. Ein späterer Umbau mit "Visu V2" wäre eher unmöglich gewesen, weil man die DB dafür eben so oder so baut. Bei späteren Updates mehrere tausend laufende DBs von einem Schema auf ein anderes umbauen wäre sehr zeitintensiv, so dass man das eher läßt. Was tun? Nun, Ihr werdet es erraten, wir haben uns für das deutlich intuitivere Management V2 entschieden. Recht geben werdet Ihr uns später dafür nicht, weil ihr wisst ja nicht, wie es vorher war. Wenn man die neue Version sieht, wird man sagen, ja, ist gut so und klar würde man das so ausführen. Wir sind wirklich gut mit UI, aber es fällt uns nicht immer mit der ersten Realisierung das Optimale ein. Da ein späteres Nachliefern kaum möglich erschien, haben wir uns schweren Herzens (wegen der Verzögerung) dafür entschieden, es nochmal zu machen und damit haben wir das Management zweimal programmiert und denken, das dies die richtige Entscheidung war.
B. "Könnt Ihr nicht noch das?": Wir haben Testvorführungen bei einigen Integratoren und Endanwendern gemacht. Da kamen eine Reihe von Wünschen auf. Schatten hier, Hintergrund dort, Anzeigeoptionen, dies und jenes abschalten, das dort konfigurierbar, das hier umschaltbar, kann man dien Farbe hier auch anders haben. Nun, es entstand eine Liste mit zwei Dutzend weiteren Wünschen. Einiges verschieben wir schon in VISU V2, aber manches beeinflusst auch die Architektur und das nehmen wir dann gleich mit. Das führt dazu, dass der VISU Editor diese Dinge nun auch einstellbar haben muss, das Backend das speicherbar haben und der Client das empfangen und umsetzen muss. Also alles einmal alles in der Kette neu anfassen für solche Wünsche. Damt dies dann bei weiteren Features schneller geht, haben wir weitere Modularisierungen eingebaut und vor allem dass der Editor ein "Super-Json" verarbeiten kann, aus dem er sich für die jeweilgen Fähigkeiten des Widgets selbst dynamisch konfiguriert und auch weiß, was er wie in die Datenbank schreiben muss. Kurz, wir haben uns die Zeit genommen, eine "Konfigurationssprache" zu designen, dass wir künftige Änderungen und Wünsche viel leichter durchschieben können. Die Einstellung der Eigenschaften im VISU Editor ist damit nicht mehr hard codiert. Das war im Frühjahr nicht so dermaßen "rich" geplant. Dafür sind die Möglichkeiten damit nun wirklich toll und es gibt VIEL MEHR Einstellmöglichkeiten, als wir uns das ursprünglich gedacht haben. Das führt auch zu einer Änderung im Konzeot, dass man nicht mehr so viele Widgets anbieten muss, weil diese so mächtig konfiguriert werden kann. Ich denke, das werdet Ihr zu schätzen wissen, insbesondere auch in der Zukunft, weil wir leichter neue Widgets hinzufügen können. Ja, hat Zeit gekostet, aber hat die Architektur und den Editor massiv vorangebracht um bessere Widgets zu bauen und leichter künftige Wünsche erfüllen zu können. Der Mehrwert ist gegenüber der aufgewendeten Zeit beträchtlich und in unseren Augen eine sinnvolle Investition. Kurz, daher jetzt länger, dafür sind andere Wünsche künftig deutlich schneller umsetzbar, da werden sich manche noch die Augen reiben, was damit möglich wird.
C. "Das Haus kann nur so groß werden wie das Fundament" oder "Entweder gescheit machen oder lassen": Als wir das Thema Kameraintegration näher untersucht haben, haben wir festgestellt, dass dies beim Wettbewerb eher schlecht gelöst ist. Manche Kunden bezeichneten uns gegenüber bei Umfragen die Lösungen der Konkurrenz als "Unverschämtheit". So ein Fehler sollte uns nicht passieren und wir haben geprüft, was denn das Problem an der Lösung der Marktbegleiter ist. Kurz, praktisch alle realisieren da so, dass die Visu-Clients sich den Feed direkt von der Kamera holen. Das Problem ist, viele Kameras können nur einen Feed, manche zwei. Da passiert es dann, dass wenn ein weiterer Client dazu kommt, der Feed bei der ersten Visu dann ausfällt. Globale Nutzung geht dann auch nicht. Aufzeichnungen oder Zugriff darauf auch nicht dabei. Unsere Lösung ist, dass die Kamera den Stream an den Server gibt und der diesen dann für alle seine Clients vervielfacht. Geht natürlich auch nur deshalb, weil wir so einen starken Server haben. Aber, das VISU Backend hatte nun tausendfach so große Datenmengen als ursprünglich angedacht. Also haben wir uns dafür entschlossen, das Fundament - die VISU-Engine - dahingehend zu erweitern (unter Berücksichtigung der komplexen MPEG-Lizenzierung) so dass dies später möglich sein wird, wobei die Kameraintegration dann auf V2 verschoben wird. Also hier eine Misch-Entscheidung: Fundament ausbauen, damit es später möglich ist, aber die komplette Realisierung verschieben, damit es die V1 nicht noch länger dauert.
D. Schatz, kann ich das anders haben?: In den vergangenen Monaten haben wir für - unsere eigentlich tolle Modbus Implementierung - viel Kritik bekommen, weil man ein in aktiver Benutzung stehendes Modbus Profil nicht im Betrieb ändern kann und daher ein paar Klicks mehr (beim ein oder anderen ein paar Dutzend mehr Klicks) erforderlich sind. Wir waren hier davon ausgegangen, dass bei Kommunikation mit dritten Geräten ein Profil mit großer Sorgfalt erstellt wird und es eher selten Profiländerungen gibt. Bei der VISU, das war klar, steht nicht die Kompatibilität zu dritten Geräten im Vordergrund, sondern die Anpassung an den Geschmack des Benutzenden. Häufige Änderungen werden an der Tagesordnung sein. Eine Visu, die heute von Oma und Opa genutzt wird, soll morgen womöglich für Oma und Opa anders aussehen - für beide unterschiedlich. Was andere VISUs gar nicht können, also verschiedene VISUs parallel, kostet hier - mit dem besseren genialen VISU Manager - weniger als zehn Klicks. Mit dem ersten Klick wird eine Kopie erzeugt. Mit den anderen ein neue Instanz angelegt und der zweiten Instanz das kopierte Profil zugewiesen. Schon sind die Profile getrennt für OMA und OPA. Im Editor die gewünschten Änderungen an den Widgets geklickt und Fertig. Ok, Oma drückt im Visu Client nun nur noch auf die Instanz "OMA" und OPA... na erratet ihr selbst. Wir haben jegliche Einrichtung und nachträgliche Änderung so dermaßen einfach gemacht, dass ich selbst immer wieder beim Testen davon emotional ergriffen bin, weil es so geil geworden ist. Echt, das ist krass gut geworden.
Bei mechanischen Uhren gibt es den Begriff der Komplikation. Das ist, wenn eine Uhr noch zusätzliche Funktionen bekommt wie Stoppuhr, Counter, Kalender, Mondphasen usw. Schwierig wird es nun für eine Manufaktur, viele solche Komplikationen, die ja alle mechanisch realisiert sind, zusammen in einer Uhr unterzubringen, weil die Komplexität expontentiell zunimmt. Derzeit ist die Schweizer Manufaktur Vacheron Constantin mit der Reference 57260 der Rekordhalter mit unglaublichen 57 Komplikationen in einer Taschenuhr. Kostenpunkt 8 bis 10 Millionen Euro. Ein Einzelstück.
Die Timberwolf VISU hat auch sehr viele solcher "Komplikationen". Jedes einzelne für sich klingt einfach. Die schiere Summe an Einstellbarkeiten und deren Abhängigkeiten untereinander ist heftig in der Timberwolf VISU. Die Architektur darunter ist genial, das Bedienungskonzept finden wir sehr gelungen (ihr sagt uns dann schon noch, ob es dass auch ist). Es sind weit mehr als 57 Komplikationen, dafür ist Software einfacher als hunderte Zahnräder.
Was an dem Vergleich aber bleibt ist, dass der Aufwand mit jeder weiterer ineinandereingreifender Funktionen expontentiell zunimmt. Ich denke, die Software-Profis unter Euch werden, wenn wir das Ergebnis bereitstellen, feststellen, dass wir in der kurzen Zeit ein kleines Wunder hinbekommen haben. Die Software-Laien werden natürlich nur mit den Schultern zucken und sagen "und was bitte daran hat so lange gedauert?". Damit muss man als Entwicklerbude wohl leben.
3. Kommunikation
Es gibt keinen Königsweg.
Am besten wäre natürlich, gar nichts anzukündigen. Das haben wir in der Verhangenheit für das ein oder andere auch gemacht. Keinen Ton gesagt und plötzlich war ein neues Leistungsmerkmal schon verfügbar. Das vereinfacht alles. Aber bei einem Projekt in dieser Größenordnung, an dem das ganze Team zu 90% über ein dreiviertel Jahr arbeitet, können wir kaum die Kommunikation einstellen. Gar nichts zu sagen, woran wir arbeiten, geht da nicht.
Wir arbeiten aber daran, dass wir ein zweites Team haben und dann kann das eine an den großen Dinge im verborgenen arbeiten und ein anderes rollte alle zwei Monate was kleineres aus.
Aktuelle Zeitpläne sind schwierig, weil wir haben hundert JIRA Tickets auf englisch und das würde niemandem wirklich etwas sagen, wenn man das grafisch aufbereiten würde, das führt eher zu mehr nachfragen, fürchte ich.
Ein Kunde hat mir eine PN geschrieben und mir geraten, wir sollen doch die VISU einfach freigeben, wie sie jetzt ist, das wäre doch viel besser. Nein, das wäre es nicht. Solange wir noch bekannte Fehler haben oder einzelne Funktionen noch knirschen bringt es gar nichts, nun hundert Tester daran zu haben, die uns nun schreiben, dass sie die - uns bereits bekannten - Fehler gefunden haben. Weil dann haben wir eine nicht beherrschbare Ticketflut ohne Mehrwert (weil wir kennen die Fehler ja schon).
Darum, wir sind schon lange im Feature-Freeze und finishen derzeit alle Funktionen. Derzeit schließen wir zwei bis fünf Funktionen mit allen Tests ab und kommen dadurch gut vorwärts. Es sind einfach nur hunderte insgesamt und daher wird es noch ein paar Wochen fressen, zumal wir auch Urlaubszeit haben und immer einige der Entwickler gerade im Urlaub.
Ihr müsst also nicht mehr lange warten und die Herausgabe der IP4 ohne VISU erleichtert uns gerade die Supportfront, womit wir womöglich die Zeit, die wir für das Release der IP4 verbraucht haben, wieder hereinholen. Zumindest dann, wenn wir die Diskussion hier eingrenzen können.
Danke, ich schließe hier, weil Familie und ich wollen noch zum Strand. Das letzte Mal.
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 2217
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1979 Mal
- Danksagung erhalten: 885 Mal
Ich finde die Entscheidungen die in den vier aufgezeigten Fällen (A-D) zeigen das ihr ganzheitliche und wichtige Entscheidungen treffen musstet und gemacht habt. Das finde ich genau Richtig, weil am Core baut man selten und der muss essentiell stabil sein.
Das habt ihr jetzt aufgebaut und damit eine bessere und einfachere Zukunft für Erweiterungen geschaffen. Stehe da hinter eurer Entscheidung. Daumen Hoch
Danke an dich @StefanW und das gesamte Team für die tolle Arbeit und das Herzblut was ihr in die Funktionen steckt. Natürlich auch an deine Frau die stabil hinter dir und der Firma steht.
Das habt ihr jetzt aufgebaut und damit eine bessere und einfachere Zukunft für Erweiterungen geschaffen. Stehe da hinter eurer Entscheidung. Daumen Hoch
Danke an dich @StefanW und das gesamte Team für die tolle Arbeit und das Herzblut was ihr in die Funktionen steckt. Natürlich auch an deine Frau die stabil hinter dir und der Firma steht.
Zuletzt geändert von Sun1453 am Fr Sep 01, 2023 3:00 pm, insgesamt 1-mal geändert.
Gruß Michael
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
-
- Reactions:
- Beiträge: 261
- Registriert: Do Jan 20, 2022 6:15 pm
- Wohnort: Germering
- Hat sich bedankt: 167 Mal
- Danksagung erhalten: 169 Mal
- Kontaktdaten:
@StefanW Jetzt muss ich echt mal schimpfen mit Dir. Urlaub ist dazu da dass Du Dich erholst und Dich nicht mit Kommentaren im Forum beschäftigst. Wenn da 3 Wochen mal nix von Dir kommt springt kein Kunde ab - also wie Peter Lustig von Löwenzahn immer schon sagte „abschalten“.
/*Schimpfen Ende*
Inhaltlich:
Das mit den Verschiebungen kann auch nach dem Urlaub diskutiert werden. Ich denke viele haben einfach Angst, dass sie ein Paket abonnieren und in der Abozeit kommen die erhofften Features nicht die für den ein oder anderen kaufentscheidend waren. Da habe ich „Kulanz“ verstanden und das ist super.
Ihr müsst echt aber auch in der Urlaubszeit mal zur Ruhe kommen, Du als GF und das Team - Notfallsupport ist klar und mit gehäuften Supportfällen habt ihr auch IP4 verargumentiert, passt.
/*Schimpfen Ende*
Inhaltlich:
Das mit den Verschiebungen kann auch nach dem Urlaub diskutiert werden. Ich denke viele haben einfach Angst, dass sie ein Paket abonnieren und in der Abozeit kommen die erhofften Features nicht die für den ein oder anderen kaufentscheidend waren. Da habe ich „Kulanz“ verstanden und das ist super.
Ihr müsst echt aber auch in der Urlaubszeit mal zur Ruhe kommen, Du als GF und das Team - Notfallsupport ist klar und mit gehäuften Supportfällen habt ihr auch IP4 verargumentiert, passt.
Zuletzt geändert von cybersmart am Fr Sep 01, 2023 4:33 pm, insgesamt 2-mal geändert.
VG, Uwe
timberwolf765 VPN: closed Reboot: no
timberwolf765 VPN: closed Reboot: no
-
- Elaborated Networks
- Reactions:
- Beiträge: 10713
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5303 Mal
- Danksagung erhalten: 8685 Mal
- Kontaktdaten:
Hallo Sebastian,
Ja. Es ist vorgesehen, dass man in der erweiterten Ansicht eines Widgets bis fünf Zeitserien anzeigen kann.
Ein andisktuierter Gedanke ist, dass lokal im Server eine Browser-Engine läuft, in welcher Grafana läuft und von der Grafik werden dann die Screenshots in das Widget kopiert. Aber auch nicht trivial.
lg
Stefan
Sebastian104 hat geschrieben: ↑Fr Sep 01, 2023 1:09 pmAbgesehen davon, hätte ich eine Frage zur Darstellung von Zeitserien in der Visu. Ich habe gelesen das eine einfache Darstellung (z.B. PV Anlagen) möglich sind. Wird es auch die Möglichkeit geben, mehrerer Zeitserien in einem Widget darstellen?
Ja. Es ist vorgesehen, dass man in der erweiterten Ansicht eines Widgets bis fünf Zeitserien anzeigen kann.
Das ist nicht geplant. Aber der Aufruf einer separaten Tab (so wie bei der jetzigen Web-APP auch) dürfte technisch möglich sein bei der Web-APP-Ausführung der VISU. Ob es sinnhaft ist? Weil man kann sich auch gleich die Grafana-Page als Icon hinterlegen.Sebastian104 hat geschrieben: ↑Fr Sep 01, 2023 1:09 pmOder kann ich vielleicht sogar Grafana Dashboards anzeigen lassen (über eine Pop-Up Widget oder so...).
Das ist technisch sehr herausfordernd, weil letztlich müsste der Grafana Code in unserer APP laufen. Ganz abgesehen vom Lizenzrecht wäre es auch teschnisch sehr aufwändig, die Grafana Dashboard-Funktion in ein Widget zu packen.Sebastian104 hat geschrieben: ↑Fr Sep 01, 2023 1:09 pmHintergrund ist folgender: ich bin gerade dabei, mir in Grafana ein paar Energie Dashboards zu bauen... (verschiedene Stromverbräuche, Spitzenlast, Gas-/Wasserverbrauch, etc.) Natürlich würde ich dies irgendwie gerne in die Visu integrieren. Ist sowas aktuell vorgesehen oder später geplant?
Ein andisktuierter Gedanke ist, dass lokal im Server eine Browser-Engine läuft, in welcher Grafana läuft und von der Grafik werden dann die Screenshots in das Widget kopiert. Aber auch nicht trivial.
lg
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 576
- Registriert: Mo Dez 02, 2019 5:38 am
- Wohnort: Freital
- Hat sich bedankt: 424 Mal
- Danksagung erhalten: 237 Mal
Wäre es denn möglich ein aktuelles Bild des benötigten Grafana Dashboards in der Visu anzuzeigen?
Grafana stellt ja links zur verfügung welche dann nur ein Bild des dashboards anzeigen
Grafana stellt ja links zur verfügung welche dann nur ein Bild des dashboards anzeigen
Grüße Micha
TWS 3500 XL #1209 + TWS 2600 #528 + PBM #972,
VPN offen, Reboot möglich
PLZ 01...
TWS 3500 XL #1209 + TWS 2600 #528 + PBM #972,
VPN offen, Reboot möglich
PLZ 01...