Bei mir ebenso.

Kann ich ebenfalls bestätigen, bis auf "BIN-RPC" alle anderen RPC-Adapter auf GELB

gleiches Problem, bei mir schmiert deswegen sogar die occu ab

Bei mir ebenfalls, aber nur für die CUXD Einstellungen mit Bin-RPC

host.raspberrypi 2017-04-22 08:06:08.431 info instance system.adapter.hm-rpc.0 terminated with code null ()

host.raspberrypi 2017-04-22 08:06:08.429 warn instance system.adapter.hm-rpc.0 terminated due to SIGTERM

host.raspberrypi 2017-04-22 08:06:08.389 info stopInstance system.adapter.hm-rpc.0 killing pid 24934

host.raspberrypi 2017-04-22 08:06:08.388 info stopInstance system.adapter.hm-rpc.0

host.raspberrypi 2017-04-22 08:06:08.387 info object change system.adapter.hm-rpc.0

host.raspberrypi 2017-04-22 08:06:07.096 info instance system.adapter.hm-rpc.0 started with pid 24934

hm-rpc.0 2017-04-22 08:06:04.599 info binrpc -> 192.168.123.170:2001 init ["xmlrpc_bin://192.168.123.37:2001",""]

host.raspberrypi 2017-04-22 08:06:04.553 info stopInstance system.adapter.hm-rpc.0 killing pid 32296

host.raspberrypi 2017-04-22 08:06:04.552 info stopInstance system.adapter.hm-rpc.0

host.raspberrypi 2017-04-22 08:06:04.550 info object change system.adapter.hm-rpc.0

host.raspberrypi 2017-04-22 08:05:22.355 info instance system.adapter.hm-rpc.1 terminated with code 7 (Adapter already running)

host.raspberrypi 2017-04-22 08:05:18.147 info instance system.adapter.hm-rpc.1 started with pid 24887

host.raspberrypi 2017-04-22 08:05:15.545 info stopInstance system.adapter.hm-rpc.1 killing pid 23286

host.raspberrypi 2017-04-22 08:05:15.542 info stopInstance system.adapter.hm-rpc.1

hm-rpc.1 2017-04-22 08:05:15.564 info binrpc -> 192.168.123.170:8701 init ["xmlrpc_bin://192.168.123.37:8706",""]

host.raspberrypi 2017-04-22 08:05:15.488 info object change system.adapter.hm-rpc.1

hm-rpc.1 2017-04-22 08:02:33.468 error Socket error: Error: connect ECONNREFUSED 192.168.123.170:8701

host.raspberrypi 2017-04-22 08:00:11.780 info instance system.adapter.weatherunderground.0 terminated with code 0 (OK)

schaut mal die 1.4.6/Github-Version , Bluefox hat gerade nochmal an den Dependecies gedreht

Hallo zusammen,

ich kann die Probleme hier auch bestätigen. Nach 4 Monaten uptime habe ich iobroker(update) und die CCU2(Firmware) auf Aktuellen Stand gebracht. Im Ergebnis ist die CCU nicht Bedienbar gewesen - quasi abgewürgt. Hat lange gedauert bis ich auf iobroker und dem cuxd mit bin-rpc gekommen bin das da die Probleme her kommen. Also der hm-rpc0 läuft hier mit dem rfd (CCU) über bin-rpc und bekommt die Verbindungen - wenn auch mitunter etwas widerwillig.

Der hm-rpc1 (cuxd) bekommt hier mit bin-rpc keine komplette Verbindung (Verbunden mit hm-rpc = falsch) Ich habe jetzt erstmal den hm-rpc mit cuxd komplett aus iobroker verband damit die ccu wenigstens läuft.

Edit: Mit aus Github installieren habe ich mich noch nicht beschäftigt wie das funktioniert - ist das eine größere Baustelle

Beste Grüße vom Volker

Github simpel!

Unter Adapter ist das dritte Icon oben von Links so ein Katzenkopf. Tooltip drüber ist "Custom Install" oder so. Da drauf. Dort beim Tab "Von Github" einfach den Adapter wählen und los gehts.

Hallo

bei mir hat das Update auf die 1.4.6 auch keine Verbesserung gebracht. Der hm.rpc.0 (rfd) springt von grün auf Gelb, der hm.rpc.1 (hmip) ist auf grün. Im Log steht folgendes:

