Homegear Installation unter Debian Stretch

Hallo zusammen,

ich scheitere gerade daran Homegear unter Debian Stretch (also testing) zu installieren.

Das hinzufügen der Repos hat geklappt und apt findet die Pakete, allerdings kommt beim Versuch aptitude install homegear auszuführen:

Die folgenden NEUEN Pakete werden zusätzlich installiert:
enchant{a} homegear{b} hunspell-en-us{a} libcurl4-gnutls-dev{a}
libenchant1c2a{a} libgnutlsxx28{a} libhunspell-1.4-0{a} libopts25{a}
libqdbm14{a} ntp{a} p7zip{a} p7zip-full{a}
0 Pakete aktualisiert, 12 zusätzlich installiert, 0 werden entfernt und 0 nicht aktualisiert.
12,7 MB/13,1 MB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 63,4 MB zusätzlich belegt sein.
Die folgenden Pakete haben verletzte Abhängigkeiten:
homegear : Hängt ab von: libgnutls-deb0-28 (>= 3.3.0) ist aber nicht installationsfähig
Hängt ab von: libhomegear-base (= 0.6.7-1545) but it is not going to be installed
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:

 Beibehalten der folgenden Pakete in ihrer aktuellen Version:
  1. homegear [Nicht installiert]                
    

libhomegear-base lässt sich zwar separat installieren, aber dann ändert sich nur folgendes:

Die folgenden Pakete haben verletzte Abhängigkeiten:
homegear : Hängt ab von: libgnutls-deb0-28 (>= 3.3.0) ist aber nicht installationsfähig
Hängt ab von: libhomegear-base (= 0.6.7-1545) but 0.6.7-595 is installed

Mir ist klar, dass testing eben nicht stable ist, trotzdem die Frage:
Lässt sich das irgendwie beheben?

Hallo @Azimoth,

bisher gab es noch kein Paket für Debian Stretch. Ich habe mal die Voraussetzungen dafür geschaffen. Die Tage sollte es Pakete geben.

Viele Grüße

Sathya

Hallo @sathya,

ein verspätetes “Vielen Dank!” für deine Antwort. In meiner Ungeduld hatte ich schon angefangen Fhem auszuprobieren (was auch ohne Homegear ging). Soweit funktioniert es zwar, aber schön ist anders…
Ich habe jedenfalls nochmal mit dem Gedanken gespielt auf Home Assistant zu wechseln und daher mir nochmal Homegear angesehen (jetzt wo Stretch stable ist). Stimmt, es gibt ein Paket, aber jetzt stoße ich auf einen Konflikt:
Auf meinem Server ist libcurl4-openssl-dev installiert, Homegear braucht jedoch libcurl4-gnutls-dev, was sich ausschließt (kann es sein, dass libcurl4-gnutls-dev unter Ubuntu verbreiteter ist?).
Auf meine Frage im Debian IRC ob man eines einfach durch’s andere ersetzen kann, sagte man mir, dass (wenn an nicht gerade kompilieren will) *-dev Pakete eigentlich garnicht notwendig seien und weshalb ich das denn überhaupt bräuchte.

Es wäre schön, dazu mal die Meinung von jemandem zu hören, der sich in der Materie auskennt.

  1. Wieso überhaupt dieses -dev Paket?
  2. Sind Probleme zu erwarten, wenn ich das eine gegen das andere austausche? (Laut IRC sollte es passen, solange ich nichts kompilieren will… was ich vorerst nicht vorhabe…)

Vielen Dank (diesmal hab ich mehr Geduld :wink: )

Hallo @Azimoth,

die Info, dass das dev-Paket nicht benötigt wird, ist auch korrekt. Ich habe die Abhängigkeit jetzt durch libcurl3-gnutls ersetzt. Ab dem nächsten Nightly bzw. Stable wird es entsprechend ohne das dev-Paket funktionieren.

Solange “libcurl3-gnutls” installiert ist, sind vermutlich keine Probleme zu erwarten. Ich bin mir nicht 100%ig sicher, weil Homegear aktuell mit “-lcurl” und nicht mit “-lcurl-gnutls” gelinkt ist. Daher ist es möglich, dass in deinem System die OpenSSL-Variante verwendet würde. Letzteres könnte schon Probleme machen. Feststellen kannst du das durch

ldd /usr/bin/homegear | grep curl

Die Ausgabe sollte so ähnlich wie folgende aussehen:

libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f90e5aa2000)

Entscheidend ist, dass dort libcurl-gnutls.so.4 steht. Alternativ warte einfach auf das nächste Nightly und berichte, ob es damit klappt.

Viele Grüße

Sathya

Hallo @sathya,

vielen Dank für die rasche Antwort. Da es nicht eilt würde ich einfach auf das nächste Nightly warten. :wink:

Ich bin gespannt.

Viele Grüße,

Azimoth

Hallo @sathya,
ich hab die Installation nochmal mit apt versucht und es hat alles geklappt (glaube ich).

Ich hab noch keine Gelegenheit gehabt es zu testen, aber apt scheint zufrieden zu sein.

Was mir nur in’s Auge gefallen ist, war die Meldung:

