Gira X1 vs Timberwolf Server 3500

[amasingh]

Ordentlicher Visu und Logikserver ist in der KNX Welt leider ein trauriges Thema. Keine Ahnung warum es keiner so richtig macht. Loxone ist uns da weit voraus (aber eben auch nicht perfekt)

Ich logge mit dem TWS L konkret:
- Den gesamten KNX Bustraffic (Temperaturen, Luftfeuchte, Stromwerte der MDT AMI Aktoren, Wetterdaten etc)
- Mein Fronius Smart Meter per ModBus TCP über einen Fronius Gen24
- Meine OpenWB über ModBus TCP
- Einen Eastron sdm72 v2 Stromzähler über ModBus TCP, an dem die Wärmepumpe hängt

[zaphood]

IO-Broker kann ich das Konzept nicht ganz nachvollziehen weil das selbst auch nur gut läuft wenn man da drinnen NodeRed installiert. Bei HA scheint es auch einige solche Abhängigkeiten zu geben.

Kannst du das ein bisschen erläutern bitte, was du damit meinst? "

[gbglace]

Wen ich das Forum hier durchstöbere und jemand berichtet davon wie er IO-Broker nutzt dann ist dort immer ein NodeRed parallel oder via IO-Broker installiert dabei. Sei es weil der KNX-Adapter im IO-Broker schlecht funktioniert oder nur begrenzte Anzahl Datenpunkte kostenfrei hat. Oder eben auch Logikabbildungen oder Anbindung einzelner Systeme via NR laufen. In dem Moment Frage ich mich, vor allem seit dem es im NR selbst die Dashboards gibt, wozu hat man dann überhaupt den IO-Broker wenn man eine solche Abhängigkeit zum NR hat. Was kann der IO-Broker mehr/besser als ein NR?

NR scheint eine gewisse Wunderwaffe bei der IoT-Integration zu sein.

Für mich es auch genau aus diesem Grunde am Start, da ich mir damit die Alexa und den Telegramm Bot ans KNX gebracht habe.

Ansonsten konzentriere ich das alles im TWS. Für meine Geräte-Landschaft funktioniert das halt auch sehr gut, da ich die halt TWS-freundlich einkaufe. Wer natürlich schon einen bunten Straus an IoT Geraffel hat und dann erst zum KNX und der Entscheidung TWS vs. X1 und welche Ergänzung dazu kommt, da schaut es dann sicher anders aus.

Bisher kann ich alles mit TWS Boardmitteln + NodeRed abdecken und es werden immer mehr Komponenten die man von NR in den TWS integrieren kann, bzw. mit MQTT über ein leichteres Protokoll weg vom KNX zwischen beiden austauschen kann. Und das zusammen auf der HW des TWS lokal im LAN.
Visu habe ich für die Bedienung des Hauses alles was ich brauche auf der einfachen App Easy-KNX, die Visu für die Statistiken usw. das ist alles im Grafana und kann daher simpel am PC/Tablet/Handy betrachtet werden.

Video und Türsprech ist hier aktuell keine Anwendung aber wohl mit sowas wie CV und EDOMI auch abbildbar, welche auf dem TWS als Container laufen können.

[zaphood]

Vielen Dank für die Übersicht :-)

Wen ich das Forum hier durchstöbere und jemand berichtet davon wie er IO-Broker nutzt dann ist dort immer ein NodeRed parallel oder via IO-Broker installiert dabei. Sei es weil der KNX-Adapter im IO-Broker schlecht funktioniert oder nur begrenzte Anzahl Datenpunkte kostenfrei hat.

Das gilt nicht mehr für den OpenKNX Adapter. Was ich aber aus eigener Erfahrung sagen kann ist, OpenHab war und ist bei mir von allen genannten System bei weitem das stabilste und das KNX Binding (so heissen die Adapter da) ist das beste aus der ganzen Liste an Systemen. Funktional kann OH m.E. die KNX Themen auch am besten nutzen (Rollershutter sind z.B. in der IOBroker UI eher suboptimal), bis hin zum control-item (da bildet OH dann selbst ein KNX Gerät ab).

Oder eben auch Logikabbildungen oder Anbindung einzelner Systeme via NR laufen. In dem Moment Frage ich mich, vor allem seit dem es im NR selbst die Dashboards gibt, wozu hat man dann überhaupt den IO-Broker wenn man eine solche Abhängigkeit zum NR hat.

