Changelog

If you connected Claude or another MCP assistant to Synacl, you will have noticed it asked you to approve it again roughly every hour. That was a defect, not a policy.

Fixed — the connection now renews itself

When you approve an assistant, Synacl hands it a short-lived credential and a renewal credential. The first lasts an hour; the second lets the assistant renew quietly for up to 30 days of use, and is replaced every time it is used. Until now only the first was being issued, so the assistant had nothing to renew with and sent you back to the consent screen when the hour ran out.

Assistants you connected before this release need one more approval to receive their renewal credential. After that they stay connected until you disconnect them under Settings → API & Agents, which still ends the connection immediately.

Also fixed

• Disconnecting via the standard token-revocation endpoint now actually revokes the token.
• A stolen or replayed sign-in code now invalidates both credentials it produced, not just one.

A heartbeat monitor used to have exactly one way to fail: stop checking in, and wait for the missed-check-in window to run out. That is the right signal for a machine that has lost power. It is the wrong one for a machine that is fine and knows the thing it watches is not — a till whose card reader has died still checks in every five minutes, and stayed green.

New — a heartbeat can report itself down

Send {"up": 0} instead of {"up": 1} and the monitor is marked down at once, with the cause reported down. The incident log and the Monitors page say so, distinguishing "the service told us" from "the service went quiet". Send {"up": 1} and it comes back through the normal path. false, "0", "false" and "down" all count as down, so a shell script can pass its result straight through. Silence still works exactly as before.

Two settings in the monitor's Edit panel let a service keep its own vocabulary: the Up/down field (default up) and the Latency field (default response_ms), which feeds the Response column and the response-time chart. A service that already reports odoo_ok and odoo_ms no longer has to be rewritten to fit ours.

New — the Monitors row shows the values a heartbeat pushes

Every adopted tag's latest value now appears on the monitor's row — queue depth, backup age, whatever the service reports — without opening the device page.

Fixed — the "unrecognised fields" banner never appeared on a new heartbeat

A heartbeat starts with no tags, because only your service knows what it reports. The banner that offers to add them was only computed once a device already had at least one tag, so the one device type that always begins tagless never saw it. It now appears on the first push.

Fixed — "Last seen" is now the real last check-in

The Monitors page reported the moment you loaded it for anything that was up, and the start of the outage for anything that was down. It now shows when the device was actually last heard from, for up and down alike.

Changed — a brand-new monitor is measured over its lifetime

A monitor created two hours ago is no longer shown with 24 hours of assumed downtime it did not exist for. Its 24-hour availability describes the two hours it has actually been around, and it is flagged as inferred until it has real events behind it.

Fixed — a dashboard that would not save, and an SLA target that would not update

A widget setting the app did not recognise (one written through the agent API, for example) made the whole dashboard fail validation, so every edit ended in Invalid Config with no explanation. The app now removes such settings when the dashboard opens, tells you which widget lost what, and saves clean. When a save is blocked, the badge names the widget and the field instead of just saying "invalid". The four uptime widgets also re-read their settings the moment you change them, so a new SLA target shows within a second rather than after the next refresh; a target of 0 is refused up front, as the API would refuse it anyway.

Changed — the agent API checks widget settings

Creating or updating a dashboard through the agent API now validates each widget's settings against the app's own widget definitions: unknown settings are dropped with a warning, and a wrong type or a missing required value is an error, so an agent can no longer build a dashboard the app cannot save.

There is now a free web flasher at synacl.com/flash. It flashes any .bin to an ESP32, S2, S3, C3, C6 or ESP8266 from Chrome or Edge over Web Serial — the same mechanism the in-app flasher uses, with nothing installed and nothing uploaded.

• Your own firmware. One or more files at the offsets you choose, with presets for application-only, merged images and full bootloader/partition/app sets.
• Synacl gateway firmware in one click. Flash the latest stable build without signing in. The board waits until you register and provision it from Gateways → Add gateway, where you can skip the flash step.
• Chip detection, progress and a serial monitor, so you can watch the board boot after writing.

