Timberwolf 3500 - eine Loxone-Erweiterung oder gar Alternative?

**eisenkarl** · 02.01.2022, 12:26

Auch ich habe den Timberwolf schon lange auf der "Beobachtungsliste". Prinzipiell brauche ich diesen aktuell nicht wirklich, will ihn aber gerne haben :-) Ich bilde mir gerne meine eigene Meinung und das am besten in dem ich mache! Allerdings ist mir das Gerät zum "probieren" zu teuer. Damit will ich nicht sagen, dass der Timberwolf sein Geld nicht wert ist, im Gegenteil...
Wenn der eine oder andere "richtige" User hier aus dem Forum sich so ein Gerät anschaffen würde, hätte das einen riesigen Vorteil für alle im Forum ;-)

**Gast** · 02.01.2022, 12:48

Hallo Klartext,

Zitat von Klartext

Paar Worte zum timberwulf:- haben schon mal Insolvenz angemeldet und es läuft finanziell anscheinend nicht so gut

Danke. Es geht uns hervorragend, sonst würde es uns auch nicht mehr geben.

Wir waren ein Unternehmen mit zwei Geschäftsbereichen und im anderen Geschäftsbereich haben wir unsere zwei größten Kunden verloren (ich kann jetzt nicht auf Details eingehen, aber das ist was unschönes gelaufen). Damit war in 2018 eine finanzielle Schieflage absehbar und es war absehbar, dass wir uns sanieren mussten.

Der effektivste Weg dafür ist ein "Sanierungsverfahren in Eigenverwaltung", das wir im Oktober 2018 beantragt haben. Nach zwei positiven Gutachten zur Fortführungsprognose des zweiten Unternehmensteils "Smarthome" sind wir am 1. Januar 2019 in das Hauptverfahren eingetreten. Das ist ein Eigenverwaltungsverfahren (es gab also keinen Insolvenzverwalter) und man steht unter gerichtliche Aufsicht, das man das auch alles ordentlich ausführt. In September hatten wir uns dann mit allen Beteiligten geeinigt (100 Prozent Zustimmung) und gingen erfolgreich saniert daraus hervor.

Diese Art Verfahren gibt es erst seit sieben Jahren und sind damit für die meisten neu. Leider ist dieses Verfahren in das Insolvenzrecht eingebettet, so dass immer mit dem Finger auf uns gezeigt wird. Ehrlich gesagt, kannte ich das vorher auch nicht, wir hatten aber einen guten Berater, als wir 2018 nach einer Lösung gesucht hatten. Dieses Verfahren ist dafür gedacht, dass Unternehmen die nötige Zeit für eine Sanierung eingeräumt wird. Weil durch so ein Verfahren erhält man ein paar rechtliche Vorteile, so dass man langjährige Verträge leichter beenden kann (in unserem Fall war das eine größere Flotte an Firmenwagen und der Mietvertrag für ein nun viel zu groß gewordenes Betriebsgebäude).

Wir waren während des Verfahrens (und auch danach) durchgehend zahlungsfähig (sonst kann man auch nicht fortführen). Im übrigen muss man zudem nur einen sechsstelligen Betrag für die Kosten des Verfahrens selbst aufbringen. Es geht in solchen Verfahren letztlich darum, die Sanierung rechtlich beschleunigen zu können.

Der Smarthome Bereich lief währenddessen praktisch ungestört weiter.

Falls das jetzt nicht rübergekommen ist, finanzielle Schwierigkeiten hat man als Unternehmen VOR solchen Verfahren, nicht danach.

Zitat von Klartext

- Das mit dem Wartungsvertrag für Updates ist für eine Softwarefirma warscheinlich gar nicht so schlecht

Anfangs war das verpflichtend, das hat aber manchen Interessenten nicht gefallen, darum gibt es das im Moment gar nicht und wird künftig optional angeboten, für denjenigen, der das möchte.

Zitat von Klartext

- die ganze Firma scheint auf den Schultern einer Person zu stehen, was ist wenn der mal nicht mehr kann?

