StefanW hat geschrieben: ↑So Jan 22, 2023 11:12 amIch bitte Dich das auch nicht als Werturteil gegen die CometVisu zu verstehen.
Habe ich auch nicht. Jeder muss das machen was für sein System optimal ist. So hat der TWS die CometVisu nicht exklusiv, und die CometVisu läuft ja auch auf viel mehr als nur dem TWS.
StefanW hat geschrieben: ↑So Jan 22, 2023 11:12 am
Es ist nur so, dass eine Machbarkeitsanalyse auf Basis eines Fork der CV zur Meinung geführt hat, dass der Integrationsaufwand umfassender würde, als eine eigene Visu inkl. Integration zu erstellen.
Das hängt mit dem alten Problem aller Programmierer zusammen: Code lesen ist wesentlich schwieriger als Code zu schreiben. Deswegen gibt es so viele häufig verwendete Sachen in unzähligen Implementierungen.
Sobald Du aber den Bereich der trivialen Funktionen verlässt, Software-Pflege dazu kommt, unterschiedlichste Laufumgebungen, ... wird das ganz anders. Ich tendiere bei der Aufwandsschätzung auch immer dazu den massiv zu unterschätzen, gerade weil ich nur die par Ziel-Funktionen im Sinn habe und das ganze bremsende außenherum vergesse. Wie schnell sind denn - gerade prototypisch - ein paar Seiten Code geschrieben? Und doch schafft ein Programmierer effektiv nur 10 - 50 Zeilen Code am Tag(!) (
https://de.wikipedia.org/wiki/Lines_of_Code)
Genau aus diesem Grund hatte ich (zum ersten mal!) schätzen lassen, was die CometVisu Wert ist, bzw. deren Herstellung in einem professionellen Umfeld kosten würde. Und wenn ich mir anschaue wie viele verschiedene Leute beigetragen haben, dann finde ich den ausgespuckten Preis durchaus realistisch.
Genau daher wünsche ich Euch ja auch, dass ihr Euch damit nicht überhebt. Denn 12 Mio Euro nur durch TWS und Paket-Verkauf wieder rein zu holen ist schon eine große Aufgabe. Und dann ist damit noch nicht mal die für ein Unternehmen notwendige Rendite mit eingerechnet. Und den Kunden kostet dass das auch noch mit Mehrwertsteuer. D.h. es müssen ca. 20 Mio Euro vom Kunden nur dafür fließen, dass eine weitere Visu im Umfang der CometVisu vorhanden ist. Es würde mich sehr freuen, wenn Du dass schaffst und nicht wider in "das Problem" von vor ein paar Jahren rutschst.
StefanW hat geschrieben: ↑So Jan 22, 2023 11:12 am
Wir möchten die Visu DIREKT mit dem Objektsystem verbinden. D.h. es entstehen Visu-Objekte die direkt mit dem Widget gekoppelt sind, ohne ein zwischengeschaltetes Bussystem (sei es KNX oder MQTT). Bei einer anderen Visu würde das bedeuten, dass wir die Kommunikation umbauen müssen, das erachten wir als aufwändig.
[...]
Wir möchten auch interne Zustände des Servers in der App mitaufnehmen und auch die vorhandene Benutzerverwaltung übernehmen.
Klar, das fehlt eindeutig. Ein Backend zu schreiben ist aber nicht aufwändig. Eines für das CometVisu-Protokoll hab ich in mehreren Programmiersprachen schon mehrfach gemacht.
Alternativ kann man natürlich der CometVisu auch beibringen mit einem anderen Protokoll zu sprechen. Neben dem CometVisu-Protokoll und den SSE für OpenHab kann die ja inzwischen auch MQTT. Also kein Hexenwerk da was weiteres einzubauen.
StefanW hat geschrieben: ↑So Jan 22, 2023 11:12 am
Native APPs. Es gibt Kunden, die sich die Visu als native App wünschen, die direkte Konkurrenz hat diese ja auch. Ja, klar kann man Browser mit Bookmark auch als Icon hinterlegen, noch VPN dazu, aber für Tante Erna ist dass dann schon schwieriger. Und wenn man bei eigener Abwesenheit (z.B. Urlaub) einem Handwerker Einlass und ggfl. Zugang zur Visu geben muss, dann dürfte das gar nicht gehen. Mit einer App im Appstore, der Server-ID und Username / Passwort wäre das dann gleich was anderes.
Das ist kein (zwingendes) Thema einer Visu. Das ist eine Schicht oben drüber. Ob man das für die CV oder irgend eine andere (Web-)Visu macht, macht keinen Unterschied und bedeutet den gleichen Aufwand.
Oder Du programmierst gleich eine App. Also zwei, 1x Andorid und 1x iOS. Hast dann aber die ganzen PCs/Laptops und Touch-Panel-PCs in der Wand ausgeschlossen. Also gleich noch 1x Windows, 1x MacOS und 1x Linux dazu. Also statt 1x Web gleich 5 Programme
StefanW hat geschrieben: ↑So Jan 22, 2023 11:12 am
Bei der CometVisu sehen wir auch Ablehnung in den Reihen der Kunden, die man eben auch zur Kenntnis nehmen muss. Die mag womöglich ungerecht und oberflächlich sein, aber so ist die Welt, mussten wir beim Server auch so erleben, dass der ein oder andere große Reden in sozialen Medien gegen den Timberwolf Server schwingt, obwohl man an seinen Aussage erkennt, dass er keine Ahnung hat. Solche Meinungsbilder haben meist auch einen wahren Kern und das bedeutet für uns, dass wir etwas eben falsch oder nicht gut vermittelt haben.
Auch wenn das natürlich weh tut wenn jemand anderes, wie Du schreibst meist sogar sehr unqualifiziert, über das eigene Baby herzieht - das ist normal und zeigt eigentlich nur, dass die Basis der angesprochenen Leute breiter wird.
Wenn man das zu ernst nimmt was geschrieben wird, dann würde keiner mehr einen BMW kaufen, so wie die von Audi-Fans in den sozialen Medien zerrissen wird. Aber es würde auch keiner mehr einen Audi kaufen, so wie der wiederum von den anderen Fans zerrissen wird. Und das alles ist sowieso unverkäuflich, wie die Tesla-Jünger zu berichten wissen. Etc. pp.
Letztendlich kann man mal schauen welche Punkte valide sind und an denen arbeiten. Den Rest muss man einfach ignorieren - denn wenn dem Nörgler was anderes besser gefällt, soll er halt das nehmen. Stecke ich 5 Minuten meiner Zeit in einen Streit mit dem, so stimme ich ihn eh nicht um. Stecke ich die dagegen in die Weiterentwicklung, dann haben alle was davon: die bestehenden Nutzer und die zukünftigen Nutzer. (Und, vielleicht sogar irgendwann mal, auch der Nörgler)
StefanW hat geschrieben: ↑So Jan 22, 2023 11:12 am
Es ist nicht so, dass wir keine Erfahrung haben und das gar nicht überblicken können. Mit der Management Web-APP haben wir letztlich eine komplexe Visu zur Einrichtung und dem Management des Servers erstellt, es liegt also durchaus Erfahrung darin vor, aktuelle Zustände in Echtzeit hin- und her zu übertragen. Wir können also durchaus aus Erfahrung schöpfen.
Im Web in Echtzeit Zustände zu übermitteln dürfte die CometVisu als erste von allen gemacht haben - das galt damals als unmöglich. Konnte daher bereits die aller erste Version, die sonst noch nicht viel konnte. Und inzwischen ist das mit den modernen Möglichkeiten des Webs sogar noch viel einfacher geworden.
Aus Spaß mal geschaut: im ersten Release hat dieser Teil 161 Code-Zeilen.
Die Komplexität ist eine Visu aus der Kommunikation zu machen - das waren damals 342 Code-Zeilen.
Fast Forward auf heute, mit der Möglichkeit für komplexe Layouts, einem Editor und Manager:
Der Code für die Echtzeitkommunikation hat 345 Zeilen (+ den für die anderen Protokolle und noch bisschen Infrastruktur außen herum, wie einen Watchdog).
Der Code für alles 219k Zeilen.
Wenn Du nun eine statische Visu machst, bei der z.B. aus einer Gebäude-Struktur-Info starr eine Visu erzeugt wird, so kannst Du den Visu-Teil natürlich gering halten. Das entspricht der Komplexität der aktuellen TWS Web-Oberfläche - der Kunde hat keine Wahl was wo steht. Ihr hab 100% Kontrolle darüber.
Das werden die Kunden aber nicht akzeptieren. Die wollen dann schon noch Änderungen vornehmen, was dann immer näher an eine voll flexible Visu kommt. Und damit in genau die gleiche Komplexitäts-Kategorie wie die CometVisu fällt. Wenn Euch kein Trick einfällt die Komplexität deutlich zu reduzieren, so wird das Zielprodukt gleich komplex sein und damit vergleichbar teuer. Ich befürchte das dieser Teil der Komplexität von Dir gerade massiv unterschätzt wird.