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 so it seems that I don’t have any kind of work a round
@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 :(.
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:
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.
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:
you have multiple declare with just the value (implicit mandatory:0) , the provisioning will suffer no change.
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
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.
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.