Passendes Debian Paket für HM-MOD-RPI-PCB – Wo/Wann?

[carbolineum]

Ja Rainer,

das mit dem hmcon habe ich auch so verstanden.

Mein Ansatz hier war hier auch, den Aufbau einer "klassischen" CCU mit der mehr oder minder beliebten ReGa und eben dem neuen RPI-Dunkmodul zu beschreiben. Aber da hmcon ja auch den rfd benutzt, können die hmcon-User nun ja auch das neue Funkmodul verwenden.

Viele Grüße

Michael

[Homoran]

Wenn meins dann nächste Woche kommt, werde ich es mit hmcon mal in iobroker einbinden.

Da wird sich ja jetzt noch ne menge tun.

Gruß
Rainer

Gesendet von meinem LIFETAB_S785X mit Tapatalk

[jmaus]

Ok verstehe und freue mich schon darauf zu sehen wie du die anderen Komponenten des OCCU dann auf dem RPi zum laufen bekommst. Ggf. könnte man ja auch überlegen das hmcon install script umzubauen und um ne option zu erweitern damit man hier auch eine klassische CCU zum laufen bekommt (inkl. aller Komponenten und nicht zwingend auf hm-manager angewiesen ist. Wenn du deine schritte erklärt hast kann ich mir das gerne dann mal anschauen und ggf. integrieren.

Oder aber eq-3 liefert das versprochene .deb Paket einer komplettinstallation doch noch irgendwann nach? Aber wer weiss ob das jemals passieren wird...

[wowi]

Hallo,

die CCU2 Software für den Raspberry PI 2 befindet sich noch in der Entwicklung/QC. Sollte aber nächste Woche freigegeben werden.

Wer schon sich schon mal den den aktuellsten Build ansehen will, kann ein SD-Karten Image unter folgender URL herunterladen. Der Link steht nur bis zur Freigabe zur Verfügung.

http://update.homematic.com/firmware/do ... BERRYMATIC

Nach dem Download das Image entpacken und mit einem Tool wie Win32DiskImager auf eine SD-Karte kopieren.
Default Passwort für root auf der HDMI Console ist root (englische Tastatur).
Über die WebUI kann wie bei der CCU2 auch SSH freigeschaltet und ein Passwort für root vergeben werden (deutsche Tastatur).

Das Image ist analog zur CCU2 aufgebaut, basiert also auf einer durch Buildroot erstellten Linux-Umgebung (kein Debian etc.).
Einer der Vorteile ist, dass das Root Filesystem ReadOnly ist und somit bei Stromausfall das Filesystem nicht beschädigt werden kann.

Das Image beinhaltet aus lizenztechnischen Gründen kein Java. Wer ein Java unter /opt/jre installiert, kann auch den HMServer (Gruppenfunktion / Diagramme / Einstellungen) nutzen.
Wenn kein Jahr installiert ist, kommt ab und zu eine Meldung in der WebUI.

Wer ein CCU2 Backup einspielen will, sollte wie folgt vorgehen:

1.) Backup 1 auf der CCU2 erstellen und gut weglegen.
2.) Auf der CCU2 alle Addons, die Linux Programme beinhalten wie z.B. CUxD, deinstallieren. Die RaspberryMatic ist nicht binärkompatibel, von daher müssen die Addons erst durch die Entwickler angepasst werden.
3.) Neues Backup 2 auf der CCU2 erstellen
4.) Backup 2 auf RaspberryMatic einspielen. ACHTUNG: Ab jetzt dürfen CCU2 und RaspberryMatic nicht geleichzeitig eingeschaltet sein, da durch das Backup die RaspberryMatic die gleiche Funkadresse verwendet wie die CCU2.

ACHTUNG: Es gibt ein Problem mit der NTP Anfrage zum eQ-3 NTP Server. Das führt dazu, dass die Uhrzeit auf dem Raspi nicht stimmen kann. Zur Zeit wird nicht jede NTP Anfrage beantwortet.
Auf einem Raspi mit falscher Uhrzeit kann kein Backup eingespielt werden. Notfalls bitte den NTP Server in der WebUI ändern.

Ich werde diesen Thread verfolgen und Anregungen / Fehler an die Entwicklung / QC weiterreichen.

Debian Packages befinden sich mit anli zusammen in der Entwicklung.

Gruß Wolfgang

[jmaus]

