UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[NEUHEIT] [V 1.6 IP3] 2. Juni 2020: "Version 1.6 - Insider Preview 3" verfügbar - Alle Modellversionen

Neue Produkte, Rollouts, Änderungen, Aktionen
Forumsregeln
  • Bitte daran denken, dass für technische Probleme mit der Firmware, die NICHT die Installation selbst betreffen, jeweils ein separater Thread zu eröffnen ist. Bei Insider Versionen dann im entsprechenden Insider-Unterforum
  • 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

Wie war Eure Erfahrung mit der Installation dieses Upgrades (Antwort nachträglich änderbar)

Umfrage endete am Sa Aug 01, 2020 10:30 pm

Erfahrung: Alles Super, keine Probleme bisher
57
95%
Erfahrung: Installation hat gut funktioniert, aber kleine Probleme im Anschluss festgestellt
2
3%
Erfahrung: Hatte größere Probleme mit dem Update selbst bzw. danach
0
Keine Stimmen
Ich warte erstmal ab und beziehe die Insider Preview erst in ein paar Tagen
1
2%
Ich warte etwas länger ab und beziehe die Insider Preview wohl erst in einer Woche oder später
0
Keine Stimmen
 
Insgesamt abgegebene Stimmen: 60


Smart Jeanie
Reactions:
Beiträge: 64
Registriert: Mo Sep 10, 2018 3:10 pm
Hat sich bedankt: 92 Mal
Danksagung erhalten: 68 Mal

#31

Beitrag von Smart Jeanie »

Hallo Stefan,
StefanW hat geschrieben: Fr Jun 05, 2020 7:54 am Ich bitte darum, dass eventuelle Probleme mit unbekannter externer Hardware nicht "schlecht" angerechnet werden. n
Die Nicht-Zählung fände ich keine gute Lösung. Besser fände ich es, die Umfrage zu ändern, so dass man erkennen kann in welchem Umfeld die Probleme lagen, z.B. mit den Docker-Containern.
Auf diese Weise kann ich mir als Anwender mit steigender Zahl an Rückmeldungen ein Bild davon machen, wo am ehesten Probleme zu erwarten sind und ob ich davon betroffen sein kann.
Die Abfrage wird man nicht für alle Releases gleichartig oder feingliedrig hinbekommen, aber bestimmte Themen scheinen ja immer dabei zu sein, wie einzelne Container mit ihrem Inhalt, angeschlossene Fremdhardware etc. Dass das nicht auf Euren "Deckel" geht, das sehe ich genauso.

Mit den Docker-Containern habe ich persönlich ein anderes Problem. Ich selbst würde diese weitestgehend vermeiden wollen und primär auf TWS-native Funktionen setzen. Deren Bereitstellung verzögert sich. Ein Grund ist Euer Anspruch an Perfektion. Fehlerfreiheit ist schön, aber unwirtschaftlich. Und Perfektion ist auch nicht kundenfreundlich. Mein Swiss Mulitool kann 20 Dinge gut, aber nichts davon sehr gut. Für jedes dieser 20 Dinge habe ich ein perfekteres Werkzeug. Trotzdem benutze ich das Multitool häufig. So sähe ich den TWS auch gern. So gesehen ärgert es mich ein wenig, wenn Du hier so ehrlich bist zu schreiben, dass die Quotierung von Docker-Containern bei den Hutschienenmodellen 2-3 Mannwochen benötigt. Da ich selbst Container vermeiden möchte und selbst wenn ich sie nutzte, dieses Feature nicht erwarte, fände ich es als "normaler" TWS-Nutzer besser, diese Entwicklerkapazitäten würden nicht in eine perfekte Docker-Verwaltung gesteckt, sondern in TWS-native Funktionen, also in die nächsten Dinge, die der TWS wie ein Multitool gut kann. Sorry, aber wer mit Containern "experimentiert", dem muss es dann auch mal reichen, wenn er für sich bei Problemen die Dinge bewertet, die Ihr ihm heute bereits anzeigt. Ihr seid nicht die Hausmeister des Universums. Ihr müsst nicht jeden selbst verursachten Dreck aufräumen. Wenn jemand Admin spielen möchte, dann muss er es irgendwann auch sein. Deswegen für mich wenig Docker. Mehr und schneller TWS-nativ und gerne auch weniger perfekt.
Zuletzt geändert von Smart Jeanie am Fr Jun 05, 2020 12:11 pm, insgesamt 1-mal geändert.
Markus

TWS 950Q #268, Software-Stand V3.5x, nicht in Verwendung
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#32

Beitrag von starwarsfan »

Hallo miteinander,

das Update von IP2 auf IP3 hat ohne Probleme funktioniert. :handgestures-thumbupright:
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

paralan
Reactions:
Beiträge: 264
Registriert: Mi Sep 05, 2018 11:49 pm
Hat sich bedankt: 287 Mal
Danksagung erhalten: 102 Mal

#33

Beitrag von paralan »

Hallo,
auch bei mir hat das Update reibungslos funktioniert. Alle Docker sind gestartet. Alle Services sind aktiv. Die neue Übersicht für Docker ist genial!
Limits sind aktiviert!
:handgestures-thumbupright:
Gruß Alan

TWS 2600 ID:190; VPN offen; Reboot nach Absprache, da Beschattung über Logikeditor aktiv!

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#34

Beitrag von StefanW »

Hallo Markus, danke für Deinen Beitrag, fand ich sehr gut.
Smart Jeanie hat geschrieben: Fr Jun 05, 2020 12:09 pmDie Nicht-Zählung fände ich keine gute Lösung. Besser fände ich es, die Umfrage zu ändern, so dass man erkennen kann in welchem Umfeld die Probleme lagen, z.B. mit den Docker-Containern.
Da kann man durchaus daran denken. Nur müssen wir eben auch realistisch bleiben. An den TWS kann man hunderte Geräte anschließen mit tausenden Funktionen. Wir kennen weder alle diese Geräte noch Funktionen der Kunden und mit Docker kommen dann auch nochmal völlig andere Geräteklassen und Möglichkeiten hinzu. Es ist unmöglich alles zu testen, was es auf der Welt gibt und angeschlossen werden kann.