Re-flashing still leaves the settings partition alone, so an existing gateway keeps its Wi-Fi and MQTT provisioning.

A monitoring product has one job: tell you when something is wrong. This release fixes a set of places where Synacl was quietly not doing that — accepting work and reporting success while the useful part went nowhere. Most of it was found by wiring a real three-terminal shop fleet into Synacl end to end and watching where it went wrong.

Fixed — offline alerts could not tell you what went offline

• An alert rule on a device goes offline now lets you pick the device or gateway to watch, instead of firing for anything on the account. The old behaviour is still there if you want it, but scoping matters more than it looks: one rule has one cooldown, so an unscoped rule that fires for your first failure stays quiet for everything that fails after it.
• Whether or not you scope it, the alert now names what happened to what — "Rule 'Till down' fired on device/offline — POS · Counter 2" — in the email subject, the message and the webhook payload.

Fixed — the alert email for an event rule was blank

An email from an event rule arrived as a rule name, a severity badge and four empty rows: it was rendering the threshold layout (Device / Tag / Measured Value / Condition) for a rule that has no reading to put in it. Event alerts now get their own layout, saying what happened and to what.

While fixing it we found that threshold alert emails had always printed the device's internal id where its name belongs. They now show the name.

Fixed — a monitor could look healthy and report nothing

A heartbeat monitor starts with no tags, because only your service knows what it reports. If it pushed a field the monitor had no tag for, the check-in was accepted, the monitor went online, and the value could not be read back anywhere — with nothing to say why.

• The monitor's page now shows which fields it is receiving and has no tag for, with a button to add them all at once.
• Nothing was ever lost. Those readings have been recorded all along and were simply unreadable; adding the tag makes the history already stored under it readable too.

Fixed — an hourly heartbeat reported false outages

A monitor set to check in every hour was marked down after exactly an hour of silence, so any delay at all — a cron firing a second late, one slow request — looked like an outage. Slow-cadence monitors now get real headroom before they are called down. Every other interval is unchanged.

Improved — the webhook ingest reply tells you what happened to your data

Pushing to a device's ingest URL always answered "accepted", including when the reading was being dropped for exceeding your plan's publish rate, and including when the device had been suspended for repeated violations. The reply now says whether the reading was kept, how many rate violations have been counted against the device, and — if it has been suspended — that it has, and when that lifts. Useful when you are building an integration and would rather find out now than from missing data later.

New — for AI agents

If you have connected an assistant, it can now do rather more:

• Create uptime monitors, including a heartbeat, and get the check-in URL and secret it needs to wire your service up — instead of you copying a secret out of the app by hand.
• Create offline alerts. Event rules were previously beyond it, which meant the one alert a heartbeat monitor exists for could not be set up by an agent.
• Read uptime history — availability, coverage and past incidents — if you grant it that permission. It was previously able to see only whether something was up right now.
• Retune a monitor and adjust how long silence is tolerated before a device is called offline.
• See what you have used, not just what you are allowed. It now knows your device, rule and monitor counts, and how much of your monthly alert-action quota is spent — with a warning as that runs low, because when it runs out alerts simply stop being delivered.
• Filter and page through devices instead of pulling the whole fleet at once.

You'll be asked to approve the new uptime permission the next time an assistant requests it; existing connections keep exactly the permissions you already granted.

If you ever added a device to a gateway and its readings never appeared — no error, nothing in the events feed, the gateway plainly online — this release explains it and fixes it.

A gateway receives its entire device configuration as a single message. That message had a size limit, and past the limit the gateway discarded it silently: no error to the gateway, and none back to us, because the delivery receipt we were reading only proved the message reached the broker, not the device. The gateway simply kept running its previous configuration forever.

The practical effect was a ceiling of roughly two devices, or ten tags, per gateway — low enough that people hit it in normal use, and invisible enough that it looked like a wiring or network fault rather than a limit.

Fixed — a gateway holds three to four times more

