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

[M*I*B]

Hallo Forengemeinde,

auf einen Tip hin hat es mich heirher verschlagen. Und ich bin angenehm überrascht, zumindest von dem, was ich hier so in der letzten halben Stunde in Erfahrung bringen konnte...

Daher...
Ich fahre seit etwa 5 Jahren ein größeres FHEM system, möchte da aber irgendwie weg, weil's mich nur noch nervt... Die Frage ist nur, ob ich meine bereits vorhandene Hardware letztlich hier irgendwie unterbringen kann; vielleicht mag mich da wer beraten wollen?

Zu meinem aktuellen System im Einzelnen:
FHEM Hauptinstanz läuft auf einem XEON 1HE. Eine weitere Instanz läuft auf einem PI3, welcher autark unsere Ölzentralheizung steuert (Pumpen, Brenner, Temp- Erfassung, Ölstand und Verbrauch, ...). Eine dritte Instanz läuft auf einem PI2, welcher ausschließlich 3SCC's verwaltet (HM, MAX, IT), eine vierte Instanz auf einem PI-zero, welcher unser Wasserbett und umzu steuert (Temperatur, Tagabsenkung, "Belegterkennung", Beleuchtung). Die quasseln alle mit der Hauptinstanz via MQTT.
Daraus erkennbar sind hier also HomeMatic- Geräte (Heizkörperthermostate, Wandthermostate, Dimmer, Schaltaktoren, Taster, Brandrauchmelder, Bewegungsmelder), MAX (nur Wandtaster = ECO-Taster) und InterTechno- Kram (Steckdosen, Temp/HUM- Sensoren, RGB- Steuerungen) im Einsatz. Hinzu kommen einige WeMos diverser Art (Sensoren, SmartMeter, Wasserzähler, Temp, Lumi, Radar, Aktoren, Anzeigen) und anderes (W)LAN Zeugs (Präsenzerkennung (SmartPhones, TV, HiFi, Server, ...))

Die alles entscheidende Frage ist also, ob ich das alles in ioBroker weiter benutzen kann und wenn ja, ob sich hier auch eine Schritt- für- Schritt - Umstellung (Funktion für Funktion aus FHEM weg in ioB implementiert) realisieren lässt, da alle auf einmal kaum möglich ist (es gibt noch ein Leben ausserhalb des SmartHomes ... :grinning: ).

DLzG
Micha

[Homoran]

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

ob sich hier auch eine Schritt- für- Schritt - Umstellung (Funktion für Funktion aus FHEM weg in ioB implementiert) realisieren lässt

Ich habe kein FHEM - aber es gibt einen FHEM Adapter.
Damit kannst du dann deine FHEM-Installation komplett in ioBroker einbinden und dann Schritt für Schritt davon entkoppeln

[M*I*B]

... danke für den Hinweis; das wäre zumindest eine von zwei denkbaren Optionen ...

Aber beim vielen Querlesen ist mir was aufgefallen:
Liege ich richtig mit der Aussage, das zur Implementierung meiner HM-Systeme eine CCU notwendig ist???

[Jey Cee]

@M-I-B ja da liegst du richtig, du brauchst eine CCU oder Derivat. Aber so eine CCU2 kostet nicht mehr viel gebraucht.

[M*I*B]

... ahhh, ok, dann habe ich das doch richtig verstanden ...
Das ist sehr schade; dann bin ich leider raus aus der Nummer...

[I-Punkt]

Nur mal für mich interessehalber: wie sind denn die HM-Komponenten im FHEM angebunden?
Edit: gerade selber gesehen - über SCC-Module
Gibt es für diese Module für den Pi keine "virtuelle CCU"?

[M*I*B]

... direkt ohne CCU ... Es reicht ein CUL, SCC oder auch HM-LAN, welcher direkt aus FHEM heraus angesprochen wird; eine physikalisch vorhandene CCU geht aber auch. Dabei ist es egal, ob per LAN, WLAN oder auch direkt via RS232(TTL) / USB am PI. Zudem kann man einen virtuellen Pool bilden, welcher aus zwei oder mehr HM- Transceivern beliebiger Art besteht, die sich über Haus und Grund verteilen; FHEM resp. das VCCU-Software-Modul kümmert sich dann selbst darum, welcher Transceiver die besten Sende- und Empfangseigenschaften zu einem Sensor/Aktor hat resp. nutzt bei Ausfall eines RXTX den Nächstbesten.

EDIT sagt: VCCU gibt es (der beschriebene Pool), hat aber mit einer "echten" CCU nix zu tun. Oder meinst Du den Befehlssatz resp. die logische Abbildung einer CCU in FHEM?

[I-Punkt]

@M-I-B
Danke für die Antwort!

[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.