Monatsrückblick Januar/Februar 2026 ist online!

[coolhead]

@homoran
Danke, habe ich schon probiert (also die 192.168.20.22) - geht aber trotzdem nicht.

[Homoran]

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

@homoran
Danke, habe ich schon probiert (also die 192.168.20.22) - geht aber trotzdem nicht.

lxc ist etwas anders gestrickt
ich nutze so was deswegen nicht, glaube aber da muss der Host adressiert werden, der routet dann in den Container

[coolhead]

@homoran
HMM - ich kann den lxc-Container in B aber direkt von A über das vpn adressieren, d.h. wenn ich die 192.168.40.24 anspreche, dann reagiert der Container wie erwartet (wie ein 2. virtueller Rechner mit einer eigenen IP).
Mit z.B. ssh, Web-Zugriff auf die piVCCU, ping sowieso. Ist da möglicherweise noch ein Fierwll-Problem für den Port? Oder kommt da etwas mit den Port durcheinander?

[paul53]

@coolhead sagte: ein Fierwll-Problem für den Port?

Vergrößere mal das Subnet in der CCU.

[coolhead]

@paul53

Wo mache ich das? bei meiner CCU kann ich nur die eigene IP und die Subnetzmaske eingeben.

[paul53]

@coolhead sagte: nur die Subnetzmaske eingeben

Dann gib dort mal 255.255.192.0 ein.

[coolhead]

@paul53
Danke - hab ich gemacht. Was trage ich bei Callback Adresse ein?

[paul53]

@coolhead sagte: Was trage ich bei Callback Adresse ein?

Nichts oder die ioBroker-IP-Adresse.

[coolhead]

@paul53
Dauert immer etwas, da ich bei jedem Fehlversuch die CCU per ssh neu starten muss, falls der rpc-Call falsch läuft.
Jetzt nach mehrfachen Neustarts per ssh komme ich nicht mehr per http auf die remote ccu - wahrscheinlich wegen der neuen subnetzmaske??

die ccu netconfig sieht jetzt so aus:
MODE=MANUAL
CURRENT_IP=192.168.40.24
CURRENT_NETMASK=255.255.192.0
CURRENT_GATEWAY=192.168.40.99
CURRENT_NAMESERVER1=8.8.8.8
CURRENT_NAMESERVER2=1.1.1.1
IP=192.168.40.24
NETMASK=255.255.192.0
GATEWAY=192.168.40.99
NAMESERVER1=8.8.8.8
NAMESERVER2=1.1.1.1
CRYPT=0

[paul53]

@coolhead sagte: wegen der neuen subnetzmaske??

Keine Ahnung. Dann ändere es wieder zurück.
Gibt es in der CCU nicht auch Firewall-Einstellungen, bei denen der IP-Adressbereich angegeben wird? Ich muss fragen, da ich keine CCU mehr verwende, sondern nur noch den rfd aus der OCCU.

[coolhead]

@coolhead
So, nun per ssh die Netzmaske wieder auf 255.255.255.0 gesetzt und http auf die ccu geht wieder. Nach meinem Verständnis ist diese Netzmaske ja auch richtig, denn alles was nicht im 192.168.40-er Adressbereich bleibt, soll ans Gateway und damit übers vpn, wenn es in den 20-er Bereich geht, oder?

[coolhead]

@paul53
ja, in der CCU gibt es auch Firewalleinstellungen. Die sind aber alle auf Vollzugriff. Ich hoffe, im Container gibt es nicht noch andere bösen Geister, die an den iptables / nft schrauben. Da kenne ich mich nicht so aus.

[paul53]

@coolhead sagte: soll ans Gateway

Hast Du dessen IP-Adresse (192.168.40.99) mal als Callback-Adresse eingegeben?

[paul53]

@homoran sagte: lxc ist etwas anders gestrickt
ich nutze so was deswegen nicht

Du nutzt kein piVCCU?

[coolhead]

@paul53
hab ich eben gemacht. Beide Adapter werden grün aber nach 90 sek kommt der Timeout bei hm-rega, dass er nichts lesen kann.

hm-rega.1
2022-06-19 15:13:22.677 error CCU 192.168.40.24 unreachable
hm-rega.1
2022-06-19 15:13:22.676 error post request error: Aborted due to timeout
hm-rega.1
2022-06-19 15:13:22.674 warn "!# datapoints.fn 1.9!#!# Dieses Homematic-Script gibt eine Liste aller Datenpu" timed out after 90 seconds
hm-rega.1
2022-06-19 15:11:52.601 info request state values
hm-rega.1
2022-06-19 15:11:51.888 info time difference local-ccu 1s
hm-rega.1
2022-06-19 15:11:51.733 info ReGaHSS 192.168.40.24 up

[paul53]

@coolhead sagte: nach 90 sek kommt der Timeout bei hm-rega

HM-Rega soll auch remote zugreifen? Deaktiviere erst mal die HM-Rega-Instanz, um zu sehen, ob HM-RPC remote funktioniert.
Hat die lokale ioBroker-Installation auch eine HM-Rega-Instanz?

[coolhead]

@paul53
ja, auf beiden ioBroker läuft eine lokale hm-rega und eine hm-rpc. Bei A läuft zusätzlich noch eine 2. Instanz für hm-rega und hm-rpc, um auf B zuzugrifen. Ich dachte, ich brauche immer beide - wenn ich mir die hm-rega Objekte im ioBroker anschaue, weiss ich aber gar nicht, wofür die die hm-rega brauche. Ich hab die 2. hm-rega mal deaktiviert.
Ich schau mal, ob es ohne rega auch geht....

[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 :-)