Browsed by
Tag: CMS

Field Tech Console Update

Field Tech Console Update

Earlier this year, I made a post regarding  a new module called the Field Tech Console. If you haven’t read it, I’ll give a quick breakdown of what it does. I’ve updated a few functions, so this is the latest rundown of its abilities:


  • Tracks location and time of installer while they process a calendar event
  • Allows provisioning of CXNK related ONT’s through the Calix Management System and Compass
  • Allow management to manage by exception and view installer performance without interference
  • Process different types of jobs
    • Fiber installs
    • Customer appointments
    • Custom events
  • Access work orders module

Lets break these down a bit more, the tracking is a function that has existed since the beginning of the field tech console. Depending on the requirements of the calendar event, the technician is required to update their status in order to complete a job. Different jobs have different statuses. Fiber installs consist of four required updates before a job can be completed. Enroute, arrival, installing and clean up. Customer appointments have only three.


Enroute, arrival and clean up. When a tech leaves for their job, they update the status to enroute. Upon arrival, the status is updated. If the tech is installing fiber, once they start installing the line or ONT, they update the status to installing. Once they are done, they update the status to cleaning up. Each status record records the time and approximate location of the job. This builds a timeline of how long it took to complete each operation. Management can view this information live though the FMS, and can further piece together jobs in a given day to see how much time the tech was idle or being utilized.

For example, a contractor has three fiber installs to perform in a given day. Their time card reflects seven hours of work, meaning each job takes 2.33 hours. If the installer is updating their statues correctly there should be a nice distribution between finished times and enroute updates to the next job. If each job only takes one hour to complete, some time stamps would reflect abnormal behavior. It could be time and distance between jobs, time between status updates, etc. It is not fool proof, but it makes it hard to fake consistently over time if you have historical data to compare to. One such flaw is faking the amount of time it takes between installing and cleaning up. If an installer finishes the job, and sits in their truck for 45 minutes before updating the job to cleaning up or finished, how does management ensure that the data is accurate? These kinds of issues are fairly difficult to track and eliminate. Using other data, this kind of issue can almost be removed from the equation. In Calix based systems, the access platform will send out syslog messages when ONT’s arrive or depart from the network. If that time is compared to when the status was updated, a manager can know that if a job took 45 minutes after the ONT came online, abnormal behavior has occurred. It’s these kinds of data metrics that can allow managers to easily track performance of contractors, and take corrective action when needed.


Now, that explanation took a bit longer than expected, but hopefully you get the idea of how this kind of data is useful. Lets discuss the latest improvement in the field tech console. Integration of Calix’s Compass suite with ONT provisioning through the FMS. With the new addition of Activate in the Calix Compass suite, it required that I start integrating our FMS software more with their cloud based system, rather than just CMS. The transition to using both systems has proven to be a little bit clunky for now, and adds anywhere between five to 20 seconds of provision time when creating records within the FMS. But, with our size, and the amount of jobs being processed, 20 seconds equates to very little in terms of money. I’ll have to make another post talking about the new CC+ integration, but for now, I’ll just link to the public repo.

When a tech has completed provisioning the ONT, they set the status of the job to Cleaning Up. This update removes the ONT provision wizard from the screen, and prompts the tech to provision the WiFi. The tech has the ability to modify an existing provisioning record, or create a new one (only one record can be stored).



These changes occur instantly if the ONT is online and operational. If the ONT is still provisioning, once it performs its check-in with Consumer Connect, it will download the provisioning record. The idea of this is to allow an installer to provision, and configure an ONT for a customer without pulling out a laptop, or connecting any wires. In addition, management can gather valuable statistics on installs. The following flowchart depicts the actual sequence and parties involved in one job or cycle.


This idea will go live in two days on 10/24/2016. A goal of this implementation is that it will generate one less call to support to get WiFi configured. Being an organization that prides itself on adding more value to the customer, a one stop, quick and accurate experience has shown to increase customer retention rate. This project has created two major milestones. It has gotten me to update the field tech console, fixing many of the bugs that existed previously, and it has finally gotten me to write the CC+ API. The PHP Class is publicly accessible on my Github page, and the like to repo is above.

