Monatsrückblick Januar/Februar 2026 ist online!

[coolhead]

@paul53 Hallo Paul

Das ioBroker-Log meldet nur rega timeout.
syslog meldet:

<12>1 2022-06-19T16:05:01+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport failed (first try), retrying...
<11>1 2022-06-19T16:05:01+02:00 192.168.40.24 rfd - - - rfd: XmlRpcClient error calling event({[methodName:"event",params:{"ioBrokerPiHome:hm-rpc.1:8524897ed22040a88cc81fbdc65a8f92","CENTRAL","PONG","ioBrokerPiTi:hm-rpc.0:edcaab88bd31e9ef693379e470264271"}]}) on http://192.168.40.99:2001/RPC2:
<11>1 2022-06-19T16:05:01+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error

[Homoran]

@coolhead sagte in HM-RPC verschiedene Adressräume:

Das ioBroker-Log meldet nur rega timeout.

Hast du die hm-rpc Instanz auf debug gestellt?

[coolhead]

@homoran
wo mach ich das?

[Homoran]

@coolhead sagte in HM-RPC verschiedene Adressräume:

@homoran
wo mach ich das?

u ter Instanzen im Expertenmodus bei der Instanz die Logstufe auf debug stellen

[coolhead]

@homoran

ok ist auf debug
<12>1 2022-06-19T16:14:01+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport failed (first try), retrying...
<11>1 2022-06-19T16:14:01+02:00 192.168.40.24 rfd - - - rfd: XmlRpcClient error calling event({[methodName:"event",params:{"ioBrokerPiHome:hm-rpc.1:12be837c081e280817454fa8a86dd22d","CENTRAL","PONG","ioBrokerPiTi:hm-rpc.0:edcaab88bd31e9ef693379e470264271"}]}) on http://192.168.40.99:2001/RPC2:
<11>1 2022-06-19T16:14:01+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error
<11>1 2022-06-19T16:14:27+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error calling system.listMethods({"ioBrokerPiHome:hm-rpc.1:c6c0269fcde36a263e8e4a62a4765f1a"}) on http://192.168.40.99:2001/RPC2:
<11>1 2022-06-19T16:14:27+02:00 192.168.40.24 rfd - - - rfd: XmlRpc transport error calling listDevices({"ioBrokerPiHome:hm-rpc.1:c6c0269fcde36a263e8e4a62a4765f1a"}) on http://192.168.40.99:2001/RPC2:

sieht aber nicht viel anders aus. Ich hab als Callback immer noch das Gateway (Fritzbox). Kann es sein, dass er sich mit der eine halbe rpc-Session aufmacht?

[Homoran]

@coolhead sagte in HM-RPC verschiedene Adressräume:

sieht aber nicht viel anders aus. I

das ist ja auch nicht das iobroker debug log.

@coolhead sagte in HM-RPC verschiedene Adressräume:

Ich hab als Callback immer noch das Gateway (Fritzbox).

Callback was?
Adresse in ioBroker oder im netz?

[coolhead]

@homoran
klar mit dem Log - ich dachte, das Syslog CCU-Log wird gebraucht - da hat sich natürlich nix geändert, wenn der ioBroker auf debug steht

Hier das ioBroker-Log nach rpc-Neustart:

hm-rega.1
	2022-06-19 16:30:11.435	warn	"!# datapoints.fn 1.9 !# !# Dieses Homematic-Script gibt eine Liste aller Datenpu" timed out after 90 seconds
hm-rpc.1
	2022-06-19 16:29:50.553	debug	xmlrpc -> 192.168.40.24:2001/ init ["http://192.168.40.99:2001","ioBrokerPiHome:hm-rpc.1:7a611a0bc122f079bdf3bc36245de482"]
hm-rpc.1
	2022-06-19 16:29:20.551	debug	start connecting interval
hm-rpc.1
	2022-06-19 16:29:20.538	debug	xmlrpc -> 192.168.40.24:2001/ init ["http://192.168.40.99:2001","ioBrokerPiHome:hm-rpc.1:7a611a0bc122f079bdf3bc36245de482"]
hm-rpc.1
	2022-06-19 16:29:20.537	debug	Connect...
hm-rpc.1
	2022-06-19 16:29:20.536	info	xmlrpc client is trying to connect to 192.168.40.24:2001/ with ["http://192.168.40.99:2001","ioBrokerPiHome:hm-rpc.1:7a611a0bc122f079bdf3bc36245de482"]
hm-rpc.1
	2022-06-19 16:29:20.535	info	xmlrpc server is trying to listen on 192.168.20.22:2001
hm-rpc.1
	2022-06-19 16:29:20.354	info	starting. Version 1.15.12 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v14.19.1, js-controller: 4.0.23
hm-rpc.1
	2022-06-19 16:29:19.957	debug	Plugin sentry Initialize Plugin (enabled=true)
hm-rpc.1
	2022-06-19 16:29:19.843	debug	States connected to redis: 0.0.0.0:9000
hm-rpc.1
	2022-06-19 16:29:19.803	debug	States create User PubSub Client
hm-rpc.1
	2022-06-19 16:29:19.802	debug	States create System PubSub Client
hm-rpc.1
	2022-06-19 16:29:19.778	debug	Redis States: Use Redis connection: 0.0.0.0:9000
hm-rpc.1
	2022-06-19 16:29:19.733	debug	Objects connected to redis: 0.0.0.0:9001
hm-rpc.1
	2022-06-19 16:29:19.724	debug	Objects client initialize lua scripts
hm-rpc.1
	2022-06-19 16:29:19.644	debug	Objects create User PubSub Client
hm-rpc.1
	2022-06-19 16:29:19.642	debug	Objects create System PubSub Client
hm-rpc.1
	2022-06-19 16:29:19.640	debug	Objects client ready ... initialize now
hm-rpc.1
	2022-06-19 16:29:19.568	debug	Redis Objects: Use Redis connection: 0.0.0.0:9001
host.ioBrokerPiHome
	2022-06-19 16:29:18.219	info	instance system.adapter.hm-rpc.1 started with pid 19400

MOD-EDIT: Code in code-tags gesetzt

[Homoran]

@coolhead wer ist .40.99, .20.22 und .40.24?

[coolhead]

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

[Homoran]

@coolhead Sorry, bin kein Netzwerkspezi
Ich versuchte nur die Meldungen im log zu verstehen.
im CCU syslog sind zwei unterschiedliche RasPis, die Anfragen stellen, zusätzlich 2 Instanzen von einem der beiden.

Hier im iobroker Log geht es ausschließlich um rpc.1 von einer iobroker Installation. Trotzdem tauchen die genannten 3 IPs auf.

[coolhead]

@homoran

ja, die erste Frage ist, ob bei callback im rpc-Adapter überhaupt etwas einzustellen ist. Wenn ich dort die vpn-Gateway Adresse 40.99 eintrage, wird zumindest der rpc-Adapter grün, aber ob der rpc wirklich rpc mit der ccu macht ???

Dann hatten wir überlegt, ob die Subnetzmaske in der ccu zu erweitern wäre, aber dann klappt der Zugriff via vpn gar nicht.

Ich hätte noch irgendwas mit Firewall in Verdacht, aber bei der CCU steht alles auf Vollzugriff.

Welche Logs oder Config-Dateien könnten noch hilfreich sein?

[Homoran]

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

[paul53]

@coolhead sagte:

timed out after 90 seconds

Das kann daran liegen, dass das Fritzbox-VPN sehr langsam ist. Das "init" kann nicht vollständig ausgeführt werden. Welche Fritzboxen sind im Einsatz?

[coolhead]

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

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

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