CCU3

[NickHM]

Ein konstanter DC im Wertebereich von 10-30 sollte noch einiges vom Limit weg sein. Bin Mal gespannt ob du Recht behältst wenn die nächsten 5-6 Aktoren noch kommen, die es dann zur endgültigen finalen Installation noch werden sollen. Damit sollte der DC nicht noch viel weiter hoch gehen. Aber dann kommen nochmal 50 Kanäle obendrauf - das werden aber wohl HM und keine HmIP Aktoren...

594 Kanäle in 179 Geräten Hm und HMIP CCU3
DC nie höher als 20% im normalen Betrieb.

Im Moment widersprechen die genannten Grenzen meinen praktischen Erfahrungen.

[Andre-Acer]

Danke Nick für die Erfahrungen! Dann hab ich ja noch Luft.
Ich dachte ich hätte mit wenigen kleinen Programmen (ja natürlich die üblichen Anfängerfehler schon raus) und die vielen Direktverknüpfungen mit den virtuellen Kanälen schon gut was für den DC getan. Aber offensichtlich muss ich da nochmal ran. Wenn ich das lese ist mir die 30 die ich ab und zu habe (zu Hochphasen) noch zu hoch. Wobei bei mir natürlich ausschließlich IP Komponenten drin sind...
Aber gut: wenn alles so steht wie ich will geht's nochmal ans Optimieren

[gzi]

Ich denke, es kommt immer darauf an, was man tut. Wahrscheinlich kann man auch eine CCU mit 10 Geräten in die Knie zwingen, wenn man es drauf anlegt. Daher ist es wohl schwierig allgemein zu sagen, wo die Obergrenze liegt.

Mich würden noch zwei Fragen interessieren

- Wie kann man feststellen, dass die CCU an der Kippe ist?

- Was macht man an besten, wenns soweit ist?

Hat wer von Euch Erfahrungen oder Vorschläge dazu?

Gzi

[66er]

Hallo,

...
- Was macht man an besten, wenns soweit ist?
...

Reagieren sollte man idealer Weise bevor es soweit ist.

Z.B. kann man die Aufgaben auf 2 Zentralen verteilen und diese miteinander vernetzen, um Informationen auszutauschen.

LG
Stefan

[gzi]

Hallo,

...
- Was macht man an besten, wenns soweit ist?
...

Reagieren sollte man idealer Weise bevor es soweit ist.

Stimmt, aber dazu müsste man das rechtzeitig erkennen. Deshalb: meine erste Frage.

Z.B. kann man die Aufgaben auf 2 Zentralen verteilen und diese miteinander vernetzen, um Informationen auszutauschen.

Nun, ins gleiche Netz hängen, ist keine Kunst. Aber wie kommunizieren zwei CCUs am besten miteinander, nach welchen Kriterien teilt man am besten Geräte und Programme auf.... Das wäre interessant .

gzi

[66er]

Moin gzi,

...
Stimmt, aber dazu müsste man das rechtzeitig erkennen. Deshalb: meine erste Frage.
...

Auch wenn es in meinem Fall der "Spieltrieb" war, warum ich die Vernetzung angefangen habe:

permanent hoher DC und oft nötige Neustarts könnten z.B. solche Anzeichen sein.

...
Aber wie kommunizieren zwei CCUs am besten miteinander, nach welchen Kriterien teilt man am besten Geräte und Programme auf...

Da bleiben wohl nur http-Requests/-befehle ( = keine Kosten), sofern man (wie ich) auf Hardwarekopplung (Aktor der einen CCU steuert Sensor der Anderen = Kosten) verzichten will.

Die Kopplung per Datenaustausch funktioniert bisher fehlerfrei.

Die Aufteilung kann nur individuell festgelegt werden. In meinen Augen macht das nur thematisch Sinn. Ich habe zwar noch nicht den Endstand erreicht, aber geplant ist:

CCU2 -> Heizung, Erweiterung EMA, Visualisierungspartner für die Home24-App*
CCU3 (Charly) -> Rest, siehe SIgnatur

Außerdem bietet sich die Möglichkeit, beim Aufsetzen der 2. CCU2 Fehler in der 1. (Anfängerfehler) auszubügeln. Bei einem Umzug, wo einfach die bestehende Versorgung in die neue Zentrale eingespielt wird, wandern die Fehler gleich mit

*der WAF verlangt nach 1 Oberfläche für beide Zentralen.

LG
Stefan

[Garbsen]

@66er :