Nein, das ist nicht so. Die Firma steht technologisch auf mehr als einem Dutzend Schultern.

Falls Du mich mit der einen Person gemeint hast, ich bin nur das hauptamtliche Sprachrohr und trage meinen Teil zu den Entscheidungen bei.

Wir sind ein nach ISO 9001 zertifiziertes Unternehmen (wird jährlich durch den TÜV Süd überprüft) und Bestandteil dieser Zertifizierung ist auch eine Regelung von Nachfolge und Sicherstellung der Betriebsabläufe bei Ausfall einzelner Personen.

Zitat von Klartext

generell ist es aufwendiger logiken zu erstellen, von der Visu ganz zu schweigen

Ich würde sagen, das kommt immer darauf an, was genau ausgeführt werden muss. Bei der Anbindung von vielen fremden Geräten haben wir mit dem Timberwolf Server sicher die Nase vorn, weil dafür wurde er gemacht, auch mit tausenden Datenpunkten umzugehen, zu loggen, grafisch in Dashboards zu visualisieren und dies alles Live einzustellen. Bei der Visu dürfte der Loxone Server sicherlich sehr gut sein, hier haben wir noch Arbeit vor uns. Es kommt eben immer ein wenig darauf an, was man benötigt.

Wir sehen den Timberwolf Server auch nicht unbedingt als Ersatz, sondern als Ergänzung für eine Loxone Installationen um damit eine Lösung für diejenigen Dinge anzubieten, in denen unser Gerät eine Stärke hat.

Bitte teilt mir einfach Eure Wünsche mit, was Euch fehlt und ihr gerne besser hättet.

lg

Stefan Werner

**olicat** · 02.01.2022, 12:52

Hi!

Ich weiss ja nicht, ob ich ein "richtiger" User für Dich bin. Aber ich habe den 3500er bestellt und werde berichten.

Oliver

**Gast** · 02.01.2022, 12:55

Hallo Eisenkarl,

Zitat von eisenkarl

Auch ich habe den Timberwolf schon lange auf der "Beobachtungsliste". Prinzipiell brauche ich diesen aktuell nicht wirklich, will ihn aber gerne haben :-) Ich bilde mir gerne meine eigene Meinung und das am besten in dem ich mache! Allerdings ist mir das Gerät zum "probieren" zu teuer.

Du hast die neuen Modelle und die neuen Preise schon gesehen?

Zitat von eisenkarl

Wenn der eine oder andere "richtige" User hier aus dem Forum sich so ein Gerät anschaffen würde, hätte das einen riesigen Vorteil für alle im Forum ;-)

Wenn jemand echtes Interesse an einem umfangreichen Test hat und sich die Zeit dafür nehmen will, dann können wir auch einen längeren Rückgabezeitraum vereinbaren. Würden drei Monate ausreichen?

lg

Stefan

**Miep Miep** · 02.01.2022, 15:53

DALI wird bei den Protokollen nicht erwähnt ? Wie sieht die Prognose aus ?

Wie sähe Kopplung mit Miniserver aus ? Vor allem wenn viele Werte rüber oder nüber müssten ?

**Gast** · 02.01.2022, 17:40

Hallo Miep.

Zitat von Miep Miep

DALI wird bei den Protokollen nicht erwähnt ? Wie sieht die Prognose aus ?

Nun, in welchem Umfang. Bisher kenne ich keine DALI Implementierung, die nicht lückenhaft wäre.

1. Nur DALI-Kommandos schreiben, das wäre sicherlich in kurzer Zeit realisierbar

2. Status der DALI-Komponenten lesen, ist etwas aufwändiger, weil DALI unterstützt nur 6 Befehle pro Sekunde und da die Schreibbefehle Vorrang haben, muss man "einmal alle Devices abpollen" da geschickt einbauen, wäre aber vermutlich auch keine große Sache, wir haben im Pollen bei 1-Wire, Modbus (da schaffen wir unter 10 ms) HTTP-/REST-API große Erfahrungen gesammelt.

3. DT8 sollte kein Thema sein, wir arbeiten ohnehin an den ganzen Farbsteuerungen und Umrechnungen wg. DMX, HUE usw.

