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)

[Frage] [1.6.0 RC8] Nutzung und Umgang mit physikalischen Adressen

Diskussionen über die KNX-Funktionen im Timberwolf Server
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

Ersteller
blaubaerli
Beiträge: 2785
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 1080 Mal
Danksagung erhalten: 1056 Mal

[1.6.0 RC8] Nutzung und Umgang mit physikalischen Adressen

#1

Beitrag von blaubaerli »

Hallo zusammen,

wir hatten ja gerade erst diesen Thread von Tom. Da ging es zwar auch um die PAs, aber nachdem ich im Test mit der 0.12.0-dev der CometVisu unterwegs bin, habe ich da aktuell in den mir zur Verfügung stehenden Diagnosetools wieder Effekte, die ich mir nicht zu erklären weiß.

Wie hatte Tom so schön geschrieben:
tofele hat geschrieben: ↑Sa Dez 26, 2020 4:34 pm Ich brauche etwas Schwarmintelligenz, ich steh auf dem Schlauch, trotz vielem Lesen hier im Forum heute.
Mal zur Konfig bei mir:
  • TSW2600 mit der Basis-PA 1.1.222 und den Zusatz-PAs beginnend bei 1.1.4 dann durchgängängig bis hoch zu 1.1.28
  • Folgende Container laufen aktuell auf dem Wolf
    31-12-_2020_12-46-26.jpg
    Wobei aktuell nur die drei Markierten jeweils einen der Tunnel des Wolfs belegen
  • Das führt aktuell bei mir auf der Schnittstellen-Seite "KNX Schnittstellen & Tunnel Verwaltung" zu folgender Zuordnung:
    31-12-_2020_13-10-24.jpg
  • Im Wiregate-Plugin-Container (markiert mit 1) läuft nun "/usr/bin/eibd -u -i ipt:172.17.0.1:3700 -d/var/log/eibd.log -e 0.0.0", wobei der eibd die Version "0.0.5" hat.
  • Im über die APP aktivierten Container der produktiven Visu 0.11.2 (markiert mit 2) läuft "knxd -i iptn:172.17.0.1:3700 -e 0.0.0 -u -d/var/log/eibd.log -c", wobei der knxd die Version "0.1.0" hat.
  • Und zu guter letzt der " CometVisuTest"-Container mit dem "0.12.0-dev"-Image. Dort läuft der "knxd -i iptn:172.17.0.1:3700 -e 1.1.238 -u -d/dev/stdout -c". Der knxd hat hier ebenfalls die Version "0.1.0"
Jetzt meinte ich mal verstanden zu haben, dass sowohl der eibd, als auch der knxd bei Nutzung des Parameters "-e 0.0.0" so etwas wie eine "automatische Zuordnung" einer freien PA aus dem Haushalt der dem Wolf zugeordneten "Zusatz-PAs" vornehmen würde.

Nun hatte ich die CometVisu 0.12.0-dev mal streng nach Anleitung installiert. Das führt defaultmäßig dazu, dass eine ENV-Variable "KNX_PA" mit dem Inhalt "1.1.238" vergeben wird. Das pass gundsätzlich zum meinem Linienaufbau und die PA ist auch frei. Damit taucht die im Aufruf des knxd dann auch als "-e 1.1.238" auf.

Wenn ich jetzt aber über die Oberfläche der "0.12.0-dev"-CV einen Schaltbefehl auf einen meiner Aktoren sende, sehe ich sowohl im Busmonitor des Wolfes, als auch in der Diagnose der ETS als Quell-PA des Telegramms die "1.1.5". Das ist jetzt aber etwas, was ich überhaupt nicht erwartet hätte. Die 1.1.5 ist schließlich die Zusatz-PA, die laut Interface-Seite dem Container mit der IP 172.17.0.6 zugeordnet wurde. In dem Teil läuft aber doch die CV 0.11.2. Aus der habe ich den Schaltimpuls aber nicht gegeben. Das Verhalten ändert sich übrigens nicht, wenn ich in der ENV-Variablen die "0.0.0" eintrage. Auch den Cache habe ich in meinem Firefox schon gelöscht.

Wenn ich aus dem Wiregate-Container etwas sende, dann taucht das im Monitor mit dem Ursprung "1.1.4" auf. Da ist meine Welt ja noch irgendwie in Ordnung...

Aber das Bild oben verwirrt mich aktuell doch massiv. :confusion-scratchheadyellow:

Mal völlig losgelöst von dem gestrigen Test einer CV-Version die im Unterbau einen knxd in der Version 0.14 nutzt. Da scheint sich was in der API beim Umgang mit den Tunneln und den Adressen geändert zu haben. Da steht im Wiki zum knxd in der "adress-section" so schön "Starting with version 0.11, this address is not used for tunnelling clients, see [multicast-server-section].". Da war dann gestern im Container am knxd neben dem gesetzten "-e" auch der "-E" zu sehen. Wobei der "-E" sich wiederum laut Doku auf Client-Adressen bezieht. Was ist denn da dann wieder zu berücksichtigen? Ich blicks langsam echt nicht mehr.... :angry-banghead: :confusion-scratchheadyellow:

