IntelliAM(CTC) Sensor Not Connecting to Gateway – On Site Troubleshooting

Scenario

Occasionally you may find that a sensor has not connected to a gateway for some time. There is no pairing mode. Any powered sensor in range of a gateway will automatically appear on the dashboard and start reporting.

What you need before you start

• Sensor identifier (sensorID if available) 
• Location and nearest gateway (or best guess) 
• “Last seen” time on the dashboard

Step 1 — Battery check (use the battery photo as reference)

• Open the sensor and inspect the battery installation. 
• Check the connector: Ensure the white 2-pin plug is fully seated in its socket (it should sit flush and not feel loose). 
• Confirm the red/black wires are not pulled, pinched, or partially detached. Check the contacts and housing: Look for corrosion, moisture, or debris around the connector and battery area. 
• Ensure the internal parts are seated properly and nothing is preventing the unit from closing cleanly. 

*Left image shows battery connected, right image shows battery not connected

If the battery/connector looks correct but the sensor remains offline, continue.

Step 2 — Bluetooth “alive” test (ws20 filter + RSSI threshold)

For the purposes of step 2, someone on site will be required to download a free Android/iOS app called 'nRF Connect'. This will be used to troubleshoot the bluetooth connectivity. Once installed the app will show you bluetooth devices in range.

On the scanner app (as shown in your screenshot):

Go to the Scanner tab. Set a name filter to ws20. Set RSSI to around -40 dBm (this restricts results to very close devices and reduces noise). Hold your phone close to the sensor (near-touch distance). Tap Scan (or start scanning) and watch for a ws20 device to appear.

How to interpret the result:

If a ws20 device appears with the phone held right next to the sensor, the sensor is powered and transmitting. Go to Step 3 (orientation) and Step 4 (near-gateway test). If no ws20 devices appear: Re-check the battery connector seating and replace the battery if you have not already. Repeat the scan at near-touch distance. If it still does not show up, treat it as likely sensor failure and move to Step 5 (swap test) to confirm. 

Step 3 — Orientation and “ideal position”

If you are close to the edge of coverage, orientation can be the difference between reporting and not reporting.

Our testing found that signal strength was impacted by the sensor orientation, if this sensor is just on the cusp of connectivity range, the orientation could provide us with the additional bandwidth we need for a successful connection.

We would expect the best results when the notch on the metal ring around the sensor is facing as gateway as per the diagram of our findings below.

It is worth noting with this test, if you do change the orientation of the sensor it may take up to 24 hours for us to see if the change has been successful. It would be advisable to wait a day or so before proceeding to the next step.

Step 4 — Near-gateway test (coverage vs sensor fault)

If all of the above has still provided no result, we would look to force the sensor to connect to the gateway by moving it closer. 

Take the sensor close to a gateway and leave for 24 hours. Wait for the next expected update window and check the dashboard for a fresh reading.

If it updates near a gateway but not at the installed location, this points to a coverage/placement issue at the original position. Reinstall and use the 180° rotation/notch orientation to optimise. If it does not update near a gateway, this points to a sensor problem (or a gateway outage affecting that area). Proceed to Step 5.

Step 5 — Swap test with a spare sensor (dashboard confirmation)

If Bluetooth scanning is not possible, or you want a definitive isolation test, use a spare sensor. This will require liaising with IntelliAM support so we can confirm the sensor ID and make sure it is deployed as visible in the platform.

Validate the spare works: Place the spare close to a gateway first and confirm it appears on the dashboard with a reading. Move the spare to the target location (where the offline sensor was installed). Check the dashboard. A new sensor can take up to 24 hours to show a reading on the dashboard. 

If the spare works in the same location: the original sensor is the issue (not the position). Action: notify IntelliAM to swap and permanently rename the sensor in the database (old sensor ID, new sensor ID, exact location, timestamp). 

If the spare also fails in the same location: this is likely coverage/gateway/environmental (not a single sensor fault). This may require an additional gateway to cover the sensors out of range of your existing setup.

Escalation checklist (send to IntelliAM)

• Site + exact location Sensor ID(s) and last-seen time(s) 
• Battery action taken (checked connector / replaced battery) 
• Bluetooth scan result (ws20 filter used, RSSI set to -40, whether it appeared) 
• Orientation change attempted (180° / notch facing gateway) 
• Near-gateway test result Swap test result (including whether the spare was validated near a gateway first)

With all of the above we should be able to determine the best course of action, thanks!