Ich möchte gern ein Release für eine lauffähige Version von CCU-Software auf einem vorhandenen System, vorzugsweise ARM/Rapsberry Pi rausbringen.
ACHTUNG PreRelease
Installationsanleitung
Basis System vorbereiten
Code: Alles auswählen
wget -nv -O- https://raw.githubusercontent.com/leonsio/YAHM/master/yahm-init | bash -s quickinstall -
https://github.com/leonsio/YAHM
https://github.com/leonsio/YAHM/wiki
Bitte liest den Post durch und gebt mir als Antwort welche Lösung ihr besser findet. In der Umfrage bitte eine Stimme für Frage 1 und eine Stimme für Frage 2 abgeben
Ich habe mich in letzter Zeit sowohl mit OCCU als auch mit dem Ansatz was LXCCU verfolgt beschäftigt und beides grundliegend zum laufen bekommen, so dass ich daraus was für die Maße produzieren kann.
Eins vorweg, ich möchte NICHT CCU Software einfach auf dem vorhandenen Raspbian installieren, sondern die Software in einem LXC (Linux Container) installieren. Dies wäre auch das Hauptunterschied zu RaspberryMatic.
Warum LXC? Weil so die relativ komplexe Software der CCU "unabhängig" von dem Basis Betriebssystem läuft und unter eigener IP erreichbar ist, so als wäre es die CCU2 nur eben "virtuell". Weiterer theoretischer Vorteil wäre die Portabilität, man könnte quasi das Container zum Download anbieten, hierfür müssten aber noch einige Lizenzfragen geklärt werden (wäre aber theoretisch möglich).
Warum nicht Docker, weil ich a) für diese komplexe Anwendung keinen Vorteil in Docker sehe und b) je nach Art der Implementierung es garnicht oder nur sehr umständlich mit Docker geht.
------------
Zurück zum eigentlichen Thema, wie ich bereits geschrieben habe, habe ich bereits sowohl OCCU auf einem normalen Raspbian, als auch LXCCU auf jeweils aktuellen Jessie Release zum laufen bekommen, somit könnte ich theoretisch aus beiden ein Release machen. Anbei die Vor/Nachteile von beiden Lösungen:
1. Frage: Welche Software soll ich als Basis für den Release nehmen, aktuelles CCU2-Image (LXCCU) oder OCCU aus dem GIT
LXCCU (CCU2-Release)
+Geschlossenes, auf einander abgestimmtes Eco-System
+Meisten Addons sollten ohne Änderung funktionieren
+Spiegelt das jeweilige Release wieder
-Updates komplizierter-> Idealfall reinstall
-Fraglich wie lange CCU-SW noch in der Form bereitgestellt wird, oder ob eq-3 irgendwann komplett auf OCCU wechselt
-Alles oder Nix Lösung (in Hinblick auf verschiedene Komponenten von CCU z.B. Homematic IP)
-Nur unter ARM nutzbar
OCCU (Daten aus dem GIT)
+(Hoffentlich) Immer aktuell (aus dem git), bzw. Updates sind einfacher (git pull + Updateskript)
+Komponenten basiert (man könnte nur die benötigte Komponenten installieren, z.B. nur RFD)
+Intergration von anderen Tools bzw. GUI wie z.B. Hmcon einfacher (ein Release mit HmCon an Stelle von ReGaHss möglich)
-Konfigurations- bzw. Aufpassungsaufwand höher (für mich als Entwickler )
-Potentielle Probleme mit vorhandenen CCU-GUI Addons vorprogrammiert
----------
Das aktuelle LXCCU Release (Dank @Bullshit) basiert auf dem Debian Paket Manager (DEB), es wird einfach das Paket installiert, welches bei der Installation diverse "interne" Skripte ausführt und falls etwas nicht so ist, wie erwartet, die Installation abgebrochen wird (siehe Jessie Unterstützung). Dies mag für den handelsüblichen Noob auf den ersten Blick einfach erscheinen... aber sofern es da ein Problem gibt, weil das besagte Noob z.B. durch irgend eine andere Anleitung für eine andere Software z.B. an der Netzwerkkonfig rumgefummelt hat... tja dann gibt es haufenweise Post mit dem Betriff "Es geht nicht" hier im Forum
Somit würde ich persönlich einen anderen Ansatz verfolgen, und zwar in Form von mehreren Installation und Konfigurationsskripten.
Man müsste dann quasi nicht nur ein Schritt machen ("apt-get install lxccu") sondern mehrere Skripte aufrufen, hätte aber den Vorteil dass man a) Nur notwendige Schritte verwendet und b) sofern man an einer Stelle nicht weiter kommt, einem besser/gezielter geholfen werden kann.
(Bsp. aus eigener Erfahrung mit LXCCU, ich habe auf meinem Rpi mehre LXC Container laufen und dazu noch in verschiedenen VLANs, nachdem ich die LXCCU installiert habe, wurde meine ganze Netzwerkkonfig überschrieben und ich kam nicht mehr aufs Rpi drauf )
P.S. ein Skript mit "quick-config" welches alle Defaultparameter setzt und nur andere Skripte ausführt, wäre ebenfalls vorstellbar. Quasi "Installieren für Noobs".
P.P.S. Letztendlich sind im DEB Paket auch nur Skripte enthalten, nur hat ein User keinen Einfluß auf deren Ausführung.
2. Frage: Wie soll die Installation erfolgen, mit Hilfe von DEB Repository, oder in Form von Skripten aus dem GIT
DEB-basiert
+Ein Aufruf installiert alles
-Für jedes OS muss eigenes Repo bereitgestellt werden
-Fehler bei der Installation führen zum Abbruch, erschwert Fehlersuche
Skript-basiert
+Für jedes Betriebssystem nutzbar (klar ohne paar Anpassungen kommt man nicht aus)
+Skripts sowohl für Profis als auch für Noobs möglich (Ich versuche auf Usability zu achten)
+Je Skript für verschiedene Schritte (LXC Installation, LXC Netzwerk, CCU2/OCCU Installation (Auswahl Module)....)
----------
Bitte je eine Stimme für Frage 1. und 2. Ihr habt insgesamt 2 Stimmen.
Auf euren Feedback bin ich gespannt.
Grüß
Leo
P.S. Aktuell funktioniert Homematic-IP sowohl unter OCCU als auch unter LXCCU Ansatz nicht. Für Hm-IP muss ein Kernel-Modul kompiliert werden, was an sich kein großer Akt wäre, dieser lässt sich vorerst nicht unter dem aktuellen Raspbian Kernel zum Laufen bringen (oder ich bin zu blöd für, schließe ich nicht aus ). Somit kommen wir zur Frage 3: Release ohne HmIP rausbringen, oder auf funktionsfähige Homematic-IP Lösung warten? Ich würde jetzt ein Release rausbringen wollen und bei Bedarf/Erfolg die Funktionalität nachreichen, man müsste aber eventuell mit einer Meldung in der GUI, dass Homematic-IP nicht funktioniert leben.