4. Interessant wird es mit Multi-Master-Betrieb, besonders in Verbindung mit Rückmeldungen. Weil da müsste man (wenn man die Rückmeldung schnell haben will) den Status einzelner Lampen simulieren (Statusmodell) und die Befehle anderer Master darauf einwirken lassen. Hierzu müsste man das Verhalten eines jeden EVG simulieren, zumindest wenn es schnell sein muss. Wenn Rückmeldungen dagegen 5 bis 10 Sekunden Zeit haben, würde das zyklische abpollen aller EVGs auch reichen (mir würde das nicht gefallen).

5. Auswertung von Notbeleuchtungseigenschaften, Brennzeiten, Leuchtmittelausfallmeldungen usw. würde manchen auch gefallen

6. Setup der EVGs ist dann auch noch ein Thema. Weil die IDs werden beim ersten Einschalten automatisch gewürfelt und sind nie so, wie man die gerne hätte. Also wäre es schon ein starkes zusätzliches Feature, wenn man diese Einstellungen dann auch mit dem Server vornehmen kann, mit allen Dimmzeiten und den vielen anderen Parametern, welche die EVGs so bieten.

7. Offizielle DALI Zertifizierung, das ist dann nochmal ein anstrengender Punkt.

Für uns steht das Thema Lichtsteuerung recht weit oben, da haben wir uns für dieses Jahr viel vorgenommen. Wir stehen auch in Gesprächen mit einem großen Unternehmen der Branche, das uns hier womöglich sponsern wird, weil das kann umfangreich werden.

Wegen der Prognose: Ein "bisschen DALI" wäre schnell realisierbar, aber solche unzureichenden Implementierungen gibt es schon genug, da wäre niemandem geholfen. Ich denke, DALI2 und Multi-Master-Unterstützung muss schon sein. Beliebig viele Universen parallel ohnehin. Das kann ich jetzt nicht verbindlich abschätzen.

Es wäre aber sehr hilfreich zu erfahren, was Eure Wünsche im Detail zum Thema Lichtsteuerung sind und was Euch fehlt.

Zitat von Miep Miep

Wie sähe Kopplung mit Miniserver aus ? Vor allem wenn viele Werte rüber oder nüber müssten ?

Wir haben UDP als Kopplung zur Loxone angedacht, weil hier beide Seiten jeweils schreiben können, wenn es eine Veränderung gibt und weil die Loxone eine entsprechende Schnittstelle anbietet. Wir haben dazu auch bereits Versuche im Labor unternommen und das sah soweit gut aus. Dauerbetrieb kann ich nichts sagen.

Viele Werte sind für uns kein Problem. Unser Objekt-Verteiler schafft etwa 20.000 bis 40.000 Objekte pro Sekunde. Wir verwalten die Eigenschaften und Konfigurationen intern in einer MariaDB, die bringt auch nichts zum platzen. Wir unterstützen beim KNX bis 8.000 Objekte mit 65.535 Gruppenadressen an dem einen TP-Anschluss und wir haben Modbus Profile von Geräten mit knapp 2000 Registern. Der Timberwolf Server ist an jeder Stelle auf Performance getrimmt und es gibt (fast) keine vorgegebenen Limitationen.

Gegenfrage bitte: Damit ich ein Gefühl bekomme, wieviele Werte müssten denn zwischen dem Miniserver und dem Timberwolf Server ausgetauscht werden?

lg

Stefan Werner

**AlexAn** · 02.01.2022, 18:11

Was uns hier im Forum extrem stört ist dass uns Loxone für die KNX Extension 600Euro abknöpft

25 Tunnel für das KNX IP Gateway ist auch mal eine Ansage!

Wäre es denkbar auf einfachen Weg KNX auf MQTT umzuleiten?
Vor Jahren hab ich sowas in NodeRed umgesetzt - NodeRed geht dann ja in kürze

KNX per UDP an den MS Go - loxforum.com

Dann noch Loxberry per Timberwolf Docker ....

