Eine CCU3, zwei Haushalte: praktikable Lösung?

[kekzmobile]

Hallo zusammen,

wir leben in einem Zweifamilienhaus und haben in einer Wohnung eine umfangreiche Homematic Installation, die zum Teil auch den Aussenbereich mit einbezieht.
Nun kommen in der anderen Wohnung immer mehr Homematic IP Geräte dazu, so dass es innerhalb der CCU, aber vor allem bei Nutzung von Alexa, zu Namenskonflikten und auch der Ansteuerung des verkehrten Geräts kommt.

Wir nutzen die EasySmartHome Lösung für Alexa, was auch ganz gut funktioniert.

Nun meine Frage:
Gibt es eine praktikable Möglichkeit innerhalb einer CCU eine Multiuser-Umgebung zu schaffen, bei denen manche Geräte nur in Alexa A und manche wiederum nur in Alexa B verfügbar gemacht werden?
Bisher habe ich es so gemacht, dass ich überflüssige Geräte manuell wieder aus der Alexa-App entferne. Es scheint aber so, dass in regelmäßigen Abständen nach neuen Geräten gesucht wird und der ganze Spaß wieder von vorn beginnt.
Mit steigender Anzahl an Geräten ist das nun nicht mehr praktikabel.

Ich würde ja eine zweite CCU installieren, daran soll es nicht scheitern. Das Problem sind hier bloß Geräte im Außenbereich, auf die von beiden Wohnungen zugegriffen werden soll. Ein Mehrfach-Anlernen ist ja meines Wissens nicht möglich.

Wie habt ihr das gelöst?
Ein iobroker läuft auf nem separaten Server. Wenn über diesen Umweg etwas denkbar wäre, wäre ich daran sehr interessiert.
CCU3 mit raspberrymatic

Grüße

[Xel66]

Wenn du ein gemeinsames Netzwerk hast oder eben eine VPN-Verbindung, dann könntest Du in einer CCU die Außengeräte verwalten und als virtuelle Geräte (z.B. via CUxD) abbilden und die Status per HTML-Kommunikation syncen lassen. Dann ist auch eine Ansteuerung von der anderen CCU möglich.

Gruß Xel66

[kekzmobile]

Das klingt interessant.
Ja, es ist ein gemeinsames LAN, wo jede Wohnung Zugriff auf dieselben VLANs hat.

Gibt es denn in CUxD ein virtuelles Pendant für alle Homematic/Homematic IP Geräte?
Also auch BWM oder Regensensor, der dann direkt-verknüpft oder in Programmen genutzt werden kann?

Die Bi-Direktionalität geht dann über HTML-Kommunikation verloren, richtig?
Also wenn ein Befehl verschütt geht, merkt es das CUxD-Gerät nicht...?

[Xel66]

Gibt es denn in CUxD ein virtuelles Pendant für alle Homematic/Homematic IP Geräte?

Nicht für jedes ein 1:1-Pendant, aber der größte Teil sollte sich abdecken lassen. Gegebenenfalls sehen die Icons der Geräte auch anders aus.

Also auch BWM oder Regensensor, der dann direkt-verknüpft oder in Programmen genutzt werden kann?

Bezüglich der Direktverknüpfung bist Du den gleichen Problemen unterworfen, wie bei protokollfremden Geräten (HM vs. HmIP). Die Zusammenarbeit mit Programmen ist natürlich gegeben.

Die Bi-Direktionalität geht dann über HTML-Kommunikation verloren, richtig?

Das kommt auf Deine Umsetzung an. Du musst einfach nur bei Statuswechsel eines Aktors mit einem separaten Programm dafür sorgen, dass der Status in der anderen CCU aktualisiert wird. Das könnte man auch mit Systemvariablen abbilden, aber die Abbildung per CUxD-Geräte ist komfortabler.

Also wenn ein Befehl verschütt geht, merkt es das CUxD-Gerät nicht...?

Auch das unterliegt Deiner Umsetzung. Es gilt das Gleiche, was ich gerade bezüglich der Bidirektionalität gerade geschrieben habe. Sowas wie Kommunikationsstörungsmeldungen gibt es dann nicht. Willst du so etwas ähnliches abbilden, musst Du das ebenfalls per Programm erledigen. Ich würde mir aber trotzdem eine zyklische Überwachung implementieren. Man könnte z.B. eine Systemvariable zyklisch per HTML-Befehl umschalten und dann mit einem Programm diese Umschaltung überwachen. Also eine Art Heartbeat.

