in einer Diskussion des Projekts RaspberryMatic auf GitHub hat sich eine interessante Idee entwickelt:
Alle Geräte einer CCU als virtuelle Geräte in einer zweiten CCU zur Verfügung stellen. Sie können dann wie reale Geräte auf der zweiten CCU bedient und beobachtet und sogar in Programmen verwendet werden, obwohl sie an einer anderen CCU angelernt sind. Technisch werden die virtuellen Geräte über einen neuen Schnittstellenprozess (wie beim CCU-Jack oder CUxD) an die ReGaHss angebunden.
Mit dem CCU-Jack kann diese Funktionalität rudimentär erbracht werden. Allerdings besitzt der CCU-Jack nicht für jedes reale Gerät eine exakte virtuelle Abbildung. Die virtuelle Nachbildung der realen Geräte ist sehr aufwändig.
Mir ist daher die Idee gekommen, dass der Weg über virtuelle Geräte eigentlich nicht nötig ist. Von den virtuellen Geräten geht man eine Ebene tiefer zum Schnittstellenprozess bzw. der XML-RPC-API. Es sollte möglich sein alle API-Aufrufe von einer CCU zu einer zweiten zu tunneln. Sicherlich müssten einige Funktionsparameter (z.B. für init) vor dem Tunneln manipuliert werden.
Noch ein paar weitere Gedanken:
- Gibt es Komplikationen, wenn sich zwei ReGaHss an einen Schnittstellenprozess hängen? Bestimmte API-Funktionen sollten besser nicht weitergeleitet werden (z.B. Gerät ablernen).
- Wieviele Multi-CCU-Anwender gibt es überhaupt? Ich kenne beispielsweise einige mit Zweit-CCUs in Ferienhäusern.
- Auch wenn jeder nur eine CCU besitzt, Freunde können sich Geräte teilen: z.B. eine Wetterstation.
Viele Grüße
Mathias
) finde ich hingegen gut.