Most of what we were sending, the gateway never read. Display labels, sort categories, form state, internal identifiers — all of it travelled to the device and was thrown away there. We now send only the fields the hardware actually uses. A typical tag went from 330 bytes to under 100, so the same gateway on the same firmware now carries roughly 25–35 tags instead of about 10 — nearer the top of that range when they sit on fewer devices, since each device costs a little overhead of its own.

Nothing about your devices changes, and you do not need to reconfigure anything.

Your gateways will restart once. The configuration they hold is now different, so each gateway applies the new one and reboots a single time on its next check-in. It comes back on its own within a minute. This happens once, not on every change.

Fixed — you are told before you hit the limit, not after

There is still a limit, because the hardware still has one. The difference is that you now find out when you try to save, with the exact number of bytes to free — instead of saving successfully and discovering days later that the gateway never got it.

Removing a tag or device is always allowed, even on a gateway that is already over the limit, so a gateway in that state can always be brought back under it.

Fixed — two smaller problems found on the way

A device using webhook data ingest could restart its gateway on every single reading it received, because a timestamp we updated on each push was part of the configuration the gateway watches for changes. That timestamp is no longer sent.

A device's webhook secret was also being included in the configuration sent to its gateway, and stored there. It no longer is. Existing secrets were not exposed outside your own hardware, but if you would like to rotate one, you can do so from the device's page.

Still to come

Gateways with very large tag counts — beyond the new ceiling — need a change to the gateway firmware itself, which is in progress. This release is the part that works on the firmware you already have.

A follow-on to the gateway configuration work in 1.15.0. That release fixed configs that vanished without a word; this one closes the same gap on the two other things Synacl sends a gateway.

Fixed — macro programs and job settings now fail loudly

Both are sent to the gateway as a single message, and both had the same flaw as device configuration: past a size limit the gateway discarded the message silently, and nothing on our side noticed, because the delivery receipt we were reading only proved the message reached the broker.

The consequences were quiet and confusing. A macro set that was too large simply did nothing when you ran it — the gateway had never received the program. Job settings that were too large left the gateway running a job without its operational limits or its hooter, while the job report described limits the hardware had never actually been given.

Both now refuse and tell you, with the exact size and what the gateway can accept, and both raise an event so it appears in your feed rather than only in a server log.

If you see one of these, the fix is the same as for device configuration: reduce what is on that gateway, split across a second gateway, or update the gateway's firmware.

Coming — much larger configurations

Gateway firmware 1.6.0-beta.2 adds the ability to receive a configuration in parts rather than one message, which removes the size ceiling almost entirely. It is on the beta channel for testing on real hardware first. Nothing changes for your gateways until you choose to update them.

If a rule sent data to your webhook and your endpoint was down, Synacl told you nothing. The rule showed as fired, the alert appeared, and the delivery quietly failed. That's fixed, along with a few things underneath it.

New — failures show up on your Events page

When a rule's action fails, you now get an Action Failed event with the reason attached — the HTTP status your endpoint returned, or a timeout. This covers every action type a rule can run: webhooks, emails, MQTT publishes, macros and device commands.

Each failing action is recorded at most once a minute, so a rule firing every ten seconds against a dead endpoint won't bury your event log.

Worth knowing: if you have a rule whose webhook has been failing for a while, you'll start seeing it now. It was failing before — there was just nothing to show it.

New — custom headers on webhook actions

Rule webhook actions and saved Actions now accept custom HTTP headers, the same way egress destinations already did. Useful when your endpoint needs an API key, a tenant identifier, or a routing header.

A handful of header names are reserved and will be rejected when you save — Content-Type, Host, Content-Length, Connection, Transfer-Encoding, and X-Synacl-Signature. Those are set by the platform, and letting a custom value override the signature header would break the guarantee your receiving endpoint relies on.

Fixed

