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 
) war das dann tatsaechlich die “sauberste” Loesung (zumindest fuer mich) 
– Micha
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.
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
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.
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.
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. 
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:
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
Passt auf den NanoPI Neo eigentlich das CC1101 Modul von cod.m? Ich hab hier drei “full-size” Raspberrys im Haus, die sich langweilen.
Das normale leider nicht. Hatte dafür aber extra eins gebaut.
Leider erstes Problem: Homegear online, Gateway online, aber:
2021-03-08 17:53:46.256 [ERROR] [ternal.handler.HomematicThingHandler] - -100 No answer from device. (sending setValue()
MEQ0161924:1
OPEN
true
)
java.io.IOException: -100 No answer from device. (sending setValue()
MEQ0161924:1
OPEN
true
)
at org.openhab.binding.homematic.internal.communicator.parser.RpcResponseParser.parse(RpcResponseParser.java:51) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:82) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:94) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:94) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:94) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:70) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.client.RpcClient.setDatapointValue(RpcClient.java:335) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway$1.execute(AbstractHomematicGateway.java:686) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.misc.DelayedExecuter.start(DelayedExecuter.java:65) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.sendDatapoint(AbstractHomematicGateway.java:665) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.sendDatapoint(AbstractHomematicGateway.java:644) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.handler.HomematicThingHandler.sendDatapoint(HomematicThingHandler.java:312) ~[bundleFile:?]
at org.openhab.binding.homematic.internal.handler.HomematicThingHandler.handleCommand(HomematicThingHandler.java:288) [bundleFile:?]
at jdk.internal.reflect.GeneratedMethodAccessor114.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy239.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Dann als nächstes in den Logs:
2021-03-08 17:53:56.029 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'homematic:HG-HM-Sec-Key:homegear:MEQ0161924' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
...
2021-03-08 17:53:58.482 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'homematic:HG-HM-Sec-Key:homegear:MEQ0161924' changed from OFFLINE (COMMUNICATION_ERROR) to ONLINE
Das ist in der Hinsicht problematisch, als das ich das in den letzten Jahren mit dem RPI (und ohne Gateway) niemals hatte.
Weiter beobachten…
Wenn das Gerät in Homegear funktioniert, dann hat das nichts mit dem Gateway zu tun. openHAB hat überhaupt keine Kenntnis von dem Gateway.
Sollte das Gerät nicht in Homegear funktionieren, dann hast du höchstwahrscheinlich einen Fehler in der Konfiguration.
Es könnte natürlich auch sein, dass die Netzwerk-Verbindung zum Gateway abgerissen ist. Du müsstest mal ins Homegear-log zum entsprechenden Zeitpunkt schauen.
Ich bin mir nicht mehr sicher, aber Du musst die Geräte einem Gateway zuweisen oder auf Roaming schalten.
Also, das seltsame ist, dass generell alle drei Komponenten funktionieren und laufen: Openhab, Homegear und Homegear-Gateway. Trotzdem wurde ein Endgerät für eine Zeitlang als nicht erreichbar gemeldet (welches ca 7m neben dem gateway steht). Im Anhang das Homegearlog zu der relevanten Zeit.homegear.log (45.2 KB)
Nach dem “Aussetzer” kam das Device ja auch ohne weiteres zutun von mir wieder online nach ein paar Minuten. Ich hatte das Türschloss einmal von Hand mit den Tasten bedient. Ob das das Kommunikationsproblem gelöst hat oder nicht, weiss ich nicht.
Vielleicht hat das ja auch gar nichts mit dem Gateway zu tun. Ich hatte es nur in den letzten Jahren nie gehabt, dass ein Homematic Device nicht funktionierte. Und jetzt mir einer zusätzlichen Komponente (Gateway) kann es natürlich auch an dem liegen.
Vorher liefen alle Devices problemlos mehrere Tage lang (und früher für ein paar Jahre am RPI).
Alle Geräte liefen ja schon ein paar Tage erfolgreich. Es gab “nur” einen Aussetzer von ein paar Minuten, was ich nie früher gesehen habe.
Übrigens, wo man Roaming einschaltet, habe ich noch nirgendwo gefunden. Das wird aber erst interessant, wenn ich das zweite Gateway online schalte (vermutlich Ende der Woche oder so).
Ach ja, der Aussetzer war um ca 17:53 und dauerte ein paar Minuten. Vielleicht war das Gerät schon viel länger offline, aber es fiel erst auf, als es angesprochen wurde.
Auf jeden Fall hatte das Türschloss in den letzten fünf Jahren (ohne Gateway) immer ohne Probleme funktioniert. Ist jetzt das erste mal, dass ich ein “Communication Error” sehe (und dann nicht ins Haus komme ).
Ich habe das über das PHP-CLI gemacht, dort lautet die Sequence
$hg->putParamset(<geräte-id>,0,"MASTER",array("ROAMING"=>true));Kurzes Update:
Ich habe jetzt zwei NanoPi Gateways im Einsatz und kämpfe mit unregelmässigen Problemen. Dabei ist für mich nicht klar, ob es sich um RF-Probleme oder Homegear->Gateway Problemen handelt.
Meine aktuelle Vermutung ist, dass es RF-Probleme sind, möglicherweise in der SPI-Kommunikation mit dem CC1101. Ist aber noch völlig unklar. Ich habe da ein paar Fragen und werde am besten mal einen neuen Thread dazu aufmachen.
Kann mir jemand sagen, ob der folgende RF-Empfang Sinn macht oder ob da etwas schief läuft zwischen den beiden Gateways? Das folgende Log ist der Empfang eines einzigen Signals eines einzigen Tastendruckes einer Taste auf einer Homematic Fernbedienung. Mir erscheint das ein wenig viel, oder?
03/24/21 19:34:37.059 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.059 Packet received (NanoPi2, RSSI: -57 dBm): 0BF6A6403872E8FD92A5032F
03/24/21 19:34:37.155 Module HomeMatic BidCoS: HomeMatic Homegear Gateway "NanoPi1": Info: Sending: 11F6A002FD92A53872E804D7DF74C21D1F00
03/24/21 19:34:37.181 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.181 Packet received (NanoPi2, RSSI: -66 dBm): 11F6A002FD92A53872E804D7DF74C21D1F00
03/24/21 19:34:37.312 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.311 Packet received (NanoPi2, RSSI: -56 dBm): 19F6A0033872E8FD92A52F50FAB9D6D73239770BE45C0FA42AD8
03/24/21 19:34:37.313 Info: r-Frame is: 19F6A0033872E8FD92A52F50FAB9D6D73239770BE45C0FA42AD8
03/24/21 19:34:37.314 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.314 Packet received (NanoPi1, RSSI: -64 dBm): 0BF6A6403872E8FD92A5032F
03/24/21 19:34:37.317 Module HomeMatic BidCoS: Info: INSTALL_TEST on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.317 Module HomeMatic BidCoS: Info: PRESS_SHORT on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.317 Module HomeMatic BidCoS: Info: TEST_COUNTER on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.317 Module HomeMatic BidCoS: Info: SIM_COUNTER on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.410 Module HomeMatic BidCoS: HomeMatic Homegear Gateway "NanoPi1": Info: Sending: 0EF68002FD92A53872E800328B019A
03/24/21 19:34:37.552 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.552 Packet received (NanoPi2, RSSI: -56 dBm): 0BF7A2403872E8FD92A5032F
03/24/21 19:34:37.649 Module HomeMatic BidCoS: HomeMatic Homegear Gateway "NanoPi1": Info: Sending: 11F7A002FD92A53872E8048679A24FB10500
03/24/21 19:34:37.675 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.675 Packet received (NanoPi2, RSSI: -66 dBm): 11F7A002FD92A53872E8048679A24FB10500
03/24/21 19:34:37.806 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.806 Packet received (NanoPi2, RSSI: -57 dBm): 19F7A0033872E8FD92A5C88E66C9082C296693BC09F368A5EB90
03/24/21 19:34:37.807 Info: r-Frame is: 19F7A0033872E8FD92A5C88E66C9082C296693BC09F368A5EB90
03/24/21 19:34:37.807 Module HomeMatic BidCoS: Info: 03/24/21 19:34:37.807 Packet received (NanoPi1, RSSI: -63 dBm): 0BF7A2403872E8FD92A5032F
03/24/21 19:34:37.809 Module HomeMatic BidCoS: Info: INSTALL_TEST on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.810 Module HomeMatic BidCoS: Info: PRESS_SHORT on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.811 Module HomeMatic BidCoS: Info: TEST_COUNTER on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.811 Module HomeMatic BidCoS: Info: SIM_COUNTER on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:37.905 Module HomeMatic BidCoS: HomeMatic Homegear Gateway "NanoPi1": Info: Sending: 0EF78002FD92A53872E8005FA4577E
03/24/21 19:34:38.046 Module HomeMatic BidCoS: Info: 03/24/21 19:34:38.046 Packet received (NanoPi2, RSSI: -57 dBm): 0BF8A2403872E8FD92A5032F
03/24/21 19:34:38.145 Module HomeMatic BidCoS: HomeMatic Homegear Gateway "NanoPi1": Info: Sending: 11F8A002FD92A53872E8043BAFAA9863D700
03/24/21 19:34:38.171 Module HomeMatic BidCoS: Info: 03/24/21 19:34:38.171 Packet received (NanoPi2, RSSI: -66 dBm): 11F8A002FD92A53872E8043BAFAA9863D700
03/24/21 19:34:38.302 Module HomeMatic BidCoS: Info: 03/24/21 19:34:38.302 Packet received (NanoPi2, RSSI: -57 dBm): 19F8A0033872E8FD92A5C6EB9A0C5A9B6072D26F45F7F840F90F
03/24/21 19:34:38.302 Info: r-Frame is: 19F8A0033872E8FD92A5C6EB9A0C5A9B6072D26F45F7F840F90F
03/24/21 19:34:38.302 Module HomeMatic BidCoS: Info: 03/24/21 19:34:38.302 Packet received (NanoPi1, RSSI: -61 dBm): 0BF8A2403872E8FD92A5032F
03/24/21 19:34:38.304 Module HomeMatic BidCoS: Info: INSTALL_TEST on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:38.304 Module HomeMatic BidCoS: Info: PRESS_SHORT on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:38.304 Module HomeMatic BidCoS: Info: TEST_COUNTER on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:38.304 Module HomeMatic BidCoS: Info: SIM_COUNTER on channel 3 of HomeMatic BidCoS peer 4 with serial number MEQ0162354 was set to 0x2F.
03/24/21 19:34:38.400 Module HomeMatic BidCoS: HomeMatic Homegear Gateway "NanoPi1": Info: Sending: 0EF88002FD92A53872E80059EA9B1B
03/24/21 19:34:38.419 Module HomeMatic BidCoS: Info: 03/24/21 19:34:38.418 Packet received (NanoPi2, RSSI: -77 dBm): 0AF88002FD92A53872E800Auch dauert der ganze Empfang etwa 1,5 Sekunden. Ganz schön viel Kommunikation für einen Tastendruck, oder?