Mehr als eine CCU2 einbinden

Begonnen von uholz, 26 November 2016, 13:15:18

Vorheriges Thema - Nächstes Thema

uholz

Liebe Community!
Aufgrund (zu) vieler HM-Aktoren habe ich mehr als eine CCU2 im Einsatz und möchte gerne via FHEM eine Visualisierung und z.T. auch begrenzte Steuerung an einem Ort für alle HM-Devices (die CCU's sollen nicht ersetzt werden!) erreichen.
Ist es also möglich, z.B. mittels HMCCU mehrere CCU anzusprechen/einzubinden?

LuckyDay


uholz

Auch wenn es darum hier nicht geht...
Um Problemen mit zu vielen Aktoren (Schalter, Relais, Thermostate, Heizungsreglern, Fensterkontakte...), der Leistungsfähigkeit der CCU-Hardware, der Funkabdeckung und dem damit verbundenen Funkverkehr (der ja limitiert ist im genutzten Funkband) in einem professionellen Umfeld (keine Einfamilienhaus-Bastelei, ohne das abwertend zu meinen) zu entgehen (und da habe ich viele Foren & Co. "gewälzt") haben wir uns für eine stockwerksweise Aufteilung mit je einer CCU2 meist plus HM-CFG-LAN entschieden - läuft auch wunderbar störungsfrei und soll auch nicht geändert werden (Never change...)  ;-)

Nun wünschen wir uns halt eine Lösung, bei der alle Räume u.v.a. deren Temperatur schnell überblickt und ggf. Störungen im Blick sind, ohne jede der 4 CCU immer einzeln abfragen zu müssen - die Regelung bleibt in der CCU - lediglich einzelne Schalter sollten noch bedienbar sein.
Ggf. möchte ich noch eine Art "Ferienschaltung" integrieren, mit der alle Heizungen z.B. zwischen Weihnachten und hl.drei König nur Frostschutz gewähren, ohne die Programmierung aller einzelner Räume anfassen zu müssen...

Ich hoffe, damit ist die Fragestellung klarer...

zap

Da ich nicht damit gerechnet habe, dass jemand mehrere CCUs im Einsatz hat und an FHEM anbinden will, funktioniert derzeit nur 1 CCU. HMCCU nutzt einige globale Variablen und auch der RPC-Server ist nicht dafür ausgelegt, z.B. n Mal den BidCos-Port zu bedienen. Ich schaue mir mal an, was ich ändern müsste und würde es in die übernächste Version einbauen. Die nächste ist schon fertig und im Test.

Bitte achte darauf, dass Dein FHEM auf einer einigermaßen leistungsfähigen Hardware läuft. Für jede CCU und für jedes verwendete Protokoll (Wired, BidCos-RF, HM-IP, Gruppendevices) wird jeweils ein separater FHEM Prozesse gestartet. Wenn Du also z.B. 4 CCUs hast und auf jeder BidCos und Gruppendevices, ergibt das 4x2 = 8 FHEM-Prozesse mit RPC-Servern.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

uholz

Danke zap, klingt doch schon mal vielversprechend...

Die Leistungsfähigkeit des Linux-Servers sollte kein Problem sein, da es eine virtuelle Maschine ist, die ich ggf. entsprechend skalieren kann!

zap

OK, ich bau das ein und hoffe dann auf Deine Unterstützung beim Testen, da ich nur eine CCU habe.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

uholz


uholz

FHEM wäre weiterhin unsere erste Wahl - aber inzwischen wurde beschlossen, unsere letzten MAX!-Komponenten gegen HM auszutauschen...
...damit würde u.U. auch io.Broker für uns funktionieren, denn der kann offenbar mehrere Instanzen gleichzeitig laufen lassen?!
Was meint Ihr?

Omega

Besonders interessant wäre es, wenn es eine dazu passende VCCU gibt.
Alleine aufgrund des VCCU-Konzepts mag ich keine CCU2 einbinden (nur 1 Gerät, Funkabdeckung nur z.T. im Haus, Probleme bei Ausfall, da kein anderes Gateway einspringen kann, Lastverteilung, Funklimit, ...).
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

zap

Zitat von: uholz am 29 November 2016, 16:53:22
FHEM wäre weiterhin unsere erste Wahl - aber inzwischen wurde beschlossen, unsere letzten MAX!-Komponenten gegen HM auszutauschen...
...damit würde u.U. auch io.Broker für uns funktionieren, denn der kann offenbar mehrere Instanzen gleichzeitig laufen lassen?!
Was meint Ihr?

Ich finde iobroker eine ziemlich coole Sache, insbesondere da JavaScript verwendet wird. Der kann wohl problemlos mehrere CCUs einbinden. Benötigt aber vermutlich eine ähnlich lange Einarbeitungszeit wie FHEM. Leider fehlen in der Adapterliste einige Dinge, sodass ich doch wieder Hand anlegen müsste und eigene Adapter schreiben müsste.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

chris1284

Zitat von: Omega am 29 November 2016, 17:29:33
(nur 1 Gerät, Funkabdeckung nur z.T. im Haus, Probleme bei Ausfall, da kein anderes Gateway einspringen kann, Lastverteilung, Funklimit, ...).

nicht nachvollziehbar...
-was bringt eine vccu mit x iODevs wenn das fhem drunter (welches bei den meisten auch nur 1 server und 1 instanz ist) ohne failover läuft.....
-die abdeckung der ccu2 ist besser als vorher der hmlan und hmcfg-usb bei mir
-Lastverteilung, Funklimit bekommst du nur mit mehreren iOs hin, diese kannst du an die ccu2 anbinden (hmlan, das neu langateway, wired gateway) und geräte nach bedarf darauf verteilen

-ein vorteil noch: es gibt aktuell und wahrscheinlich zukünftig auch kein hm ip ioDev

eine vccu mit mehreren ccus ist denke ich granicht machbar (im sinne von failover und lastverteilung durch fhem). die müssten ja alle die selbe hmid haben und man müsste die logik der ccu verändern denke ich, da ja jede ccu denken würd sie ist gemeint wenn ein aktor sich meldet. geräteverteilung ginge nur mit unterschiedlichen hmids, was wieder den failover behindert. ich denke das kann man vergessen.

die beste lösung dafür ist denke ich:
- man cloned eine "primere" und legt sie in den schrank. bei ausfall schrank auf, anschließen, backupeinspielen und in fhem ggf die hmccu-ip ändern.
- reichweite und funklastverteilung bekommt man durch zusätzliche lan gateways