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

[DISKUSSION] TW und USV via NUT?

Eure Wünsche und Phantasien
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

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

#11

Beitrag von StefanW »

Hallo Göran,
gbglace hat geschrieben: So Dez 12, 2021 12:39 pmJa, da bedarf es einen dicken Disclaimer und explizit manuelles zutun, das das Objekt (TWS-Shutdown) verfügbar ist.
Nach unserer Erfahrung nutzt das nur bedingt. Zum einen werden Disclaimer nicht unbedingt gelesen zum anderen werden diese - auch über längere Zeit hinweg - durch einen eigenen Glauben darüber ersetzt, was dort beinhaltet war.


Folgendes (typisches) Szenario:

1. Der Nutzer hat gerade eine Änderung vorgenommen+
2. Zeitnah dazu spielt der Nutzer ein Update der Software ein
3. Relativ Zeitnah stellt der Nutzer ein Problem fest am Server.

Welcher Änderung wird der durchschnittliche Nutzer nun als Ursache vermuten? Seine eigene Änderung oder die Änderungen durch die eingespielte neue Software. Nach unserer Erfahrung: zu 95% der neu installierten Software. Und so wird es der Nutzer dann auch hier im Forum oder gar gleich im Support adressieren "seit dem Update....". Die eigene Änderung wird dabei womöglich gar nicht mehr erwähnt.

Worauf ich hinaus möchte ist, dass wenn der Nutzer ein Problem mit dem Server hat, das er im Moment nicht beheben kann (oder ihm nicht bewusst ist, welcher seiner eigenen Änderungen davor das bewirkt hat) dann wünscht er eine Lösung und damit wendet er sich an das Forum und je nach Schweregrad direkt an uns (was er eigentlich nicht soll, wenn kein Supportvertrag besteht, weil sonst machen wir Support über das Forum) und will nun Hilfe. Da ist es ihm egal, was im Disclaimer gestanden hat, denn für sich subjektiv hat er alles richtig gemacht und erwartet nun Hilfe.

Und dabei spielt auch die Art und Weise der Störung eine Rolle, wie emotional die Unterstützung eingefordert wird. Nehmen wir an, wir stellen nun ein Objekt zum Herunterfahren des Servers zur Verfügung und in Verbindung mit der beliebigen Verknüpfung hat er es mit einem KNX Objekt verknüpft auf dem sich zu diesem Zeitpunkt nichts tut (etwas weil es Sommer ist und dieses Objekt nur im Winter genutzt wird). Dann wird es Winter und eine Logik springt an und fängt nun an auf das Objekt zu feuern...... Und kurz davor gab es ein Update von uns....

Das ist alles ganz menschlich und ganz normal, aber für uns als Hersteller eines komplexen Produktes ist es eine immense Herausforderung, wie wir Supportaufwändungen im Griff behalten. Weil wenn dann so ein Server dreimal am Tag herunterfährt und der Kunde beteuert nichts gemacht zu haben (den Zusammenhang mit im Sommer falsch eingestellt auf ein Objekt das im Winter feuert ist nicht bekannt) dann will der Kunde dass ihm geholfen wird. Wir können ja schlecht das eMail nicht beantworten. Finden wir dann nach längerer Analyse heraus (die beliebig kompliziert sein kann, wenn der Server schon vom nächsten Paket heruntergefahren wird) dass es ein Konfigurationsfehler ist, wer zahlt uns dann den Aufwand?

gbglace hat geschrieben: So Dez 12, 2021 12:39 pmWer dann per Logik oder KNX-Telegramme oder sonstiger Daten-quellen wild das Objekt auslöst muss selbst mit der Konsequenz leben.
Ich kenne solche Diskussionen mit Kunden schon. Da kann man gleich für den selben Aufwand nochmal diskutieren.....


Es ist also nicht so einfach, solche Funktionen mit so gewaltigem Impakt zur Verfügung zu stellen und hoffen, dass jeder damit auch vollverantwortlich umgehen kann damit und im Zweifelsfall den Aufwand der vergeblichen Entstörung auch bereit ist zu bezahlen.

gbglace hat geschrieben: So Dez 12, 2021 12:39 pmZur weiteren Absicherung seitens Elabnet-Support würde ich da noch an Aufwand erkennen, dass man bei solchen elementaren aktiven Systemobjekten, auch ein separiertes Log über die Verknüpfungen hat. Quasi so einen Zwangs Doktormodus an diese Objekte und deren Verlinkungen. Damit sollte schnell klar werden welcher Trigger das ausgelöst hat.
Ja, aber was hilft das? Es ermöglicht uns eine Beweisführung, deren Kosten wir eher nicht erstattet bekommen werden.


