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.
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.
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.
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?
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.
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.
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.
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.
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 ) war das dann tatsaechlich die “sauberste” Loesung (zumindest fuer mich)
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.
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.
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.
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.
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.
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.
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
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.
) war das dann tatsaechlich die “sauberste” Loesung (zumindest fuer mich) 
