Changelog

If you work in someone else's Synacl account as a team member, signing in now takes you straight to that team. Owners get a new way to limit what each member sees, and a few permissions have been tightened. If you're the only person in your account, nothing changes for you.

Changed — team members land in their team

Signing in opens the workspace you used last — or, the first time, the team you joined most recently — instead of your own empty account. (If you have devices of your own, you still start in your own account; switch to the team when you need it.) The team's name shows in the top bar. If you belong to more than one workspace, a new workspace switcher in the profile menu (top right) moves between My account and each team without signing you out; it only appears when there is something to switch to.

Two things that silently didn't work for members now do: live data (charts updating in real time) streams for team members on the web (the mobile app catches up in its next update), and a member's rule and macro limits come from the team's plan rather than their own account's.

On the mobile app, members land in their team too. The app has no switcher yet: pick the workspace on the web, then sign in again on the phone and it opens the one you chose last.

New — Device access: limit a member to some devices (rolling out)

An Owner, or a member with Manage members, can open Team → a member → Device access and choose All devices (the default) or Selected: pick gateways (a gateway includes its sub-gateways and every device on them) and individual devices. A restricted member then sees and acts on only those — device and gateway lists, device pages and charts, live data, events, alarms, rules, macros, jobs, fleet views, uptime, reports (and only the saved reports and schedules they created) and push notifications. Anything outside their access simply isn't there. Devices or gateways they create are added to their access automatically, and a change takes effect immediately. A restricted member can't invite people, change roles or access, or change account-wide settings such as data forwarding and actions. Owners are never restricted.

This is being switched on account by account — if your account has it, you'll see Device access on the Team page. See team members and roles.

Changed — permissions

• New: View data forwarding and Manage data forwarding. Until now any member could change where your data is forwarded. The Admin preset has both, Viewers can view (credentials hidden), Operators have neither. Custom roles can grant either — see custom roles.
• Any permission includes viewing. Edit devices now includes View devices, and so on, so existing custom roles keep working. Pages check view permissions too: a role without View rules can't open Rules.
• Flashing gateway firmware from the browser needs Provision gateways.
• Billing for members. Members with View billing (Admins and Viewers) can see the team's plan, orders and invoices. Only the Owner can change the plan, pay, or manage payment methods.

Two things customers with many stations have asked for: a way to get the data out, and charts that show when a reading happened. Both are rolling out account by account — if you don't see them yet and want them, contact support.

New — Reports

A new Reports page builds a report over any range of your stations and tags and downloads it as CSV, Excel or PDF. Two kinds: a telemetry trend (readings over time, charted per unit, with the average, minimum, maximum and the distribution per tag) and data completeness (which stations and tags reported, how completely, when each was last seen, and the tags that have never reported). The preview updates live as you change the question; Table view lists every station and tag per interval and exports every row.

• Building, running and exporting work on every plan, within your plan's history retention — a longer range is shortened and the report says so.
• Saved reports and scheduled email delivery (daily, weekly or monthly, at a local time, to you and your team members) need a paid plan. Every delivery is kept as a frozen record of exactly what was sent.
• Owners and admins can save and schedule; operators can build, run and export; viewers can build and run on screen.

New — The line chart plots on a time axis

The dashboard line chart now draws the dashboard's time range on a real time axis: the stored history for the range, with live readings appended where they were measured. Gaps show as gaps instead of being squeezed shut, on/off tags draw as steps, and a new Show the tags' alarm limits option draws dashed lines at each alarm (red) and Watch (amber) limit. Changing the dashboard's time range now refreshes these charts in place. The chart tells you when the plan shortened the range, when a plan keeps no history, and when nothing has arrived for 30 seconds.

Fixed — Aggregated widgets

Every widget with an aggregation set on its data source changes in this release, for every account:

• Average works. avg was silently treated as no aggregation, so a widget set to "average over 5 minutes" showed raw readings (and a bucketed source with avg never updated at all).
• Interval units are read correctly. 5m is five minutes — it was being read as 5 milliseconds.
• Refresh every 10 seconds or less. An aggregated widget now refreshes every interval or every 10 s, whichever is shorter, instead of once per interval; a 5-minute average no longer waits five minutes to update. When a device goes quiet, the window drains and the widget shows no recent data instead of a frozen number.
• Sums and counts are scaled correctly. A sum no longer has the tag's offset added; a count is no longer multiplied by the scale factor.

Also in this release

• Reports print local dates. Dates in exported reports, scheduled emails and on screen are in the report's timezone — a daily report sent at 07:00 covers yesterday, not a UTC day that straddles two of yours. Partner reports too.
• Partner reports scale every device with its own calibration. Two stations with different scale factors were both scaled with the first one's.
• The Jobs page now explains when jobs are not part of your plan instead of showing a generic error.

A monitor's response-time chart over 90 days now covers the whole window. A monitor that probes every minute records about 130,000 response times in 90 days, more than a single history request returns, so the chart quietly showed only the most recent five weeks or so. Windows longer than 30 days are now drawn from the average of each time slot across the full period; the 7- and 30-day views still show every reading.

Also in this release

• History requests have sensible limits. A history window can span at most 400 days, longer than readings are kept, and a request for more is refused with a clear message instead of failing.
• AI assistants get the bucket they actually got. get_telemetry returns at most 2,000 buckets. A bucket too fine for the window, for example 1 second over a day, is widened, and the answer says which bucket was used and why.
• Faster, steadier pages under load. Every list and history read now has a hard ceiling on how many rows it returns and how long it may run, so one heavy request can no longer slow the platform down for everyone else.

