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

[quickmic]

Welchen SW-Stand hast du eigentlich? 3.41.7 oder schon auf 3.41.11 upgedated? Wenn nein, versuch das bitte mal.

[neokalis]

Welchen SW-Stand hast du eigentlich? 3.41.7 oder schon auf 3.41.11 upgedated? Wenn nein, versuch das bitte mal.

Bin nach der Neuinstallation erst mal auf 3.41.7 geblieben. Hab dann gestern den Sprung auf 3.41.11 gemacht. Hat leider auch keine Besserung gebracht.

Schon mal ein Danke für Deine Unterstützung!

[ant]

Guten Abend,

danke für dein Script. Es hat mir ein paar Anhaltspunkte gegeben, die ich bei meiner eigenhändigen Einrichtung noch nicht wissen konnte. Die OCCU-Software zu installieren ist ja offensichtlich alles andere als straight-forward.

Ich habe dennoch weitere zwei Fragen, bei denen du mir vielleicht weiterhelfen kannst:
Du veränderst im Teil "#Patches and link fixes" deines scripts eine Menge tcl-Skripte in /www. Was ist der Sinn dieser Aktion? Ist die OCCU nicht in dem Zustand, in dem sie auf Github zur Verfügung steht, uneingeschränkt funktionsfähig?

Weiterhin habe ich mit dem rfd ein kleines Problem. Dieser beendet sich nach dem Starten umgehend wieder. Die Log-Meldung, die er dabei ausgibt, lautet "rfd: No BidCoS-Interface available". Ich möchte die OCCU jedoch zzt. HM-IP only betreiben. Entsprechend habe ich die InterfacesList.xml auch bereits angepasst. Wie kriege ich rfd nun ohne BidCos-Interface zum Laufen?

Lieben Gruß
ant

Edit:
Stimmt es, dass man den rfd gar nicht benötigt, wenn man ein HmIP-only setup betreiben möchte?

Der eigentliche Anstoß, dass ich versucht habe den rfd zum Laufen zu kriegen, ist die folgende Meldung, die jegliches Arbeiten auf der WebUI verhindert:

Code: Alles auswählen

One of the Homematic devices is not responding.

This may have various reasons:

    there is no network connection
    the power supply to the CCU is interrupted
    at least one device of the HomeMatic CCU is down

Please check the network connection and the power supply to the HomeMatic CCU. If necessary, restart your HomeMatic CCU.

Das einzig auffällige im hmserver.log sind die folgenden Meldungen:

Code: Alles auswählen

Nov 28 00:01:43 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-0] SYSTEM ADVICE: pre-conditions for deployment of LocalServerFirmwareUpdateInitialization still not met - check deployment configuration  (still unfulfilled: [connector.open]) 
Nov 28 00:01:43 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-1] SYSTEM ADVICE: pre-conditions for deployment of LegacyInitializion still not met - check deployment configuration  (still unfulfilled: [connector.open])

[quickmic]

@neokalis

Ich hoffe ich hab Zeit am Wochenende, dann schau ich mir das Problem mit dem HmIP-BWTH an.
Leider hab ich das Devices aber nicht hier. Kannst du mir bitte deine device-config schicken.
Die findest du unter: /etc/config/crRFD/data/ -> Seriennummer.dev Ich hoffe ich kann das Geraet damit reinsimulieren.

@ant

rfd: No BidCoS-Interface available

Wuerde ich im Moment ignorieren. Ich vermute der HMIPServer.jar erwartet immer eine Bidcos-Hardware. Ich wuesste nicht, wie man dem das abgewoehnen kann im Moment.

Stimmt es, dass man den rfd gar nicht benötigt, wenn man ein HmIP-only setup betreiben möchte?

Ja stimmt absolut. rfd ist nur fuer bidcos. Aus dem selben Grund kann man auch hs485dLoader rausschmeissen wenn man kein bidcos-wired verwendet.
Auch cuxd kann man entfernen, wenn man die Zusatzfunktionen nicht braucht, die cuxd anbietet.

