Insolvenz der Elaborated Networks GmbH

Leider müssen wir Sie heute darüber informieren, dass das Amtsgericht München mit Beschluss vom 16. Oktober 2026 das Insolvenzverfahren über das Vermögen der Elaborated Networks GmbH unter dem Aktenzeichen 1509 IN 1258/26 eröffnet hat.

Zum Insolvenzverwalter wurde Herr Rechtsanwalt Dr. Matthias Hofmann bestellt. Dieser hat die Verwaltungs- und Verfügungsbefugnis über das Vermögen der Gesellschaft übernommen.

Die Gesellschaft firmiert ab sofort unter dem Namen: “Elaborated Networks GmbH in Insolvenz”. Der Geschäftsbetrieb der Gesellschaft wurde im Zuge des Verfahrens eingestellt. Eine Erbringung von Leistungen oder Lieferungen ist leider nicht mehr möglich. Die Cloud-Dienste werden bis auf weiteres im Rahmen einer privaten Initiative aufrechterhalten, dies kann jederzeit widerrufen werden.

Sollten Sie noch offene Forderungen (§ 38 InsO) gegen die Elaborated Networks GmbH haben, werden Sie gebeten, diese direkt beim Insolvenzverwalter bis zum 7. Dez. 2026 zur Insolvenztabelle anzumelden. Bitte richten Sie sämtliche diesbezügliche Korrespondenz direkt an das Büro des Insolvenzverwalters:

Rechtsanwalt Dr. jur. Matthias Hofmann
Unterer Anger 3
80331 München

Telefon: +49(89)5480330
Telefax: +49(89)548033111
Email: mail@pohlmannhofmann.de

Wir bedanken uns für die bisherige Zusammenarbeit und stehen Ihnen bei Rückfragen in Abstimmung mit dem Insolvenzverwalter unter support at elabnet dot de gerne zur Verfügung.

Details zum Verfahren und den privaten Initiativen stellen wir Kunden in einem nicht-öffentlichen Bereich zur Verfügung. Falls Sie hier keinen Zugriff haben, dann tragen Sie bitte Ihren Forennick in die Registrierung Ihres Servers ein und senden uns den Nick zusammen mit der ID Ihres Timberwolf Servers an support at elabnet dot de. Falls Sie hierzu erst einen Nick anlegen müssen verfahren Sie genauso. Das Bestätigungsmail nach der Anmeldung kommt aus technischen Gründen derzeit nicht, die Aktivierung erfolgt dann manuell nach Ihrer Mail an uns.

Stefan Werner
Geschäftsführer (ohne Vertretungsmacht)

[TIPP] Leitfaden zur strukturierten Fehlersuche in 1-W (und anderen) Bussystemen

Ihr habt ein tolles 1-Wire Projekt gebaut, dann stellt es vor, es hilft anderen auf Ideen für die eigenen Aufgabenstellungen zu kommen.
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
Antworten
Benutzeravatar

Ersteller
773H
Beiträge: 428
Registriert: Mo Okt 15, 2018 9:24 pm
Hat sich bedankt: 104 Mal
Danksagung erhalten: 291 Mal

Leitfaden zur strukturierten Fehlersuche in 1-W (und anderen) Bussystemen

#1

Beitrag von 773H »

Aus aktuellem Anlass der schon seit längerem fälligen Fehlersuche bei mir. Hilft vielleicht dem einen oder anderem auch weiter, der das so noch nie machen musste ... :idea:
Ein Leitfaden zur strukturierten Fehlersuche in 1-W (und anderen) Bussystemen findet sich sicherlich auch in der einen oder anderen Dokumentation von ElabNET in einer ähnlichen Form. Im Forum konnte ich diesbezüglich nichts ausführliches finden. Darf gerne in der KB hierhin -> app.php/kb/viewarticle?a=54 <- verschoben werden, da hätte ICH es gefunden)