**Gast** · 02.01.2022, 18:13

Hallo MIep,

gibt es für Kommentare auch einen "Zitieren"-Button, weil ich habe es jetzt einfach mal rauskopiert,

mich interessiert primär wie aufwändig es ist in der Konfiguration, muß ich mir für jedes Element manuell einen abkonfigurieren ?

Nun, unsere Idee ist folgendermaßen.

Die Loxone Config hat bei UDP die Möglichkeit, dass man das, was man dort an virtuellen Ein- und Ausgängen bei UDP einrichtet (bitte korrigiert mich, wenn ich was falsches sage, bin kein Loxone Spezialist) exportieren kann.

Wir würden dann ermöglichen, dass man auf der Timberwolf Seite dieses Loxone-Konfig-File importieren kann und damit der entsprechende Gegenpart verfügbar ist. Dann verknüpft man diese mit den anderen Objekten des Timberwolf Servers (was sehr einfach geht) und fertig.

Um Dir ein Beispiel zu geben. Wir haben ein Video gemacht, wie ein Modbus Zähler einzubinden ist, bei dem das Modbus Profil schon bekannt ist. Hier wird nach Anlegen des Gerätes (Profil auswählen, Name vergeben, Adresse angegeben) nur noch ausgewählt, welche Register angesprochen werden sollen, anschließend werden diese (im Beispiel mit KNX) verknüpft.

So in etwa kannst Du Dir das dann mit der Loxone Verbindung vorstellen, Man legt die Loxone an (dürften ja beliebig viele Miniserver sein), ließt das Config-File der Loxone ein und klickt anschließend die Verknüpfungen dazu.

Hier das Modbus Video ab der entsprechenden Stelle: https://youtu.be/7Fix-79WzIk?t=262

lg

Stefan Werner

**olicat** · 02.01.2022, 18:20

Hi!

MQTT würde aber tatsächlich den LoxBerry benötigen. Eine native UDP-Unterstützung würde ich da bevorzugen.
Zumal ich da dann auch gleich eine Importdatei für die virtuellen Ein- und Ausgänge machen könnte.
FOSHKplugin macht das ja auch so.
Objekte (KNX oder MQTT oder 1-Wire) im TW anlegen/verbinden. Knopfdruck und eine Importdatei für Loxone mit allen VIs wird erzeugt.
Im Miniserver einlesen und schon sind alle VIs da.
So stelle ich mir das im Groben vor.

Sorry Stefan, da haben sich unsere Beitraege ueberschnitten.

Oliver

**Christian Fenzl** · 02.01.2022, 18:55

Miep Miep Dass das Konfigurieren externer Schnittstellen in Loxone so kompliziert ist, liegt an Loxone und nicht an den externen Systemen. Da kann der Timberwolf oder LoxBerry oder (beliebiges System einfügen) nichts dafür.

Mit den Loxone UDP Templates, das sehe ich zwiegespalten. Das funktioniert einmal. Es gibt aber keinen „Merge“ in Loxone. Heißt, ändert sich was im Template, muss man das komplett neu importieren, und alles sind neue Objekte in Loxone, wo ich erst alles von den vorherigen Inputs in der Logik umhängen muss.
Außerdem muss bei UDP jede Übertragung durch die Textsuche aller Eingangsbefehle dieses Ports.
Wenn es also 100 Werte gibt, die an dem Port übertragen werden, und ein Wert kommt per UDP herein, laufen am Miniserver 100 regex-artige Suchen.

Wenn Timberwolf als KNX Interface genutzt wird, kann man sicher mit 200-300 unterschiedlichen Sensoren rechnen, wo die Befehlserkennung definitiv heftig ausgelastet sein wird.
Deswegen empfehle ich beim MQTT Gateway die HTTP-Übertragung.

Lg, Christian

**AlexAn** · 02.01.2022, 19:09

KNX Datentyp in Timberwolf einstellen - MQTT - virtuellen Eingang in der Loxone anlegen
Wer den Broker macht wird dann vermutlich egal sein.