Würden wir für alle damit zusammenhängenden Problemklassen eine Statistik erheben, könnte ein oberflächlicher Betrachter den Eindruck bekommen, beim TWS funktioniert nichts. Wir dürfen nicht vergessen, dass wir uns in einer Bewertungsgesellschaft befinden und zuviele "Dislikes" aka Negativbewertungen einen großen Schaden auslösen können. Nicht jeder Nutzer versteht, dass er in seinem Smarthome zum Integrator wird und manche Funktionen auch erobert und administriert werden müssen und das andauernde Einspielen von Updates und Firmware von der Kamera bis zum intelligenten Schlüsselbund das Szenario jeweils neu aufstellt und der Server zwar viel kann aber nicht jedes Kompatibilitätsproblem der Welt beheben kann.

Würden wir also jeden kleinen Schluckauf erfassen, könnte ein falscher Eindruck entstehen. Daher plädiere ich dafür, dass in der Statistik der Updatequalität nur die direkten und supporteten Kernfunktionen gemessen werden, damit wir auch eine klare Kennzahl haben, nach der wir uns richten können, wenn wir entscheiden aus einer Insider Version eine Hauptversion zu machen.

Es bleibt dem Nutzer ja unbenommen, hier im Textteil zu berichten, welche Funktionen angeschlossener Komponenten womöglich Aufwand verursacht haben, wobei ich mir wünsche, dass erst geprüft und dann geschossen wird, weil in zwei Drittel der Fälle hatte es nicht mal indirekt mit dem Update zu tun, sondern ist ein zufälliges zeitliches Zusammentreffen (wobei es meistens nur an der erhöhten Aufmerksamkeit nach einem Update liegt).


Smart Jeanie hat geschrieben: Fr Jun 05, 2020 12:09 pmAuf diese Weise kann ich mir als Anwender mit steigender Zahl an Rückmeldungen ein Bild davon machen, wo am ehesten Probleme zu erwarten sind und ob ich davon betroffen sein kann.
Gerade bei sehr speziellen Docker Problemen mit einem speziellen USB Device (wobei das gemeldete Problem in diesem speziellen Fall mit einem USB Device zusammen hängt, das im Forum schon öfters negativ aufgetaucht ist, weil der Hersteller den USB Chip nicht - oder nicht korrekt - initialisiert hat und dieses nun die Kunden selbst mit einem Tool vornehmen müssen und diese Initialisierung womöglich nicht perfekt verläuft). Mit anderen Worten: Kaum übertragbar auf andere Fälle und nichts was mit dem Timberwolf Server zu tun hat.

Smart Jeanie hat geschrieben: Fr Jun 05, 2020 12:09 pm.... und primär auf TWS-native Funktionen setzen. Deren Bereitstellung verzögert sich. Ein Grund ist Euer Anspruch an Perfektion. Fehlerfreiheit ist schön, aber unwirtschaftlich. Und Perfektion ist auch nicht kundenfreundlich. Mein Swiss Mulitool kann 20 Dinge gut, aber nichts davon sehr gut. Für jedes dieser 20 Dinge habe ich ein perfekteres Werkzeug. Trotzdem benutze ich das Multitool häufig. So sähe ich den TWS auch gern.
Nun, nach meiner Analyse und dem was wir im Support erleben, deckt sich Deine Meinung nicht mit dem Wunsch der meisten anderen Kunden und den wirtschaftlichen Folgen.

Ich verstehe den Vergleich des Multitool hinsichtlich der vielen Eigenschaften des Timberwolf Servers. Aber so ein Multi Tool ist als Kompromiss gebaut worden, dessen Haupteinsatz der mobile ist. Es muss in die Tasche passen, dem ordnet sich alles unter. Und im Notfall ist ein schlechtes Messer im Wald besser als das tolle Messer das Zuhause liegt.

So ein Server muss dagegen den ganzen Tag funktionieren, optimalerweise Jahrzehnte lang mit einer extremen Verfügbarkeit von 99,99 % oder besser. Im Zusammenhang mit hunderten anderen Geräten. Die Kunden wollen dafür keinen Kompromiss, das muss einwandfrei funktionieren. Jedesmal. Ein mir bekannter KNX Entwickler ist mal auf eine fünfstellige Summe verklagt worden, weil in einer Handvoll Fälle ein Licht im Haus nicht angegangen war. Man darf ja nicht vergessen, dass es nicht nur nette Menschen gibt.



Ob man mit so einem komplexen Produkt am Ende auch Geld verdient, ergibt sich aus der Stückzahl und wie aufwändig der Support ist. Stückzahl erzielt man nur, wenn das Gerät eine gute Bewertung bekommt und vor allem die professionellen Kunden das Gerät zigmal für deren Kunden kaufen. Das Gerät muss also TOP funktionieren, einfach bedienbar sein, nicht ausfallen und auf gar keinen Fall darf es beim Endkunden Probleme machen für die dann der Integrator Ärger mit seinem Kunden hat. Weil dann kauft er es nie wieder. Support in dieser Komplexitätsklasse kostet uns um die 120.- EUR pro Stunde. Und es gibt Integratoren die für den Austausch fehlerhafter Komponenten oder Fehlersuche vom Hersteller bezahlt werden wollen (Schadensersatz).

Unser Anspruch an Perfektion entsteht durch die Anforderung der Kunden. Fehlerfreiheit IST definitiv wirtschaftlich, weil ein einzelner kleiner Fehler, den ein Integrator in einer Kundenanlage hat, er deswegen hinfahren, Fehler suchen und das problem eingrenzen muss, womöglich unseren Support bemühen, gemeinsam weiter an der Ursache suchen, kann gut und gerne 1000 EUR an Arbeitszeit kosten.

