API based signal tests
Richard Verbrugge
richard.verbrugge at myhighspeed.ca
Wed Jan 21 14:07:15 EST 2015
Reducing the inform time to 30 seconds prior to starting the DELT test can
reduce the test time significantly.
I would paste the php code and javascript code in here to show the script
for graphing using Google's API but it is too much text. (I could put this
on the GenieACS page somewhere?)
On top if it I need all the correct formulas for the DELT test:
HLOGpsus, HLOGpsds, QLNpsus, QLNpsds, SNRpsus, SNRpsds, BITSpsds, BITSpsus,
And if someone has it for HLINpsds and HLINpsus .. (I know Dan), it would be
most appreciated.
/RV
-----Original Message-----
From: Users [mailto:users-bounces at lists.genieacs.com] On Behalf Of
users-request at lists.genieacs.com
Sent: January-21-15 12:37 PM
To: users at lists.genieacs.com
Subject: Users Digest, Vol 2, Issue 24
Send Users mailing list submissions to
users at lists.genieacs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.genieacs.com/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at lists.genieacs.com
You can reach the person managing the list at
users-owner at lists.genieacs.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Users digest..."
Today's Topics:
1. Re: API based signal tests... (Dan Morphis)
2. Re: API based signal tests... (Christopher Chance)
3. Re: API based signal tests... (Dan Morphis)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Jan 2015 08:30:15 -0900
From: Dan Morphis <dan at milkcarton.com>
To: Community support for GenieACS users <users at lists.genieacs.com>
Subject: Re: API based signal tests...
Message-ID:
<CAHwrMLf5PS=YOyH8M_UVeuGJs75FUyvUWJYw1EMAb6sSXQd6cw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <cchance at newtechgrp.com>
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
> Users at lists.genieacs.com
> http://lists.genieacs.com/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.genieacs.com/pipermail/users/attachments/20150121/a1bcecf8/att
achment-0001.html>
------------------------------
Message: 2
Date: Wed, 21 Jan 2015 13:33:50 -0400
From: Christopher Chance <cchance at newtechgrp.com>
To: Community support for GenieACS users <users at lists.genieacs.com>
Subject: Re: API based signal tests...
Message-ID:
<73FF4E82D3029143B484F1859227DA72D8C2A5691C at POSEIDON.newtechgrp.net>
Content-Type: text/plain; charset="utf-8"
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 <dan at milkcarton.com> 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
<cchance at newtechgrp.com<mailto:cchance at newtechgrp.com>> 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
Users at lists.genieacs.com<mailto:Users at lists.genieacs.com>
http://lists.genieacs.com/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.genieacs.com/pipermail/users/attachments/20150121/489aa31b/att
achment-0001.html>
------------------------------
Message: 3
Date: Wed, 21 Jan 2015 08:36:32 -0900
From: Dan Morphis <dan at milkcarton.com>
To: Community support for GenieACS users <users at lists.genieacs.com>
Subject: Re: API based signal tests...
Message-ID:
<CAHwrMLeYxAGDVKXJArP3r02MeuNdCnX9m3Nt9V5AWx9Qs5ACwg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <cchance at newtechgrp.com>
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
> <dan at milkcarton.com> wrote:
>
> By signal test, I presume you mean duel ended line test? If thats the
> case, you need to set
> *InternetGatewayDevice.WANDevice.1.WANDSLDiagnostics.LoopDiagnosticsSt
> ate* 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 <
> cchance at newtechgrp.com> 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
> Users at lists.genieacs.com
> http://lists.genieacs.com/mailman/listinfo/users
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.genieacs.com
> http://lists.genieacs.com/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.genieacs.com/pipermail/users/attachments/20150121/f161aa54/att
achment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Users mailing list
Users at lists.genieacs.com
http://lists.genieacs.com/mailman/listinfo/users
------------------------------
End of Users Digest, Vol 2, Issue 24
************************************
More information about the Users
mailing list