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] Status eines Schalten-Widgets: falsche Darstellung in der Detailanzeige

Hier informieren wir über die Timberwolf Visu (die frühere Arbeitsbezeichnung war "Instant Visu"). Dies ist die im Timberwolf Server ab V4 enthaltene Visualisierung, die sich vor allem dadurch kennzeichnet, dass diese zum einen besonders einfach einzurichten ist und zum anderen durch die hohe Integration deutlich erweiterte Leistungsmerkmale bietet.
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
speckenbuettel
Beiträge: 477
Registriert: Mo Jun 27, 2022 9:30 am
Hat sich bedankt: 364 Mal
Danksagung erhalten: 434 Mal

[V4.0.1] Status eines Schalten-Widgets: falsche Darstellung in der Detailanzeige

#1

Beitrag von speckenbuettel »

Hallo,

ich verwende ein Schalten-Widget, um über die Detailanzeige meine Alarmanlage (ABB Sicherheitsmodul SCM/S1.1) scharf bzw. unscharf zu schalten.

Die Wert-Setzen-Quelle ist verknüpft mit dem Status-KO des Sicherheitsmoduls, das Wert-Setzen-Ziel ist verknüpft mit dem Schaltbefehl.

Wenn ich nun über die Detailanzeige die Anlage scharf schalte und die Scharfschaltung aus irgendeinem Grund nicht funktioniert, dann steht beim nächsten Öffnen der Detailanzeige der Schalter trotzdem auf "Ein":
Bild

Obwohl sich der Status der Anlage nicht geändert hat, das entsprechende KNX-Objekt ist weiterhin false:
Bild

So sehen die Verknüpfungen des Widgets aus:
Bild


Ich würde eigentlich erwarten, dass bei jedem Öffnen der Detailanzeige der Status des Schalters gemäß der Wert-Setzen-Quelle angezeigt wird.

Das ist ja nichts anderes als würde ich z. B. mit dem Widget einen KNX-Aktor bedienen, der geschaltet wird und der ein Statusobjekt zurückgibt.
Wenn der Aktor aus irgendwelchen Gründen nicht schaltet, dann ändert sich auch das Statusobjekt nicht.

Die Anzeige (verknüpft über Wert-Anzeige) wird übrigens korrekt dargestellt, diese wechselt nicht auf scharf.

Ich habe dieses Phänomen gerade mit Widgets auf der Alarmanlagenseite meiner Visu des öfteren gemacht, aber heute habe ich etwas Muße, das Verhalten systematisch nachzustellen und zu dokumentieren.

Hat jemand eine Idee, woran die falsche Darstellung (in der Detailanzeige) liegen könnte?

Vielen Dank und viele Grüße
Falk
Vielen Dank und viele Grüße
Falk

TWS 3500M ID:810 - VPN aktiv - Reboot nach Absprache
1-Wire, KNX (MDT u. a.), EnOcean (Eltako u. a.), Gira TKS, ekey multi

ms20de
Elaborated Networks
Elaborated Networks
Beiträge: 1402
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 434 Mal
Danksagung erhalten: 1045 Mal

#2

Beitrag von ms20de »

Hallo Falk,

wenn ich den Fall richtig verstanden habe, dann würde dir aktuell eine Und Logik weiterhelfen.
Den Eingang der Logik bildet KNX 1713 und KNX 1723, der Ausgang wird alleinig mit dem Eingang von Wert Setzen verbunden.
Nur wenn eingeschaltet wurde und der Aktor eingeschaltet zurückmeldet, dann wird auch der Schalter in der VISU auf den Ein-Zustand gesetzt.

Es ist geplant in der VISU für den Sende-Assistenten eine Konfiguration anzubieten, für den Fall wenn der gesendete Wert nicht den Rückmelde-Werte entspricht. Von einfacher Übernahme des Wertes bis zum Auslösen eines Fehlerzustandes kann dies nach konkreter Einbausituation alles sein.

