Seite 1 von 1
CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 13:10
von MartinBr
Hallo,
seit dem Update auf die CUxD-Version 1.12 erhalte ich jede Minute die folgende Meldung:
Dec 11 13:02:12 homematic-ccu2 daemon.warn cuxd[30806]: unknown request method 'ping' 'ping'
Dec 11 13:03:42 homematic-ccu2 daemon.warn cuxd[30806]: unknown request method 'ping' 'ping'
Ich habe aber kein Ping Gerät aktiviert (2803001).
Was kann das sein? Hat jemand eine Idee?
Gruß
Martin
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 13:17
von Bulli
Hallo
du hast iobroker im Einsatz richtig?
@Uwe hat sich mit 1.12 was geändert? Bei 1.11 war das noch nicht.
Hier mal ein Test mit 1.11 und 1.12
Code: Alles auswählen
Dec 9 11:06:12 homematic-ccu2.fritz.box cuxd[324]: Received SIGTERM signal.
Dec 9 11:06:12 homematic-ccu2.fritz.box cuxd[324]: CUx-Daemon stop(0)
Dec 9 11:06:12 homematic-ccu2.fritz.box cuxd[324]: unlink(/var/cache/cuxd_proxy.ini)
Dec 9 11:06:12 homematic-ccu2.fritz.box cuxd[324]: save paramsets(/usr/local/addons/cuxd/cuxd.ps) size:620
Dec 9 11:06:59 homematic-ccu2.fritz.box cuxd[661]: write_pid /var/run/cuxd.pid [661]
Dec 9 11:07:00 homematic-ccu2.fritz.box logger: dutycycle.tcl[671] /var/cache/cuxd_dutycycle.txt 120 started
Dec 9 11:07:00 homematic-ccu2.fritz.box cuxd[661]: system(extra/dutycycle start)
Dec 9 11:07:00 homematic-ccu2.fritz.box cuxd[661]: CUx-Daemon(1.11) on CCU(2.29.23) start PID:661
Dec 9 11:07:00 homematic-ccu2.fritz.box cuxd[661]: load paramsets(/usr/local/addons/cuxd/cuxd.ps) size:620 update(-48s):Sat Dec 9 11:06:12 2017
Dec 9 11:07:00 homematic-ccu2.fritz.box cuxd[661]: write_proxy /var/cache/cuxd_proxy.ini (661 /usr/local/addons/cuxd/ 1.11 2.29.23 0)
Dec 9 11:07:02 homematic-ccu2.fritz.box cuxd[661]: CUX2801001 device update from (1.12) to (1.6)
Dec 9 11:07:28 homematic-ccu2.fritz.box cuxd[661]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:10:29 homematic-ccu2.fritz.box cuxd[661]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:13:30 homematic-ccu2.fritz.box cuxd[661]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:16:31 homematic-ccu2.fritz.box cuxd[661]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:19:31 homematic-ccu2.fritz.box cuxd[661]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:20:23 homematic-ccu2.fritz.box cuxd[661]: Received SIGTERM signal.
Dec 9 11:20:23 homematic-ccu2.fritz.box cuxd[661]: save paramsets(/usr/local/addons/cuxd/cuxd.ps) size:616
Dec 9 11:21:15 homematic-ccu2.fritz.box cuxd[749]: write_pid /var/run/cuxd.pid [749]
Dec 9 11:21:16 homematic-ccu2.fritz.box logger: dutycycle.tcl[759] /var/cache/cuxd_dutycycle.txt 120 started
Dec 9 11:21:16 homematic-ccu2.fritz.box cuxd[749]: system(extra/dutycycle start)
Dec 9 11:21:16 homematic-ccu2.fritz.box cuxd[749]: CUx-Daemon(1.12) on CCU(2.29.23) start PID:749
Dec 9 11:21:16 homematic-ccu2.fritz.box cuxd[749]: load paramsets(/usr/local/addons/cuxd/cuxd.ps) size:616 update(-53s):Sat Dec 9 11:20:23 2017
Dec 9 11:21:16 homematic-ccu2.fritz.box cuxd[749]: 2 device-paramset(s) loaded!
Dec 9 11:21:16 homematic-ccu2.fritz.box cuxd[749]: write_proxy /var/cache/cuxd_proxy.ini (749 /usr/local/addons/cuxd/ 1.12 2.29.23 0)
Dec 9 11:21:18 homematic-ccu2.fritz.box cuxd[749]: CUX2801001 device update from (1.6) to (1.12)
Dec 9 11:21:23 homematic-ccu2.fritz.box cuxd[749]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:22:54 homematic-ccu2.fritz.box cuxd[749]: unknown request method 'ping' 'ping'
Dec 9 11:24:24 homematic-ccu2.fritz.box cuxd[749]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:25:55 homematic-ccu2.fritz.box cuxd[749]: unknown request method 'ping' 'ping'
Dec 9 11:27:25 homematic-ccu2.fritz.box cuxd[749]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:28:55 homematic-ccu2.fritz.box cuxd[749]: unknown request method 'ping' 'ping'
Dec 9 11:30:26 homematic-ccu2.fritz.box cuxd[749]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:31:56 homematic-ccu2.fritz.box cuxd[749]: unknown request method 'ping' 'ping'
Dec 9 11:33:27 homematic-ccu2.fritz.box cuxd[749]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:34:57 homematic-ccu2.fritz.box cuxd[749]: unknown request method 'ping' 'ping'
Dec 9 11:35:35 homematic-ccu2.fritz.box cuxd[749]: Received SIGTERM signal.
Dec 9 11:35:35 homematic-ccu2.fritz.box cuxd[749]: CUx-Daemon stop(0)
Dec 9 11:35:35 homematic-ccu2.fritz.box cuxd[749]: unlink(/var/cache/cuxd_proxy.ini)
Dec 9 11:35:35 homematic-ccu2.fritz.box cuxd[749]: save paramsets(/usr/local/addons/cuxd/cuxd.ps) size:620
Dec 9 11:35:52 homematic-ccu2.fritz.box cuxd[800]: write_pid /var/run/cuxd.pid [800]
Dec 9 11:35:53 homematic-ccu2.fritz.box logger: dutycycle.tcl[810] /var/cache/cuxd_dutycycle.txt 120 started
Dec 9 11:35:53 homematic-ccu2.fritz.box cuxd[800]: system(extra/dutycycle start)
Dec 9 11:35:53 homematic-ccu2.fritz.box cuxd[800]: CUx-Daemon(1.11) on CCU(2.29.23) start PID:800
Dec 9 11:35:53 homematic-ccu2.fritz.box cuxd[800]: load paramsets(/usr/local/addons/cuxd/cuxd.ps) size:620 update(-18s):Sat Dec 9 11:35:35 2017
Dec 9 11:35:53 homematic-ccu2.fritz.box cuxd[800]: write_proxy /var/cache/cuxd_proxy.ini (800 /usr/local/addons/cuxd/ 1.11 2.29.23 0)
Dec 9 11:35:55 homematic-ccu2.fritz.box cuxd[800]: CUX2801001 device update from (1.12) to (1.6)
Dec 9 11:36:06 homematic-ccu2.fritz.box cuxd[800]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:39:06 homematic-ccu2.fritz.box cuxd[800]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:42:07 homematic-ccu2.fritz.box cuxd[800]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Dec 9 11:45:08 homematic-ccu2.fritz.box cuxd[800]: INIT 'xmlrpc_bin://192.168.40.47:8701' 'hm-rpc.1'
Gruß
Bulli
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 13:31
von MartinBr
Richtig, ich habe den ioBroker im Einsatz. Da läuft die Alexa Integration am stabilsten, zumindest was die Cloud Connectoren angeht.
Ich vermute den Fehler auch in den externen Gateways. Ich habe alle Ping und Discover Instanzen auf dem ioBroker gestoppt.
Leider keine Besserung.
Gruß
Martin
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 13:42
von uwe111
Bulli hat geschrieben:@Uwe hat sich mit 1.12 was geändert? Bei 1.11 war das noch nicht.
Ja, damit die Schnittstelle einfacher zu debuggen ist, werden ab CUxD 1.12 Warnmeldungen bei ungültigen RPC-Methodenaufrufen geloggt.
system.listMethods liefert alle vom CUxD unterstützten RPC-Methoden. 'ping' ist hier nicht dabei. Da es sich um eine 'optionale' Methode handelt, dürften externe Dienste sie beim CUxD-Interface überhaupt nicht aufrufen.
Ich habe mal in der XMLRPC Doku nachgeschaut:
In der folgenden Liste mit [optional] gekennzeichneten Methoden müssen von einem konkreten Schnittstellenprozess nicht unbedingt exportiert werden. Bei Verwendung dieser Methoden ist mit einem Fehler zu rechnen, wenn nich vor dem Aufruf mit system.methodHelp oder system.listMethods die Existenz geprüft wird.
bool ping(String callerId)
Beim Aufruf dieser Funktion wird ein Event (im Folgenden PONG genannt) erzeugt und an alle registrierten Logikschichten versandt. Da das PONG Event an alle registrierten Logikschichten (wie bei allen anderen Events auch) verschickt wird, muss in einer Logikschicht damit gerechnet werden, ein PONG Event zu empfangen ohne zuvor ping aufgerufen zu haben.
Ich bin mir nicht sicher, ob ich diese Funktion wirklich implementieren will, da durch die PONG-Anwort an ALLE registrierten Logikschichten nur zusätzlicher Overhead generiert werden würde.
Viele Grüße
Uwe
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 14:57
von MartinBr
Hallo Uwe,
erstmal danke für deine schnelle Antwort. Wenn ich das richtig verstanden habe, dann kann ich die Warnmeldung ignorieren.
Kann man sie irgendwie ausblenden, so dass die Logs nicht "volllaufen"?
Gruß
Martin
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 15:03
von uwe111
Hallo Martin,
ja, die Meldung kannst Du ignorieren.
Nein, ausblenden kann man sie nicht. Aber volllaufen wird auch nichts, keine Angst.
Es wäre hier sowieso besser, das Problem beim Verursacher zu beseitigen.
Viele Grüße
Uwe
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 15:20
von Bulli
Hallo
sehe ich auch so, sollte in hm.rpc geändert werden.
@Martin stell einfach beim Adapter >>Verbindungs-Check Interval(sek) auf 86400<<< dann kommt die Warnung nur einmal am Tag
Gruß
Bulli
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 11.12.2017, 15:32
von MartinBr
Hallo Bulli,
das ist eine gute Idee
Ich hoffe, dass die Kollegen aus dem ioBroker Team hier mitlesen.
Danke und allen eine gute Woche.
Martin.
Re: CUxD: unknown request method 'ping' 'ping'
Verfasst: 02.03.2018, 16:55
von Bluefox
uwe111 hat geschrieben:Bulli hat geschrieben:@Uwe hat sich mit 1.12 was geändert? Bei 1.11 war das noch nicht.
Ja, damit die Schnittstelle einfacher zu debuggen ist, werden ab CUxD 1.12 Warnmeldungen bei ungültigen RPC-Methodenaufrufen geloggt.
system.listMethods liefert alle vom CUxD unterstützten RPC-Methoden. 'ping' ist hier nicht dabei. Da es sich um eine 'optionale' Methode handelt, dürften externe Dienste sie beim CUxD-Interface überhaupt nicht aufrufen.
Ich habe mal in der XMLRPC Doku nachgeschaut:
In der folgenden Liste mit [optional] gekennzeichneten Methoden müssen von einem konkreten Schnittstellenprozess nicht unbedingt exportiert werden. Bei Verwendung dieser Methoden ist mit einem Fehler zu rechnen, wenn nich vor dem Aufruf mit system.methodHelp oder system.listMethods die Existenz geprüft wird.
bool ping(String callerId)
Beim Aufruf dieser Funktion wird ein Event (im Folgenden PONG genannt) erzeugt und an alle registrierten Logikschichten versandt. Da das PONG Event an alle registrierten Logikschichten (wie bei allen anderen Events auch) verschickt wird, muss in einer Logikschicht damit gerechnet werden, ein PONG Event zu empfangen ohne zuvor ping aufgerufen zu haben.
Ich bin mir nicht sicher, ob ich diese Funktion wirklich implementieren will, da durch die PONG-Anwort an ALLE registrierten Logikschichten nur zusätzlicher Overhead generiert werden würde.
Viele Grüße
Uwe
Wie wird es erkannt, dass die Verbindung immer noch aktiv ist?