Wegen den Patches bzw. Gundsaetzliche Infos...
Wenn man sich das occu git (https://github.com/eq-3/occu) anschaut merkt man, dass unter "X86_32_Debian_Wheezy" fast nur Binaries (und ein paar configs) liegen.
Der "WebUI" Teil mit den ganzen Scripts ist "allgemein" gehalten, also nicht speziell modifiziert fuer z.b. X86 oder auch Raspberry Pi usw.
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.

Weiters wird auf der CCU nicht direkt in die "echten" Verzeichnisse die CCU-spezifischen Files geschrieben sondern fast nur verlinkt.
z.b. die configs liegen bei meiner Installation echt unter /etc/config/, bei der CCU liegen die unter /usr/local/etc/config/ und werden auf /etc/config/ verlinkt.
Ganz viel liegt auch bei der CCU unter /opt/hm/ und wird dann ebenfalls an den Zielort weiterverlinkt.
Ich bin kein Freund von zuviel Links, das macht das ganze imho unuebersichtlich. Ich vermute aber dass es auf der CCU wird hardwarespezifische Gruende gibt, warum man sich dazu entschieden hat.


Das die hmserver.log ein paar Fehlermeldungen ausspuckt, ist bei mir auch so, und vermutlich normal. Zumindest habe ich keine Probleme feststellen koennen.
Ein paar Vermutungen dazu.
Schaut man sich das File /etc/config/crRFD.conf an, sieht man einen Eintrag "KeyServer.Gateway.URL=secgtw.homematic.com"
Ich denke das ist ein Cloudserver der bei meiner Installation nicht verwendet wird.
Das kann z.b. zu Fehlermeldungen fuehren, dass der Gateway nicht verfuegbar ist:
Vielleicht ist das der Fehler "IO Exception: Could not reinitialize interface: HmIP-RF_java. Remove interface from list"
Es kann auch sein, dass der Fehler von einem versuchtem Zugriff auf die original HMIP-Kommunikations-Hardware herruehrt.
Wie gesagt, alles Spekulation.
Wenn du selbst graben willst, empfehle ich dir die git von RaspberryMatic anzusehen. Jens Maus hat da sicher wesentlich mehr Arbeit reingesteckt als ich mit meiner Anleitung. Villeicht kann man einige Optimierungen noch uebernehmen.

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


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.

[kandamir]

Hallo quickmic,

Danke für das Installationsskript und den Support hier im Forum! Ich plane gerade eine Homematic Installation bei mir (klassische Homematic + Homematic wired, kein HMIP) und möchte die CCU gerne auf meinem (virtualisierten) x86 Server laufen lassen (ESXi 6.5 als Virtualisierungsplattform auf einem Intel Xeon basierten Server, falls das von Relevanz ist). Die Überlegung ist, in einer Debian VM mittels Deines Installationsskript die CCU zu installieren und das Lan-Gateway HM-LGW-O-TW-W-EU zu verwenden. Das hätte den Vorteil, dass ich das Gateway etwas abgesetzt zum Server und dafür zentral im Haus platzieren könnte. Ich habe zwar noch keine Homematic Hardware da, wollte aber die VM mit der CCU schon einmal installieren, um zu sehen, ob das klappt. In Abhängigkeit davon, ob alles klappt, hätte ich dann das Gateway bestellt und eingebunden - oder eben die normale CCU, wenn das nicht gut funktioniert. Frage: geht das so und ist diese Vorgehensweise aus Deiner Sicht sinnvoll? Ich will vermeiden, dass ich wochenlang rumbasteln muss, nicht zum Ziel komme und,dann ein für mich nicht mehr nutzbares Lan Gateway rumliegen haben. Ich war bei ersten Installationsversuchen auf diverse Probleme gestoßen und habe mir meine VM wohl kaputt konfiguriert und würde jetzt nochmal von vorne anfangen wollen...

Danke für eine kurze Rückmeldung!

[quickmic]

Hallo Kandamir

Der Ansatz ist absolut richtig finde ich. Bevor du irgendwas kaufst, probier zuerst die Installation aus.
Du solltest dir aber bereits bei der Installation im klaren sein, was du verwenden willst. Das wird abgefragt beim Installscript. Wenn du dir nicht sicher bist, musst du entwerder nachher manuell nachkonfigurieren, oder nochmal installieren.

Das Installscript hat ebenfalls ein paar kleinere Probleme wie hier berichtet wurde. Ich werde das am Wochenende ausbessern. Du kannst also das derzeitige Install-script verwenden und bei Problemen in diesem Thread nachlesen, oder abwarten.

Um aber keine falschen Erwartungen zu wecken...
Das Install-script Installiert dir zwar die CCU aber du musst trotzdem an manchen Stellen Hand anlegen bei Bedarf.
z.b. die IP Addressvergabe wird wie bereits erwaehnt vom Betriebssystem gehandelt. Das wird zwar bei der Installation von Debian eingestellt, aber wenn du nachher was aendern willst, muss du das selbst im Linux umbauen.
Plugins koennen nicht (sollten nicht) per WebUI installiert werden. 3 Plugins werden default mitinstalliert. xml-api, cuxd und email. Wenn du was anderes brauchst, kann das wieder basteln heissen.
Firmware updates der Gateways muessen auch manuell eingespielt werden. HMIP Geraete werden automatisch upgedatet. Bidcos Firmwareupdates bin ich mir nicht sicher. Ich hab nichts zum Updaten im Moment.
Wenn du mit sochen Dingen nicht leben kannst, dann lass es lieber sein.

Fuer Homematic-wired (bidcos) brauchst du einen zusaetzlichen Lan-GW. https://www.elv.at/homematic-rs485-gateway-1.html
Wenn du von Null startest, wurde ich mir auch echt ueberlegen nicht doch auf HMIP zu setzen. Ich wuerde das machen, aber bleibt jedem ueberlassen.

Ich selbst verwende bidcos-wireless und bidcos-wired sowie HMIP-Funk (nur fuer Testzwecke).
Ob und wie man HMIP-wired anbinden kann ist mir derzeit nicht bekannt. Es gibt ja noch nicht wirklich was dafuer.

Fazit, ausprobieren kannst ja mal ohne Komponenten. Kostet nichts und du bekommst einen Eindruck. Wenn du sagst es passt, kauf dir trotzem nicht gleich 100 Geraete. Teste mal mit dem Gateway und 1,2 Aktoren.
Uebrigends, wenn die Virtuelle CCU nicht zusagt, kannst du noch immer auf was anderes wechseln. Den gekauften Gateway kann man mit den anderen Loesung auch verwenden als Reichweitenverlaengerer.

Und noch was. Im Moment bin ich der Einzige der an x86 was veroeffentlicht. Wenn ich tot vom Schreibtisch falle, gibts auch nix mehr wenn kein anderer weiterbastelt.

deimos (piVCCU) arbeitet auch an einem Ansatz fuer x86 soweit ich weiss, ich glaube da ist aber noch nichts public und ich weiss auch nicht wieweit fortgeschritten das Projekt ist. Koennte aber auch sehr intressant werden.

[kandamir]

Hi quickmic,

Danke für die schnelle Rückmeldung! HMIP ist für mich eigentlich nicht wirklich eine Option, da ich zwar „smart“ mag, aber „cloud“ eher weniger. Das ist bei mir so eine Grundeinstellung... Dass ich das RS485 Lan Gateway brauche. Wusste ich, das kommt später, wenn das System vom Grundsatz her läuft.

Gut zu hören, dass ich erst einmal ohne HM Komponenten die CCU installieren kann, ich hatte da meine Zweifel, weil scheinbar nicht wirklich was laufen wollte. Mich hat auch verwirrt, dass in einem x86 Thread immer wieder von amd64 die Rede war...
Komischerweise Schlug bei mir schon die Oracle Java Installation fehl. Würde die Installation auch mit dem OpenJDK 8 funktionieren? Das war der Standard auf meinem Debian 9.4 (werde die VM aber mit Debian 9.6 neu aufsetzen).

Gegen das Hand anlegen habe ich grundsätzlich nix, ich bin schon regelmäßig auf der Shell unterwegs, auch wenn ich nicht DER Linux Crack bin. Wichtig ist zu wissen, wo ich Hand anlegen muss, denn das weiß ich jetzt natürlich noch nicht. Hinweise sind da gerne gesehen.

Und Gott bewahre, dass Du tot umfällst. Sollte das aber doch passieren, steht mir der Weg ja durchaus offen, auf eine Standard CCU zu wechseln.

Bidcos ist der Funkstandard, den Homematic verwendet, richtig?

Viele Grüße, Kandamir

[quickmic]

HMIP ist für mich eigentlich nicht wirklich eine Option, da ich zwar „smart“ mag, aber „cloud“ eher weniger.

HMIP laeuft offline via CCU. Cloud ist hier der Fall: https://www.elv.at/homematic-ip-access-point.html

in einem x86 Thread immer wieder von amd64 die Rede war..

Korrekt, Debian sollte gleich in amd64 installiert werden (64bit), nur die CCU Komponenten sind auf 32bit kompiliert.
Aber das macht nichts, 32bit Apps koennen ja auch unter einem 64bit OS laufen.
32Bit OS gibts ja kaum noch. Gibts das bei Windows 10 ueberhaupt? Egal.

Komischerweise Schlug bei mir schon die Oracle Java Installation fehl.

Das wurde schon reportet, und wurde auch schon der Fix hier im Thread publiziert. Ist aber noch nicht im Install-Script inkludiert. Ich denke das ist bei dir das selbe Problem.

Hi!

Vielen Dank für die Bereitstellung des Installationsskripts (2018-10-26 - ccu-install-script-mod5.txt)!

2 Dinge sind mir jedoch bei der Installation (Debian 9.6 / amd64) aufgefallen:

• - Problem bei der Installation von Java:

  Code: Alles auswählen

  apt-get install oracle-java11-installer -y

  führte zu dem Fehler

  Code: Alles auswählen

  E: There were unauthenticated packages and -y was used without --allow-unauthenticated

  der jedoch mit

  Code: Alles auswählen

  apt-get install oracle-java11-installer -y --allow-unauthenticated

  schnell umgangen werden konnte.
• - ein Kommentarzeichen in der rfd.conf wird falsch gesetzt:

  Code: Alles auswählen

  /bin/sed -i 's/AccessFile/\AccessFile#/g' /etc/config/rfd.conf

  müsste lauten

  Code: Alles auswählen

  /bin/sed -i 's/AccessFile/\#AccessFile/g' /etc/config/rfd.conf

Aber ansonsten alles top und easy!

Danke

Würde die Installation auch mit dem OpenJDK 8 funktionieren

Ziehmlich sicher ja.

Bidcos ist der Funkstandard, den Homematic verwendet, richtig?

Bidcos ist das Protokoll der "alten" Komponenten, das entweder per Funk oder Wired implementiert wird.
HMIP das gleiche. Protokoll fuer neue Komponenten fuer Funk, und Wired kommt noch.

[kandamir]

Danke, quickmic! Das war tatsächlich wieder erhellend. Frage zu 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? Dass HMIP auch ohne Cloud nutzbar ist, ist mir heute erst klar geworden, danke für den Tipp. Mir ist aber noch nicht ganz klar, welche Vorteile HMIP Komponenten gegenüber den klassischen bidcos Komponenten haben. HMIP scheinen teurer zu sein, wenn ich das halbwegs überblickt habe.
Und man kann HM und HMIP an einer CCU betreiben kann, aber keine Direktverknüpfungen zwischen HM und HMIP verwenden, korrekt? So richtig klar ist es mir noch nicht, warum ich HMIP verwenden sollte.

Naja, ich werde das WE erst einmal nutzen, die VM neu aufzusetzen und die CCU zu installieren.

[jp112sdl]

Hi,

ohne Gewähr auf Vollständigkeit:

Mir ist aber noch nicht ganz klar, welche Vorteile HMIP Komponenten gegenüber den klassischen bidcos Komponenten haben.

Der größte Vorteil (womit der Hersteller wirbt! ) ist die durchweg gesicherte(/verschlüsselte?) Funkübertragung.
Man hat hier das aus der Netzwerktechnik bekannte IPv6 Transportprotokoll verwendet. Daher die Bezeichnung HMIP
Meines Wissens fällt auch der (bei HM RF mit gesicherter Übertragung) notwendige AES Handshake weg - was weniger Funkverkehr bedeutet.
Weiterhin wird bei HmIP die Triple Burst Technologie sowie auch das 869MHz Band verwendet, auf dem bis zu 10% DC erlaubt sind.
Schau dir mal dieses Video an: Homematic User Treffen 2018: Staffelung Sendeverhalten

HMIP scheinen teurer zu sein, wenn ich das halbwegs überblickt habe.

Ich glaub der Schein trügt. HmIP ist annähernd gleich mit HM, wenn nicht sogar preiswerter (zB Bewegungsmelder innen).

Und man kann HM und HMIP an einer CCU betreiben kann, aber keine Direktverknüpfungen zwischen HM und HMIP verwenden, korrekt?

Ja das ist korrekt. Denn beide funken mit unterschiedlichen Protokollen.
Willst du mit einem HmIP Sender einen HM Aktor schalten, bleibt dir nur der Umweg über ein CCU-Programm.

So richtig klar ist es mir noch nicht, warum ich HMIP verwenden sollte.

Fakt ist wohl, dass es für HM keine Geräteneuentwicklungen mehr geben wird.
Verständlich -> warum sollte man ein neues, sichereres Funkprotokoll entwickeln und dann das alte noch weiterverwenden?

Für mich als Bastler steht HmIP jedoch nicht im Vordergrund.
Das klassische HM Protokoll kann mit einer Arduino Bibliothek auf eine Handvoll µC portiert werden, so dass man für sehr kleines Geld HM funkende Geräte selbst bauen kann.
Auch ist das "gute alte" Zeug sehr stabil und arbeitet fehlerfrei, wobei die Kinderkrankheiten von HmIP mittlerweile auch weitestgehend behoben sind.