Wir hatten vor drei Monate so einen Fall. Integrator ruft aufgeregt an, der KNX Bus geht nicht, am Abend ist Vorführung und Abnahme, der Server funktioniert mit KNX nicht. Großes Theater, mehrere Mitarbeiter involviert, zuerst First Level, dann Second Level und wegen der Dringlichkeit den Entwickler hinzugezogen, zusammen nach dem Fehler gesucht, Traces ausgewertet, Messungen vornehmen lassen. Nach einigen Arbeitsstunden stellt sich heraus: Ursache war ein Adernbruch im KNX Kabel, dadurch intermittierende Aussetzer auf der Leitung. Vorführung gerettet, ein ansehnlicher dreistelliger Betrag im Support verloren.

Ergebnis: Wir haben eine diesbezügliche Meldung in den Stack eingebaut, der bei den KNX Interfaces nun angezeigt wird. Künftig kann der Kunde das selbst sehen, weil es im Log angezeigt wird. Auch weil viele Nutzer das so erwarten. Mancher Nutzer würde die Schuld nicht dem Adernbruch oder dem womöglich handwerklichen Fehler beim Abisolieren suchen, bei dem die dünne Ader so gekerbt wurde, dass diese nach mehrmaligen Knicken bricht und das womöglich so unter der leicht verschobenen Isolierung, dass man es nicht sieht. Es gibt nunmal eine gewisse Nutzerschicht, welche in solch einem Fall die die Schuld beim Server sieht, weil der dies nicht angezeigt hat.

Wir können es uns nicht leisten, dass ein Integrator unseren Server aus dem Programm nimmt und in den nächsten zehn Jahren womöglich nicht hundert Stück davon an seine Kunden verkauft, weil er vom Produkt enttäuscht wurde. In einer Welt mit großer Informationsflut und von einzelnen oft kaum noch überblickbaren technischen Details muss die Technik möglichst alles kompensieren und darf nicht nur keinen Frust machen, sondern muss auch für Begeisterung sorgen. Weil beim nächsten Mal, wenn der Kunde dann ein Problem schnell lösen kann, weil er eine tolle Anzeige bekommen hat, wird er das mit Begeisterung zur Kenntnis nehmen und die Begeisterung in das Verkaufsgespräch mit seinen Kunden führen.

Zumindest wenn Du als Hersteller "neu" auf dem Markt bist. Als alteingesessener Hersteller ist das was anderes. Da hast Du einen guten Ruf von früher auf der Basis der damals viel einfacheren Produkte und der beschert Dir laufende Umsätze aus guter Erfahrung. Wenn wir nun einen Integrator dazu bringen wollen, auf unseren Server zu wechseln, dann ist das mit großem Aufwand verbunden. Das macht der Integrator nur, wenn wir sehr sehr viel besser sind als das bisher eingesetzte Produkt, damit sich der Aufwand und das Risiko für ihn lohnt. Und um eben mit dem Server auch zu Punkten, müssen wir damit an allen Stellen richtig gut sein.

Kurz: Wir sind darauf angewiesen, dass die Integratoren unsere Server gerne an Ihre Kunden verkaufen. So wie ein Hersteller eines Milchproduktes darauf angewiesen ist, dass die Supermarktketten sein Produkt listen und im Markt verkaufen. Wenn die Kunden wegen Schimmel oder schlechtem Geschmack reklamieren, dann war es das für den Hersteller des Milchproduktes.


Anderes Beispiel: Letztens hatten wir einen Kunden, der hat in Docker was aufgesetzt und ist dann mehrere Monate beruflich ins Ausland gefahren. Die Anwendung in dem Container hat dem Server über die Monate hinweg die Platte vollgeschrieben. Klar ist das der Fehler des Kunden, aber sieht er das auch ein? Der diesbezügliche Supportfall hat uns mehrere Stunden gekostet. Könnten wir das abrechnen? Vermutlich ja, weil es steht im Vertrag. Aber wird der Kunde das auch akzeptieren? Vermutlich nein. Ergebnis sind stundenlange Diskussionen die - Du wirst es ahnen - uns nochmal 120.- EUR die Stunde kosten.

Darum bleibt uns am Ende nichts anderes übrig, als alles und jedes so perfekt wie möglich auszuführen, Analysen und Warnungen einzubauen und alle nötigen Bordmittel. damit die Kunden sich auch selbst helfen können. BTW: wenn der Kunde sich einen SSH Container gebaut hätte, hätte er sich auch selbst helfen können. Nur kann er argumentieren, dass ihm niemand das gesagt hat. Nun blenden wir einen Disclaimer ein und geben eine Hilfe mit und Kennzeichnen Werte - die so auch im Portainer stehen - nun farblich und alles auf einen Blick, damit es nicht übersehen wird. Weil wir wollen diese Supportfälle nicht mehr haben, bzw. brauchen eine Diskussionserleichterung wenn wir solcherlei Supportaufwand dann abrechnen wollen.

Smart Jeanie hat geschrieben: Fr Jun 05, 2020 12:09 pmSo gesehen ärgert es mich ein wenig, wenn Du hier so ehrlich bist zu schreiben, dass die Quotierung von Docker-Containern bei den Hutschienenmodellen 2-3 Mannwochen benötigt.
Im schlechten Fall, womöglich ist es auch mit drei Manntagen zu schaffen, aber das wissen wir erst danach. Wenn immer was am Kernel machen muss, kann das einen Rattenschwanz nach sich ziehen.

Smart Jeanie hat geschrieben: Fr Jun 05, 2020 12:09 pmDa ich selbst Container vermeiden möchte und selbst wenn ich sie nutzte, dieses Feature nicht erwarte, fände ich es als "normaler" TWS-Nutzer besser, diese Entwicklerkapazitäten würden nicht in eine perfekte Docker-Verwaltung gesteckt, sondern in TWS-native Funktionen, also in die nächsten Dinge, die der TWS wie ein Multitool gut kann.
Ja. Aber es ist nun mal der Wunsch einiger, dass eine solche Quotierung erfolgt.

