Erst als ich die Zigbee-Konfiguration vollständig entfernt hatte (sowohl im Gateway als auch bei Homegear selbst) wurde wieder mit BidCos kommuniziert. (Alle Geräte waren wieder erreichbar.)
Ist das so geplant, dass jedes Gateway nur eine Familie beliefern kann?
Falls ja, wie sollte man dann auf einem RaspberryPi mehrere Gateway-Instanzen einrichten?
Falls nein, wie kann ich helfen, damit der Fehler behoben werden kann?
Das alles mit 0.8.0-2956, als es nicht sofort geklappt hat, habe die aktuellste Version installiert.
homegear-gateway kann (derzeit) nur ein Protokoll pro Installation. Das ist meines Wissens auch so gewollt (gewesen)
Ich habe fuer unser kommerzielles Produkt in den letzten Wochen genau an dem “Problem” gearbeitet, und auch ab und an mal mit Sathya drueber gesprochen. Aktuell konnte ich es mit LXD loesen, und harre geduldig auf eine native Multiprotokoll-Homegeargateway-Version
Oha. Dieses Wissen hätte mir eine Menge Zeit gespart.
Oja, ich auch!
@sathya, könnte man das auch mit einem weiteren systemd-service machen, der auf ein anderes Konfigurationsfile verweist? (Option -c, andere Ports etc.)
Gesagt, getan. Aktuell laufen 2 Gateway-Services auf dem Pi.
root@pi3:/etc# systemctl status homegear-gateway*
● homegear-gateway.service - Homegear Gateway
Loaded: loaded (/lib/systemd/system/homegear-gateway.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2020-04-28 23:01:55 CEST; 1 day 17h ago
Main PID: 5819 (homegear-gatewa)
Tasks: 5
Memory: 2.4M
CGroup: /system.slice/homegear-gateway.service
└─5819 /usr/bin/homegear-gateway -u homegear -g homegear -p /var/run/homegear/homegear-gateway.pid
● homegear-gateway-zigbee.service - Homegear Gateway (Zigbee)
Loaded: loaded (/lib/systemd/system/homegear-gateway-zigbee.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2020-04-30 16:49:34 CEST; 8min ago
Main PID: 28829 (homegear-gatewa)
Tasks: 5
Memory: 876.0K
CGroup: /system.slice/homegear-gateway-zigbee.service
└─28829 /usr/bin/homegear-gateway -u homegear -g homegear -c /etc/homegear-zigbee -p /var/run/homegear/homegear-gateway-zigbee.pid
So, sieht erstmal gut aus. Ob es wirklich funktioniert ist was Anderes.
Das normale Gateway arbeitet mit Homematic BidCos, das zweite logischerweise mit Zigbee. Die Ports habe ich um 100 verschoben.. 2017 → 2117 und 2018 ->2118.
Das Doofe an der ganzen Sache ist natürlich, dass sich Homegear nicht mit dem Zigbee-Gateway verbinden möchte. Irgendwas ist da falsch, ich bin aber blind, ich finde nichtmal die entsprechende Code-Zeile auf Github. Zeit für 'ne Pause.
04/30/20 17:27:36.258 Module Zigbee: Zigbee serial module "pi3-gateway-zigbee": Warning: Gateway: Connection to device closed. Trying to reconnect...
04/30/20 17:27:37.260 Module Zigbee: Zigbee serial module "pi3-gateway-zigbee": Error in file PhysicalInterfaces/GatewayImpl.cpp line 190 in function void Zigbee::GatewayImpl::listen(): Could not connect to server 10.10.10.10 on port 2117. Poll failed with error code: 1.
sorry für die späte Antwort. Ich habe gerade mal reingeschaut. Der Port ist sowohl in Homegear als auch im Gatewaydienst frei konfigurierbar. An die Funktion configureGateway kann der Gatewayport mit übergeben werden.
Korrigiert mich wenn ich falsch liege, aber nutzt SSDP normalerweise™ nicht immer Port 1900 UDP?
Also solange man ssdpSearch nicht sagen kann, dass ein Port != 1900 verwendet werden soll wird das nicht funktionieren … IIRC hatte ich das gleiche Problem, als ich meine Loesung gebaut hatte …
beide Dienste lauschen auf Port 1900 parallel. Das geht auch, solange das Hostsystem das gleiche ist. Beide Dienste können entsprechend auch auf SSDP-Anfragen unabhängig voneinander antworten.
ich hab es tatsaechlich hinbekommen: auf meinem Gateway (OPi Zero) laufen zwei homegear-gateway Instanzen mit nur einer Installation auf unterschiedlichen Ports und antworten jeweils getrennt auf die ssdp-Suche.
Folgende Dinge sind zu beachten:
Jede Konfigurationsdatei (gateway.conf) muss in einem eigenen Pfad liegen, damit man homegear-gateway mit dem Parameter -c starten kann (eg. homegear-gateway -c /gateway-data/etc/zigbee/).
Jede Instanz benoetigt einen eigenen logfilePath und dataPath. Ansonsten kann die 2. Instanz die Logs nicht oeffnen, bzw. die Zertifikate werden einfach ueberschrieben.
Die Einstellungen port bzw. portUnconfigured muessen natuerlich je Instanz unterschiedlich konfiguriert werden.
Die uPnPUDN muss natuerlich auch je Instanz eindeutig sein!
So funktionierts hier bei mir. Ich hab auch testweise mal ein Zigbee-Device an meine Zigbee-Instanz angelernt um die Kommunikation zu testen. Funktioniert wie gewuenscht. Ein Hinzufuegen von Gateways mit nicht-standard Ports ueber die AdminUI ist ab dem naechsten nightly auch moeglich, die Aenderungen hab ich eben gepushed.
ich mache mir gerade Gedanken mir ein Homegear-Gateway mit mehreren Interfaces (ZigBee, Z-Wave, Homematic BidCos) zu bauen. Nachdem ich hier die Diskussion über mehrere Instanzen gelesen habe, kam mir die Idee, ob es nicht vielleicht eine Option wäre das ganze auf Docker-Basis zu bauen und jedem Protokoll/Interface einfach einen eigenen Docker-Container zu betreiben.
Vor 1-2 Wochen habe ich nun meine Homegear-Instanz in einem Docker-Container mit Zugriff auf eine Aeotec Z-Wave-Stick umgezogen. Derzeit stellt ein weiterer Container mit ZigBee2MQTT und Zugriff auf einen ConBee2 die ZigBee-Anbindung. Das würde ich aber zukünftig gerne mit Homegear-kompatibler Hardware ebenfalls mit Homegear-GW realisieren. Idealerweise direct über die GPIO-Pins statt über USB. Sowohl ZigBee als auch Z-Wave habe ich erstmal zum Spielen mit dazu genommen und mich dabei ungeschickterweise für den ConBee2 entschieden, den ich mit Homegear nicht zum laufen bekomme. Der Umweg über ZigBee2MQTT passt mir nicht so recht.
Denkbar wäre auch das Deployment, Updaten und Restarten von (neuen) Containern und das Pushen von Konfiguration von zentraler Stelle (vielleicht irgendwann die zentrale Homegear-Instanz/-WebGui?) zu steuern. Interessant wäre das insbesondere bei mehreren Gateway oder einem kommerziellen Produkt wie dem von @Micha. Damit könnte man die GWs als reine Docker-Nodes bereitstellen, dann dynamisch mit Hardware erweitern und dann von zentraler Stelle die passenden „Hardware-Container“ deployen, konfigurieren und pflegen.
Nur ne Anmerkung zu Zigbee: Das Mesh mag nur einen Coordinator haben. Also mehrer Funkmodule auf mehrere Gateways verteilen würde dann jedes mal ein eigenes Mesh aufspannen.
Soweit richtig. Viele Anwendungsfälle wird es für mehrere ZigBee-Gateways nicht geben, nehme ich an. Aber gerade bei sehr verteilten Installationen kann das sehr sinnvoll sein. Und genau so ein Szenario habe ich: ich wohne in einem Hochhaus mit 7 Obergeschossen + Erdgeschoss + Keller + Tiefgarage. In diesem Haus habe ich eine Wohnung im 2. OG und einen zusätzlichen Raum im Keller, den ich als Büro nutze. Beide sind mit LWL verbunden. Hier sind getrennte Mash-Netze sinnvoller als irgendwie ein großes Netz aufzubauen. Evtl. möchte ich die Hausautomation noch in die Garage ausdehnen. LWL werde ich da demnächst hinlegen. Bei anderen Technologien (z.B. HM BidCos) kommt man um mehrere GWs manchmal gar nicht rum. Z.B. wenn die Netze zu weitläufig werden oder zu viele Geräte für ein Gateway im System hängen (Stichwort: DutyCycle).
Absolut, aber hatte mit @Adrian diesbezüglich eine Unterhaltung, bis ich verstanden habe, dass mehre Koordinatoren keinen Sinn machen.
Allein aber schon für den Anwendungsfall, das Homegear in Docker oder auf irgend nem Server laufen, machen für das Gateway (auch bei ZigBee) schon Sinn.
Die CC253x-Module von mir, sind ja zum Beispiel direkt zum aufstecken auf den Pi und am Server mit USB runhantieren geht ja auch nicht immer
