SyncTide 1.14.5

SyncTide 1.14.5 — 2026-10-12 — schema 99

Upgrade note: no database migrations. Drop-in upgrade from 1.14.4. Files
set aside earlier only because they had no readings are taken in on the first
scan after the upgrade and leave the list of set-aside files.

• A file with only its header is an empty delivery, not an error. A
  datalogger that has nothing to report yet (just started, or no readings in
  the period) sends its column names and no data. Such a file is now recorded
  as processed with no rows and no longer set aside. A file with lines of data
  that cannot be read (for example values without a valid timestamp) is set
  aside exactly as before, and a datalogger that stops sending data still
  raises its communication alarm.

---

Also included since the previous installer (1.14.3):

SyncTide 1.14.4 — 2026-10-09 — schema 99

Upgrade note: no database migrations. Drop-in upgrade from 1.14.3. Only
Docker installations change; the Windows standalone behaves as in 1.14.3.

• Docker: the server's own log is visible with docker logs. Like every
  other service, the server now writes its log (security-policy reports,
  report and messaging warnings) to the container output instead of a file
  inside the container that was lost at each upgrade.
• Hosted: the Content-Security-Policy can be enforced per installation
  (SYNCTIDE_CSP_ENFORCE=1); without it the policy stays report-only.

SyncTide 1.14.3

SyncTide 1.14.3 — 2026-10-09 — schema 99

Upgrade note: no database migrations. Drop-in upgrade from 1.14.2.

• Devices kept for their history no longer count as silent. A device whose
  Communication Lost alarm is turned off (a device kept only for its history,
  a copy of another installation, a test device) is still listed with its last
  data, shown as "off", and is no longer counted among the devices that stopped
  reporting — in the health panel and in the hosted fleet overview. The
  dashboard's device status already treated it this way.

SyncTide 1.14.2

SyncTide 1.14.2 — 2026-10-08 — schema 99

Upgrade note: one database migration runs on first start (099); it only
adds a table. Take a backup before upgrading, as always.

• A new datalogger export is read. Files whose first three lines are a
  title, the column names and a units line (with the date format, e.g.
  dd/MM/yyyy HH:mm:ss) are imported using the declared date format, and the
  units are kept. Every other format is read exactly as before.
• A file with empty cells no longer breaks the reader. A file with no
  valid rows is set aside with "No valid rows parsed", and set-aside files
  always state the kind of error.
• The ingestion status is the same on every installation. The last run's
  summary is kept in the database, so it is shown even when the ingestion
  worker runs separately from the server.
• Read-only accounts see contact details masked in the messaging history
  and statistics (for example +351•••••789).
• Ports & firewall: the server now reports the ports it is configured on.

SyncTide v1.14.1 — files set aside reach the fleet console

SyncTide 1.14.1 — upgrade from 1.14.0

Before upgrading: take a backup (Configuration → Backup). No database migrations. The full installer moves the embedded Python runtime to 3.13.16; installs updated only with an update package keep their current 3.13 runtime, which is compatible. The installer is unsigned: SmartScreen may warn — More info → Run anyway.

• The fleet console warns about files set aside. Each installation reports
  the intake files it has set aside; the console shows them per installation
  and raises an alert when a file has waited more than 30 minutes (configurable),
  through the same contacts as the "installation stopped" alert.
• Safer fleet console pages. Every value shown from an installation is
  escaped, and alert texts with special characters reach Telegram.
• Windows installer: embedded Python 3.13.16. A full installer upgrade
  moves the runtime to 3.13.16; the build now refuses to ship a runtime that
  differs from its pin.
• FTP and SFTP images pinned to the exact builds already in service.

SyncTide v1.14.0 — faster, lighter and harder to break

SyncTide 1.14.0 — upgrade from 1.13.1

Before upgrading: take a backup (Configuration → Backup). Migrations 097 and 098 run on the first start and only add tables. Do not downgrade below 1.14.x afterwards. On Windows the SyncTide services now start only after PostgreSQL; a fresh install suggests a random database password instead of a fixed one (on an upgrade nothing changes). The installer is unsigned: SmartScreen may warn — More info → Run anyway.

Sessions now also end on the server after the same idle time the screens use (30 minutes by default): an integration that calls the API less often than that must log in again on a 401. The first ingestion cycle after the upgrade reads every intake file once to rebuild its cache.

• A file that cannot be imported is set aside, not retried for ever. It is
  listed with its reason in the ingestion status, can be retried with one
  click, and is retried automatically when it changes or after an upgrade.
  Temporary problems (database, permissions, disk) never set a file aside.
