Hindustan Scale Company · Est. 1955Foundations — what connected weighing is and why it matters

The link drops at 11:40. The weighing does not stop. The question is whether the records do.

Every connected scale is sold on the day the network works. This article is about the other day. It is a plain-English guide to weighing scale offline data logging — what a well-designed scale does with its readings while the internet is gone, how a server tells a quiet scale from a dead one, why “no news” has to ring a phone, and what should happen, minute by minute, during a three-hour outage.

Bluetooth Enabled Customized Scale - the HSCo product this paper is about.
The link drops. The weighing does not stop. Whether the records survive is a design decision made long before the outage.

Even the biggest network has bad days

On 17/09/2024 India’s largest mobile operator went down across the country after a fire at one of its data centres. More than 10,000 complaints were logged on the outage-tracking site Downdetector, Reuters reported; PTI covered the same outage and the operator’s statement that service was fully restored that day. If the biggest network in the country can lose a day, your broadband line can lose an afternoon.

Then there are the outages no router can fix. According to Access Now’s #KeepItOn tracker, governments ordered 65 internet shutdowns in India in 2025, out of 313 worldwide. SFLC.in’s tracker counts 930 in India since 2012, the longest running for months. Each number is its tracker’s own; the pattern is not in doubt.

The cost is harder to pin down; treat these as indicative. One vendor estimate put the economic cost of India’s 2024 shutdowns at about USD 322.9 million. A 2026 Uptime Institute survey of IT operators found 57 % of their most recent major outages cost more than USD 100,000, and that fibre and connectivity outages are rising and lasting longer. Your number will be different. The lesson will not.

So the design question is not “will the link drop?” It is “what does the scale do when it does?”

How does weighing scale offline data logging actually work?

The answer is written into the standards. OIML D 31:2023, the international guidance for software-controlled measuring instruments, says it in one sentence: if network services become unavailable or very slow, no measurement data shall be lost. Europe’s WELMEC 7.2:2025 software guide repeats it almost word for word. Both then describe the same mechanism, usually called store-and-forward:

  1. The scale keeps weighing. The load cell, the stable-weight logic and the display never depended on the network.
  2. Each reading goes into a local buffer first, on the scale itself, in the order it was taken.
  3. The scale sends the buffer forward, first-in-first-out, and keeps each record until the server confirms correct receipt. No acknowledgement, no deletion.
  4. If the buffer fills, the scale warns the operator and stops weighing rather than overwrite old records.

The same pattern runs the rest of industrial IoT. MQTT, the industry messaging standard (ISO/IEC 20922), requires a reconnecting device to re-send every message the server never acknowledged. The Sparkplug specification built on it (ISO/IEC 20237:2023) adds one rule: data sent late after an outage must be flagged historical, so nobody mistakes a 12:15 weighment for a live one at 14:45.

Diagram of store-and-forward: the scale keeps weighing, readings enter a first-in-first-out buffer, the backlog is sent when the link returns and released only when the server acknowledges it
Nothing is deleted until the server confirms receipt. If the buffer fills, a good scale warns and stops rather than overwrite a record.

Hindustan Scale Company’s Wi-Fi scales already post each stable reading themselves to the HSCo relay; buffering at the scale is designed to sit in front of that post, so an outage changes when a record arrives, never whether it arrives.

Why “no news” must be an alert

A silent scale is either idle or cut off, and from a dashboard you cannot tell which — unless the scale must speak even when it has nothing to say.

That is a heartbeat, and its rule is old and well tested. MQTT’s keep-alive rule: the device must send something within a fixed interval; if the server hears nothing for one and a half times that interval, it must treat the connection as failed. The device also registers a “last will” that the server publishes on its behalf the moment the keep-alive lapses; Sparkplug calls it a death certificate. Microsoft’s guidance for its cloud IoT service says the same in plain words: send a heartbeat at a fixed interval even with no data, keep the last heartbeat time for every device, and if one is missed, assume a problem. Passive “connected” flags, it warns, can lag by as much as five minutes.

Figure: a 60-second heartbeat received at 0 s and 60 s, nothing at 120 s, and the scale declared lost at 90 s — one and a half intervals after the last heartbeat
A heartbeat every 60 seconds; silence for one and a half intervals and the server treats the scale as lost. The alert is the silence itself.

This is the part HSCo has built and shipped. Every HSCo Wi-Fi scale sends a heartbeat about once a minute. The relay keeps a last-seen time for each scale, shows it on the dashboard, and raises an endpoint-down alert when a scale goes quiet. Silence itself becomes the alarm. By the standard’s arithmetic, a one-minute heartbeat means a lost scale is noticed within about a minute and a half — not at the month-end reconciliation.