Ausgangssituation
Seit 2 Jahren machte einer meiner Außensensoren (Hülsenfühler mit Silikonleitung) im Gullisumpf Probleme, wenn die Temperaturen in den zweistelligen Minusbereich gingen. Er lieferte dann keine Werte mehr. Erstmal egal.
Seit ca. einem halben Jahr zeigte der Kanal des PBM mit dem angeschlossenen Außenbereich eine verminderte Busqualität (5%) mit dem Mouse-over-Hinweis: „viele Fehler, Verkabelung, Klemmstellen, Buslänge überprüfen“ (oder so ähnlich). Erstmal egal, denn die 5 Balken daneben waren alle grün, die Messwerte aller Sensoren wurden weiterhin zuverlässig geliefert, die Zeitserien zeigen keine Aussetzer (bis auf manchmal den Gullifühler).
Seit dem Update des TWS von V3.0IP3 auf V3.0IP4 dann das Desaster: Nach dem Neustart des Systems war der Kanal des PBM dauerhaft rot hinterlegt. PBM-Kanal tot. Nicht egal, denn alle an diesen Kanal angeschlossenen Sensoren waren auf einen Schlag weg.
ext/dmzx/imageupload/files/0b7e98dac483 ... 04cf34.jpg

Deswegen ist es auch WICHTIG, einen Neustart des Servers ca. 1 Tag VOR der Updaterei durchzuführen, denn dieser schon länger bestehende Fehler trat ja erst NACH dem Neustart störend in Erscheinung und würde dann fälschlicherweise dem Update angelastet!!!

Vorüberlegung
Es spielt eine Rolle, ob man Fehler in einer Bestands- oder Neuinstallation sucht. In meinem Beispiel einer lange Jahre fehlerfrei funktionierenden Bestandsinstallation kann man natürlich alle Verdrahtungsfehler, ungünstige Buslänge, ungeeigneten Abzweige, etc. ausschließen. Es kann letztendlich nur einer (oder mehrere!) der Sensoren defekt sein oder sich eine Klemmstelle gelöst haben (wenn kurz zuvor keine Bauarbeiten (Bohrer!) im Haus durchgeführt wurden und auch keine neuen Sensoren hinzugefügt wurden!). Diese Art von Fehler in einer Neuinstallation / Änderungsinstallation / Post-Baustellen-Installation lassen sich allerdings durch die im Folgenden beschriebene Fehlersuche ebenfalls ausfindig machen.

