MAX! devices an homgear gateway

Deutsche Foren Konfiguration
21

Es scheint, dass im Container die SSL-settngs nicht OK sind (aus dem error log des UI):
Using configuration from /usr/lib/ssl/openssl.cnf
Can’t open ./demoCA/private/cakey.pem for reading, No such file or directory
140475340645760:error:02001002:system library:fopen:No such file or directory:…/crypto/bio/bss_file.c:74:fopen(’./demoCA/private/cakey.pem’,‘r’)
140475340645760:error:2006D080:BIO routines:BIO_new_file:no such file:…/crypto/bio/bss_file.c:81:
unable to load CA private key

im docker container is cakey.pem unter /ect/homegear/ca/private/ zu finden

22

Hi @clh27,

sorry fuer die “lange Leitung”, war kurz im Urlaub.
Hmok, im Docker hab ich das noch nie getestet … muss ich mir anschauen. Evtl. schaffe ich das noch vor Ostern, kann es aber nicht versprechen …

– Micha

23

Hi,

ich versuche auch gerade einen MAX culfw als homegear-gateway einzurichten.

Ich bin mittlerweile auf der aktuellen nightly - aber auch da kommt immer als Fehler

Module MAX: Error: Unsupported physical device type: homegeargateway

24

Kann denn keiner was dazu sagen?

25

Sorry, hatte deinen Post nicht gesehen. Da muss @sathya was zu sagen, ob der Max! schon im Gateway implementiert hat.

26

Hallo @teha75,

die prinzipielle Unterstützung ist drin, allerdings ungetestet. Es war auch noch ein kleiner Fehler drin, wodurch das Gateway im MAX!-Modul nicht geladen wurde. Dieser ist jetzt korrigiert.

Ich bitte um Rückmeldung, ob es klappt ;-).

Viele Grüße

Sathya

27

Hi,

ich wollte es gerade testen. Was ist die aktuelle Methode um homegear-gateway nightly zu installieren (auf raspbian)? Ich dachte ich hätte dazu ein “script” - finde dazu aber aktuell nix.

Viele Grüße

TeHa

28

Hier ist leider auch nur stable erklärt: https://www.dahlen.org/2019/05/homegear-gateway-mit-cc1101-und-raspberry-pi-3/

29

Hier ist mein Script um das Homegear-Gateway up-zu-daten:

#!/bin/sh
sudo systemctl stop homegear-gateway

sudo dpkg -r homegear-gateway libhomegear-base

rm homegear-gateway_current_raspbian_stretch_armhf.deb
rm libhomegear-base_current_raspbian_stretch_armhf.deb

wget https://downloads.homegear.eu/nightlies/homegear-gateway_current_raspbian_stretch_armhf.deb
wget https://downloads.homegear.eu/nightlies/libhomegear-base_current_raspbian_stretch_armhf.deb

sudo dpkg -i homegear-gateway_current_raspbian_stretch_armhf.deb libhomegear-base_current_raspbian_stretch_armhf.deb

sudo systemctl start homegear-gateway

Muss natürlich auf die entsprechende Architektur angepasst werden. Ich benutze stretch da mein Gateway auf OSMC läuft. Und das ist derzeit noch stretch-basiert. Läuft aber problemlos mit Homegear auf Buster zusammen.

3 Likes
30

Hallo,
ich hänge mich mal an diesen schon etwas älteren Thread dran, da ich gerade dabei bin eben diese Kombi zu testen.

Aktuell habe ich einen PI 3B mit einem CUL im Erdgeschoss und zusätzlich einen CUNx auf der 2. (beides ehemalige MaxCubes mit a-culfw). Damit steuere ich meine MAX! Fensterkontakte und Thermostate die so im Haus verteilt sind. Das funktioniert soweit auch ganz gut - bis auf die seltsame Mehrfachübertragung von Geräten, die am CUNx registriert sind. Das beeinträchtigt allerdings nicht die Funktionalität. Homegear läuft in der aktuellen Nightly vom 05.05.

Ziel des heutigen Tages sollte eigentlich sein, den CUNx durch einen Homegear Gateway mit angeschlossenem CUL zu ersetzten. Dafür habe ich meinen PI Zero W mit LAN Adapter hergenommen und dort den Gateway (mit dem obigen Script) installiert und konfiguriert. Soweit alles gut.
Dann kam das erste Problem: Homegear wollte den Gateway im Admin UI nicht automatisch finden. OK. Also habe ich ihn manuell über die Oberfläche hinzugefügt. Das hat geklappt. Der Gateway hatte einen grünen Haken. In beiden Instanzen (Homegear und Gateway) habe ich keinen Fehler gesehen. Anschließend habe ich einen MAX! Fensterkontakt vom ehemaligen CUNx zum Gateway über die Console “umgezogen”. Das hat auch funktioniert. Allerdings wurden jetzt keinerlei MQTT Meldungen mehr erzeugt bzw. blieben die Logs “stumm”.

