Device data intake
The service your devices talk to: several protocols decoded, checked and standardised before anything is stored.
IIoT
IoT solutions that work past the pilot
We build the software behind connected devices: the service that receives what they send, the storage under it, the rules that raise the alerts, and the dashboards and apps people use.
- 3 yrsa connected platform live, built and run
- 37+report types in production
- 12years building software
What we build
What an IoT platform has to be good at.
Most connected systems need the same run of parts, from the socket a device connects to up to the app in someone's hand: data intake, telemetry storage, rules and alerts, operations dashboards, customer portals and apps, and the hosting under all of it. Not every build needs all of them. We build the ones yours does as one platform, because a reading is only worth collecting if it reaches someone who can act on it.
Telemetry storage and history
Live state that answers instantly, and a year of readings behind it that still answers a question in seconds.
Rules, thresholds and alerts
Limits on any sensor and boundaries on anything that moves, delivered to the person who can act on it.
Operations dashboards and reports
The live view your team watches and the reports they run every morning, with access granted by role.
Customer portals and mobile apps
Self-service tracking on web and phone, each client organisation with its own users and permissions.
Hosting, monitoring and support
The servers that have to stay up, watched by someone, with new device models added as you grow.
The shape holds. The work inside it varies.
Our deepest platform work is in vehicle and fuel telemetry, and that case study is below. The architecture carries over to meters, machines or cold-storage units: receive, normalise, keep live state apart from history, raise events, show people. What varies is not cosmetic — how readings arrive, how many per device per day, how long they are kept, and what counts as an event. Those are the first questions we would ask you.
What we do not do
Do you build the hardware too?
No. We do not design boards, write firmware or certify enclosures — if that is the job, we are the wrong firm and will say so on the first call. Everything above is the software half, and that is where IoT solutions are usually won or lost.
The device itself
Not us. A sensor to design, a board to lay out, an enclosure to certify.
We integrate the one you chose, over the protocol it already speaks.
The firmware on it
Not us either. We do not flash devices or ship updates to them.
We decode what it sends, including several versions of one protocol.
Everything after that
Usually nobody's job. Intake, storage, rules, dashboards, apps, servers.
Ours, as one platform, with one team accountable for all of it.
Architecture
What production needs that a pilot does not.
A pilot runs on a handful of devices somebody is watching. Production runs on thousands that nobody is watching, over networks that drop and with device models that drift apart as firmware versions diverge. Four decisions in the platform we have run for three years exist only because of that, and they are the ones most expensive to add later.
-
01
Intake is its own service
Device data does not arrive through the website. A separate listener takes it off the socket and shares no process with the dashboards, so a busy morning on the screens cannot slow what the devices are sending.
-
02
One format before anything is stored
Every reading is checked and converted into one format on the way in. Skip it and each new device model reaches the reports as a special case — and the reports are where the operation is actually run from.
-
03
Live state kept apart from history
The current state of every device lives in a cache; the year of readings behind it lives in a store built for volume. A screen that has to answer instantly should not be querying a year of history.
-
04
Alerts raised where the reading lands
A sensor passing its limit, or an asset leaving where it should be, becomes an event at the point of intake rather than in a nightly job. An alert that waits for someone to open a dashboard is a report with extra steps.
What we build with
Your devices decide half of this.
The device end is a constraint we work to, not a menu we offer. What sits above it is chosen per project, and the protocols below it are chosen by whatever you already bought.
TCP / UDP
Codec 8 / 8E / 16
Java
Node.js
STOMP
WebSockets
Redis
MongoDB
MySQL
PostgreSQL
PHP / Laravel
REST APIs
Angular
React
Flutter
AWS
Docker
GitHub Actions
This is what we have built on, not a list of everything in the field. If your devices speak something else, that means writing a decoder — not learning a new trade.
Stages and price
What you commit to at each stage, and what moves the price.
IoT solutions are funded in stages rather than signed in one go. Each stage is priced on its own and ends in a decision that is yours, which is the protection against paying for a platform sized for thousands of devices before a handful of real ones have proved the idea.
-
Stage 1
Device and data assessment
We confirm what your devices actually send, against real traffic rather than a datasheet, and scope the platform behind them.
you decideWhether to build at all, with a costed scope in hand -
Stage 2
Connected pilot
A small number of devices running end to end on the platform the rollout will use, rather than a demo that gets thrown away.
you decideWhether it works on your devices, before funding the rest -
Stage 3
Production rollout
Intake sized to the device count you are committing to, with the dashboards, portals and apps around it.
you decideThe pace, and how much goes live at once -
Stage 4
Run and improve
Hosting, monitoring, backups and patching, with new device models added as they arrive.
you decideWhether we keep running it or your team takes it over
What the number actually depends on.
How many device models you run and whether their protocols are documented, how often each one reports and how long readings have to be kept, how many zones and alert rules the operation needs, how many client organisations get a portal of their own, and whether the data has to reach anything else — billing, an ERP, or a client's own system.
Every build includes
- The code and the reading history, yours
- Cloud accounts in your name
- A deployment pipeline
- Monitoring on the intake itself
- Backups, tested by restoring
- A runbook a new developer can follow
Our work
One connected platform, three years in production.
IoT · Fleet management
Connexis: integrated fleet tracking and fuel monitoring platform
A fleet tracking and fuel monitoring platform for a large logistics company that serves business and government clients. It has four connected parts, and Eiglou has built and maintained it for three years.
Our platform tracks fleets for some of the largest corporate names in the country, so the bar for reliability is unforgiving. Eiglou handles that scale and the demanding requirements that come with it — the system just keeps running, and changes get turned around fast.
FAQ
Common questions.
Can you work with the devices and sensors we already have?
Usually, yes. We take device data straight off the socket over TCP and UDP, and already decode several versions of one device family's protocol. A protocol we have not met before means writing a decoder for it, which is ordinary work once we have the specification.
How many devices can it handle?
As many as the intake is sized for, which is why the first two numbers we ask for are how many devices you have and how often each one reports. Those set the throughput the listener and the storage have to carry. The platform we run today carries corporate and government fleets.
What happens to readings while a device has no signal?
Most devices store readings and send them when the connection returns, so what matters is keeping the time a reading was taken rather than the time it arrived. How gaps appear in reports is agreed before we build them.
How long before we see live data?
Weeks for a pilot, because only the intake and one dashboard have to exist before real data appears. Rolling out to every device is a separate step, scoped and priced on its own.
Who owns the data and the platform?
You do. The readings, the history and the code are yours, and the cloud account can be in your name from day one with us operating it. Nothing is locked to a platform of ours.
Can we get the alerts and reports our operation needs?
Yes, and they are built to your rules rather than chosen from a list: which conditions raise an event, who receives it and on which channel, and which reports your team actually runs.
Can you take over a connected platform somebody else built?
Often. We review the intake, the database and the hosting, write down what is risky, then fix it in steps. We have run one connected platform for three years, so the work after launch is familiar ground.
Still deciding? Tell us what you are building and we will tell you what the first release should be, and what it would take.
Let’s talk about your project.
Tell us about your IoT project. We will reply with what we would build first and what it would involve.