Schau Dir bitte mal die Dynamik von Change Requests an. Wenn ich einen solchen Request "ablehnen" würde, dann folgt, das ist die allgemeine Erfahrung, dass anschließend umso vehementer um den CR gekämpft wird. Es ist wirklich jedesmal so. Wenn ich nur ein wenig den CR zurückweise, setzt diese Dynamik ein. Es hat eben jeder seinen Herzenswunsch. Am Ende bekomme wir dann hier im Forum durchaus seitenlange Plädoyers für die jeweilige gewünschte Funktion. Am Ende stehen wir (ElabNET) nach solchen Pladoyers ungut dar. Gerade so, als wären wir die letzten auf der Welt, die einfach nicht kapieren wollen, wie wichtig diese gewünschte Funktion für den Betrieb des Servers ist und dass wir den Nutzer um eine wichtige Sache bringen würden, weil wir das Feature abgelehnt haben. Mancher würzt einen CR durchaus mit den abschließenden Worten, dass man den Server ja gerne den Bekannten beim Hausbau empfehlen würde, aber ohne das Feature würde das schwer fallen bzw. der Server ist nicht reif für ein Release.

Nicht zu vergessen, sehr viele der CRs kommen von den sehr aktiven Schreibern hier. Das sind Meinungsführer auf die wir auch angewiesen sind. Wir müssen die Beziehungen zu unseren Kunden schließlich auch pflegen, wobei das auch unsere besondere Stärke ist. Zudem laufen im nächsten Jahr viele Care Verträge aus und wir müssen dann um Verlängerung bitten.

Am Ende bleibt uns meist gar nichts anderes mehr übrig, als dieses und jenes Feature dann auch umzusetzen, damit der / die Nutzer glücklich sind. Wobei dabei dann auch ein besserer Server heraus kommt, es sind ja durchaus gute Ideen.

Mittlerweile haben wir auf diese Weise an vielen - nicht allen - Stellen einen ziemlichen Perfektionsgrad erreicht, allerdings erwarten die Kunden nun von neuen Leistungsmerkmalen mindestens die gleiche Umsetzungsqualität oder besser noch, das wir immer noch eines drauflegen. Weil nichts verbraucht sich so schnell wie Begeisterung und die brauchen wir eben auch für den Verkauf.

Das geht es uns wie den Spieleentwicklern. Jedes neue Spiel muss noch bombastischer werden als das vorhergehende. Mit all dem unguten Druck auf die Entwickler die das auslöst.

Smart Jeanie hat geschrieben: Fr Jun 05, 2020 12:09 pmSorry, aber wer mit Containern "experimentiert", dem muss es dann auch mal reichen, wenn er für sich bei Problemen die Dinge bewertet, die Ihr ihm heute bereits anzeigt. Ihr seid nicht die Hausmeister des Universums. Ihr müsst nicht jeden selbst verursachten Dreck aufräumen. Wenn jemand Admin spielen möchte, dann muss er es irgendwann auch sein. Deswegen für mich wenig Docker. Mehr und schneller TWS-nativ und gerne auch weniger perfekt.
Wenn es nach mir geht, wäre die Reihenfolge der Umsetzung mancher Leistungsmerkmale auch eine andere gewesen in den letzten einundeinhalb Jahren.

Mit der Version 1.6 haben wir die neue native Unterstützung für ekey herausgebracht. Danach wollten wir intensiv Modbus fertig stellen.

Jedoch entstanden dann eine Menge Supportfälle hinsichtlich KNX und wir haben die Interfaceseite getuned um den Kunden mehr Infos und Rückmeldungen zu geben. Damit konnten die Kunden nun genau messen und mitloggen, dass es Verbindungsabbrüche mit Software in Containern gab. Also mussten wir anschließend mit zig Entwicklern fremder Software kommunizieren, damit die deren Fehler in deren KNX Tunnel implementierung beheben, nur damit wir keine Supportfälle mehr mit Containern und der KNX Schnittstelle hatten. Haben wir geschafft, aber es war Aufwand an dieser Stelle Ruhe ins System zu bekommen.

Damit wollten wir dann eigentlich die V 1.6 funktional abschließen. Nur gab es dann - rein zufällig - viel Support wegen Docker Containern und zwei mal Server mit zugemülltem Speicher. Ein voll geschriebener Server ist in der heutigen Bewertungsgesellschaft eine sehr schlechte Publicity. Ob das nun in die Sphäre des Herstellers oder des Anwenders fällt, ist für die Schlagzeilen erstmal egal.

Am Ende müssen wir stets zusehen, dass wir ALLE Nutzer zufrieden stellen und eine gute Bewertung von ALLEN bekommen. Es reicht keine einfache Mehrheit oder eine absolute. Wir brauchen eine sehr hohe Zustimmungsrate um fünf Sterne zu bekommen.

Ich würde mir auch manchmal etwas weniger an Anforderungen wünschen, damit wir besser mit den eigentlichen Hauptthemen voran kommen, aber das liegt eben auch ein gut Stück weit in der Hand der Nutzer und das man akzeptieren möge, wenn wir nicht jedem CR nachkommen können.

Bislang konnten wir uns dem Druck nur dadurch entziehen, dass wir dem Wunsch nachgegeben und das gewünschte implementiert haben. Das damit länger geplante Leistungsmerkmale auf der Strecke geblieben sind, muss man eben akzeptieren, wobei ich darüber nicht glücklich bin.

Allerdings ist mittlerweile viel geschafft und die bestehenden Leistungsmerkmale haben eine sehr hohe Qualität, so dass die Menge an Wünschen zuletzt stark zurück gegangen ist. Es sind zwar noch viele FRs offen und die werden wir auch einer nach dem anderen berücksichtigen, aber wir haben den Eindruck, dass wir das parallel zum Ausrollen neuer Funktionen einflechten dürfen, so dass wir nun deutlich schneller im Plan voran kommen, als noch vor einem halben Jahr. Die Aussichten sind also gut, dass wir bald eine Menge neuer starker Leistungsmerkmale bekommen, auch diejenigen großen Merkmale, auf die viele schon lange warten.

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.

Smart Jeanie
Reactions:
Beiträge: 64
Registriert: Mo Sep 10, 2018 3:10 pm
Hat sich bedankt: 92 Mal
Danksagung erhalten: 68 Mal

#35

Beitrag von Smart Jeanie »

Hallo Stefan,

