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)

[Problem] [V4.0.1] Mehrere Geräte am Modbus, "Response not from requested slave"

Wissen, Planung & Diskussion zur Modbus Unterstützung im Timberwolf Server.
Stellt uns hier Eure Modbus Projekte und Ideen vor.
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
Zugschlus
Beiträge: 375
Registriert: Di Okt 02, 2018 4:28 pm
Wohnort: St. Ilgen, Baden-Württemberg
Hat sich bedankt: 136 Mal
Danksagung erhalten: 130 Mal
Kontaktdaten:

[V4.0.1] Mehrere Geräte am Modbus, "Response not from requested slave"

#1

Beitrag von Zugschlus »

Hallo,

auf der RS485 Schnittstelle meines TW 3500 L hängen drei Stromzähler DZG DVH4013. Einer ist von 2015, die beiden anderen sind neu. Als Leitung für den Bus habe ich KNX-Busleitung genommen, sie ist vielleicht 100 cm lang. Die drei Zähler sind hintereinander aufgeschaltet und ca 15 cm auseinander. Die Verdrillung des Adernpaares ist nur für die Klemmstellen aufgemacht worden. Der "alte" Zähler ist dabei NICHT der letzte in der Reihe, der Bus ist am letzten Zähler mit 120 Ohm terminiert. So weit ich weiß ist die RS485-Schnittstelle im TW 3500 L bereits intern terminiert, der Timberwolf hängt am Ende eines Busses und deswegen habe ich dort keinen 120-Ohm-Widerstand eingebaut.

Die ganze Konstruktion habe ich erst letzte Woche gebaut; der "alte" Zähler wurde vorher mit Volkszähler, einem Raspberry Pi und einem RS485-to-USB-Adapter (und einer dreimal so langen, unterminierten RS485-Leitung) ausgelesen. Bei DZG wird der Zähler über die letzten zwei Ziffern der Seriennummer "plus eins" adressiert, wobei das quasi als "decimal coded hex" zu sehen ist. Meine Zähler enden auf 46, 47 und 48, was über 0x47, 0x48 und 0x49 schließlich in 71, 72 und 73 mündet. Welch Glück dass da keine Kollisionen sind (Geburtstagsparadoxon, anyone?).

Die beiden "neuen" Zähler kooperieren mit dem Timberwolf problemlos. Bei dem "alten" Zähler hagelt es im Busmonitor CRC-Fehler und "Response not from requested slave". Eine erfolgreiche Auslesung ist auch mal dabei, aber bei weitem nicht oft genug als dass die Werte brauchbar wären. Bevor ich nun den "alten" Zähler als "defekt" in die Tonne trete, hätte ich mir das gerne etwas genauer angeschaut. Es kann natürlich sein, dass der Hersteller in den neun Jahren zwischen meinen beiden Zähler-Generationen die Hard- oder Software seines Produkts geändert hat und dass die neueren Zähler einfach unproblematischer arbeiten.

Habt Ihr irgend eine Idee, was ich noch ausprobieren könnte? Morgen früh werde ich mal die beiden "neuen" Zähler vom Bus nehmen und schauen ob der "alte" dann besser funktioniert. Vielleicht stören die sich ja doch irgendwie gegenseitig.

Zwei Verständnisfragen:
  • "CRC error" im Busmoniitor bedeutet, dass der Modbus-Server antwortet, aber der Timberwolf-Server die Antwort wegen der falschen Prüfsumme verwirft? Hier wäre es hilfreich, den falschen Modbus-Frame trotzdem sehen zu können.
  • "Response not from requested slave" im Busmonitor bedeutet, dass der Timberwolf-Server auf seine Anfrage eine Antwort erhalten hat, die Prüfsumme korrekt ist, aber die Antwort eine falsche Absenderadresse enthält? Auch hier würde ich mich dafür interessieren, was der Modbus-Server konkret geantwortet hat.
Grüße
Marc
--
Marc Haber, St. Ilgen. Freier IT-Berater, Debian Developer. Kann nicht mit Webforen.
TWS 3500L ohne Insider, VPN auf Anfrage - KNX, 1Wire (13/55/54 Slaves), MQTT, Cometvisu, viel Grafana, ganz ein bisschen Logik. unfertige Anwendungsfälle für Modbus.