Bei der Logik würde ich sagen, das geht in Blockly einfacher als in Nodered. Sobald es mal bisschen komplexer wird, braucht es in NR einen Function-Node, da bist du dann mit Java dabei. Das ist bei IOBroker simpler und für Anfänger einfacher. Daher verstehe ich auch nicht, warum die Leute NR da als Logikmaschine einbinden, ich sehe den Bedarf an der Stelle ehrlich gesagt nicht. Aber auch das ist nur meine Meinung die ich mir im Laufe der Zeit gebildet habe und die sicher nicht allgemein gültig ist.

Was kann der IO-Broker mehr/besser als ein NR?

NR ist wesentlich mehr "Handarbeit" bis das mit allen Devices läuft. Speziell z.B. Rückmeldefunktionen sind aufwendiger zu bauen, bis die in der Visu ankommen. Von da her kann ich verstehen, wenn man den IOB da als einfacher empfindet. Zudem ist die Visu in NR... eher sehr simpel. Da kann man bei praktisch allen anderen Systemen was deutlich hübscheres bekommen ;-) Bei manchen Nodes bekommt man auch nen Knoten ins Hirn, bis man versteht wie die Syntax sein muss. Auch das ist bei IOB oder HA (in Teilen auch bei OH) einfacher, da sie Devices selbst finden und als Objektbäume abbilden. Viel Klick-and-Run macht das Leben eben einfach.

Am Ende hast du dir auch eine Landschaft aus mehreren Teilen gebaut, die deine Bedürfnisse abdeckt. Unterstreicht leider den Tenor dieses Threads zum Thema KNX Visu und Logik, das gibt es wohl einfach nicht in gut, günstig und gefällig ;-)

Cu
Frank


Edit:Typo

[gbglace]

Ja noch hat niemand die eierlegende Wollmilchsau in der Form gebaut, das sie auch leicht und intuitiv zu bedienen ist.

[xnet]

TSW hat Vorteil, dass hier viele Tools aus Opensource und einige eigene in einem Gerät zusammengestellt und für diese Hardware optimiert wurden. Die Tools aus Opensource-Welt sind nicht immer aktuell, werden aber ab und zu upgedatet. Die Hardware von TSW ist schon viel leitungsfähiger als bei X1. Arbeitsspeicher, CPU und Speicher sind fest verlötet und lassen sich kaum austauschen oder erweitern. Beim CPU handelt es sich um einen 64 Bit ARM Cortex-A72 mit 4 Kernen zu je 1,5 GHz aus dem Jahr 2016. Wenn man einige Dockers laufen möchte, sollte man ein Modell mit größtem Arbeitsspeicher - 8GB wählen.
Leistungswunder soll man von dieser Hardware nicht erwarten auch 32GB Festspeicher könnten irgendwann knapp werden, besonders wenn man einige Dockers mit Logging am Laufen hat. Dafür ist der Stromverbrauch sehr klein.
Die Firma selbst ist nicht besonders kundenfreundlich und Support nach dem Gewährleistungsablauf ist ein sehr teurer Spaß. (persönliche Erfahrung)
Für Leute ohne Kenntnisse und ohne Zeit, aber mit viel Geld wäre es wahrscheinlich die beste Lösung.

Ansonsten kann man NAS-Systeme dafür nehmen, wenn man schon eins hat.
Wenn man viel Power braucht, dann wäre NUC oder Futro mit Proxmox die beste Wahl.
Futro mit 32GB Arbeitsspeicher und 256GB SSD kostet nur ein Bruchteil, hat enorme Leistung und man hat natürlich vollen Zugriff auf eigenes System!

[kmk85]

Ohje Leute, ich bin jetzt noch unsicherer als zuvor... :-|

Werde glaub ich erst mal ne gebrauchte NAS schießen und nur mein Logging der relevanten Punkte da erledigen, NAS brauch ich eh.

Werde mich dann mal an NodeRed wagen, was da im Docker laufen kann. Damit sollte ich meine paar Geräte auch in HomeKit bekommen.

Und dann schaue ich mal, ob ein TWS noch Sinn macht, wäre beim Modubus sicherlich reizvoll.

[willisurf]

