Monatsrückblick Januar/Februar 2026 ist online!

[coolhead]

@coolhead
achso, ohne rega fehlen alle Objekte im rpc-Zweig. Aber zumindest rpc meldet Connected

Kein Fehler im Log:

hm-rpc.1
2022-06-19 15:29:03.433 info Connected
hm-rpc.1
2022-06-19 15:29:03.284 info xmlrpc client is trying to connect to 192.168.40.24:2001/ with ["http://192.168.40.99:2001","ioBrokerPiHome:hm-rpc.1:71647e6e9fd12fa6797f1acf911dc3b1"]
hm-rpc.1
2022-06-19 15:29:03.283 info xmlrpc server is trying to listen on 192.168.20.22:2001
hm-rpc.1
2022-06-19 15:29:03.130 info starting. Version 1.15.12 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v14.19.1, js-controller: 4.0.23
host.ioBrokerPiHome
2022-06-19 15:29:01.013 info instance system.adapter.hm-rpc.1 started with pid 15737
host.ioBrokerPiHome
2022-06-19 15:29:00.676 info "system.adapter.hm-rpc.1" enabled

[paul53]

@coolhead sagte: ohne rega fehlen alle Objekte im rpc-Zweig.

Dann funktioniert HM-RPC noch nicht. HM-Rega erzeugt zusätzliche Objekte unter HM-RPC, deren Datenpunkte meist auf "_ALARM" enden. Ansonsten benötigt man HM-Rega nur, um die Namen der Objekte aus der CCU zu übernehmen und um auf Systemvariablen zuzugreifen.

[coolhead]

@paul53
jetzt habe ich raga gestoppt und alle rpc-Objekte gelöscht.

Dann rpc gestartet (grün) -> wieDu schon vermutest, fehlen die Objekte. Dass rpc wieder gestoppt und rega gestartet. Dann hat er den Objektbaum gelesen, aber ohne Inhalte.
Auch wenn dann rpc gestartet wird, fehlt weiterhin der Inhalt. Zumindest ist jetzt alles grün, aber scheinbar klappt der rpc immer noch nicht. Und die Web-Oberfläche ist auch noch nicht abgestürzt :-)

[Homoran]

@paul53 sagte

Du nutzt kein piVCCU?

doch, aber der zählt nicht, den hat Alex fertig konfiguriert :-)

[Homoran]

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

Und die Web-Oberfläche ist auch noch nicht abgestürzt

steht denn beim Anmeldeversuch des hm-rpc etwas im syslog der ccu?

[paul53]

@coolhead sagte: ist jetzt alles grün, aber scheinbar klappt der rpc immer noch nicht.

Im Log ist nicht zu sehen, weshalb es nicht klappt?

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