Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Kuddel]

habe das Loglevel vom Adapter mal auf Info gestellt:

hm-rpc.0	2019-11-28 17:24:26.959	info	(12834) xmlrpc -> 230 devices
hm-rpc.0	2019-11-28 17:24:26.914	info	(12834) xmlrpc <- listDevices ["hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:26.910	info	(12834) xmlrpc <- system.listMethods ["hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:26.393	info	(12834) xmlrpc -> 230 devices
hm-rpc.0	2019-11-28 17:24:26.352	info	(12834) xmlrpc <- listDevices ["hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:26.348	info	(12834) xmlrpc <- system.listMethods ["hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:16.785	info	(12834) Connected
hm-rpc.0	2019-11-28 17:24:16.469	info	(12834) xmlrpc -> 230 devices
hm-rpc.0	2019-11-28 17:24:16.400	info	(12834) xmlrpc <- listDevices ["hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:16.395	info	(12834) xmlrpc <- system.listMethods ["hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:16.384	info	(12834) xmlrpc client is trying to connect to 192.168.4.5:2001/ with ["http://192.168.4.30:2001","hm-rpc.0"]
hm-rpc.0	2019-11-28 17:24:16.384	info	(12834) xmlrpc server is trying to listen on 192.168.4.30:2001
hm-rpc.0	2019-11-28 17:24:16.162	info	(12834) [META] Meta data updated
hm-rpc.0	2019-11-28 17:24:16.136	info	(12834) starting. Version 1.10.3 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v10.17.0

[Kuddel]

Jetzt zickt die CCU wieder rum.

Die RPC-Instanz verbindet sich nicht mehr.

Wenn ich auf der CCU iwas manuell schalten will, bewegt sich nur oben rechts der Ladekreis, der Aktor wird aber nicht geschaltet

[Homoran]

@Kuddel
Hast du irgendwas geändert?
Update?
Firewall?
IP-Adressen?

[Kuddel]

@Homoran leider nein.

ich habe vorallem an der CCU nichts geändert.

Wäre ein Defekt der CCU möglich?

[Homoran]

@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:

ich habe vorallem an der CCU nichts geändert.

auch nicht an Skripten oder so?

@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:

Wäre ein Defekt der CCU möglich?

Ist nie ganz auszuschließen.

Nach deinem log scheint ioBroker ja wenigstens die Daten zu pollen.
Deine Aussage:

@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:

Wenn ich auf der CCU iwas manuell schalten will, bewegt sich nur oben rechts der Ladekreis, der Aktor wird aber nicht geschaltet

verstehe ich nicht ganz.
Schaltest du AUF DER CCU oder in ioBroker?

Gibt es im Log der CCU irgendwelche Hinweise?

[Kuddel]

@Homoran

die CCU fungiert nur als Gateway.

Die Skripte laufen alle auf dem ioBroker.

Da sich die RPC-Instanz nicht verbunden hat, wollt eich zum Test über die CCU einen Lichschalter schalten. Da kam dann nur das Ladeicon.

Wo liegen die Logs auf der CCU ?

Würde die dann hier posten

[Homoran]

@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:

Wo liegen die Logs auf der CCU ?

Einstellungen-Systemsteuerung-Zentralenwartung-Log herunterladen

Ist aber nicht klein

[Bachmann77]

@Kuddel
Hi.
Nutzt du zufällig die diagramme auf deiner CCU?
Ich hatte vor längerer Zeit identische Probleme....bis hin das nichts mehr ging..bei mir wars es die Speicherkarte in der CCU
Hab Sie dann durch eine "industrial" ersetzt. Dann war das Problem behoben.
Da die CCU ja nicht die schnellste ist, bin ich dann iwann auf den Pi3 und jetzt auf den Pi4 umgestiegen auf welchem Rasperrymatic läuft.

[Kuddel]

@Bachmann77 nein, die CCU ist bei mir nur Gateway zu den Aktoren. Eine SD Karte ist auch nicht verbaut

[Kuddel]

@Homoran nachdem die CCU gestern Abend mal wieder nicht reagiert hat, habe ich soe für 60 Sekunden vomr Strom getrennt.

Bis jetzt läuft sie run, nur die States werden immer noch nicht gepushed.

Ich habe mal zwei Log-Datein angehängt.

CCU2-2019-11-28.log

CCU2-2019-11-29.log

[Kuddel]

Aktueller Stand:

Meine CCU2 läuft seit gestern Abend immer noch sauber durch.

Ich habe zum testen eine neue UBuntun 18.04 VM ausgerollt und ioBroker neuinstalliert.

Alle States werden korrekt erkannt und die Lichtschalter gemäß Skript korrekt geschaltet:

Also könnte meine produktive ioBroker Instanz doch das Problem sein.

[Homoran]

@Kuddel
Im log gibt es eine IP. 30 und eine .31

Wer ist wer?

[Kuddel]

@Homoran

192.168.4.30 = produktive VM
192.168.4.31 = Klon der VM von Mittwoch auf der aber keine Skripte aktiv sind

[Homoran]

@Kuddel dann sollte sich vielleicht @foxriver76 mal das log von heute ansehen. Einer meldet sich im Sekundentakt an und ab.

[Kuddel]

@Homoran das würde natürlich erklären, warum die CCU in die Knie geht und nicht mehr erreichbar ist.

Der Klon ist auf jeden Fall schonmal aus, da ich die IP für meinen jetzigen Test (neue VM / neue IoB Installation) verwende

[foxriver76]

@Kuddel zeig mal das Debug Log von den Instanzen. Und mit deiner geklonten VM geht es mit gleichen Einstellungen? I welche Firewall Geschichten evtl unterschiedlich? Iwo muss ja der Unterschied liegen.

[Kuddel]

@foxriver76

aktuell läuft alles wieder, wie zum Zeitpunkt bevor die Probleme das erste Mal aufgetreten sind.

Ich vermute, dass die CCU ständig unter Vollast lief. Der Klon (1:1 die gleichen Einstellunge wie produktive VM) ist immer noch ausgeschaltet.

[Homoran]

@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:

dass die CCU ständig unter Vollast

Ich weiss nicht wie viel Power das frisst, aber hast du IP-Geräte die gerade ein Update bekamen?

[Kuddel]

@Homoran habe nur zwei Steckdosen von IP

[Kuddel]

aktuell läuft alles wieder rund.

es scheint so, also hätte meine Testumgebung die Probleme verursacht.

Vielen Dank an alle für die Mithilfe