Deswegen bitte ich um Verständnis, dass wir uns das gut überlegen wollen, ob wir solch mächtige Statusobjekte, mit Einfluss auf die Verfügbarkeit des Servers, zur Verfügung stellen wollen.


lg

Stefan
Zuletzt geändert von StefanW am Di Dez 14, 2021 5:38 pm, insgesamt 3-mal geändert.
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.

stonie2oo4
Reactions:
Beiträge: 159
Registriert: Di Okt 23, 2018 9:27 pm
Hat sich bedankt: 30 Mal
Danksagung erhalten: 37 Mal

#12

Beitrag von stonie2oo4 »

Ist dass Szenario das der Server einfach so vom Netzt getrennt wird, da es keine Möglichkeit zum sauber Herunterfahren gibt nicht wesentlich kritischer?

Wenn es dem Wolf aber nichts ausmacht das er abrupt vom Netz getrennt wird, dann ist natürlich so ein Systemobjekt unnötig.

Bei mir ist es so, dass alle Server an einer USV hängen (ebenso Router, Switche und Bus).
Wenn nun ein Stromausfall passiert, werden alle Server bei x Minuten Restlaufzeit der USV heruntergefahren. Switche und Router sowie Bus gehen halt dann aus wenn Stromausfall länger dauert und Batterie leer gezogen ist.

Das gleiche passiert momentan auch leider mit dem Wolf, hier wäre so ein externer Befehl zum sauberen Herunterfahren schon eine feine Sache.
Gruß Ben


TWS 960Q ID:359, VPN offen, Reboot erlaubt
Benutzeravatar

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

#13

Beitrag von starwarsfan »

Hallo miteinander
stonie2oo4 hat geschrieben: Mo Dez 13, 2021 9:25 pm Ist dass Szenario das der Server einfach so vom Netzt getrennt wird, da es keine Möglichkeit zum sauber Herunterfahren gibt nicht wesentlich kritischer?
Diese Frage stelle ich mir auch... :confusion-scratchheadyellow:

stonie2oo4 hat geschrieben: Mo Dez 13, 2021 9:25 pm Wenn nun ein Stromausfall passiert, werden alle Server bei x Minuten Restlaufzeit der USV heruntergefahren. Switche und Router sowie Bus gehen halt dann aus wenn Stromausfall länger dauert und Batterie leer gezogen ist.

Das gleiche passiert momentan auch leider mit dem Wolf, hier wäre so ein externer Befehl zum sauberen Herunterfahren schon eine feine Sache.
Hier genauso und das Setup mit einer richtigen USV hat sich mittlerweile schon mehrfach bezahlt gemacht. :handgestures-thumbupright:

Wie die Diskussion weiter oben zeigt, ist das ein schwieriges Thema. Allerdings nicht aus technischer sondern eher aus finanzieller Sicht, nachdem das Feature zur Verfügung steht. Ich kann die Argumentation von @StefanW bis zu einem gewissen Punkt nachvollziehen. Bis zu einem gewissen Punkt aus dem Grund, als dass ich mich darüber wundere, dass überhaupt überlegt wird, derartige Features nicht zur Verfügung zu stellen!? Wir bewegen uns hier ja nicht mehr im Consumer-Markt, oder täusche ich mich?

Ich sehe den TW als ein Spezialprodukt (oder eine Appliance wie es so schön heisst) und dafür sind echte Rechenzentrumsfunktionen ein wichtiger Faktor. Das potentielle Problem mit allfälligem Support kann man da natürlich so oder so sehen. Einerseits ist es völlig nachvollziehbar, dass man versucht ist, den Support-Aufwand gering zu halten. Andererseits wird dadurch die Entwicklung eher behindert, wenn Funktionalitäten mehr nach möglichem Support-Aufwand als nach deren tatsächlichem Mehrwert bemessen werden. Bitte nicht falsch verstehen! Mir geht es darum, eine gute Lösung ausgehend von der gewünschten Funktionalität zu finden und damit dann den Supportfall abdecken zu können. Also nicht in der anderen Richtung ausgehend vom Supportfall zu versuchen, die Funktionalität einzuschränken oder eben gar nicht erst einzuführen.

Gut, das mag vielleicht von der Zielgruppe abhängen aber wenn wir uns schon auf einem derart perfektioniertem Level bewegen, wie das der TW mit Bravour tut, dann schliesst es sich ja eigentlich von selbst aus, dass es keine Möglichkeit zum sauberen Shutdown gibt (um beim Topic dieses Threads zu bleiben).

