Existing sensors and loggers can be connected to an online platform without replacing hardware: the logger or hub sends readings over HTTP in JSON format, and the platform accepts them, converts them, checks thresholds, and displays them on charts. The condition is an agreed data contract: device and channel identifier, measurement time in UTC, raw value. If the asset already has sensors, connection to Inclify takes a few days, and the old system runs in parallel during that time.
In brief
- Sensors, loggers, and software are separate layers. Changing the platform does not require replacing sensors if the logger or hub can send data over HTTP/JSON.
- There are three connection points: a logger with its own HTTP sending, a hub placed next to a logger that cannot do this, and history exported from the current system and sent through the same channel.
- The data contract has seven fields: device, channel, measurement time in UTC, raw value with unit, calibration location, device state, a rule for unique identification of the reading, and a raw frame for audit.
- Parallel pilot: the old system keeps running, the new platform receives a copy of the data, after 2-4 weeks you compare the series channel by channel, and only then switch notifications.
- The most common pitfalls are local time instead of UTC, mixed units, double calibration, gaps without NO_DATA state, duplicates, and frames arriving out of order.
You do not have to replace sensors to change software
A measurement system on an asset consists of four layers: sensors, loggers or hubs, transmission, and software. Each ages at a different pace. A vibrating wire sensor cast into a girder can operate stably for more than 20 years. A logger until the first modem failure. Software changes most often: a licence ends, the vendor withdraws a version, the only person who knew how to run it leaves, or you need alarm handling with a procedure and reports that the current program does not provide.
A data logger is a device that polls connected sensors at a set interval, stores readings in memory, and, if it has a modem or another link, sends them onward. A measurement hub is an intermediary device or software that collects readings from one or many loggers, or directly from sensors, and sends them to the platform through one unified path. A monitoring platform is online software that accepts data, converts it, stores it, compares it with thresholds, notifies people, and visualises the results.
As long as these layers remain separate, you can replace one without touching the others. Problems start when the software is tied to the sensor or logger vendor. Then a change of "just the software" looks like a full system replacement, even though nothing changes on the asset. We explain how to spot that dependency before purchase in the 30-question platform supplier checklist, and the difference between a general platform and a Polish SaaS approach in the Vista Data Vision and Inclify comparison.
If your old system is working, you probably have two concerns. First: that migration will take months and the asset will remain unsupervised in the meantime. Second: that after the switch you will lose history, the zero reading, the seasonal background, and years of data that are the only proof of how the structure behaved. Both concerns are valid, and both can be controlled: you switch off the old system only after comparing both series channel by channel, and you migrate history with the original timestamps before you switch anything. The rest of this text explains how to do that step by step.
Imagine a geotechnical engineer taking over an asset from the previous monitoring contractor: several dozen vibrating wire sensors, two loggers with modems, and the vendor software on one laptop. The sensors are fine, the loggers work. What is missing is the layer that shows data online, sends an SMS when a threshold is exceeded, and leaves a trace of who responded. This is the situation in which you connect an existing system to a platform instead of designing it from scratch. Full background on the topic is in the structural monitoring guide.
Success depends on three things: whether the logger can send data over HTTP by itself, or whether you can place a hub beside it that does this; whether you know the channel configuration and calibration coefficients for each sensor, not just the values on the chart; whether you have access to the reading history, because without it the new platform starts without a zero reading and without seasonal background. For you, this means one thing: before you call the supplier, inventory these three items. They, not the software, determine how fast the connection can be completed.
Three connection points
An existing measurement system is connected to an online platform in three places. The first two answer the question "what is happening now" and differ in who physically sends the data. The third answers the question "what happened before".
1. Logger with its own HTTP/JSON sending
This is the shortest path. At a set interval, in Inclify systems every 15 minutes by default, or more often, but the platform accepts any step, the logger sends an HTTP request to the platform address with a JSON document: who is sending, when it was measured, from which channel, and what the value is. It is enough to enter the address, device identifier, and frame format in the logger. The platform replies whether it accepted the frame; if not, it gives the reason so the device knows what to correct.
Measurement time and reception time are two different times. After a communication outage, the logger sends the buffered data in one batch, and the platform must arrange frames by measurement time, not reception time. We return to this in the pitfalls section.
2. Hub next to a logger that cannot do HTTP
Most older loggers do not have built-in HTTP/JSON sending. They do, however, have another documented data output path, and this is what the hub uses. It is a small industrial computer or gateway placed next to the logger. The hub reads the logger through its own method, then sends a unified JSON output. From the platform's point of view, both configurations look the same: one data contract instead of a separate integration for every vendor.
Where the hub gets the data depends on what is already installed on the asset. Campbell Scientific loggers are operated with LoggerNet software, which, according to the vendor, handles programming, communication, and data retrieval from loggers to a computer. The hub reads what LoggerNet has retrieved. Geokon networks are operated with Agent software, which collects data, converts them into engineering units, and exports them to several file formats, manually or automatically. Worldsensing CMT Edge gateways make collected data available through FTP/FTPS, Modbus TCP, API, and an MQTT client. In each of these cases, the hub is a translator between the vendor format and the platform contract, which is why you do not touch either sensors or loggers.
3. History from the current system sent through the same channel
Current data without history is a chart that starts today. To set sensible thresholds, you need background, at least one full seasonal cycle. To defend the data in a dispute, you need a zero reading and continuity from the start of measurements. That is why the third connection point is history exported from the current system.
In practice: you export history from the old software in the form it offers, map the fields to the same data contract as for current data, and send it to the new platform through the same HTTP/JSON channel with the original timestamps. History and current measurements then pass through the same validator and land in the same data model. There is no separate "import" that could interpret anything differently. In Inclify, this path is standard: the platform does not limit the age of sent readings, and a reading with the same device, channel, and measurement time is overwritten, not duplicated, so history can be sent in batches and repeated without harm. The platform does not have CSV/XLSX file import or a form for manual series entry. The only path into the database is the HTTP/JSON channel, and that also applies to history.
Where can you get the export? It depends on the old system. Vista Data Vision provides an API for reading series data (in the documentation: a maximum of 20 variable identifiers per request and 10 000 values per variable), vendor logger software usually has file export, and in the worst case the history sits in logger memory or in a database on a laptop. If the old system has no export at all, that is information in itself. That is exactly what the export question in the platform selection checklist warns about. And if you have a choice, export raw values together with calibration coefficients rather than converted values only: raw values can be recalculated after recalibration, converted values cannot be "un-calibrated".
| Connection point | What question it answers | When you need it | What to watch |
|---|---|---|---|
| Logger -> HTTP/JSON | what is happening now | when the logger has HTTP sending | buffer after outages, measurement time vs reception time, device clock |
| Hub next to logger -> HTTP/JSON | what is happening now | when the logger can only handle files, FTP, Modbus, or a proprietary protocol | the hub as a second destination so the old system still receives data |
| History through the same channel | what happened before | when the asset already has measurements; for thresholds and proof | history units and calibrations vs current data, export time zone |
Manually performed measurements such as levelling of benchmarks, an inclinometer probe run, or a crack gauge reading do not have a separate input in Inclify. If you want to compare them with automation, they reach the platform the same way as everything else: as a separate channel sent through a hub or a user-side script, with measurement time in UTC.
What the data contract must include
A data contract is a written description of what the device sends to the platform, in what form, how often, and what the platform replies. Without it, integration is a verbal agreement between two engineers that ends on the day one of them changes jobs. The table below is the minimum you should require from every party: the logger vendor, the hub supplier, and the platform. The examples are illustrative. For vibrating wire installations, this map is expanded in the detailed guide to integrating a vibrating wire sensor logger, including Hz, digits, the thermistor, and the risk of double conversion.
| Field | Example (illustrative) | Purpose |
|---|---|---|
| Device identifier | dvc01 or the logger serial number |
Links the frame to a specific device; without this you cannot distinguish two loggers on one asset or answer "what did this come from?" |
| Channel / sensor identifier | CH001 plus, in the configuration, the sensor serial number |
Mapping to a platform channel; the mapping should survive logger replacement. A sensor serial number is more durable than a port number. |
| Measurement time in UTC | 2026-03-29 01:15:00 (UTC) |
Measurement time, not reception time, with no ambiguity at daylight saving time change, comparable across devices and with external data. |
| Raw value and its meaning | 2456.3 with the key frequency for a vibrating wire sensor |
Allows the reading to be recalculated after recalibration; this is the evidentiary layer. |
| Calibration location | "platform calculates with project equations" or "logger calculates, platform receives µε" | One source of truth for calibration; without this decision, there is a risk of double conversion or no conversion at all. |
| Device state / quality | measuring, error; missing frame = NO_DATA on the platform side |
Distinguishes "no data" from "zero"; a gap is shown as a gap and a fault as a fault. |
| Unique reading rule and raw frame | rule "device + channel + measurement time = one reading" plus the original payload in the log | Duplicate detection, order reconstruction, audit of "what exactly arrived"; the raw frame is what you show an expert witness. |
For illustration, here is a simplified numeric frame structure accepted by Inclify (contract compliant with SHMmonitor 1.1; some device fields omitted, sample values):
{
"device": {
"id": "dvc01",
"type": "rejestrator-VW",
"currenttime": "2026-03-29 01:15:20"
},
"data_type": "numeric",
"measurements": [
{
"datetime": "2026-03-29 01:15:00",
"keys": ["frequency", "temperature"],
"channels": [
{ "id": "CH001", "data": [2456.3, 12.6] },
{ "id": "CH002", "data": [2391.8, 12.4] }
]
}
]
}
Three things in this frame matter for migration. datetime is the measurement time in UTC, currenttime is the device clock. The platform compares it with its own and, if the difference exceeds 30 s, rejects the frame with code invalid_device_time and sends back the correct time to set. The keys list says what the successive numbers in the data field of each channel mean; a mismatch in the lengths of the two lists causes the entire frame to be rejected, because the platform prefers to refuse rather than guess. The values are raw from the logger. Conversion to µε, mrad, or kPa is performed by the project equations in the platform.
The contract also has another side: what the platform replies. The minimum is acceptance confirmation or rejection with a clear reason, such as unknown device, wrong time, or mismatched lists, so the device knows whether to resend. In Inclify there is one more element: when the device is registered, the platform returns the point from which data is missing for a given measurement type, so the logger resends the backlog after an outage. The contract also includes retention: how long the platform stores raw frames (in Inclify, by default 7 days, configurable; the measurements themselves are not automatically deleted) and in what form it returns data when the agreement ends. This should be recorded in the contract, which is discussed in more detail in the text on monitoring data as evidence in a dispute.
Parallel pilot step by step
A parallel pilot is a period in which the current system continues to operate and remains the source of decisions, while the new platform receives a copy of the same data so that both systems can be compared without risk to the asset. This is an engineering practice, not a guarantee of outcome. We describe the method, not deployment statistics. For you, the key point is that at no step do you switch off what works.
- Inventory. A list of sensors with serial numbers, assignment to logger ports, calibration coefficients and zero readings, logger software versions, who has passwords and SIM cards. Gaps come out right now.
- Agree the data contract. The table from the previous section, field by field, plus the decision on who sends: the logger itself or an intermediary hub, and who converts: the logger or the platform.
- Send a copy. The old system keeps receiving as before. The new platform gets a copy, either as a second destination in the logger or through a hub that reads the logger in parallel. You do not switch off the old system.
- History and mapping. You export history and send it through the same channel with the original timestamps. Each channel receives a name in the platform, a conversion equation if the platform is to convert, and WARNING/ALARM thresholds copied from the monitoring plan. With history, thresholds immediately have seasonal background, and the chart does not start today.
- Parallel period of 2-4 weeks. That is usually enough to see several daily cycles, one communication outage, and, if it happens, one real threshold exceedance. You check completeness (with readings at the default 15-minute interval, one day gives 96 frames per channel, arithmetic, not a result), value consistency, and alarm behaviour.
- Compare channel by channel. For the same raw data, the difference between systems should be zero. A constant difference points to units, calibration, or zero reading. A time shift points to the time zone. A gap in one system that is not present in the other points to buffering or transmission.
- Decision and switch-over. You set the date from which SMS and emails come from the new platform, who receives them, and who confirms them. You leave the old system in read-only mode until the end of the agreed retention period.
Attach the pilot protocol, what was compared, what differences appeared, and how they were explained, to the monitoring documentation. In a dispute, this answers the question of whether the software change altered the data.
Typical pitfalls
Most problems when connecting an existing system are not about transmission. They are about the meaning of the data: when it was measured, in what units, and whether someone has already converted it.
Time zones, daylight saving time, and the logger clock
A logger set to local time produces data that cannot be ordered unambiguously twice a year. On the last Sunday in October, the hour between 2:00 and 3:00 occurs twice, and on the last Sunday in March it does not occur at all. On a tilt chart compared with temperature from another source, a one-hour shift looks like a structural response delay that does not exist. The rule is: the device sends time in UTC, the platform displays it in the user's time zone. A separate issue is a logger clock that slowly drifts. After a year without synchronisation, minute-level differences distort correlations between devices. A platform that compares the device clock with its own and returns the correct time catches this from the first frame; without that, you find out when an expert asks why two charts do not match.
Units
Tilt in mrad, degrees, or sine of the angle; strain in µε or mm/m; pressure in kPa or metres of water column; temperature in °C or thermistor ohms. The same channel in the old system and the new platform can have different units, and both values will be "correct". Illustrative example: 1 mrad is 0.0573°, and for a 1 m segment it is about 1 mm of displacement. If one system shows mrad and the other degrees, thresholds copied "one to one" differ by about seventeen times. The meaning of every number must be part of the contract, not an assumption.
Calibrations entered in the logger vs in the platform
A vibrating wire sensor gives frequency. Strain is obtained from the formula: calibration coefficient times the difference between the current reading and the zero reading, plus a temperature correction. This conversion can be done by the logger, the hub, or the platform, but only one of them should do it. If the logger sends a converted value and the platform has the same coefficients in its equations and converts again, you get a double-converted value. It looks plausible and is useless. Decide in writing where calibration lives. The safest option: the logger sends raw values, the platform converts them, and the equations and their changes remain in the audit log with the before and after values.
Gaps and NO_DATA
A missing frame is not a zero value or the "last known value". After a set time without data, the platform should mark the channel as NO_DATA and treat this as an event to review: battery depleted, antenna broken, buffer full, SIM package exhausted. If the old system drew a continuous line through gaps, after migration the chart will "look worse" visually. That is good news, because only now can you see when the asset was unsupervised. We describe how to set this state alongside WARNING/ALARM thresholds in the post on warning and alarm thresholds.
Duplicates
A device that did not receive confirmation resends the frame. That is correct behaviour. But if the platform accepted the frame and the acknowledgement was lost on the way, the same frame arrives a second time. Without a uniqueness rule, the duplicate lands in the database and corrupts averages, read counts, and data completeness SLA. There are two ways: a sequence number in the frame, or the rule "the same device + the same channel + the same measurement time = the same reading", where a repeated frame overwrites the previous one instead of duplicating it. Inclify uses the second one, which is why sending history twice does no harm. Ask the supplier which rule their platform uses; "none" is a red flag.
Frame order
After a communication outage, the buffer sends delayed frames, often in reverse order or mixed with current ones. A platform that arranges data by reception time will show a value "jump" that did not happen. A platform that arranges by measurement time, and keeps reception time separately in the communication log, will show a filled gap. Ask this directly during the pilot: "What happens when the logger sends 6 hours of data at once?"
What this looks like in Inclify
Inclify accepts data from existing hubs and loggers over HTTP/JSON. This is the standard integration path, not a separate project for each asset. Every exchange with the device goes into a communication log with the raw content of the request and response: the administrator can see what arrived, when, and from which device, and can download exactly that frame. In a dispute or when searching for a calibration error, this saves hours of guesswork. The log is stored for a configured period, by default 7 days. Time in the database is in UTC and displayed in the user's time zone. When a channel stops transmitting, after the configured window it receives NO_DATA status alongside OK / WARNING / ALARM states and is visible like any other event. You send history through the same channel as current data, with original timestamps, without an age limit, with overwrite instead of duplication.
The device type in the platform is descriptive, so a mixed fleet of sensors from several years and several manufacturers is not a problem. The Inclify team has spent 15 years selecting and installing more than 40 sensor types, including vibrating wire, inclinometers (including chain / in-place), strain gauges, MEMS, piezometers, temperature sensors, inductive, piezoelectric, and resistive sensors. So the loggers on your asset are usually not the first ones it talks to. If the asset already has sensors and loggers, connection takes a few days, and a pilot on one asset is one of three standard cooperation models. An overview of platform modules is available on the Inclify platform page.
FAQ
Do I have to replace the loggers to move to an online platform?
No, if the logger can send data over HTTP in JSON format or you can place a hub next to it that reads it and sends the data onward. Sensors and loggers are the hardware layer, the platform is the software layer. You change one without touching the other. Hardware replacement makes sense only if the logger is faulty or data cannot be retrieved from it in any way.
What is a data contract and why must time be in UTC?
A data contract is a written agreement on what fields, in what form, and how often the device sends to the platform, and what the platform replies. Measurement time in UTC removes the ambiguity of daylight saving time changes, allows comparison of data from different devices and external sources, and the platform still displays it in the user's time zone. Local time in the logger is one of the most common causes of "unexplained" chart shifts.
How long does it take to connect an existing measurement system to Inclify?
If the asset already has sensors and loggers, connection to the platform takes a few days: agreeing the data contract, configuring sending from the hub or logger, mapping channels and thresholds. A full deployment with sensor selection and installation takes from several to over a dozen weeks. A parallel pilot, where the old system keeps running, is usually planned for 2-4 weeks. That is practice, not a requirement.
How do I move measurement history to a new platform, and will I lose anything?
Export history from the current system, preferably raw values together with calibration coefficients and zero reading, map the fields to the same data contract as for current data, and send it through the same HTTP/JSON channel with the original timestamps in UTC. In Inclify there is no age limit for readings, and a repeated reading overwrites the previous one, so history can be sent in batches. Verify the units and export time zone, because history and current data must lie on one axis. Switch off the old system only after comparing both series.
Can I upload a CSV file or enter measurements manually?
Not in Inclify. The platform does not have CSV/XLSX file import or a form for manual entry of measurement series. The only path into the database is the HTTP/JSON channel, the same for current data, history, and manually performed measurements. These are sent by a hub or a user-side script as a separate channel. This is a deliberate simplification: one validator, one data model, one communication log, with no second path through which data could enter differently interpreted.
What is a parallel pilot and how long should it last?
A parallel pilot is a period in which the current system continues to operate and remains the source of decisions, while the new platform receives a copy of the same data. After 2-4 weeks you compare values, completeness, and alarm behaviour channel by channel, explain each difference (units, calibration, time zone, buffering), and only then switch notifications. The pilot protocol stays in the documentation as proof that the software change did not change the data.
This text is informational and technical; it is not legal advice. Have the retention, export, and data access provisions in the monitoring supplier contract reviewed by a lawyer.
Sources and further reading
- RFC 3339 Date and Time on the Internet: Timestamps (an ISO 8601 profile used on the internet) - datatracker.ietf.org/doc/html/rfc3339
- ISO 8601 Date and time – Representations for information interchange - standard for date and time notation (no link)
- Campbell Scientific - LoggerNet (software for programming, communication, and data retrieval from loggers): campbellsci.com/products/loggernet; KonectGDS (cloud service, marked by the vendor as "Limited availability" on the website): campbellsci.com/konectgds
- Geokon - Agent, software for configuration, collection, and export of data from GeoNet networks and LC2 loggers: geokon.com/8800-GNA
- Worldsensing - CMT Edge (data export via FTP/FTPS, Modbus TCP, API, MQTT): worldsensing.com/product/cmt-edge/
- Vista Data Vision (Bentley) - documentation: data sources and file import (help.vistadatavision.com/data-source/data-source), API for reading series data (help.vistadatavision.com/web-interface/api; specification apidocs.vdvcloud.com)
- J. Dunnicliff, Geotechnical Instrumentation for Monitoring Field Performance - chapters on data acquisition and data management (no link)
- Inclify - Structural monitoring (SHM): complete guide
- Inclify - What makes up the cost of structural monitoring (TCO) - where the cost of logger, hub, and transmission sits
What next
If you have an asset with sensors and loggers, and what you lack is the layer that shows data online, sends SMS, and leaves a decision trail, we will propose a pilot on that one asset: connection of the existing system in a few days, sending history through the same channel, a parallel period with the old software, and channel-by-channel comparison. You do not replace anything and you do not switch anything off until you see for yourself that both series match. The best time is now, while the old system still works and history can still be exported from it. After the laptop with the database fails or the licence expires, it will be harder. Prepare the list of sensors and loggers, and we will decide the rest together. Book a pilot call - we respond within 24 hours.