Gruß Xel66

[kekzmobile]

Nicht für jedes ein 1:1-Pendant, aber der größte Teil sollte sich abdecken lassen. Gegebenenfalls sehen die Icons der Geräte auch anders aus.

Wie ließe sich denn z.B. ein Regensensor oder Temperatur-/Luftfeuchtesensor in CUxD abbilden?

Ich habe bisher nur sehr wenig mit CUxD gearbeitet, hauptsächlich um eine handvoll Shelly1-Aktoren zu schalten. Das ging über System mit Funktion Exec ganz gut. Die Shellies bieten hier auch eine Lösung der Rückmeldung zur Statusänderung.

[Xel66]

Wie ließe sich denn z.B. ein Regensensor oder Temperatur-/Luftfeuchtesensor in CUxD abbilden?

Als 31er Gerät lässt sich ein Wettersensor KS300 abbilden. Ich habe ein solches Gerät nicht bei mir in Verwendung. Ich gehe aber mal davon aus, dass die gewünschten Daten sich dort abbilden lassen, da das Vorbild ja über entsprechende Sensorik (Regenmenge, Thermo, Hygro- und Wind-Sensoren) verfügt.

Die Shellies bieten hier auch eine Lösung der Rückmeldung zur Statusänderung.

Die Abbildung von Geräten in der CCU würde ähnlich laufen. Analog zur Statusrückmeldung der Shellys auf der CCU kann die CCU mit dem virtuellen CUxD-Gerät die Status per HTML an die CCU zurückmelden (die Shellys machen das ja ähnlich). Das ist aber nur für Schaltaktoren, Dimmern u.ä. relevant, damit dieser Zustand auf beiden CCUs verfügbar ist. Eine Statusübermittlung von Wetterdaten oder von BWM und anderen Sensoren braucht ja nicht zurückgemeldet werden. Hier würden ja die eine Richtung CCU mit Realsensor an CCU mit virtuellem CUxD-Sensor ausreichen.

Gruß Xel66

[kekzmobile]

Ok danke Dir.

Dann werde ich das mal so testen.
Ich glaube für Regensensor und Lichtsensor wäre es sogar einfacher eine Systemvariable zu beschreiben.
Der Regensensor kennt nur zwei Zustände und der Lichtsensor ist einfach ne Zahl.

[kekzmobile]

Ich habe nun beide Zentralen in Betrieb und versuche gerade einen HM-Schaltaktor auf CCU A mittels CUxD auf CCU B zu schalten.
Dabei bin ich vorgegangen, wie ich es von den Shellies kenne:

Ein CUxD Gerät System(28) mit Funktion Exec anlegen.
Im ersten Kanal:
SWITCH|CMD_SHORT:

Code: Alles auswählen

/usr/local/addons/cuxd/curl -s http://user:pass@homematic-og.xxx.yyy:8181/x.exe?x=dom.GetObject('BidCos-RF.SERIENNUMMER:1.STATE').State(1)

SWITCH|CMD_LONG:

Code: Alles auswählen

/usr/local/addons/cuxd/curl -s http://user:pass@homematic-og.xxx.yyy:8181/x.exe?x=dom.GetObject('BidCos-RF.SERIENNUMMER:1.STATE').State(0)

Wenn ich die URL über den Browser aufrufe, funktioniert es auch prima.
Bloß das CUxD Gerät arbeitet so scheinbar nicht.
Müsste ich anstelle

Code: Alles auswählen

/usr/local/addons/cuxd/curl -s

eine andere Funktion nutzen?

[Xel66]

Die Pfadangabe ist nicht mehr notwendig. Und die Angelegenheit könnte auch ganz ohne CUxD-Geräte einfach per system.EXEC und curl-Aufruf erledigt werden.

Gruß Xel66

[kekzmobile]

Die Pfadangabe ist nicht mehr notwendig.

Der Effekt ist leider der selbe. Es wird nichts geschaltet. Zur Probe habe ich noch einmal versucht einen der Shellies zu schalten.

Code: Alles auswählen

/usr/local/addons/cuxd/curl -s http://192.168.xxx.yyy/relay/0?turn=off

Funktioniert mit als auch ohne Pfadangabe