• Actions using PUT, PATCH or GET were sent unsigned. If you'd configured a signing secret, it was applied to POST requests only — the other verbs went out with no X-Synacl-Signature header at all. They're now signed like everything else. If your endpoint validates signatures and was skipping them for non-POST requests, it can stop.
• Your plan's allowed action types are now enforced on saved Actions. They were always enforced on rules; Actions could be created and run regardless. If an action type isn't on your plan you'll now see a clear message instead of it silently working.
• A destination disabled by support now says so. If our team disables one of your egress destinations, the reason and the time appear on the destination itself, and you can re-enable it yourself.
• Several hardening fixes to how outbound URLs are validated, so a destination can't be pointed at an internal address.

Signing out of the Admin panel or the Partner Portal returned an error instead of completing, and left the session record on the server behind.

Fixed

• Sign out. The sign-out request failed every time it was made, so the server-side record of your session was never cleared. Your browser still discarded its credentials, and sessions continued to expire on their own as normal — but the tidy-up that should have happened immediately never did. Signing out now completes and clears that record, including when your session had already timed out.

Notes

• Nothing to do on your side. If you want to be certain an old session is gone, sign out once more.
• This does not change how long a session lasts. Stronger session controls — ending a session everywhere at once, and cutting one off the moment you sign out — are in progress and will follow in a later release.

Two fixes: partners can sign in again, and a gateway's amber "needs attention" dot now updates by itself instead of waiting for a page refresh.

Fixed

• Partner Portal sign-in. Signing in at partner.synacl.com failed with a browser security error and no explanation. The API was refusing the Partner Portal's requests because the portal's address had never been added to its list of permitted origins — an omission dating back to the portal's launch. The list is now derived from the platform's own domain, so every Synacl app is trusted automatically and a new one can't be missed. Only sign-in was affected; no partner data was ever at risk.
• Live gateway health. A gateway shows an amber dot when it is online but one of its devices has stopped responding. That dot was correct whenever you loaded or refreshed the page, but it never changed on its own — the update that should have arrived the moment a device dropped or recovered was failing silently. It now updates live, as it was meant to. Device online/offline indicators and alarms were not affected.

Notes

• Nothing to do on your side, and no settings changed.

Partners can now build reports across every customer they manage — telemetry trends, uptime and SLA, alarms, and fleet health — download them as PDF, Excel or CSV, and have them delivered by email on a schedule.

New — the reporting suite

• Four report types. Telemetry trend charts values over time and is the only view that compares customers side by side. Uptime / SLA reconstructs availability per device and gateway against a target you set. Alarms & events shows breach volume, severity mix and the noisiest equipment. Fleet health surfaces data quality, gaps and silent devices.
• Tags that never reported. Fleet health lists every tag configured on a device that has never produced a single reading — usually a wrong Modbus register, a bad JSON path or a sensor that was never wired. Found in a report instead of on a return visit.
• Distribution, not just averages. Telemetry reports carry p50, p95 and p99 alongside the mean, because an average hides the excursion that tripped the alarm.
• Saved reports and scheduled delivery. Save a report, then schedule it daily, weekly or monthly. Each schedule keeps its own timezone, so 07:00 means 07:00 where the reader is.
• White-labelled output. PDFs carry the partner's company name, colours and logo; charts take their palette from the partner's brand colour; replies go to their support address.

Notes

• Reports say what they don't know. Periods with no recorded history render as a distinct grey band and are excluded from availability figures rather than counted as uptime. Customers on realtime-only plans appear in every report clearly marked and with no figures — never with a zero, which would read as an idle plant.
• Each customer sees only their own data. A report emailed to a customer contains only their rows, with cross-customer comparisons removed.
• Recipients must already be members of the partner's team or of that customer's account, re-checked at send time — so someone who leaves a team stops receiving the next morning.
• Event history is kept for 30 days, so uptime and alarm reports covering a longer range are shortened, with the shortfall shown rather than filled in.
• Automatic email delivery is enabled per partner account; building, running and downloading reports is available to every partner.
• Nothing changes in your own app — this is a Partner Portal feature.

