Getting IoT device data to the cloud: webhooks, device management and testing
A sensor is only useful once its readings arrive somewhere they can be read. Three things stand between a device on a wall and a number on a screen: a way to deliver the data, a way to keep a fleet of devices configured and healthy, and enough testing to know how the hardware behaves outside the lab.
Webhooks: the event comes to you
A webhook is a notification about an event, delivered as an HTTP POST. You hook into an event, and when it happens a message arrives at a URL that is yours alone. The event can be a routine temperature reading in a greenhouse, a new login on a website, or a comment on a blog.
Two terms are enough to follow it. HTTP, the hypertext transfer protocol, is the method for moving data over the web. A POST sends data to a given URL, where whatever receives it acts on it.
For an IoT device such as a Bluetooth sensor, the notification can carry everything the sensor collected. A webhook is therefore a direct way to see your sensor data.
Webhooks earn more when they are chained. Once the conditions for an event are set, the alert is automatic, and nobody has to scan pages of data for a change. One event can trigger the next, and that one another, until a whole process runs on its own. Sending a sensor’s readings to a webhook is a long way from automating a workflow, but it is the first step.
Managing a fleet
One device can be configured by hand. A large IoT system may have thousands, placed precisely and all reporting to gateways. They have to be configured, given secure credentials, provisioned and connected, and then kept that way. This is device management: adjusting each device, updating its firmware and watching the health of the whole fleet.
Remote configuration. Devices need software updates and bug fixes without anyone visiting them, and each kind of device has its own settings. The transmission (Tx) power of a Bluetooth LE beacon is one: it decides how far away a gateway can be and still receive, and the lower it is, the more precise a location zone can be.
Scale. A deployment has to be planned to handle more data, more services and more users without producing errors.
What makes it hard:
- The variety of devices, on the market and still in development. Management has to keep pace with them.
- Bandwidth. Machine-to-machine communication often runs over limited links.
- Interoperability. Devices communicate over both wired and wireless connections.
- The life cycle. Batteries and systems fail, and a dead device has to be removed without weakening the security of the rest.
Done well, device management lowers operating cost, reduces security risk and makes the collected data usable: temperature, humidity, light, motion and air pressure, presented so that people can decide from it.
Testing before a full deployment
IoT connectivity rests on several wireless standards at once. A medical device may have to work with Wi-Fi, 4G, Bluetooth and Zigbee, through electromagnetic and physical interference, while meeting strict security requirements. Software has to be designed around that. The question to answer early is what happens to the data when a connection drops without warning. Finding out means testing in an environment crowded with radio signals while the device moves between connections.
The figures on a data sheet can look inflated once a device is in a real building. Test for the following.
- Range. It depends on climate, on the surroundings and on configuration. Humidity, walls, columns, metal and people walking past all weaken a signal. Many devices, beacons among them, let you raise or lower signal strength. Find the balance between battery life and the number of nodes.
- Battery life. Most IoT devices run on batteries, and how long one lasts depends on how often and how strongly the device transmits. Test the drain at low, medium and high usage to predict how much maintenance to expect. If battery life matters, buy devices that take larger batteries.
- Capacity and latency. Capacity is the number of bytes a network can carry per second. Latency is the time a message takes from an endpoint device to the cloud application. Real-time tracking and monitoring depend on keeping latency low.
- Security. Check that data is encrypted as it passes from one device to the next. This matters most when the service is offered to the public.
- Compatibility. Peripheral devices work with gateways and hubs with varying success. Testing small batches of hardware together saves time and money later.
So buy a small quantity first and test it where it will be used. The number of nodes in the first estimate often needs correcting. Try several configurations, raising and lowering Tx power, until range and battery life are in balance.
Watching the data during a test
A webhook is also a test instrument. Configure the gateway to forward what it hears from the peripheral devices to a webhook endpoint, and each device’s Tx power, signal strength (RSSI), battery level and data packets can be read as they arrive. When a device stops reporting, it is out of range. When its RSSI falls, it is moving out of range.
The original articles recommended uBeac Hook for this, a free service that logged the HTTP requests sent to it. It was part of uBeac.
Adapted in October 2026 from three articles first published on the Momentaj blog in 2018. It describes the technology as it stood then.