Und somit stellt sich die Frage: Wie kriegen wir die Kuh vom Eis? Ich glaube nach der bisherigen Diskussion eher nicht mehr daran, dass NUT direkt integriert wird. Wenn sich das über den Umweg eines Containers und entsprechenden System-Objekten lösen lässt, soll's mir Recht sein. Aber Achtung, dann muss man auch sauber einen USB-Port an den Container durchreichen können, sonst nützt die ganze Übung auch wieder nichts.

Also bleiben eigentlich nur die System-Objekte als Lösung übrig. Ich tendiere dazu, dass sich das nur über ein entsprechendes Logging für beide Seiten, also Kunde und Elabnet, sauber lösen lässt. Mit all den bereits vorhandenen Funktionalitäten sollte es doch möglich sein, derart relevante Events nachvollziehbar zu tracken. Bspw. unter Systemeinstellungen > System > Log und dort ein Log der wichtigen System-Events. Also Zeitpunkt des TW-Start und Zeitpunkt des TW-Stop jeweils explizit mit der Angabe des Triggers oder auch wenn ein Backup angelegt wurde. Damit steht dort dann bspw. ob $USER im Web-UI einen Shutdown oder einen Reboot ausgelöst hat oder im Falle der Systemobjekte dann eben, welches davon um welche Zeit getriggert hat. Bei Edomi sehe ich nach dem Login auf das Backend bspw., dass es einen unerwarteten Reboot gab. Sowas sollte doch auch hier möglich sein. Und damit hat man auch schwarz auf weiss im Blick, warum es zum Zeitpunkt X einen Neustart gab.

Just my (etwas mehr als) two cents... :whistle:
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) - ... -

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

#14

Beitrag von Smart Jeanie »

Den Punkt von Stefan verstehe ich.
Ich könnte gut mit einer Variante leben, bei der z.B. genau ein Modell einer USV für den Betrieb mit dem TWS validiert ist. Nur dieses Modell wird dann im Support unterstützt. Diese USV könnte dann von elabnet auch angeboten werden.
Bei allen anderen Produkten ist es dann halt Glückssache.
Markus

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

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

#15

Beitrag von starwarsfan »

Hallo miteinander
Smart Jeanie hat geschrieben: Mi Dez 15, 2021 10:05 am Ich könnte gut mit einer Variante leben, bei der z.B. genau ein Modell einer USV für den Betrieb mit dem TWS validiert ist. Nur dieses Modell wird dann im Support unterstützt. Diese USV könnte dann von elabnet auch angeboten werden.
Die Idee ist nachvollziehbar aber wenn ich jetzt mal aus Stefans Blickwinkel schaue, vergrault man sich damit potentielle Kundschaft. Wenn die USV noch nicht vorhanden ist, mag das funktionieren. Was aber, wenn die entsprechende Infrastruktur schon da ist? Für den Wolf noch eine separate USV? Schon allein ökologisch ist das fragwürdig.

Wenn man den NUT-Weg einschlägt, dann steht ootb diese Liste an unterstützten USVs zur Verfügung. Aber wie oben schon geschrieben, wer's braucht, kann's auch in einem Container lösen (wenn USB durchgereicht werden kann), ohne dass das für alle anderen "mitgeschleppt" wird.

Ich hätte auch kein Problem damit, ein entsprechendes Docker-Image zu entwickeln und zur Verfügung zu stellen, wäre nicht das erste... :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) - ... -

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

#16

Beitrag von StefanW »

Hallo Yves,
starwarsfan hat geschrieben: Di Dez 14, 2021 9:42 pmWie die Diskussion weiter oben zeigt, ist das ein schwieriges Thema. Allerdings nicht aus technischer sondern eher aus finanzieller Sicht, nachdem das Feature zur Verfügung steht.
Auch bevor das Feature zur Verfügung stehe, weil ich schätze die Entwicklungskosten (mit allem drumherum) schon auf einen fünfstelligen Betrag.

Es geht bei technischen Produkten praktisch IMMER nur um die finanzielle Seite. Technisch ließe sich oft mehr realisieren. Wir würden unseren Job nicht gut machen, wenn wir diese Seite nicht im Auge behalten würden und das gilt auch für Folgekosten durch Support.

Etwas überschlägig ausgedrückt, wenn wir für jedes zusätzliche Leistungsmerkmal (auf Dauer) einen weiteren Supporter einstellen müssten, dann wären zusätzliche Leistungsmerkmale nicht mehr möglich.

starwarsfan hat geschrieben: Di Dez 14, 2021 9:42 pmAndererseits wird dadurch die Entwicklung eher behindert, wenn Funktionalitäten mehr nach möglichem Support-Aufwand als nach deren tatsächlichem Mehrwert bemessen werden.
Wenn wir nur noch am supporten sind, dann haben wir keine Ressourcen mehr um zu entwickeln. Man kann bei bestehendem Budget nicht beides haben.

