Ahh, okay. I wouldn't worry too much about repeated calls then, unless perf becomes an issue. The request/response is fairly small.
On Wed, Jan 21, 2015 at 8:33 AM, 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]> 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] > http://lists.genieacs.com/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.genieacs.com/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.genieacs.com/mailman/listinfo/users