The history chart on a device page now loads in well under a second at every period, however often the device reports. It used to fetch every single reading of every tag — for a device reporting every 10 seconds that is about 60,000 readings a day, which made the 7- and 30-day views take several seconds. The chart is now drawn from one point per tag per time slot (5 minutes at 1 day, 30 minutes at 7 days, 2 hours at 30 days): the average of the slot for a measurement, and for an on/off tag whether it was on at any moment in the slot, so a brief pump run or alarm contact still shows. The Records table and dashboard widgets are unchanged.

If you run many stations that carry the same tags — a network of water-quality sites, a fleet of pumping stations — you can now see all of them on one dashboard and drill into any one of them without building a dashboard per station. Two new widgets, a station picker, and a fleet summary for AI agents. See Fleet views.

New: Fleet KPI widget

One number across every station that carries a tag type — the average Nitrate over the whole network, the lowest Dissolved Oxygen and which station has it, how many stations have pH in range. Pick the Tag subtype, the Statistic (average, minimum, maximum, in range, or the number of stations in Alert, on Watch or offline) and optionally one Gateway to count only the stations behind it. The tile shows 6.4 mg/L avg with a line of counts underneath — 174 / 176 in range · 1 watch · 1 alert · 2 offline — and turns amber when any station is on Watch, red when any is in Alert. A mixed units chip warns when stations disagree about the tag's unit. Under Add Widget → KPIs & Counters.

New: Station List widget

Every station in a table: one row per station, one column per tag type you choose, Last seen at the end. Cells are coloured by that tag's level, and hovering one shows the limit in words (Alarms below 4 mg/L · Watch below 5 mg/L). Sort by level puts Alert first, then Watch, then offline stations — greyed, with last seen 12 min ago — then the rest; or show only the stations in Alert, on Watch or offline. Clicking a row opens that station in a drill-down dashboard of your choice, or on its device page. Under Add Widget → Comparisons.

New: dashboard variables and the station picker

Dashboard Settings → Variables → Add station variable creates a variable such as station, optionally limited to devices carrying a tag type or behind a gateway, with a default device. On a widget's Data tab choose ${station} — Station (station variable) instead of a fixed device — computed widgets' device fields take it too — and the toolbar gets a searchable station picker that re-points every bound widget at once. The pick lives in the page address (?var-station=<device id>), so a link opens on a station, and choosing one never edits the dashboard. Paired with the Station List's Row click opens, an overview dashboard drills into a per-station detail dashboard with one click — the alternative to duplicating a dashboard per station.

How the fleet numbers are computed

Each station contributes its latest reading within the last hour, in engineering units (after scale factor and offset) — not stored history, so fleet views work on plans that don't store telemetry. An offline station is counted as offline and never averaged; a station that is online but hasn't sent that tag in the last hour counts as no data. In range is the stations whose tag is Normal out of those whose tag has a limit — a tag with no limits shows the statistic but no in-range count. With cloud alarms on, the levels are exactly the ones on the Active alarms page, hysteresis included; without them, the latest reading is compared directly against the tag's limits. Both widgets refresh on their interval and within a couple of seconds of any level change.

New for AI agents: get_fleet_summary

A connected AI agent can ask how the fleet is doing right now: the same figures as the Fleet KPI, per tag type, plus the stations that need attention — Alert first, then Watch, then offline. Agents can also build dashboards with a station variable ("deviceId": "${station}").

Fixed: agents now get telemetry in engineering units

get_telemetry and get_latest_values returned the raw stored number labelled with the tag's unit — a tag stored ×10 read 60 mg/L for 6.0. Both now return values in the tag's engineering units, the same units as its limits and rules; when a tag has a scale factor or offset, the raw value is included alongside.

Also

• Fleet views are rolled out account by account. The two fleet widgets and the fleet API also need a plan that includes premium widgets — the same entitlement as the analog / SCADA widgets; on a plan without it they show a 🔒 Pro badge in Add Widget, and a tile already on a dashboard says Fleet views need a paid plan. Station variables and the picker need only the rollout. If your account doesn't have it yet, contact support.
• The mobile app doesn't support dashboard variables yet — a widget bound to a variable shows no data there — and the fleet widgets aren't in the app yet either.

Every tag's alarm limit can now carry an early-warning Watch value, Synacl evaluates limits in the cloud for the devices that have no firmware to do it, and a new Active alarms page lists everything on Watch or in Alert across your account. Cloud alarms are being rolled out account by account and need a plan that includes alert thresholds — if you don't see them yet, contact support. See Normal, Watch and Alert.

New: Watch — an early warning inside the alarm limit

A tag's alarm limit (above, below, outside a range, beyond ±) can carry an optional Watch value in the same mode, sitting strictly inside the limit: Dissolved Oxygen alarm below 4 mg/L, watch below 5; pH alarm outside 6.5–8.5, watch outside 6.8–8.2 (either side optional). Every reading is graded Normal, Watch or Alert. Entering Watch raises a Watch event (severity Warning), entering Alert a Threshold violation (Error), and coming back inside a Threshold cleared — all following your notification preferences and quiet hours as usual. Watch is an early warning, not an alarm: it isn't counted in job reports. There is also an optional hysteresis, in the tag's units: how far back inside the limit a reading must come before it leaves Alert or Watch, so a value hovering on the line stops alarming and clearing over and over. Going up is always immediate.

New: alarms evaluated in the cloud — and a per-device switch

