If Gateways Unexpectedly Stop Communicating with iMonnit Enterprise

The information in this article can help you address the issue if you find that all gateways suddenly stop sending data to iMonnit Enterprise.

Reviewing iMonnit Enterprise

The first component to review is iMonnit Enterprise. These steps will confirm the server is accepting gateway communication.

Check your Version

Monnit currently supports iMonnit Enterprise version 4.0 and later. While basic support for legacy iMonnit Enterprise 3.5.0.0 and later may possible. Versions prior to 3.5.0.0 are no longer supported. It is worth noting that upgrading from version 3.5.0.0 and later is possible, while upgrade support to versions prior to 3.5.0.0 was dropped.

Upgrades of iMonnit Enterprise are included within 12 months of purchasing your Enterprise license. If your key is less than 12 months old, you can download and install Enterprise 4.0 from a supported version at no additional cost. If you have an Enterprise version key older than 12 months, a 20% maintenance fee will be charged for the new license. Please be prepared to provide your iMonnit Enterprise key or sales order number to Monnit Support when reaching out for assistance.

Confirm your Enterprise Wireless Gateway Server service is running

As per this article, make sure that your Enterprise Wireless Gateway Server service is running. This service is the process which takes data from the network over inbound port 3000 (by default, but it may have been changed during configuration) to the server, and processes delivers the data to the iMonnit Enterprise database. This service must be running in order for your gateways to deliver data to the iMonnit Enterprise database. The most common symptom of the service not running is that all gateways on the server will stop communicating with the Enterprise Server at the same time.

Confirm your gateway has been added to Enterprise

Be sure your devices have been added to the Enterprise database. If your Enterprise Server does not have a connection to the Internet, view this article regarding devices offline to Enterprise.

Banner Indicating Installation has Expired

Monnit offers Trial Enterprise licenses (good for 60 days), Annual 50 sensor licenses, and perpetual 250 sensor (or more) licenses for the iMonnit Enterprise software. If you have applied a key that is valid for a specific amount of time, the license will need to be renewed. If this occurs, iMonnit Enterprise will stop receiving data from gateways, and you may see the message “This installation is expired, contact support to update subscription.” as a banner at the top of the iMonnit Enterprise Portal. If you see this, you will need to renew your license with a valid key.

Note: There is a unique scenario in which you might see this message even if you have a 250 sensor license with a legacy version of Enterprise (version 3.6.2.1 or earlier). Review this article if that scenario applies.

Sensor limit

There are different sensor limits in the available iMonnit Enterprise licenses. If your sensor limit is reached, the Enterprise Wireless Gateway Server service will continue to run, but it will not accept incoming communication to the server. An exception is generally displayed in the ExceptionLog table of the Enterprise database. If you review the most recent logs, you can generally see the log if this is the case.

To test this, use the Communication Check Utility, and test using port 80 instead of 3000. If this is successful, but testing using port 3000 fails, the issue is likely that you have exceeded your sensor limit.

You may see the error “Only EnterpriseBasic sensors allowed for this installation.” If so, see the article on this issue.

Check your database connection, size, and limits

If you are using the free version of SQL Express, you will need to make sure your database is not over the 10 GB limit as per this article. The article will also allow you to confirm that you have a valid database connection and credentials.

Running the Communication Check Utility

If you have confirmed that your Enterprise Wireless Gateway Server service is running and that your license is current, you will want to test with the Communication Check Utility as per the (Using the Communication Check Utility with a local server such as iMonnit Enterprise section) of this article.

There are two tests you may want to conduct:

  1. Test with the utility running on the server running iMonnit Enterprise.

    If the test is not successful but your Enterprise Wireless Gateway Server service is running, you will want to analyze security settings on the PC preventing the traffic from getting to the configured port (default 3000) in iMonnit Enterprise.

  2. Test from a PC on the same network segment.

    Testing from another PC on the same network segment might help identify network configurations preventing communication to the server over the configured port. If the test succeeds on the server, but fails from the node PC, you will want to review network configurations. If the test is successful from the server and the node PC, there is not likely any network configuration issues on the subnet. Although, it is also worth noting that while a successful test from a node PC can be a helpful indicator about the network configuration, it does not confirm that the gateway is able to reach the Enterprise server on the network segment. It is a good indicator, but not a certain confirmation as there can be other security features (such as MAC address filtering) which can still be present.

Reviewing the gateway

If you have conducted the Communication Check Utility test from the server (and preferably from a node PC) with success, you have confirmed that the Enterprise server is configured and successfully accepting gateway communication. At this point, you will want to review the gateway and network configuration.

Gateway LED’s

To determine the state of the gateway, you will review the gateway LED’s. For the purpose of this article, we will focus on a configuration with an Ethernet Gateway 4. Although other gateway types can be used with Enterprise, the Ethernet Gateway 4 is the most common with Enterprise.

  • The bottom LED represents the local Ethernet connection. If that LED is solid green, the gateway has a valid IP address on the local network. Although this does not necessarily mean that the gateway has a network path by which to reach the Enterprise Server, it is a good sign that the gateway is communicating on the local network.

    If the bottom LED is red, the gateway is not able to get a valid IP address. This will need to be addressed before the gateway can reach the Enterprise Server.

  • The second LED represents the connection to the Enterprise server. If this LED is green, there is a valid connection to the server. The likelihood is that this LED is red since there is no valid server connection.

Ping the Gateway’s IP address

If the bottom LED of the gateway is green, and you know what the gateway’s IP address is, ping the IP address from Enterprise Server. If you get a successful response, you know there is a network path by which the gateway can be reached from the Enterprise server.

If the ping returns unreachable, you will want to review the networking configuration to determine what is preventing the connection.

Access the gateway’s Local HTTP Configuration Page

If you are able to ping the gateway, you will want to check to see if you can reach the gateway’s Local HTTP Configuration page. This can be done by entering the gateway’s IP address in a browser. If you see the gateway’s configuration page, you have confirmed there is a path by which HTTP traffic can be transmitted between the gateway and server.

Note: when visiting the HTTP Configuration page, you may see a message indicating the interface is disabled, or that it is read-only if it has not been enabled prior. The purpose of this step is simply to confirm there is a path by which the server and gateway can communicate, and not necessarily to edit gateway configuration. If you need to make configuration changes, you can enable the HTTP Configuration page. If you are unable to determine the gatweay’s IP address, you may be able to use the AutoIP feature described in this article to configure the gateway locally.

Reviewing the gateway’s server host address

If you are able to access the gateway’s Local HTTP Configuration page, select review the “Default Server Name/IP:” to confirm this is configured with the server’s IP or domain address.

If you see the address is correctly entered as your server’s address, your gateway is configured to deliver data to the iMonnit Enterprise Portal, and your Enterprise Server is configured to receive data from gateways. You will want to review network configurations that are preventing communication between the two.

Conclusion

After confirming the configuration with the server is good and it is receiving data, and confirming the gateway is indeed pointed to the server, you have confirmed the configuration from the Monnit side is correct. Other network and security considerations should be reviewed with the appropriate party. Feel free to contact support@monnit.com with related inquiries.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.