• Faster, lighter ingestion and polling. Measurements are written in
  batches and a slow database no longer holds up the other devices of the
  same protocol.
• Faster alarms, charts and forecasts. The alarm engine reads only the new
  data since its last check, the Explorer filters tags earlier, and forecast
  training on hourly models reads the hourly summary instead of years of raw
  samples.
• Lighter screens. The interface loads in parts (the sign-in page downloads
  about a fifth of what it did), charts no longer redraw when nothing changed,
  and long alarm lists scroll smoothly.
• Security. Sessions expire on the server after inactivity; error messages
  never show internal details; a Content-Security-Policy is reported; the
  fleet console limits repeated failed sign-ins; the Windows installer no
  longer suggests a fixed database password; base images updated (Python
  3.13.16) and pinned.
• Windows services wait for PostgreSQL before starting.

SyncTide v1.13.1 — a failed message never costs an alarm

SyncTide 1.13.1 — upgrade from 1.10.2

Before upgrading: take a backup (Configuration → Backup). Migrations 093
to 096 run automatically on the first start; they add tables, columns and
indexes. If a licensed add-on has records on the install, migration 094
converts them and checks every total before removing anything — on any
mismatch the whole upgrade stops and nothing changes. Do not downgrade below
1.13.x afterwards. The installer is unsigned: SmartScreen may warn — More
info → Run anyway.

Alarms

• A failed message never costs an alarm. If sending a notification hit a
  database error, the alarm check for that minute could be lost for every
  device, while the log still reported success. Each notification now runs on
  its own: an error affects only that message, and it is logged.
• Alarm rules can wait before they fire. A numeric rule takes an optional
  delay: it raises only when its condition has held that long (for example a
  value at 0 for more than 10 minutes). Available on devices with live data,
  not on CSV-file devices, whose data arrives in batches.
• Stale views count only data received from the device. The fleet
  overview, health panel, asset tree and flow diagram ignore values the
  platform computes.

Map and asset tree

• The asset tree greys a silent device again. A device whose last
  communication is older than its configured communication timeout is grey in
  the tree, exactly as on the map and in the alarm engine. A time-zone
  mismatch had kept every device green in the tree.

Forecasts

• Forecast cards say which inputs the model really uses. Inputs the last
  training dropped (for example weather that did not help) are shown apart, as
  "not used in the last training".
• A device that sends data in batches no longer shows a warning between
  deliveries. A short-horizon forecast waiting for the next delivery shows a
  neutral note with the delivery cycle; a delivery that is really late is
  still a warning.

Accounts and data protection

• Read-only accounts no longer see monetary values computed by a licensed
  add-on, nor alarms on them, in any screen, chart, export or history.
• Connection credentials are never returned by the add-on's device answers.

Licensed add-ons

• Devices managed by an add-on can count from machine counters (OPC UA,
  Modbus TCP, IEC 60870-5-104, DNP3, or a CSV logger), with counter resets
  and rollovers confirmed by the next reading and stops taken from the
  machine's state.
• Their internal devices stay internal, their computed values stay protected,
  saving an address list keeps the tags they rely on, and an inactive one
  frees its licence tags.

Full per-version notes: 1.10.3, 1.11.0, 1.12.0, 1.12.1, 1.13.0 and 1.13.1.

SyncTide v1.10.2 — fill a communication gap with the forecast

Five releases on top of 1.9.6 (1.9.7 to 1.10.2). The headline: a communication gap can now be filled with the forecast the prediction module had stored for it.

Upgrading: schema 91 — migration 091 runs automatically when the backend starts (a few seconds). Do not downgrade to 1.9.x after the first accepted fill: a 1.9.x build does not know accepted-forecast rows; it would train on them, drop real data that arrives at a filled instant, and remove replaced rows on a revert.

The installer is not code-signed, as with every release since 1.7.0.

---

Fill a communication gap with the forecast

• A new tool in the Explorer's editor, "Fill gap with forecast". Drag a finished gap on the chart and the stored forecast is staged over it point for point: one point per forecast value, at the instant and with the value and band of the dashed forecast line. Any point can be dragged before accepting; accepting needs a reason and makes one reversible batch, "Forecast accepted", that records the horizon, the model's training date and how many points were adjusted. The device's sampling only decides where the gap is (the rule the chart uses to break a line), so it works the same for loggers that deliver files and for devices on real-time protocols. Instant tags only for now. Needs the editor and prediction modules.
• Accepted points never train or score the model. Training, inference anchors, the band calibration, the delivery-cadence checks, the ceiling measurement and the accuracy panels all leave them out. They are drawn with a dashed ring.
• Real data wins when it arrives late. If the logger later delivers the filled period, the real samples replace the accepted ones and the history says how many were replaced; reverting afterwards leaves the real data alone.
• Forecasts over gaps are kept longer, for a configurable number of days (Configuration › Runtime › Retention, "Forecasts over gaps", default 180), so a gap can still be filled weeks later.

