Send all parameters on the same setParametersValue RPC


I have a problem with my provisioning flow and I think is because genieacs is trying to optimize the SPV response by omitting the parameters that already have the same value.
For example, if i want to set 3 parameters with declare:
declare(‘a.b.c.param1’, {value: now}, {value: ‘x’});
declare(‘a.b.c.param2’, {value: now}, {value: ‘y’});
declare(‘a.b.c.param3’, {value: now}, {value: ‘z’});

but param2 is already set to ‘y’, the SPV response will contain just param1 and param3 but my device will return a fail because all three parameters are mandatory and are required to be set in the same SPV.

I did try to make this via alias filtering with just one declare(‘a.b.c.[param1:x,param2:y,param3:z]’,{path:now}, {path:1}); but it’s the same thing.

One workaround i found is to make two SPV’s, first to change all 3 parameters to some random values and than back to the correct ones but it must be a better way. Is there a way to force genieacs to send all the parameters although they have the same value?

thank you for your time!

any suggestion for this problem?

First thing to do is refresh the three params to make sure they have the value you think they do. The data you see is the device model at the moment in time when the GPVs were done. Genie will not change a parameter it doesn’t think has changed. So refresh first, then see if the value thats stored in Genie is actually whats there.


thank you @akcoder for confirming this to me … exactly here is the problem.

I am refreshing the node first but because genieacs filters one or two of my params from the SPV, the provision script fails because all three params are mandatory on my device.

Is there a way to change this behavior without patching the genieacs code?


This sounds more like a flaw with the implementation on the device honestly. If parameter2 is set to the value of Foo, and the device confirms the value of parameter2 is Foo, there is no need to send that value again.