HM-RPC verschiedene Adressräume
-
@coolhead
achso, ohne rega fehlen alle Objekte im rpc-Zweig. Aber zumindest rpc meldet ConnectedKein 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 -
@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.
-
@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
-
-
@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?
-
@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?
-
@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 -
@coolhead sagte in HM-RPC verschiedene Adressräume:
Das ioBroker-Log meldet nur rega timeout.
Hast du die hm-rpc Instanz auf debug gestellt?
-
@homoran
wo mach ich das? -
@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
-
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?
-
@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? -
@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 19400MOD-EDIT: Code in code-tags gesetzt
-
@coolhead wer ist .40.99, .20.22 und .40.24?
-
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 -
@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.
-
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?
-
@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.
-
@coolhead sagte:
timed out after 90 secondsDas kann daran liegen, dass das Fritzbox-VPN sehr langsam ist. Das "init" kann nicht vollständig ausgeführt werden. Welche Fritzboxen sind im Einsatz?
-
@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.