Fehlersuche
Wichtig ist hierbei vor allem, dass man SYSTEMATISCH vorgeht, um unnötige Mehrfacharbeiten zu vermeiden. Weiterhin ist es essentiell, dass der Fehlersuchende weiß, wo ALLE Klemmstellen und Sensoren zu finden sind und diese natürlich auch zugänglich sind!
ext/dmzx/imageupload/files/f38adc69c0a5 ... 219588.jpg
Wir gehen mal davon aus, dass der Eigentümer der Anlage dieses Wissen hat, denn sonst wird es sehr zeitaufwendig.
Zunächst zieht man den entsprechenden Stecker des Kanals des PBM ab und überprüft, ob der Kanal wieder die vorherige Busqualität liefert. Dies dient dazu, Hardwaredefekte durch den Fehler am PBM auszuschließen. Man kann natürlich auch im entsprechenden Stockwerk das ankommende Buskabel vom Rest trennen und muss nicht an den PBM (Abdeckungen im Sicherungskasten, etc).
ext/dmzx/imageupload/files/d9505cb000a6 ... c3dc87.jpg
Danach sucht man sich eine Klemmstelle an der zu untersuchenden Buslinie, die idealerweise mittig zwischen allen angeschlossenen Sensoren liegt - also 50% der Sensoren sind vor und 50% der Sensoren sind hinter dieser Klemmstelle an den Bus angeschlossen. Hier wird der Bus nun aufgetrennt, indem man vorsichtig an dem zu lösenden Draht zieht und dabei die Wago-KNX-Klemme durch leichte Drehbewegungen hin und her bewegt.
[Anmerkung: wenn man das zu oft macht, nutzt sich der Kupferdraht immer weiter ab, bis er nicht mehr zuverlässig in der Klemme hält. Man kann das an den zunehmenden Riefen im Kupfer erkennen, die irgendwann in eine Mattierung übergehen. Spätestens jetzt sollte man den Draht an der Isolierung abzwicken und neu abisolieren. Wer auf Nummer sicher gehen will, macht das vor jedem neuen Einstecken des Drahtes in die KNX-Busklemmen. Wenn sich der Draht ohne Drehbewegungen aus der Klemme ziehen lässt, hat man eine neue zukünftige Fehlersuche erfolgreich vorbereitet ...]
ext/dmzx/imageupload/files/bdaf42d2cc34 ... ae21da.jpg
Dies kann unter entsprechenden Vorsichtsmaßnahmen auch unter Spannung (SELV) durchgeführt werden, ist aber aus Gründen von möglichen Hardwaredefekten NICHT empfehlenswert!
[Anmerkung: aus historischen Gründen ist bei mir im Projekt das 1-W-Buskabel GRÜN und der KNX-Bus ORANGE. In Abweichung zu den vorherrschenden Meinungen in anderen Foren ist auch diese Kombination funktionstüchtig]. :mrgreen:
Einzelne UP-Sensoren lassen sich durch Abziehen der Wagoklemmen vom Bus trennen – das ist identisch zu KNX-Geräten.
Nach dem Öffnen der Buslinie an dieser Stelle kann man unter den Reitern „1-Wire“ -> „Schnittstellen“ auf -> „erneute Inventur“ drücken oder warten, bis sich das System selbst aktualisiert hat. Ist der Kanal jetzt wieder grün (nicht notwendigerweise allerdings auf 100%) bzw. die rote Kanalmarkierung weg, wissen wir, dass der Fehler auf der abgeklemmten Seite des Busses liegt.
Ist der Kanal weiterhin gestört, wissen wir, dass zumindest „EIN“ Fehler auf der noch angeschlossenen Seite liegt. Für die weitere Beschreibung gehen wir einfach davon aus, dass es genau „EINEN“ Defekt in dieser Buslinie gibt, denn sonst wird die Beschreibung unnötig lang und kompliziert. Mehrfachfehler lassen sich durch dieses Vorgehen genauso ausfindig machen.
Wir gehen davon aus, dass durch die eben durchgeführte Maßnahme der Bus wieder auf „grün“ ist.
ext/dmzx/imageupload/files/46a6feb170e4 ... 963fe8.jpg
Man schließt in diesem Fall die abgeklemmten Drähte wieder farbrichtig an und bewegt sich weiter am Bus entlang Richtung einer Klemmstelle, an der die Sensoraufteilung 25% hin zum Ende des Buskabels und 75% zum PBM ist. Hier wird wieder aufgetrennt und wieder getestet, ob der Bus in Ordnung ist. Man führt diese Schritte nun so oft Richtung Ende des Buskabels (und im weiteren Verlauf natürlich auch eventueller Abzweige) durch, bis man letztendlich am Verursacher der Störung angelangt ist. Dieser wird dann abgeklemmt / getauscht.
Eine Übersicht über noch verbleibende Sensoren liefert im Übrigen der „Slave-Manager“ An dieser Stelle kann man nachsehen, wenn man sich nicht mehr ganz sicher ist, was noch alles im weiteren Verlauf an Sensoren angeschlossen wurde.
ext/dmzx/imageupload/files/3e667d62d7ad ... 745a49.jpg
Wenn man sicher gehen will, dass jetzt alles wieder in Ordnung ist, kann man den TWS neu starten, denn dann werden auch alle 1-W Dienste neu gestartet und damit die Bushistorie mit der Busqualität gelöscht. Alternativ kann man auch nur den 1-W Dienst unter „Systemeinstellungen“ -> System“ -> „Monitor“ neu starten, indem man hinter „1-W-Subsystem“ auf „Neustart“ klickt – das habe ich allerdings nicht getestet und weiss nicht, ob das so wie gedacht funktioniert.
ext/dmzx/imageupload/files/dfcf652e94e4 ... 14cec0.jpg

Viel Erfolg bei der Fehlersuche
Stephan
Zuletzt geändert von 773H am Mi Dez 29, 2021 3:26 pm, insgesamt 2-mal geändert.
TWS 2500 ID:677, PBM ID:495 & ID:632, TWS 2500 ID:574, TWS 2500 ID:220, PBM ID:1022, VPN offen, Neustart kein Problem

MartinMV
Elaborated Networks
Elaborated Networks
Beiträge: 6
Registriert: Sa Aug 11, 2018 10:47 pm
Hat sich bedankt: 4 Mal
Danksagung erhalten: 13 Mal

#2

Beitrag von MartinMV »

Auch wenn ich jetzt nicht alle Bilder angesehen habe, ist das im Allgemeinen genau die Vorgehensweise, die wir im Support so auch empfehlen.
Gerade durch die stetige Halbierung des vermutlich fehlerhaften Busstücks kommt man oft recht effizient ans Ziel.

Beim Lösen der Busleitung von der WAGO-Klemme bitte bedenken, dass die Leiter hier evtl. geknickt werden, wenn man nicht aufpasst.
Wir hatten schon mehrmals den Fall, dass sich, nach langem Suchen, ein verdeckter Leiterbruch als Ursache für den vermeintlich defekten Sensor herausgestellt hat.
Antworten

Zurück zu „Vorstellung Eurer Projekte“