What a record must carry to survive an outage

A buffered number is only useful if it can still be trusted three hours later. OIML D 31 and WELMEC 7.2 both spell out what a transmitted weighing record carries:

  • the measured value with its unit;
  • the date and time of the weighing — stamped by the scale’s own clock at the moment it happened, never the time the server finally received it (the WHO’s data-integrity guideline uses a weighing as its example of “contemporaneous”);
  • the place of measurement;
  • the identity of the scale that produced it, so every record traces back to one instrument;
  • an unambiguous consecutive number.

The consecutive number is the outage detector. If the server holds record 4,118 and record 4,131 and nothing between, the gap is visible and the missing thirteen can be asked for. Without it, an outage that swallows a run of weighments leaves no trace at all — which is exactly what regulators mean when they say a record must be complete and enduring. The UK’s MHRA and the WHO both use the ALCOA+ test: attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available for the whole life of the record. Readings that silently vanished at 11:40 fail on two counts.

How long is that life? Under the CGST Act, the records behind a registered business’s production and stock accounts must be kept for 72 months from the due date of the annual return — about six years, longer under appeal. A weighment record has to outlive the invoice by a long way.

A three-hour outage, minute by minute

This is what a well-designed system does between 11:40 and 14:40.

Time On the floor On the dashboard
11:40 The broadband line drops. The scale keeps weighing. Last heartbeat received at 11:40.
11:41–11:42 Readings go into the buffer with the scale’s own time and the next serial numbers. No heartbeat arrives; after one and a half intervals the scale is marked down and the owner’s phone gets the alert.
12:00–14:30 Weighing continues. The buffer holds every stable reading in order. Last seen: 11:40. Someone is already looking at the router.
14:40 The link returns. The scale posts the backlog first-in-first-out; the server acknowledges each record and the scale releases it.
14:45 Nothing to do. The gap is closed, the serial numbers run unbroken, and the late records are flagged historical.

Now the badly designed version. Three hours of weighments live in a supervisor’s notebook — if at all. Or the readings arrive, but with the server’s time, so 12:15 becomes 14:40. Or the link flaps and the same weighment arrives twice because nobody waited for an acknowledgement. Each looks fine on the day and is indefensible in an audit two years later.

Plant head on a factory mezzanine reading a single amber alert tile on his phone while the packing line below keeps running
11:42. The line below has not stopped, and the owner already knows the scale has gone quiet.

What offline data logging is not

It is not permission to ignore the network. The alert exists so that somebody fixes the router at 11:45, not so the buffer becomes the system.

It is not a change to the legal weight. The verified display remains the stamped reading; the buffered record is a faithful, time-stamped copy.

It is not infinite. Every buffer has a size. A proper design warns before it is full and stops rather than overwrites; ask any supplier how many readings it holds and what happens at the limit.

It is not the server’s job alone. The buffer, the clock and the serial number have to live on the scale, because it is the only device still working when the link is gone.

And it is not something every “Wi-Fi scale” has. Ask two exact questions before you buy: where do readings go when the link is down? and how do you know a scale has gone quiet? HSCo answers the second today with its heartbeat, per-scale last-seen time and endpoint-down alerts; the first is designed to be answered at the scale with store-and-forward buffering, which can be added to a connected installation.

What changes on Monday morning

  1. An outage becomes an event, not a discovery. The phone rings at 11:42, not at month-end.
  2. The weighing never waits for IT. The line runs through the outage as it runs every other day.
  3. The record set stays complete. Consecutive numbers run unbroken; the time on every reading is the time it was weighed.
  4. Old readings are marked old. Late arrivals are flagged historical, so the dashboard never shows a stale weight as current.
  5. The audit answer is one search away. “What did line 3 weigh between 11:40 and 14:40 the day the internet went down?” has an answer — six years later.

How to start: one scale, thirty days

  1. Pick the one scale whose readings you could least afford to lose — usually the one feeding a bill or a batch record.
  2. Connect it and give it a name. Let it post to the data logging and reports dashboard for a week; note its last-seen time each morning.
  3. Pull the plug on purpose. Switch off the router for an hour on a quiet afternoon. Time how long the alert takes to reach a phone. Count the readings taken during the hour.
  4. When the link returns, check three things: are the readings all on the server, do they carry the scale’s time, do the serial numbers run unbroken?
  5. Write down the answers. Roll out to the next scale only if the test passed — with a buffer size that covers your longest realistic outage.

