... naja sag ich doch
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).

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

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

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

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

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

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

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

DLzG
Micha