Changelog
Product milestones of the V.A.D. IIoT ecosystem, release by release — new platform modules, integrations, languages and reliability work.
Monitoring, roles and new ways to connect
Three parallel tracks: a monitoring service with a shared detector registry and one event table, an authorisation model built on policy objects, and new ways to bring a device or a region on board — proxy mode and a regional compliance pack.
- New
A shared detector registry and one monitoring event table
Problem events arrive from several sources: the collection daemon, the ingestion module, scheduled checks, AI analysis. The service reduces them to two entities — a detector directory that says what counts as a problem and which service and duty group it belongs to, and one event table every source writes into. Dashboards, filters and reports read it directly, so the count of open problems is the same everywhere.
Learn more - Reliability
Problem-session markers applied at ingestion
A session is scored at the moment it is written to the database. The rules are thresholds: contact more than 15 minutes ahead of schedule, a telemetry battery drop of more than 0.1 V against the previous session, a metrology battery drop of more than 0.05 V, abnormal connection duration. The session gets a marker, and the daily summary is assembled from markers rather than by re-scanning the archive — the cost of checking does not grow with the estate.
- Security
Access rules on policy objects
The access model is built on policy objects: one class per resource, plain methods instead of a DSL. A role is described as a set of named capabilities with active and enabled-by-default flags, so the mix of rights is configured per deployment without shipping a build. A policy stays an ordinary object and is covered by unit tests rather than an end-to-end run through the web.
Learn more - Integration
API controllers and views moved to the v3 namespace
The public contract gets a namespace of its own: controllers and representations move to v3, while v1 stays frozen as a compatible entry point. Breaking changes happen only in the new namespace, so the API can evolve without a round of agreement with every integrator. Responses are localized — directories and text descriptions come back in the language of the requesting user.
Learn more - Integration
A third mode of working with a device — proxying
A device works with two servers: one leading, one standby. A third mode adds proxying — the collection daemon accepts the connection and passes the data on, staying transparent to the device. That covers sites without a direct route to the platform. The mode is reflected both on the collection server and in the interface, so when a link is investigated it is clear which path the data took.
Learn more - Performance
Last session and meter model cached in the telemetry table
The last communication session and a reference to the meter model are cached next to the telemetry record — battery voltage, session status code, units of measurement. Estate-wide lists and filters are served by a single query instead of reaching into the archive for every screen, so response time stays independent of how deep the history goes. The cache is refreshed during ingestion, so its lag is bounded by the communication session rather than by a scheduled recalculation window.
- New
MENA Compliance Pack
Requirements differ across the region but overlap in a core: IoT rules, cybersecurity, personal data protection, cloud hosting constraints, industrial operation. The pack fixes that common core and moves the differences into country annexes, while a deployment configuration points at the annex it needs. The document answers the applicability question before a pilot starts — it is addressed to customers, local partners, system integrators and government organisations.
Trustworthy, readable device data
Device data is parsed against the protocol specification: bitmasks are decoded bit by bit, codes are shown in hexadecimal, and archive descriptions are written from the state of the equipment. The accumulated archive was recalculated with the same logic.
- Reliability
Bit-level decoding of status masks in event and alarm journals
The event and alarm status fields of the Type-M protocol are 16-bit masks: bit 1 is low battery, bit 2 is weak GSM signal, bit 15 (32768) is a device restart. Decoding walks the bits and checks them against firmware thresholds: the low-battery event is set below 11.7 V and cleared above 12.0 V, with 300 mV of hysteresis. Journal descriptions are built from the decoded bits, and the accumulated archive was recalculated with the same logic — 7,872 records updated, 112,924 added.
- Improved
Rewritten tab labels and event descriptions in device archives
The texts in the archive tabs are written from the state of the equipment rather than from the packet fields: a description says what happened to the device. Tab labels do not repeat the section name, and the status column is called “Flags”, matching what it holds. Values are rendered in a monospaced font, so column width does not depend on the length of a value.
Learn more - Improved
Alarm and event codes rendered in hexadecimal
Alarm and event codes are rendered in hexadecimal: 0x8000, 0x0001, 0x0000 — padded with leading zeros to four digits. A monospaced font lines the digits up vertically between rows, so the bit that is set stands out immediately and can be matched against the protocol specification without converting from decimal.
- Improved
Table state: page size, units and retry codes
Data tables hold their state across navigation: the chosen page size is kept. Units moved out of the column header down to the value itself — the header stays short and the unit sits where the number is. The retry counter shows both the number of attempts and the reason code, so link quality can be read straight from the table.
- Performance
Profiling the ingestion queue in the background job server
The background ingestion pipeline was profiled stage by stage and rebalanced across workers. Readings land in the archive right after the communication session, and the queue keeps pace as the estate grows — jobs are drained faster than they arrive, and the throughput headroom is visible in the ingestion log.
Learn more
Industrial operation
The first production release of the third generation: an operator runs its live metering estate on it end to end — collection, storage, web interface, API and analytics. The Operations Center runs on top, and session parameters moved into the shared archive store.
- New
Version 3.0: the first industrial production environment
The third generation leaves pre-release: an industrial operator runs its live metering estate on it. The collection daemon, the store, the web interface, the public API and analytics all work inside one environment. The transitional period with two generations running side by side is closed.
Learn more - New
Operations Center (OHM)
A stream of raw alarms becomes a set of managed operational issues. Detectors and canons fold repeating events into one issue, correlation attaches the evidence to it, asset health scoring ranks the estate by risk, priorities and SLA set the response deadline, and the work queue holds the job until closure. Massive incidents — one failure raising hundreds of alarms — are handled as a class of their own. An AI layer suggests the next step from the accumulated history of similar cases.
Learn more - Improved
GSM signal level stored and shown on a single dBm scale
GSM signal level is held on a single dBm scale whatever unit the device protocol delivers it in — percent, relative units or dBm itself. The conversion lives in the ingestion drivers and runs on input rather than at render time, so the value reads the same in the interface, in the API and in reports. Accumulated data is carried onto the same scale, and the coverage trend reads across the whole history of the estate.
- Reliability
Historical communication sessions converted into the v3 schema
Migration commands carry the communication-session history into the third-generation schema. The transfer runs in stages: the device’s own session channels first, then the shared channels of the telemetry unit, then the alignment to the parameter schema. The commands are launched per server and work in portions, so data collection keeps running and charts and reports span the full history of a device.
- Performance
Session parameters moved into the shared archive table
Session headers stay in their own table, while session parameters are written to the shared archive table — the same store the readings go to. The protocol declares which parameters it carries: Type-M has one set of channels, Type-J another, MQTT a third. A new device type is introduced with rows in the channel dictionary, without a database schema migration.
Learn more
Pressure and temperature sensors: the full path
A new device class taken from the protocol all the way to its card in the interface: driver, data model, archive ingestion, sensor-type directories, units of measurement. Alongside it, the data-model links that reports, filters and access rules depend on.
- New
Pressure and temperature sensors: driver, model, archives, device card
A new device class is supported along the whole path. In the collection daemon there is a protocol driver: the identification packet of the autonomous unit, current values, archives, configuration. In the application there is the data model and the write path: current pressure and temperature, archive slices, communication session parameters, a configuration snapshot. In the web interface the device gets a card of its own, with a field set shaped for a sensor.
Learn more - Improved
Sensor type directory and calibration coefficients of the sensor
The sensor type comes from a directory of ranges — absolute pressure 0…160 kPa, 0…400 kPa, 0…600 kPa, 0…1.0 MPa, 0…1.6 MPa, 0…2.5 MPa and onwards per specification — tied to the equipment model in third normal form. The write-path driver resolves the type during device identification, so the range and the units are known to the system and not only to the installer. The parameters tab shows the calibration coefficients of the installed sensor.
Learn more - Improved
Selected units of measurement in every view of a value
The chosen unit of measurement is applied at the presentation layer and holds across every view of the value — the current-pressure tile, the chart, the data journal, the alarm journal. Conversion of absolute pressure into gauge pressure belongs to the same layer: a flag switches it on, and it applies only to sensors that measure in absolute terms. Precision is derived from the sensor — temperature with one decimal place, millimetres of mercury with none.
- Reliability
Completeness check on the configuration archive before the database write
A link to a device can break in the middle of an upload, so the configuration archive is checked for completeness and integrity before the database write. A snapshot gathered only in part does not take the place of the standing one. The event archive is stored alongside the readings. Even an interrupted communication session therefore leaves a trail to work from.
- Improved
Metering unit and utility company linked at the model level
Ownership of a metering unit by a utility company is written as an explicit relation at the level of the database and the data models. Existing records are carried over by migration commands. Report selections, faceted filters and access rules all hang off that relation. They are built straight from the organisational structure, including the way it shifts through reorganisations.
Learn more - Improved
Date filter and export on the transmitted-data journal tab
The transmitted-data journal carries the same toolbar as the other archive tabs. It holds a filter over the period and an export to a file. A selection for the interval in question goes to neighbouring teams straight from the interface, with no database request in between.
Learn more - Reliability
Valve position synchronised with the limit sensors
The closed and open positions are fixed unambiguously by the limit sensors of the actuator. The interface shows exactly the position those sensors confirm and keeps the control active. The state is reconciled after the first power-up, after a manual turn and after service work, so the operator sees the actual position in the field.
External acceptance and a rebuilt data core
The platform went through external acceptance testing: the scenarios were run by outside specialists, and their findings were resolved before the release candidate. In parallel the data core was decoupled — a consumer can be served by several utility companies, and the telemetry module is described independently of IMEI.
- New
A data core rebuilt around the consumer and the telemetry channel
The data core is reassembled for the tasks of the third generation: one consumer can be served by several utility companies, and a telemetry module is described independently of the IMEI. Both separations sit at the schema level, laid down before the rest of the functionality is built on top of it. The third generation therefore carries its own data model, designed for a change of supplier and for several energy resources at a single consumer.
Learn more - Integration
Telemetry module described by channel type and identifier
A telemetry module is described by two fields: the channel type — GSM, Ethernet, MQTT, data concentrator, LoRaWAN — and an identifier of the matching kind: IMEI, IP, MAC, client_id, DevEUI. Controllers, reports, exports, background services and the API all follow the extended model. A new transport is therefore added as a value in a reference list, at a single point of the schema.
Learn more - Reliability
A wave of external acceptance testing
The platform went through external acceptance testing on a demonstration environment: the scenarios were run by outside specialists rather than by the development team. Findings on the object creation wizard, the forms, the faceted filters, the schedules and the localisation of notifications were worked through and closed before the release candidate. External acceptance is part of the cycle as a mandatory stage ahead of a release.
- Improved
Editable operating intervals of the valve control unit
The operating intervals of the valve control unit are edited from the interface. The pre-opening time is set within 1–30 s, the pressure stabilisation pause within 30–600 s, and the full stroke time follows the actuator specification. Values are entered in seconds with one decimal place and checked against those ranges, so the unit and the precision in the form match the equipment data sheet.
Learn more - Improved
Detaching a device from a metering unit without losing history
A device is detached from a metering unit and stays in the system with its own data. Replacement, relocation and return from repair are registered as accounting events. The history of the metering unit and the history of the device therefore both remain continuous and separable.
Learn more - Security
Static security analysis of the code base
The source code goes through static analysis for the standard classes of web-application vulnerability. Every hit is reviewed by hand: the analyser sees no context, so part of the output is set aside as a false positive and the rest is closed before the release. The run is built into the release procedure and repeats on every build.
Learn more - Languages
Platform and devices in 13 languages
The documentation for Platform v3, the IIoT device line-up and the whole portal interface ship in 13 languages. Arabic and Persian are wired in with right-to-left writing: the entire layout mirrors, not just the direction of the text. A page that is still in the translation queue renders in English at its localized URL and carries a noindex tag, so a switch of language always lands on a page that exists.
Learn more - Integration
Third-generation auto-registration across the whole supported line-up
Third-generation auto-registration covers the whole supported line-up, including MQTT-driven shut-off valves. A device switched on at the site creates its own metering unit and is available for reading and control straight away. The identifier travels inside the device packet, so installation calls for no manual entry on the platform side.
Learn more
The V3 stack in an industrial environment
The third-generation collection daemon and data storage were deployed for the first industrial customer and started taking live readings. The public API was verified against the new data model, and the documentation portal opened.
- New
AI Analytics: 22 reports with open methodology and formulas
The AI analytics module: 22 reports on individual nodes and on the fleet as a whole — balances, pressure anomalies, battery-life forecasts, detection of metering bypasses, an atlas of faults. The methodology and the formulas of every report are published: the fields and the assumptions a conclusion rests on are visible, and the figure can be recomputed by hand. That makes a report fit for a walk-through with the customer and for filing with regulatory documentation.
Learn more - New
Illustrated user guide on real screenshots in both themes
A step-by-step guide to working with the platform, built on real screenshots of the interface in the light and the dark theme. Both series are captured from one and the same state of the data, so the steps match across themes. The data on the screenshots is anonymized, which lets the guide be handed outside without a separate clearance.
Learn more - New
IIoT Platform v3: architecture, scaling and conformity with EU directives
A major documentation release: architecture, scaling and conformity with EU directives are described for the third generation. Version 3 is the current one, and the root redirects lead to it. The second generation stays reachable through direct links and the version switcher.
Learn more - Performance
Metering-unit register: table, cascading filters, saved selections
The metering-unit register is sized for a fleet of thousands of records: a paginated table with an action bar, cascading facet filters and saved user filters. Picking a value in one facet recomputes the admissible values in the rest, so no combination ends in an empty selection. The unit page itself is assembled from two panels with tabs and cards.
Learn more - Improved
Unified documentation portal for the platform, API and IIoT devices
The documentation of the platform, the API and the IIoT devices is gathered into one portal: a static build, a shared glossary and an AI assistant over the content. Full-text search runs on the client side, with no external service and no keys. Every page is served as its markdown source as well — for those who read it with a tool rather than with their eyes.
- New
Public REST API for metering units, archives and sessions
The platform exposes a public REST API over metering units and their characteristics, readings archives, device events and messages, communication sessions and reference data. The reference is organised endpoint by endpoint: method, parameters, response format, error codes. An integrator builds the whole connection from the page itself, without accompanying support on our side.
Learn more - Integration
Public API validation against the V3 data model
Every endpoint of the public API is verified against the third-generation data model, one by one. Paths and contracts stay exactly where integrators expect them, so existing integrations keep running without edits. The configuration-archive response carries consolidated metrological parameters — minimum and maximum flow rate, verification date, serial number — which would otherwise take several requests to assemble.
Learn more - New
Pressure and temperature sensor protocol driver in the collection daemon
The collection daemon gains a driver for a new protocol: the identification packet of an autonomous unit, current pressure and temperature values, the archives and a configuration snapshot. It sits next to the shut-off valve handling inside the same protocol family and reuses its session-layer parsing. A month later the complete module rests on that foundation — from the data model through to the device card.
Learn more - Improved
AI reports at every level of the company hierarchy
Report embedding is wired into every level of the company tree: the head organisation, a branch and a subdivision each open their own set of analytical reports. Each node reports on its own scope, at whatever depth of the tree it sits. The embedded block carries no heading of its own, since the section name already stands in the navigation.
Learn more - Reliability
Time-zone offset in collection daemon logs
Collection daemons run in different countries and time zones, so every log line carries an explicit offset — the format reads 2026-05-27 14:43:43 +03:00. Records from separate sites line up on a single scale the moment they are placed side by side. When an incident is reconstructed, the order of events across the fleet is unambiguous.
Learn more - Integration
MQTT shut-off valve stack on the V3 collection server
The stack for MQTT-controlled shut-off valves runs on the third-generation collection server: message exchange, command delivery, data storage and the auto-registration module adapted to the V3 algorithm. A valve connected at a site registers itself — it creates its own metering unit and accepts commands straight away. One server therefore carries the whole fleet of actuators alongside the metering devices.
Learn more - New
Full V3 collection and storage stack at the first industrial customer
The collection daemon and the third-generation collection and storage system are deployed as a complete set at the first industrial customer and take in live readings. From that point the work runs against a real stream: archives, reference data and volumes match industrial operation. Analytics is exercised on genuine field data rather than a test snapshot.
Learn more
Telemetry beyond GSM
The estate gained devices the platform not only reads but also commands: MQTT shut-off valves. The metering-unit register was rebuilt around statuses and geodata fit for a map and for field crews.
- Integration
MQTT driver for remotely controlled shut-off valves
The first class of devices the platform not only reads but also commands. A dedicated driver covers the MQTT exchange, command delivery and storage of the valve’s own data. The control path runs on the same stack as metering, so actuators need no subsystem of their own.
Learn more - Improved
A single geocoordinate format for the whole estate
The geographic coordinates of the estate are brought to a single format: more than eight hundred metering units, of which 761 were processed programmatically and 48 by hand, where the site names called for cross-checking. An audit of the master table follows: five units carry no coordinates, three of them test records. The register is fit for a map, for clustering and for routing field crews.
- Improved
Four working statuses of a metering unit
A metering unit carries four working statuses: in service, disconnected, new, under repair. Each of them corresponds to a specific action by the operator. On the dashboard the statuses are grouped, so the estate summary reads without expanding the full list.
Learn more
The shell of the new interface
The starting point of generation three: one page template, a working global search, a theme manager and a dashboard on the production data model. Localization is built into the components from day one rather than added later.
- Languages
Localization built into the new shell’s components
Localization sits in the foundation of the new interface: every component of the shell arrives with its strings externalized, not with text embedded in markup. The language set of a server is declared at deployment through environment variables — the localization scheme and the list of locales. An installation aimed at another market therefore calls for no rebuild of the image.
- New
Dashboard on the production data model
The dashboard widgets are wired to the production data model: estate coverage, the health of communication sessions and device states on one screen. It is the first exposure of the new shell to real volumes and to the real sparseness of field data. Layout and queries work on an industrial data set, not on fixtures.
Learn more - New
Interface shell: page template, panels, theme manager
The front end is assembled on a single page template: header and footer, left and right panels, a theme manager with light and dark appearance. Global search covers objects, equipment and consumers, with a jump straight to the record it finds. Every section of the third generation is then built from this template, which fixes one common behavior for navigation and states.
Learn more