Until now only Synacl's ESP32 firmware compared readings against their limits. Devices polled by Synacl (HTTP, Modbus TCP, SNMP), webhook devices, direct MQTT devices and devices behind any other gateway — a software gateway, a third-party gateway speaking the open protocol — never alarmed at all. Synacl now evaluates their limits in the cloud on every reading, in engineering units after scale and offset, exactly as the ESP32 does. Each device page has an Alarms evaluated setting: On the gateway (the default behind a Synacl ESP32 — it keeps alarming while its uplink is down) or In the cloud (the default for everything else; a device with no gateway is always here). Switching a gateway device moves its limits into or out of the gateway's configuration, so the gateway restarts once; after that, editing a cloud-evaluated device's limits never restarts anything. Changing it needs the Change parameters permission. Behind an ESP32 in gateway mode nothing changes for the alarm itself — the cloud tracks the level for the badges and adds Watch.

New: Active alarms page

Active alarms in the sidebar lists every tag currently on Watch or in Alert across your account — alerts first, then the longest-standing — with its value, its limit in words and since when, updating live. The Devices list and each device page show a Normal / Watch / Alert badge, and the Connectivity summary widget counts Watch and Alert devices under need attention. Needs view access to devices.

New: alarm limits drawn on Progress bar and Level meter

Both widgets have a new option, Show the tag's alarm limits, which draws the alarm and Watch markers on the bar with a caption like Alarms below 4 mg/L · Watch below 5 mg/L. The markers follow the limit set on the tag, so there is nothing to retype in the widget when it changes.

New: duplicate a dashboard

Duplicate on the dashboard list copies the layout, widgets, variables and settings as (copy). The copy counts toward your plan's dashboard limit, and its widgets keep pointing at the same devices — open the copy and re-point them, which makes one dashboard per site or station a two-minute job. See creating, editing and deleting dashboards.

Changed: water-quality parameters come with units, plus Nitrate, COD, BOD and Water Level

Water Quality parameters now carry their unit — Turbidity NTU; Dissolved Oxygen, TDS and Chlorine mg/L; Conductivity µS/cm; ORP mV; Salinity ppt — and gain Nitrate, COD and BOD (mg/L). A new Water Level category has Level and Depth (m). When you add a tag, the unit is prefilled from the parameter and can be edited. See device parameters.

New: AI agents can set limits and duplicate dashboards

A connected AI agent gets set_tag_limits — the limit, Watch value and hysteresis on several tags of a device in one call, with a note on whether the gateway will restart — and clone_dashboard. Device reads now include the current alarm level and where the device's alarms are evaluated.

Also

• A device that is offline or unreachable isn't graded, so it drops off Active alarms until it reports again; its status dot still says why.
• Tags of a cloud-evaluated device no longer take up room in the gateway's configuration.
• Readings a gateway buffered while offline are replayed without raising alarms, as before.

A team member can no longer get around their role — through a role change, a rule, a macro trigger, an AI app or a secret on screen — and signing out now means signed out. Members on limited roles are the people who will notice a difference; if you're the Owner or the only person in your account, the one new thing for you is Sign out of all devices under Settings → Security.

Changed: roles can't be used to climb

Managing the team now stays within your own role. Whoever invites or manages members can only invite people into, or move people into, a role whose permissions they hold themselves; roles above your own aren't offered. Nobody can change their own role — another admin or the Owner does that. You can't change or remove a member who holds a permission you don't, and custom roles can be created, edited or deleted only within your own permissions (editing the role you hold yourself can only narrow it). The Owner is never limited. See team members and roles.

New: Team → Agent access

Anyone who can manage members now sees every API token and connected AI app held by anyone in the workspace, and can revoke any of them without waiting for that member to do it. Removing a member revokes their tokens and connected apps in your workspace automatically; what they hold for their own account is untouched.

Changed: an AI app can only be granted what you hold

When you connect an AI app, the consent screen offers only the permissions your own role includes; anything else it asked for lands in the "not granted" list. If your role is narrowed later, the app's access is trimmed to match.

Changed: turning on a macro's automation needs "Run macros"

Scheduling a macro, adding an event trigger, allowing an AI agent to run it, switching a macro on, or changing the steps of a macro that already runs on its own (on a schedule, a trigger or from a rule) now all need the Run macros permission — the one that can move physical equipment. Anyone who can edit a macro can still switch it off or remove its schedule. Two more things: changing a macro's steps withdraws "Let an AI agent run this macro" until someone with Run macros reads the new sequence and allows it again, and an AI agent can't change the steps of a macro that runs automatically — do that in the app. A macro step that calls a saved action needs Trigger actions. See macros.

Changed: a rule can only do what you could do yourself

Creating, editing or switching on a rule now needs the permission for each action it takes: a device command needs Command devices, running a macro Run macros, a saved action Trigger actions, starting or ending a job Start/end jobs. Notifications (in-app, email, push), webhooks and MQTT need nothing extra. Anyone with Toggle rules can always switch a rule off. An AI agent can only switch on rules that do nothing but notify. See create an alerting rule.

Changed: secrets are shown only to people who can edit

Team members who can only view no longer see gateway MQTT passwords, device webhook secrets (they see that one is set, and its fingerprint), access keys, SNMP community strings, broker logins, auth headers, or the secrets and headers on webhook actions in rules and saved actions. Gateway passwords are no longer sent with the gateway list at all: open a gateway → Connection Info → Show password (needs Edit gateways; each reveal is recorded, and limited to 20 an hour).

New: rotate a software gateway's password

Connection Info → Rotate password on a software gateway issues a new password on the spot. The gateway disconnects until you give it the new one — for the reference gateway, re-run npx synacl-gateway init … --pass <new password> and restart it. ESP32 gateways get new credentials only by being re-provisioned over USB.

Changed: signing out ends the session — and you can end all of them

Sign out now ends that session on the server, so the sign-in it came from can't be reused. New under Settings → Security: Sign out of all devices ends every session of your account, including the one you're on. Resetting your password also signs you out everywhere. A page that is already open may keep working for up to about 10 minutes before it notices. See changing or resetting your password.

