WeatherTRAK Server Communication and Mobile App Lag Issues

Updated December 19, 2022 4 min read

Purpose:  This article is intended to assist with the general troubleshooting, diagnostics, tracking and investigation of reported performance delay or lag issues on the WeatherTRAK website and mobile app that is NOT related to any known HydroPoint outage or maintenance issues.

Best Troubleshooting Practices

When encountering controller communication issues do the following first: 

1.  Verify firmware is updated to the current version and update if necessary.

2.  Verify modem type and suggest a modem upgrade if applicable.

Firmware and modem updates have proven to resolve a significant portion of latency issues and will be the first troubleshooting steps that engineering suggests. These should be standard items to check in all cases and would help prevent future issues related to cell communication. If issues continue beyond that, proceed to the steps below in gathering the required data and test results.

Collecting real-time data: 

Wherever possible, gathering data during a real-time event will provide the most useful information. If you are working with a customer currently experiencing an issue, and they are able to help provide more detailed data, do the following:

1.  Find out the specific issue that is occurring. 

    a.   What command(s) are they running? If slow, what specifically is running slow? 

          For example - Delayed valve turn-on after starting manual from the mobile app.

2.  Ask the customer to launch a web browser from the device having the issue by logging into: https://www.weathertrak.net/

    a.  If the page loaded successfully, ask how the experience was. Was it normal or slow?

    b.  If the page fails to load in a browser search for a speed test and have them run it to see if their connection is still good.

    c.  If the speed test fails, have them reset the connection on the phone, or maybe even reboot the phone, and then try again.

3.  Have the customer go to the physical controller panel if they are nearby.

     a.  Go to the COMM 16 menu screen and press star (*) to initiate a test message. 

          Note: An OptiFlow panel needs to be unlocked first

    b.  If the test fails, there is potentially a communication issue with the controller.

    c.  If the test passes, try the mobile app again.

4.  Collect the following REQUIRED information for logging a case to Engineering

     a.  Date and time of occurrence

     b.  Serial number(s)

     c.  Phone/device type (iOS or Android) and model type

     d.  Phone/device carrier (ATT, Verizon, etc.)

     e.  Phone signal strength (bars and speed test data)

     f.  Controller signal strength (from COMM 02 menu screen)

     g.  Username (customer account that is logging into the app)

Collecting Post Issue Data 

If it is not possible to gather data during a real-time event, the following information can still be used to investigate. If you are working with a customer not currently experiencing an issue, check the following:

1.  Find out the specific issue that was occurring 

     a.  What command(s) were they running? If slow, what specifically was running slow?

          For example: Delayed valve turn-on after starting manual from the mobile app

2.  Collect the following REQUIRED information for logging a case to engineering: 

     a.  Date and time of occurrence

     b.  Serial number(s)

     c.  Phone/device type (iOS or Android) and model type

     d.  Phone/device carrier (ATT, Verizon, etc.)

     e.  Username (customer account that is logging into the app)

Why do we need this required information? 

In order to have engineering research an issue, it’s absolutely necessary to gather the information above whenever you are working with a customer that is experiencing issues or delays. Any additional test/data results you can also gather is helpful to further isolate specific issues. Without this data, engineering will not be able to perform any meaningful research.

How do we gather data? 

If possible, test in real-time while you have the customer on the phone to see if the issues can be duplicated. If a real-time test isn’t possible, have the customer provide all the necessary details from when the issue was encountered. We need to start training the customers to provide this data any time they experience performance issues that aren’t related to a known outage or problem on our side.

What happens next? 

Update all details in the case notes. Be sure to include the listed items above. Send the info to Escalations (Pedro) so it can be updated in the escalation tracker. This will provide direction to Engineering for investigation and further review. If you have any questions, please let Escalations or your manager know.

Additional general troubleshooting tips and best practices to rule out possible site or cell coverage issues:

Below are a few additional steps and best practices that can also be helpful in some instances, or if we have a user that is willing and able to help provide further data: 

1.  Try using a different network (WI-FI or Ethernet vs cellular).

2.  Try using a different device (desktop, laptop, tablet, phone).

3.  Try using the website as opposed to the mobile app and compare the performance between the two.

4.  Verify individual user’s data threshold limits aren’t throttling a user’s performance (example: monthly data limits have been exceeded and the carrier has downgraded available usage).

5.  Dedicated private networks should generally work better than public or shared networks. If using a shared connection, switch to a dedicated connection and compare the performance.

Was this article helpful?