VirtualParameters with index instances


I have a rather strange question. Is there a way to have index instances in VirtualParameters. For example:

  • I would like to read docsis cable modem signals from external script on every PII
  • You don’t always know upfront on how many DS/US channels the cable modem is connected to. This means that when I would exectue the external script it would return something like this to the system:
    Device.X_DOCSIS.DownstreamNumberOfInstances: 4
    Device.X_DOCSIS.Downstream.1.Frequency: 210000000
    Device.X_DOCSIS.Downstream.1.SNR: 355
    Device.X_DOCSIS.Downstream.1.Signal: 100
    Device.X_DOCSIS.Downstream.4.Frequency: 310000000
    Device.X_DOCSIS.Downstream.4.SNR: 355
    Device.X_DOCSIS.Downstream.4.Signal: 100

I know it’s a strange request, but I have to give it a try :slight_smile: I think that altering data in the mongodb would be possible, but this is not how I would like to do it.

thanks for the reply and keep up the good work.


I asked this 3-4 yrs ago. Not possible. One way you can kind of accomplish your goal is using json. This is how I keep track of TR-143 diag data.

As for why I’ve done it this way, the TR-069 spec only specifies the CPE has to send a 8 DIAGNOSTICS COMPLETE event. But no other information about what diagnostic event occurred. So before a diagnostic is requested of the CPE, I store a bit of data about what diagnostic action was requested (IPPing, upload speedtest, download speedtest, UDPEcho, DSL loop, wifi, etc), and sometimes extra information like in the case of DSL loop diagnostics, I need to know which line instance the diag was performed on. When the 8 DIAGNOSTICS COMPLETE event comes back, I spin through the items in the vparam and figure out which one has a status of ‘Requested’ then I know what data to capture, do a little pre-processing on it and then package up the data and send it to our subscriber management server.

I have a vparam called Diagnostics. Here is the data currently stored in it for one of our customers.

  "Upload": {
    "source": "CAF",
    "timestamp": "2022-03-24T23:03:15-08:00",
    "entityId": 2738775,
    "completed": 1648191835327,
    "status": "SUCCESS"
  "Download": {
    "source": "CAF",
    "timestamp": "2022-03-24T23:04:14-08:00",
    "entityId": 2738849,
    "completed": 1648191890935,
    "status": "SUCCESS"
  "IPPing": {
    "source": "Dashboard",
    "timestamp": "2022-03-31T23:59:08-08:00",
    "entityId": 7931473,
    "completed": 1648799955061,
    "status": "SUCCESS"

Nicely done, but not completely applicable in my case :frowning:
I think I’ll need a separate redis and mongodb in order to store this information. The goal is to check DOCSIS upstream/downstream signal values on every boot, bootstrap, periodic events. This data can only be collected via snmp (external queuing would make most sense). I have an idea on how to achieve this and present the data on the external web portal (much work need’s to be done). The same mechanism can later be used even for xDSL/GPoN CPEs where you collect the data directly from the CPE and store the data via queuing to the external time series db or mongodb.

Create a provisioning script for that, which reads the data and then stores it away.
I am currently using influxdb for the data storage.
I show the data in grafana, which I have embedded into genieacs UI.

Maby I can show you the scripts. It is in a very early stage and not the best option for your topic.

Have a look at this Extract eventcode from inform request - #3 by zaidka

This can be applied on the thing with the multiple instances /docsis channels. Currently I have not implement that. Maby I am going to for my DSL bonding lines.

1 Like

Thanks a lot. I think I got it now.

Here are the scripts I use to write the Data into influxdb:
The provision script:

the ext script:

And the preset for that:

Name		Channel	Weight	Schedule	Events	Precondition	        Provision	Arguments
monitoring		    -100		                Tags.debug IS NOT NULL	monitoring	"WRITE"	
monitoring_r		-99			                Tags.debug IS NOT NULL	monitoring					
1 Like