Fixed

• Re-inviting someone who had been removed from the team failed; it works again.

Also

• On the API & Agents page, workspace-wide usage totals are shown only to people who manage the team; everyone else sees the usage of their own tokens and apps.
• Live gateway logs and remote diagnostics need the Debug gateways permission.

A maintenance release that tightens a few edges of the platform. Nothing changes for most accounts; the places you might notice are listed first.

Fixed: HTTP Poll and MQTT Topic widgets now show live values

Widgets using the HTTP Poll or MQTT Topic data source stayed blank: Synacl fetched the value but it never reached the dashboard. Each value now goes straight to the dashboard that asked for it and updates live while the dashboard is open, within the limits below.

Changed: stated limits on the HTTP Poll and MQTT Topic widget sources

These are the two dashboard data sources that Synacl fetches on your behalf while a dashboard is open. They now work within the same limits as everything else the platform reaches out to:

• HTTP Poll — the URL must be reachable from the internet. Addresses on a private or internal network (192.168.x.x, 10.x.x.x, localhost, and hostnames that resolve to them) are refused, as they already are for webhooks and uptime monitors. A response larger than 64 KB is discarded. One browser tab polls at most 10 distinct URLs at a time.
• MQTT Topic — the topic must be one of your own account's topics (it always had to start with tenants/<your id>/), and wildcards (+, #) are not accepted — readings are matched to the exact topic, so a wildcard could never match one.

A widget whose source is refused shows no value; the rest of the dashboard is unaffected. Widgets bound to a device tag — which is how nearly every dashboard is built — are untouched. Details in widget data sources explained.

Fixed: a widget on a device's own data topic no longer counts that device twice

Pointing an MQTT Topic widget at one of your devices' data topics made Synacl handle every message from that device a second time: it counted twice against your plan's publish rate, which on a busy account was enough to suspend the device. Each message now counts once.

Changed: a session follows the account behind it

Signing in and out is unchanged, and nobody is signed out by this release. What changes is what a session that is already open may keep doing:

• A removed team member leaves that workspace the next time their session refreshes — within minutes — and lands in their own account.
• A suspended, banned or closed account can no longer keep a session alive: an open session ends at its next refresh, within minutes.
• Staff sessions end when the staff role is removed.

Fixed: account profiles are private

Your profile and fleet summary — name, email, plan, device and gateway counts — can be seen only by you, your team, and Synacl staff.

Fixed: API token activity was going unattributed

Calls made with a personal API token are now attributed to the token that made them. Each token's View activity list and the By agent breakdown under Settings → API & Agents show them; until now they were counted under Other credentials on this account. Connected apps were attributed correctly all along.

Notes

• Nothing to do on your side. If a dashboard has an HTTP Poll widget pointed at an address inside your own network, either publish that endpoint on a public address or read it through a gateway on that network as an HTTP-polled device — which also gives it history and rules.

If two devices trip the same rule, you now get two alerts. If a gateway goes down with twenty devices behind it, you get one. And if you share your account with a team, their phones now buzz too.

Fixed: a rule that watches every device no longer goes quiet after the first one

A rule with no device chosen — any device goes offline, any temperature above 40 °C — had a single cooldown shared by every device. The first device to trip it silenced every other device for the whole cooldown window, so the second and third going down produced no alert at all. Each device now has its own cooldown: two devices breaching → two alerts; the same device again inside its window → still one. Rules scoped to a single device behave exactly as before. One thing to keep an eye on: a rule watching many devices now sends one alert per device that breaches, so email, webhook and push actions count against your plan's monthly action allowance per device — give noisy fleet-wide rules a longer cooldown.

Changed: a gateway outage is one alert, not one per device

When a gateway disconnects, the devices behind it (and any sub-gateway that forwards through it) are marked offline with it. A rule on a device goes offline, a gateway goes offline, or both now sends one alert for that outage, and your phone gets one Gateway offline push instead of one per device. A device that drops on its own while its gateway is up still alerts on its own.

Fixed: team members now get push notifications

A team member's phone never received the workspace's alerts. Every active member's phone now gets them. Each person's Settings → Notifications — on/off, minimum severity, quiet hours (critical still comes through) — apply to their own phone only, and removing someone from the team stops their notifications. Nothing to do on the phone: one that was already signed in picks this up on its own within a few hours of use, and opening the app brings that forward.

Fixed: dashboards with an absolute date range

Setting a dashboard's time range to Absolute — say 1–7 January — couldn't be saved: the dashboard refused the save as an invalid configuration, and until you reloaded, the charts showed the same number of days counting back from today. Absolute ranges now save, and show exactly the dates you picked — with no live readings tacked on after a range that has already ended.

Also

• The Connectivity Summary widget shows devices online out of your device total, as it already did for gateways; the total was missing before.
• Plans with unlimited team seats can invite members again — every invite was refused on those plans.

• Fixed: after we shipped an update, clicking to another page could do nothing until you reloaded. A tab left open across an update was still running the previous version, whose files are gone once the new one is live. Now the page you clicked opens, loaded fresh on the new version. If your connection has dropped instead, a message says so rather than nothing happening.
• New: a notice when a new version is out. A pop-up says a new version is available. It loads by itself the next time you open a page, or click the notice to reload straight away. Close it with × to carry on where you are.
• Applies to the Synacl app, the admin console and the partner portal.

You no longer need an ESP32 to have a gateway. synacl-gateway, the open-source reference gateway, is published on npm: a Raspberry Pi, a mini PC next to your panel, a server or a container can now be a Synacl gateway.

New — the reference gateway (synacl-gateway 0.1.0)