Sun1453
Beiträge: 2504
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 2263 Mal
Danksagung erhalten: 1276 Mal

#2

Beitrag von Sun1453 »

Hallo Marc,

also ich denke von der Einbindung werden die neuen Zähler besser sein wie du selbst ja schreibst. Ich kann mich nur an die Texte und Videos von Stefan erinnern wo er sagte was für einen Wildwuchs es teilweise bei Modbus gibt und wie schwer das war da vieles schon abzufangen. Ich denke mal deine zwei Annahmen zu den Fehlern würde ich auch so interprettieren.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Benutzeravatar

Ersteller
Zugschlus
Beiträge: 375
Registriert: Di Okt 02, 2018 4:28 pm
Wohnort: St. Ilgen, Baden-Württemberg
Hat sich bedankt: 136 Mal
Danksagung erhalten: 130 Mal
Kontaktdaten:

#3

Beitrag von Zugschlus »

Also, ich habe noch ein kurzes Update: Die Abfragen des alten Zählers werden im Modbus-Gerätemanager rot sobald ein zweiter Zähler mit auf dem Bus ist. Dabei ist es egal, ob der alte oder der neue Zähler "vorne" im Bus sind. Ich werde mal beim Hersteller nachfragen ob das ein bekanntes Issue ist und ob es sich beheben lässt.
--
Marc Haber, St. Ilgen. Freier IT-Berater, Debian Developer. Kann nicht mit Webforen.
TWS 3500L ohne Insider, VPN auf Anfrage - KNX, 1Wire (13/55/54 Slaves), MQTT, Cometvisu, viel Grafana, ganz ein bisschen Logik. unfertige Anwendungsfälle für Modbus.

StefanW
Elaborated Networks
Elaborated Networks
Beiträge: 11404
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 5521 Mal
Danksagung erhalten: 10996 Mal
Kontaktdaten:

#4

Beitrag von StefanW »

Hi Marc,

ich lese mit, aber da wir diesen Fall noch nicht hatten, habe ich keine guten Ideen.

Entwickler ist auch gerade im Urlaub, daher können wir jetzt gerade nicht drauf sehen, in ein paar Wochen würden wir uns das aber gerne ansehen wollen. Und dann können wir auch prüfen, ob wir die Fehlermeldungen verbessern können. Da es so einen Fall in den letzten Jahren nicht gab (zumindest nicht nach meiner Kenntnis) hatten wir hier auch nicht mehr Liebe in die Fehlermeldungen gesteckt.

Bitte weiter berichten.

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

Ersteller
Zugschlus
Beiträge: 375
Registriert: Di Okt 02, 2018 4:28 pm
Wohnort: St. Ilgen, Baden-Württemberg
Hat sich bedankt: 136 Mal
Danksagung erhalten: 130 Mal
Kontaktdaten:

#5

Beitrag von Zugschlus »

StefanW hat geschrieben: ↑Mi Sep 18, 2024 10:17 am Bitte weiter berichten.
Aye, wird gemacht.

Der Hersteller hat mich schon vor neun Jahren gut beraten, als ich den ersten Zähler gekauft habe. Da haben sich meine Probleme dann tatsächlich zu "Zähler kaputt" zusammenfassen lassen, nach Austausch ging es dann. Ich habe in meiner Anfrage beim Hersteller auch gezielt nach vielleicht inzwischen erfolgten Hardwareänderungen an dem Produkt gefragt und ob es Firmwareänderungen bezüglich Modbus gab. Ich gehe davon aus, dass sie mir bestenfalls ein Firmwareupdate des Zählers anbieten werden. Das wird also Wochen dauern. Ich bleibe da aber dran.

Grüße
Marc
--
Marc Haber, St. Ilgen. Freier IT-Berater, Debian Developer. Kann nicht mit Webforen.
TWS 3500L ohne Insider, VPN auf Anfrage - KNX, 1Wire (13/55/54 Slaves), MQTT, Cometvisu, viel Grafana, ganz ein bisschen Logik. unfertige Anwendungsfälle für Modbus.
Antworten

Zurück zu „Modbus“