In the future, once development dies down a little, I am hoping to focus on increasing the effectiveness of the processes and sequences I have created. Utilizing what I am learning on operation management classes will hopefully allow me to benchmark, optimize and replace existing flows in an attempt to reduce overhead and cut out waste.

Current Road-map

  • Integrate appointments to provision other types of Calix devices, 801F’, 844E, etc
  • Remove partially, or fully CMS functionality, and switch to CC+
  • Integrate Activate and other services
  • Integrate raw TR-069 requests in managing and provision units
  • Auto generate and monitor installs and control limits, and only alert when a system is out of control
No light at the end of the tunnel

No light at the end of the tunnel

I figured it was time to update this blog a bit, give a quick update on changes I have been making within the FMS. I haven’t died, or quit, I have just been quiet. Since my last post, a few things have happened.

Calix released E3 units. This is cool, but has been difficult to get around to. The FMS was built to work with CMS and its NBI. can hang under an E7 (or at least in a later release), but do not use CMS in any way shape or form. Calix has created Activate, a cloud based solution and SDN. I could rant about this all day, but I am not too impressed with the whole idea. I don’t like being at the mercy of the cloud for my operations. In addition, Activate is not even ready to be used. We have been waiting for over a month from Calix to get access to the program. Finally, our management VLAN is severed from the internet, making it impossible to currently implement without a VPN. I guess we’ll just keep making exceptions until our security is nonexistent.

In addition to having to rewrite most of my code to work around Consumer Connect, I have to rewrite the following modules:

  • Customer  management
  • Inventory
  • ONT Provisioning
    • Field Tech Console
  • Alerting

I’ll have to keep ya’ll updated as finish these. I have been working on each one, but none are currently completed.




Major overhaul of the Plant Management module. This will deserve its own post, and it will be a LONG one. Our plant management is almost out of its infant stage, and will soon have good enough core or baseline, that a lot of cool things could be attached to it. Currently the plant management handles

  • Objects
    • Sites
    • Regions
    • Terminals
    • Splitters
    • Splice Cases
    • Segments
      • Fiber Cables
  • Distributive and traditional fiber network layouts
  • Fiber cable and splicing management
    • Generation of splice diagrams
  • Optical cable and route tracing

I assure you, there is a lot more that it could be doing, and it could be doing its current operations much better. None the less, I will be continuing to work on.


Locate module and Work Orders module. These two modules are smaller, but none the less important. Locate record management and tracking makes it easy to plot out where and when areas need to be located. I have been in discussions with our Public Works department to assist them in locating and time management. Work orders are another small, cross module, module that allows our utility technicians to determine what needs to be finished. It is accessible through our field tech console, and has the ability for contractors to have limited access into our system. Paper work orders are no longer needed, and these are auto generated, and virtually filed. These can be assigned to segments and drops currently. Techs can simply pull up their work order list, go out and fix the issue, update it in the field, and be monitored by appropriate individuals. Finally, inspectors have the ability to analyze the record and approve or reject the work order completion. Notes and various attributes record what actions were taken and resources were used.

So, overall I have been busy. I am hoping to start wrapping up some of these modules in the near future. It currently seems like a never ending job. At least for one person :/

On the bright side, I’ll be back in Corvallis soon enough for my final year at OSU.


Also, some photos of this year.

Field Tech Dashboard

Field Tech Dashboard

Well, as promised from my previous post, I am here to unveil the new module that will CHANGE THE WAY WE INSTALL FIBER CUSTOMERS (not really, but I like to think so).

So naturally, after a fiber project is completely built out and operational, the time and effort needed to build a system is finally found and put to good use. During our initial build out, we hired contractors to assist in the deployment of ONT’s for our new fiber customers. Being contractors, they would show up late for work, leave early, put in poor effort and often just caused a lot of issues. This issue resolved itself once we discontinued our relationship with the contracting company, and took some of their employees (the good ones). So given that we no longer have an issue with getting ONT’s installed in people’s houses, this module has lost some of it luster. But hey, I am a college student getting paid to write code right now, so I gotta find something productive to do!