• One line to try it. Register a Software gateway under Gateways → Add gateway and paste the Quick start (Node.js) line from its Connection Info into a terminal. npx fetches the gateway, init saves and checks the settings, run connects — the gateway is online in seconds.
• Keep it running. npm i -g synacl-gateway and sudo synacl-gateway service install register a systemd service that starts at boot and restarts on failure. A Docker image, ghcr.io/synacl-iot/synacl-gateway (amd64 and arm64), does the same for containers.
• Two new device types, offered once your software gateway is online:
  • Host metrics — CPU temperature and load, memory, disk, uptime and network throughput of the machine the gateway runs on, as ordinary tags with history, dashboards and rules. A metric the machine can't provide is left out, never reported as 0.
  • Local MQTT bridge — subscribe to topics on a broker you already have (Tasmota, zigbee2mqtt, Home Assistant, a PLC) and map a field of each payload to a tag. ON/OFF and true/false become 1/0. One-way in this release.
• Modbus TCP from a software gateway. PLCs, meters and TCP-to-RTU bridges on the LAN can now be polled by a software gateway with the same register type, address, format (u16 … f32) and word-order fields as on an ESP32 — 32-bit formats included — plus single coil and holding-register writes.
• Works through outages. Readings taken while the connection is down are kept on disk and replayed afterwards, and alert thresholds are evaluated on the gateway itself — both exactly as on the ESP32 firmware.
• Device changes arrive on their own. Adding, editing or removing a device under a software gateway pushes the new configuration to it immediately; there is no Resend config step.
• status, doctor and metrics. synacl-gateway status shows what the gateway is doing (also when it is stopped); doctor checks the machine, the broker and — after signing in — what the platform sees; metrics previews what this host can report.

Open source, with a conformance suite

synacl-gateway is Apache-2.0 on GitHub and one implementation of the public gateway protocol. If you extend it with a driver of your own, synacl-gateway conformance --driver <package> checks the driver against the contract; conformance --offline runs the 23-scenario protocol suite, which doubles as a checklist for a gateway written in any language.

Setup, Raspberry Pi notes and troubleshooting: connect your own gateway. Device articles: host metrics, local MQTT bridge, Modbus TCP.

• Fixed: after a successful sign-up, every field turned red as if something had gone wrong. The form now gives way to the "check your email" message.
• Sign-up errors say what is wrong — for example "Email address already registered." instead of "validation error.", and passwords shorter than 5 characters are caught before you submit.
• One click is one sign-up. The Register button waits while your account is created.

• New: one LED indicator, many LEDs. Tick several tags on the LED indicator's Data tab for one LED per tag — a panel of digital inputs, for example — and give each its own name under LED labels. With one tag it looks exactly as before.
• New: Last Updated widget. Shows when a device last sent data, as a date and time in coloured digits, and turns amber once it goes stale — so a dashboard can say how current it is when a gateway is offline.
• Fixed: a gateway could show as offline while its devices kept sending data, until you reloaded the page. It happened when the connection dropped while the gateway reconnected (a sleeping laptop, a network blip, an update on our side), or when a gateway reconnected very quickly. The app now re-checks gateway status after every reconnection and shortly after any gateway goes offline, and opening Gateways always shows the current status.
• Fixed: after signing in, live updates did not arrive until you reloaded the page — no online/offline pop-ups, and gateways shown as offline. Signing in now starts them straight away.
• Fixed: a tag you had just added did not appear in a widget's tag list until you reloaded the whole page. The dashboard now picks up new tags, and changed scale factors, every time you open it, open a widget's settings, or browse tags in Add Widget.
• Fixed: offline alerts said "Device went offline went offline". Online and offline pop-ups now name the device, and every event about a device or gateway carries its name.
• Fixed: some warnings never reached your Events list. The account-wide rate-limit warning (quota/tenant-rate-limited), the many-devices-at-once warning (quota/tenant-burst) and firmware update requests (firmware/update/requested) were raised but never saved. They now appear like any other event.

• Fixed: the device page's live chart drew most tags one reading late. Each reading now appears as one step, with every tag together. Before, only the device's first tag was current; the others showed the previous reading until the next one arrived, and on a device whose first tag never reports the chart did not move at all. The readings themselves were always recorded correctly — only the chart lagged.
• Fixed: the device page's records table showed timestamps with empty cells for any tag created with its own name rather than a standard measurement type — and its column headings were blank. The values were stored all along; the table now shows them, headed by the tag's name and unit.
• The top chart's unit no longer sits under the legend.
• Hiding tags in the chart legend frees their space. When every tag in a panel is switched off, the panel folds away and the rest move up; click the tag in the legend to bring it back. A hidden tag also stays hidden now — on the live chart it used to reappear with the next reading.
• A tag missing from one reading no longer breaks the line, for example when you press Read now on a single tag.
• What's new and the changelog now list two releases from the same day in the right order.

• Fixed: JSON path, CAN ID and M-Bus record now save. Since late May, the JSON path of an HTTP or local-MQTT-bridge tag, the CAN ID of a CAN tag and the record number of an M-Bus tag were dropped when a device was saved from the device form, so those tags read the wrong value or nothing. They are saved now. If you set one of these up since May, open the device, re-enter the value and save. A JSON path written with brackets — sensors[0].temp, as the form's hint used to suggest — now works too; sensors.0.temp is the same path.
• Software gateways pick up device changes by themselves. Adding, editing or removing a device on a software gateway now sends it the new configuration straight away — there is no Resend config step. ESP32 gateways are unchanged: a config push restarts them, so you still choose when.
• Fleet views no longer offer firmware updates to software gateways. A software gateway updates by upgrading the program it runs, not by OTA.
• Tighter access checks across device and gateway management.

