ioBroker vs. RedMatic, Koexistenz?

[linuxdep]

Hallo,

gute Diskusion hier zu dem Thema, jeder hat hier wohl seine eigenen Erfahrungen gemacht, da kann man als Einsteiger nur lernen.
Werde ich wohl mal auf pivCCU3 gehen und dort dann RedMatic dazu tun. Damit die Automation erst mal alles auf dem RPi läuft...
Was meint ihr, ioBroker extern anzubinden an RedMatic, wenn ich andere Sachen einbinden will, wie meinen "Mähhh" macht das Sinn oder wäre es besser auch Node-Red im ioBroker zu haben? Wobei mir die Abhängikeit RPi und Syno zu groß ist, die ist halt nicht so hoch verfügbar wegen Updates und Co.

...
Ein Hinweis dazu allerdings: Ich rate davon ab auf einer CCU3/RaspberryMatic mit 1GB RAM beides zu nutzen. Der Mediola Server fußt genauso wie RedMatic/Node-RED auch auf Node.js. Und das schluckt eine Menge RAM. Ich würde dazu raten Dich dann für eins von beidem zu entscheiden.

Da meinst doch: RedMatic und Mediola auf einem RPI, richtig?

[rewe0815]

Also wenn du ioBroker ohnehin nutzen willst, rate ich (zur Zeit) noch zur integrierten Lösung ioBroker-Node-Red Adapter.
Warum ?
Die Lösung bietet dir einen relativ (wenn auch eingeschränkten) Zugriff von Node-Red auf ioBroker.
Und mit den Homematic Nodes hast du dennoch einen sehr komfortablen Zugriff auf HM falls du die brauchst.
Denn den HM-Adapter gibt es ja auch in ioBroker. Damit lassen sich die beiden Welten (meiner Meinung nach) am Besten verbinden.
Allerdings bist du dann auch an ioBroker gebunden, was nicht nur Vorteile hat:
- NR Updates kannst du nicht autonom machen, da bist du auf die Version des Adapters angewiesen.
- Ein paar spezifische Eigenarten des ioB-NR-Adapters gibt es auch
- Die beim Adapter mitgelieferten Nodes gestatten keinen kompletten Zugriff auf die ioB Daten. Du kannst zwar den Simple-API Adapter zusätzlich in NR nutzen, aber das bleibt immer noch Gefrickel.
- Und du kannst dich über kurz oder lang vom Raspi verabschieden, weil dem mit ioB schnell die Puste ausgeht. (Auch wenn jetzt wieder alle schreien wie toll das läuft Aber ein Blick ins ioB-Forum mit den vielen Threads zum NUC, Rock64, OPi und wie die alle heissen, sollte jeden stutzig machen.

Aber alles in Allem kann man damit super arbeiten (mach ich seit ca. einem Jahr)

Falls du lieber Raspimatic oder Homematic + Node-Red einsetzen willst, hast du auch keine bessere HM-Anbindung in NR aber die ioB Anbindung ist wesentlich schlechter.
Da steht dir dann im Grunde der Simple-API Adapter zur Verfügung, mit dem du aber nichts abonnieren kannst.
Der ideale Zugriff in dieser Konstellation ist der socketIO-Adapter. Der kann eigentlich Alles was nötig ist.
Allerdings kenne ich derzeit noch keinen contrib-node dafür. Ich hab mir einen "node" dafür gebastelt. Der läuft allerdings im Moment noch in einem Function-node. Mal sehen ob ich da noch genügend Zeit für finde, da mal ein contrib-node draus zu machen. Aber vlt. macht sich inzwischen ja jemand Anderes dran.

Bei mir läuft alles Wesentliche in separaten Docker-Containern derzeit auf einem rock64. Außer der HM, da hab ich eine CCU2.
Bei separaten Containern für ioB, NR, mqtt, influxDB, grafana u.a. ist es kein Problem mehrere Instanzen parallel laufen zu lassen. Unschätzbare Hilfe beim Entwickeln. Und wenn die Ressourcen knapp werden, wird der ein oder andere Container einfach auf einen anderen Rechner verschoben.

Also Beides hat Vor- und Nachteile

Gruß
rewe0815

[hobbyquaker]

Werde ich wohl mal auf pivCCU3 gehen und dort dann RedMatic dazu tun.

Da würde ich eher von Abraten. Wenn Du piVCCU einsetzt kannst Du auch einfach ein Container oder eine Installation auf dem Host selbst mit einem "normalen" Node-RED und node-red-contrib-ccu nutzen. RedMatic braucht man eigentlich nur für die CCU3 und RaspberryMatic weil man dort eben ausschließlich Addons nutzen kann.

[hobbyquaker]

Falls du lieber Raspimatic oder Homematic + Node-Red einsetzen willst,

Ich vermute Du meinst hiermit RedMatic bzw. Node-RED mit den node-red-contrib-ccu Nodes? Bitte genau auf die Begrifflichtkeiten achten um Verwirrung zu vermeiden

hast du auch keine bessere HM-Anbindung in NR

Also falls Du die node-red-contrib-ccu Nodes meinst widerspreche ich vehement. Die Möglichkeiten die diese Nodes bieten gehen weit über das hinaus was ioBroker.hm-rpc/ioBroker.node-red bei der Anbindung an und Nutzung von Homematic in Node-RED bieten. Man hat mit dem RPC Event Node einen Node der Nachrichten "gespusht" bekommt, mit mächtigen Filtermöglichkeiten, auch per RegExp. So ist es beispielsweise kein Problem zu sagen "gib mir alle Events von Aktoren aus Räumen die mit 'Kinderzimmer' beginnen und im Gewerk Licht sind. Auch beim setzen von Werten ist es möglich auf mehrere Aktoren auf einmal zu gehen und mit nur einem Node zu sagen "Schalte alle Schaltaktoren des Gewerks Licht und alle Dimmer im Erdgeschoss aus". Auch die Nutzung von RAMP_TIME und ON_TIME ist dabei komfortabel vereinfacht.
Darüberhinaus gibt es spezielle Nodes die das Handling von Homematic Display(-Tastern), Funkgongs, MP3 Aktoren und LED Signalen super komfortabel machen.
Und zu guter Letzt ist es mit dem RPC Node möglich beliebige RPC Calls auf den Schnittstellenprozessen aufzurufen um speziellere Dinge wie z.B. das Umschalten des Modus bei den Wandthermostaten der ersten Generation durchzuführen oder Wochenprogramme bei den neueren Thermostaten dynamisch zu ändern u.v.m.

Was meint ihr, ioBroker extern anzubinden an RedMatic, wenn ich andere Sachen einbinden will, wie meinen "Mähhh" macht das Sinn oder wäre es besser auch Node-Red im ioBroker zu haben?

Ich würde dazu raten keine all zu "wilde Mischung" aufzubauen, das macht es am Ende nicht übersichtlicher und jedes System bringt Overhead und weitere Subscribers auf den Schnittstellenprozessen mit (was die CCU belastet). Besser für ein System entscheiden und dann dabei bleiben. Entweder ioBroker oder RedMatic bzw. node-red-contrib-ccu. Wenn es Dinge gibt die Du anbinden möchtest, für die es keine Node-RED Nodes gibt, aber ioBroker Adapter - oder wenn Du Wert auf eine tolle Visualisierung (ioBroker.vis) legst dann nutze besser den ioBroker. Wenn das nicht der Fall ist und/oder Du lieber alles auf einer Kiste laufen haben willst rate ich eher zu RedMatic bzw. node-red-contrib-ccu.

[Marcdo70]

Moin also ich bin seit ein paar Wochen von iobroker mit Nodered Adapter komplett auf Redmatic umgestiegen.
Da meine Homematic Installation eh nicht so groß ist und werden wird, da nur eine Wohnung und ich keine Lust mehr hatte 2 Systeme ständig upzudaten.
Nutze aktuell wie gesagt Redmatic wie auch vorher Nodered hauptsächlich um Alexa ohne Cloud bzw. ohne monatliche zusätzliche Gebühren zu integrieren.
Vorher hatte ich halt Iobroker um über den Szenen Adapter und Harmony Adapter Szenen zu steuern und Milight und Sonoffs zu integrieren.
Dies hab ich nun ausschließlich mit Redmatic und den dazugehörigen, milight, Harmony nodes usw als Szenen zusammen gestellt um es nun aus Redmatic per Alexa und CuxD zu schalten.
Durch die Kombination von Redmatic und CuxD Schaltern lässt sich alles halt wunderbar einfach auch aus Apps wie home24 etc auch an einem Wandtablet steuern, ohne aufwändige Visualisierung selbst zu erstellen, was mir reicht.
Evt werde ich mich mal mit dem Dashboard noch beschäftigen wenn ich Lust und Zeit habe.
Aktuell reicht es mir halt so.
In Nodered im Iobroker hatte ich dann ausschließlich mit den Iobroker Nodes gearbeitet weil ich die ccu nodes erst zu verwirrend fand und die iobroker nodes einfacher waren mit den auszuwählenden Datenpunkt, naja jetzt geht's auch mit den ccu nodes super in Redmatic.
Iobroker ist natürlich sehr umfangreich und wenn man eine tolle Visualisierung erstellen möchte toll, aber diese Visualisierung empfand ich am Anfang als Anfänger sehr schwierig zu verstehen und hatte es nie so einfach und toll aussehend hinbekommen, wie man es bei Beispielen im Internet und Foren gesehen halt.
Wie gesagt ich benutze Redmatic halt um Fremdgeräte und Alexa zu integrieren und meine paar Programme die ich bis jetzt habe, laufen auf der RaspberryMatic.
Das einzige was ich manchmal empfinde ist, das die Reaktion nach Alexa schalte dies oder das......manchmal sehr zeitverzögert ist, was ich bei iobroker nodered und alexa lokal nicht so hatte.
Ansonsten bin ich mit meiner Kombination RaspberryMatic, CuxD und Redmatic soweit zufrieden und deckt erstmal alles ab was ich integrieren wollte.
LG Marcus

[Hypnos]

Also wenn du ioBroker ohnehin nutzen willst, rate ich (zur Zeit) noch zur integrierten Lösung ioBroker-Node-Red Adapter.
Warum ?
Die Lösung bietet dir einen relativ (wenn auch eingeschränkten) Zugriff von Node-Red auf ioBroker.
Und mit den Homematic Nodes hast du dennoch einen sehr komfortablen Zugriff auf HM falls du die brauchst.

Sehe ich genau anders. Ich habe auch IOBroker laufen und nehme RedMatic.

Wie schon von hobbyquaker geschrieben ist die Anbindung der CCU an RedMatic ist nicht zu vergleichen mit der Anbindung von IO Broker zu Homematic.

Falls du lieber Raspimatic oder Homematic + Node-Red einsetzen willst, hast du auch keine bessere HM-Anbindung in NR aber die ioB Anbindung ist wesentlich schlechter.
Da steht dir dann im Grunde der Simple-API Adapter zur Verfügung, mit dem du aber nichts abonnieren kannst.
Der ideale Zugriff in dieser Konstellation ist der socketIO-Adapter. Der kann eigentlich Alles was nötig ist.

Die ideale Anbindung macht man ohne "gefrickel" über MQTT! Damit kann man auch sehr einfach IOBroker an RedMatic anbinden.
Man kann beispielsweise im IOBroker MQTT - Client Adapter einstellen, welche IOBroker Stati über MQTT veröffentlicht werden sollen(*).

Als MQTT Broker empfehle ich hier sowieso besser Mosquito als Addon auf der CCU und nicht den IOBroker MQTT Adapter als Broker.

Im IOBroker MQTT Adapter kann man auch alle Stati kompletter anderer IOBroker Adapter über MQTT veröffentlichen und 2-Wege darauf direkt von RedMatic/Node-Red zugreifen. Im Node-Red wiederum ist damit sehr einfaches subscribe auf Stati-Änderungen des IOBroker möglich.

ganz anderes Thema:
Was für mich auch wichtig ist, ist das neben der besseren Anbindung die Backup Strategie wichtig ist. Der IOBroker läuft ja fast schon zwangsweise auf anderer Hardware (weil er mehr Ressourcen benötigt). Hier hatte ich ich in der Vergangenheit mehrere Probleme mit IOBroker. Mindestens 3 mal führte ein Update des Controllers in der Vergangenheit dazu, das IOBroker danach überhaupt nicht mehr lief (weil die objekt Datenbank zerschossen war) und damit eine Neuinstallation nötig war. Auch ein Hardwareproblem (Boot-Flash-Speicher kaputt) machte da in dem Rechner eine Neuinstallation nötig. Die Wiederherstellung der IO Broker Installation ist (im Vergleich zur Homematic CCU) aufwendig und komplex (man muss schon mit der Kommandozeile umgehen können).

Im Gegensatz dazu ist hier ist RedMatic klar im Vorteil. Der läuft auf der Selben Hardware wie die CCU. Damit lässt sich da auch entsprechendes Backup einfach bereitstellen. In meinem Falle hab ich immer (neben den Backups) eine SD Karte neben den Raspi liegen, welche eine relativ aktuelle Kopie enthält. Einem Laien lässt sich da auch sehr einfach erklären, das er im Problemfall erstmal den Pi Stromlos und die SD Karte tauschen soll.
Wenn das nicht hilft ist das Wieder einspielen eines Backup über die Homematic Oberfläche auch nicht so kompliziert, das man es einem Laien nicht erklären kann. Das kann man sicher noch weiter ausbauen (Backup-Pi bereitstellen).

Man sollte sich jedoch eine klare Trennung zwischen Redmatic und IOBroker haben. Also alles an Logikschicht was wichtig ist auf RedMatic und im IOBroker alles was nicht so wichtig ist und nicht die Welt untergeht, wenn es mal ein paar Tage nicht läuft.

Gruß

PS: *) Ich weiß nicht ob das Problem gefixed ist, aber "früher" musste man im IOBroker MQTT Adapter unbedingt einstellen, das man getrennte Topics für setzen und lesen von Stati heben will.