Forecasts

• The confidence band is calibrated against the misses the model has really made. Each run takes the 10th and 90th percentiles of the last seven days' real misses and widens every new point's band to contain them — widened only, never narrowed. On a hosted client's 7-day flow model the fitted band had been covering 59–77% of the real misses against the 80% it is labelled with.

Explorer

• Raw mode shows up to 100 000 samples per series (a week of a logger sampling every 8 seconds) and says under the chart when a longer window had to be cut.
• Responses are compressed: a hundred thousand raw rows go from six megabytes to well under one.

Security and editing

• Every edit checks who may touch the device. Editing points, offsetting a period, adding points and reverting now check the user's device scope; an administrator restricted to some devices could previously change measurements on any device.
• Series the platform rebuilds itself are not editable, since an edit there was silently overwritten at the next rebuild.
• The ingestion worker and the editor share a per-series lock, so an edit, a fill and a late delivery of the same instants can never cross; a long edit holds ingestion back for at most 30 seconds.

SyncTide v1.9.6 — alarms keep going, nothing waits forever

One release on top of 1.9.5, made of a general audit: what could stop alarms or data collection without anyone noticing, what could freeze the platform, and four security holes.

Upgrading: schema 90 — migration 090 runs automatically when the backend starts (a few seconds). Coming from 1.9.4 or earlier, read the 1.9.5 notes first: since 1.9.5 only equipment tags mapped to a system tag with the mapping switched on keep history.

The installer is now available in Portuguese, shows licence agreement 2.0 (English and Portuguese) and installs THIRD_PARTY_NOTICES.txt with every bundled component and its licence. It is not code-signed, as with every release since 1.7.0.

---

Alarms and data collection keep going

• One faulty device can no longer silence every alarm. The alarm engine evaluates all devices in one pass. A database error on a single device used to abort the pass and undo the alarms already recorded in it — for every device — while the engine still reported itself healthy. Each device is now evaluated on its own.
• Nothing waits forever any more. Database waits, queries and idle transactions have limits; a CSV ingestion run that hangs is stopped and retried; two public endpoints no longer block the whole server while they wait on the database; the nightly retention continues past a failed step.
• The Windows service waits for the database after a reboot instead of failing with a misleading schema error; the MQTT subscriber no longer restarts (and loses messages) over a transient database error.

Faster as history grows

• Fewer, larger storage chunks for new data (a week instead of a day). Planning a query costs a step per chunk; with years of history that had become the main cost of the queries the alarm engine runs every 5 seconds.
• Faster queries for the alarm engine's latest values, the fleet health and flow views and the prediction ceiling card, and new indexes for the alarm list. Results are identical — every rewritten query was compared with the old one.

Security

• A Telegram reply acknowledges an alarm only from the chat the alert was sent to.
• The tag limit can no longer be bypassed through production devices, nor by two simultaneous requests for the last tag.
• The Telegram bot token no longer appears in delivery errors; the SMS webhook secret is shown to administrators only; operators restricted to some sites no longer read other sites' mappings, monitoring settings or PLC addresses; alarm acknowledgement by token is POST-only and rate-limited; a licence is verified before it replaces the current one; baseline security headers on every response; passwords set by an administrator need at least 8 characters.

Licences

• MAC-bound licences work in virtual machines. VMware and Hyper-V network adapters were ignored, so a licence could never match inside a VM.
• A licence file replaced on disk takes effect without restarting the services.

Web interface

• When the server does not answer, the interface says so. The top bar shows OFFLINE since hh:mm and the alarm list keeps its last known state — it used to empty itself, which read as "no alarms". Polling backs off while the server is down and pauses in background tabs.
• An expired session returns to the login page with a message; a failed start shows an error with a retry; a failed chart refresh keeps the last data.
• Moving the mouse over a chart with a lot of data no longer freezes the page.
• Fonts and the map library are served by SyncTide itself — nothing is loaded from Google or unpkg, and installations without internet get their fonts. Only map tiles come from OpenStreetMap.

SyncTide v1.9.5 — the tag limit counts what you use

One release on top of 1.9.4. Schema 89, unchanged — no migration on upgrade.