• Bring your own gateway. A gateway no longer has to be an ESP32 running our firmware. Gateways → Add gateway → Software gateway registers a gateway you built yourself — a Raspberry Pi, a Linux box, a PLC, a container — and gives it credentials. Add devices under it exactly as under an ESP32. Connect your own gateway
• Connection Info shows the topic prefix. A gateway's Connection Info now shows its full MQTT topic prefix, tenants/{tenantId}/sources/gateway/{id}, beside the broker address and username, so a gateway you write knows where to publish without reading the firmware.
• The contract is published at synacl.com/protocol. Every topic, every message as a JSON Schema with a valid example, the connection lifecycle, config delivery and hashing, commands and acknowledgements, store-and-forward, what happens to an invalid message, the rate limits, and the reference firmware's quirks, stated plainly. Machine-readable at /protocol/v1/index.json. Version 1 is frozen; additions will be announced here. The gateway protocol
• Coming soon: npx synacl-gateway, an Apache-2.0 reference gateway in Node.js with host-metrics, local-MQTT-bridge and Modbus TCP drivers.
• Fixes. A gateway registered and flashed by a team member was provisioned with the member's own id as its tenant, while its broker permissions were issued for the account owner's — so the broker refused every message it sent and it never came online. It is now provisioned with the owner's id. Also: a gateway's actions (restart, reset, resend config, firmware, network) are now strictly scoped to the account that owns it.

• A gateway can now read several I²C sensors. Adding a second I²C device to a gateway used to fail with a pin conflict, because every I²C sensor uses the same SDA/SCL pins. Sensors on the same bus are now told apart by their address, so a BH1750 and a BME280 can share one gateway. Connect an I²C device
• Clear errors for the two setups that can't work. Pins that differ from the bus's pins are refused with I2C_BUS_MISMATCH, which names the right pins. An address already taken on the bus is refused with I2C_ADDRESS_IN_USE. A second I²C device now starts with the bus's pins already filled in.

Two things that go together: the gateway can now read the 32-bit and signed Modbus values most real meters use, and there is a catalog of known meters and sensors so you no longer have to type their register maps in by hand.

New — Start from a catalog device

• Pick the hardware, not the registers. In Add device, choose Start from a catalog device and the protocol, connection defaults and every tag — address, format, scaling, unit — are filled in. You still pick the gateway and can change anything before saving. Add a device from the catalog
• Nine entries to begin with: Eastron SDM120, SDM230 and SDM630 energy meters, the Peacefair PZEM-004T v3, the XY-MD02 RS-485 temperature/humidity transmitter, and the BH1750, BME280, SHT31 and DS18B20 sensors.
• Honest about verification. Each entry says whether it was read on real hardware (bench) or built from the vendor's document (datasheet). Only the BH1750 is bench-verified today; every entry's page has a Report a mismatch link so a wrong register can be fixed and the entry promoted.
• Public pages. Every entry has a page under synacl.com/devices/ with the wiring, the notes that matter for that model, and the register table — useful even if you enter the device by hand.
• For AI assistants. A connected agent can list the catalog and create a device from an entry by name. As before, creating a device moves nothing.

New — Modbus data formats on tags

• Each RS-485 / Modbus TCP tag has a Format: u16 (the default, unchanged), s16, u32, s32 or f32, plus a Word order for the 32-bit ones. The gateway reads two registers where needed and decodes them, so an SDM meter's float voltage or a PZEM's 32-bit energy counter comes through as the number it is, not as half of it. Modbus data formats
• Existing tags are untouched — nothing changes on a gateway until you set a format on a tag.
• Any format other than u16 needs the gateway firmware that ships with this release. On an older gateway the form warns you and the save is refused with a clear message rather than silently reading garbage; update the gateway from its page and try again.

• A reading that arrives late isn't treated as too fast. When the network delays one reading past the next one, the older reading used to count as a publishing-rate violation, and enough of those could suspend a healthy device. It's now skipped with no violation. How rate limits work
• Online and offline events are recorded once. When a gateway reported a device's data and status at the same moment, the device's came online or went offline event was sometimes recorded twice. That doubled entries in the event list and could send the same notification twice.

Gateway firmware 1.5.3

Gateway firmware 1.5.3 is the new stable release. A gateway on an older version shows an Update firmware button on its card. The update runs over the air and keeps your Wi-Fi and cloud settings.

• A misbehaving device no longer gets the others suspended. When a gateway fell behind, for example because a Modbus device stopped answering, it could send several devices' readings in one burst. Each of those devices then looked like it was publishing too fast, and enough of that got a perfectly healthy device suspended for an hour. Now a reading that would go out right behind the previous one is held briefly and sent with its real timestamp instead. What happens when the gateway falls behind
• A Modbus device that stops answering is given up on sooner. After two timeouts in a row the gateway skips that device's remaining tags until the next poll, so it doesn't hold up everything else on the bus.
• No more 15-second wait at boot on boards without Ethernet. A plain ESP32 board with no Ethernet chip was detected as having one and waited 15 seconds for a network address on every start-up before falling back to Wi-Fi. It now goes straight to Wi-Fi.

Readings that arrive in a burst after a network hiccup are also treated fairly on our side, even on older firmware. If each reading's own timestamp shows it was taken at the right spacing, it counts as on time. How rate limits work

Gateway events and uptime

A gateway's page now lists its online and offline events. They were recorded under a different ID, so the page never showed them. The same fix means:

• gateway uptime history now records up and down time from those events, going forward
• automation rules scoped to a gateway's online or offline events now fire

Also