Sonst hat man beim setzen eines Stati sehr schnell eine Endlosschleife:

Ein Stati wird gesetzt --> MQTT Adapter reagiert auf die Änderung --> MQTT Adapter published die Änderung auf dem Broker --> MQTT Anapter relisiert die Änderung des Stati über den Broker --> MQTT Adapter setzt den Stati --> MQTT Adapter reagiert auf die Änderung....

[rewe0815]

Also falls Du die node-red-contrib-ccu Nodes meinst widerspreche ich vehement. Die Möglichkeiten die diese Nodes bieten gehen weit über das hinaus was ioBroker.hm-rpc/ioBroker.node-red bei der Anbindung an und Nutzung von Homematic in Node-RED bieten. Man hat mit dem RPC Event Node einen Node der Nachrichten "gespusht" bekommt, mit mächtigen Filtermöglichkeiten, auch per RegExp.

Nanu? und wieso sollten die sich nicht unter ioB-Node-Red nutzen lassen? Also bei mir sind sie installiert. Oder gibt es da noch andere speziell für Redmatic?
Und zusätzlich gibt es in ioB noch den RPC/Rega-Adapter, mit dem sich das ganze Gedöns dann nochmal per States nutzen läßt;-)

Ich würde dazu raten keine all zu "wilde Mischung" aufzubauen, das macht es am Ende nicht übersichtlicher und jedes System bringt Overhead und weitere Subscribers auf den Schnittstellenprozessen mit (was die CCU belastet).