das letzte was ich wollte war, dass Du jetzt den ganzen Samstag Nachmittag mit der Antwort auf meinen Post verbringst. Die Familie und Deine Erholung gehen mal vor. Ich glaube, dass wir im Kern nicht so weit auseinander liegen und Du mich nur in Teilen missverstanden hast. Deshalb möchte ich einzelne Teile kurz präzisieren.

1. Die Umfrage nach einer Preview
Die Umfrage muss kurz bleiben. Sie darf nicht auf hunderte Details zerfleddert werden. Das ist mir klar. Ich könnte mir jedoch vorstellen, dass weitere Anwender und auch ich Euch schneller unterstützen können. Ich selbst setze bevorzugt ausgetestete Software ein. Dinge müssen einfach laufen. Wenn aber Anwender vermehrt zurückmelden nach dem Motto "ich hatte leichte Probleme mit meinen eigenen Dockern" oder "ich hatte größere Probleme mit meinen eigenen Dockern und proprietärer Hardware daran", dann würde das bedeuten, dass der von Euch verantwortete Kern des Timberwolf weitestgehend stressfrei läuft. In so einem Fall würde auch ich ggf. eine Preview installieren und könnte zum schnelleren Feedback beitragen. Das ist nur eine Idee, der muss man nicht folgen. Und Du musst auch nicht lange rechtfertigen, wenn Ihr Euch anders entscheidet.

2. Perfektion vs. mehr gute Features
In meinen Augen beschäftigt Ihr Euch zu sehr mit Glasperlen und Unterholz, anstatt mit Rennpferden und Staudämmen.
Mir hätte eine verfügbare befriedigende Light Engine gereicht.
Mir hätte eine verfügbare befriedigende Modbus-Schnittstelle gereicht.
Mir hätte eine verfügbare befriedigende Rest-Api gereicht.
Stattdessen läuft demnächst Docker perfekt für einige Hände voll Menschen, von denen die meisten besser die Finger davon ließen.
Jetzt investiere ich einen vierstelligen Betrag in herkömmliche KNX-Komponenten und/oder in DALI. Dann gehöre ich nach Deinen Schilderungen einfach nicht zur Zielgruppe. Euer Fokus ist dann eben der Wiederverkäufer und Systemintegrator, und wenn die Quotierungen für Docker brauchen, weil die schon von Grund auf dem Thema eigentlich nicht gewachsen sind und schon das nicht verwenden können, was bereits da ist, dann sei es so. Da ist niemand dran Schuld, dafür muss sich niemand entschuldigen. Ich habe lediglich zu früh das am Ende falsche Produkt für mich gekauft. So what?!

Ja, und so "Experten", wie Du sie in Deinen Beispielen schilderst, kommen mir bei meinem Projekt auch reihenweise unter, leider nicht nur im Gewerk Elektro. Ich verstehe ja, dass Ihr Euch darauf angewiesen seht.
Markus

TWS 950Q #268, Software-Stand V3.5x, nicht in Verwendung

fsl
Reactions:
Beiträge: 120
Registriert: Do Nov 01, 2018 12:23 pm
Hat sich bedankt: 55 Mal
Danksagung erhalten: 60 Mal

#36

Beitrag von fsl »

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amMir hätte eine verfügbare befriedigende Light Engine gereicht.
Mir hätte eine verfügbare befriedigende Modbus-Schnittstelle gereicht.
Mir hätte eine verfügbare befriedigende Rest-Api gereicht.
Stattdessen läuft demnächst Docker perfekt für einige Hände voll Menschen, von denen die meisten besser die Finger davon ließen.
Jetzt investiere ich einen vierstelligen Betrag in herkömmliche KNX-Komponenten und/oder in DALI.
Das deckt sich etwa auch mit meinen Gedanken dazu. Ich freue mich natürlich über beim Verkauf noch nicht angekündigte Leistungsmerkmale und nehme durchaus wahr, dass die Umsetzung dann wirklich schön erfolgt. Aber meine Kaufentscheidung für den TWS - und da insbesondere die Hutschienenversion - ist in erster Linie durch die Überlegung motiviert worden, dass ich mir dann keinen Router und kein DALI-Gateway (OK, ggf. ein kleines Kästchen) bzw. kein DMX-Gateway, wenn ich mich doch in diese Richtung orientieren sollte, kaufen muss und auch Richtung Hue und Konsortien offen bin, was den Kaufpreis relativierte. Die ganzen HTTP-Sachen (REST-API, MQTT, usw.) wollte ich auch nutzen, um unflexibele Cloud-Lösungen für einzelne Geräte insbesondere für das Jogging adaptieren zu können

Wenn das alles "nativ" laufen würde, wäre vielleicht auch der Schrei nach NodeRED und IOBroker nicht so groß. Sind das nicht auch die Container, die tendenziell Probleme machen?
StefanW hat geschrieben: Sa Jun 06, 2020 5:37 pmZudem laufen im nächsten Jahr viele Care Verträge aus und wir müssen dann um Verlängerung bitten.
Eben.
Zuletzt geändert von fsl am So Jun 07, 2020 7:13 am, insgesamt 1-mal geändert.
TWS 950Q ID:310 + PBM ID:10072, VPN offen, Reboot erlaubt
TWS 3500L ID:1030, VPN offen, Reboot erlaubt

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#37

Beitrag von gbglace »

Naja das der TWS nativ DALI sprechen wird war aber so noch in keinem alten Prospekt beschrieben. Aber das mit dem DMX verfolge ich ja auch sehr.
Aber ich sehe auch ein, das DMX im EFH eine geringere Verbreitung hat als eine Logikmaschine und in Zeiten sich schnell ausbreitender IoT Sachen eben auch MQTT und der gleichen. Modbus ist da auch nicht schlecht gerade im Systemintegrativen Gedanken. Ekey ist da auch ganz nett.

