HM-RPC verschiedene Adressräume

[paul53]

@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.

[coolhead]

@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,

[paul53]

@coolhead sagte: Das könnte die Erklärung sein.

Das hattest Du schon so, aber dann lief "init" in einen Timeout.

[coolhead]

@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

[paul53]

@coolhead sagte: Das sind beides 7490.

Dann kann leider das Labor-OS mir dem schnelleren Wireguard nicht verwendet werden.

[coolhead]

@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.

[paul53]

@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?

[coolhead]

@paul53

@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]

@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]

@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.99

Der 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 Text

Ich habe keine Callbackadresse eingestellt.

Andreas

[coolhead]

@randyandy

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

[RandyAndy]

@coolhead

Interessanter Ansatz dies mit MQTT umzusetzten.

Andreas