Understanding the Icons in the Software


CONNECTED - Normal:  A brown door with no icons on it means that the door is online and locked. When a user presents a valid credential, the door will unlock briefly to allow passage.

CONNECTED - Unlocked:  A door with a green padlock on it means the door in an Unlocked override mode, allowing free passage through the door without using a credential.  It will remain in this mode until it is manually returned to a Normal mode by a BlueWave administrator.

CONNECTED - Unlocked for Shift:  A door with a green padlock with a clock means the door is “Unlocked for Shift.” The door will return to a Normal mode when it reaches the end of its scheduled unlock shift.  

CONNECTED - Lockdown:  A door with a red padlock on it means the door is in an emergency Lockdown override mode and ONLY a credential programmed as a Master Card will work to open it. It will remain in this mode until it is manually returned to a Normal mode by a BlueWave administrator.

DISABLED:  A gray door means “Disabled” ­ the door is currently being ignored by the server. This is normal and you can refer to this Advanced Guide in the case that you want to make any adjustments to your door. In practice, this may mean that the door was temporarily taken offline for maintenance. In most cases, a disabled door will continue to function with its last programmed configuration, but it will not be able to receive updated permissions or report back audit events until it is re­enabled from the server in the BlueView software. 
OFFLINE - No Route to Controller:  A door with a yellow lightning bolt means­ the server is unable to communicate with the door controller due to a network outage of some kind. If the network outage is temporary, the door will be reconnected automatically when connectivity is restored. (Note that even if the controller is showing as offline, if it still has power, it may still be operating under its last known set of shifts and credentials.

OFFLINE - Not Connected:  A door with a red X means “Not Connected.” This indicates that the controller WAS offline, but the software is now able to ping it. The software will periodically try to resume connection to any controllers that are marked as “Not Connected.”

OFFLINE - Controller Failed:  A door with a yellow triangle with an exclamation point means “Controller Failed” ­ the server can reach the door on the network but is having trouble communicating with it. 


Connectivity Troubleshooting Steps


Determine the controller’s IP address.

Find the controller’s IP address by looking in the Door screen in BlueView software.  If the door has not yet been set up in BlueView, the IP address needs to be configured according to the Network Configuration Guide for NetGen Ethernet Controllers document.


Can you ping the controller’s IP address from the BlueView server?  

On the server hosting BlueView, open a command prompt.  Type the following command, followed by <Enter>:  

ping <controller’s ip address> -t 

(i.e. ping 192.168.1.103 -t)


Watch the output for at least several seconds, if not several minutes or longer.  There should be a consistent response with a less than 300ms response time to ensure consistent communication between the controllers and our software.  Use <Ctrl-C> to stop the ping cycle when you are done monitoring it.


If there is no ping response, check:

  • The NetGen Controller is powered on (green LED on the board is lit).

  • The NetGen controller has enough power - use a multimeter to measure the power at the board on the power input pins.  It should be within 10% of either 12V or 24V (depending on which input was used).

  • An ethernet cable is securely plugged in to the port on the NetGen controller.

  • The other end of the ethernet cable is plugged into a properly configured switch that has connectivity to the same network as the BlueView server.

  • There are blinking lights on either side of the ethernet port - this indicates basic connectivity.

  • Push the reset button to reboot the network component on the board.  This is a small white button on the short side of the board, counter clockwise from the ethernet port.  On boards with a silver covering, you may need a paper clip to get to the button.  The button should be pressed for about 1 second and then released.  The network component may take 10-15 seconds to reboot, then you can try the ping again.


    Depending on the NetGen version, it will look like one of these:




  • The ethernet cable itself has been inspected for damage, the cable run is no longer than 90 meters, and it tests good with a cable testing tool. 

  • There is no software or hardware firewall blocking ping communication between the BlueView server and the NetGen controller.

  • Can the device be found using BlueView’s Discover Door Controllers tool or Lantronix DeviceInstaller tool?  Try to match up the MAC address printed on the network port of the NetGen to the MAC address reported in the search tools to verify the controller’s IP address.  (If it did not have a static IP address, its IP address could have changed.)  Refer to the Network Configuration Guide for NetGen Ethernet controllers for more information.


If the ping was successful (or once it has been re-established), then the next step is:


Verify network settings on the network component.

  • Open the web browser of your choice and browse to the IP address of the NetGen controller.  

  • When prompted for a User Name and password, use Username admin and Password PASS for newer boards, OR Username admin with no password for older NetGen boards.


For newer NetGen boards, you should get a screen like this:


(Note that sometimes browser security settings and software/hardware firewalls can prevent the proper display of this page.)


  • In this screen, verify that the following settings are correct based on your network configuration:

    • IP Address/Subnet Mask

    • Default Gateway

    • If you need to make changes to the network settings, select Network in the orange column, then click the Configuration link towards the top of the page. Click Submit if you make a change.

  • Select “Line” in the orange column, then click the Configuration link towards the top of the page.  Make sure the Baud Rate is set to 115200. Click Submit if you make a change.

  • Select “Tunnel” in the orange column, then click the Packing Mode link towards the top of the page.  The settings should be as follows:

    • Mode:  Timeout

    • Threshold:  512 bytes

    • Timeout:  12 milliseconds

    • Click Submit if you make a change.

  • When finished, select “System” in the orange column, then hit the “Reboot” button.  (This is somewhat equivalent to pushing the reset button on the NetGen controller.)


(For older NetGen boards, the interface will be slightly different, but the relevant settings are the same.  Contact us if you need assistance with the particulars.)

Connect to the controller using the BlueWave software (BlueView and Bluelink Network Services).

  • If the door is in “Not Connected” mode (red X), right click on it in the System Overview and select Reconnect.  

  • If “Reconnect” is not available, an alternate method to force a reconnect attempt is to open the Door configuration screen, select the door, click on “Advanced Configuration,” and then close both windows.  

  • Wait for several seconds to see if there is any indication that the door reconnected.  You can also close BlueView and re-open it to make sure the display information is up to date.

  • If it was not able to reconnect, try stopping and restarting BNS.  Be aware when you do this that on larger systems it can take several minutes for BNS to fully restart and update door status.


Narrow down causes for “Controller Failed.”

When “Controller Failed” is not cleared by a Reconnect, look for other possible causes.


  • Firmware Version - If your firmware version is too old (or too new) for the version of BlueView you are running, you may need to upgrade (or downgrade) your firmware using BlueView Firmware Updater.  In some cases you will also need to upgrade your BlueView software.

BlueView Version

Supported Firmware Version(s)

HW1:  older boards with silver cover

HW2:  newer boards without cover

14.0-14.3(NO LONGER SUPPORTED

Version 3 (3.0115, 3.0124) for HW1 ONLY

14.3.6-15.0 (NO LONGER SUPPORTED)

Version 3 (3.0124) for HW1

Version 5 (5.0024) for HW2

15.1

Version 3 (3.0124) for HW1

Version 5 (5.0024) for HW2

Version 7 (7.0103) for HW2

16-16.1

Version 3 (3.0124) for HW1

Version 5 (5.0024) for HW2

Version 7 (7.02.02) for HW2

17

Version 3 (3.0124) for HW1

Version 5 (5.0024) for HW2

Version 7 (7.03.00) for HW2

18+

Version 3 (3.0124) for HW1

Version 5 (5.0024) for HW2

Version 7 (7.03.02) for HW2


  • Scrambled Firmware - Have there been any recent power outages, brownouts, or surges that may have affected that door?  Anyone servicing it that could have disrupted the power supply?  These types of things can damage the firmware code itself.  The fix is to re-program the board with firmware using the BlueView Firmware Updater tool.  


  • Hung Firmware - Sometimes, due to power disruptions as described above, or other factors, the firmware can get in a state where it stops responding, even to attempts to update firmware.  In this case, try to power cycle the entire NetGen controller by cutting power to the power input on the board and then restoring it.  After you do this, hit the white reset button to reset the network component, as well.


  • Lantronix Settings - See above under “Verify settings on the network component”


  • Duplicate IP addresses - could this door have been accidentally assigned the same IP address as another device on the network?  Is its static IP address in the DHCP range for your network?  One way to test is to run a continuous ping cycle from the server (see first troubleshooting step, above).  While someone is monitoring the ping cycle from the server, disconnect the ethernet cable from the NetGen controller for several seconds, then plug it back in.  Is there a ping response while the cable is unplugged?  If so, there is some other device on the network with that IP address.


  • Firewall - could a software or hardware firewall be blocking communication (but allowing ping traffic though).  A quick way to eliminate this possibility is to temporarily turn off all firewalls and see if the problem is resolved.  If it’s a firewall issue, exceptions may need to be configured for TCP ports 6500, 6501 and 10001. 


  • Other software communicating to same IP address - has BlueView ever been installed on another machine on this network?  If so, double-check to make sure BNS is not running on that old machine. On any machine other than the current machine running BlueView (including clients), if Bluelink Network Services appears in the list of services, it should be stopped and then its startup mode should be set to Disabled using the Windows Services tool.  (Typically, if this is happening it would affect ALL controllers that are configured in BlueView, not just one.)  Alternatively, could there be an older access control system (or other software platform) trying to communicate with the same IP address that the NetGen controller is using?

 


Advanced Troubleshooting:  Intermittent Connectivity Issues


Software and Firmware Updates

We continuously work to improve our product, so we suggest that whenever it’s feasible, the BlueView software be upgraded to the latest released version and NetGen firmware be updated to the latest version supported by the NetGen hardware.

Computer Specifications

Does the computer running BlueView meet the minimum hardware requirements to run BlueView software and (if it’s running on the same machine) SQL Server?  

Bandwidth Limitations

Could traffic during high-peak times on your network be intermittently interfering with network traffic to and from the NetGen controllers?  Is there network traffic from security cameras or other bandwidth hogs flowing through the same switches?

Switch Configuration

If your network uses managed switches, take advantage of the switch’s management tools to help diagnose the problem.  Is the port configured correctly?  Could the port be over-subscribed?  Is there a full/half-duplex mismatch?

Power Instability

On doors where the power supply is providing a borderline amount of power and/or where the power supply may vary the power input slightly, this can cause the network component on our board to lose connection.  Most often we see power supply instability on systems that are powered with a POE switch.  


Example:  A standard BlueWave installation with a mag lock, motion detector, REX button, reader, and NetGen controller draws about 0.9 A.  POE standard 802.3af provides for a maximum of 15.4 Watts of power, which at 12V comes out to 1.28 A (Voltage X Current = Power) available.  Accounting for line loss, and depending on the exact equipment at the door, some installations will bump into the limit.


Additionally, not all POE switches are created equal.  Check the documentation for your switch to determine both the maximum power available at a single port as well as the TOTAL power that the whole switch can provide at one time.  Some switches will not provide the maximum power at all ports on the switch at one time.

BNS Software Settings

There are some settings for the Bluelink Network Services software that allow advanced users to customize communication parameters for the best performance for their particular network configuration.  Changing these settings typically will not resolve whatever issue is causing the controller to go offline, but it can make a difference in how the disruption is handled and how noticeable it is to the end user.


Use Windows Explorer to find this file (Program Files may be Program Files (x86) on 64-bit machines):

C:\Program Files\BlueView\Bluelink Network Services\BNS.exe.config


We suggest making a copy of the file before you begin, so that you can revert the settings later, if needed.  Then, open it with Notepad.  (If you're on Windows 7 or higher, you may need to run Notepad as an Administrator so that you can save it when you're done.) 


Explanations for each setting are located above the setting.  To change a setting, change the part between the quotation marks after the word value.  


For example:


<add key="NetGenReconnectInterval" value="120"/>


Once you’ve made the change, save the file and then restart BNS.  Give the system at least several minutes to stabilize before evaluating the effect of any change you’ve made.  Below are the settings that will be most relevant for connectivity issues.




<!-- NETGEN POLL INTERVAL:  BNS periodically polls all NetGen controllers.       -->

        <!--                 This value sets how long BNS will wait BETWEEN poll cycles. -->

        <!--                 For example, if there are 10 controllers, BNS will poll     -->

        <!--                 all 10 in succession, and then wait for the time specified  -->

        <!--                 before polling all 10 controllers again.                    -->

        <!--   Note that this is a 2-part parameter:                                     -->

        <!--     NetGenPollInterval defines the quantity                                 -->

        <!--     NetGenPollUnits defines the units (can be Minutes or Seconds)           -->

        <!-- DEFAULT VALUE:  5 Seconds                                                   -->

        <add key="NetGenPollInterval" value="5" />


        <!-- Units for the Poll Interval (values are Minutes or Seconds)                 -->

        <add key="NetGenPollUnits" value="Seconds" />


        <!-- NETGEN TIMEOUT:  When attempting to communicate with the controller, -->

        <!--                  this value specifies how long BNS will wait for a   -->

        <!--                  response before timing out                          -->

        <!-- UNITS:  Milliseconds                                                 -->

        <!-- DEFAULT VALUE:  1500 milliseconds                                    -->

        <add key="NetGenTimeout" value="1500" />


        <!-- NETGEN RECONNECT INTERVAL:  This specifies how often BNS will attempt -->

        <!--                             to reconnect to offline controllers.      -->

        <!-- UNITS:  Poll Cycles, as in NETGEN POLL INTERVAL (above)               -->

        <!--         For example, if the Poll Interval is set to 5 seconds and the -->

        <!--         Reconnect Interval is set to 360, then BNS will attempt to    -->

        <!--         reconnect every 360 x 5 seconds = 1800 seconds, which is      -->

        <!--         about every 30 minutes                                        -->

        <!-- DEFAULT VALUE:  60 poll cycles, which at the default Poll Interval   -->

        <!--                of 5 Seconds equals 5 minutes                         -->

        <add key="NetGenReconnectInterval" value="60" />


        <!-- COMM FAILURE RETRY THRESHOLD:  In some network situations,            -->

        <!--           controllers intermittently may fail to respond.  To prevent -->

        <!--           these controllers from prematurely being marked offline,    -->

        <!--           BNS will retry communication with these controllers up to   -->

        <!--           the specified amount of times before marking them as        -->

        <!--           offline.  This applies only to NetGen controllers.          -->

        <!-- UNITS:  Retries, which will happen once each NetGen Poll Cycle.       -->

        <!-- DEFAULT VALUE:  3                                                     -->

        <add key="CommFailureRetryThreshold" value="3" />


<!-- PERMISSIONS RETRIES:                                                    -->

        <!--                If a controller scheduled for a permissions update       -->

        <!--                is offline, BNS will attempt to reconnect to it before   -->

        <!--                pushing permissions.  This setting specifies how many    -->

        <!--                attempts to reconnect can fail before BNS assumes        -->

        <!--                failure.  BNS will reschedule the permissions push       -->

            <!--                in intervals that increase in multiples of 5 seconds.    -->

            <!--                After the maximum number of retries, BNS will not        -->

        <!--                    attempt to push permissions again until the user         -->

        <!--                requests another permissions activation.                 -->

        <!-- UNITS:         Number of retry attempts                                 -->

        <!-- DEFAULT VALUE:  10 (retry for approximately 5 minutes)                  -->

        <add key="PermissionsRetries" value="10" />


Other

There may be other circumstances that cause controllers to go offline.  If your problem has not been resolved by the steps listed here, please contact us at support@bluewavesecurity.com and describe your problem in detail, including the answers to questions like:


  • What version of BlueView software are you running?

  • What version of NetGen firmware are you running?

  • Did it start happening recently or has it had this problem since it was installed?

  • How often does the controller go offline?

  • When it goes offline, what steps bring it back online?  (Reset button, power cycle, software reconnect, BNS restart, etc.)

  • Is it always the same controller(s) that go offline?

  • If it is affecting more than one controller, do they all go offline at the same time?

  • What hardware is on the doors (mag lock or strike, readers, motion sensors, etc.)?

  • How are the NetGens powered?

  • What steps have you tried to resolve the issue, and what were the results?