Mit dem Release ins Beta oder besser nur Alpha von nur rudimentären Umsetzungen der DMX Geschichten kann ich auch leben, auf den Hutschienen TWS geht das ja sogar schon. Hab aber nen Desktop und freue mich daher sehr wenn denn Mal die DMX Zusatzmodule antestbar werden.
Aber eine rudimentäre Funktion bis richtig in die Oberfläche zu bringen halte ich für nicht zielführend. Denn es gibt auch viele Endkunden die zwar viel technisches Spielzeug wollen es aber mit Konsoletippen dann doch nicht so haben und eben eine Oberfläche wollen und brauchen. Fehlt die, dann gibt das schlechte Presse.
Geräte/Systeme die quasi von sich aus nur den Bastlerfreak ansprechen, den kann man sowas anbieten (EDOMI) egal wie gut das selbsterklärend funktioniert oder man selber in die Tiefen einsteigen muss.
Aber Kunden des RealKNX, Youvi von Peaknx, einer Domovea oder dem TWS kannst damit nicht kommen. Das wiregate war damals eben mehr EDOMI als die anderen genannten.

Ja die Integrations-Container obsolet werden zu lassen wäre ein Traum. Gab im.KNX-UF ja gerade auch so ein zerlegten Werbebeitrag vom Control4 das ist auch so eine IoT-Integrationsbox. Die können wahrscheinlich technisch viel weniger als der TWS aber gehen halt voll mit der Optik in den Vertrieb. Aber machen das auch schon einige Jahre so.
Daher sehe ich auch das das noch eine Weile brauchen wird bis das Mal soweit ist. Die Docker Plattform bietet darüber hinaus aber eben die Möglichkeit für den Kunden in der Nische immer quasi sofort agieren zu können bevor es ggf Mal auf dem offiziellen Kanal daher kommt. Aber ja wer das nutzen will sollte.mehr Ahnung davon haben. Daher finde ich diese letzten Maßnahmen zur quasi Stabilisierung schon ganz gut. Auch wenn ich Docker nicht so intensiv nutzen, weiß ich doch jetzt das die Entwicklerkapazitäten nun ungestörter am Ziel arbeiten können und nicht mehr von übermotivierten Dockeranfängern durch Supportanfragen ausgebremst werden.
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
#3 PBM 3 Kanäle, #4 Modbus-Extension

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#38

Beitrag von StefanW »

Guten Morgen Markus,
Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amdas letzte was ich wollte war, dass Du jetzt den ganzen Samstag Nachmittag mit der Antwort auf meinen Post verbringst.
Wollte ich auch nicht, aber das Thema ist wichtig und unter der Woche habe ich dann garantiert keine Zeit.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amIch glaube, dass wir im Kern nicht so weit auseinander liegen
Richtig, ich habe großes Verständnis für Deine Position. Ich würde mir auch manches anders wünschen, aber ich kann auch die anderen Sachzwänge nicht außer Acht lassen und die hatte ich oben skizziert.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amIch selbst setze bevorzugt ausgetestete Software ein. Dinge müssen einfach laufen.
Das ist genau der Punkt, und das haben wir auch erreicht. Wir haben noch nicht alles umgesetzt, was wir uns für diesen Zeitpunkt vorgenommen haben, allerdings funktioniert das was wir umgesetzt haben dafür problemfrei.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amMir hätte eine verfügbare befriedigende Modbus-Schnittstelle gereicht.
Lass mich das mal herausgreifen. Wir haben unsere Entscheidung, welche Leistungsmerkmale wir unterstützen wollen schon vor einem halben Jahr getroffen, aber womöglich lassen sich einzelne Merkmale priorisieren.

==> Da Du es ansprichst, was ist Deine Einschätzung von einer (für die Mehrheit der Kunden) befriedigende Umsetzung der Modbus Unterstützung?

Folgend die Fragen die wir uns beim Design der unterstützenden Protokolleigenschaften von Modbus gestellt haben:

  1. Welche der 12 möglichen Betriebsarten und Protokollversionen von Modbus sollen unterstützt werden?
  2. Welche der 21 möglichen Befehlsarten (Function Codes) sollen wir unterstützen und welche davon lassen?
  3. Welche der 15 Diagnostics Funktionen für die serielle Kommunikation sollen wir auswerten / anzeigen?
  4. Soll ein Fehlerbehandlung unterstützt werden? Wenn ja welche? Diagnose? Fehlercodeauswertung? Welche Exception Codes? Prüfung der Parameter auf zulässigen Bereich? Reaktion auf Fehler?
  5. Welche der unzähligen ByteOrder Formate sollen wir unterstützen?
  6. welche der 9 vorgefundenen Codierungsvarianten für Registerinhalte sollen umgesetzt werden ?
  7. Welche Umrechnungen? Nur Fixpunktumrechnungen? Offsets? Oder frei eingebbare Formel?
  8. Soll es ein Handling von Einheiten geben (Sekunden, Kilowatt usw.)? Und wenn ja, welche davon?
  9. Wie ist mit Setup-Registern umzugehen? Sowohl mit denen, die nur im RAM eines Modbus-Gerätes gesetzt werden (und nach Reboot eines Modbus Gerätes neu gesetzt werden müssen) oder mit denen im Flash, die keinesfalls zu oft gesetzt werden dürfen, weil nach mehreren hundert Schreibbefehlen der Konfig-Flash des Modbus-Gerätes zerstört wird? Mit anderen Worten, soll der TWS - im Rahmen der technischen Möglichkeiten - den Nutzer davor schützen, dass er sich durch einen Konfigurationsfehler die Modbus-Platine in seinem Wechselrichter schießt, weil er zu oft in das Schreibregister eines Geräteparameters geschrieben hat?
  10. Wie handelt man "Write-Protected" Register, die erst beschreibbar sind, wenn zuvor ein Passwort in ein anderes Register geschrieben wurde?


Das sind jetzt nur die groben Themen zu Eigenschaften im Protokoll Modbus


