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

[quickmic]

Oh, ich kenne aehnlich Screenshots von anderen Anwendern. Das hat bei denen auch nicht geklappt ueber das Fenster dass du gepostest hast.

Ist bei dir nach dem Reinkopieren des files in /firmware (und vielleicht restart) die Firmware ersichtlich wie bei mir?

[ant]

Nee, reinkopieren in den firmware Order + Neustart führt leider nicht dazu, dass dort etwas erscheint

[quickmic]

Ok, ich werde mal suchen ob ich was finden kann im Code...

[ant]

Der Grund war, dass der HMIPServer im falschen Ordner nach den Firmware-Updates geschaut hat.
In crRFD.conf war nämlich folgendes definiert:

Code: Alles auswählen

FirmwareUpdate.BG.OTAU.Home=/opt/hm/etc/config/firmware

Ich hatte die Updates jedoch nach /opt/hm/firmware gepackt, wo auch die anderen Updates sind.

Mit Firmware-File in /opt/hm/etc/config/firmware ging dann alles.

Die deutlich bessere Lösung ist jedoch folgendes:

Code: Alles auswählen

FirmwareUpdate.BG.OTAU.Home=/etc/config/firmware

Dann klappt auch das Uploaden der Firmware über das Webinterface, denn in diesen Ordner lädt dieses die Updates.

[quickmic]

Danke.
Bei mir war das schon korrekt, keine Ahnung ob ich das nachträglich gemacht hatte.
Das muss aus jeden Fall im Install-Script und im Update-Script automatisch umgebogen werden.
Ich schau mir das an.

[ant]

Hey,
ich habe heute gemäß deiner Anweisungen versucht den Stick zu updaten.

Leider klappt das nicht wie gewünscht:

Code: Alles auswählen

$ java -jar /opt/HmIP/hmip-copro-update.jar -p /dev/ttyUSB0 -f /opt/hm/firmware/HmIP-RFUSB/hmip_coprocessor_update-2.8.6.eq3 -o
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyUSB0
[INFO] SGTIN = 3014f5ac94000416fbxxxx
[INFO] Performing update with firmware file '/opt/hm/firmware/HmIP-RFUSB/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.4 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 ...
[ERROR] No update performed.
[INFO] Exiting update tool.

Auch andere Nutzer scheinen dieses Problem zu haben:
https://community.home-assistant.io/t/s ... rt/76818/4
viewtopic.php?f=56&t=47158

[quickmic]

Der Grund war, dass der HMIPServer im falschen Ordner nach den Firmware-Updates geschaut hat.
In crRFD.conf war nämlich folgendes definiert:

Code: Alles auswählen

FirmwareUpdate.BG.OTAU.Home=/opt/hm/etc/config/firmware

Ich hatte die Updates jedoch nach /opt/hm/firmware gepackt, wo auch die anderen Updates sind.

Mit Firmware-File in /opt/hm/etc/config/firmware ging dann alles.

Die deutlich bessere Lösung ist jedoch folgendes:

Code: Alles auswählen

FirmwareUpdate.BG.OTAU.Home=/etc/config/firmware

Dann klappt auch das Uploaden der Firmware über das Webinterface, denn in diesen Ordner lädt dieses die Updates.

Ich habe jetzt nochmal auf einer frischen VM das Install-script durchlaufen lassen:

die /etc/config/crRFD.conf hat folgenden Inhalt:

# USB HM/IP TRX Adapter Configuration
Adapter.1.Type=HMIP_CCU2
Adapter.1.Port=/dev/ttyS1000

Config.Dir=/etc/config/crRFD
Config.Include=hmip_user.conf

# Directory Configuration
Persistence.Home=/etc/config/crRFD/data
FirmwareUpdate.BG.OTAU.Home=/etc/config/firmware
FirmwareUpdate.BG.OTAU.divergent.device.type.definition.file=/opt/HmIP/crrfd.fwfix

# Legacy API Configuration
API.1.Type=XML-RPC
Legacy.Encoding=ISO-8859-1
Legacy.ResponseTimeout=20
Legacy.ReplacementURL=127.0.0.1
Legacy.Parameter.Definition.File=/opt/HmIP/legacy-parameter-definition.config
# Legacy.RemoveUnreachableClients=false
Legacy.AddressPrefix=3014F711A0
Legacy.SwitchTypeAndSubtype=true
Legacy.HandlersFilename=/var/LegacyService.handlers
Legacy.DiscardDutyCycleEvents=true
Legacy.SendUDPServiceMessages=true