In reality, this module will actually solve some other issues that we currently are facing, but able to manage.


The field tech console is web interface that allows technicians, installers and contractors, manage and track their appointments. In the past, we have used Google Calendar to push out appointments to contractors and installers. While this has worked, see my calendar post for information as to why I chose to leave Google and move my calendar system in house.


So just looking at the screenshot, it is easy to see now what this page does. Appointments are stacked, and the appointment details are provided to techs.

So, nothing really fancy, Google calendar does the same thing, only looks fancier. Not true!

The ability for calendar events to tie into customer records is helpful, since it can allow for appointments to be assigned to customers or tax lots for later reference. For example, I can look at a customer record and see who has visited them in the past.


Not only that, but these events have statuses. Depending on how the repair/install/pizza run went, it is recorded if it was successful, incomplete, or the customer failed to show up.

Location tracking

Now this feature is probably the most ideal for managers, and least ideal for really bad contractors that lie on their time cards. There are stages built within an event that tracks the progress.


Allowing for updated statues during an event utilizes the device and it GPS. Coordinates of the device are recorded under the record, along with the time stamp. From the last post, the result is a map on the final report for the event.


So now we can know when and where a status was updated, and how much time it took between each task. Now, one issue we thought of was that the numbers would just be fudged. While true, if a manager were closely watching each event, it would be apparent when times did not match up, or locations looked off. Apart from that, time stamps on when ONT’s arrived and departed are recorded, which can be compared to the time that it was provisioned.

ONT Provisioning

One of the coolest features that the field tech console allow for, is real time provisioning of ONT’s Not to get too much into detail, but if you read my previous post on the Calix NBI, you know that I used to provision units using the FSAN on each ONT. That FSAN is assigned to the customer and used for numerous things. One big issue that we have just dealt with in the past, was that ONT’s are assigned to customers now, instead of using a registration id. This means the ONT’s are provisioned in the morning, and handed to the installers. This resulted in the wrong ONT getting assigned to the wrong customer sometimes. We no longer really have this issue, but we can use this new feature to our advantage.

Usually on the day of an installation, a customer record is created, and a configuration for the ONT is made. This prevents techs from providing the wrong service package to the customer, or messing up other options.

ONT’s are assigned from inventory to installers. Those installers can then take batches of ONT’s to their vehicles and not requiring them to check into the office every morning. Since the FMS tracks ONT’s, it presents a list of assigned ONT’s to an installer.


Then, once an appointment has been set to the proper status, the ONT can be provisioned!




Obviously this is where the happy green success message would show up, if the ONT wasn’t already provisioned elsewhere. But you can see how an installer has more autonomy to do their job now, and we can actually collect more information than before! This module is going live this Friday, and we will begin to see first hand how well it works. Of course there is more to this module, but I have shown you a good portion of it. There is room in the future for expansion and addition of new features.

CMS Northbound Interface Integration

CMS Northbound Interface Integration

When designing the fiber management system (FMS), one feature that is heavily needed is a way to provision, change, delete and query customer hardware. Being a Calix shop, we have our access hardware, and a CMS (Calix Management System) which aggregates all of our access systems together. The result is a one stop shop where ONT’s can be managed across one interface. Upon our first deployment, we used the CMS client to provision and manage all of our ONTs for customers. We quickly hated using the client for most of our operations. Now, I am in no way trying to bash on Calix’s software, I believe CMS is a great tool. The client on the other hand… I cannot say the same.

CMS features a northbound interface, which uses an XML http request to exchange information between CMS and 3rd party applications. The CMS API is by far my most favorite/hated feature of CMS. The ability to use any language to make and retrieve requests is awesome, but can be difficult in some languages. Let me provide a bit more information. My FMS system uses PHP for a majority of its server side rendering. I know how bad PHP is, but in the case of making a system web accessible from any device drastically limited my options. Further details on why I used PHP will be made available in later posts. The access diagram for the FMS is below.


