Anleitung zur Installation der CCU auf einem x86 system (Part 2 inkl. HMIP)

[quickmic]

...HMIP: das würde auch mit dem Lan-Gateway HM-LGW-O-TW-W-EU funktionieren oder nur mit dem ELV Homematic IP ARR-Bausatz RF-USB-Stick?

HmIP nur mit dem Stick (der Stick kann kein bidcos)
HM-LGW-O-TW-W-EU brauchst fur bidcos (der kann kein HMIP)
Du kannst auch beides gleichzeitig verwenden, dann hast beide Optionen.
Die einzige Hardware die beides unterstuetzt ist die original CCU oder der Aufsatz fuer den Raspberry PI.

Eine Ergaenzung noch zu HMIP. Ein weiterer Vorteil ist, dass wired und Funkkomponenten direkt verknuepft werden koennen soweit ich weiss. Bei Bidcos geht das nur zwischen Funk oder nur zwischen Wired. Keine Mischung moeglich.

[quickmic]

Install script ist aktualisiert. Bekannte Fehler ausgebessert und Backup Einspielen verbessert.

[ChristianF]

Sorry, ich war ein paar Tage beruflich eingespannt.

@quickmic und @Christian
Hallo zusammen,
danke für die Anleitung.
In der Anleitung habe ich gelesen das Christan auf qnap getestet hat.
Gerne würde ich die iInstallationsart (Docker, qpkg...) kennen und welche genau.
Danke und Gruß
0Kay

Für QNAP empfehle ich dringend, die Virtualization Station zu nutzen und innerhalb einer VM ein blankes Debian Minimal zu installieren (ohne Grafik, nur CLI). Wenn ich richtig informiert bin, basiert QTS auf FreeBSD, was die Installation in einem Docker Container schwer macht. Zudem ist mir die Nähe zum OS der QNAP zu nah, da QTS regelmäßig aktualisiert wird und nach den Aktualisierungen regelmäßig Dinge innerhalb der Container nicht mehr funktionieren bin ich zu einer "echten" VM übergegangen.
Ich kann noch empfehlen, sich die VMWare Workstation zu installieren (es gibt eine kostenfreie Testversion) und damit die VM zu installieren und anschließend in die Virtualization Station zu importieren. Funktioniert hervorragend, man muss nur vor dem Umzug die BIOS basierten Device Names deaktivieren da sich sonst die Netzwerk Config zerschießt.

Die CCU VM kommt mit 512MB RAM aus und verursacht wenig bis gar keine CPU Last. Zudem wird das Snapshotting sehr einfach.

Bei Detailfragen, gern melden.

VG
Christian

[kandamir]

...HMIP: das würde auch mit dem Lan-Gateway HM-LGW-O-TW-W-EU funktionieren oder nur mit dem ELV Homematic IP ARR-Bausatz RF-USB-Stick?

HmIP nur mit dem Stick (der Stick kann kein bidcos)
HM-LGW-O-TW-W-EU brauchst fur bidcos (der kann kein HMIP)
Du kannst auch beides gleichzeitig verwenden, dann hast beide Optionen.
Die einzige Hardware die beides unterstuetzt ist die original CCU oder der Aufsatz fuer den Raspberry PI.

Eine Ergaenzung noch zu HMIP. Ein weiterer Vorteil ist, dass wired und Funkkomponenten direkt verknuepft werden koennen soweit ich weiss. Bei Bidcos geht das nur zwischen Funk oder nur zwischen Wired. Keine Mischung moeglich.

Danke, quickmic! Das hat erneut gut geholfen. Ich konnte jetzt die CCU-VM endlich erfolgreich installieren. Nachdem ich das Debian 9.6 amd64 Image genommen habe, lief auch die Installation mit Hilfe Deines Installationsskripts. Wichtig ist halt wirklich, dass man das amd64 Image verwendet. Dass ich darauf (mangels besserem Wissen) nicht geachtet hatte, hat mir den ersten Installationsversuch richtig verhagelt. Naja, nun bin ich schlauer.

Auch die Hinweise zur Kompatibilität der einzelnen Gateways/HF-Bausätze waren wichtig. Ich werde nun doch den Raspberry Charly Bausatz (das Starterset) von ELV nehmen. Damit habe ich alles zusammen und bin offen für bidcos und HMIP. Könnte mir dann zwar auch sparen, die CCU auf meinem Server zu installieren... Aber wo bliebe da der Spaß?

