[Homegear-Gateway] Ein Gateway / mehrere Geräte-Familien (BidCos, Zigbee)

Ok, wie soll man aber dann getrennte Zellen aufbauen, zwischen denen man keine ZigBee-Verbindungen aufbauen kann, da es von der Reichweite nicht reicht und man dazwischen keine Devices setzen kann, die als „Repeater“ dienen könnten.

Bereits ein Stockwerk darüber oder darunter (fremde Wohnungen) ist meinen Test zufolge aufgrund der dicht armierten Stahlbetondecken nahezu kein Empfang mehr und ich müsste 2 Stockwerke (1.OG und EG) überbrücken in denen ich keine Devices setzen kann.

Gerne lasse ich mich eines besseren Belehren, aber aktuell sehe ich keine sinnvolle Alternative. Aufgrund der getrennten Nutzungsdomänen (Wohnung / Kellerbüro), zwischen denen eigentlich keine Interaktion zu erwarten ist, sehe ich auch keinen technischen Nachteile. Aber ich muss auch zugestehen, das ich mich bisher nicht mit den technischen Besonderheiten von ZigBee beschäftigt hab.

Vielleicht kann mir jemand die Argumente nennen, die gegen getrennte Mesh-Netze im allgemeinen sprechen, und ob diese in den skizzierten Anwendungszweck relevant sind.

Aber um ZigBee im speziellen ging es bei meinem Post nicht wirklich. Mehr um die Verwendung von Docker für den Betrieb mehrerer Gateway-Instanzen auf einer Hardware um Multi-Protokoll HG-GWs zu realisieren und den Vor- und evtl. Nachteilen die dieser Ansatz hätte.

Gruß Andreas

1 Like

Ja, genau für so etwas macht das Sinn. Bei mir ist das Szenario, dass in der 2. Etage Homegear und im Keller ein Homegear-Gateway läuft. Auf dem Homegear Pi4 läuft auch noch Zigbee2MQTT. Ich wollte dann Zigbee langsam nach Homegear (über das Gateway im Keller) migrieren. Einen zweiten Koordinator am Pi4 zu betrieben war mir zu heikel, das führt mit Sicherheit zu Problemen.

Ich habe es damals nicht hingekriegt, dass sich Homegear mit dem zweiten Gateway auf dem Gateway-Pi verbunden hat. :frowning:
Dann habe ich es nicht mehr verfolgt.

Der Nachteil, bei mehreren Zigbee-Gateways, ist dass man nicht ein einzelnes Gateway in den Pairing-Modus versetzen kann, sondern nur die gesamte Familie, so dass es möglich ist, dass sich das neue Gerät mit dem “falschen” Gateway verbinden kann.

Es spricht meiner Ansicht nach theoretisch nichts gegen die Verwendung von Docker, ich habe nur überhaupt keine Erfahrung damit. Wenn die Trennung im IP-Stack funktioniert, wovon ich ausgehe, sollte es besser gehen als mit meiner Lösung auf Service-Ebene, bei der ich die Ports umleiten musste.

1 Like

Hab es gerade noch einmal getestet.

Mittlerweile gibt es eine Fehlermeldung auf dem Gateway:

11/28/20 22:24:07.292 Error in file RpcServer.cpp line 267 in function BaseLib::PVariable RpcServer::configure(BaseLib::PArray&): Could not open file.

Und folgenden Output bei Konfiguration des Gateways:

PHP Fatal error:  Uncaught Homegear\HomegearException: Unknown application error. See log for more details. in /var/lib/homegear/scripts/inline.php:7
Stack trace:
#0 /var/lib/homegear/scripts/inline.php(7): Homegear\Homegear::configureGateway('pi3', 2118, '-----BEGIN CERT...', 'Certificate:\n  ...', '-----BEGIN RSA ...', 'HeTgvbFTeJ4ELpX...')
#1 {main}
  thrown in /var/lib/homegear/scripts/inline.php on line 7

Leider gibt es das Script nicht, ist wahrscheinlich etwas temporäres. Und auch im Log gibt es keine Details.

ConBee does not work with the zigbee module. Only TI zstack 3.0 chips work. cc2538 is recommended, but cc2530 works, too.

Hi @Adrian,

thank you very much for your answer, I have already noticed that in the meantime. Unfortunately I had already bought this stick when I realized that it is not supported by homegear. So at the moment I’m using ZigBee2MQTT to use this stick for the first time.

My plan is to build my own interfaces based on TI CC2538. (Electronic engineering was part of my studies and is still one of my hobbies)

@pmayer wrote that you explained him why multiple coordinators in a system make no sense. But I think that in my use case there is no alternative.

The scenario is as follows:
I live in a high-rise building with 7 upper floors + first floor + basement + underground parking beside the main building. In this building I have a condominium on the 2nd floor and an additional room with 24 square meters in the basement, which I use as an office. Both are connected by fiber optic cable. My parents had a additional condominium in the 5th upper floor and my wife’s car and my car and my parents car, too, are parking usually in the underground parking. Both buildings are made of densely reinforced concrete, so that after only one ceiling almost no signal can be received. Between the apartment and the basement there are two other apartments to which I have no access to.

