HM-RPC verschiedene Adressräume
-
@coolhead sagte in HM-RPC verschiedene Adressräume:
ob bei callback im rpc-Adapter überhaupt etwas einzustellen ist
Deine Konstellation mit VPN und Container kann ich nicht beurteilen.
in die Callback adresse kann immer eine IP eingetragen werden, über die die CCU direkt auf den ioBroker zugreifen kann.Eine Adresse muss eingetragen werden, wenn die Anfrage an die CCU von einer anderen IP kommt (siehe CCU syslog) als die des ioBroker.
@homoran
ok. Dann muss in der Call-Back Adresse nichts eingetragen werden, denn der rpc-Adapter ruft die CCU mit der eigenen Adressse, an die dann auch geantwortet werden soll.
Dann schmiert aber die entfernte CCU ab, bzw. deren Web-Oberfläche ist nicht mehr ansprechbar. RPC geht dann auch nicht mehr, oder die Antworten gehen ins Nirvana.Das sind beides 7490. Hier ein ping vom ipBroker über das vpn auf die Container ccu
PING 192.168.40.24 (192.168.40.24) 56(84) bytes of data.
64 bytes from 192.168.40.24: icmp_seq=1 ttl=62 time=62.9 ms
64 bytes from 192.168.40.24: icmp_seq=2 ttl=62 time=53.8 ms
64 bytes from 192.168.40.24: icmp_seq=3 ttl=62 time=55.6 ms
64 bytes from 192.168.40.24: icmp_seq=4 ttl=62 time=52.9 msIch denke, der Timeout in 90 sekunden. Ist ja schon merkwürdig, dass dann die Weboberfläche der CCU tot ist, nur weil ein rpc timer abläuft.
-
@homoran
ok. Dann muss in der Call-Back Adresse nichts eingetragen werden, denn der rpc-Adapter ruft die CCU mit der eigenen Adressse, an die dann auch geantwortet werden soll.
Dann schmiert aber die entfernte CCU ab, bzw. deren Web-Oberfläche ist nicht mehr ansprechbar. RPC geht dann auch nicht mehr, oder die Antworten gehen ins Nirvana.Das sind beides 7490. Hier ein ping vom ipBroker über das vpn auf die Container ccu
PING 192.168.40.24 (192.168.40.24) 56(84) bytes of data.
64 bytes from 192.168.40.24: icmp_seq=1 ttl=62 time=62.9 ms
64 bytes from 192.168.40.24: icmp_seq=2 ttl=62 time=53.8 ms
64 bytes from 192.168.40.24: icmp_seq=3 ttl=62 time=55.6 ms
64 bytes from 192.168.40.24: icmp_seq=4 ttl=62 time=52.9 msIch denke, der Timeout in 90 sekunden. Ist ja schon merkwürdig, dass dann die Weboberfläche der CCU tot ist, nur weil ein rpc timer abläuft.
-
@coolhead sagte: Dann muss in der Call-Back Adresse nichts eingetragen werden
Die CCU benötigt als Callback eine Adresse im eigenen Subnet (so ist es bei ioBroker im Docker-Container). Das kann nur die Gateway-Adresse sein.
-
@paul53 aha!!!!!! Das könnte die Erklärung sein. Dann kann ich aber nur die Gateway Adresse eintragen. Damit wird´s dann auch grün,
-
@coolhead sagte: Das könnte die Erklärung sein.
Das hattest Du schon so, aber dann lief "init" in einen Timeout.
-
@homoran
ok. Dann muss in der Call-Back Adresse nichts eingetragen werden, denn der rpc-Adapter ruft die CCU mit der eigenen Adressse, an die dann auch geantwortet werden soll.
Dann schmiert aber die entfernte CCU ab, bzw. deren Web-Oberfläche ist nicht mehr ansprechbar. RPC geht dann auch nicht mehr, oder die Antworten gehen ins Nirvana.Das sind beides 7490. Hier ein ping vom ipBroker über das vpn auf die Container ccu
PING 192.168.40.24 (192.168.40.24) 56(84) bytes of data.
64 bytes from 192.168.40.24: icmp_seq=1 ttl=62 time=62.9 ms
64 bytes from 192.168.40.24: icmp_seq=2 ttl=62 time=53.8 ms
64 bytes from 192.168.40.24: icmp_seq=3 ttl=62 time=55.6 ms
64 bytes from 192.168.40.24: icmp_seq=4 ttl=62 time=52.9 msIch denke, der Timeout in 90 sekunden. Ist ja schon merkwürdig, dass dann die Weboberfläche der CCU tot ist, nur weil ein rpc timer abläuft.
-
@paul53 jou - damit ist eine Fehlerquelle schon mal eliminiert und ich werde hier wieder die 192.168.40.99 als callback eintragen.
Dann setze ich jetzt mal die rega auf debug und schaue was da passiert
@coolhead
gibt es eine Möglichkeit, den rpc zu testen, um auszuschließen, dass es nicht daher kommt? Wenn der läuft, liegt es wahrscheinlich an dem 90 sekunden timeout. Aber 90 sekunden sollten doch reichen . . .
Ich schaue gerade auf die Prozessorauslastung des entfernten pi - der eidelt vor sich hin. Beil lokalen rega gibt es ja auch keinen timeout.
Der traffic in der fritzbox mit dem vpn liegt bei gemittelt 30kbps - da ist noch genügend Luft...Habe nochmal alle Objekte gelöscht und die beiden Adapter wieder neu gestartet:
Der Objektbaum mit Namen wird eingelesen aber nicht die Objekte selbst. Rega timed mit 90 sekunden schön regamäßig.
und im ccu Log steht dann:
<11>1 2022-06-19T18:18:46+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error calling system.listMethods({"ioBrokerPiHome:hm-rpc.1:6450e47710681f0f5c9c4fc3fd1c4ad1"}) on http://192.168.40.99:2001/RPC2: <11>1 2022-06-19T18:18:46+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error calling listDevices({"ioBrokerPiHome:hm-rpc.1:6450e47710681f0f5c9c4fc3fd1c4ad1"}) on http://192.168.40.99:2001/RPC2:ob das daran liegt, dass als callback das Gateway eingegeben ist und nicht der iobroker? Das gateway kann natürlich damit nichts anfangen. Wenn das so wäre, ginge ein subnetzübergreifender rpc Zugriff auf eine ccu nie, wenn da immer eine IP aus dem eigenen Subnetz einzutragen werden müsste.
-
@coolhead
gibt es eine Möglichkeit, den rpc zu testen, um auszuschließen, dass es nicht daher kommt? Wenn der läuft, liegt es wahrscheinlich an dem 90 sekunden timeout. Aber 90 sekunden sollten doch reichen . . .
Ich schaue gerade auf die Prozessorauslastung des entfernten pi - der eidelt vor sich hin. Beil lokalen rega gibt es ja auch keinen timeout.
Der traffic in der fritzbox mit dem vpn liegt bei gemittelt 30kbps - da ist noch genügend Luft...Habe nochmal alle Objekte gelöscht und die beiden Adapter wieder neu gestartet:
Der Objektbaum mit Namen wird eingelesen aber nicht die Objekte selbst. Rega timed mit 90 sekunden schön regamäßig.
und im ccu Log steht dann:
<11>1 2022-06-19T18:18:46+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error calling system.listMethods({"ioBrokerPiHome:hm-rpc.1:6450e47710681f0f5c9c4fc3fd1c4ad1"}) on http://192.168.40.99:2001/RPC2: <11>1 2022-06-19T18:18:46+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error calling listDevices({"ioBrokerPiHome:hm-rpc.1:6450e47710681f0f5c9c4fc3fd1c4ad1"}) on http://192.168.40.99:2001/RPC2:ob das daran liegt, dass als callback das Gateway eingegeben ist und nicht der iobroker? Das gateway kann natürlich damit nichts anfangen. Wenn das so wäre, ginge ein subnetzübergreifender rpc Zugriff auf eine ccu nie, wenn da immer eine IP aus dem eigenen Subnetz einzutragen werden müsste.
-
@coolhead sagte: Das gateway kann natürlich damit nichts anfangen.
Schau mal in die Fritzbox des entfernten Systems, welche IP-Adressen vergeben werden. Vielleicht ist eine dabei, die geeignet ist?
@paul53 sagte in HM-RPC verschiedene Adressräume:
Schau mal in die Fritzbox des entfernten Systems, welche IP-Adressen vergeben werden. Vielleicht ist eine dabei, die geeignet ist?
Was ist damit gemeint? im entfernten Netz (B) sind natürlich nur die Adressen vergeben, für die es auch Geräte gibt. Die piVCCU hat natürlich auch eine IP (=die .24) und der Host für den Container, auf dem auch ein ioBroker läuft, hat die .22.
-
@paul53 sagte in HM-RPC verschiedene Adressräume:
Schau mal in die Fritzbox des entfernten Systems, welche IP-Adressen vergeben werden. Vielleicht ist eine dabei, die geeignet ist?
Was ist damit gemeint? im entfernten Netz (B) sind natürlich nur die Adressen vergeben, für die es auch Geräte gibt. Die piVCCU hat natürlich auch eine IP (=die .24) und der Host für den Container, auf dem auch ein ioBroker läuft, hat die .22.
@coolhead
Update: Jetzt habe ich mal die beiden Adapterinstanzen hm-rega und hm-rpc gelöscht, die auf die entfernte CCU zugreifen sollen. Nach Neuinstallation und ohne Angabe von callback-Adressen, ohne Änderung der Subnetzmasken in der CCU oder sonstigen Klimmzügen klappt der Zugriff nun so wie er soll.
Auch nach reboot beider rpi´s oder Löschen der entsprechenden Objektbäume wird nach Aktivieren der Instanzen alles brav neu angelegt und der Zugriff klappt wie erhofft. :-) Hoffentlich bleibt es so . . .Ich danke allen Helfern in diesem hervorragenden Forum. Es war eine Freude zu erfahren, wie hilfsbereit man hier ist !!!
Danke auch für die schnellen near realtime Antworten.Beste Grüße
-
@randyandy
was muss denn bei callback Adresse stehen?Zur Erklärung meines Aufbaus:
ich habe zwei Subnetze an verschiedenen Orten mit jeweils einem rpi4 auf denen der ioBroker und piVCCU im lxc läuft. Jeder Standort für sich funktioniert lokal gut.
Da die beiden Standorte über fritz-vpn verbunden sind (jeweils unterschiedliche Sub-Netze) , möchte ich über den ioBroker von Standort A auf Standort B zugreifen.
Standort A : iobroker 192.168.20.22, piVCCU 192.168.20.24, Gateway 192.168.20.99
Standort B : iobroker 192.168.40.22, piVCCU 192.168.40.24, Gateway 192.168.40.99Der vpn-Zugriff geht auch von A nach B (z.B. ssh, Web-Zugriff auf die remote ccu).
Um aus ioBroker von A auf die piVCCU in B zuzugreifen starte ich nun in A eine 2. Instanz von hm-rpc und hm-rega und trage die IPs von B ein. Bei Callback, was kommt da rein?
Die 2. hm-rpc-Instanz bei A bekommt momentan keine Verbindung zur CCU von B. Sobald ich die hm-rpc Instanz bei A starte ist auch der Web-Zugriff von A nach B auf die remote CCU nicht mehr möglich und die CCU muss per ssh neu gestartet werden.
Die Firewall der piVCCU (B) ist auf Vollzugriff eingestellt. Bei iptabels bzw. nft sehe ich auch nichts auffälliges.Was muss ich bei der 2. hm-rpc Instanz bei A einstellen, damit der Zugriff auf die CCU (B) klappt?
Ist bei der CCU (B) oder im Container noch etwas freizugeben?Welche logs oder config Dateien könnten Aufschluss geben?
@coolhead sagte in HM-RPC verschiedene Adressräume:
@randyandy
was muss denn bei callback Adresse stehen?Zur Erklärung meines Aufbaus:
ich habe zwei Subnetze an verschiedenen Orten mit jeweils einem rpi4 auf denen der ioBroker und piVCCU im lxc läuft. Jeder Standort für sich funktioniert lokal gut.
Da die beiden Standorte über fritz-vpn verbunden sind (jeweils unterschiedliche Sub-Netze) , möchte ich über den ioBroker von Standort A auf Standort B zugreifen.
Standort A : iobroker 192.168.20.22, piVCCU 192.168.20.24, Gateway 192.168.20.99
Standort B : iobroker 192.168.40.22, piVCCU 192.168.40.24, Gateway 192.168.40.99Der vpn-Zugriff geht auch von A nach B (z.B. ssh, Web-Zugriff auf die remote ccu).
Um aus ioBroker von A auf die piVCCU in B zuzugreifen starte ich nun in A eine 2. Instanz von hm-rpc und hm-rega und trage die IPs von B ein. Bei Callback, was kommt da rein?
Die 2. hm-rpc-Instanz bei A bekommt momentan keine Verbindung zur CCU von B. Sobald ich die hm-rpc Instanz bei A starte ist auch der Web-Zugriff von A nach B auf die remote CCU nicht mehr möglich und die CCU muss per ssh neu gestartet werden.
Die Firewall der piVCCU (B) ist auf Vollzugriff eingestellt. Bei iptabels bzw. nft sehe ich auch nichts auffälliges.Was muss ich bei der 2. hm-rpc Instanz bei A einstellen, damit der Zugriff auf die CCU (B) klappt?
Ist bei der CCU (B) oder im Container noch etwas freizugeben?Welche logs oder config Dateien könnten Aufschluss geben?
Sieh Dir dazu auch mal folgenden Beitrag von mir an. Das hat mir wochenlang kopfzerbrechen gemacht.
Link TextIch habe keine Callbackadresse eingestellt.
Andreas
-
@coolhead sagte in HM-RPC verschiedene Adressräume:
@randyandy
was muss denn bei callback Adresse stehen?Zur Erklärung meines Aufbaus:
ich habe zwei Subnetze an verschiedenen Orten mit jeweils einem rpi4 auf denen der ioBroker und piVCCU im lxc läuft. Jeder Standort für sich funktioniert lokal gut.
Da die beiden Standorte über fritz-vpn verbunden sind (jeweils unterschiedliche Sub-Netze) , möchte ich über den ioBroker von Standort A auf Standort B zugreifen.
Standort A : iobroker 192.168.20.22, piVCCU 192.168.20.24, Gateway 192.168.20.99
Standort B : iobroker 192.168.40.22, piVCCU 192.168.40.24, Gateway 192.168.40.99Der vpn-Zugriff geht auch von A nach B (z.B. ssh, Web-Zugriff auf die remote ccu).
Um aus ioBroker von A auf die piVCCU in B zuzugreifen starte ich nun in A eine 2. Instanz von hm-rpc und hm-rega und trage die IPs von B ein. Bei Callback, was kommt da rein?
Die 2. hm-rpc-Instanz bei A bekommt momentan keine Verbindung zur CCU von B. Sobald ich die hm-rpc Instanz bei A starte ist auch der Web-Zugriff von A nach B auf die remote CCU nicht mehr möglich und die CCU muss per ssh neu gestartet werden.
Die Firewall der piVCCU (B) ist auf Vollzugriff eingestellt. Bei iptabels bzw. nft sehe ich auch nichts auffälliges.Was muss ich bei der 2. hm-rpc Instanz bei A einstellen, damit der Zugriff auf die CCU (B) klappt?
Ist bei der CCU (B) oder im Container noch etwas freizugeben?Welche logs oder config Dateien könnten Aufschluss geben?
Sieh Dir dazu auch mal folgenden Beitrag von mir an. Das hat mir wochenlang kopfzerbrechen gemacht.
Link TextIch habe keine Callbackadresse eingestellt.
Andreas
Danke für Deinen Hinweis. Ich hatte auch keine Callbackadresse eingestellt und nach Neuinstallation der von hm-rega und hm-rpc ging es aufeinmal. ---- Leider nur 3 Tage und dann war schin wieder keine rpc-Verbindung da !!!
Ich glaube auch, dass sich irgendetwas in den Adaptern verhakt, wenn verschiedene Subnetze verwendet werden.
Nachdem ich wie Du schon ewig daran rumgedoktert hatte, bin ich kurzerhand von rpc auf mqtt umgestiegen (Client im einen Subnetz und Server im anderen) . Seit dem läuft es wunderbar.
beste Grüße
coolhead -
Danke für Deinen Hinweis. Ich hatte auch keine Callbackadresse eingestellt und nach Neuinstallation der von hm-rega und hm-rpc ging es aufeinmal. ---- Leider nur 3 Tage und dann war schin wieder keine rpc-Verbindung da !!!
Ich glaube auch, dass sich irgendetwas in den Adaptern verhakt, wenn verschiedene Subnetze verwendet werden.
Nachdem ich wie Du schon ewig daran rumgedoktert hatte, bin ich kurzerhand von rpc auf mqtt umgestiegen (Client im einen Subnetz und Server im anderen) . Seit dem läuft es wunderbar.
beste Grüße
coolhead
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden631
Online32.8k
Benutzer82.7k
Themen1.3m
Beiträge