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
Benutzeravatar

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

TW und USV via NUT?

#1

Beitrag von starwarsfan »

Hallo miteinander,

in Anlehnung an den Thread "UMFRAGE: Interessse an USV- und / oder NV-RAM Modul" und dem gestrigen Stromausfall (bei dem sich die USV im Rack super bezahlt gemacht hat) erneut das Thema USV. Konkreter Hintergrund ist, dass der TW noch nicht auf die Events der USV reagieren kann. Neben den bestehenden Threads hier nun etwas genauer beleuchtet.

Da der TW ja ein sehr zentrales System ist, stellt sich mir die Frage, ob man nicht "einfach" NUT bereitstellen und via UI konfigurieren könnte. Ich habe "einfach" in Quotes geschrieben, da ich selber Softwareentwickler bin und weiss, dass das mit dem "einfach" i.d.R. etwas anders aussieht. ;) Daher an dieser Stelle erstmal die Diskussion dazu, einen Feature-Request kann ich dann gerne separat schreiben.

Idee und Hintergrund:
Für das Handling von USVs (oder sollte das besser USVen heissen? :confusion-scratchheadyellow: ) steht das Paket NUT, Network UPS Tools zur Verfügung. Das Tool ist herstellerneutral und kann eine grosse Liste von USVs handhaben.

Es gibt bzgl. USV-Handling zwei Szenarien:

1. TW als Client
In diesem Szenario unterhält sich der TW mit einen NUT-Server im lokalen Netz. Je nachdem, was dessen Status ist, wird reagiert. Der einfachste Fall ist dabei, den TW bei kritischem Akku-Stand der USV herunterzufahren. Im UI braucht es für diesen Fall lediglich die Zugangsdaten zum NUT-Server. Das wären der Connection-String (bspw. "ups@192.168.10.220"), Username und Passwort sowie der Client-Typ (Master/Slave als Radiobuttons). Als Beispiel hier die Konfiguration eines NUT-Client auf den Hosts eines ProxMox-Clusters. Das ist kein Rocket-Science und läuft so hier bei mir.

2. TW als Server
In diesem Szenario agiert der TW als NUT-Server und überwacht selbst die USV. Das heisst, dass diese via USB an den TW angeschlossen werden muss. Hier braucht es nun etwas mehr Konfigurationsaufwand, da zum Einen auf die Reaktion des TW selbst und zum Anderen auf potentielle weitere Geräte im Netz eingegangen werden muss, welche bei Stromausfall in irgendeiner Art und Weise reagieren sollen. Synology macht das bspw. so, dass man

a) selektiert, wann das NAS herunterfahren soll und
b) eine Liste der NUT-Clients pflegt (IPs), welche den NUT-Server abfragen.

Zusammenfassung:

M.M.n. ist das erste Szenario (TW als Client) wesentlich einfacher zu realisieren, da der TW hier auf vorhandene Infrastruktur zurückgreifen kann. Was ich mir als Nebeneffekt aber sehr gut vorstellen kann, ist das Monitoring der USV! Das wäre sicher eine coole Sache, insbesondere mit dem kommenden Meldungsverwalter.

Variante zwei (TW als Server) braucht sicher mehr Hirnschmalz aka Entwicklerstunden und hängt wie alles andere auch vom Bedürfnis der Kundschaft ab.

Meinungen?
Zuletzt geändert von starwarsfan am Sa Dez 11, 2021 9:10 pm, insgesamt 2-mal geändert.
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) - ... -
Benutzeravatar

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

#2

Beitrag von starwarsfan »

Zuletzt geändert von starwarsfan am Sa Dez 11, 2021 9:06 pm, insgesamt 1-mal geändert.
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: 7633 Mal
Kontaktdaten:

#3

Beitrag von StefanW »

Hi Yves,

die Sache ist nicht so einfach.

1. Die am Markt verfügbaren USVs erscheinen mir unübersehbar. Ich glaube nicht daran, dass jede USV sich vollständig kompatibel zu NUT verhalten wird.