chown: Zugriff auf '/etc/homegear/dh1024.pem' nicht möglich: Datei oder Verzeichnis nicht gefunden
chmod: Zugriff auf '/etc/homegear/dh1024.pem' nicht möglich: Datei oder Verzeichnis nicht gefunden

Ist das ein Zeichen, dass irgendwas irgendwo nicht geklappt hat? Oder ist das ohne Relevanz?

Jedenfalls: Vielen Dank für deine Arbeit!

Hallo @sathya,

ich hab’s mal getestet und bin auf folgendes Problem gestoße n:

systemctl start homegear 

führt zu einer Fehlermeldubng

systemctl status homegear

zeigt:

● homegear.service - Homegear
   Loaded: loaded (/lib/systemd/system/homegear.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-07-07 01:12:48 CEST; 5min ago
      CPU: 12ms

Jul 07 01:12:48 MyMachine systemd[1]: homegear.service: Unit entered failed state.
Jul 07 01:12:48 MyMachine systemd[1]: homegear.service: Failed with result 'exit-code'.
Jul 07 01:12:48 MyMachine systemd[1]: homegear.service: Service hold-off time over, scheduling restart.
Jul 07 01:12:48 MyMachine systemd[1]: Stopped Homegear.
Jul 07 01:12:48 MyMachine systemd[1]: homegear.service: Start request repeated too quickly.
Jul 07 01:12:48 MyMachine systemd[1]: Failed to start Homegear.
Jul 07 01:12:48 MyMachine systemd[1]: homegear.service: Unit entered failed state.
Jul 07 01:12:48 MyMachine systemd[1]: homegear.service: Failed with result 'exit-code'.

und

homegear -r

zeigt

homegear: error while loading shared libraries: libmariadbclient.so.18: cannot open shared object file: No such file or directory

Installiert hab ich das per aptitude, daher denke ich, dass die Konfiguration soweit passen sollte, oder?

Reicht das schon um zu erkennen wo der Fehler liegt?

Vielen Dank!

Hallo @Azimoth,

Das ist ein unabhängiges Problem. Die openssl-Anweisung muss für stretch leicht angepasst werden. Das ist im nächsten Nightly gefixed.

Installier das Paket libmariadbclient18, dann wird es funktionieren. Das fehlte noch in der Liste der Abhängigkeiten. Im nächsten Nightly ist es dort ebenfalls ergänzt.

Damit sollten wir es jetzt aber haben :-P.

Viele Grüße

Sathya

Hallo @sathya,

tatsache, es tut jetzt alles. Habe testweise ein Thermostat hinzugefügt und es zeigt zumindest die Soll und Ist Temperatur korrekt an und ich kann auch aus Home Assistant heraus die Soll Temperatur verändern. (Auch wenn es nur in Home Assistant auftaucht, wenn ich HASS als root starte… aber das ist wohl ein Thema für ein anderes Forum.)

Vielen Dank! (Ganz ehrlich: Da kann sich mancher Kundensupport mal ein Beispiel dran nehmen!)

Hey @Azimoth,

super! Könntest du vielleicht mal in nem eigenen Thread kurz zusammen tippen, wie du homegear an HASS bekommen hast?

Fänd ich super!

so long,
p

Hallo @pmayer,

vorneweg: Das ist mir nur gelungen, nachdem ich HASS mittels systemd als root gestartet habe. Einfach nur “docker run…” oder in einem virtualenv “hass” starten hat da nicht ausgereicht…

Mit systemd konnte ich “einfach” in der configuration.yaml (mit docker standardmäßig in /home/.homeassistant) ganz unten

homematic:
  hosts:
    homegear:
      ip: 127.0.0.1
      port: 2001

hinzufügen.

Ich bin mit viel googeln auf diese Seite gestoßen, daher die Inspiration. :wink:

Anschließend HASS neustarten (hab ich per systemctl restart gemacht) und dann tauchte das vorher mit homegear angelernte Thermostat auch schon in der HASS Übersicht auf.

Mehr als das hab ich aber noch nicht erreicht, da ich zunächst versuchen wollte ein reverse proxy mit Nginx hinzurkiegen, um HASS auch von außerhalb erreichen zu können.
Führt bislang aber leider wahlweise zu 404 oder “Home Assistant had trouble connecting to the server. TRY AGAIN”

Danke!

Mag aber VPN empfehlen. Nginx tut zwar was du möchtest, aber ich würde keine Dienste die zu Hause laufen und eventuell sicherheitsrelevant sind, nach aussem öffnen ohne passende Firewall.

Ich hab Nginx gesagt, es soll Benutzername und Passwort abfragen, bevor Zugriff auf die Seite gestattet wird (.htpasswd + SSL/TLS) und durch das reverse proxy läuft es alles über Port 443 (keine zusätzlichen offenen Ports). :wink:

zumindest, wenn es dann mal funktioniert…

Bin ich im Grunde bei dir. Das ist in jedem Fall besser als das was die Meisten machen (port 80, dyndns, mit default pw)…

So lange du dann deinen Proxy auf dem aktuellen Stand hältst, sollte da ok sein - VPN fühlt sich für mich irgendwie eben besser an :wink: Will ja auch nicht päpstlicher sein als der Papst.