@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.
Hoffentlich bleibt es so . . .