2. Die Erfahrung zeigt, dass selbst dann, wenn wir eine kostenfreie Software in den Server integrieren, hierfür dann Unterstützung, Aktualisierungen, Erklärungen & Wiki, Stellungsnahmen usw. verlangt werden, insbesondere dann, wenn das ein sehr starkes Feature ist, dass die Wirkung hat, dass der Server deswegen herunter fährt.

3. Das ist auch ein stark emotionales Feature. Weil wenn es zu einem - vom Nutzer nicht nachvollziehbaren - Verhalten des Servers kommt (z.B. durch Kompatibilitätsprobleme mit der USV), sei es dass der Server heruntergefahren ist, obwohl er das nach Ansicht des Nutzers nicht sollte oder umgekehrt. dann könnte dies zu unübersehbaren und emotional aufgeladenen Supportaufkommen führen.

Wir verstehen, dass es toll wäre, wenn ein Server auf eine USV reagiert und entsprechend sauber herunterfährt. Aber wir haben Sorge, dass der Aufwand - auch über viele Jahre gesehen - umfangreicher wird als das zunächst erscheinen mag und wir befürchten, dass wir von dem ein oder anderen "an die Wand genagelt" werden, wenn so ein USV-Feature nicht so funktioniert wie gedacht und dies am Ende - auch wegen der vielen verschiedenen Geräte und Verbindungsvarianten - zu einem nicht übersehbaren Supportaufkommen führt.

Wir behalten das Thema im Hinterkopf, weil wir verstehen, dass es für einige wichtig ist, müssen aber auch die Supportseite beachten.


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.

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#4

Beitrag von Robert_Mini »

ich habe keine USV (dafür ein sauberes Rebootverhalten).
Für NUT: tut sich da nicht ein Weg auf mit: NUT im Container mit MQTT, MQTT am TWS und künftige Systemobjekte, die damit angesprochen werden können?

Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

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:

#5

Beitrag von StefanW »

Guten Morgen Robert,
Robert_Mini hat geschrieben: So Dez 12, 2021 9:44 amFür NUT: tut sich da nicht ein Weg auf mit: NUT im Container mit MQTT, MQTT am TWS und künftige Systemobjekte, die damit angesprochen werden können?
Wir denken über Systemobjekte auch schon nach und haben über diesen Weg auch schon diskutiert.

Es hätte den Charme, das wir für die Kommunikation mit der USV nicht verantwortlich sind.

Aber, sobald man so ein Feature "herunterfahren per Objekt" anbietet, läuft man Gefahr, dass wir unter Reaktionsdruck gebracht werden dürften, wenn der Server auch nur einmal heruntergefahren ist, obwohl der Nutzer das nicht nachvollziehen kann.

Ihr kennt das doch aus der aktuellen Diskussion. Wenn jemand irgendeine Spritze bekommen hat und am nächsten Tag mit dem Auto an den Baum fährt (obwohl er in den Jahren zuvor nie gegen einen Baum gefahren ist) dann gibt es Menschen, die einen Zusammenhang herstellen der womöglich nicht gegeben ist.

Ich habe Sorgen, dass wenn wir ein Feature einbauen, dass man den Server per Systemobjekt herunterfahren kann, dass dann, wenn der Server eines Tages vom Nutzer - zum Beispiel bei der Rückkehr aus dem Urlaub - als "Aus" angetroffen wird (etwa weil der Strom weg ist), wir dann "ihr habt doch bestimmt ein Log" gebeten werden, hier eine Untersuchung vorzunehmen.

Wie gesagt, das ist ein Thema mit hohem Potential für Emotionen auf der Nutzerseite. Das möchten wir bitte mit Vorsicht betrachten wollen.


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.

pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#6

Beitrag von pbm »

Seht schöner Vergleich, das mit dem Baum. :D

Vielleicht kann man die Emotionen in Grenzen halten:

Folgende Idee:
- Ein Systemobjekt "USV Restlaufzeit in Minuten" (INTEGER), das in eine system-timeserie schreibt.
- Ein Grenzwert, der einstellbar ist. Der muss auch in eine system-timeserie geschrieben werden. (Zylisch?)
(System Timeserie deshalb, damit der User das nicht abstellen kann.)