My plan was to set up separate mesh networks in the apartment as well as in the basement, both with their own homegear-gateway with ZigBee interface. Maybe an additional one in the underground parking or at my parents condominium later. Is there anything to be said against this from technical perspective?

Regards,
Andreas

1 Like

:smiley:

Hi,

You can use multiple coordinators with homegear, a module allows more than one interface.
You can connect them either directly to homegear (that is, as ‘serial’) or using gateways. The only issue that could exist with such a setup is that all interfaces are put in pairing mode. As far as you keep the coordinators far away from each other, that shouldn’t be much of a problem, if you keep the pairing device close to the coordinator you want to pair with.
Otherwise you may want to temporarily disable the other interfaces.

2 Likes

Juchu!

Mittlerweile habe ich es geschafft. Es war wohl etwas mit dem Zertifikatspeicher des zweiten Gateways nicht in Ordnung.

1 Like

Hi Adrian

thank you for the fast response. This confirms my assumption. I already knew about the fact that pairing is always activated on all gateways of the module. But this is not a problem for my use case, as you say.

Greeting Andreas

Hi Job,

Glückwunsch. Ich nehme an, du hast es als mehrere Services realisiert.

Zu deiner Anmerkung zu Docker:
Docker hat Vor- aber auch Nachteile. Prinzipiell verwendet Docker als Standard ein internes Netz (meist mit 172er IP-Adressen) das mit einer Art NAT auf die IP-Adresse des Docker-Host übersetzt wird. Man kann dann ähnlich dem Port-Forwarding bestimmte Ports des Host an bestimmte Ports des Containers weiterleiten. Alternativ kann man einem Container aber auch eine MAC-Adresse verpassen und diesen in das normale Netz hängen. Dann bekommt er vom DHCP eine eigene IP (wie eine VM bei der Virtualisierung).

Als ich mit Docker angefangen habe, hatte ich meinen ersten Container (fertiges Image) innerhalb von Minuten am Laufen. Bei meinen ersten Versuchen mit Homegear als Container waren es mit den USB-Interfaces und dem einen Service der die NAT in den Standard-Einstellungen nicht so super findet ein paar Stunden länger. Gerade die Anbindung an die CCU war bisschen problematisch, hier musste man an der HG-Config bisschen was anpassen. Auch die USB-Devices in den Container zu bekommen bedurfte ein bisschen Recherche. Aber ansonsten war es wirklich mit Backup des bestehenden HG, kopieren der HG-Ordner in die Container-Volumes, deployen des fertigen Docker-Images und Restore des Backups im Container-HG getan.

Mit WebGUIs wie Portainer und Co ist das Management der Container recht komfortabel.

Wenn du Interesse an dem Thema hast, können wir hierzu gerne einen getrennten Thread aufmachen und darüber zu sprechen. Das passt ja nicht so ganz in diesen Thread hier.

Gruß Andreas

1 Like

Hi Andreas,

Danke. Ja, genau. Hier mal die kurze Skizze, was ich gemacht habe:

  • Konfigurationsvereichnis kopiert (/etc/homegear-gateway => /etc/homegear-gateway-zigbee)
  • Datenverzeichnis (Zertifikatsspeicher) kopiert (/var/lib/homegear-gateway => /var/lib/homegear-gateway-zigbee)
  • Ports und Pfade in neuer Konfiguration angepasst (2017->2117 und 2018->2118)
  • Servicekonfiguration erstellt (wie homegear-gateway, nur verweist auf das neue Konfigurationsverzeichnis)
  • richtige Zertifikate unter richtigem Namen in die richtigen Ordner gelegt.

Ich bin sehr an der Docker-Variante interessiert, Docker interessiert mich schon lange. Ich hatte nur kein Szenario bei dem es meiner Ansicht nach Sinn machte das damit zu lösen.

Viele Grüße

Joachim

1 Like

Hallo zusammen,

kleiner Hinweise zu Docker: ich wollte es erst auch so realisieren, hab es allerdings (ggf. auch meiner mangelnden Docker-Kenntnisse geschuldet) nicht hinbekommen, das SSDP-Discover fuer die unterschiedlichen Gateway-Container abzubilden.

Mit lxd/lxc hat das dann funktioniert. Aber nach @job’s Idee den Dienst einfach mehrfach mit separaten Config-Files zu starten (noch mal nen dickes Danke dafuer :smiling_face_with_three_hearts:) war das dann tatsaechlich die “sauberste” Loesung (zumindest fuer mich) :wink:

– Micha

1 Like

Hier mal meine Service-Konfiguration. Ich habe die des normalen Gateways kopiert und dann angepasst, indem ich an die relevanten Punkte -zigbee drangehängt habe. Da das so einfach geht, ist es meiner Ansicht nach nicht relevant, dass ein Gateway mehrere Familien hat. Super-Komfort-Lösung wäre ein Shell-Skript, was die Dateien/Verzeichnisse erzeugt.

