Vor- und Nachteile der SW-Tools

[Christian24]

Hallo zusammen,

gibt es irgendwo eine Übersicht über die Vor- und Nachteile bzw. Verwendungsgrenzen der einzelnen Tools wie ioBroker, OpenHAB, NodeRed, FHEM usw.? Was macht Sinn, vielleicht auch in welcher Kombination?
Ich persönlich finde es gerade recht schwierig, eine Auswahl zu treffen, worauf ich jetzt setzen möchte und könnte ein paar Entscheidungshilfen gebrauchen. Vielleicht kann man ja die einzelnen Felder wirklich abgrenzen oder sind es eher persönliche Vorlieben!? Danke für eure Hilfe.

Gruß,
Christian

[Beleuchtfix]

Ist mir so nicht bekannt, ich denke, das hängt u.a. Auch mit den Vorlieben der Anwender/Programmierer für die einzelnen Programmsprachen zusammen. Einige schreiben lieber Code, andere machen es lieber graphisch z.B. mit Node Red. Du findest für jedes Programm Fand
Gruß Florian

[gbglace]

Ich würde auch schauen welche IoT-Systeme Du planst zu verwenden und auf welcher Plattform es dazu den größeren Support gibt.

Und soll es nur die Integration der IoT-Welt sein oder auch gleich noch Visu. Das alles beherrschen die Systeme unterschiedlich und haben eigene Designs.

ioBroker scheint ganz gut zu laufen ist aber wohl recht ressourcenhungrig und ich wundere mich warum viel IO-Broker nutzen um dann eine Ebene Tiefer doch noch NR z.B. zur Kopplung vom KNX zu benutzen.

Ich habe einen kommerziellen Server für Logik und KNX usw., IoT Ergänzungen die nicht vom Server direkt angebunden werden können ( Alexa, Velux KLF und Telegramm-Nachrichten-Bot) binde ich per NR im Docker-Container an, der auf dem Server läuft.

[meti]

Viele entwickeln sich auch recht rasch was so eine Aufstellung schnell alt aussehen lassen würde.
OpenHAB zb released so 2-3x pro Jahr, Home Assistant 1x pro Monat... da ändert sich doch recht viel.

Ich würd mir mal überlegen welche Integrationen benötigt werden (Knx, Modbus, Hue, Alexa, Apple HomeKit, InfluxDB, Fernzugriff, ne native App mit - evtl lokalen - Push Messages etc.) und danach ausschließen.
Dann einfach mal ausprobieren mit ner Minimal-Konfiguration um zu sehen welche Konzepte für UI und Logik am besten gefallen.

NodeRed als Logik-Engine kannst du übrigens auch unter Home Assistant und OpenHAB benutzen (über die anderen weiß ich nix).

[GLT]

eine Übersicht über die Vor- und Nachteile bzw. Verwendungsgrenzen der einzelnen Tools wie ioBroker, OpenHAB, NodeRed, FHEM usw.? Was macht Sinn, vielleicht auch in welcher Kombination?

Jede Übersicht wäre ohnehin nur eine Momentaufnahme, da sich die Umgebungen permanent weiter entwicklen - was letztes Jahr vielleicht noch ein Malus gewesen wäre, ist inzwischen ausgemerzt, der Bonus einer anderen Lösung ist längst nicht mehr Alleinstellungsmerkmal,....

Im Internet gibt es zwar Einige, die "Vergleiche" anstellen (oder versuchen) - im Endeffekt muss man sich aber mal alle Kandidaten ansehen u. dann für sich selbst eintscheiden.

ioBroker+NodeRed ist gar nicht so unüblich - hier ersetzt NodeRed dann üblicherweise Blockly, da NodeRed wesentlich mehr Möglichkeiten bietet.
Obwohl mit NodeRed im Grunde alleine auch alles möglich sein sollte, kann man manches mit ioBroker eleganter lösen.

Nun könnte man sich entweder/oder entscheiden, aber auch die Kombination wählen - reine Geschmackssache.

So fügen sich auch alle anderen marktgängigen Lösungen ein; vorrausgesetzt die Lösungen können deine Ansprüche aktuelle alle erfüllen, so wird dir die eine in der Handhabung besser gefallen, als eine andere - die Qual der Wahl

[scw2wi]

Es gibt eine alte Masterarbeit, wo die Systeme mal verglichen wurden. Ist aber leider nicht mehr relevant, da sich das zu rasch ändert. Auf YouTube findet man aber auch aktuelle Beispiele, um sich ein grobes Bild machen zu können.

Wichtig ist auch noch die Community, wie viele Leute bei Problemen helfen können.

