NBI script behaves differently

Help
1

Hi,

I have this NBI php script that behaves strangely:

<?php

require 'vendor/autoload.php';
use GuzzleHttp\Client;

$IMEI = $argv[1];
set_time_limit(180);

$client = new Client([
    'timeout'  => 5.0,
]);

$response = $client->request('GET', 'http://10.100.4.38:7557/devices/', [
    'query' => [
                'query' =>'{"InternetGatewayDevice.WANDevice.1.X_NOTION_WANNetConfigInfo.IMEI":"' . $IMEI . '"}', 
                'projection' => '_deviceID._id'
                ]
]);

$body = $response->getBody();
//var_dump(json_decode($body));
$arr = json_decode($body,true);
//print_r ($arr);
if (!$arr) {
        echo "DNF \n";
        exit;
}

$id = "";
foreach ($arr as $dev){
        if (isset($dev["_id"])) {$id = $dev["_id"];}
}
//$file = "/var/log/genieacs/output.txt";
//file_put_contents($file, $id);
$response1 = $client->request('POST', 'http://10.100.4.38:7557/devices/' .$id. '/tasks?connection_request', [
    'body' => '{ "name": "setParameterValues", "parameterValues": [["InternetGatewayDevice.DownloadDiagnostics.DownloadURL", "http://speedtest.bhtelecom.ba/100MB.bin", "xsd:string"], ["InternetGatewayDevice.DownloadDiagnostics.Interface", "InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1", "xsd:string"],["InternetGatewayDevice.DownloadDiagnostics.DiagnosticsState", "Requested", "xsd:string"]] }'
]); 
echo('ID is: '.$id);

$response2 = $client->request('POST', 'http://10.100.4.38:7557/devices/' . $id. '/tasks?connection_request', [
		'body' => '{"name": "getParameterValues", "parameterNames": ["InternetGatewayDevice.DownloadDiagnostics.DiagnosticsState"]}'
	]); 

?>

Sometimes it runs both SPV and GPV methods, sometimes just SPV and sometimes just GPV.

What could be the reason for such a strange behavior?

Best regards,

Tarik

2

I found the reason for this issue. It was related to the fact that I actually sent 2 NBI requests in one POST method (i.e. I sent in one code line Connection request and SPV method together ). When I separated these two into two POST requests each, the issue hasn’t appeared any more.

3

This helped but it didn’t resolve the issue in all occasions. It seems that sometimes when the device is already configured with the target value, or the parameter was recently refreshed and the cached value matches the requested value GenieACS determines the task is redundant
and silently drops it before sending it to the CPE. For that reason I added another SetParameterValues action with some dummy value on the targeted parameter before the correct value is entered via SetParameterValues. This way the success rate is 100%

4

That seems like logical behaviour from GenieACS. If the value is already what you want it to be, why set it?