[Problem] HM-RPC-Adapter 1.4.5 läuft nicht richtig (on/off)
-
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.6Gruß 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.0ggf. auch weitere Instanzen
dann die PID des noch laufenden Prozesses herausbekommen mit:
ps -A | grep ioirgendwo steht dann noch z.B. ein
20234 ? 00:05:30 io.hm-rpc.0Anschließend diesen Prozess killen
sudo kill -9 20243Dies ggf. mit weiteren Instanzen ebenfalls durchführen.
Dann wieder mit
sudo iobroker start hm-rpc.0die 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
-
auch bei mir wieder alles im grünen Bereich!
Herzlichen Dank!
-
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):