Viele Grüße,
Matthias
Zuletzt geändert von ms20de am Mo Aug 12, 2024 12:16 pm, insgesamt 2-mal geändert.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
TWS 3500 ID:695 VPN offen, Bitte kein Reboot ohne Absprache

gbglace
Beiträge: 4360
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1539 Mal
Danksagung erhalten: 2706 Mal

#3

Beitrag von gbglace »

Die interne Umschaltfunktion und dessen Wert zu verwenden ist ja OK, so lange keine externe Verbindung besteht. Sowie aber eine externe Verbindung besteht sollte dann auch nur noch das angezeigt werden was da angeliefert wird und nicht mehr die eigene Bedienung.

Sollte warum auch immer (Fehler auf der Signalstrecke oder Logik im Zielgerät), keine Reaktion erfolgen darf sich das eben an der Visu nicht von sich aus Ändern, wenn man auf OFF drückt.

Ein Plausibilitätsabgleich Sende-Wert vs Statuswert ist interessant aber kann auch viel Verwirrung stiften.
Alle Ziele mit Ein-/Ausschaltverzögerungen, Treppenlichtfunktionen oder grundsätzlich weitere Bedienstellen neben diesem Visu-Widget TWS, führen ja zwangsweise zu Abweichungen.

Und alle Verzögerer haben dann eben den Knopf noch auf ON auch wenn OFF gedrückt wurde und die Ausschaltverzögerung im Aktor läuft. Den Status vom Aktor bekommt man dann halt erst nach deren Ablauf geliefert und dann darf das Widget auch auf OFF wechseln.

Die Knöpfe der Visu mit Sendeverzögerungen versehen bin ich unschlüssig. Da man zumindest im Ziel KNX mit sowas keine saubere Trennung mehr hat wo was passiert. Parametrierung Aktor (ein Ausschaltverzögerung) vs eine TWS-Logik oder ETS-Logik mit Verzögerern vs ein Parameter am Visu-Knopf.
Grüße Göran
#1 Timberwolf 2600 Velvet Red
#2 Timberwolf 2600 Organic Silver
Benutzeravatar

Ersteller
speckenbuettel
Beiträge: 477
Registriert: Mo Jun 27, 2022 9:30 am
Hat sich bedankt: 364 Mal
Danksagung erhalten: 434 Mal

#4

Beitrag von speckenbuettel »

Hallo Matthias,

vielen Dank für den Tipp. Die Logik hilft erstmal weiter.

Die Idee mit dem Sende-Assistenten ist gut. In manchen Fällen würde es ebenfalls ausreichen, wenn das Widget für die Anzeige den Wert vom Dispatcher abholen kann. Vermutlich ist das technisch eher aufwendig, aber wenn z. B. nach einer gewissen Zeit nach einem Schaltbefehl kein neuer Zustand kommt, würde eine aktive Abfrage des Quell-Objekts zumindest dafür sorgen, dass der korrekte Zustand angezeigt wird.

Das ist m. E. besser als ein Plausibilitätsabggleich in der Visu. Im Idealfall kann man das Abfragen des Status für jedes Widget aktivieren oder deaktivieren, um dem von Göran angesprochenen Problem aus dem Weg zu gehen. Überall dort, wo irgendeine Art von gewollter Verzögerung eingebaut ist, sei es durch eine Logik, eine Schaltverzögerung im Aktor oder eben eine Treppenlichtfunktion, würde eine automatische Korrektur bzw. Abfrage natürlich zu Verwirrung und teilweise ungeplantem Verhalten führen.

Vielen Dank und viele Grüße
Falk
Vielen Dank und viele Grüße
Falk

TWS 3500M ID:810 - VPN aktiv - Reboot nach Absprache
1-Wire, KNX (MDT u. a.), EnOcean (Eltako u. a.), Gira TKS, ekey multi
Antworten

Zurück zu „Timberwolf Visu“