Cool wäre auch ein Template-Creator ähnlich wie im MS4H auf http Basis wie Christian schreibt: TemplateCreator (music-server.net)

Doku zur Kommunikation: 1202_Communicating with the Miniserver (loxone.com)

**Squarry** · 14.01.2022, 13:39

Ich beschäftige mich auch schon seit gut 5 Jahren mit Wiregate und hatte dann dem Timberwolf entgegengefiebert. Ich würde noch so gern Loxone endlich rausschmeissen. Gewisse Kommentare/Fragen der User und die Antworten von Stefan sind für mich ein richtiges deja-vu (dazu nachher noch mehr). Ich hatte damals eine grundsätzlich interessante Kommunikation mit Stefan angefangen, die dann allerdings von seiner Seite plötzlich abgebrochen wurde (nachdem ich zahlreiche Ideen und Gedanken übermittelt hatte). Ich glaube er fand mich einfach doof oder nervig (bin eben Endkonsument und kein Techniker). Gut, kann sein, habe ich auch kein grundsätzliches Problem damit (ich fand es bloss schade, da ich es gut meinte). Schon damals hatte ich aber den klaren Eindruck, dass der Timberwolf ein Produkt von Technikern für Techniker ist. Und mit Endkonsumenten weiss man nicht wirklich umzugehen...

Ich habe noch heute exakt das gleiche "Problem" mit dem Timberwolf wie damals, nämlich dass ich nicht begreife, was ich mit dem Ding tatsächlich machen kann und wie. Ja, er kann offenbar alles und ist super schnell. Aber was ICH damit KONKRET machen kann - insbes. als Loxone-Alternative - und was das für mich bedeutet, habe ich noch immer nicht kapiert. Und schon damals hiess es von Stefan, dass man wisse, dass man in diesem Bereich (das Produkt verständlich präsentieren) Schwächen habe und dass man daran arbeite. Schon damals wurde mir dann vorgerechnet wie viel Mannstunden Entwicklung man geleistet habe und man deshalb keine Kapazitäten für Dokumentation/Erklärung habe. Ja, ist nett, kann ich aber nix damit anfangen und interessiert mich letztlich auch nicht. Ich sehe da ehrlich gesagt null Verbesserungen und nur wieder die gleichen Aussagen. Sorry, aber das ist meine klare Wahrnehmung. Es ist ja schön (schon wieder) zu lesen, dass man irgendwelche Datenpunkte direkt verknüpfen kann. Aber hey: meine Frau will wissen, ob sie mit einem schönen Knopf das Licht einschalten kann. Mein Haus besteht nicht aus 1'000 Temperatursensoren, die ich untereinander verknüpfen muss und aus denen ich mittels Grafana schöne Charts zeichnen will (erster Titel zum Thema "Visualisierung" lautet beim Timberwolf so: "InfluxDB für Logging von Milliarden Datensätze"). Ich will schlaue Logiken bauen um meiner Familie das Leben zu erleichtern (aus dem Leben: Kind öffnet das linke Fenster seines Zimmers (ohne Fliegengittter davor), Jalousie fährt sofort zu, Taster schlägt mit voller Lautstärke akustisch Alarm und die Zimmerlampe blinkt zusätzlich um das Kind abzulenken. So habe ich einen simplen "Rausfallschutz" realisiert. Kann ich sowas einfach auch realisieren?). Milliarden von Datensätzen brauche ich nicht und was ist überhaupt eine InfluxDB?? Jawohl, das überzeugt mich, dass ich das Teil haben muss... und so geht es munter weiter.

Wenn ich dann davon lese, dass ich mittels Docker ja jede Visu installieren kann usw., dann wird mir schon wieder schlecht. Ich will nicht Alles irgendwie können, sondern ich will etwas Gutes, das einfach funktioniert. Und da glaube ich, dass der Timberwolf grandios scheitert. Er erstickt den User mit endlosen Möglichkeiten da er es nicht schafft, daraus etwas(!) simples und massentaugliches anzubieten. Apple und Loxone haben ja etwas gemeinsam und das machen sie extrem gut: sie bieten einfache Lösungen an. Klar kann ich bei Linux jeden Furz einstellen und bei macOS nicht. Das macht Linux aber aus Endkonsumentensicht nicht zum besseren Betriebssystem. Usability ist das Stichwort.