Before you upgrade: from 1.9.5 on, only equipment tags mapped to a system tag with the mapping switched on keep history. Columns a datalogger sends that are not mapped still appear in the tag list and in the Real Time tab, but their values are no longer written to history. If there is a column whose history you want, map it and switch it on before upgrading. CSV files still in the intake folder can be re-read later to fill in a tag mapped afterwards; live protocols (OPC UA, Modbus, IEC 104, MQTT) have no copy to re-read.

The installer is not code-signed, as with every release since 1.7.0.

---

The tag limit counts what you use

• Only active mappings count toward the licence. The limit counted every
  column a datalogger sends, mapped or not. A CSV logger that reports eighteen
  columns, of which six feed the platform, needed a plan for eighteen. It now
  counts equipment tags mapped to a system tag with the mapping switched on —
  the same six. Production-module tags never counted and still don't.
• Only those tags keep history. What is stored is exactly what is counted:
  a column without an active mapping still appears in the tag list (so it can
  be mapped) and still shows its current value in the Real Time tab and in the
  device's freshness, but its values are not written to history. Mapping it
  later starts its history from that moment. The Active switch in the mapping
  editor says so.

Lines break only where data is missing

• A coarse interval no longer reads as a communications failure. A line
  broke whenever two points were further apart than one and a half times the
  device's sample period. At a 30-minute interval over 15-minute samples every
  pair of points is 30 minutes apart, so every pair was a "hole" and the
  Explorer drew a scatter of dots. The threshold is now the wider of the
  sample period and the chosen interval, in the Explorer and in both dashboard
  trends — the rule the Prediction page already used. An interval with no data
  still breaks the line.

Licences

• A licence file replaced on disk takes effect on its own, without
  restarting the services — every process notices the file changed. Uploading
  a licence from the License tab works as before.
• Failed actions show a red notice instead of a green check.

SyncTide v1.9.4 — years of history count, and the ceiling before you train

Two releases on top of 1.9.2. Schema 89, unchanged — no migration on upgrade.

The thread through both: a hosted client whose logger uploads twice a day and went quiet for three days taught the forecasts to read delivery cadence off the right clock, to keep years of history instead of one, and to say plainly which trivial references a model has to beat before anyone trains it.

Anything forecast-related needs a licence with the prediction module. The installer is not code-signed, as with every release since 1.7.0.

---

1.9.3 — 2026-09-30 — schema 89

• The delivery-cadence guard reads the clock it should. 1.8.5 taught the
  staleness guard to recognise a feed that uploads a few times a day by
  measuring the gap between its deliveries. It measured that gap inside a
  window of sample times, which is the wrong clock: a delivery is a moment
  rows arrive, whatever hours they carry. On the first hosted client the
  logger went quiet from 26 to 29 September, then delivered a three-day-old
  catch-up file at 15:17 and a full day of fresh data at 21:56 — two arrivals,
  hours apart. Inside a 26-hour window of sample times only the fresh one
  existed, the guard saw a single arrival, found no cadence, and fell back to
  two buckets: "latest value is 681 min old (limit 120 min)", the exact badge
  1.8.5 was written to retire, back on the model for ten hours of every day.
  The window is now seven days of arrival time (bounded on sample time for
  the index), so a catch-up delivery counts as the delivery it is, and a feed
  silent for longer than a week has no recent cadence and is judged dead by
  the bucket rule — the right verdict for one that has really stopped.

1.9.4 — 2026-09-30 — schema 89

Years of history now count

• The long-horizon class trains on up to three years (it was capped at
  365 days). One year shows each season exactly once, so the model learned
  what this September looked like rather than what Septembers look like; two
  years is the minimum for a season to be an average instead of a memory, and
  three keeps an odd year from deciding it alone. The cap is a ceiling, not a
  requirement: a client with 77 days trains on 77 days, and a client who keeps
  years of history is the reason to keep them. Weather archive backfill and
  retention widen with it automatically. A validation probe on a signal with
  annual structure asserts that the extra years never cost accuracy.

The ceiling card reads the season too

• Two seasonal references on "Measure the ceiling": repeat the value from
  52 weeks ago (the same hour and weekday one year back — 364 days so the
  weekday lines up) and the average for this week of the year and hour, a
  table of the season across the years on record. Both show a dash until the
  history can honestly answer them — a year for the first, two years for the
  table, because with one year every cell would be a single remembered day
  and the number a memory, not a forecast. The card now scores up to 400 days
  so the first has a year to pair against.
• The reading sentence names phases, not a distance. It said "repeating
  the last value beats the table up to about 24 h ahead", as if there were a
  line. On a signal with a daily cycle there is not: an hour ago and a day ago
  both beat the table while six hours ago — the opposite phase of the day —
  loses badly. It now lists which lags win and which lose, and says why.