In einer KNX Umgebung hat Edomi viele Vorteile, in einer heterogenen Umgebung gibt es Beführworter für viele verschiedene Systeme, bis auf FHEM, das immer weniger erste Wahl ist.

Walter

[meti]

scw2wi Welche Vorteile hat Edomi in Bezug auf Knx ggü. zB HomeAssistant? Hab Edomi nie probiert.

[Beleuchtfix]

Einfach alle mal testen, bei den Open-Source Programmen kostet das doch nur deine Zeit

[gbglace]

Welche Vorteile hat Edomi in Bezug auf Knx ggü. zB HomeAssistant? Hab Edomi nie probiert.

Edomi wurde gebaut um KNX perfekt zu bedienen. Fremdsysteme sind dann per LBS hinzugefügt um sich ins KNX-Schema einzufügen.

Alle anderen Systeme sind irgendwie Smarthome IoT und haben unter anderem einen KNX-Adapter.

[meti]

Das ist jetzt die Herkunftsgeschichte, mich hätte interessiert welche konkreten Vorteile das bringt. Was kann Edomi mit Knx was die anderen (mit ihren Knx Adaptern) nicht können?

[gbglace]

Naja mit EDOMI kann keine Geräte programmieren, wüsste aber auch keinen Adapter der das sonst kann, die normale Kommunikation mit dem KNX per Tunneling oder KNX-IP gemäß den Regeln der Flags an KO sollte jeder Adapter beherrschen.

Das da so mancher Adapter hingegen Störungen produziert wie ein eibd oder knxd oder die Loxone-Kiste ist mir bei EDOMI noch nicht aufgefallen.

[meti]

KNX-IP gemäß den Regeln der Flags an KO sollte jeder Adapter beherrschen

ETS Applikationen haben die doch alle nicht (und die KNXA hat da auch kein Interesse dran...) also bekommen die auch nix von irgendwelchen Flags mit, oder?

[h4nnes]

Ich habe mir Edomi und Home Assistant auf einer VM installiert, um diese zu vergleichen.

Vorteil von Edomi ist sicherlich hier die Community. Vorteil Home Assistant (in Verbindung mit NodeRed) ist mMn die Einfachheit. Bei Edomi ist man zwar wesentlich flexibler, was die UI anbelangt (da man alles selber machen kann/muss), was aber auch zu meinem vorherigen Punkt führt, dass man bei Home Assistant wesentlich schneller zum Ziel kommt (und man mit Custom Cards auch eine schicke Visu hinbekommt). Ich denke, dass das jeder für sich abwägen muss.

[gbglace]

ETS Applikationen haben die doch alle nicht (und die KNXA hat da auch kein Interesse dran...) also bekommen die auch nix von irgendwelchen Flags mit, oder?

Man kann bei einigen Systemen aber sehr wohl je GA einstellen ob der Adapter / Server auf readrequests antworten soll oder auch auf Readresponds reagieren soll, sprich man die Flags und das Reaktionsverhalten in den Adaptern einstellen kann. Wer will schon das ein solches System auf alle Readrequests wenn es nur ein Konsument ist oder auf keine antwortet wenn die IP-Seite die Quelle der Information ist.

Ich glaube kaum das die KNX-org das nicht will, die Ersteller der Adapter bauen halt keine zertifizierten Schnittstellen. Die horchen blank auf dem Bus und gönnen dem User noch den Import von GA-listen / Projektdateien (was schon zu den guten Umsetzungen zu zählen ist) um Tipparbeit zu sparen. Die Hoffnung ist immer das der implementierte Stack dann keine Störungen verursacht bei dem was sonst auf dem Bus passiert.

Visu ist nochmal eine ganz andere Kiste. Und ja da reicht die Spannweite es von einfachen Apps bis EDOMI, da muss man wirklich sehen was einem gefällt und wieviel Aufwand ist man bereit aufzuwenden bzw. welche UI zur Erstellung liegt einem.

Logik und Systemadaptierung kann da ja gern was anderes sein.

[meti]

Ich glaube kaum das die KNX-org das nicht will, die Ersteller der Adapter bauen halt keine zertifizierten Schnittstellen.

Naja, zumindest nicht im Open-Source Sinn. Wenn man ihnen 1000€ pa. schickt würden sie es schon nehmen. Man muss eben "KNX Member" sein um eine ETS Applikation signieren zu können (ja das geht auch irgendwie ohne, aber Benutzerfreundlicher wirds dadurch nicht...). "Zertifizierte Schnittstelle" kannst auch nur als Member machen - auch wenn es nur reine Software ist die KNX Routing / Tunneling spricht.

Mal schauen was KNX IoT für diese Projekte so bieten wird.