Achte mal beim NAS darauf, das die RAM Ausstattung nicht zu klein und der Prozessor nicht ganz schwachbrüstig ist. 4GB sollten es mind. schon sein.

[kmk85]

Habe mal ne QNAP TS-253be mit 8GB im Auge. Sollte vorerst reichen.

[zaphood]

Bedenke bitte, dass die NAS auch im Leerlauf einen vergleichsweise hohen Stromverbrauch haben. Platten runterfahren und ähnliches klappt bei vielen NAS durch aktive Hintergrunddienste nicht. Mein NAS (QNAP mit i5 / 32GB und 4 x 4TB) braucht im Idle rund 35W, und das ist noch ohne eine einzige VM oder Container aktiv. Daher ist das bei mir zu 95% runtergefahren und wird nur bei Bedarf per WOL gestartet.

Würde dir nochmals zu einem NUC raten, die mit 8000er Prozessor sind relativ günstig zu bekommen (ca 400€) und mit Proxmox hast eine super Platform die kaum den Zähler belastet. Auf dem Teil läuft bei mir auch noch ein OpenMediavault als LXC für die wichtigsten Files, so dass ich eine alternative Dateiablage zum NAS habe.

Ansonsten kann man auch nen Raspi nehmen und Portainer als Containermanagement draufsetzen. Wenn man den auf USB-Boot umstellt und ne externe SSD dran klemmt, dann ist das auch ne recht brauchbare Lösung. Nur das Backup ist dann noch separat zu lösen. (und bei den aktuellen Preise für RPi4 ist der Sprung zum NUC nicht mehr weit ;-))

[zaphood]

Ohje Leute, ich bin jetzt noch unsicherer als zuvor... :-|

Und dann schaue ich mal, ob ein TWS noch Sinn macht, wäre beim Modubus sicherlich reizvoll.

Modbus TCP geht so gut wie mit allen Lösungen relativ schmerzarm. Nur wenn du Modbus RTU (also per seriellem Kabel) benötigst, dann ist der TWS deine Lösung der Wahl.

Bedenke, eine Lernkurve hast du überall, kommerziell wie Open Source. Das sollte also nicht das alleinige Kriterium sein. Und weder Influx/Grafana noch NodeRed brauchen sonderlich viel Ressourcen, können also auf allem laufen was stromsparend unterwegs ist (nur bei Einsatz eines RPi würde ich dringend von einer SD Karte abraten und auf eine SSD setzen, sonst "zerschreibt" dir Influx im Zweifel alle paar Monate die Karte)

[zaphood]

Habe mal ne QNAP TS-253be mit 8GB im Auge. Sollte vorerst reichen.

Check dann aber vorher, ob das überhaupt Container und VM unterstützt. Das tun nicht alle bei QNAP....

[xnet]

Habe mal ne QNAP TS-253be mit 8GB im Auge. Sollte vorerst reichen.

Die CPU ist nicht der Renner, aber sollte für Logging und einige Dockers ausreichen...
Wenn Raspi, dann nur mit 8GB, aber bei heutigen Preisen würde ich es nicht empfehlen...
Lieber einen gebrauchten Futro und man kann direkt loslegen, später kann man immer noch aufrüsten. Stromverbrauch im durchschnitt ca. 10W.

[zaphood]

Wenn Raspi, dann nur mit 8GB, aber bei heutigen Preisen würde ich es nicht empfehlen...

Am Thema Preis ist was dran. Aber den 8GB würde ich eh nicht empfehlen,da RaspberryOS m.W. noch immer 32-bittig ist und daher alles über 4GB nur mit Kopfstand funktioniert. Die Idee mit dem Futuro finde ich auch gut. Solange man Docker Container nutzt sind auch 4GB absolut ausreichend. Es war ja auch die Rede davon, Homeassistant oder IOBroker nutzen zu wollen, da würde ich nun beiden Fällen zur VM (oder zum LXC Container) raten. Auf Docker haben beide Systeme m.E. einen zu hohen Konfigurationsaufwand (wieder nur meine eigene Meinung aus Stunden des Versuchs).

[meti]

64 Bit Raspbian gibts seit ca. nem Jahr. Auch HA OS zb gibt es als 64 Bit Image für RaspberryPi (und ist auch empfohlen).
Arch etc schon viel länger.