[ant]

Hallo quickmic,

Der WebUI-Teil ist also nachwievor fuer die CCU Hardware geschrieben was dazu fuehrt, dass gepatcht werden muss in manchen Bereichen.
Ich bin soweit wie moeglich am original-Code geblieben (auch ein bischen aus Zeitmaangel alles rauszupatchen.)
Wenn du z.b. die Patches vom Raspberry-Matic vergleichst (https://github.com/jens-maus/RaspberryM ... tches/occu), siehst du wieviel da modifiziert wurde.
An der Stelle vielen Dank an Jens Maus, ich hab mir da einige Anregungen geholt.

Ein Beispiel Zeitformat:
Die CCU (die Scripts auf der CCU) erwarten ein spezielles Zeitformat als Rueckgabewert: 2018-11-28T08:41:41+0100

Im Falle von /www/config/cp_time.cgi z.b. in der Zeile (original code):
"set iso8601_date [exec date -Iseconds]"
Variable iso8601_date wird also mit dem shell-command "date -Iseconds" geladen.
Wenn man das aber bei einer Debian-Installaion (auf der shell) ausfuehrt, kommt das raus "2018-11-28T08:45:48+01:00"
Format der Zeitzone, daher muss die Zeile gepatcht werden auf z.b. "set iso8601_date [exec date +%Y-%m-%dT%H:%M:%S%z]"
Dann kommt beim Ausfuehren von "date +%Y-%m-%dT%H:%M:%S%z" das erwartete Format wieder raus.

Das sind einfach Betriebssystem Eigenheiten und wie gesagt, das "WebUI" im git ist auf CCU Hardware programmiert.

Ein weiteres Beispiel sind Backups erstellen und Einspielen.
Da werden default vorher Partitionen als rw gemountet die auf der CCU normalerweise ro sind usw. Also alles spezieller CCU-Hardware-Kram was alles nicht benoetigt wird.

Ich verstehe jetzt, wozu die patches dienen. Danke für die Erläuterung. Der Link zu Jens Maus github-repo ist auch sehr hilfreich.
Allerdings verstehe ich nicht, wofür die vielen Links dienen:

Code: Alles auswählen

ln -s /www/tcl/eq3_old/session.tcl /www/session.tcl
rm /www/tools/session.tcl
ln -s /www/tcl/eq3_old/session.tcl /www/tools/session.tcl
rm /www/config/user.tcl
ln -s /www/tcl/eq3_old/user.tcl /www/config/user.tcl
rm /www/user.tcl
ln -s /www/tcl/eq3_old/user.tcl /www/user.tcl
rm /www/config/verifysid.cgi
ln -s /www/tcl/eq3_old/verifysid.cgi /www/config/verifysid.cgi
rm /www/verifysid.cgi
ln -s /www/tcl/eq3_old/verifysid.cgi /www/verifysid.cgi
rm /www/config/display/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/config/display/cgi.tcl
rm /www/config/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/config/cgi.tcl
rm /www/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/cgi.tcl
rm /www/tools/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/tools/cgi.tcl
rm /www/api/eq3/rega.tcl

...und so weiter. Bei mir funktioniert OCCU auch ohne diese Veränderungen. Kannst du mir erklären, warum Du das machst?

Zum Schluss, gerade weil ich recht wenig patche, sind auch manche Menupunkte ohne Funktion oder das WebUI schmiert gleich ab beim Draufklicken. z.b.
Firewall settings ohne Funktion, ssh ohne Funktion, Timezone ohne Funktion, IP settings ohne Funktion usw. Das muesste alles entfernt oder angepasst werden.
All diese Funktionen sind imho auch nur sinnvoll, wenn man fuer eine spezielle Hardware oder Software programmiert.
Im Falle meines Scripts sind IP Einstellungen per WebUI problematisch. z.b. Bei LXC werden die IPs am Host konfiguriert und nciht am Client sprich der emulierten CCU. Man koennte zwar IPs trotzdem umbiegen anfangen, aber das macht alles nur heasslich.
Meine Meining ist daher, solch elementaren Einstellungen wie oben beschreiben sollten im Falle einer emulierten CCU auf Betriebssystemebene bleiben, dort sind die gut aufgehoben

Das sehe ich genauso.

Ps:
Das Firmwareupdates des HMIP-USB-Sticks wird im Moment auch nicht automatisch durgefuehrt. Bei veralteter Firmware sollte man auch das in Betracht ziehen. Bei mir war die veraltet, aber nach dem Update hatte ich keinen Unterschied festgestellt. Bei Bedarf kann ich auch hier eine Anleitung schreiben...
Aktuell muesste sein 2.8.6 siehe Seite 1 irgendwo in der Mitte hab ich was dazu geschrieben.

Müsste das nicht mittels `hmip-copro-update.jar` gehen? Zumindest konnte ich mit dieser jar erfolgreich auslesen, dass auf meinem Stick derzeitig die 2.8.4 läuft. Wo kann man sich entsprechenden update files denn herunterladen?

Eine letzte Frage habe ich noch: Mir wird derzeit andauernd angezeigt, ich solle meine e-TRV-2 updaten. Die neue Firmware 2.0.2 habe ich bereits hochgeladen, und diese ist unter "Device Firmware" ersichtlich. Allerdings bietet mir die CCU unter "Action" nicht an, die Thermostate zu updaten. Wie mache ich das nun? Fehlt hier ggf. auch irgendein patch? Ich habe bei Jens Maus nichts gefunden, was dazu passt.

Lieben Gruß
ant

[quickmic]

Ich verstehe jetzt, wozu die patches dienen. Danke für die Erläuterung. Der Link zu Jens Maus github-repo ist auch sehr hilfreich.
Allerdings verstehe ich nicht, wofür die vielen Links dienen:

Code: Alles auswählen

ln -s /www/tcl/eq3_old/session.tcl /www/session.tcl
rm /www/tools/session.tcl
ln -s /www/tcl/eq3_old/session.tcl /www/tools/session.tcl
rm /www/config/user.tcl
ln -s /www/tcl/eq3_old/user.tcl /www/config/user.tcl
rm /www/user.tcl
ln -s /www/tcl/eq3_old/user.tcl /www/user.tcl
rm /www/config/verifysid.cgi
ln -s /www/tcl/eq3_old/verifysid.cgi /www/config/verifysid.cgi
rm /www/verifysid.cgi
ln -s /www/tcl/eq3_old/verifysid.cgi /www/verifysid.cgi
rm /www/config/display/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/config/display/cgi.tcl
rm /www/config/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/config/cgi.tcl
rm /www/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/cgi.tcl
rm /www/tools/cgi.tcl
ln -s /www/tcl/extern/cgi.tcl /www/tools/cgi.tcl
rm /www/api/eq3/rega.tcl

...und so weiter. Bei mir funktioniert OCCU auch ohne diese Veränderungen. Kannst du mir erklären, warum Du das machst?

Da werden Links umgebogen.
Schau dir die Originallinks vom occu-git an, z.b.:
ls /opt/occu-git/WebUI/www/tools/cgi.tcl -Al
"lrwxrwxrwx 1 root root 30 Dec 5 12:30 /opt/occu-git/WebUI/www/tools/cgi.tcl -> /opt/hm/www/tcl/extern/cgi.tcl"
Man sieht, dass der Originallink auf /opt/hm/www/tcl/extern/cgi.tcl zeigt. Das kommt daher, dass auf der original CCU das WebUI (und Vieles mehr) in /opt/hm/www/ installiert wird, und von dort dann das Ganze /opt/hm/www/ auf /www/ verlinkt wird (wenn ich das noch richtig im Kopf habe).
Auf der Original-CCU wird sehr viel herumverlinkt, was das Ganze imho unuebersichtlich macht. Vermutlich hat dieses Verfahren wieder mit der CCU-Hardware zu tun. Vermutlich ist /www/ schreibgeschuetzt und wird daher verlinkt? Aber egal, ich hab das jedenfalls nicht so gemacht.
Ich hab den www code auch direkt ins /www/ Verzeichnis kopiert.
Genau aus diesem Grund muessen die links umgeschrieben werden, sonnst zeigen die ins Leere.

Müsste das nicht mittels `hmip-copro-update.jar` gehen? Zumindest konnte ich mit dieser jar erfolgreich auslesen, dass auf meinem Stick derzeitig die 2.8.4 läuft. Wo kann man sich entsprechenden update files denn herunterladen?

Die liegen bereits im /firmware Ordner hier:
/firmware/HmIP-RFUSB/hmip_coprocessor_update.eq3
NUR:
Du kannst die Datei nicht flashen ohne Dateinamenaenderung. Der Dateinamen muss die Versionsnummer enthalten, oder zumindest irgendeine Versionsnummer. Frag mich bitte nicht wieso das nun wieder der Fall ist...
Du kannst ale folgendes versuchen:

cp /firmware/HmIP-RFUSB/hmip_coprocessor_update.eq3 /root/hmip_coprocessor_update-2.8.6.eq3
Dann updaten:
java -jar /opt/occu-git/HMserver/opt/HmIP/hmip-copro-update.jar -p /dev/ttyUSB0 -f /root/hmip_coprocessor_update-2.8.6.eq3

/dev/ttyUSB0 muss auf deinen Stick zeigen.

Es sollte ca sowas rasukommen:

java -jar /opt/occu-git/HMserver/opt/HmIP/hmip-copro-update.jar -p /dev/ttyUSB0 -f /root/hmip_coprocessor_update-2.8.6.eq3 -o
[DEBUG] Start bootloader ...
[DEBUG] Bootloader running
[DEBUG] Request bootloader version ...
[INFO] SGTIN = 3014f711a000041709adff28
[INFO] Performing update with firmware file '/root/hmip_coprocessor_update-2.8.6.eq3' ...
[DEBUG] Start application ...
[DEBUG] Application 'HMIP_TRX_App' running
[DEBUG] Request application version ...
[DEBUG] Request application version ...
[INFO] Updating coprocessor from version 2.8.6 to version 2.8.6
[DEBUG] Start bootloader ...
[DEBUG] Bootloader running
[INFO] Entering bootloader ...
[DEBUG] Start bootloader ...
[DEBUG] Bootloader running
[DEBUG] Request bootloader version ...
[INFO] Bootloader version: 1.0.12
[DEBUG] Send update frames ...
[INFO] Starting application ...
[DEBUG] Start application ...
[DEBUG] Application 'HMIP_TRX_App' running
[DEBUG] Request application version ...
[DEBUG] Request application version ...
[INFO] New application Version: 2.8.6

Falls du Probleme hast, mach vorher einen Werksreset mit -r Parameter.

Eine letzte Frage habe ich noch: Mir wird derzeit andauernd angezeigt, ich solle meine e-TRV-2 updaten. Die neue Firmware 2.0.2 habe ich bereits hochgeladen, und diese ist unter "Device Firmware" ersichtlich. Allerdings bietet mir die CCU unter "Action" nicht an, die Thermostate zu updaten. Wie mache ich das nun? Fehlt hier ggf. auch irgendein patch? Ich habe bei Jens Maus nichts gefunden, was dazu passt.

Wenn das unter Device-Firmware bereits ersichtlich ist, brauchst du nichts weiter zu tun wenn ich mich recht erinnere. Glaube da war kein Button, bin mir aber nichtmehr sicher, aber das dauert oft Stunden bis sich das automatisch updatet.
Ich hab bei mir eine HMIP-PSM upgedatet. Firmware eingespielt (auf die CCU kopiert) und dann am naechsten Morgen war die aktualisiert.

https://www.elv.at/topic/geraeteupdate- ... lange.html

[ant]

Hey,
da ich schon ca. eine Woche auf die updates warte, glaube ich nicht, dass es daran liegt

Tatsächlich steht in der Device firmware Übersicht in der Spalte "Firmware available on the CCU" nur "---" drin. Obwohl die Firmware unter "Device firmware" drinsteht.

Irgendwelche Ideen?

[quickmic]

Wenn da "Firmware available on the CCU" --- steht, wird auch nichts upgedatet. dann stimmt da was nicht. Ich schau mal wo das bei mir rumliegt...

[quickmic]

Fuer meinen HMIP-PSM habe ich die Firmware von eq3 runtergeladen -> HmIP-PSM_update_V2_6_2_170504.tar
Dann entpackt -> HmIP-PSM_update_V2_6_2_170504.efw
Dann in /firmware kopiert -> /firmware/HmIP-PSM_update_V2_6_2_170504.efw

Das wars, hast du vielleicht nicht entpackt?

[ant]

Also bei mir lief das so:
Hinweis, dass neue Firmware verfügbar wäre auf der OCCU Startseite:


Hochladen der Firmware über die CCU (nur .efw geht nicht, da u.a. das Changelog benötigt wird)

Firmware wird erfolgreich in der CCU Übersicht angezeigt:


Ich habe es jetzt auch einmal probiert, nur die .efw in den firmware Ordner zu kopieren. Allerdings wird mir das Update dann weder in der Firmware Übersicht angezeigt, noch angewandt.