Ankündigung

Einklappen
Keine Ankündigung bisher.

Timberwolf 3500 - eine Loxone-Erweiterung oder gar Alternative?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    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 ;-)

    Kommentar


    • #17
      Hallo Klartext,

      Zitat von Klartext Beitrag anzeigen
      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 Beitrag anzeigen
      - 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 Beitrag anzeigen
      - 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 Beitrag anzeigen
      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

      Kommentar


      • Klartext
        Klartext
        Extension Master
        Klartext kommentierte
        Kommentar bearbeiten
        Danke für die Klarstellung, freut mich das bei euch alles rund läuft
        (war auch nicht böse gemeint, man hat hat immer eine gewisse Grundskepsis um nicht auf das falsche Pferd zu setzen)

        Als Schnittstellenmonster sehe ich euren Server ziemlich einzigartig an und natürlich wärs cool wenn es eine direkte Schnittstelle zum Miniserver geben würde

      • Gagi
        Gagi kommentierte
        Kommentar bearbeiten
        Das beantwortet auch meine Frage. Ich seh das wie Klartext und ist bestimmt nicht böse gemeint, nur eine gewissen Grundskepsis ;-)

        Als Ergänzung zur Loxone find ich das Gerät auch sehr interessant.

    • #18
      Hi!

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

      Oliver

      Kommentar


      • #19
        Hallo Eisenkarl,

        Zitat von eisenkarl Beitrag anzeigen
        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 Beitrag anzeigen
        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

        Kommentar


        • #20
          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 ?
          Es ist nie zu spät für eine glückliche Kindheit.

          Kommentar


          • #21
            Hallo Miep.

            Zitat von Miep Miep Beitrag anzeigen
            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 Beitrag anzeigen
            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

            Kommentar


            • Miep Miep
              Miep Miep kommentierte
              Kommentar bearbeiten
              Danke für die Antwort:

              Thema DALI:
              a) grober Loxone Umfang
              b) alles was man bei a) schmerzlich vermisst (z.B. mehrere Lines)
              c) Rest

              Kommunikation Loxone:
              - mich interessiert primär wie aufwändig es ist in der Konfiguration, muß ich mir für jedes Element manuell einen abkonfigurieren ?
              - wie viele Elemente ? So dass eine mittelgroße Konfiguration verbunden werden kann. Für mich nicht einschätzbar, weil ich auch noch nicht alle Möglichkeiten verstehe (meine Holschuld)
              Zuletzt geändert von Miep Miep; In den letzten 2 Wochen.

          • #22
            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 ....
            AlexAn
            Lebende Foren Legende
            Zuletzt geändert von AlexAn; In den letzten 2 Wochen.
            Grüße Alex

            Kommentar


            • #23
              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

              Kommentar


              • #24
                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
                Zuletzt geändert von olicat; In den letzten 2 Wochen.

                Kommentar


                • #25
                  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
                  LoxBerry/Plugin Support: Wenn du einen Begriff in meiner Antwort nicht auf Anhieb verstehst, bitte nicht gleich rückfragen, sondern erst die Suche im LoxWiki und bei Google bemühen.
                  PN/PM: Ich bevorzuge die Beantwortung von Fragen in öffentlichen Threads, wo andere mithelfen und mitprofitieren können. Herzlichen Dank!

                  Kommentar


                  • Miep Miep
                    Miep Miep kommentierte
                    Kommentar bearbeiten
                    StefanWerner Quoten geht da leider nicht ;(

                    Wieso es so kompliziert ist ist nicht unwichtig, aber wenn kein Weg dran vorbei geht, auch nicht hilfreich.

                    Wobei die Frage ist welche Use Cases man abdecken will. Vielleicht sollte man die sammeln. Ich fange mal banal an.

                    Werte aus Loxone, die man gerne in ordentlichen Statistiken wie Grafana haben will möglichst einfach rüber bringen. Das können beliebig viele sein. 2 Mehrwerte, Miniserver Schreiblast extrem reduziert, schicke und tolle Statistiken in Grafana, zum Beispiel auch zusammengeführt (Beispiel: Raumtemperaturen + Vorlauftemperatur Heizung + Außentemperatur)

                • #26
                  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)
                  AlexAn
                  Lebende Foren Legende
                  Zuletzt geändert von AlexAn; In den letzten 2 Wochen.
                  Grüße Alex

                  Kommentar


                  • #27
                    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.
                    Zuletzt geändert von Squarry; vor 6 Tagen.

                    Kommentar


                    • Dütt
                      Dütt kommentierte
                      Kommentar bearbeiten
                      Squarry Du kannst ja zum Beispiel Edomi im Docker installieren. Edomi ist auch inzwischen schon relativ mächtig da gibt es inzwischen auch im Knx user forum eine große Community.
                      Edomi hat auch einen logikeditor und auch werden von den Usern ziemlich viele Bausteine entwickelt.
                      In dem Logikeditor kannst du dich genauso austoben wie im Miniserver. Nur ist es bei edomi oder egal welcher Hersteller nicht so einfach und schnell eine funktionierente Visu zu haben. Bei Edomi baust du deine Grafik selber und dann musst du hinter Button z.B. deine Gruppenadressen hinterlegen. Zusätzlich baust du dann noch deine logik.
                      Ich hab selber schon viele Geräte X1, HS3/4, Edomi, wiregate… programmiert. Nur so leicht und schnell hast du es nirgendswo wie bei Loxone.
                      Ich überlege such schon ob ich mir nicht mal den Timberwolf Server zum Spielen hole.

                      Das einzige was ich allerdings nicht weiß ob du durch Edomi zugriff auf die Datenpunkte im Timberwolf server hast. Da Edomi ja hauptsächlich gür KNX programmiert worden ist.

                      Gruß

                    • Christian Fenzl
                      Christian Fenzl
                      Lebende Foren Legende
                      Christian Fenzl kommentierte
                      Kommentar bearbeiten
                      Worauf Squarry hinaus wollte, ist dass sich ein normaler Häuslbauer keinen Docker-Container installieren kann, egal ob Edomi oder sonst was.
                      Mein Bruder würde sagen, „Was ein Container, dafür habe ich im Garten keinen Platz!“ 😊

                    • tollertenya
                      tollertenya kommentierte
                      Kommentar bearbeiten
                      Der "Normalo" bleibt weiter bei HomeKit etc hängen. Viele wahrscheinlich ganz ohne Automatisierung.
                      Ich habe auch ein paar Systeme durch IoBroker, fhem, OpenHab.... - bei keinem war es so einfach sinnvolle Automatiken zu erstellen wie bei Loxone (wenn auch manchmal vertrackt genug).
                      Die Loxone App und das Schalterprogramm sind für uns optisch ansprechend.

                      Wenn ich was dazu baue wäge ich den Integrationsaufwand einer 3rd Party und der oft teureren Loxone eigenen Lösung gegeneinander ab.
                      Beispiel Wallbox - die Keba Wallbox kostete mehr als eine Easee Box war aber nativ sehr schnell einzubinden.
                      Genauso ginge mir es mit dem Timberwolf - der Integrationsaufwand ist für mich schwer abzuschätzen.

                  • #28
                    Hallo zusammen,

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

                    lg

                    Stefan

                    Kommentar

                    Lädt...
                    X