Frequently Asked Question

The manner by which sensors are authorized to communicate to gateways is through Sensor Lists. Once a gateway downloads a sensor onto its Sensor List, the sensor ID is not removed from the gateway’s Sensor List unless the gateway’s network is Reformed. Therefore if a sensor is set up on the same network as a gateway and the gateway performed the Sensor List download while the sensor was on the network (see the previously linked Sensor List article to see scenarios where this occurs), that sensor will be on that gateway’s network.

Therefore, if the sensor is subsequently moved to a different network, that sensor ID will remain on the Sensor List of the gateway from the Sensor Network to which the sensor was previously added.

Identifying the gateway ID through which the sensor sent readings

The ID of the gateway through which a sensor delivers readings is recorded in Sensor Readings. When using the Export feature to download sensor data, the Gateway ID is a column included in the export. Therefore you can see the ID of the gateway through which the sensor transmitted the reading. You can use this information to determine if the gateway through which the sensor communicated on the reading is the gateway that is expected.

How this might affect WebHooks

For customers that use WebHooks to deliver sensor data to a WebHook endpoint, this is a particularly important consideration. This is because WebHooks are triggered by gateway Heartbeats, and they include the sensor data the gateway has received by a sensor. Therefore if a sensor which is not attached to the same network as the gateway is in range of that gateway and continues to check in with a gateway, the sensor data will be included in the WebHook JSON. This can be especially confusing if you receive data from a sensor that is not currently added to the same network as the gateway. In other words, you will see sensor data come in from a sensor which is not expected.

Resolving this issue

To resolve this, you will need to Reform the network of the gateway which is receiving the sensor communication but is no longer on the same network. It is generally a good practice to Reform all gateways on the account in case the sensor ID remains on the Sensor List of another gateway in the event the sensor was one that gateway’s Sensor List at one time.

Conclusion

While the scenario described above is common, it can often be confusing for a user unfamiliar with the Reform command. This article should help you resolve this, but if you have related questions, please contact [email protected]