ElabNET Technik Forum

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? ) 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?

Links zu bestehenden Threads dazu:
[FR] APCUPSD / NUT Support
Wie den TWS von aussen herunterfahren?

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

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

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

Seht schöner Vergleich, das mit dem Baum.

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

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

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.

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.

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