Two fixes to how we track whether your devices are alive — and, for some of them, whether we were keeping their data at all.

Online status now matches how often your device actually reports

Until now every device was judged by the same 90-second clock. That worked for equipment connected through a gateway, which checks in every few seconds regardless of how often it publishes — but it was wrong for anything that reports on a slower schedule.

Each device now gets a window based on how it actually reports:

• Through a gateway — unchanged at 90 seconds. Your RS485 meter set to publish every 5 minutes was never at risk, and still isn't.
• Polled by us (HTTP, SNMP, Modbus TCP) — three times your configured poll interval.
• Edge/fog devices — 15 minutes, matching the fog node's own heartbeat. These previously flickered between online and offline all day on perfectly healthy hardware.
• Direct MQTT and webhook — still 90 seconds by default, since we can't see the reporting interval of a device that pushes to us. If yours reports less often, set a reporting grace period on the device and it will stop flapping.

Alongside this:

• Offline events now carry the real last-seen time instead of an approximation, so an outage's start time on the events feed is the actual moment we last heard from the device.
• A device that publishes faster than your plan allows is no longer reported offline. Its extra messages are still dropped, but being over-rate is a quota matter, not a connectivity one, and it should never have looked like the device had dropped off the network.
• A gateway that vanishes without warning is now detected. Gateways check in every minute; if we miss three in a row the gateway shows offline even when we never received a disconnect notice. Previously a gateway that lost power abruptly could keep showing green.

HTTP, SNMP and Modbus TCP devices now keep history

Devices we poll directly were only ever streamed live — their readings were shown on dashboards but never stored. Charts beyond the newest value were empty, and there was nothing to export or report on.

These devices are now handled exactly like every other kind, which means they get:

• Stored history, so charts, exports and reports work the same as for gateway-connected equipment.
• Threshold alerts. Alert rules on a polled device previously never fired at all. They do now.
• Egress forwarding to your configured destinations.
• Correct online status — they were previously shown as permanently offline even while polling succeeded and data flowed.

Storage still follows your plan: realtime-only tiers and accounts at their storage cap continue to stream live without persisting.

Gateway firmware 1.5.0 is now the stable release. If your gateway is on an older version, its card shows an Update firmware button — one click updates it over the air, with your Wi-Fi and MQTT settings preserved.

New in firmware 1.5.0

• Wired Ethernet (W5500). Gateways fitted with a W5500 module can use a wired uplink — or run dual-NIC with Wi-Fi to the cloud and Ethernet to local equipment. DHCP or static addressing, automatic fallback to Wi-Fi, and pin-conflict protection so an Ethernet port never fights your sensors for a GPIO.
• Offline resilience groundwork. The firmware can now buffer readings locally through a connection outage and replay them once the broker is reachable again, so short network blips no longer mean lost data. This is being enabled account-by-account — watch this changelog.
• More reliable device polling. Per-device read cadence, Modbus TCP unit-id addressing, and a fixed TCP write path (carried over from the 1.4.4 maintenance release) are all part of the mainline build.

Firmware updates, upgraded

• Beta-channel gateways on a 1.5.0-beta.* build graduate to stable 1.5.0 automatically on their next update.
• Updates are safer behind the scenes: releases are tracked with full version history, and a withdrawn release can be rolled back platform-side without any action on your part.

The browser flasher now understands firmware channels. Until now, flashing over USB always wrote the latest stable build — fine for a brand-new gateway, but wrong for one enrolled in the Beta program, and the only way to recover a stuck beta gateway was over the air.

New — channel-aware USB re-flash

• Flash via USB on a gateway's card jumps straight to the flasher with that gateway selected. You can also pick any of your gateways under "Re-flashing an existing gateway?" on the Add gateway page.
• The right build, automatically. A gateway on the Beta channel gets the latest beta firmware; everything else gets stable. New gateways always get stable.
• See it before you flash. A banner shows the exact version and channel that will be written — no surprises.
• Settings survive. Re-flashing preserves the gateway's Wi-Fi and MQTT provisioning, so there's nothing to re-register or reconfigure.