• Refreshing, or opening a link to, Macros, Jobs, Monitors or Team no longer sends you to Dashboards. Macros and Jobs also appear in the menu straight after you sign in, instead of after a refresh.
• Changing a widget's data source now streams the new tag straight away instead of after a page refresh.
• A Modbus TCP device polled directly, without a gateway, can be edited and saved again.
• Setting a device's reading interval faster than your plan allows is now refused with a message saying what the limit is. Before, it saved, and the extra readings were quietly dropped.
• Add gateway no longer asks for "this server's LAN IP". The broker details come filled in for you.
• Referral rewards and sign-up referral codes are created reliably. After the first one, some were silently not being created.

Controls write to the tag they show

The rocker switch, illuminated button, selector, fan-speed selector, rotary knob and slider now work like the toggle. Bind one to a tag and it writes to that tag: the device, address and function code come from the tag itself. Before, each of them silently did nothing unless you typed in an internal device ID and an address by hand. The old fields are still there as optional overrides, labelled as such. A control bound to something it can't write, such as an input register, or a coil for a slider, now says so instead of doing nothing.

• Momentary buttons always release. Letting go of an illuminated button while the gateway was still confirming the press could leave the output on. The release is now always sent.

Device charts with very different values

A device reporting, say, a baud rate of 9600 next to an on/off tag drew both on one scale, so the on/off tag was a flat line you couldn't read. The device page chart now:

• puts tags with the same unit on a shared panel and gives the others a panel each,
• draws on/off tags as a strip under the panels, shaded while ON,
• keeps one time axis and one tooltip across all of them.

We deliberately didn't add a second y-axis. Two scales on one plot make unrelated lines look connected. How tags appear on the chart

Also

• The promo section on the ESP32 serial monitor, ESP32 chip info and Modbus RTU tester pages no longer wraps one word per line.

Gateway firmware 1.5.2 is the new stable release. If a gateway is on an older version, its card shows an Update firmware button. The update runs over the air and keeps your Wi-Fi and cloud settings.

Live logs, now worth opening

Open Live Logs on a gateway's page to watch what it's doing without a USB cable. Until now it showed little more than "started" and "stopped", because almost everything the gateway logs only went to its USB port. With 1.5.2 it streams the useful parts, and you choose what you see:

• Network: Wi-Fi, Ethernet and cloud connections dropping and coming back.
• Commands: what the gateway receives, and whether each write worked.
• Modbus: every poll's result, read failures with the reason, and retries.
• Sensors: I²C, SPI, 1-Wire and UART start-up and read errors.
• Macros: each run, step by step.

Pick up to three at a time and change them while the stream is running. The gateway limits itself to about 20 lines a second and tells you if it skipped any. Credentials never appear in the stream. Some categories need a paid plan. How live logs work

Writes are confirmed

When you write to a Modbus device from a toggle, a command button or Write Data, the gateway now reports back whether the device accepted it. The control shows acknowledged or failed instead of sent. A failed write also says why, for example that the device didn't answer.

Also

• The first log line no longer goes missing when you press Start.
• A large burst of log lines could exceed the gateway's message size and be silently lost. They're now split across messages.
• Log lines produced while the gateway was offline are sent once it reconnects, so you can see what happened during the outage.

If you tried to write to an RS485 or Modbus TCP device through a gateway, with a dashboard toggle, a command button or Write Data on the device page, the value never reached the device. The platform sent the command in a form the gateway firmware didn't recognise. The gateway dropped it before it reached the bus and briefly reported the device as unreachable. Macros were not affected. We found it while testing against our new Modbus slave simulator, and it is fixed.

• Writes reach the device. Single coils (function code 05) and single registers (06) are written as expected on the firmware your gateways already run. No update is needed.
• Multi-register writes through a gateway (15 and 16) are refused with a clear message rather than sent. The current firmware can only write one value per command.
• Write Data on the device page lists your writable tags. It was always empty before. It now shows every holding register and coil that has a Modbus address, with that address next to each name. It tells you when a device has nothing writable.
• A toggle writes to the tag it shows. Bind a toggle to a coil or holding register and it works out the device, address and function code itself. The old free-text Device ID field, which wanted Synacl's internal ID rather than the Modbus unit ID, is now an optional override. The address help explains that register 40003 is address 2.
• Controls no longer spin forever. If the gateway doesn't confirm a write within 10 seconds, the toggle, button, slider, knob or selector shows it as sent, and the next reading shows the actual value. A write the gateway reports as failed still shows as failed.
• Live values keep flowing after you switch accounts in the same browser tab, and after a network drop once your session has been open for over an hour. Before, both could leave dashboards and device charts frozen until you reloaded the page.

There's a sixth free tool at synacl.com/tools: a Modbus slave simulator. With Chrome or Edge and a USB-RS485 adapter, your laptop becomes a Modbus RTU slave on a real RS485 bus. Your PLC, HMI, gateway or your own code can poll it and write to it, with no device on the desk.

• An editable register map. Coils, discrete inputs, holding and input registers, shown as 16-bit, signed, hex, binary or 32-bit values in either word order. It supports function codes 01–06, 15 and 16. Rows the master writes are highlighted as the writes arrive.
• Values that move. Set a register to ramp, follow a sine wave, jump randomly or toggle, so your master has something live to read. A sample energy-meter map is loaded to start with.
• Faults on demand. Make it skip a reply, send a bad CRC, answer as the wrong unit, cut a reply short, answer late, or return any exception code. That lets you check how your master copes before a real device does it to you.
• A traffic log of every request and reply, with counters. You can save the register map and load it again later.

It's a Modbus RTU simulator only, on purpose. A web page can't accept incoming network connections, so no browser tool can act as a Modbus TCP slave; the page explains the workaround. Nothing you set up leaves the browser.

We used it on our own bench the day it was built: an ESP32 gateway polling the simulator is how we found the device-write fault fixed in this release.