hm-rpc.0	2017-04-22 11:39:28.695	info	binrpc -> 150 devices
hm-rpc.0	2017-04-22 11:39:28.684	info	binrpc <- listDevices ["hm-rpc.0"]
hm-rpc.0	2017-04-22 11:39:28.669	info	binrpc <- system.listMethods ["hm-rpc.0"]
hm-rpc.0	2017-04-22 11:39:28.370	info	binrpc -> 150 devices
hm-rpc.0	2017-04-22 11:39:28.359	info	binrpc <- listDevices ["hm-rpc.0"]
hm-rpc.0	2017-04-22 11:39:28.345	info	binrpc <- system.listMethods ["hm-rpc.0"]

und das fortlaufend… Die CCU reagiert seitdem auch sehr träge

Gruß

Wolle

Hallo,

hier läuft es jetzt mit der 1.4.6 - Fettes Danke an Bluefox

! hm-rpc.1 2017-04-22 11:53:10.704 info Connected
! hm-rpc.1 2017-04-22 11:53:10.698 info new CUxD devices/channels after filter: 0
! hm-rpc.1 2017-04-22 11:53:10.683 info binrpc -> listDevices 18
! hm-rpc.1 2017-04-22 11:53:10.029 info binrpc client is trying to connect to 192.168.178.28:8701 with ["xmlrpc_bin://192.168.178.23:8701","hm-rpc.1"]
! hm-rpc.1 2017-04-22 11:53:10.026 info binrpc server is trying to listen on 192.168.178.23:8701
! hm-rpc.1 2017-04-22 11:53:09.780 info starting. Version 1.4.6 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v4.2.6

Gruß vom Volker

Auch von meiner Seite die Bestätigung, dass sowohl mit der hm.rpc Version 1.4.5 als auch mit der 1.4.6 der Adapter Schwierigkeiten macht.

Ich nutze 2 Instanzen vom hm.rpc (einmal wireless, einmal wired).

Mit der 1.4.5 konnte nur der wireless (hm.rpc.0) gestartet werden, der wired (hm.rpc.1) blieb rot.

Mit der Version 1.4.6 gehen beide Instanzen auf grün, wechseln dann jedoch rhytmisch wieder auf rot.

Anbei mein Log hierzu:

Dieses Verhalten kann ich bestätigen.

Das Problem:

Beim Update (genau gesagt davor) wurde der laufende Prozess nicht gekillt)

Nach dem Update sollte er wieder gestartet werden, statt dessen wurde er zum zweiten mal gestartet

Die Lösung:

Die Instanz stoppen und die dann noch laufende zusätzliche Instanz über die Konsole killen und anschließend die hm-rpc (im admin) wieder starten.

Das Vorgehen:

über die Konsole mit

cd /opt/iobroker
sudo iobroker stop hm-rpc.0

ggf. auch weitere Instanzen

dann die PID des noch laufenden Prozesses herausbekommen mit:

ps -A | grep io

irgendwo steht dann noch z.B. ein

20234 ? 00:05:30 io.hm-rpc.0

Anschließend diesen Prozess killen

sudo kill -9 20243

Dies ggf. mit weiteren Instanzen ebenfalls durchführen.

Dann wieder mit

sudo iobroker start hm-rpc.0

die Instanz starten, alternativ über den Reiter Instanzen im Admin

Viel Erfolg

Rainer

Moin Rainer,

Deine Anleitung war Perfekt!!

Bei mir waren es insgesamt 6 hm-rpc Prozesse die noch liefen :shock:

Nun macht es einen guten Eindruck und die v.1.4.6 scheint wieder zu machen was sie soll

Vielen Dank für deine superschnelle Hilfe und ein erholsames Wochenende.

Auch von mir ein Danke!

Alles wieder in Ordnung!

Bei mir liefen 8 Prozesse! Jetzt muss ich nur noch meine Wemos updaten.

Gruß

Wolfgang

Hallo,

bei mir läuft seit den Updates die 2. Instanz (CUXD) nicht mehr richtig.

