-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Das gesamte Wiki ist mit hochauflösenden Bildern auf Github verfügbar.
Das Repo ist öffentlich auf Github zu finden.
Maximilian Burr + Cedric Becker
Eine Smarthome Bridge ermöglicht es, verschiedene Smarthome Systeme unterschiedlicher Hersteller durch Plugins anzubinden. Dies bedeutet, dass die Benutzer dieser Bridge die Freiheit haben, Geräte unterschiedlicher Marken und Modelle miteinander zu verbinden. Dadurch kann ein nahtloses Smarthome-Erlebnis geschaffen werden und es hilft, den Dschungel an am Markt erhätlichen Systemem etwas zu lichten. Die Smarthome Bridge bietet durch die Plugin Funktionalität eigene Möglichkeiten ein Frontend anzubinden. Dazu bietet die Bridge ein Interface an, was von anderen Programmteilen implementiert werden kann, um an die Bridge anzukoppeln.
Um die Smarthome Bridge auszuführen, kann einfach das Bridge Modul der Anwendung mit Maven gebaut und ausgeführt werden. Das Maven Package Goal erstellt automatisch eine ausführbare JAR Datei.
Das Minecraft Smarthome Plugin kann ebenfalls mit Maven gebaut werden, vorher müssen aber folgende Vorbedingungen erfüllt sein.
- Lauffähiger Minecraft Paper Server (Minecraft Version 1.19.3)
- Umgebungsvariable MC_PLUGINS_DIR muss auf den plugins Ordner des Minecraft Servers gesetzt sein.
Nachdem die Vorbedingungen erfüllt sind, kann mit mvn install das Projekt gebaut und die korrekte JAR Datei automatisch in den Plugins Ordner kopiert werden.
Die Anwendung wird in mehrere unabhängig lauffähige Teile getrennt. Die unabhängigen Module werden mittels eines Buildsystems unabhängig voneinander verwaltet. Dazu verwenden wir das Buildsystem Maven für Java.
Die Smarthome-Bridge verwaltet eine Konfiguration, kennt alle Geräte und übernimmt die Kommunikation und die Transformation der Nachrichten für die einzelnen Smarthome Systeme, die mit der Smarthome Bridge angesprochen werden.
Um die Funktionalität des Kerns der Smarthome-Bridge unabhängiger von Drittbibliotheken zu gestalten, wurde mithilfe der Clean Architecture eine Plugin Architektur mit einheitlicher Schnittstelle geschaffen.
Neue Features für die Bridge können somit als Plugin angebunden werden.
Im folgenden Klassendiagramm ist der Entwurf ersichtlich, den wir uns für die Bridge überlegt haben. Das Tool ist noch lange nicht fertig und braucht noch sehr viel Arbeit. Die grundlegenden Strukturen zur Anbindung sind jedoch bereits implementiert und in folgendem Diagramm ersichtlich. Im momentanen Zustand im Repository ist diese Struktur auch noch nicht komplett umgesetzt geschweige denn vollständig. Zu Beginn des Projektes war ich der Ansicht, es wäre sinnvoll, einzelne Plugins wie die Configuration oder den EventPublisher als feste Bestandteile des Kerns der Bridge zu sehen. Um das System jedoch komplett modular zu halten, wollte ich jedoch versuchen, alle Elemente lose an den Kern der Bridge zu koppeln.
Ein hochauflösendes Bild des Klassendiagramms ist im Wiki zu finden.
%%{init: {'theme':'forest'}}%%
classDiagram
Loader --> "1" Core : creates and injects plugins to core
Loader --> "1" Plugin1 : creates
Loader --> "1" Plugin2 : creates
Core ..|> ICore : implements
Core --> "0..n" IPlugin : communicates
Core ..|> ICoreFeatureProvider : implements
Core ..|> IAppState: implements
EventPublisher --|> IReceiver : sends Messages
EventPublisher ..|> ICoreFeature : implements
EventPublisher ..|> IPublisher : implements
EventReceiver ..|> IReceiver : implements
EventReceiver ..|> ICoreFeature :implements
ICoreFeature --> ICoreFeatureProvider : registers at
IAppState -- ApplicationState
Plugin1 ..|> IPlugin : implements
Plugin1 --> EventReceiver : creates
Plugin1 --> EventPublisher : creates
Plugin1 <-- ICoreFeatureProvider : getsFeatures
Plugin2 ..|> IPlugin : implements
Plugin2 --> Configuration : creates
Plugin2 <-- ICoreFeatureProvider : getsFeatures
Configuration ..|> IConfiguration : implements
Configuration ..|> ICoreFeature : implements
class Core{
+loadedPlugins
+pluginFactory
+applicationState : IAppState
}
class ICore{
<<interface>>
+run()
+getCore()
}
class IAppState{
<<interface>>
ApplicationState
+setState(ApplicationState state)
+getState() : ApplicationState
}
class ICoreFeature{
<<interface>>
+getName()
+execute()
}
class ICoreFeatureProvider{
<<interface>>
+registerFeature(ICoreFeature feature)
+unregisterFeature(ICoreFeature feature)
}
class ApplicationState{
<<enumeration>>
}
class IPlugin {
<<interface>>
+load()
}
class Loader {
+ICore core
}
class IPublisher {
+sendMessage(String message, IReceiver recipient)
}
class IReceiver {
+receive(String message)
}
Zunächst muss die folgende Aussage aus der Themenmitteilung berichtigt werden:
Für einen modifizierten Minecraft-Server (Spigot), der die Einbindung von Java-Plugins erlaubt, entwickeln wir ein Dummy-Plugin, das dessen API in eine REST-API übersetzt. Das Plugin, das an unser Kern-System angebunden ist, kommuniziert über diese REST-API mit dem Dummy-Plugin.
Minecraft ist kein Smarthome System. Unsere Smarthome Bridge allerdings auch nicht. Deshalb ist Code notwendig, der Minecraft zu einem Smarthome-System macht. Das erwähnte Dummy-Plugin wird damit ausgebaut zu diesem Smarthome-System. (Im Kapitel Clean Architecture wird beschrieben, wie das Smarthome-System wiederum ein Dummy-Plugin erhält, um die Abhängigkeit von Minecraft zu minimieren.)
Außerdem gibt es weiterhin das Plugin für unser Kern System, die Smarthome Bridge. Es soll über REST mit dem Minecraft-Smarthome-System kommunizieren.
Das Plugin für die Smarthome-Bridge und die Kommunikation über REST wurden in diesem Projekt nicht mehr umgesetzt. Das Minecraft-Smarthome jedoch wurde implementiert und befindet sich in einem nutzbaren Zustand (davon abgesehen, dass es, da es nicht mit der Smarthome Bridge kommunizieren, noch nicht sooo viel praktischen Nutzen hat).