Das wiederum empfinde ich persönlich als Nachteil. Ich würde mir wirklich wünschen hier würden ordentliche .deb Pakete generiert werden die man in einer standard Raspberian version installieren kann ohne wiederum an den Limitationen der Linux-Umgebung der CCU2 anzuecken.
Debian Packages werden kommen, ich kann nur leider nicht sagen wann und ob für alle Teile des OCCU-SDKs. Als wir im April das Github Projekt aufgesetzt haben hatten wir gehofft, dass sich die Community mit Ihrem Know How an der Entwicklung beteiligt. Leide hat das bisher so gut wie gar nicht stattgefunden. Von daher braucht es mehr Zeit.
Nun, das wird wohl auch – ehrlich gesagt – der einzige Vorteil sein.
Hast du beruflich mit Softwareentwicklung, Pflege und Support zu tun? Dann wüsstest du, dass ein System, dass auf einen speziellen Anwendungsfall ausgelegt ist, viel einfache zu pflegen und zu supporten ist. Kein zweiter Webserver der evtl. auch auf Port 80 läuft, keine Firewall Konfiguration die Zugriffe von außen verhindert und und und...
Jedoch betreiben sicherlich viele hier die das OCCU ohnehin bereits freudig erwarten eine USV parallel zur CCU und somit ist auch dieser Vorteil dahin.
Also so viele werden es nicht sein, sonst hätten wir mehr Rückmeldungen zum OCCU bekommen. Und auch die Anzahl Installationen auf lxc Container Basis spielt bei der gesamten Anzahl CCU2 Installationen keine nennenswerte Rolle. Eine USV gehört denke ich bei den wenigsten Raspi Usern zur Standardausstattung (ich habe eine
).
Das sollte in der Tat sicherlich ohne Probleme möglich sein. Jedoch würde ich sagen gibt es inzwischen genug freie Java derivate die sicherlich mit den Funktionen kompatibel sein sollte die HMServer benötigt. Wieso nehmt ihr dann nicht einfach die?
Schon mal mit den alternativen beschäftigt? Ich schaue mir Alternativen seit vielen Jahren an. OpenJDK, cacao-vm, jamvm oder wie sie alle heißen. Keine kommt von der Performance auch nur annähernd an die Original JVM von Oracle für ARM Systeme ran. Die meisten haben für ARM nicht mal einen JIT Compiler.
Auch hier hätte ich den Vorschlag das dies mal generell geändert wird. Es gibt genug freie NTP pools (siehe pool.ntp.org) die man nehmen sollte. Hier immer nur den eq-3 NTP zu nehmen erscheint mir nicht der richtige bzw. beste Weg zu sein wie man eben genau daran sehen kann das der eq-3 nlp nicht immer erreichbar ist!
Als kommerzieller Anbieter darf man nicht ohne weiteres pool.ntp.org verwenden (You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance.) Als die CCU1 (und seitdem gibt es ntp.homematic.com) entwickelt wurde gab es keine andere Möglichkeit. Werde mal bei pool.ntp.org anfragen, ob wir eine eigene Zone bekommen können.
Nochmal vielen Dank dafür. Es wäre wirklich schön wenn ELV/eq-3 wirklich aktiver sich an der Entwicklungscommunity rund um CCU beteiligen könnte. Auch wäre es gut wenn das public Github repo regelmäßiger geupdatet werden könnte damit Innovationen der Community nicht immer hinterherhinken.
So viele innovative Entwicklungen sehe ich da nicht. Bisher benutzt nur hmcon von hobbyquaker das OCCU-SDK und kommerzielle Anbieter. Das Repository ist fast auf dem Stand von der 2.15.2 (Beta Version) also hinkt es auch nicht gravierend hinterher.
Hab ich das jetzt richtig verstanden? Es wird entgegen der Ankündigung im aktuellen ELVjournal doch KEINE Debian packages zu OCCU geben? Das wäre wirklich schade. Ich denke die wenigsten (die zumindest eigene Entwicklungen rund um OCCU machen wollen) wollen doch einfach eine CCU nur eben auf einem Raspberry - denn nicht nur die Hardware stellte mitunter immer eine Limitation der CCU2 dar, sondern auch die zu limitierte Linux Umgebung. Es wäre schöner ein gut gepflegtes und immer aktuelles Debian packages repository zu haben bei dem man OCCU inkl. aller Komponenten auch auf der standard raspberian distro installieren kann und dann mit wenigen manuellen schritten zum laufen bekommt.
Wie ich geschrieben habe werden die Debian Packages gerade entwickelt. Wenn du Know How darin hast, bist du gerne eingeladen daran mitzuarbeiten. Änderungen von Anderen werden schnell übernommen. Auch wenn es im github Projekt noch einige offene Issues gibt, Pull Request gibt es keine.
Jeder der Know How bei der Erstellung der Debian Packages einbringen kann ist herzlich willkommen, mit an der Umsetzung zu Arbeiten.
Wolfgang