I figured about as much, tho I do plan to do timed polling on all devices down 
the line so we can build up historical stat graphs... And if I don't keep it 
tidy the task queues could get nasty if I query half hour or so...

On Jan 21, 2015 1:35 PM, Christopher Chance <[email protected]> wrote:

Ahhh I should have clarified no were wimax not DSL. So when I say signal test 
basically I'm pulling fresh snr and rssi levels from the device via the 
gerparmvalues call

On Jan 21, 2015 1:32 PM, Dan Morphis <[email protected]> wrote:
By signal test, I presume you mean duel ended line test? If thats the case, you 
need to set 
InternetGatewayDevice.WANDevice.1.WANDSLDiagnostics.LoopDiagnosticsState to 
"Requested" After I set that value, I immediately add a refreshObject on the 
InternetGatewayDevice.WANDevice.1.WANDSLDiagnostics object so that when the CPE 
comes back online, the diagnostic results will be sent right away.

While the test is being performed, I periodically query the acs to see if the 
refreshObject task is done. When its done, then I pull back the updated data 
and graph out the results.

If you want to ensure that back to back tests aren't performed, query the tasks 
for the device. And if you see "Requested" for LoopDiagnosticState, then delete 
that task. Speaking of, I should probably add that to my code :)

If you are interested in the formulas for decoding HLOGpsus, HLOGpsds, QLNpsus, 
QLNpsds, SNRpsus, SNRpsds, BITSpsds, BITSpsus, etc let me know.

-dan


On Wed, Jan 21, 2015 at 7:30 AM, Christopher Chance 
<[email protected]<mailto:[email protected]>> wrote:

Ok I got my OSS system working to pull signal tests from devices and display 
for my helpdesk,



Basically  what I have it doing is…



1.       Connects to MongoDB on GenieACS box, to perform a Serial Number query 
to find the DeviceID, (as our backend staff knows the SN not the OID etc).

2.       Run a getParamaterValues API request to refresh the signal (using 
timeout = 10000, if it doesn’t respond 200 the device is offline right?)

3.       If #2 returns 200 then run a devices query on API to grab the signal 
results

a.       If #2 returns 202 then return “signal test results not available”.



Simple enough I think right? Let me know if you see any flaws or something I 
missed J



But there is 1 issue I think, if my OSS staff clicks signal test and the device 
is offline, and we have some staff that will keep trying to get a test, it will 
keep adding tr69 tasks to the queue… or if they do a signal test and device is 
off and then an hour later they do it again and so on the device may have 5-10 
getParmValues pending because it was offline.



Is their any way to restrict the queue of the device, or abort the  
getparamatervalues request if it doesn’t return 200? So never queue it for 
later… update values, if not possible abort instead of queue?



Or If theres a way, maybe that I can call something on the API, from my OSS 
automatically that if I get a 202, run an api to wipe that devices queue?



Chris

_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.genieacs.com/mailman/listinfo/users




_______________________________________________
Users mailing list
[email protected]
http://lists.genieacs.com/mailman/listinfo/users

Reply via email to