Kann man FHEM auf Homematic CCU3 installieren?

Begonnen von supernova1963, 02 Dezember 2018, 10:50:02

Vorheriges Thema - Nächstes Thema

supernova1963

Für die Entscheidung zur Anschaffung einer CCU3:

Ist es möglich fhem auf der CCU3 zu installieren und läuft eine solche FHEM Installation einigermaßen performant?   

Vielen Dank,

Gernot

zap

#1
Theoretisch ja. Eigentlich müsste die Frage lauten: ,,Kann man Perl auf einer CCU3 installieren?"

Nun ist ja eine CCU3 auch nur ein Raspi, d.h. die Performance wird vergleichbar sein.

Allerdings sind sowohl die EQ3 Variante als auch RasperryMatic eigene Build-Roots, d.h. eigene, aus den Linux-Sourcen gebaute Ditributionen. Der erste Schritt ist also, Perl auf einer CCU3 aus den Sourcen zu bauen bzw. zu übersetzen. Da die CCU3 (vermutlich) keinen Paketmanager enthält, kommt zumindest noch CPAN mit dazu, um Module nachinstallieren zu können.

Um Perl übersetzen zu können, benötigst Du eine Entwicklungsumgebung auf der CCU, zB Gnu-C mit den Build Tools. Ob RasperryMatic die schon enthält, weiß ich nicht. Könnte man aber evtl. über die Git Seite von RasperryMatic in Erfahrung bringen.

So ist eben eins vom anderen abhängig => Dependency Hell.

So richtig Sinn macht der ganze Aufwand aber nicht. Am Ende hast Du mehr oder weniger das, was Du auch mit einem Standard FHEM Raspi mit piVCCU oder YAHM hast.

Update: Gerade mal nachgeschaut: auf einer Standard CCU3 ist weder Perl noch GNU-C installiert.

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

supernova1963

Vielen Dank @zap,

hatte es befürchtet, dass es zumindest "kompliziert" wird, wenn nicht sogar "unmöglich" ist.

Mein Antritt war, die vorhandene CCU2 durch die CCU3 zu ersetzen und als LAN Gateway zu nutzen, ohne eine weiteres 24/7 Geräte zu betreiben.

Gernot 

chris1284

Du kannst piVCCU nutzen https://github.com/alexreinert/piVCCU
dann hast du ein normales Debian mit fhem und allen Abhängigkeiten und eine virt. CCU .
Lediglich den Button und das RTC Modul sind dann ohne Funktion in der virt. CCU

Mathias R

Hallo,
hat jemand schon erfolgreich FHEM auf einer VCCU3 laufen?
Lässt sich damit auch problemlos Hue oder MQTT2 einbinden?
In der VCCU3 steckt ja wohl ein Raspi. Lässt sich auch das WLAN-Modul aktivieren?

Gruß, Mathias

MadMax-FHEM

#5
Zitat von: Mathias R am 10 Oktober 2022, 10:57:56
Hallo,
hat jemand schon erfolgreich FHEM auf einer VCCU3 laufen?
Lässt sich damit auch problemlos Hue oder MQTT2 einbinden?
In der VCCU3 steckt ja wohl ein Raspi. Lässt sich auch das WLAN-Modul aktivieren?

Gruß, Mathias

Warum umständlich, wenn es wie von chris1284 geschrieben auch einfach geht? ;)

Warum ein "proprietäres" System (ja: es ist ein PI aber mit speziellem Image) nehmen...
...wenn man einfach einen PI mit Standard-OS nehmen kann und daruaf dann (virtualisiert) eine/die CCU-SW installiert.

piVCCU oder debMatic.

Also in der Konstellation geht sicherlich: fhem, WLAN, mqtt2 und HUE (wie: deCONZ? zigbee2mqtt? auch auf dem selben PI oder extern?)

UND: warum einen 4 Jahre alten Thread aufwärmen?!
Da gab es doch bestimmt eine Meldung beim "Antworten"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

fiedel

