How to Unlock and Point an ALTA Gateway to a Custom Host or IP Address

Oct 16

9 min read

Updated: 5 days ago

An ALTA Gateway will not send data to a local iMonnit server just because the server exists on your network. The gateway must be unlocked first, then pointed to the host or IP address where your iMonnit Enterprise, iMonnit Express, or Monnit MINE instance is running.

That order matters. If the gateway is still locked, it needs to communicate with iMonnit over the Internet on outbound port 3000 so it can receive the unlock command. Once unlocked and pointed, the gateway can use its Default Interface to send data to your chosen destination.

This guide explains the process from start to finish, including what to prepare, how the Default Interface works, and how to confirm the gateway has moved from iMonnit to your custom host.

Eye-level view of an ALTA-style gateway connected to an Ethernet cable. — Start with the gateway online so it can receive unlock and pointing commands.

What unlocking and pointing an ALTA Gateway means

Monnit uses the term Default Interface for the interface through which a gateway transmits data to Monnit Software. In practical terms, it is the gateway’s active destination path.

A gateway can send data to one destination at a time through the Default Interface. That destination may be:

iMonnit in the cloud
A local iMonnit Enterprise server
A local iMonnit Express server
A Monnit MINE server
Another configured custom host or IP address, when supported by your setup

When you unlock and point the gateway, you are changing where the gateway sends its data. Instead of continuing to report to iMonnit’s cloud service, the gateway receives instructions to use your selected host or IP address.

The main workflow is:

Apply the Unlock Code to the gateway.
Point the gateway using the `SetHost` tool.
Connect the gateway to iMonnit.
Confirm the gateway checks in and receives the unlock and point commands.
Confirm the gateway communicates with the new host.
Reset the device to communicate with iMonnit again if you need to reverse the change.

The key detail is that the gateway usually needs to check in with iMonnit before the change takes effect. If the gateway cannot reach iMonnit, it may not receive the command that unlocks or points it.

Before you begin

Prepare the gateway and network before changing any host settings. This reduces the chance of a failed check-in or a gateway that appears offline during the transition.

You will need:

An ALTA Gateway
A purchased Gateway Unlock Code
Access to the iMonnit account associated with the gateway
Internet access for the gateway during the unlock process
Outbound access on port 3000
The host name or IP address of your iMonnit Enterprise, Express, or Monnit MINE server
Network access between the gateway and the custom host after the change
Any required local firewall or routing rules already in place

If you plan to use a domain name instead of a raw IP address, confirm that DNS resolution works from the network where the gateway will operate. If you plan to use an IP address, confirm that the address is static or otherwise stable.

The gateway must receive the unlock and point commands before it can operate against the new destination. Do not disconnect it from iMonnit too early.

Confirm the local server is ready

Before pointing the gateway, make sure the local Monnit server is installed, reachable, and ready to accept gateway traffic. A common mistake is changing the gateway destination before the server or network path is ready.

Check the basics:

The server is powered on and connected to the network.
The host name resolves correctly, if using a DNS name.
The IP address is reachable from the gateway’s network.
Firewalls allow the required traffic between the gateway and server.
The iMonnit Enterprise, Express, or Monnit MINE software is running.

If the gateway checks in to iMonnit, receives the new destination, and then cannot reach the local server, it may appear offline in the new environment until the network problem is fixed.

Close-up view of network cables connected to a compact IoT gateway. — Network access must be ready before you send the gateway to a new host.

Step 1. Apply the Unlock Code

Before you point the gateway, apply the Gateway Unlock Code. Unlock codes can be purchased through Monnit, and they are required for this process.

There are two common ways to apply the code.

Use the Gateway Unlock feature in iMonnit

In iMonnit, the unlock feature is found under Credits and then Gateway Unlock. Use this area to apply the code to the gateway associated with your account.

The exact screens may vary by account configuration, but the goal is simple: assign the purchased unlock to the correct gateway so iMonnit can send the unlock command when the gateway checks in.

Take care when identifying the gateway. If you manage more than one gateway, confirm the gateway ID or serial information before applying the unlock.

Use the SetHost tool

You can also use the `SetHost` tool at:

`https://www.imonnit.com/SetHost`

You must be signed in to your iMonnit account to view this page. If you are not signed in, the page may show a 404 error or appear unavailable.

Once signed in, visit the `SetHost` page and enter the required gateway information. This normally includes identifying the gateway and providing the values needed to associate the unlock and destination settings with that device.

Use the host name or IP address exactly as it should be used by the gateway. Avoid extra spaces, incomplete host names, or temporary IP addresses that may change later.

Step 2. Point the gateway to the custom host or IP address

After the unlock information is applied, use the `SetHost` tool to point the gateway to your local server.

This is the core step in How to Unlock and Point an ALTA Gateway to a Custom Host or IP Address. The gateway’s Default Interface will be updated so that future data is sent to the new destination instead of the previous one.

When entering the destination, choose one of these formats based on your setup:

A fully qualified host name, such as a local DNS name
A static IP address assigned to the server
A reachable host address for the iMonnit Enterprise, Express, or Monnit MINE server

Use the format your network can resolve from the gateway’s location. A host name that works from a laptop on one network may not work from the gateway’s subnet. If the gateway lives on a locked-down VLAN or private network, confirm name resolution and routing from that network.

Host name or IP address

A host name is easier to maintain if the server’s IP address may change, but it relies on DNS. An IP address avoids DNS issues, but it must remain stable.