Apr 23 11:12:07 homematic-ccu2 daemon.info cuxd[307]: INIT 'xmlrpc_bin://192.168.178.23:8701' ''
Apr 23 11:12:07 homematic-ccu2 daemon.info cuxd[307]: INIT 'xmlrpc_bin://192.168.178.23:8701' ''
Apr 23 11:12:12 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(init) request
Apr 23 11:12:12 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(listDevices) request
Apr 23 11:12:12 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(init) request
Apr 23 11:12:19 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(init) request
Apr 23 11:12:19 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(listDevices) request
Apr 23 11:13:49 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(ping) request
Apr 23 11:14:23 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(init) request
Apr 23 11:15:09 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(init) request
Apr 23 11:15:09 homematic-ccu2 daemon.warn cuxd[307]: process_rpc_request(192.168.178.23) - illegal XMLRPC(listDevices) request

Ich habe den Tip von Rainer schon ausprobiert. Nichts.

Gruß Marco

Das ist auch kein Wunder, da cuxd nur bin-rpc versteht.

Mit dem letzten fix des Adapters sollte das dann wieder gehen.

Gruß

Rainer

Ich hab auch Probleme mit CUXD.

Meine Version ist die 1.4.6.

Ich wollte die Kanäle neu einlesen, weil ich einige Datenpunkt umbenannt hatte (hieß mal LIGHT, jetzt GAS).

Im WebUI soeht es folgendermaßen aus:

Also unter Objekte hab ich das gelöscht und Geräte neu einlesen den haken rein:

Wenn ich jetzt Speichere und den haken bei neu einlesen setze und speichere springt das erstmal ständig zwischen Connected und Disconnected hin und her:

hm-rpc.2	2017-04-26 22:35:30.088	info	Disconnected
hm-rpc.2	2017-0 4-26 22:35:30.088	info	Connected
hm-rpc.2	2017-04-26 22:35:30.088	info	Disconnected
hm-rpc.2	2017-04-26 22:35:30.087	info	Connected
hm-rpc.2	2017-04-26 22:35:14.878	info	Connected
hm-rpc.2	2017-04-26 22:35:14.877	info	new CUxD devices/channels after filter: 0
hm-rpc.2	2017-04-26 22:35:14.854	info	binrpc -> listDevices 125
hm-rpc.2	2017-04-26 22:35:14.360	info	binrpc client is trying to connect to 192.168.178.205:8701 with ["xmlrpc_bin://192.168.178.220:8711","hm-rpc.2"]
hm-rpc.2	2017-04-26 22:35:14.357	info	binrpc server is trying to listen on 192.168.178.220:8711
hm-rpc.2	2017-04-26 22:35:13.249	info	starting. Version 1.4.6 in /media/1c31537f-0f75-428d-9228-7b54b469086c/programms/iobroker/node_modules/iobroker.hm-rpc, node: v4.8.2
hm-rpc.2	2017-04-26 22:35:10.137	info	Disconnected
hm-rpc.2	2017-04-26 22:35:10.133	info	binrpc -> 192.168.178.205:8701 init ["xmlrpc_bin://192.168.178.220:8711",""]
hm-rpc.2	2017-04-26 22:35:06.628	info	Connected
hm-rpc.2	2017-04-26 22:35:05.702	info	binrpc -> listDevices 125
hm-rpc.2	2017-04-26 22:35:05.197	info	binrpc client is trying to connect to 192.168.178.205:8701 with ["xmlrpc_bin://192.168.178.220:8711","hm-rpc.2"]
hm-rpc.2	2017-04-26 22:35:05.193	info	binrpc server is trying to listen on 192.168.178.220:8711
hm-rpc.2	2017-04-26 22:35:04.048	info	starting. Version 1.4.6 in /media/1c31537f-0f75-428d-9228-7b54b469086c/programms/iobroker/node_modules/iobroker.hm-rpc, node: v4.8.2
hm-rpc.2	2017-04-26 22:35:01.001	info	terminating
hm-rpc.2	2017-04-26 22:35:00.979	info	Disconnected
hm-rpc.2	2017-04-26 22:35:00.977	info	binrpc -> 192.168.178.205:8701 init ["xmlrpc_bin://192.168.178.220:8711",""]

Die Datenpunte stimmen dann nicht (LIGHT anstelle GAS):