Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[I-Punkt]

@M-I-B
Ich dachte an sowas wie Raspimatic, piVCCU oder so um das ganze vielleicht doch in den iobroker zu bekommen.

[M*I*B]

... ahh, nu weiß ich, wohin Du gedacht hast ...
Tja, irgendwie aber auch nichts Halbes und nix Ganzes...
Nur damit wir uns nicht falsch verstehen: Ich finde ioBroker, mal von JAVA / JS abgesehen, ziemlich gut, und das nicht nur die UI betreffend. Aber wenn ich schon einen Umstieg angehe, der sicherlich noch reichlich Probleme mit sich bringen wird, möchte ich mir nicht zusätzliche Probleme durch erforderliche und mit der heißen Nadel gestrickte Hardware einbauen; und die CCU's gehören zu den Dingen, die ich hier keinesfalls sehen will ;o)

[I-Punkt]

@M-I-B
Okay, kann ich nachvollziehen.

[Wildbill]

Es spricht ja aber nichts dagegen, FHEM dann quasi nur als Hardware-Schnittstelle zu "missbrauchen" und den ganzen Rest wie Logik, Scripts, Visualisierung, Logging und dergleichen ioBroker zu überlassen, welcher über den FHEM-Adapter oder MQTT mit FHEM kommuniziert?!
Bei mir läuft auf einem Pi mit Funkmodul piVCCU für Homematic, in einer separaten VM FHEM mit zwei CUL (433 und 868) weil ioBroker via CULs leider nicht alle meine Altlasten (u.A. FS20) steuern kann. Alles andere, was iobroker direkt kann, läuft dort. Und ich habe, abgesehen vom vielleicht etwas höheren Verwaltungsaufwand was z.B. Updates angeht, keinerlei Probleme und freue mich, dass ich alle Datenpunkte aller Geräte einfach in iobroker habe und dort verwenden kann, als wenn es FHEM oder piVCCU gar nicht gäbe.

Kleiner Vorteil wäre zudem, dass man in CCU/piVCU Direktverknüpfungen anlegen kann, die dann auch noch laufen würden, wenn iobroker doch mal abschmiert, was bei mir aber noch nie vorkam, toi toi toi...

Gruss, Jürgen

[Homoran]

@M-I-B sagte in Einsteigerfragen (weg von FHEM, hin zu...):

und die CCU's gehören zu den Dingen, die ich hier keinesfalls sehen will

Das kann ich definitiv nicht nachvollziehen!
Wobei ich diese Aussage auf piVCCU und deren Vorgänger yahm und lxccu beschränken möchte.

Diese laufen bei mir seit Jahren absolut problemlos.
Kann es nicht dass CCU und ccu2 wegen der geringen Ressourcen Probleme haben könnten, aber diese lagen meist an kaputtgespielten Systemen.

Wenn du für ioBroker die CCU nur als Gateway nutzst sollte es alles laufen.

[Jey Cee]

@Homoran sagte in Einsteigerfragen (weg von FHEM, hin zu...):

Wenn du für ioBroker die CCU nur als Gateway nutzst sollte es alles laufen.

Das kann ich bestätigen, bei mir läuft die CCU2 nur als Gateway und das funktioniert seit Jahren Problemlos.

[M*I*B]

... ja, diese Option sehe ich schon ...

ioBroker kann ja eigentlich alles mögliche nativ, daher möchte ich mal anders herum fragen: Warum kann ioBroker denn gerade HM nicht nativ? Was hat denn das für Gründe, das genau diese Implementation nicht vorhanden ist?

Der Stolperstein hier ist ja, das ein PI als reiner RXTX mit seinen drei SCC's (HM, IT, MAX) arbeitet. Den müsste ich dann zerreißen und quasi alles dezentralisieren. Das geht dann hier für mich persönlich in die genau falsche Richtung. Ich würde mir eher wünschen, das ich noch mehr dieser RXTX-PI's verwenden könnte, bestenfalls mit Generierung entsprechender Transceiver- Pools wie bei FHEM mit der VCCU, so das auch mobile Geräte immer die bestmögliche Abdeckung erfahren ...

[Homoran]

@M-I-B sagte in Einsteigerfragen (weg von FHEM, hin zu...):

ioBroker kann ja eigentlich alles mögliche nativ,

Falsch! ;-)

ioBroker ist schlicht eine Software und benötigt für ALLE Systeme ein Interface/Gateway/Bridge/WasAuchImmer

Einige dieser Interfaces sind LAN/WLAN und somit zufällig in der Hardware vorhanden, oder werden als USB-Stick/GPIO-Modul angesteckt.
trotzdem bleiben das externe Gateways

ioBroker wurde entwickelt um vorhandene Systeme jeden Ursprungs miteinander zu verbinden. (I/O Broker)
In diesem Fall existieren ja schon die Gateways