Since PHP is a server side translator, it allows our information to processed within the same network as our CMS server, ultimately allowing clients to process information in the management VLAN where the CMS and Calix equipment resides. With the ability to serve clients with data via web, any mobile or web accessible device can use the FMS.


Tying it all in

Given my current situation, I cannot explain in detail what I have fully done with this API, but what I can explain are some of the modules we tied the northbound interface in with. Some modules that reside within the FMS are: customer records and basic inventory. Which means that we can record our ONT inventory and tie it in with customers, allowing me to knew exactly what customer has what piece of equipment. Further with the northbound interface module, I can use the inventory data to generate a configuration linked with a customer and have one click customer provisioning. Behold! I have made our jobs so much easier! Upon creating a customer, I can provision an ONT in under 15 seconds, record where it is going, where it was and I don’t even have to unpack the unit. I can hand it to an installer, whom installs it at a customers house, plugs it in, turns it on and it provisions instantly. Now, while a lot of this does not involve the northbound interface, you can see how I have taken three tasks and combined them in to a fluid cycle. (Note, this cycle does not work for everyone, or every deployment, which is why I am currently redesigning the process). Inventory is linked to a customer, and linked to CMS, and the installer does not have to carry a buttset around and punch in registration ID’s. I wish I could explain more, because with the addition of other modules, and more detail, A LOT more cool stuff can be automated.


Building the module, take one

When I first designed this module, I honestly knew almost zero about http requests, Python, XML, SOAP, PHP, JS and Love. Refrain from laughing as much as possible when you see my code and keep in mind that I was learning. Also keep in mind that once I got this working, it became the bomb-diggity for our company. I decided to use Python, because WHY THE HECK NOT?!? Mostly I was aware of how bad PHP was, and I wanted to make the service available even in non web based environments (Yes, I am aware that CLI PHP is thing, but still I wanted to refrain from using it as much as possible). So I got to work writing python scripts that would take in FSAN numbers, ONT ID’s, bandwidth profiles and everything else as arguments. I could then process it and and spit out the result. The code was messy, some outputs were XML, others were strings, and some just returned a 1 or 0. If you want to see how bad it is, here is the link to the github repo. A lot has changed and is not reflected there. It is now a lot more structured and allow for provisioning of SIP services, RG interfaces, and other stuff.


Provisioning was a simple three click process, auto assigned the ONT to a customer, and made an note in the inventory on the whereabouts of an ONT. It even allowed for error checking allowing us to make sure things went smoothly during the provisioning process.


CMS integration was a module added in the early stages of the FMS development. After the module was created, it didn’t really change mostly because it just worked. Only until recently, have I had to make drastic changes to the FMS, which pretty much required a redesign of the whole module.

The process effectively went from this


to something like this


🙁 I am sorry that I cannot show you the inner workings of my new process, but I have been instructed that I cannot display the secret sauce. As you can see, this new flow is a lot more structured and has a lot more going on. What I can explain is what makes the system a heck of a lot better than before.


Dynamic, TO THE MAX

One benefit this new module brings is the added dynamic that previously did not exist. The old code relied on a config file that stored all of the variables for connecting to CMS.


This limitation allowed you to only query one system from one CMS server. The new module allows for dynamic addition and deletion of systems, meaning that multiple CMS hosts with multiple access systems can be queried.

access systems blur

One feature, or more rather byproduct (but works as a feature) is that the result is transferred to the client as an http request. This allow AJAX queries from server to client to occur instantly and be encoded in JSON. I effectively created and API for an API :P. I feel that there is potential to allow access from 3rd party devices/systems in the future.

I must wrap up this post, but before I do, I want to show you a screenshot of what kind of useful data is possible through the new Calix-NIAPI module.


It is certainly cool what can be done when you tie services into one another! If you have questions regarding this system, processes involved please contact me at