Zitat von: MadMax-FHEM am 10 Oktober 2022, 11:16:28
UND: warum einen 4 Jahre alten Thread aufwärmen?!

Das würde ich hier niemandem ankreiden.
Das ist eine der guten Seiten an diesem Forum:
Keiner schließt irgendwelche Threads und man kann auch nach Jahren mal was nachfragen.

Gruß
Frank
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

MadMax-FHEM

Ja aber oft sind die Themen/Lösungen usw. (schwer) veraltet...
...und nach 4 Jahren hat sich die Welt (meist deutlich) weiter gedreht.

Das nicht schließen und noch was schreiben zu können ist eher "kurzfrisitg" gedacht.
Nicht umsonst bekommt man ja einen großen roten Hinweis, ob man tatsächlich noch hier antworten will ;)

Und: es werden (meist) nur die bereits im Thread vertretenen Personen aufmerksam...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Nun ja, hier ist es wenigstens dieselbe Fragestellung, und der Thread war auch nicht als "gelöst" markiert...

Wir erleben es in jüngerer Zeit aber recht häufig, dass (gefühlt) willkürlich irgendeine "alte Leiche" aufgewärmt wird, die thematisch in eine ähnliche Richtung zu gehen scheint, aber zu der dann kein wirklicher Bezug mehr zu erkennen ist, sobald man sich die Details etwas genauer anschaut. In diesen Fällen ist es für die "zwangsweisen Mitleser" (die alten thread-Teilnehmer) ärgerlich, wenn nochmal Benachrichtigungen oä. kommen, und für den (neuen) Fragenden auch nicht hilfreich, wenn schon ein [gelöst] vornedran steht.
Da fragt man sich dann m.E. zurecht, warum der TE denn nicht einen neuen Thread aufmacht, mitteilt, was er dazu "ähnliches" gefunden hat und dann vielleicht (!) noch einen Link in dem vermeintlich passenden Uralt-Thread platziert...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Mathias R

Zitat von: MadMax-FHEM am 10 Oktober 2022, 11:16:28
UND: warum einen 4 Jahre alten Thread aufwärmen?!

Weil es sich um exakt die gleiche Frage handelt und sich dazu noch keine konkrete Aussage, auch aus neuerer Zeit, finden lässt.

Bei der Eröffnung neuer Threads zum gleichen Thema kommt dann gern ein Link auf den alten Thread als Antwort, wäre hier aber nicht sinnvoll. Daher erschien mir hier die Antwort auf den alten Thread zweckmäßiger.

Zum Thema:
Diverse Themen nutzen die VCCU nur als Gateway um die Homematic-IP-Komponenten, teilweise auch die Homematic-Klassik-Komponenten anzubinden.
Vielleicht hat es ja in den Jahren auch mal jemand ausprobiert und hat FHEM direkt auf einer VCCU laufen.

Gruß, Mathias

Beta-User

Nun ja, vermutlich gibt es keine neuere Antwort, weil die alte afaik noch 100% gültig ist: die CCU3 (nicht: VCCU, das stammt aus einer anderen Welt) ist ein geschlossenes System, das sich nicht wirklich für die Installation weiterer Software eignet. Daher gibt es andere Projekte wie das bereits genannt piVCCU oder debmatic, um dieses Ziel zu erreichen.

Mehr Details sollten im angepinnten Thread zu HM-IP zu finden sein (https://forum.fhem.de/index.php/topic,116424.0.html ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Mathias R

Mein Fehler (bzw. Autokorrektur), denn ich meinte eine CCU3 (original) als Basis, denn es ist ja auch ein Raspi drin.

MfG Mathias

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

zap

Am ehesten könntest Du es schaffen, FHEM unter Rasperrymatic zum Laufen zu bekommen. Da müsstest Du halt das Git-Repository klonen und das "buildroot" um Perl und alle abhängigen Libraries ergänzen. Einfach wird das bestimmt nicht (ich sage nur "Abhängigkeits-Hölle").

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)