ACS reverting change to device it just issued?

1

Hi,
I am attempting to modify the periodic update interval of my device via this curl command:

curl -i ‘http://xxx.xxx.xxx.xxx:7557/devices/C0EE40-sentrius-RG1xx29D9CE/tasks’ -X POST --data ‘{“name”: “setParameterValues”,“parameterValues”:[[“InternetGatewayDevice.ManagementServer.PeriodicInformInterval”,“42”]]}’

This seems to successfully queue the task - although unlike previous versions of GenieACS - I can’t easily view pending tasks for my devices…

The issue is - when the device consumes the task - I am seeing this in the log:

Feb 13 20:17:49 RG1xx29D9CE daemon.notice easycwmpd: send Inform
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: receive InformResponse from the ACS
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: send empty message to the ACS
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: received SetParameterValues method from the ACS
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: external: execute set value InternetGatewayDevice.ManagementServer.PeriodicInformInterval 42
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: external: execute apply value
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: send SetParameterValuesResponse to the ACS
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: received SetParameterValues method from the ACS
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: external: execute set value InternetGatewayDevice.ManagementServer.PeriodicInformInterval 300
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: external: execute apply value
Feb 13 20:17:50 RG1xx29D9CE daemon.notice easycwmpd: send SetParameterValuesResponse to the ACS

So it seems like the ACS very briefly sets the interval in my device to the new value - and then sends the old value to the device?

Am I reading these logs wrong - or am I queuing up the task wrong?

thanks

2

The issue turns out to be my unfamiliarity with the “Provisioning” script feature in 1.2.9 - which my previous installation of 1.2.1 back in 2018 or earlier did not have.

The “inform” provisioning script was the culprit.
As a work-around - I modified the hard coded value of “300” there to the lower value I needed.