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
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)
Alles rund um Node Red im Allgemeinen und den entsprechenden Docker-Container für den Timberwolf Server im Speziellen.
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
ich kämpfe mit der Einstellung für WebSocket Unterstützung wenn ich den ReverseProxy für NodeRed nutzen möchte.
Dabei versuche ich den Dashboard Websocket für NodeRed der unter dem Pfad ws://Dashboard-IP:1880/ui/socket.io/ erreichbar ist über den Reverse Proxy einzubinden. Allerdings scheint "socket.io" nicht akzeptiert zu werden bei der Eingabe in die betreffenden zwei Input-Felder. Die Fehlermeldung, wie im Bild auch zu sehen, lautet: "Speichern nicht möglich. Alias für websocket invalid" Ich vermute es liegt am Punkt. Kann das jemand bestätigen oder mache ich bei der Einbindung was falsch?
Wenn ich WebSocket Reverse Proxying aktiviere ohne was in die Inputfelder zu hinterlegen, dann führt das leider auch nicht zum Erfolg.
Generell wird in allen Szenarien ein HTTP 400 Fehler erzeugt wenn das Dashboard eine Verbindung versucht zum WebSocket aufzumachen.
Zuletzt geändert von ms20de am Mo Aug 19, 2024 12:19 pm, insgesamt 2-mal geändert.
@Chris M., dann hast du vermutlich keine WebSocket Unterstützung und das NodeRed fällt auf ein Polling des Servers zurück. Das ist sehr ineffizient. Du kannst das z.B. in den Developer Tools deines Browser sehen, dass in sehr kurzen Abständen Anfragen an den NodeRed Server gestellt werden. Wenn du das vergleichst mit dem Aufruf des Dashboards ohne Proxy, dann siehst du das nicht. Stattdessen öffnet sich am Anfang eine WebSocket Verbindung, die dann genutzt wird bidirektional Daten zu übertragen.
@gbglace, auch ich nutze MacVLAN, das ist für meine Frage aber m.E. irrelevant.
@gbglace@Eraser , der Vorteil des Reverse Proxies ist, dass NodeRed über HTTPS erreicht werden kann was sonst nicht der Fall ist. Ich binde z.B. TWS Grafana Dashboards in mein NodeRed Dashboard ein. Das führt dann in vielen Browser/Geräte Konstellationen zu Problemen, weil damit HTTP und HTTPS Inhalte vermengt werden.
Stell Dir einen Reverse-Proxy als jemanden vor, der für Dich surft, also alle Deine Klicks, die Du dem Proxy schickst, erkennst, der dann einen Browser bei sich aufmacht und nochmal klickt und das Ergebnis das er erhält, dann als "Screenshot" an Dich zurück schickt.
Ein Reverse Proxy surft für Dich. Er ist Webserver und "Browser" in einem. Dem eigentlich angesprochenen Server, z.B. Node Red erscheint es, als würde der proxy des TWS bei ihm surfen (also von der IP her). Deinem Browser erscheint es so, als würde er nur mit dem Proxy sprechen (von der IP her). Der Proxy übersetzt transparent zwischen beiden hin und her.
Der Vorteil besteht darin, dass der Proxy hierbei eine TLS-Verbindung zur Deinem Browser aufbaut (während die Verbindung des Proxys zum eigentlichen Server unverschlüsselt sein kann) und eine mögliche Impersonation (also Anmeldung, das nutzen wir bei Grafana, da wirst automatisch angemeldet vom Proxy) und dafür, dass damit IPs genutzt werden können, die ansonsten nicht aufrufbar sind.
Wenn nun eine Anwendung im Docker Container mit den üblichen privaten Adressen von Docker laufen, dann gibt es von außen nicht unbedingt ein Routing drauf und Du kommst von außen nicht drauf. Mit dem Proxy ist das kein Problem, weil der Proxy wird über die IP des TWS angesprochen und intern kennt der TWS den Weg zur IP der Docker Adressen.
Alternativ kann man MacVLAN machen, dann kann man der Anwendung im Docker Container eine Adresse aus dem lokalen Netz geben, die dann auch gefunden wird. Aber ist eben ein anderes paar Stiefel als der Proxy. Beides zusammen sollte auch gehen.
Das ist jetzt keine vollständige Abhandlung, weil nicht in allen Fällen geht Proxy (die URLs müssen einen übersetzbaren Aufbau haben) und MacVLAN setzt schon ein gewisses Verständnis von Netzen vorraus.
lg
Stefan
Stefan Werner
Support für Timberwolf Server, 1-Wire und BlitzART Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Wichtige Fragen an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Was ich jetzt noch nicht verstehe ist, welchen Vorteil es hat über eine separate IP (bei MacVLAN) oder/und über einen Proxy auf die Weboberfläche von NR zuzugreifen, wenn man angenommenerweise so wie bei mir ich mit dem PC sowieso im gleichen privaten Netz wie der TW schon bin.
ich möchte wirklich nicht stänkern, auch ich interessiere mich für das Thema, aber die Ausführungen haben eigentlich nichts mit der Fragestellung zu tun und sollten abgetrennt werden.
TWS 2500 ID: 341 + PBM ID: 463, VPN offen, Reboot nur nach Absprache
geh doch bitte mal auf die Seite mit dem Reverse Proxy des Timberwolf Servers und klicke dort auf das blaue i. Da sind die vier Zugriffsverfahren auf Docker Ressourcen erklärt.
Der Text hat mich mal einen Tag gekostet.
Stefan
Stefan Werner
Support für Timberwolf Server, 1-Wire und BlitzART Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Wichtige Fragen an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