Ich habe dann versucht den Homegear-Gateway nochmal manuell über die max.conf einzutragen. Der Gateway hatte dann auch wieder einen grünen Haken aber Nachrichten wurden keine an Homegear übermittelt. :frowning:

Kann es sein, dass die ganze Geschichte mit MAX! noch nicht (richtig) funktioniert? Habt Ihr das mit MAX! schon zum Laufen bekommen?

Ich habe übrigens dann am Ende des Tages den CUL wieder zum CUNx verwandelt und den Gateway zum Zigbee-Gateway geändert (mein nächstes Projekt :smiley: zur Ablösung von Zigbee2Mqtt ) und siehe da: Das Hinzufügen im Admin UI ging automatisch und Kommunikation sehe ich auch zwischen Homegear und Gateway. (Jetzt muss nur noch mein neuer C2531 kommen)
…also scheint es aus meiner Sicht vielleicht doch mit der “Familie” zusammenzuhängen.

VG vom,
Carsten

PS: Ich habe gerade gesehen, dass er mir folgenden Fehler (da ich den CUL abgezogen hatte) aus der “HomeMaticCulfw.cpp” schmeißt, obwohl ich in der gateway.conf als family = MaxCulfw eingetragen hatte. Im GIT sehe ich ja, dass es eine MaxCulfw.cpp gibt. Die müsste doch eigentlich “meckern”…mmhhh

Auszug aus der /var/log/homegear-gateway/homegear-gateway.err:
05/05/20 22:18:41.191 Error in file Families/HomeMaticCulfw.cpp line 109 in function void HomeMaticCulfw::start(): Couldn't open device "/dev/ttyACM0": No such file or directory

31

HomeMaticCulfw::start(): Couldn’t open device “/dev/ttyACM0”: No such file or directory

Sieht halt irgendwie so aus, als ob das Device weg wäre.

Da kann vielleicht @sathya was zu sagen.

32

Hi,
naja, das war nur so eine Feststellung am Rande. Ich hatte ja den MaxCube abgezogen. Mich hat nur der Inhalt der Fehlermeldung gewundert.

Läuft denn der Homgear-Gateway mit MAX! Komponenten bei jemandem schon? Dann würde ich weiter Zeit in die Fehleranalyse stecken. Vielleicht müssen die Komponenten neu am Gateway angelernt werden, als diese nur über die Shell umzuziehen? Sollte man denn etwas im Log des Gateways sehen, wenn ein mit dem Gateway verbundenes Gerät eine Statusänderung erfährt (z.B. Fenster auf/zu beim MAX! Fensterkontakt)?

VG vom,
Carsten

33

Habe persönlich leider noch gar kein Gateway im Einsatz, von daher @sathya - allein schon wegen der Implementierung auf dem Gateway.

34

Hallo @cnowden,

da wurde tatsächlich die falsche Familie aufgerufen. Der Fehler ist im nächsten Nightly behoben.

Vielen Dank und viele Grüße

Sathya

1 Like
35

Hi @sathya,
Sehr gut. Das kann ich dann auch gleich in der Kombination mit dem anderen Thema bzgl. 1 Gateway für 2 homegear Familien testen. Ein Gateway für Zigbee und Max! wäre klasse.
VG Carsten

36

Sehr gerne. Ich bin gespannt auf deine Rückmeldung!

37

Geht das nicht schon? Oder meinst du in Hardware?

Bei ZigBee wäre ein Gateway ein zweiter Coordinator, das macht nicht so viel Sinn. Also da eventuell eher einen Mesh-Router einsetzen.

https://shop.codm.de/bundles/zigbee/router/25/zigbee-long-range-router-bundle-9cm/2.5dbi

38

Ich hänge mich auch mal an den Thread.
Ich benötige eine Anleitung/Erklärung wie ich eine Homgear-Bridge auf’m Raspi mit CC1101 via SPI für max! ans laufen bekomme. In der 0.7er stable ist max! wohl nicht drin, jedenfalls hab ich es nicht in der config gesehen. Wenn ich die 0.8er nightly homegear installiere und anschließend apt homegear-bridge bekomme ich einen Abhängigkeitsfehler.
Vielleicht kann mal jemand einen Zweizeiler dazu schreiben…
Danke vorab,
Ingo

39

Meinst du homegear-gateway?

40

ja, genau. Sorry für die verspätete Rückmeldung, hab’s verpennt.
In dieser Anleitung wird ja die stable von Homegear nenutzt, aber auch nicht max! sondern HomeMatic.
Ich habe so probiert, aber im Konfigfile gibt es dann bei der stable (0.7) auch kein max! Konfigurationsabschnitt. Im Netz (wo ich das gelesen habe weiss ich nicht mehr) steht, man muss die nightly, wenn ich das richtig verstehe also die nightly 0.8) benutzen. Da verstehe ich jetzt nicht, wie ich bei der nightly 0.8 das homegear-gateway installiere.