CCU3 als Gateway
-
@dominik-f Moin,
ich hatte früher die CCU2, bin dann auf RaspberryMatic umgestiegen und habe die CCU2 als Gateway eingerichtet. Funktioniert wunderbar
-
die Raspberrymatic kann meines wissens als Gateway betrieben werden.
dass damit aber HmIP "verlängert" wird wäre mir neu, aber nicht unmöglich.Entscheidend wird das Funkmodul sein. Für die Reichweitenverlängerung auf der CCU ist auf jeden Fall zwingend das große Funkmodul nötig, da dieses die Verschlüsselung der Netzwerkverbindung übernimmt.
-
@nordischerjung sagte in CCU3 als Gateway:
@dominik-f Moin,
ich hatte früher die CCU2, bin dann auf RaspberryMatic umgestiegen und habe die CCU2 als Gateway eingerichtet. Funktioniert wunderbar
auch für HmIP?
-
@homoran Stimmt, hast recht. Kein HMIP. Hab ich auch gar nicht.
-
@dominik-f sagte: weitere CCU3 als Gateway
Weshalb als Gateway? Man kann zwei CCU3 in ioBroker integrieren. Da ohnehin mit Alias gearbeitet wird, merkt man am Ende (Visualisierung / Logik) nicht einmal den Unterschied zwischen beiden.
-
Das mit der 2ten ccu3 stimmt natürlich, da hatte ich gar nicht dran gedacht, dass man diese dann einfach parallel laufen lassen könnte. Ich hatte bisher immer nur von Gateways gelesen, für hmip halt den access point und für hm ne ccu2 oder den gateway. Dachte dann an die ccu3 will die ja beides kann und ich mir dann ein Gerät sparen kann
Kommen die sich denn irgendwie in die Quere bzw. Muss da auf etwas geachtet werden?
-
@dominik-f sagte: Kommen die sich denn irgendwie in die Quere bzw. Muss da auf etwas geachtet werden?
Da der Duty cycle auf 1% begrenzt ist, ist die Wahrscheinlichkeit gering, dass sie sich gegenseitig stören. Der physische Abstand wird ohnehin nicht gering sein.
-
@dominik-f sagte in CCU3 als Gateway:
Kommen die sich denn irgendwie in die Quere bzw. Muss da auf etwas geachtet werden?
Die Geräte können nur an eine Zentrale angelernt werden, die Logik muss dann natürlich nur auf ioBoker laufen.
Dort musst du dann entsprechend mehr hm-rpc Instanzen laufen haben -
@homoran sagte: die Logik muss dann natürlich nur auf ioBoker laufen.
... zumindest die raumübergreifende Logik. Ich würde generell auf die etwas eigenwillige Logik der CCU verzichten.
-
wie sieht es dann mit den enums aus? Die müssten/sollten auch Quellunabhängig sein, falls man mit Selector arbeiten will, oder?
-
@homoran sagte: wie sieht es dann mit den enums aus?
Du meinst die enums, die in der CCU verwaltet und per HM-Rega in ioBroker übernommen werden?
-
@paul53 ja, laufen die automatisch in ioBroker zusammen?
-
@homoran sagte: laufen die automatisch in ioBroker zusammen?
Ja, wenn man sie in beiden CCUs gleich bezeichnet hat.
Ich würde auf die Verwaltung in der CCU verzichten und es nur in ioBroker machen: Ich nutze kein RegaHss. -
-
Ich danke euch für eure Antworten und auch für die Diskussion, dass hilft sehr weiter.