[M*I*B]

... ok, ist ein Argument und akzeptiert ...
Ändert aber nichts daran, das ich meine "Gateways" zu HM, MAX und IT, welche sich aktuell auf einem PI faktisch in einem "Modul" befinden, zerreißen müsste. Von daher ist Dein Argument korrekt bezogen auf den Zusammenschluß verschiedener Systeme, welche jeweils ein eigenes Gateway haben; mein System ist genau anders herum gewachsen: Ein (resp. derzeit drei) MultiGateways (von der Hardware betrachtet), auf dem die Infrastruktur gewachsen ist.

[I-Punkt]

Nur kurz zur Klarstellung. Meine CCU2 läuft auch seit Jahren tadellos. Das "kann ich nachvollziehen" bezog sich auf dem Umstand, daß es ohnehin aufwändig ist, ein bestehendes großes System auf eine andere Plattform umzuziehen und dass man da nicht noch zusätzliche neue "Fehlerquellen" haben möchte.

[Homoran]

@M-I-B sagte in Einsteigerfragen (weg von FHEM, hin zu...):

mein System ist genau anders herum gewachsen: Ein (resp. derzeit drei) MultiGateways (von der Hardware betrachtet), auf dem die Infrastruktur gewachsen ist.

Das ist mir vollkommen klar.
Dieses "Missverständnis" kommt bei FHEM-Usern immer wieder vor.

Beide Systeme haben einen unterschiedlichen Anspruch.
Und damit auch beide für den jeweiligen Anspruch eine Daseinsberechtigung.

[Jey Cee]

Also mein ioBroker host läuft auch als MultiGateway. Bei mir läuft deConz mit USB Stick für ZigBee parallel zu iobroker und direkt in ioBroker integriert enOcean mit USB Stick.
Die CCU2 war einfach schon vorher da und ich hab nie die Notwendigkeit gesehen sie zu ersetzen, sonst gäbe es bestimmt eine Lösung direkt am Host

Mir kommt es so vor als hättest du gerne alles aus einem Software Guss. Das ist bei ioBroker sowieso nicht so, hier werden nicht auf biegen und brechen eigene Integrationen gebaut wenn es schon ein gutes System gibt das man nutzen kann.

[M*I*B]

... naja sag ich doch :sunglasses:
Ich bin halt gestern noch von einer falschen Voraussetzung ausgegangen und stelle nach und nach fest, das sich meine Vorstellungen mit ioB wohl nicht umsetzen lassen...
Ein entscheidendes Kriterium für mich ist halt, wie sich heute ja herauskristalisiert hat, das ich meine PI/Debian/SCC - basierten Multigateways weiterhin als einzige Gateways benutzen möchte. Es kommt für mich nicht in Frage, hier weitere Gateways ala CCU, MaxCube o.ä. zu implementieren.
Optional wäre ich auch bereit, eine andere Art von MultiGateway zu erwerben, so lange dieses Gateway per LAN (PoE?!) resp. WLAN aus ioB nutzbar ist und mindestens die Protokolle HM, MAX und IT vereint (gern auch modular weitere like ZigBee & Co).

[umbm]

Ich bin auch nach Jahren mit fhem zu iobroker gewechselt, vor allem wegen der mir immer wieder zu umständlichen Programmierung und Sprachen-Mix in fhem (bin bekennender Syntax-Legastheniker).
Der Umstieg auf iobroker hat es mir einfacher gemacht, da reicht Javascript aus und Blockly ist perfekte Hilfe für schnelle logische Umsetzung.

Was du auch als Aspekt beim Umstieg unbedingt beachten solltest, ist die Visualisierung.
Ich hatte mir das in fhem für mein Tablet perfekt eingerichtet und mit iobroker war da natürlich eine vollständige Neuerstellung über das VIS-Modul notwendig. In fhem war das Handarbeit in HTML, was in iobroker so nicht nutzbar ist.
Das sind noch so einige Stunden zusätzliche Arbeit.

Ansonsten: alle Hardware, die mit MQTT arbeitet ist problemlos in iobroker zu übernehmen.
Zur Zeit habe ich mir parallel zum iobroker noch ein Mini-fhem neu installiert, mit dem ich den 433MHz-Cul für einige alte Komponenten einbinde und proplanta -Wetter abfrage, was es für iobroker noch nicht gibt.
Dieses fhem läuft wartungsfrei im Hintergrund und wird mittels fhem-Adapter in iobroker eingebunden.

Zu der HM-Problematik kann ich leider nichts beitragen, nutze nur noch WLAN-Komponenten über MQTT und ZigBee-Aktoren.

Ich habe den Umstieg auf keinen Fall bereut.