Data pipeline 4 sections Part of bespoke software
Internet of Things
Software Development
What IoT software actually is
Internet of Things software is what happens to a reading after a device takes it. A sensor measures something, sends it somewhere, and software stores it, shows it and tells someone when it looks wrong. Most of the work is in that second half, not the device.
Dev Moves does not present an IoT build in its current portfolio. This page sets out the software method we offer.
The useful part is not the sensor. It is the alert, record or action it creates.
Putting things online, and what comes with it
Connected equipment tells you what is really happening. It also becomes something you have to look after.
| What to weigh | What connecting equipment gives you | What comes with it |
|---|---|---|
| Knowing what happened | Readings come from the equipment itself rather than from somebody remembering. | You now have a lot of data, and most of it will never be looked at. |
| Acting sooner | A problem can raise an alarm before a customer notices it. | An alarm nobody acts on is worse than none, because it teaches people to ignore alarms. |
| The hardware | Sensors are cheap now and there is a part for most jobs. | Anything on a wall or a vehicle gets wet, knocked and unplugged. |
| Getting the data back | Mobile, wifi and long-range radio all work, and one of them will suit. | Signal is never as good in the real building as it was in the test. |
| Security | A device that is built properly can be updated in the field. | A device that cannot be updated is a problem with a countdown on it. |
| How long it lives | Good equipment stays in service for years. | Which means the software behind it has to still be supported in years. |
The five parts, in order.
Every IoT project has all five parts, whether or not anyone planned them. A weak part can make every later reading doubtful.
-
01
The thing that measures
A sensor takes a reading and gives it a device identity and time. The value may be heat, movement, pressure, position or something else.
-
02
The way it sends
A gateway or network carries the reading onwards. It also needs a plan for gaps, weak signals and messages sent twice.
-
03
Where it lands
The reading reaches a service that checks its shape, knows the device and stores the accepted value. Bad messages are kept apart for review.
-
04
What reads it
Software turns the current value and its history into a clear view. Users see the devices, places and periods that matter to their work.
-
05
What happens when a number goes wrong
A rule checks whether the reading is missing, unlikely or outside an agreed limit. It then records the event and tells the right person.
The hardware is the easy part
For many business projects, sensors are cheap and well understood. A specialist can choose one that takes the right reading and survives where it will sit.
The larger job starts after that reading leaves the device. Years of values need a clear home. A missing value must not look the same as a safe one. A broken sensor must not create a false alarm that people learn to ignore.
Storage needs rules for the device, time and place behind each value. Our bespoke database work covers that half. See our API integration services for how readings and alerts reach other systems.
The final choice is human. The scope states who gets told, what they need to see and what they are expected to do next. That makes the alert useful instead of just another number on a screen.
Watching equipment without going to look at it
The common reason to build this is simple. Something you care about is measured in a place nobody stands, and you find out it went wrong afterwards.
Remote monitoring closes that gap. A temperature, a pressure, a run time or a door state is read on a schedule and kept. The current value and its history are then both visible from a desk.
Once there is history, the software can watch for the shape of a problem rather than only the moment it happens. Think of a motor drawing more current each week. Or a freezer taking longer to recover after every door opening. Both are visible before anything fails. That is what people mean by predictive maintenance. It needs months of readings before it says anything useful. So it is a reason to start collecting early, not a feature to buy on day one.
Starting with a pilot, and using your own hardware
You do not have to replace your equipment. If the devices you already own can report a reading, we work with those. If they cannot, we work with your supplier rather than choosing kit on your behalf.
The sensible first step is a pilot on a handful of devices in one location. It proves the readings arrive, that they mean what everyone assumed, and that the alert reaches a person who can act. Scaling from ten devices to thousands is mostly a question of how often each one reports and how long the history is kept. Both are decisions rather than rebuilds.
What it costs
The cost sits in the amount of data, the checks around it and how quickly a person must act. The sensor price is separate.
-
03.1
How many devices
Each device needs an identity, status, place and safe way to join the service.
-
03.2
How often they report
Frequent readings create more storage, checks and work when the connection drops.
-
03.3
How long the history is kept
A live value is small. Years of readings need clear storage and useful ways to search.
-
03.4
How fast somebody must be told
A daily report is simpler than a live alert that must reach the right person at once.
Common questions
What is IoT software?
Do you supply the hardware?
What happens to the data?
How do we know if a sensor has failed?
Can it connect to the systems we already run?
Where the readings usually end up: customer portal software, mobile app development and bespoke databases.
Start with the reading
Tell us what is measured, how often it reports and who needs to know. We will map the software between the device and that decision.
- Pontefract, West Yorkshire
- Building for businesses across the UK
- Reply within 1 working day