[Beantwortet] [V4.5] TWS350Q, Login klappt nicht mehr, RUN-LED blinkt doppelt

[bluegaspode]

Moin zusammen,

ich wollte mal wieder eine ETS-Programmierung machen und stelle fest, dass der Timberwolf nicht mehr als KNX-Gateway auftaucht.

Beim Versuch des Logins in die Weboberfläche:
- wird das statische HTML der Login-Seite geladen (/login, diverse Javascripts, pngs)
- nicht geladen (404 not found) wird die 'global_settings.json?65522.666332576104'
- die Webseite zeigt dauerhaft das drehende Zahnrad und die Meldung "Timberwolf Server Web app is Loading"
- die Webseite zeigt die Meldung: " Verbindung zwischen Web-APP und Timberwolf Server ist unterbrochen. Es wird versucht die Verbindung automatisch wiederherzustellen. Während des Verbindungsaufbaus sind keine Eingaben möglich."
- reagiert normal auf pings auf die IP

Nach öffnen des Verteilers:
- die "Run" LED blinkt immer doppelt in zügiger Folge
- habe die PWR-Knopf gedrückt um neu zu booten- ich komme aber beim gleichen Ergebnis raus (doppelt blinkende RUN-LED und kein Login möglich)

Die letzte Aktion an die ich mich beim Timberwolf erinnern kann ist der Klick auf "Update" Button, was die 4.5er Hauptversion installiert hat (irgendwie vor 2-3 Wochen).

Der Timberwolf hat keine aktiven Aufgaben mehr bei mir (außer IP-Gateway für die ETS und manchmal der Busmonitor). Wie lange der Fehler existiert, kann ich daher nicht gut eingrenzen, weil es mir evtl. gar nicht aufgefallen ist.

Die Suche hier im Forum nach 'run led' bringt 11 Ergebnisse die mich erstmal nicht weiterbringen (außer dass eine blinkende LED wohl nicht der Normalzustand ist). Die Suche im https://elabnet.atlassian.net/wiki/ mit "run led" hat auch keine Treffer.

Habt ihr eine Idee, wie ich das potentielle Problem weiter eingrenzen kann?

Grüße
Stefan

[StefanW]

Hi Stefan,

blinkende oder nicht leuchtende RUN-LED zeigt u.a. an, dass nicht alle Module geladen wurden. Welche der gut zwei Dutzend Module ein Problem haben, kann man nicht aus dem Blinken entnehmen.

Falls der Timberwlf Server geprüft und ggfls. repariert werden soll, bitte Ticket mit Mail an service at elabnet dot de eröffnen und auf diesen Thread verweisen.

Sorry für Probleme

lg

Stefan

[bluegaspode]

OK, Weitere Eigendiagnose (lokaler login o.ä, Zugriff auf Logs) ist nicht möglich?

Für mich läuft das dann gerade auf finale Ablösung des Timberwolf hinaus. Bisher habe ich > 2.000€ Umsatz in das Gesamtsystem investiert, weitere Investitionen sind nicht geplant.

Wenn es für euch von Interesse ist herauszufinden, warum ein nur 6 Jahre altes Gerät, was im wesentlichen als IP-Router und Busmonitor fungierte und ca 1x pro Jahr einen Klick auf den "Update" Button bekommen hat nun ausfällt, meldet euch.

[StefanW]

Hi Stefan,

Wenn es für euch von Interesse ist herauszufinden, warum ein nur 6 Jahre altes Gerät, was im wesentlichen als IP-Router und Busmonitor fungierte und ca 1x pro Jahr einen Klick auf den "Update" Button bekommen hat nun ausfällt, meldet euch.

Danke, wissen wir mittlerweile. Der Server hat eine Meldung an die Cloud ("Insufficient disk space (stage 3) 0.00 B free") abgesetzt, dass der Massenspeicher zu 100% voll ist. Stage 3 heißt, das zuvor zwei Warnungen mit Hinweis auf den vollaufenden Speicher im Nachrichtencenter angezeigt wurden. Warum und weswegen der Speicher voll ist, kann ich nicht sagen, weil der Server seine eigenen Buslogs und Logs automatisch bei Knappheit eingekürzt. Bei anderen Nutzern, denen das passierte, waren Docker Container (deren Logs und Backups) die Ursache.

Wenn Du das Gerät nicht mehr nutzen möchtest, kannst uns den auch gerne für Ersatzteillager usw. "spenden", bitte nicht wegwerfen, der Hardware fehlt nichts, wäre schade.

lg

Stefan

[bluegaspode]

>> vollaufenden Speicher im Nachrichtencenter angezeigt wurden.
ok - was natürlich nicht gesehen wird, wenn man sich nur alle 6 Monate einloggt.

Portainer/Docker wurde nicht produktiv genutzt, ich kann aber nicht ausschließen, dass ich vor 4 Jahren mal irgendeinen Demo-Container installiert habe. Wüsste aktuell aber nicht (mehr) was, relevante Container laufen ja gar nicht auf dem 350er.

Die separate SD-Karte die ich selber entnehmen kann ist definitiv nicht voll, eher gähnend leer, die habe ich schon geprüft.

Ich entnehmen deinen Posts, dass diese Problem nicht selbst lösbar ist sondern nur durch einschicken und ihr euch dann irgendwie lokal draufschalten könnt? Das WartungsVPN habe ich per Default nicht an (und bekomme es durch fehlenden Login auf die Weboberfläche auch nicht mehr an).

[StefanW]

Die separate SD-Karte die ich selber entnehmen kann ist definitiv nicht voll, eher gähnend leer, die habe ich schon geprüft.

Die ist für Backup

Ich entnehmen deinen Posts, dass diese Problem nicht selbst lösbar ist sondern nur durch einschicken und ihr euch dann irgendwie lokal draufschalten könnt?