Bei USV-Restlaufzeit < Grenzwert --> fahre den Server herunter.
(Da muss natürlich noch ein bisschen Intelligenz rein, z.B. erster empfangener Wert der Restlaufzeit muss > Grenzwert sein. Oder oder oder)

Die timeserie sollte ja bis zum Unterschreiten des Grenzwertes geschrieben werden.
So lässt sich der Grund für das runterfahren durch übereinander legen der beiden timeseries zweifelsfrei nachweisen.

Schön wäre dann auch noch ein restore on Power loss = last state

Das bedingt natürlich, dass man eine USV hat, die die Restlaufzeit auf einer Schnittstelle ausgibt, deren Daten man irgendwie in den TWS bekommt.

Für jemanden, der noch keine USV hat, wäre das ein Parameter, den er bei seiner Kaufentscheidung berücksichtigen kann...
vielleicht kann die USV von Ives das auch?

In meinem Fall geht das über Modbus TCP mit einer APC/Schneider USV mit Network Management Card.

Jetzt warte ich nur noch auf die Umsetzung meines Vorschlags... :mrgreen:
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#7

Beitrag von Robert_Mini »

Das muss aus meiner Sicht viel einfacher sein und mit den vorhandenen Technologien kombiniert werden.
Systemobjekte / Dispatcher / Logik.

Wenn Systemobjekt "ShutdownTWS" eine 1 empfängt wird ein Shutdown eingeleitet, fertig.

Für Stefans (berechtigte) Sorgen würde ich empfehlen, dass nur lesbare Systemobjekte freigeschaltet sind.
Das "Shutdown"-Systemobjekt muss man selber freischalten, wie das Häkchen bei MacVLAN + Warnung, erst dann darf das Objekt im Dispatcher durchgereicht werden.

So oder so ähnlich könnt ich mir das vorstellen.

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

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

#8

Beitrag von gbglace »

Ja, da bedarf es einen dicken Disclaimer und explizit manuelles zutun, das das Objekt (TWS-Shutdown) verfügbar ist.

Wer dann per Logik oder KNX-Telegramme oder sonstiger Daten-quellen wild das Objekt auslöst muss selbst mit der Konsequenz leben.

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

Mehr Integrationsnotwendigkeit sehe ich da auch nicht.
Da kann man sich dann immer noch selbst eine Option bauen erstmal ein paar Mails / SMS usw. zu verschicken bevor man das dann aktiviert. Und was der Trigger ist, KNX / MQTT / NUT ist dann ziemlich egal.
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

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#9

Beitrag von Sun1453 »

StefanW hat geschrieben: So Dez 12, 2021 9:53 am
Ich habe Sorgen, dass wenn wir ein Feature einbauen, dass man den Server per Systemobjekt herunterfahren kann, dass dann, wenn der Server eines Tages vom Nutzer - zum Beispiel bei der Rückkehr aus dem Urlaub - als "Aus" angetroffen wird (etwa weil der Strom weg ist), wir dann "ihr habt doch bestimmt ein Log" gebeten werden, hier eine Untersuchung vorzunehmen.

Wie gesagt, das ist ein Thema mit hohem Potential für Emotionen auf der Nutzerseite. Das möchten wir bitte mit Vorsicht betrachten wollen.
Disclaimer davor wie bei der Container Verwaltung — Es handelt sich hierbei um ein Experten Feature und es ist mit Vorsicht und bedacht zu verwenden. Ihr übernehmt für die Auslösung durch irgendwelche Objekte keine Verantwortung. Einzig die Verbindung vom Objekt zur Funktion im Betriebssystem ist in eurer Verantwortung.
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 |

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#10

Beitrag von Sun1453 »

gbglace hat geschrieben: So Dez 12, 2021 12:39 pm
Zur 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.
Sehr gute Idee :clap: :dance: :handgestures-thumbupright:
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 |
Antworten

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