Partner Portal

• The commissioning wizard's Flash step gains the same Firmware target picker, so installers can re-flash a customer's existing gateway — following that gateway's channel and the customer's beta access — without re-registering it.

Details: Flash an ESP32 from your browser and firmware channels.

Reporting a bug used to be a bit of a one-way street. You'd send it, we'd fix it, and the only sign was a banner you might notice on your next visit — days later, long after you'd stopped caring.

Resolved reports now reach you

• A notification the moment it's fixed. When a report you filed is marked Resolved, you get a toast straight away if you have the app open — and a push notification on your phone if you use the mobile app with notifications turned on.
• The banner still backs it up. If you weren't around, the notice in the banner at the top of the app is unchanged, and still waits two weeks for you.
• Closed reports stay quiet. A report marked Invalid only updates the banner. We'd rather not interrupt you to tell you we couldn't reproduce something.

Reopened reports won't contradict themselves

Occasionally a fix doesn't hold and we reopen a report. Previously that could have followed the resolution notice with a second, conflicting one. Reopened reports now go quietly back to In review — the notice you already read just expires on its own.

Nothing changes about how you file a report: the report option in the topbar menu, same as before. The Help Center article covers the full status list and the plan-extension reward for reproducible bugs.

A batch of dashboard-builder improvements: faster ways to get widgets on the canvas, a new widget for reading devices on demand, and fixes for the rough edges you told us about.

New — quick-add widgets straight from your tags

• The Add Widget drawer has a new From device tags tab: every device and its tags in one searchable list. One click adds the tag to the dashboard as a ready-configured digital readout — name and unit filled in, no setup. The drawer stays open so you can add several in a row.

New — On-demand Read widget

• Shows a tag's value with a Read now button that asks the gateway to read the physical device immediately — no waiting for the next poll. Perfect for read-on-demand tags that aren't polled automatically.
• On-demand readings are streamed live but not stored in telemetry history, so your charts and storage stay clean. Reads are rate-limited to one per device every few seconds.

Improved

• No more demo data on new widgets. Freshly added widgets used to show a fake demo signal until configured; they now show a clear Not configured prompt with a one-click path to the settings panel. (The explicit Mock / Debug Signal source still works when you want it.)
• Widget titles and units fill themselves in. Picking a device tag on the Data tab now auto-fills the widget's title, label, and unit from the tag — your own custom text is never overwritten.

Fixed

• The widget picker sometimes opened empty on first click (most noticeable on new accounts with no devices) — it now always shows the catalog immediately.
• Navigating away from a dashboard with an invalid, unsaved configuration used to silently do nothing for 10 seconds. You now get a clear dialog listing what's wrong, with Stay & fix or Discard changes & leave.

Partners now have their own in-context help, right inside partner.synacl.com — so installers and resellers can find commissioning and troubleshooting guidance without digging through docs meant for account owners.

New — Partner Help Center

• Help built for partners. A separate library of articles covers the partner workflow — getting started, branding, commissioning gateways and devices, working with customers, and diagnostics — written for the partner role rather than the account owner.
• In-context and searchable. Partners open Help from inside the portal, search across the partner articles, and read them in the same light/dark theme as the rest of the workspace.

Notes

• Partner and account-owner help are kept separate: partners see only partner articles, and the main Help Center in your app is unchanged.

Installers and resellers who look after your Synacl fleet now get their own portal at partner.synacl.com — so the people who commission and support your hardware can do it without touching your account.

New — Partner Portal

• A dedicated partner workspace. Partners sign in to their own portal — branded with their company name, logo and colors — and see only the customers who have been assigned to them.
• Fleet overview at a glance. Partners see device and gateway health across the customers they support: online counts, recent events, and per-customer drill-downs.
• Guided commissioning. A step-by-step wizard walks a partner through flashing a gateway in the browser, registering it to your account, and adding the connected devices — then verifies everything comes online.
• Access you control. A partner only ever sees a customer's fleet while an access grant is active. Assigning a partner creates the grant automatically; removing them revokes it instantly. Every action a partner takes is audit-logged.

