2x Homematic Wired Gateway an einer OCCU

[trood]

Mit meiner Anfrage direkt bei eQ3 habe ich leider Schiffbruch erlitten - vielleicht komme ich ja mit OCCU und Rasberrymatic weiter?

Die Story ist einfach: ein Teil meiner Aktoren ist Wired-gebunden in einem Nebenhaus und ohne die Möglichkeit, weitere Kabel (weder seriell, noch CAT7) dort zu verlegen und durch einen Planungs-/Denkfehler kann ich das dortige RS465 LAN-Gateway zwar problemlos via PowerLine stabil bis ins Hauptgebäude zur CCU bringen, doch diese CCU versorgt bereits ein RS465 LAN-Gateway im Dachgeschoss. Mir war nicht klar, dass man an die originale CCU-Firmware selbst auf CCU3-Hardware keine zwei dieser RS-Gateways anlernen kann/darf. Die Begründung "Lastproblem" vom Support finde ich aber reichlich kurz gesprungen, denn die CCU3 darf ja problemlos ne ganze Reihe von Gateways in Hm und HmIP gleichzeitig zugeordnet bekommen und hat dafür genug Power unter der Haube.

Also betreibe ich notgedrungen derzeit zwei unabhängige CCU mit jeweils einem RS465 LAN-Gateway und für kritische Steuerungen "zwischen" beiden Welten mogele ich mich mit CUxD und der XML-API durchs Leben. Unter Mediola habe ich halt dann zwei CCU-Connections, also alles kein Totalschaden.

Ich würde tatsächlich aber lieber gerne ***eine*** Rasberrymatic nutzen und dort beide LAN-Gateways gleichzeitig anlernen. Ist das aus Entwicklungssicht absolut abwegig? In Summe bräuchte ich Support für 2x HMW465, 1x HM LAN-Gateway, 1x HmIP-HAP (beide jeweils wegen Reichweite und Funkschatten im Betonbau) und 1x HmIP-DRAP und die erstgenannten sind offenbar "einer zu viel" für eine CCU3. Wie wäre es denn mit OCCU?

Danke
LG
Thorsten

[jmaus]

Wie wäre es denn mit OCCU?

Die Systemvorrausetzungen sind diesbzgl. In OCCU genau die selben wie bei einer CCU3, denn alle die Wired (egal ob BidCos oder HmIP) sind in den entsprechenden Closed-Source Teilen von OCCU verankert auf die es eben keinen Quellcode Zugriff gibt.

[Ralli_]

Mehrere HMW-Gateways an einer CCU, welche auch immer, werden nicht unterstützt.

Mehr als ein DRAP geht aber. Und es geht m.W. auch ein HMW- und ein DRAP-Gateway. Also wäre die Alternative, einen Strang auf HmIP-Wired umzustellen.

[trood]

@jmaus: schade, ich dachte der OCCU-Zweig hätte da Vorteile und du könntest dich ggf. dran vorbei mogeln

@ralli: daran hatte ich auch gedacht, aber muss dann leider auch die Aktoren alle von Wired auf IpWired umbauen. Auf der Hutschiene wäre netto zwar der Platz verfügbar bei all-in 1:1 Tausch, aber dann sitze ich eben auch auf den HmW-Komponenten fest - für die Ersatzteilkiste 'n Hauch zu viel und für Ebay mit zu viel Verlust, wenn ich sie dort abverkaufe. Übrigens waren die IpWired zum damaligen Zeitpunkt noch nicht auf dem Markt, die sind - trotz Ankündigung der Markteinführung - dann doch mal locker 8 Monate oder mehr zu spät gekommen.

im PDF zum Advanced Routing ist aber 2x DRAP und 1x HAP auch einer zu viel: https://homematic-ip.com/sites/default/ ... iel-ar.pdf - ich hänge also am selben Problem, dass ich für Wired eigentlich ein Buskabel zwischen den Gebäuden benötige - oder einen Busumsetzer RS465 auf Ethernet. Hat jemand sich schon mal mit so was auseinander gesetzt?

[trood]

ich mein natürlich RS485. Typo.

[Ralli_]

Du hast doch geschrieben, dass du über DLAN das jetzige HMW-Gateway problemlos vom Nebengebäude zur CCU im Hauptgebäude bringen könntest.

Wenn du unbedingt alles mit einer einzigen Zentrale zusammenbringen möchtest, wirst du m.E. keinen anderen Weg finden, als im Nebengebäude (oder im Hauptgebäude) die Wired-Komponenten auf HmIP-Wired zu bringen und somit ein HMW-Gateway und ein HmIP-Wired-Gateway an der CCU zu betreiben.

Ich selbst würde tatsächlich bei dem Ansatz mit den beiden getrennten CCUs bleiben, diese als reine Kommunikations-Gateways (über die angeschlossenen HMW-Gateways) zu den Aktoren und Sensoren betrachten und die Logik in eine übergeordnete Schicht auslagern (FHEM, openHAB, ioBroker etc.).

[trood]

ja, das wird vermutlich so laufen. Ich hätte es halt schöner gefunden, übergreifende Skripts, die Komponenten in beiden Umgebungen ansprechen, "simpel" zu integrieren und nicht mit wilden crossover-API aufzurufen, zumal man deshalb durchaus 1-2 Sekunden Latenz in der Aktorenschaltung erkennen kann. Das trifft glücklicherweise nur auf ein paar Bewegungsmelder-abhängige Abläufe zu. Außerdem käme mein Notfallplan und -equipment dann mit weniger Zeugs aus. Vielleicht ist es einfach nur die Optimierung der letzten 5%...

Umrüstung geht eben nicht, weil es schon drei räumlich getrennte Wired-Aktorenblöcke sind. Manchmal scheitert es einfach am fehlenden Leerrohr über die letzten 20 Meter... Ich wollte mich noch mal vergewissern, dass ich nicht doch ein Feature übersehen habe.

Danke für die Antworten!

[trood]

PS: den Vorschlag mit der konsolidierten darüberliegenden Schicht möchte ich nicht verfolgen, weil einfach historisch schon extrem viel in HMScript direkt auf der CCU investiert/entwickelt wurde und dieser Umbau einfach deutlich zu aufwändig wäre. Dazu kommt noch der WAF-Faktor, was in welcher Reihenfolge ggf. bei einem Totalausfall oder Kaltstart berücksichtigt werden muss, wenn ich auf Dienstreise bin.

[Fonzo]

Ich hätte es halt schöner gefunden, übergreifende Skripts, die Komponenten in beiden Umgebungen ansprechen, "simpel" zu integrieren und nicht mit wilden crossover-API aufzurufen

Wenn Du so oder so zwei CCUs im NEO Creator angelegt hast, wäre zumindest eine mögliche Option einfach beide in NEO Server einer der beiden CCU3 zu verknüpfen.