# Miscellaneous Configuration
CyclicTimeout.TimerStartMaxDelay=90
CyclicTimeout.TimerCycleTime=600
Legacy.Parameter.ReplaceEnumValueWithOrdinal=true

### Configuration for Inclusion with key server (internet) or local key (offline)
KeyServer.Mode=KEYSERVER_LOCAL
KeyServer.Gateway.URL=secgtw.homematic.com
Vertx.WorkerPoolSize=5

Das wird eigentlich auch nur kopiert vom Git, und dort steht das auch bereits "korrekt" drin:
https://github.com/eq-3/occu/blob/maste ... crRFD.conf
"/etc/config/firmware" und das ist verlinkt auf /firmware

Kann das sein, dass es von einem frueheren Backup-Einspielen uebernommen wurde?

[ant]

@quickmic: Ja, diese Änderung lag vermutlich nicht in Verantwortung deines Scripts sondern bei mir.

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

Moin quickmic,

Ich habe noch einmal eine Frage: Dein Installationsscript für den Raspi auf Seite 1 - geht das von einem USB-Stick aus oder funktioniert das auch per GPIO angebundenem Funkmodul? Ich habe mir ja den Charly Bausatz gekauft (gestern eingetroffen und zusammengebaut ), würde die CCU aber trotzdem gerne auf meinem x86 Server kaufen lassen, d.h. der Raspi mit dem RPI-RF-MOD würde nur als Gateway dienen und nicht als CCU.

Was ich auch bisher noch nirgends gelesen habe, aber stark annehme: das RPI-RF-MOD wird zwar angegeben für den Einsatz mit einem Raspi 3, aber mit einem Raspi 2 B müsste das ja auch zusammenarbeiten, oder? Soweit ich das sehen konnte, sind die GPIO Buchsen ja Pin-kompatibel. Ich habe noch einen Raspi 2 B übrig und fände es schade, wenn der Raspi 3 nur herum idlen würde - da fällt mir Besseres ein.

[quickmic]

Eins gleich vorweg. Ich hab keinen RPI-RF-MOD aber bischen was weiss ich darueber.
Ich hab zufaellig gestern sowas Ahenliches mit einem anderen User per Remote gemacht.

Es gibt einen mod, wie man Raspberrymatic als Gateway konfigurieren kann.
https://homematic-guru.de/raspberrymati ... -einsetzen

ABER! Der gibt nur bidcos per Lan-GW frei. HMIP hat da einen anderen Ansatz, ich vermute darum gibts auch keine zu kaufen im Moment.
Und weil man HMIP nicht so einfach im Netzwerk verteilen kann, verfolge ich hier mit dem Script einen anderen Ansatz.
Ich verwende remserial was nichts weiter macht, als eine serielle Schnittstelle im Netzwerk zu verteilen. Hat also bis dahin garnichts mit HMIP zu tun.

Zur praktischen Anwendung. Der HMIP-Stick (nachdem man die kernelmodule geladen hat blabla..) verhaelt sich wie ein serielles Geraet.
Ich glaub du merkst schon was ich eigentlich mache. Ich leite also nur den HMIP-Stick (den Serial Port) per Netzwerk weiter, und binde den auf der CCU wieder ein.
Das Resultat ist dann, dass die CCU glaubt der HMIP-Stick ist direkt an die CCU angesteckt und alles klappt.

Was ich gestern gemacht habe war, Raspberrymatic als Gateway fuer Bidcos UND Hmip-Stick auf Raspberrymatic angesteckt.
Dann den Stick eben per Netzwerk weitergereicht.
Eins gleich vorweg falls du das machen willst, kannst du mein Raspi-Install-Script nicht einfach so verwenden.
Was ich beim Raspberrymatic sah ist, dass fast alle Ordner ro gemountet sind. Darum muss remserial anders installiert werden (Pfade umbiegen, remserial vorher wo anders kompilieren etc), aber es klappt.

Jetzt zu Theorie:
Es waere denke ich moeglich auch den HMIP-Teil des RPI-RF-MOD ueber das Netzwerk zu teilen, nur muss sich dann am besten der HMIP-Teil als Serial-Port ausgeben genau wie der Stick. Dann ist ein NW-share ohne Probleme moeglich, aber ich weiss nciht ob das so ohne Weiteres geht.

Zur Frage RPI2 vs RPI3. Ich denke auch das es kein Problem sein sollte, aber wissen tu ich das nicht.

Fuer Details zu Raspberrymatic musst Jens Maus fragen.