Notes

• Partner access is read-plus-commissioning only: partners can never delete devices, send control commands, or see billing.

Devices can now send telemetry to Synacl over plain HTTPS, as an alternative to connecting over MQTT. Perfect for anything that already speaks HTTP — a script, a cloud function, or a device stuck behind a firewall that only allows outbound web traffic.

New — Webhook data ingest

• A first-class protocol in Add Device. Pick Webhook (HTTP push) when adding a device — the secret is minted and ingest enabled in one step, and the endpoint + ready-to-paste curl appear on the device page immediately. No gateway, no broker credentials.
• Push data with a simple HTTPS request. Each device gets its own POST /ingest/webhook/<deviceId> endpoint. Send a JSON body of tag/value pairs and you're done — the reading shows up live on your dashboards.
• Per-device secret. Generate or rotate a webhook secret right from the device's detail page. Authenticate with either a bearer token or an HMAC-SHA256 signature of the request body — whichever you prefer.
• Flexible payloads. Send a flat { "temperature": 22.5 } and let the server timestamp it, or a native shape with your own timestamp and a quality flag.
• Same pipeline as MQTT. Data that arrives over the webhook flows through the identical path — live dashboards, stored history, threshold alerts, actions, macros and egress all work exactly as before.

One small guard that comes with this: a device's protocol can no longer be switched to or from Webhook or mqtt-direct after creation (their credentials are provisioned at create time) — create a new device instead.

When a push goes wrong, you'll see it

Previously a rejected webhook told only the device that sent it. Failed pushes now raise a warning on the Events page:

• Ingest Auth Failed — wrong or missing secret (usually a rotation the device never got).
• Ingest Bad Payload — the body didn't match an accepted shape.
• Ingest Unknown Tag — the push was accepted, but a key matched none of the device's tags. This one is easy to miss: a typo is still a 202, and the reading is filed under a name no dashboard is bound to. The response now names the unrecognised keys, too.

Each is recorded at most once a minute per device, so a device retrying in a loop won't bury your event log.

Fixed

• The Events page could show a live event with no device, detail or timestamp, and colour an offline device blue. It now shows the device name rather than its raw id, and the device filter works.
• A malformed JSON body sent to the ingest endpoint returned 500; it now correctly returns 400.

Webhook ingest is a paid-plan feature, enabled per account. Full setup steps, payload shapes and curl examples are in the Help Center.

Dashboards can now show a full process mimic — a SCADA-style schematic where your equipment, pipes and instruments come alive with real-time data.

New — Schematic widget

• Mimic canvas. Add the new Schematic (P&ID mimic) widget, then drop pumps, valves, tanks, motors, gauges, readouts and status lights onto a free-form canvas.
• Animated pipes. Connect symbols by dragging from one connection point to another. Pipes animate flow — speeding up as a value rises, or switching on/off — so you can see your process move.
• Bind anything to anything. Each symbol binds to its own device and tag (across different devices on one screen). Gauges sweep, tanks fill, pumps show running/stopped — all from live telemetry.
• Full editor. A drag-and-drop editor with a symbol palette, move/resize/rotate, layer order, grid snapping, pan/zoom and per-symbol data binding. It saves with your dashboard automatically.

Reuses the analog/SCADA widget library, so every gauge, tank and indicator you already know is available as a placeable symbol.

The Schematic widget and the analog/SCADA widget library are a premium feature — available on plans that include premium widgets. Dashboards you've already built keep working regardless.

Dashboards get a big new set of realistic, industrial-style widgets — gauges, switches, fans, tanks, meters and more — so your dashboards can look and feel like a real control panel. All of them bind to your device tags the same way as the existing widgets, in light and dark mode.

Added — analog & SCADA display widgets