die CCU2 Software für den Raspberry PI 2 befindet sich noch in der Entwicklung/QC. Sollte aber nächste Woche freigegeben werden.

Na das sind doch mal gute Nachrichten. Schön das ELV/eq-3 sich langsam aktiv hier im Forum engagiert!

Nach dem Download das Image entpacken und mit einem Tool wie Win32DiskImager auf eine SD-Karte kopieren.
Default Passwort für root auf der HDMI Console ist root (englische Tastatur).
Über die WebUI kann wie bei der CCU2 auch SSH freigeschaltet und ein Passwort für root vergeben werden (deutsche Tastatur).

Das Image ist analog zur CCU2 aufgebaut, basiert also auf einer durch Buildroot erstellten Linux-Umgebung (kein Debian etc.).

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.

Einer der Vorteile ist, dass das Root Filesystem ReadOnly ist und somit bei Stromausfall das Filesystem nicht beschädigt werden kann.

Nun, das wird wohl auch – ehrlich gesagt – der einzige Vorteil sein. Jedoch betreiben sicherlich viele hier die das OCCU ohnehin bereits freudig erwarten eine USV parallel zur CCU und somit ist auch dieser Vorteil dahin. Ein wichtiger Punkt für mich bzgl. des Modules war es eben dann ein vollwertiges Linux einsetzen zu können und dort dann auch Sachen wie iobroker und ccu.io installieren zu können ohne eben an den bekannten Limitationen der Linux-Umgebung der CCU anzustoßen.

Das Image beinhaltet aus lizenztechnischen Gründen kein Java. Wer ein Java unter /opt/jre installiert, kann auch den HMServer (Gruppenfunktion / Diagramme / Einstellungen) nutzen.
Wenn kein Jahr installiert ist, kommt ab und zu eine Meldung in der WebUI.

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?

ACHTUNG: Es gibt ein Problem mit der NTP Anfrage zum eQ-3 NTP Server. Das führt dazu, dass die Uhrzeit auf dem Raspi nicht stimmen kann. Zur Zeit wird nicht jede NTP Anfrage beantwortet.
Auf einem Raspi mit falscher Uhrzeit kann kein Backup eingespielt werden. Notfalls bitte den NTP Server in der WebUI ändern.

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!

Ich werde diesen Thread verfolgen und Anregungen / Fehler an die Entwicklung / QC weiterreichen.

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.

Debian Packages befinden sich nicht mit anli zusammen in der Entwicklung.

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.

[wowi]

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

[Homoran]

Hallo Wolfgang,
ich nehme an, da war ein typo bzgl. Der debian pakete in deinem vorigen post. Es sollte sicher "noch" und nicht "nicht" heissen

Gruß
Rainer

Gesendet von meinem LIFETAB_S785X mit Tapatalk

[Gluehwurm]

Oben steht zu lesen:

Debian Packages befinden sich mit anli zusammen in der Entwicklung

Nochmal ohne Zitat ... Anli und die Debian Packages sind zusammen in der Entwicklung

Vielleicht sollte man das TapaZeug mal überarbeiten oder weglassen