Dem kann ich nur zustimmen!

Besser für ein System entscheiden und dann dabei bleiben

Dem weniger Das geht an der Realität vorbei. Du wirst immer Sachen finden, die dein gewähltes System nicht abbildet, die du aber uuunbedingt gerade brauchst.
Wenn ich mich im ioB-Forum schaue, scheint es jede Menge User zu geben, die ioB einsetzen obwohl sie hautsächlich mit HM arbeiten. Vlt. sollte der TO da ja mal nachfragen, warum sie ioB als Hauptsystem einsetzen und wie deren Konstellation ist.

Ich vermute Du meinst hiermit RedMatic bzw. Node-RED mit den node-red-contrib-ccu Nodes? Bitte genau auf die Begrifflichtkeiten achten um Verwirrung zu vermeiden

Ja, das wird so sein, kann einen schon verwirren.
Auch wenn hier nicht so der richtige Rahmen dafür ist, Ich bin schwer beeindruckt von deinen Software Sachen. Ich nutze sie sehr gern und möchte mich ausdrücklich bei dir bedanken!!!
Ich weis wieviel Zeit man da investiert!

Die ideale Anbindung macht man ohne "gefrickel" über MQTT! Damit kann man auch sehr einfach IOBroker an RedMatic anbinden.
Man kann beispielsweise im IOBroker MQTT - Client Adapter einstellen, welche IOBroker Stati über MQTT veröffentlicht werden sollen(*).