Schade um den Timberwolf, denn ich denke das Produkt ist technisch extrem gut. Nur leider interessiert sich der Endkonsument meist nicht dafür, wie viele Datenpunkte das Ding parallel verarbeiten kann, sondern bloss, ob es ihm mit möglichst wenig Aufwand einen grossen Nutzen stiftet. Ich hatte schon vor Jahren mal gefragt, für welche Zielgruppe der Timberwolf denn eigentlich sei (da ich irgendwann zum Schluss kam, dass es ICH offenbar nicht sei). Diese Frage wurde mir nie zufriedenstellend beantwortet. Es ist jedenfalls klar nicht der Endkonsument und sonst macht Stefan die gleichen Fehler einfach immer und immer wieder. Ja, Stefan wird nun (wieder) antworten, dass man sehr erfolgreich sei mit dem Timberwolf und dass man alle Kapazitäten in die Technik stecke anstatt in Marketing. Kann sein, kann ich nicht beurteilen und ist zudem eine Frage des Massstabs. Von Massenmarkt ist man - im Gegensatz zu Loxone - aber garantiert meilenweit entfernt.

Um es kurz zu sagen: der Timberwolf weckt durch seine technischen Fähigkeiten enorme Begehrlichkeiten. Leider bleibt es dann dabei, da man eigentlich nicht weiss, was man dann damit anfangen soll. An konkreten Normalo-Projekten ("Häuslebauer Hans mit seinem Timberwolf") mangelt es massiv, was für mich aber auch nicht wirklich verwunderlich ist. Es wäre schön, wenn sich mal ein Normalo an den Timberwolf wagen würde um zu berichten. Keine Leute, die MQTT, Grafana, Docker und Co. wunderbar kennen und gerne experimentieren.

**Gast** · 16.01.2022, 13:53

Hallo zusammen,

danke für Eure Beiträge und Fragen. Ich gehe auch gerne noch darauf ein, ist aber zeitlich gerade schwierig.

lg

Stefan

**Maulwurf 82** · 07.02.2022, 12:18

Ich lese hier fleissig mit, und spiele mit dem selben Gedanken wie olicat .

Wenn es hierzu erste Erfahrungen gibt, oder mal ein Screenshot von einer ersten Visu... bitte darüber berichten

.
An meinem MS Gen1 ist nur die KNX Schnitstelle belegt, und die 1Wire sowie die DMX Extension.

Hätte ich vor dem Kauf des MS schon etwas von dem Timberwolf gewusst, hätte ich vielleicht gleich mal einen Test gemacht.

**Dütt** · 18.02.2022, 21:32

Hi zusammen,

Ich habe mir auch den Timberwolfserver 3500L zum Spielen zugelegt. Er läuft bei mir seid zwei wochen Produktiv in teilen meines Hauses als Ersatz für KNX Extension, RS485 Extension, 1-Wire Extension. Bisher ohne Probleme. Ich sende mir die ganzen Werte per MQTT an den Miniserver.
Die KNX Werte kommen über MQTT sogar schnellere rein als über die KNX Extension. Das Konnte ich mehrfach in der Config beobachten. Aktuell könnte ich mir das Gerät sehr gut als ersatz für die oben geannten Extension vorstellen.
Was ich allerdings nicht weiß wie das mit dem MQTT Gateway ist obs da irgendwelche grenzen gibt wenn mehr daten auf einmal kommen zum Beispiel.
Falls der Loxberry mal nicht laufen sollte funktioniert erst mal nichts mehr. Aber da könnte man sich denk ich mal im Timberwolfserver eine Not-Logik anlegen falls ein Gerät nicht mehr erreichbar wäre zum Beispiel.

Das Einzige Manko falls man es überhaupt als Manko sehen kann ist das man mehr Konfigurationen im Timberwolfserver machen muss als im vergleich zu den Extension.

Gruß Marco