Schedules triggering differently after upgrade

Discussions about RaZberry - Z-Wave board for Raspberry computer
Post Reply
bogr
Posts: 190
Joined: 16 Nov 2015 22:46

Schedules triggering differently after upgrade

Post by bogr »

Hi!

After the upgrade to v3.0.3, the Schedules (in Automation menu) seem to trigger differently. I have a DummyDevice that is associated (Association app) to a CodeDevice which sends a HTTP request to trigger a wifi plug. When the DummyDevice is triggered by a Schedule the log looks like:

Code: Select all

[2020-02-03 07:12:00.150] [I] [core] ---  DummyDevice_100 performCommand processing: {"0":"off"}
[2020-02-03 07:12:00.159] [I] [core] Notification: device-info (device-OnOff): {"dev":"Plug_dd","l":"off","location":""}
[2020-02-03 07:12:00.162] [I] [core] ---  Code_Device_switchBinary_99 performCommand processing: {"0":"off"}
[2020-02-03 07:12:00.450] [I] [core] Notification: device-info (device-OnOff): {"dev":"Nedis Plug","l":"off","location":""}
[2020-02-03 07:12:00.607] [I] [core] [BaseModule-92] Set lastLevel to off for DummyDevice_100 (was on)
[2020-02-03 07:12:00.753] [I] [core] [BaseModule-92] Set lastLevel to off for Code_Device_switchBinary_99 (was on)
and the actual Plug is not triggered through the association and the CodeDevice.

But when I trigger the DummyDevice e.g. clicking in the Smart Home UI it works fine and the log shows:

Code: Select all

[2020-02-03 19:11:38.187] [I] [core] ---  DummyDevice_100 performCommand processing: {"0":"off","1":{}}
[2020-02-03 19:11:38.225] [I] [core] Notification: device-info (device-OnOff): {"dev":"Plug_dd","l":"off","location":""}
[2020-02-03 19:11:38.228] [I] [core] ---  Code_Device_switchBinary_99 performCommand processing: {"0":"off"}
[2020-02-03 19:11:38.403] [I] [core] Notification: device-info (device-OnOff): {"dev":"Nedis Plug","l":"off","location":""}
[2020-02-03 19:11:38.557] [I] [core] [BaseModule-92] Set lastLevel to off for DummyDevice_100 (was on)
[2020-02-03 19:11:38.703] [I] [core] [BaseModule-92] Set lastLevel to off for Code_Device_switchBinary_99 (was on)
and the Plug is triggered as it should.

I guess the behaviour should not be different in the two scenarios above?
User avatar
PoltoS
Posts: 7565
Joined: 26 Jan 2011 19:36

Re: Schedules triggering differently after upgrade

Post by PoltoS »

Should not be different. But the log loog identical, no?

BTW, I see the difference in calls to performCommand: {"0":"off","1":{}} versus {"0":"off"}
bogr
Posts: 190
Joined: 16 Nov 2015 22:46

Re: Schedules triggering differently after upgrade

Post by bogr »

Yes, that's exactly what is different in the log. But how it affects the actual DummyDevice and the association to the CodeDevice I don't know. That's the only difference I could spot when comparing the calls, so I guess it's having an impact? Somehow the CodeDevice is not making the necessary HTTP request to the plug device.
bogr
Posts: 190
Joined: 16 Nov 2015 22:46

Re: Schedules triggering differently after upgrade

Post by bogr »

I think I have a clue what is happening. From the CodeDevice I removed the system(curl...) call to the plug and replace it with a script instead. Then I got the following in the log:

Code: Select all

[2020-02-07 06:21:05.485] [I] [core] Error: Command timeout
    at Error (native)
    at CodeDevice.eval (eval at <anonymous> (automation/modules/CodeDevice/index.js:146:8), <anonymous>:1:1)
    at CodeDevice.act (automation/modules/CodeDevice/index.js:146:3)
    at self.controller.devices.create.handler (automation/modules/CodeDevice/index.js:88:10)
    at _.extend.performCommand (automation/classes/VirtualDevice.js:316:25)
    at automation/modules/BindDevices/index.js:53:11
    at Array.forEach (native)
    at handlerLevel (automation/modules/BindDevices/index.js:48:29)
    at EventEmitter.emit (automation/lib/eventemitter2.js:311:33)
    at _.extend.emit (automation/classes/VirtualDevice.js:342:26)
so it seem that the CodeDevice, which is now calling the script, which has the http-call to the actual plug, is showing that the http-request is timing out.
Post Reply