Hindustan Scale Company has made weighing scales in Mumbai since 1955 and builds the connected hardware, the relay and the dashboard itself, so one supplier answers for the whole chain from load cell to alert. The Wi-Fi module makes a scale you already own post its own readings; the full range is on the IoT connected weighing scales page.

Frequently asked questions

What happens to weighing scale data when the internet goes down?

The scale keeps weighing — the load cell and the display never depended on the network. In a well-designed system each reading is stored on the scale with its own time and serial number, sent first-in-first-out when the link returns, and deleted only once the server confirms receipt. The standards for measuring-instrument software (OIML D 31:2023, WELMEC 7.2:2025) require that no measurement data is lost.

How does the server know a scale has gone offline?

Through a heartbeat: the scale sends a short “I’m alive” message at a fixed interval even when it has nothing to report. If the server hears nothing for about one and a half intervals, it marks the scale down and raises an alert. HSCo Wi-Fi scales send a heartbeat about once a minute, and the dashboard shows a last-seen time for every scale.

Do buffered readings keep the correct time?

They must. The time on a record comes from the scale’s own clock at the moment of weighing, not from the server when it finally receives the reading. Readings sent late after an outage should also be flagged as historical, so a dashboard never shows them as live.

How long must weighment records be kept in India?

The records behind a GST-registered business’s production and stock accounts must be retained for 72 months from the due date of the annual return — about six years — and longer if the year is under appeal or investigation. A weighment record therefore has to survive long after the invoice is paid.

Does an HSCo Wi-Fi scale keep working without internet?

Yes. Weighing, the stamped display and any local printout continue exactly as before. The relay’s one-minute heartbeat, per-scale last-seen time and endpoint-down alerts are delivered today; store-and-forward buffering at the scale is designed to be added on top, so ask for it explicitly when you specify the system.

Is a scale with a local printer enough?

A printout survives an outage, but it is a piece of paper: no consecutive number the server can check, no scale identity in a database, and nobody totals it. Treat the printer as a backup for the operator, not as the record of the business.

Next step

Tell us which scale you could least afford to lose three hours of readings from, and we will propose a thirty-day pilot with an outage test built in.

Hindustan Scale Company (HSCo) · Mumbai · est. 1955 · www.hindustanscale.com · hsc@hindustanscale.com

Sources

  1. OIML D 31:2023 — General requirements for software-controlled measuring instruments, clauses 6.2.7 (timestamps), 6.3.4.4.1 (buffering example), 6.3.5.2 (transmitted dataset) and 6.3.5.4 (transmission interruption).
  2. WELMEC Guide 7.2:2025 — Software Guide (Measuring Instruments Directive 2014/32/EU), requirements T1, T4, T8, L7 and L8.
  3. OASIS — MQTT Version 3.1.1 (29/10/2014; ISO/IEC 20922:2016) and MQTT Version 5.0 (07/03/2019), sections 3.1.2.5, 3.1.2.10, 4.3 and 4.4.
  4. Eclipse Foundation — Sparkplug Specification 3.0.0 (ISO/IEC 20237:2023), sections 2.3, 2.4 and 5.1; the is_historical flag.
  5. MHRA — ‘GXP’ Data Integrity Guidance and Definitions, Revision 1 (March 2018), clause 3.10.
  6. WHO Technical Report Series 1033, Annex 4 — Guideline on data integrity (2021), sections 1.2 and 11.15 and Example 7.
  7. US FDA — Data Integrity and Compliance With Drug CGMP: Questions and Answers (December 2018).
  8. Central Goods and Services Tax Act, 2017, sections 35 and 36 (CBIC statute repository); TaxGuru commentary on section 36.
  9. Access Now / #KeepItOn — Internet shutdowns in 2025, press releases of 31/03/2026 (global and Asia-Pacific).
  10. SFLC.in — Internet Shutdowns Tracker, internetshutdowns.in (read 14/09/2026).
  11. RCR Wireless News, citing Reuters (18/09/2024); Deccan Herald / PTI (17/09/2024) — the nationwide mobile-network outage of 17/09/2024.
  12. Microsoft Learn — Azure IoT Hub, Monitor device status: the device heartbeat pattern (updated 06/05/2026).
  13. Uptime Institute — Annual Outage Analysis 2026 (13/05/2026); Top10VPN, Cost of Internet Shutdowns 2024, as reported by Medianama (January 2025) — illustrative figures only.
  14. Hindustan Scale Company — Wi-Fi relay and data logging & reports service: one-minute heartbeat, last-seen time per scale, endpoint-down alerts.