Hier nun die Fragestellungen zu den Leistungsmerkmalen hinsichtlich Nutzung und Bedienung:

  1. Wieviele Modbus-Schnittstellen sollen am TWS gleichzeitig unterstützt werden (andere KNX to Modbus Gateway können genau EINE Schnittstelle)
  2. Soll es dazu auch extern ansteckbare Schnittstellen zur Erweiterung geben, oder muss der Kunde dann jeweils einen neuen Server kaufen (so wie beim Wettbewerb, bei dem man jeweils ein Gateway benötigt pro Modbus Bus)?
  3. Wenn ja, soll eine solche extern ansteckbare Schnittstelle automatisch erkannt werden? Oder soll der Kunde ein Ini-File in einem Texteditor editieren und dort alle richtigen Parameter eingeben müssen, damit eine solche Schnittstelle auch erkannt wird (also eine Bedienung wie bei den meisten Open Source Produkten)?
  4. Soll es einen Testmodus geben, damit man die Rückmeldung vom Modbus Gerät sehen kann bzw. Einstellungen einfach setzen kann, ohne erst eine Verknüpfung auf ein KNX Objekt vorzunehmen um dann im Busmonitor zu sehen, welcher Wert letztlich auf den Bus gelangt ist? Oder mit anderen Worten, sollen wir es dem Kunden durch ein interaktives Setup stark erleichtern, die richtigen Parameter in einem Preview-Modus mit Trial-and-Error zu erarbeiten oder soll er für jedes Setting die "große Testschleife" über den Busmonitor führen müssen?
    Hinweis: So (schlecht) ist das bei allen KNX-to-Modbus Gateways am Markt umgesetzt. Es gibt dort keinen Testmodus. Der Nutzer sieht erst dann, was vom Modbus Gerät gekommen ist, wenn es auf den KNX Bus gesendet wird. Um den Betrieb nicht zu stören, könnte man zwar erstmal auf eine Dummy-GA schreiben um das zu prüfen, was da kommt und ob die ganzen Einstellungen zu ByteOrder und Codierung (da kommen gut 20 Varianten zusammen) auch richtig gesetzt wurden. Das kann aber mühsam werden für Dutzende oder Hunderte Parameter jeweils Dummy-GAs einzurichten und das ganze per ETS hin- und her zu programmieren. Wie gesagt, das ist heute Stand der Technik, die Frage ist, wird vom Timberwolf Server erwartet, dass die Entwicklung eines Modbus-Setup auch auf Ebene jeder einzelnen Funktion mit einem Preview unterstützt wird)?
  5. Soll das dann mühsam erarbeitete Setup (so ein Wechselrichter kann hunderte Parameter unterstützen) dann von einem Timberwolf Server zum anderen kopierbar sein? Damit die Arbeit eines einzelnen weitergegeben werden kann in der Community? Oder damit ein Integrator nicht bei jedem Kunden von vorne anfangen muss?
  6. Welche Abfrageintervalle sollen unterstützt werden? Fixe - aus einer vorgegebenen Liste wählbare - Intervalle (so ist es bei den meisten am Markt befindlichen Gateways) oder soll der Kunde das frei einrichten können?
  7. Sollen durch die Modbus-Setup Oberfläche Umrechnungen unterstützt werden? Es gibt zum Teil sehr "dumme" Modbus Geräte. Manche Temperaturmesser können nicht vorzeichenbehaftet Codieren und unterstützen auch kein Fließkomma. Mithin wird, damit man auch runter bis -50 °C den Wert mit einer Kommastelle übermitteln kann, auf den internen Messwert 50 aufaddiert und das ganze dann mal 10 genommen. Mithin erhält man bei der Abfrage via Modbus für -10,2 °C einen Integerwert von "398". Diese Zahl kann man keinesfalls so auf den KNX Bus senden oder in eine Zeitserie schreiben. Damit stellt sich die Frage, erlaubt man die Umrechnung, in diesem Beispiel "=(X/10)-50", gleich in der Modbus Engine, so dass das Modbus-Objekt die gewünschten "-10,2 °C" erhält und man es bequem verknüpfen und weiterverarbeiten kann, oder soll der Kunde diese rohen Modbus-Werte selbst über die Logik umrechnen müssen.
    Hinweis: Eine sehr große Zahl an Modbus Geräten senden die Messwerte in einer Weise, dass eine Umrechnung erforderlich ist, weil nur ein kleiner Teil der Geräte am Markt Fließkomma unterstützen. Die meisten Werte sind daher Fixpunkt kodiert. Und wir reden bei solchen Defiziten in der Wertekodierung nicht von China Ware, sondern ordentliche Produkte deutscher Markenhersteller. Hier wird die ganze Arbeit auf den Nutzer übertragen, weil man sich mit der Software im Modbus Gerät keine Mühe geben wollte.
  8. Soll man die Enumerierungen und deren Auswertungen unterstützen? Es geht darum, dass viele Register von Modbus-Geräten keine Messwerte enthalten, sondern Codes zu Betriebseigenschaften. Beispiel: In einem Register zur Wartung steht dann "0815" für "Installateur kontaktieren" und "2411" ist der Code für "Gefahr! Hersteller kontaktieren" und noch ein paar andere Statuscodes. Wie soll der Timberwolf Server hier unterstützen? Gar nicht und den Zahlenwert so an KNX senden? Soll das der Kunde in der LogikEngine ausdekodieren? Oder in der Visu? Oder soll der TWS die Möglichkeit bieten, dass je nach Code ein Text gesendet wird bzw. ein boolsches Flag (z.B. für "Alarm")?


Das sind die knackigen Fragen, die man sich beim Produktsdesign stellt. Was daran sind nun Staudämme und was sind Glasperlen?

Was soll mein Gerät können und was nicht? Wo kann man ein Alleinstellungsmerkmal realisieren und wie schafft man das der Kundschaft zu vermitteln, die bei der Kaufentscheidung womöglich gar nicht auf diese Details achtet, weil deren Bedeutung unklar ist (der Haken in der Systembeschreibung "unterstützt Modbus" reicht dem ein oder anderen vermutlich für die initiale Kaufentscheidung, zumindest hat noch kein Kunde hier im Forum beim Thema Modbus gezielt nach den oben beschriebenen Parametern gefragt, weil die Vielfalt der 50 jährigen Modbus Welt vermutlich gar nicht bekannt ist)?

Bei solchen Designentscheidungen gehört dazu, was realisieren wir zuerst (also in V1 Modbus) und was später mit Folgeversionen. Dabei kommt dann das Thema Datenformat ins Spiel, weil eine Datenbank nachträglich zu erweitern - im laufenden Betrieb beim Kunden im Rahmen eines Updates - ist sehr anstrengend zu implementieren. Bekommt unsere Kunden so nicht mit, weil das im Hintergrund automatisch geschieht, aber es muss schon jemand tatsächlich programmieren und testen. Wir hatten schon ein gutes Dutzend solcher Schema-Updates. Sehr aufwändig....

