CUxD: unknown request method 'ping' 'ping'

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Moderator: Co-Administratoren

Antworten
MartinBr
Beiträge: 393
Registriert: 25.01.2017, 10:51
Wohnort: Bei Berlin
Hat sich bedankt: 3 Mal
Danksagung erhalten: 8 Mal

CUxD: unknown request method 'ping' 'ping'

Beitrag von MartinBr » 11.12.2017, 13:10

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
RaspberryMatic-3.59.6 auf Tinkerboard S, CUxD 2.6, XML-1.20, ioBroker (HM,HMIP, Zigbee, Zwave und Shelly) und Alexa in einer VM unter Proxmox, VitoComfort 200

Bulli
Beiträge: 494
Registriert: 29.04.2014, 18:38
Hat sich bedankt: 2 Mal
Danksagung erhalten: 9 Mal

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von Bulli » 11.12.2017, 13:17

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

MartinBr
Beiträge: 393
Registriert: 25.01.2017, 10:51
Wohnort: Bei Berlin
Hat sich bedankt: 3 Mal
Danksagung erhalten: 8 Mal

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von MartinBr » 11.12.2017, 13:31

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
RaspberryMatic-3.59.6 auf Tinkerboard S, CUxD 2.6, XML-1.20, ioBroker (HM,HMIP, Zigbee, Zwave und Shelly) und Alexa in einer VM unter Proxmox, VitoComfort 200

Benutzeravatar
uwe111
Beiträge: 4807
Registriert: 26.02.2011, 22:22
Hat sich bedankt: 3 Mal
Danksagung erhalten: 240 Mal
Kontaktdaten:

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von uwe111 » 11.12.2017, 13:42

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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.11, SSH KeyDir

MartinBr
Beiträge: 393
Registriert: 25.01.2017, 10:51
Wohnort: Bei Berlin
Hat sich bedankt: 3 Mal
Danksagung erhalten: 8 Mal

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von MartinBr » 11.12.2017, 14:57

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
RaspberryMatic-3.59.6 auf Tinkerboard S, CUxD 2.6, XML-1.20, ioBroker (HM,HMIP, Zigbee, Zwave und Shelly) und Alexa in einer VM unter Proxmox, VitoComfort 200

Benutzeravatar
uwe111
Beiträge: 4807
Registriert: 26.02.2011, 22:22
Hat sich bedankt: 3 Mal
Danksagung erhalten: 240 Mal
Kontaktdaten:

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von uwe111 » 11.12.2017, 15:03

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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.11, SSH KeyDir

Bulli
Beiträge: 494
Registriert: 29.04.2014, 18:38
Hat sich bedankt: 2 Mal
Danksagung erhalten: 9 Mal

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von Bulli » 11.12.2017, 15:20

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

MartinBr
Beiträge: 393
Registriert: 25.01.2017, 10:51
Wohnort: Bei Berlin
Hat sich bedankt: 3 Mal
Danksagung erhalten: 8 Mal

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von MartinBr » 11.12.2017, 15:32

Hallo Bulli,

das ist eine gute Idee :lol:

Ich hoffe, dass die Kollegen aus dem ioBroker Team hier mitlesen.

Danke und allen eine gute Woche.

Martin.
RaspberryMatic-3.59.6 auf Tinkerboard S, CUxD 2.6, XML-1.20, ioBroker (HM,HMIP, Zigbee, Zwave und Shelly) und Alexa in einer VM unter Proxmox, VitoComfort 200

Bluefox
Beiträge: 779
Registriert: 20.02.2011, 19:55

Re: CUxD: unknown request method 'ping' 'ping'

Beitrag von Bluefox » 02.03.2018, 16:55

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?

Antworten

Zurück zu „CUxD“