starwarsfan hat geschrieben: Di Dez 14, 2021 9:42 pmMir geht es darum, eine gute Lösung ausgehend von der gewünschten Funktionalität zu finden und damit dann den Supportfall abdecken zu können. Also nicht in der anderen Richtung ausgehend vom Supportfall zu versuchen, die Funktionalität einzuschränken oder eben gar nicht erst einzuführen.
Der Punkt ist, dass wir bei jeder einzelnen Sache die wir entwickeln, nur und ausschließlich den Nutzer als Ziel haben, genauer sein Nutzer- und Konfigurationserlebnis. Die Erwartungshaltungen sind sehr hoch und wir müssen daher alles, was wir anfassen, auch sehr ordentlich, einfach bedienbar und keinen Support verursachend ausführen. Weil die Nutzer wollen keine Probleme mit dem Server, wollen gar nicht in die Situation kommen, dass sie einen Supportfall eröffnen müssten und und die Nutzer wollen auch, dass wir weitere Leistungsmerkmale entwickeln (und nicht stattdessen Support leisten müssen).

Es ist also für eine positive Nutzererfahrung essentiell, dass alles top funktioniert, leicht konfigurierbar ist und der Server den Nutzer bei Problemen möglichst gut auf die Ursache hinweist.

Daraus folgt, dass wir alles, was wir machen, auch wirklich richtig gut machen müssen. Bedeutet aber auch, dass selbst einfache Funktionen Entwicklungsintensiv und damit teuer sein können. Wenn dann eine Funktion noch das Potential hat, zu aufwändigen Supportfällen zu führen, dann muss man das schon abwägen.

Zum Thema Systemobjekte ist zu sagen, dass diese offenbar nicht oder nur von einer Minderheit benutzt werden würden. Wir haben solche Systemobjekte mit dem Leistungsmerkmal HTTP-/REST-API eingeführt. Und während das Leistungsmerkmal deutlich mehr Response bekommen hat als die Leistungsmerkmale Modbus und MQTT zusammen (mithin HTTP/REST-API den Nutzer offenbar wichtig sind) gab es für die darin enthaltene Neuerung der Systemobjekte kaum (ich glaube sogar KEINE) Rückmeldung.

Da sehe ich dann schon eine andere Palette von Features, für die viel Nach- und Rückfragen existieren, als deutlich wertvoller für die breite Basis der normalen Nutzer, als spezielle Systemobjekte für die oberen Top 10 der Nutzer.


Wir haben den Wunsch verstanden und können die Diskussion damit gerne beenden. Die Systemobjekte brauche ich nicht auf die Liste zu schreiben, weil da stehen sie schon lange, auch solche zum herunterfahren. Uns ist klar, dass solche professionelle Leistungsmerkmale durchaus wünschenswert sind. Im Moment sehen wir jedoch auch die Nachfrage nach anderen Leistungsmerkmalen, die wir ebenfalls berücksichtigen müssen. Manchmal tun sich jedoch in der Entwicklung Fenster auf, so dass man das eine durchaus zwischen die anderen Dinge schieben kann. Daher bitte ich euch, das unserem Geschick zu überlassen, wie wir die vielen Wünsche effizient umsetzen.


lg

Stefan
Zuletzt geändert von StefanW am Mi Dez 15, 2021 7:42 pm, insgesamt 1-mal geändert.
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.

macgyver
Reactions:
Beiträge: 33
Registriert: Sa Nov 27, 2021 5:18 pm
Hat sich bedankt: 4 Mal
Danksagung erhalten: 4 Mal

#17

Beitrag von macgyver »

Hi,

also mal unabhängig von der Diskussion hier - ich für meinen Teil werde diese Funktion nicht realisieren wollen so. Ich habe mich entschieden das wie folgt umzusetzen, dass ich den TWS mit meinen Busmastern auf eine Phoenix UPS Mini 12 V USV mit Batterie einsetzen werde.
Problem war nur , dass die USB Kabel max 3 Meter sein dürfen, daher hab ich mich für eine Schaltschrankleiste mit Hutschiene entschieden auf 3U, ich denke das wird eine gut Brauchbare Lösung werden. So geht bei Stromausfall der TWS weiter.....arbeitet dann seine Liste ab und fährt dann später herunter.....ob das so geht, wird sich noch zeigen.

Und ich denke , dass einfachste um einen Stromausfall mitbekommen zu können dürfte ein 230V Binäreingang sein , der eine KNX Adresse schreibt. +/ - Hysterese,,,, Da bin ich noch am Experimentieren gedanklich.
-- --Timberwolf 2500S-- -- TWS #606 / VPN inaktiv / Reboot nur nach Absprache
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Allgemein“