Disable Wireless Network on Server Loss - Ethernet Gateway 4
There may be applications in which you prefer that your gateway does not retain logged messages during loss of communication to the Monnit server. In applications where loss of network connection is frequent or network data usage needs to be carefully staggered, you may prefer to rely on the sensors to log data messages. In these scenarios, you can implement an Ethernet Gateway 4 which offers the feature, Disable Wireless Network on Server Loss.
Enabling this feature
In iMonnit Online, this feature is labeled “On Server Loss: Log Sensor Data/Disable Wireless”.
- Log into your iMonnit Online account
- Select Gateways in the sidebar
- Select your Gateway
- Select the Settings tab
- In the General tab, toggle the On Server Loss: configuration to either Log Sensor Data or Disable Wireless
In the Local HTTP Configuration Page
- Access the gateways local HTTP Interface
- Select the Settings tab (this varies depending on firmware versions)
- Select the Default Server tab
- Select the dropdown for the On Server Loss configuration
- Select Disable Wireless Network
What does this do?
Enabling Disable Wireless Network on Server Loss turns off the Ethernet Gateway 4’s radio when there is a loss of communication to the Monnit server. Therefore if the gateway is checking in with the Monnit server, and a network issue occurs, the gateway’s sensor network will be disabled. At that point, the sensors will lose the connection to the gateway and start logging sensor messages in their own memory. Once the gateway’s server connection is restored, the Wireless Sensor Network is enabled, and the sensors will reconnect and upload the logged data.
When this might be useful
In older gateway firmware, logged sensor messages are not retained on gateway power loss. Since network issues and power loss are often experienced as a result of related underlying issues, it may be in the best interest of data logging to disable the gateway’s Sensor Network to allow the sensors to log data rather than the gateway. For example, a storm can often knock out a network connection, and some time later disable power for a facility.
Consider this scenario:
- A customer operating an Ethernet Gateway 4 with firmware version 188.8.131.52 (does not support logged data retention after power loss) on a local network sending data to a server hosting iMonnit Enterprise at their local data center.
- The gateway is operating locally, and because of network restrictions it cannot be configured to reach out to iMonnit Online for a firmware update. Therefore the customer is operating with older firmware, and cannot update. The gateway is operating with default settings with the Disable Wireless Network on Server Loss feature not active.
- A storm comes along and damages the network lines between the facility housing the gateway and the data center (but power is still active).
- The gateway continues to receive transmissions from the sensors, and logs the messages in its memory to be delivered upon reconnection to the server.
- Several hours after the network connection between the gateway and server was damaged, the storm knocks out electricity to the facility (wiping out logged data on the gateway).
- The sensors begin to log readings on their Heartbeats.
- A few hours later, the network connection between the gateway and server is restored, and the power is restored.
- The sensors automatically relink to the gateway, and upload the data they logged during the power outage.
- There is subsequently a gap in the data between the time the network was damaged and the power went out.
In this scenario, the data that was logged by the gateway between the time the network went down and the power went down would be lost. Therefore it would have made sense to activate the Disable Wireless Network on Server Loss feature with this installation because the sensors would have started logging their readings as soon as the network connection between the gateway and server was severed. The sensors would have then uploaded the messages they logged after reconnecting to the gateway, and the user would not have gaps in the data.