A new account used to open onto an empty Devices page, and every step of the onboarding checklist waited on a device you might not own yet. Now there is a way in without one.

On an empty Devices page, click Add a simulated device. A Demo Sensor appears and starts reporting temperature, humidity and light within a minute. It is not a canned chart. Its readings travel the same path a real device's do, so it comes online, its history is stored, it appears in Events, and a rule on it fires like any other.

• It lasts an hour, then removes itself. You can remove it sooner with Remove now. Either way, removing it never raises an offline alert.
• It doesn't count towards your device limit, and you can have one at a time.
• It's clearly labelled. A Demo badge and a countdown appear everywhere it shows up. Its connection is locked, so you can't turn it into a real device by editing it.

Use the hour to build a dashboard and set up an alert, then swap in your own hardware. Details: Try Synacl without hardware.

There are now five free tools at synacl.com/tools — Modbus and ESP32 utilities that run entirely in Chrome or Edge, with no account, nothing installed and nothing uploaded.

• Make sense of a Modbus frame. Paste the bytes into the frame decoder and it names the function, the register type, the start address in every notation, says whether the CRC is valid (and what it should be), and lists every way the data could be read side by side. The CRC calculator works the other way: CRC-16/MODBUS for any bytes, plus a builder that assembles a valid request frame.
• Read a real slave. With a USB-RS485 adapter, the Modbus RTU tester reads coils, discrete inputs, holding and input registers straight from the browser, scans the bus for unit IDs, finds the baud rate when you don't know it, and writes a single coil or register after a confirmation.
• See what a board is doing. The serial monitor prints the ESP32 log with the boot messages explained, and ESP32 chip info reports the chip, MAC and flash along with the partition table and which firmware sits in which OTA slot.

Nothing you type or read leaves the browser — the tools talk only to the adapter or board you pick.

A connected AI assistant can now write macros — the step sequences that run on your gateway's own processor — and, if you let it, run one. Describe what the hardware should do in a sentence; the assistant builds the sequence, fixes it when it doesn't compile, and hands it back for you to read.

That closes the loop on the no-toolchain path: flash an ESP32 from the browser, attach your sensors and actuators, then say "pulse the pump relay for two seconds, wait a minute, repeat five times". No firmware, no IDE, no code.

New — macro tools over MCP

• List, read, write and correct macros. The assistant can see what you already have, author a new sequence, and change an existing one. Anything that doesn't compile is refused with the exact step named, so it can fix it rather than guess.
• Run one on demand, when both keys below are turned. The assistant waits for the gateway to confirm the run actually started before telling you anything.
• The plan's macro caps apply exactly as they do in the app, and an assistant's macro is bounded by the same ten-minute gateway ceiling and one-run-per-gateway rule as one you built yourself.

Letting an assistant run one takes two keys, and you hold both

Writing a macro moves nothing. Running one moves real equipment, so it needs two separate things to be true — and no assistant can supply either:

1. The connection has the new "Run macros" permission. It arrives unticked on the approval screen while everything else is pre-selected, and "Select all" in the API-token picker skips it.
2. That specific macro is marked "Let an AI agent run this." A new tick box in the macro editor, off by default on every macro. An assistant can never set it — not on macros it wrote, not on any other.

The second is the one that matters. A permission decides which software may act; it cannot tell you whether a particular sequence is safe to hand over. So we ask you about the sequence, one at a time. An assistant refused this way is told to ask you to review the macro, not to find another route.

What an assistant still cannot do

• Arm a macro to run on its own. Schedules and device-event triggers are set by a person, in the app, whatever permissions the assistant holds. A sequence firing at 3am with nobody in the building stays your decision.
• Send a raw device command, delete anything, or take a macro in or out of service.
• Report a run it didn't see. If the gateway hasn't confirmed the start within a few seconds, the answer you get is unknown — which is the truth.
• Run into a gateway that is away. Runs are not queued; the assistant is told the run was not sent rather than reporting success into nothing.

On safety, plainly

The limits above bound a mistake. They do not make a machine safe, and neither does any permission in Synacl. Abort is a message sent over the network and cannot reach a gateway that is offline — a macro runs on the gateway, which is exactly why it keeps working when the internet doesn't. Synacl is not a safety-rated system.

If a machine can injure someone or destroy something, the protection has to be physical and independent of this platform: a hardwired emergency stop in the power path, interlocks and guards, a safety-rated relay. That has always been true of automation. It is not new, and it is not special to AI — but it is worth saying out loud on the release that lets an assistant press the button.

Also

• Assistants can read macro limits. whoami now reports your macro caps and how many you have, alongside the device, rule and monitor counts already there.
• The API-token picker offers everything the server accepts. View reports was missing from the list of permissions you could put on a token even though tokens could carry it — the picker now reads the list from the server, so it cannot drift again.
• Running a macro is now its own permission in the web app too. A team member with a read-only role could previously start a macro from the Macros page; they can't now. Operator and Admin roles are unaffected, and aborting a run still needs no permission at all — nothing should stand between a person and a stop button.
• Assistants can set up sensors with no built-in driver. The device tools now accept the generic I²C/SPI fields — init byte, bytes to read, byte order — so “a BH1750 light sensor at 0x23” in a sentence is enough for the assistant to fill in the datasheet numbers. Same fields the Add-device form has always had. An I²C device created without pins now lands on the ESP32's standard SDA 21 / SCL 22 (the firmware default) and the reply says so — before, it was refused, and an assistant rightly would not guess a pin it cannot undo.

Macros and the MCP server are each enabled per account. Full detail — what to grant, what to read before you allow it — is in Connect an AI agent and Macros.

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 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 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 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 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.