• Needle gauge — a classic dial with a sweeping needle and coloured red/amber/green zones.
• Level meter / thermometer — a vertical bar (or thermometer) with a coloured scale and tick marks.
• Fan / motor — a fan that spins faster with the reading (RPM), or simply runs/stops.
• Equipment (SCADA) — a pump, valve, motor or compressor symbol driven by device state, with running animation and a fault flash.
• Nixie tube & seven-segment — retro glowing numeric displays.
• Direction dial — a compass for wind direction or heading.
• Battery — a charge-level indicator with an optional charging animation.
• LED bargraph — a segmented VU-style bar coloured by zone.
• Flow / pipe — a pipe segment with animated flow.
• Stack light — an andon tower lamp lit by device state.
• Status matrix — a grid of state cells for watching many tags at once.
• Motorized valve — shows a valve's % open position.

Added — realistic control widgets

• Rocker switch — an industrial bat-handle / rocker toggle (writes a Modbus coil/register or fires an action).
• Illuminated button — a lit momentary, latching, or emergency-stop push-button.
• Rotary knob — turn to set a value; writes the register when you release.
• Selector switch — a multi-position rotary selector (e.g. Off / Manual / Auto), each position writing its own value.
• Fan speed — an Off / Low / Med / High fan control with a live fan.

Add any of them from the + Add widget picker while editing a dashboard. See the read-only widget catalog and interactive widgets for details.

Refer a friend and your reward is more flexible. Previously, referring someone who subscribed only ever extended your plan by a fixed number of days. Now your referrer reward can also be a discount code for money off your own next plan.

Changed — referral rewards

• Discount rewards for referrers. When you refer someone who subscribes to a paid plan, your reward can now be a percentage or fixed-amount discount code (in addition to the existing "extra plan days" option).
• Rewards Earned list. Any discount codes you earn now show up under Settings → Referrals → Rewards Earned, each with a copy button and a "used" badge once redeemed. You're also emailed the code when you earn it.
• Extra-plan-days rewards are unchanged — they still apply to your plan automatically with nothing to do.

This release makes it easier to get real-world values out of Modbus and other raw sensors — especially when your device's datasheet gives a scale factor to divide by.

Added

• Divide as well as multiply when scaling a tag. Device tags now have a Multiply / Divide switch. If your Modbus (or other) datasheet lists a scale factor to divide by — for example, "the register stores the value ×10" — just choose Divide and type 10 exactly as the datasheet lists it. No more converting it to 0.1 in your head. A live example under the inputs always shows how your numbers are applied (e.g. raw ÷ 10 + 0).

Improved

• Change a tag's scaling without deleting and re-adding it. Open a device's Edit form and use Edit scaling on any saved tag to adjust its factor, direction, or offset in place — the same way you can already edit alert thresholds. For gateway-connected devices the new scaling is sent to the gateway automatically.
• Existing tags are unchanged: anything set up before this release keeps working exactly as it did, in Multiply mode.

This release focuses on fixing the things you told us about — data accuracy, device management, and general polish.

Fixed

• Sensor readings now show the correct values. Readings from polled sensors could appear mis-scaled on dashboards and history charts. Scaling is now applied correctly everywhere.
• RS-485 parity setting is back. The parity field had disappeared from the device form; it's restored.
• Gateway USB console reconnects cleanly. Returning to the provisioning page no longer fails with "port already open" — reconnecting just works.
• Deleting devices and gateways now cleans up everything. Removing a device also removes its parameters, rules, history, and dashboard references. Deleting a gateway that still has devices attached now warns you first.
• Dashboards no longer silently miss parameters. A naming mismatch could cause some parameters to never appear as dashboard data sources; they now show up reliably.
• Storage usage is measured accurately. Fixed an accounting issue in storage-quota tracking.

Improved

• Telemetry history is now kept for 365 days (up from the previous retention window).
• Dark mode everywhere. Sign-in and help pages now follow your operating system's dark-mode setting.
• Security hardening across the platform, plus better internal error monitoring so we can catch issues before you notice them.