CUxD: unknown request method 'ping' 'ping'
Moderator: Co-Administratoren
-
- 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'
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
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
-
- 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'
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
Gruß
Bulli
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'
Bulli
-
- 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'
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
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
- uwe111
- Beiträge: 4819
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 245 Mal
- Kontaktdaten:
Re: CUxD: unknown request method 'ping' 'ping'
Ja, damit die Schnittstelle einfacher zu debuggen ist, werden ab CUxD 1.12 Warnmeldungen bei ungültigen RPC-Methodenaufrufen geloggt.Bulli hat geschrieben:@Uwe hat sich mit 1.12 was geändert? Bei 1.11 war das noch nicht.
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.
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.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.
Viele Grüße
Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
-
- 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'
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
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
- uwe111
- Beiträge: 4819
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 245 Mal
- Kontaktdaten:
Re: CUxD: unknown request method 'ping' 'ping'
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
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 Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
-
- 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'
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
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
-
- 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'
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.
das ist eine gute Idee
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
Re: CUxD: unknown request method 'ping' 'ping'
Wie wird es erkannt, dass die Verbindung immer noch aktiv ist?uwe111 hat geschrieben:Ja, damit die Schnittstelle einfacher zu debuggen ist, werden ab CUxD 1.12 Warnmeldungen bei ungültigen RPC-Methodenaufrufen geloggt.Bulli hat geschrieben:@Uwe hat sich mit 1.12 was geändert? Bei 1.11 war das noch nicht.
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.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.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.
Viele Grüße
Uwe