Eine USV gehört denke ich bei den wenigsten Raspi Usern zur Standardausstattung (ich habe eine

Ist denn eine Unterstützung dieses Moduls
http://www.elv.de/s-usv-pi-advanced.html
machbar bzw zu erwarten oder ist eine externe USV (so massiv, daß der Raspi nicht runterfahren muss ) besser?

Von der Erstellung irgendwelcher Pakete habe ich keine Ahnung, kann daher nicht wirklich helfen.

Gruß
Bruno

[PaulG4H]

Hallo wowi,

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.

Wie ich es ihnen schon Persönlich am Usertreffen in Kassel dieses Jahr gesagt habe ist ein Repository das nicht gepflegt wird und auch nicht Zeitnah die Änderungen der CCU Firmware erhält auch für die Community nicht wirklich Atraktiv vor allem wenn es alternativen gibt.

Und auch die Anzahl Installationen auf lxc Container Basis spielt bei der gesamten Anzahl CCU2 Installationen keine nennenswerte Rolle.

Dies könnte einfach durch Bereitstellung eines Raspbian Images mit Installierter LXCCU (ohne Firmware, diese wird entweder beim ersten Start oder über ein Web GUI heruntergeladen und integriert!) erzielt werden.

Schon mal mit den "Java" 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.

Noch ein Grund mehr warum ich Java NIE in die CCU2 Firmware Integriert hätte, entweder alles in Java oder alles in Python oder alles in C, aber bitte verschont uns von solchen misch Systemen wo es ein wahnsinniger Aufwand ist alle möglichen "side" effekte durch die verschiedenen Engines und vor allem auch die dadurch erhebliche System belastung wegen der zwei dienste auszuschließen.

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.

Wenn ich z.B. 100.000 CCU's verkaufe dann sollte ich es mir auch leisten können die dafür nötige Server Infrastruktur zu Finanzieren die mit dieser Last umgehen kann, warum Mietet ihr euch keine Server bei z.B. Hetzn** wo ihr diese Dienste in einem Skalierbares Cluster ausgelagert betreiben könnt?

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.

Inovation ist schwer möglich wenn wichtige Teile der CCU Firmware noch immer nicht veröffentlicht wurden. Gerade die REGA würde dringenst einer Überarbeitung bedürfen aber da kann die Community auch nicht helfen weil der Quellcode nicht verfügbar ist...

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.

Wenn ich mir vorstelle die OCCU installation in viele einzellne Pakete (rfd, rega, hs485, java..) zerteilt damit diese dann sowohl auf einem x86 NAS als auch einen ARM Odroid lauffähig sein soll...
Entschuldigt bitte wenn das jemals umgesetzt wird dann kommt Weihnachten in diesem Jahr zweimal!
Wer hat bitte dann die Zeit das zu Warten, Support anzubieten? Wenn ja nicht einmal die Änderungen und dann auch nur Teile der CCU Firmware zeitnah von EQ3 ins github gestellt werden sehe ich hier leider schwarz.

Paul

PS: Dies soll bitte niemanden in irgend einer Art Persönlich angreifen und falls ich jemanden mit meinen Aussagen zu nahe getreten bin so möge er mir verzeihen, dies war keine Absicht!

[jmaus]

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.

Das ist verständlich und nachvollziehbar. Allerdings denke solltet ihr auch bedenken, dass eine aktive developer community um euer OCCU nur entstehen kann wenn ihr dieses Projekt bei Github auch aktuell und aktiv haltet. Nur 1x im Jahr dort updates hochzupushen bringt leider den Nachgeschmack mit sich das das Projekt anscheinend nicht mehr aktiv betreut wird. Was spricht denn bitte dagegen das ihr das Github Projekt als euer Hauptentwicklungsbranch verwendet? Momentan sieht es so aus als ob ihr immer von Hand ein neues OCCU fertig machen müsst und dann das hochpusht. Wieso nehmt ihr das Github repo nicht zum Tagesgeschäft eurer Entwicklung? D.h. dort eben nicht nur die eurer Meinung nach stabilen Sachen hochladet nachdem das durch das QC, etc. gegangen ist. Sondern vielmehr auch unstable Sachen dort hochpusht wie sie eben jeden Tag bei der Entwicklung entstehen. Das würde viel mehr den Eindruck ergeben das man wirklich aktiv an der Entwicklung teilhaben kann.

Auch sind wohl einige etwas enttäuscht das nur gewisse Teile der CCU wirklich Open Source geworden sind. Große Teile wie der HMServer sind immer noch closed source und gerade dort hapert es ja in Sachen Stabilität und Funktionalität. Auch hier würde man sich wünschen das Ihr noch offener werdet und auch diese und andere Teile komplett im Quellcode offen legt. Nur dann kann man auch von der recht großen Community erwarten das dann auch wirklich aktiv pull requests erarbeitet werden die in eine stabilere CCU Version endet. Momentan hat man mitunter nur den Eindruck das das Wort "Open Source" hier nur ein Lippenbekenntnis ist und somit engagieren sich Entwickler wohl lieber in Feldern die Sie komplett überschauen können. Nur an den Installationskripten bzgl. OCCU rumbasteln zu können ist einfach zu wenig.

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...

In der Tat habe ich beruflich damit sehr viel zu tun und kann gewisse Argumente schon nachvollziehen. Allerdings betont ihr ja auch immer das Ihr offiziell das OCCU und das HM_MOD_RPI_PCB nicht supportet (zumindest ELV) und das ist ja auch ok. Es hat deshalb im Grunde auch niemand erwartet das ihr ne gesamte OCCU-Distribution pflegt und zwar in ner art und weise das das ganze auch 100% stabil läuft. Genau hier kann nämlich die HM-Developer-Community helfen. D.h. Ihr könntet z.b. die Entwicklung der Debian Pakete öffentlich machen (auch im OCCU Github) dann könnte man jetzt bereits daran teilhaben und Pull-requests schicken bevor ihr das einfach in die Runde als fertige Pakete werft. D.h. dann könnten verschiedene Leute mit verschiedensten Anwendungsfälle ihre Patches einreichen damit das ganze dann auch beim offiziellen Release auf den meisten System rundläuft.

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.

Das stimmt. für ARM hab ich mir das noch nicht angesehen. Aber auch hier könnte wieder die Community helfen und ggf. bei den Installationsskripten, etc. dafür sorgen das solch eine Java Installation zumindest semiautomatisch passiert oder eben besser/einfacher integriert wird. Ich hoffe du verstehst mich hier nicht falsch. Das Problem ist einfach das Ihr zwar das OCCU als "quasi"-OpenSource herausgegeben habt (wofür wir alle dankbar sind), allerdings findet nun anscheinend die Debian packages Entwicklung sowie die Entwicklung dieses neuen "Raspberry-Matic" wiederum closed source statt. Viel besser wäre ihr integriert das ganze in das OCCU SDK oder startet neue Github Projekte dafür das die Community JETZT schon in der frühen Phase mitentwickeln und mitgestalten kann. Am Schluss seid ihr ja trotzdem Herr dieses Paketes in dem Ihr eben Pull-Requests annehmen könnt aber eben nicht müsst. Das die beiden Entwicklungen jedoch gerade wieder closed erfolgt finde ich persönlich einfach traurig und nicht sehr schlau. Ihr als Unternehmen mit den doch sicherlich beschränkten Entwicklerressourcen hättet sicherlich mehr davon das ganze *wirklich* Open Source zu machen.

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.

Aber genau das ist es doch. Ihr pflegt das Repository anscheinend momentan parallel zu eurem eigenen Entwicklungssystem (vmtl. nutzt ihr da nichtmal selbst git) und genau das muss dann unweigerlich dazu führen das das Github repository niemals so aktuell sein kann wie der neueste offizielle release. Im Grunde wäre es so mitunter besser/schneller ihr würdet einfach immer Archive als "Snapshots" eures Entwicklungssystem anbieten. Momentan sieht man einfach das Github Projekt und denkt sich "Ok, soviel machen die gar nicht oder das was man potential zu OCCU beitragen könnte landet eh nicht im Hauptentwicklungspfad". Und für mich persönlich ist das schon auch mit ein Grund wieso ich mir das ganze (obwohl ich es fachlich könnte) nicht aktiver an OCCU beteilige. Momentan bin ich da einfach (wie sicherlich viele andere) in Wartestellung ob und wann da mal was im Github wirklich passiert und was da noch so alles ggf. offengelegt wird.

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.

Entschuldige, aber wo genau arbeitet ihr da denn dran? Im Github Projekt sehe ich die letzte Änderung vom 31. Mai?!? Ich sehe da keinerlei Anpassungen an das HM-MOD-RPI-PCB, noch das ihr in irgendeiner weise versucht Debian packages für die raspberian distribution zu erstellen. Es gibt auch keinerlei "unstable" branch in dem man solch eine Entwicklung normalerweise vornehmen würden und dann auf den master pusht. In der Tat habe ich schon ein paar Debian Pakete gebaut und könnte mir auch vorstellen mich mehr zu beteiligen. Aber (wie schon gesagt) solange man nicht wirklich sieht das dort zumindest 1-2x in der Woche etwas eingecheckt wird (am besten direkt von den Entwicklern und nicht von dem der nur das OCCU vml. manuell pflegt) ist es wirklich schwer sich direkt zu beteiligen weil man dann ja auch nicht mitbekommt wohin die Reise gehen soll. Bis vor deiner Erwähnung von "Raspberry-Matic" wusste zumindest ich noch nicht davon das ihr überhaupt an einem separaten Image arbeitet. Auch wusste man vor Nennung im ELVjournal nicht das Debian Pakete zumindest angemacht sind. All das hätte man (zumindest ich) jedoch gerne schon viel früher (eben durch regelmäßiges Monitoring eures OCCU Github repositories) mitbekommen.

Und bitte versteh mich nicht falsch. Dies alles sollen keine Angriffe sein sondern viel mehr als konstruktive Kritik gedacht sein auf deine Anmerkung das von der Community bisher nicht soviel gekommen ist...

Beste Grüße,

Jens