Daher sind Gedanken bezüglich "machen wir gleich und machen wir später" auch dahingehend abzuwägen, wie groß der Änderungsaufwand für eine später eingebrachte Funktionalität ist. Und dies auch in jeder Hinsicht, auch inkl. Auswirkungen auf Dokumentation, Handbücher, Videos, die man dann auch alle umarbeiten / neu erstellen muss. An "bauen wir später ein" hängt sehr viel mehr, als es auf den ersten Blick aussehen mag.

==> Ich habe vorhin das Forum um die Bereiche "Modbus", "MQTT" und "Rest-API" erweitert. Ihr alle würdet uns einen großen Gefallen tun, wenn Ihr Eure Vorstellungen der jeweils unterstützten Leistungsmerkmal dort präzisieren könnt. Hierbei reicht uns auch schon, wenn Ihr uns die Datenblätter mit den Programmierbeschreibungen / Schnittstellenbeschreibungen dort postet, weil dann lesen wir heraus, was denn nun funktionieren muss für Euch.

==> Hinsichtlich Modbus wären auch sehr präzise Angaben zu den oben genannten Fragestellungen hilfreich. Bitte im neuen Modbus Bereich, nicht in diesem Thread.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amMir hätte eine verfügbare befriedigende Rest-Api gereicht.
Ja, bitte schreib uns, was Du denkst, was für die meisten Kunden als "befriedigend" gilt. Im neuen "Rest-API" Bereich bitte.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amStattdessen läuft demnächst Docker perfekt für einige Hände voll Menschen, von denen die meisten besser die Finger davon ließen.
Bitte nicht von den negativen Rückmeldungen auf die Anzahl aller Nutzer schließen. Diejenigen, für die alles so passt und funktioniert, eröffnen keine Threads. Das Verhältnis der Motivation für Erfolgsberichte vs. Fehlerberichte ist etwa 1:100. Praktisch niemand verschwendet seine Zeit dafpr zu schreiben, dass alles wunderbar für ihn funktioniert. Und wenn dann nur mal als Nebensatz.

Es reicht bei den meisten nicht einmal für den Abstimmungsknopf. Wir sehen an den Downloadzahlen, dass erheblich mehr Kunden die Insider Preview installieren (eine ordentliche dreistellige Anzahl), aber an der Abstimmung beteiligt sich nur ein kleiner Teil, womöglich lesen manche den Thread gar nicht oder sind hier nicht angemeldet und können nicht abstimmen.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amDann gehöre ich nach Deinen Schilderungen einfach nicht zur Zielgruppe. .... Euer Fokus ist dann eben der Wiederverkäufer und Systemintegrator....
Nein, keine Sorge, Du gehörst durchaus zur Zielgruppe um die wir uns auch hier im Forum liebevoll kümmern.

Aber es gibt auch Endkunden, die sich von Integratoren beraten lassen und deshalb müssen wir auch dieser beratenden und womöglich das Material handelnden und dabei Gewährleistung übernehmenden Gruppe ebenfalls gefallen. Plus den Kunden aus Forschung & Lehre, sowie Industrie die hier nicht oder nur verdeckt schreiben.

Ich wollte nur darauf hinweisen, dass die Bandbreite der Interessen unserer Kundschaft umfassender ist, als es im Forum erkennbar ist.

Smart Jeanie hat geschrieben: So Jun 07, 2020 1:16 amIch habe lediglich zu früh das am Ende falsche Produkt für mich gekauft. So what?!
Nein, ich denke nicht. Die vielen schönen Dinge kommen durchaus jetzt zügig. Bitte ein wenig Geduld, auch wenn es strapaziert ist.

Man darf nicht übersehen bitte, dass Support auch viel Entwicklerkapazität bindet, weil es manchmal schon um das einzelne Bit geht. Deshalb war es eine wichtige Investition, all die vielen kleinen Supportschmerzen durch entsprechende Optimierungen aus der Welt zu schaffen, damit wir mehr Zeit für das eigentliche Entwickeln neuer Funktionen haben.

Am Ende mussten wir dasjenige nacharbeiten, das wir zunächst nur "befriedigend" umgesetzt hatten, wie die Verwaltung der KNX Schnittstellen und des Docker Managements. Das zeigt auch wieder, dass zu einfache oder nur befriedigende Lösungen auf Dauer den Kunden nicht reichen und man nacharbeiten muss. Da stellt sich schon die Frage, ob man es nicht besser gleich richtig umsetzt.

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.
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#39

Beitrag von starwarsfan »

Hallo miteinander,

Leute, wenn ich das so lese, dann tut ihr gerade so, als ob Docker das Böse auf Erden ist!? Und meint ihr ernsthaft, dass eine "befriedigende Light Engine / Modbus-Schnittstelle / Rest-Api" einem so neuen Produkt wie dem TWS hilft? :think:

Wenn irgendetwas nur "befriedigend" läuft, dann wird es nicht gekauft! Gerade weil es ja nun wirklich kein Schnäppchen ist und der potentielle Kunde das Potential des TWS in den meisten Fällen wohl (noch) nicht einschätzen kann. Von daher kann ich die Argumentation von @StefanW nur befürworten. Anders holt man heutzutage niemanden mehr hinter dem Ofen hervor. :handgestures-thumbupright:
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

ExInspektor
Reactions:
Beiträge: 47
Registriert: Fr Jan 11, 2019 4:04 pm
Hat sich bedankt: 50 Mal
Danksagung erhalten: 34 Mal

#40

Beitrag von ExInspektor »

Hallo liebe Gemeinde,
das Update von 1.6.0 IP2 auf 1.6.0 IP3 ist ohne Probleme durchgelaufen - vielen Dank! Gesund bleiben!
Gruß,
Andreas
TWS 3500XL ID:1398, Wartungs-VPN offen , Reboot erlaubt
Antworten

Zurück zu „Bekanntmachungen“