Ja, das könnte ein super interoperabeler Ansatz sein. Da habe ich lange meine komplette HM mit angebunden. Aber "ohne gefrickel" ? Na ich weis nicht, ob das ein Anfänger auch so sieht;-)

Was für mich auch wichtig ist, ist das neben der besseren Anbindung die Backup Strategie wichtig ist.

Na lass die Sachen in Containern laufen. Für die Bewegungsdaten mappst du je ein Verzeichnis in die einzelnen Container. Alle Verzeichnisse befinden sich in einem gemeinsamen Hostverzeichnis.
Dann reduziert sich ein Backup auf ein einfaches Docker-compose stop mit anschließendem Zip.
Und die 'Wiederherstellung der ioB Installation' ist mit Docker ja auch ein Einzeiler;-)
Ich wünschte, da gäbe es offizielle Docker-Images mit entsprechendem Support. Aber wenn man einmal weis wie es geht..

Also, ich will hier um Gottes Willen keinen Streit vom Zaun brechen was besser ist! Hat alles seine Vor- und Nachteile.
Der Thread zielte ja darauf ab, dass der TO über kurz oder lang zusätzlich ioB einsetzen will. Und da muss er selbst entscheiden, wo seine Schwerpunkte liegen.
Ich wollte lediglich einige der verfügbaren Varianten mit seinen Vor- und Nachteilen aufführen.
Ich setze Beides ein und kann damit sehr gut leben;-)

rewe0815

[Marcdo70]

Also falls Du die node-red-contrib-ccu Nodes meinst widerspreche ich vehement. Die Möglichkeiten die diese Nodes bieten gehen weit über das hinaus was ioBroker.hm-rpc/ioBroker.node-red bei der Anbindung an und Nutzung von Homematic in Node-RED bieten. Man hat mit dem RPC Event Node einen Node der Nachrichten "gespusht" bekommt, mit mächtigen Filtermöglichkeiten, auch per RegExp.

rewe0815

Ähm, das habe ich nicht geschrieben, da hast dich geirrt mit dem Zitat

LG Marcus

[rewe0815]

Ähm, das habe ich nicht geschrieben, da hast dich geirrt mit dem Zitat

Entschuldigung. Habs geändert. Da nimmt man schon die Zitierfunktion...

[Marcdo70]

Ähm, das habe ich nicht geschrieben, da hast dich geirrt mit dem Zitat

Entschuldigung. Habs geändert. Da nimmt man schon die Zitierfunktion...

Kein Ding
LG