[Unit]
Description=Homegear Gateway (Zigbee)
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
PIDFile=/var/run/homegear/homegear-gateway-zigbee.pid
TimeoutSec=300
LimitRTPRIO=100
ExecStart=/usr/bin/homegear-gateway -u homegear -g homegear -c /etc/homegear-zigbee -p /var/run/homegear/homegear-gateway-zigbee.pid
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
TasksMax=infinity
LimitCORE=infinity

Die wird in folgende Datei gespeichert /lib/systemd/system/homegear-gateway-zigbee.service.

Und dann muss noch das entsprechende Konfigurationsverzeichnis kopiert und angepasst werden. Fertig.

1 Like

Hallo Andreas

Hast Du inzwischen einen Homegear-Gateway Container gebaut?

Hallo @Neuer_User,

ehrlich gesagt bin ich ich noch nicht mal dazu gekommen, mich überhaupt weiter mit dem Gateway zu beschäftigen. Aktuell liegt das Thema „SmartHome“ wegen einiger großer Projekte auf Eis. Aber das Thema steht noch immer auf dem Plan, nur sind die Prioritäten gerade andere. Sorry, dass ich dir keine positivere Antwort geben kann.

Gruß Andreas

1 Like

OK, kein Problem. Dann probiere ich einmal, so einen Container zu bauen.

Homegear selber läuft bei mir auf einem NanoPi im unpriviligiertem Docker-Container als Test soweit ganz gut. Dann sollte das Gateway eigentlich auch laufen. Nur haben wir da leider kein offizielles Image. Und ich weiss nicht, was man ggf alles vorinitialisieren muss. Na mal sehen.

2 Likes

Kurzes Update: Homegear-Gateway läuft jetzt mal experimentell bei mir auf dem NanoPi im Container. Ich lasse das jetzt mal eine Zeit lang laufen, baue ein zweites Gateway auf, setze das ganze in ein paar Gehäuse und berichte dann mal wieder.

2 Likes

Hi @Neuer_User,

super Sache!

Was für einen NanoPi benutzt du denn?

Ich hatte damals geplant für das Gateway den RockPiS (RockpiS - Radxa Wiki) zusammen mit einem PoE-Hat (ROCKPI S PoE HAT - Radxa Wiki) zu nutzen. Darauf sollte dann zumindest mal ein Container für Homematic (BidCos) und Zigbee, idealerweise auch noch Z-Wave laufen. Den RockPi wollte ich dann, gemeinsam mit den Interfaces in ein 3D-Druck-Gehäuse packen und per PoE vom USV-gepufferten Switch mit Strom versorgen.

1 Like

Hallo Andreas

Ich habe hier zwei NanoPi Neos mit 512MB. Die sind wirklich winzig und verbrauchen als Gateway je weniger als 100mA, also weniger als 0,5W im Betrieb. :slight_smile:

Ich hatte früher eine USV-gepufferten RPI im Schaltschrank mit OpenHab, Homegear, MQTT und KNXD, gewissermassen als feste “Homeautomation”-Appliance. Ich probiere aber jetzt gerade einen mehr auf eine Art “Microservices” basierende Architektur, bestehende aus:

  • Zwei Proxmox-Server (AMD64, einer ein NUC mit idle 6W, einer ein HP Microserver Gen8), über eine USV gepuffert, genutzt für alles mögliche :smiley:
  • Auf beiden je ein Docker-Host im Swarm-Mode
  • Darauf Openhab, Frontail, Homegear, MQTT und restic (backup) als Services (je genau eine Instanz)
  • Für die nicht stateless Services wie Openhab und Homegear plane ich einen Sync-Service der Daten zwischen den beiden Hosts (vermutlich via Syncthing)
  • Zugang zu Homematic und KNX läuft dann über die beiden NanoPis, die je ein KNXD mit TUL-Interface und ein Homegear-Gateway mit CC1101 haben

Damit habe ich dann planmässig eine komplette Redundanz der Hausautomatisierung. Wenn mal einer der Server ausfällt oder gewartet werden muss, gehen die Services automatisch auf den zweiten Server rüber. Wenn ein Gateway ausfällt oder gewartet werden muss, wird das zweite verwendet.

Ich bin aber noch am Aufbau. Für die NanoPis habe ich jetzt zwei Metallgehäuse bestellt. Als nächstes Bau ich den Syncthing Service für Openhab und Homegear auf. Dann müsste ich damit bereits Redundanz haben.

Aber jetzt erstmal schauen, wie sich das so im Betrieb macht. Wenn das grössere Probleme machen sollte, kann ich notfalls den RPI wieder in Betrieb nehmen.

Grüsse

Michael

1 Like

Passt auf den NanoPI Neo eigentlich das CC1101 Modul von cod.m? Ich hab hier drei “full-size” Raspberrys im Haus, die sich langweilen.