Aber wie immer, die Hoffnung stirbt ja bekanntlich zuletzt.

Ich wünsche euch allen aber mal schon einen guten Rutsch! Auf das 2021 schönere Überraschungen für uns parat hat als 2020! :handgestures-thumbupright:

Beste Grüße
Jens
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
timberwolf168(2600er)VPN offenReboot nach Vereinbarung
timberwolf1699(3500XL)VPN offenReboot jederzeit
wiregate1250
Bitte WIKI lesen.
Benutzeravatar

Chris M.
Beiträge: 1242
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 258 Mal
Danksagung erhalten: 1060 Mal
Kontaktdaten:

#2

Beitrag von Chris M. »

Der knxd 0.1.0 ist im Wesentlichen der eibd 0.0.5.1. Hier gilt noch das alte verhalten, dass alle Bus-Kommunikation darüber mit der PA des eibd/knxd passieren.

Ob am Bus nun die -e Addresse auftaucht oder nicht müsste damit zusammen hängen wie der knxd an den Bus angeschlossen ist (TP, Tunnel, Router)
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

Ersteller
blaubaerli
Beiträge: 2785
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 1080 Mal
Danksagung erhalten: 1056 Mal

#3

Beitrag von blaubaerli »

Hallo Chris,

die Methode ist aber ja mit dem „iptn“ offensichtlich in allen drei Instanzen identisch gewählt. Wenn da ja was unterschiedlich wäre, dann könnte das ja sein. Wenn aber nach deiner Aussage die hier genutzte Version des knxd und dem eibd im Verhalten und von der API eigentlich identisch sind, dann blick ich das nicht.

Beste Grüße
Jens
Zuletzt geändert von blaubaerli am Do Dez 31, 2020 9:23 pm, insgesamt 1-mal geändert.
timberwolf168(2600er)VPN offenReboot nach Vereinbarung
timberwolf1699(3500XL)VPN offenReboot jederzeit
wiregate1250
Bitte WIKI lesen.

Ersteller
blaubaerli
Beiträge: 2785
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 1080 Mal
Danksagung erhalten: 1056 Mal

#4

Beitrag von blaubaerli »

Hallo zusammen,

ist das wieder ne peinliche Nummer....... :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead:

Das war beim Konfigurieren eindeutig wieder ein: :text-blondmoment:

Wenn man in der ENV-Variablen "CGI_URL_PATH" für die Testinstanz auch "/proxy/visu/cgi-bin/" statt "/proxy/visutest/cgi-bin/" einträgt, darf man sich in der Tat nicht wundern.

Dann auch noch behaupten, dass man das streng nach Anleitung gemacht hat... :liar: :think: :crying-yellow:

Also Asche auf mein Haupt, damit ist nun erklärt, wieso die mir nicht schlüssig erscheinende PA genutzt wurde. Wenn man das nicht richtig macht, kann da auch mal was falsches rauskommen......

Was das wieder für ne Zeit gekostet hat....

Beste Grüße
Jens
timberwolf168(2600er)VPN offenReboot nach Vereinbarung
timberwolf1699(3500XL)VPN offenReboot jederzeit
wiregate1250
Bitte WIKI lesen.

Robert_Mini
Beiträge: 3936
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1312 Mal
Danksagung erhalten: 2519 Mal

#5

Beitrag von Robert_Mini »

Ging mir gestern auch so.
Wollte schnell mal eine Lampe in OpenHAB + Alexa auf dimmbar umstellen.
Hat mich fast 1h gekostet und zwischenzeitlich ging gar nichts mehr per Alexa zu schalten...

Am Ende war es ein " zuviel bei den GA-Definitionen :angry-banghead: :angry-banghead: :angry-banghead:

Über die proxy bin ich auch schon mal gestolpert. Hab mich gewundert, warum die CV nuf geht, wenn beide Container laufen, weil im proxy der andere eingetragen war.

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

Ersteller
blaubaerli
Beiträge: 2785
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 1080 Mal
Danksagung erhalten: 1056 Mal

#6

Beitrag von blaubaerli »

Hi Robert,

das gehört glaube ich zum Thema Lernkurven. Der Chris hätte verdammt noch mal in der CV Anleitung die Stelle mit der Doku für die Testinstanz aber gefälligst auch was auffälliger markieren können.... :laughing-rolling:

Beste Grüße
Jens
Zuletzt geändert von blaubaerli am Sa Jan 02, 2021 3:37 pm, insgesamt 1-mal geändert.
timberwolf168(2600er)VPN offenReboot nach Vereinbarung
timberwolf1699(3500XL)VPN offenReboot jederzeit
wiregate1250
Bitte WIKI lesen.
Antworten

Zurück zu „KNX“