SetParameterValue set value that already exists

Hi all,

I have a strange situation where I need to re set the same exact value to the ceratin ParameterName to exact previous value:

When I GPV the ParameterName below it returns me “pushButton”
Device.WiFi.AccessPoint.10001.WPS.X_CABLELABS_COM_SetWPSMethod

When I try to do SPV “pushButton” the ACS doesn’t even interact with the device.

Is there any way to force SPV no matter the pre existing value?

Thanks and BR,
Janko

1 Like

Currently, you have to do a GPV before SPV in that situation.

Unfortunatly this is not the case here. Even if I do GPV the value will be read exactly the same as the one I need to set :frowning: so it seems that I don’t have any kind of work a round :frowning:

@zaidka might have another idea. But the only thing I can think of off the top of my head is to do a SPV with a dummy value, and then follow that up with a SPV with the desired value.

GenieACS is designed to be very, very fast. And the way it achieves this is through caching and an intelligent change detection mechanism. Unfortunately, all those things fall down in this very specific use case :(.

This sounds like a good workaround to try out. There’s no way to force an SPV when the current and desired values already match.

Hi, yes, this works and this is the current workaround I also use but this complicates all the provisioning scripts. The best thing will be to add a new parameter to the declare statement to skip the “already match” check and send the SPV anyway … something like:

declare(‘Device.OID’, null, {value: ‘xxx’, force:1});

This use case is needed where the device has mandatory parameters to be set … The simple example for this is trying to set a WANIPConnection from DHCP to Static, for which IP and Netmask are mandatory but if the connection already has the same IP and/or netmask assigned dinamicaly, it will send just the AddresingType:Static and 0 or 1 of the other 2 mandatory values which will result in a fault by the device.

1 Like

That won’t work. Genie executes the script multiple times until there’s no more changes to be pushed, so if you skip the check you’ll end up stuck in an infinite loop.

What i’m trying to say is that if you have many values that need to be set, send also the ones that have force = 1 (or some other more meaningful name - mandatory), even if they have the same value as the one from the database). This will lead to the following 3 scenarios:

  1. you have multiple declare with just the value (implicit mandatory:0) , the provisioning will suffer no change.

  2. you have multiple declare with {mandatory: 1} and all have the same declared value as in the database, no SPV will be pushed to the device, the script will stop

  3. you have multiple declare values with {mandatory: 1} and at least one needs to be set … the SPV will push to the device all values for which mandatory is 1. This will happen at the first run of the script and on the second one it will hit the second case and will stop.

is this doable?

1 Like

How does we support it?? if its a required to do that. means the value should be pushed to device even if it has the same value and GPV reported same.

Hi Kumar,

this was just a proposal, and this was not implemented AFAIK, can’t say exactly why. The only workaround I know for this is to set this parameters to random values and back to the correct ones … It’s stupid but it works.

cheers

1 Like