Host name

IP address

Easier to change later through DNS, useful when the server may move to another address.

Direct and simple, useful when the server has a static address and DNS is not available.

For many local iMonnit Enterprise or Monnit MINE deployments, a static IP address is the simplest choice. For managed networks, a DNS name may be better because it keeps device configuration cleaner over time.

Step 3. Connect the gateway to iMonnit

After applying the unlock and point settings, connect the gateway so it can check in with iMonnit.

This is the step that many people skip. The settings entered in iMonnit or the `SetHost` tool do not help until the gateway receives them. If the gateway is locked and has never received the unlock command, it must reach iMonnit through the Internet.

Confirm these items before waiting for the check-in:

The gateway has power.
Ethernet or cellular connectivity is active, depending on your model.
The local network allows outbound traffic on port `3000`.
DNS and general Internet access are working, if required by the gateway’s connection path.
The gateway is assigned to the correct iMonnit account.

If outbound port `3000` is blocked, the gateway may fail to receive the unlock command. In that case, review firewall rules, security appliance policies, and any network restrictions between the gateway and the Internet.

Wide-angle view of a small network rack with an IoT gateway and patch panel. — The gateway may need temporary Internet access before moving to a local server.

Step 4. Confirm the gateway checks in and receives the commands

Once connected, wait for the gateway to check in with iMonnit. During this check-in, it should receive the unlock command and the new host settings.

Look for signs that the gateway has communicated successfully. Depending on your tools and setup, this may include:

A recent gateway check-in in iMonnit
A status change showing the gateway has received instructions
Local server logs showing later connection attempts from the gateway
Network traffic from the gateway toward the new host
Sensor data beginning to appear in the local Monnit environment

Do not assume the gateway has been pointed just because the host value was entered. The device must receive and apply the command.

If the gateway does not check in, start with the network path to iMonnit. Confirm Internet access, outbound port `3000`, power, cabling, and account assignment.

Step 5. Confirm communication with the new host

After the gateway receives the unlock and point commands, it should begin communicating with the custom host or IP address.

At this stage, shift your checks from iMonnit cloud access to local server access.

Confirm the following:

The gateway can reach the local server address.
The server accepts the gateway traffic.
The gateway appears in the local iMonnit Enterprise, Express, or Monnit MINE environment.
Sensor data arrives as expected.
No firewall is blocking traffic between the gateway and server.
The gateway is not still reporting only to the previous destination.

Since the gateway can only transmit to one destination at a time through the Default Interface, successful communication with the new host means it should no longer use the old destination for normal data transmission.

If the gateway does not appear on the local server

Work backward from the destination.

Start with the server. Confirm the Monnit software is running and listening as expected. Then check the network path between the gateway and server. If those look correct, review the host or IP address entered in `SetHost`.

Common causes include:

Typing the wrong IP address
Using a host name the gateway cannot resolve
Blocking traffic at a firewall
Pointing the gateway before it received the unlock command
Connecting the gateway to a different network than expected
Applying the unlock to the wrong gateway

If you manage several gateways, label devices physically before making changes. This helps prevent a simple mix-up from becoming a longer troubleshooting session.

Step 6. Reset the device to communicate with iMonnit when needed

There may be times when you need the gateway to communicate with iMonnit again. For example, you may be retiring a local server, moving the gateway to another account, testing connectivity, or correcting a pointing mistake.

To move the gateway back, reset or reconfigure it so the Default Interface communicates with iMonnit again. The exact recovery path depends on the gateway model, the current state of the device, and how it was pointed.

Before resetting, record the current local host or IP address. If you need to point the device back to the same local server later, having the original values will save time.

After changing the destination back to iMonnit, confirm the same basics:

The gateway has Internet access.
Outbound port `3000` is open.
The gateway checks in with iMonnit.
The gateway status updates as expected.

When to disable the Default Interface instead

Some ALTA Ethernet Gateways are unlocked for use on a local private network without a Monnit server. That is a different use case from pointing the gateway to iMonnit Enterprise, Express, or Monnit MINE.

In that setup, the Default Interface may need to be disabled so the gateway does not keep trying to reach iMonnit. This is useful when the gateway operates on a private network where cloud communication is not used.

Do not confuse these two goals:

Point the gateway

Disable the Default Interface

Use this when the gateway should send data to a specific Monnit server, such as iMonnit Enterprise, Express, or Monnit MINE.

Use this when the gateway is unlocked for private-network use without a Monnit server and should stop trying to reach iMonnit.

If your goal is private LAN operation with no Monnit server, follow the specific procedure for disabling the Default Interface. If your goal is a local Monnit server, use the unlock and point workflow described above.

Top-down view of an industrial gateway beside a printed network checklist. — A short checklist helps confirm the gateway moved to the intended destination.

What success looks like

A successful unlock and point process has a clear result: the gateway stops using iMonnit as its active data destination and starts communicating with your custom host or IP address.

You should be able to confirm that:

The Unlock Code was applied to the correct gateway.
The gateway checked in with iMonnit and received the unlock command.
The `SetHost` destination was entered correctly.
The local iMonnit Enterprise, Express, or Monnit MINE server is reachable.
The gateway appears or reports as expected in the local environment.
Sensor data flows to the new destination.

The safest path is to keep the gateway online with iMonnit until it receives its unlock and point commands, then verify the new destination from the local server side. Once the gateway is reporting to the right place, document the host value, gateway ID, and network path so future changes are easier to manage.