Da bleiben wohl nur http-Requests/-befehle ( = keine Kosten), sofern man (wie ich) auf Hardwarekopplung (Aktor der einen CCU steuert Sensor der Anderen = Kosten) verzichten will.

Kannst Du zu beiden Möglichkeiten etwas Anfängerhilfe geben?
Ich finde die Idee der Vernetzung sehr gut, da ich noch einen Raspi mit raspimatic „rumliegen“ habe würde ich auch gerne die Steuerung auf zwei Zentralen (derzeit CCU3 im Einsatz) verteilen. Erhöht ja definitiv die Betriebssicherheit.

Aber mir ist noch nicht klar, wie das mit http-Request funktionieren soll und was Du mit Hardwarekopplung meinst.

[Familienvater]

Hi,

solange nicht gute bis sehr gute Gründe vorliegen, würde ich ein Smart-Home nicht Clustern. In meinen Augen ist es (meistens) Augenwischerei hier von einer erhöhten Betriebssicherheit zu sprechen. In einem häuslichen Umfeld gibt soviele Single-Points-of-Failure, das "ein Zentrale" nur einer von vielen Punkten ist. Der Gewinn an "Betriebssicherheit" durch getrennte Zentralen geht zu Lasten der Komplexität. Man selber mag da noch durchblicken, was man aktuell gebastelt hat, aber wenn es in 2 Jahren ein Problem gibt, weiß man selber nicht mehr, was man sich dabei gedacht hat, ist man selber nicht mehr da, ist es praktisch unmöglich, das da jemand anders kurzfristig durchsteigt.

Es gibt evtl. Konstellationen, wie z.B. eine Keymatic mit FBs "exklusiv" mit individuellem Sicherheitsschlüssel als Insellösung an einer eigenen Zentrale zu betreiben, und den Rest auf einer anderen Zentrale mit Default-Sicherheitsschlüssel. Da muss man sich aber auch sehr gut überlegen, welche Trigger der "ungesicherten" Welt eine Türöffnung auslösen können, und wie ein "faken" dieser Trigger in der ungesicherten Anlage verhindert wird.

Wenn aufgrund der Weitläufigkeit einer Installation eine HmIP-Antenne und HmIP-Router nicht mehr ausreichen, würde ich eher auf eine Middleware wie ioBroker gehen, und dort die Logik Zentral halten, und die CCUs nur noch als "Funk-Antennen" nutzen.

Der Familienvater

[66er]

Hallo Garbsen

...
Kannst Du zu beiden Möglichkeiten etwas Anfängerhilfe geben?

Gerne doch.

Hardwarekopplung Informationsübergabe über Hardwarekomponenten wie z.B. 8-fach Sende- und Empfangsmodul

mein Variante per http

Setzen von Variablen oder Gerätezuständen mittels http-Aufruf

Mit diesem Thread fing das Thema an. Vielleicht hilft er DIr als Einstieg.

LG
Stefan

[66er]

Servus Familienvater,

...
solange nicht gute bis sehr gute Gründe vorliegen, würde ich ein Smart-Home nicht Clustern. ...

Es kommt darauf an, was man als "gute Gründe" ansehen möchte, wobei ich gleichzeitig Deiner Argumentation nicht wiedersprechen möchte.

Warum habe ich mit der Verteilung begonnen bzw setze diese fort:

• Die CCU3 (Charly) will ich neu aufsetzen, weil
  
  1.) In der CCU2 ein geänderter Sicherheitsschlüssel steckt
  
  2.) ich im Laufe des Lebenszyklus meiner CCU2 erkannt und gelernt habe, dass man viele Dinge besser machen kann. Und daher schied die Portierung der gesamten Programmierung aus.
  
  3.) Durch das Neuaufsetzen wird die Programmierung des Charly effektiver als es bei einigen Funktionen (durch meine damalige Unwissenheit) in der CCU2 war

Als angenehmer Nebeneffekt habe ich festgestellt dass sich die durchschnittliche Laufzeit der CCU2 durch die "Entlastung" deutlich verbessert hat.

Eigentlich wollte ich ja so die CCU2 schrittweise komplett ablösen. Davon bin inzwischen aufgrund der zuverlässigen Kommunikation und Co-Existenz der beiden Systeme aber endgültig abgerückt!

Ich kann bislang keine Negativpunkte verzeichnen.

Ob man 2 Systeme verwalten und administrieren will, muß natürlich jeder für sich entscheiden.

Noch habe ich Funktionsüberschneidungen drin, aber das Endziel ist eine klare Aufgabentrennung.

LG und schönen Sonntag
Stefan