Richtig, wobei es danach i.d.R. komplett neu installiert und durchgecheckt wird.

Bitte Ticket eröffnen.

lg

Stefan

[bluegaspode]

Ich habe den Server am Wochenende ausgebaut und schließe für mich das Kapitel elabnet damit ab.
Ich habe mich über die Jahre zu viel geärgert (und über diesen Fall auch schon wieder), und es fühlt sich für mich gut an, jetzt emotional abzuschließen.

Mich hats letzte Woche echt auf kaltem Fuß erwischt, dass euer Server gebrickt werden kann, wenn man ihn unbedarft falsch benutzt.
Wir werden jetzt nicht mehr feststellen, ob irgendein 3 Jahre alter TestDocker die SDKarte vollgemacht hat oder es was anderes war. Meine "intensive Nutzung" war es jedenfalls nicht, ich logge mich nur 1mal jedes halbe Jahre ein um Updates einzuspielen oder mal auf den Busmonitor zu schauen.

Ich habe gelernt, dass ihr bei so einem fatalen Fehlerbild "Server Bricked":
- das Problem kennt, aber eure Systempartition nicht vor Überlauf schützt (oder einen Recovery Modus habt)
- ihr einen Push bekommt, wenn der Server kurz davor ist ein echtes Problem zu haben und daraus aber nichts macht, um den Kunden/das System zu schützen (stattdessen als 'technische Information' getarnte Werbemails). Ich hätte wohl lieber die "technische Information" gehabt, dass mein System in kritischem Zustand ist.

Es hat mich jetzt zum Glück nicht fatal erwischt:
- ich hatte keine Logiken mehr auf dem Server
- ich habe vor 3 Jahre proaktiv 1wire Stück für Stück rückgebaut
- einzig allein die Automationen/Visu auf einem anderen System haben nicht mehr funktioniert, weil das System nichtmal mehr als IP-Router arbeitete. Zum Glück genau in der Woche, wo meine Frau eine Woche auf Dienstreise war.

Ich wünsche dem nächsten Nutzer mit ähnlichem Fehlerbild der sich deutlich intensiver auf den Timberwolf eingelassen hat, dass elabnet hier prozessual oder SW-seitig nachbessert. Sowas kann RICHTIG böse ins Auge gehen und dann sitzt du da mit gebricktem Server a.k.a gebricktes Haus bei deinem 1.000€ Server und bekommst Ehestress, wenn du vielleicht noch elabnet Anleihen für weitere 1.000€ gekauft hast.
Oder lustige Haftungsfragen als Systemintegrator .

Machts gut soweit - mit einigen von euch sehen wir uns bestimmt auf der Light & Buildung.
Bis dahin!

Tschüssi - der Stefan

[Didda93]

Ausgehend davon, dass es sich darum handelt, dass ein Docker Container den kompletten Speicher vollgeschrieben hat:
Es ist immer schwierig zwischen Sicherheit und Nutzungsfreiheit zu balancieren. So manches Mal wurde sogar ein Root-Zugriff gefordert/gewünscht. Ich will mir garnicht vorstellen zu wie vielen Problemen es da kommen würde und wie oft dann Elabnet "schuld" wäre.

Das mit Docker ist dennoch eine wichtige Freiheit, die jedoch auch das Risiko hat, dass man sich damit den Server vollschreibt.
Es gibt den deutlichen Hinweis, dass man mit der Nutzung von Portainer ein Risiko eingeht. Dieses bist du mit deinem "TestDocker" bewusst eingegangen. So leid es mir tut aber da kann man dann keinem anderen die Schuld geben wenn man Jahr später nicht mehr weiß was genau dort gemacht wurde.

Natürlich ist eine zusätzliche Sicherheit (wie das Verhindern des kompletten Vollschreibens des Speichers) wünschenswert, jedoch muss dafür Ebtwicklungskapazität eingesetzt werden, die sonst woanders fehlt.

Für Systemintegratoren sollte das Risiko kein Problem darstellen, denn diese wissen für gewöhnlich was sie machen. Wenn Kabel falsch verdrahtet werden können Elektriker auch nicht den Hersteller von Geräten verantwortlich machen, wenn diese durch einen Kurzschluss kaputt gehen. Wieso sollte es hier anders sein?


Ich verstehe deinen Frust natürlich und Elabnet ist sicherlich einer der wenigen Hersteller, die bei der nächsten Gelegenheit, wenn sie soweiso in diesem Bereich weiterentwickeln, einen Schutz einbauen. Auch wenn Problem XY bisher nur einen Nutzer betroffen hat.

Aber das ist nichts was man erwarten kann, da man, wie gesagt, das Risiko bewusst eingeht. Hinweise sind dazu vorhanden.


Wenn du das Angebot ein Ticket zu eröffnen und eventuell eine gute Lösung zu finden nicht annehmen willst, bzw ihr nicht zu einer Einigung gekommen seid, dann trotzdem alles Gute für dein SmartHome

[devilchris]

@bluegaspode schade das es so geendet ist mit deinem Server. Das Angebot ein Ticket zu eröffnen wurde ja unterbreitet hier hätte man bestimmt eine Lösung finden können.

[AndererStefan]

Hi,

welche Sicherheitsvorrichtungen / Warnhinweise gibt es denn derzeit bei volllaufender Festplatte? Zeigt die Visu eine Warnung an?
Sonst könnte man ja auch einen Alert und eine Notification (via E-Mail, Telegram, ...) in Grafana erstellen.

In der "Timberwolf Monitoring DB" findet man unter "sys_stats" den Eintrag "disk_free" (Oder einfach im TWS Interface unter System > Monitor bei Systemüberwachung auf das Grafana-Icon klicken.)

VG
Stefan