Error in Wget handler

Hi AK

I’ve had this error in my log for a long time and have never found the offending plugin. Is there a way I can trap for which plugin is causing the nil when it calls a wget?

2019-10-13 21:34:30.520 openLuup.http:: GET /data_request?id=lu_status2&output_format=json&DataVersion=27632241&Timeout=60&MinimumDelay=1500&=1571027652478 HTTP/1.1 tcp{client}: 0x560d31a0c1d8
2019-10-13 21:34:31.519 openLuup.http:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&
=1571027652479 HTTP/1.1 tcp{client}: 0x560d3194df08
2019-10-13 21:34:31.623 openLuup.http:: request completed (1 bytes, 1 chunks, 103 ms) tcp{client}: 0x560d3194df08
2019-10-13 21:34:31.970 luup.io.incoming:: bytes received: 51, status: OK tcp{client}: 0x560d31a726e8
2019-10-13 21:34:36.971 luup.io.incoming:: bytes received: 51, status: OK tcp{client}: 0x560d31a726e8
2019-10-13 21:34:38.485 openLuup.context_switch:: ERROR: ./openLuup/client.lua:172: attempt to index local ‘request_URI’ (a nil value)
2019-10-13 21:34:38.485 luup.delay_callback:: function: 0x560d30a2dfb0 ERROR: ./openLuup/client.lua:172: attempt to index local ‘request_URI’ (a nil value)
2019-10-13 21:34:40.229 luup.variable_set:: 20012.urn:micasaverde-com:serviceId:ZWaveNetwork1.LastPollSuccess was: 1571027350 now: 1571027680 #hooks:0
2019-10-13 21:34:40.442 openLuup.http:: request completed (15212 bytes, 1 chunks, 9921 ms) tcp{client}: 0x560d31a0c1d8
2019-10-13 21:34:41.525 openLuup.http:: GET /data_request?id=lu_status2&output_format=json&DataVersion=27632243&Timeout=60&MinimumDelay=1500&_=1571027652480 HTTP/1.1 tcp{client}: 0x560d31a0c1d8

The two lines of error messages are in the middle of the log. Not sure if the log text will wrap correctly…

Ah yes, there’s a couple of rubbish error messages!

  1. the context switch doesn’t tell you which device context!
  2. the callback doesn’t tell you which routine!!

…and although you get the hex address reference of which callback routine, there’s nowhere else you can check that against!

I think the best thing for me to do is to add the device number to the context switch error.

Now fixed in latest development version 19.10.14

Thanks. I’ll give it try later today.

That solved it! The TED5000 plugin was using a call_delay with an out of scope http param. This plugin probably runs without a glitch on a vera, as scope seems to be a little more strict in openLuup…

Thanks for the revision.

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules