HiveMQ Edge 2026.13 is Released
What's New in HiveMQ Edge 2026.13
HiveMQ Edge 2026.13 brings OPC UA alarms to MQTT. Alarms and conditions are now published as they change state, and can be acknowledged, commented on, or shelved by publishing a message back. The release also makes secured OPC UA connections practical in factory networks that have no certificate authority, and sharpens how tags describe what a device will actually accept.
OPC UA Alarms and Conditions
Until now, the OPC UA adapter read data variables and wrote values back to them. It now handles the alarm path as well.
Point a tag at an alarm on your OPC UA server, and every state transition arrives on MQTT as it happens — one message per transition, carrying the alarm's new state and the event id identifying that transition. A tag can follow one alarm, or a whole notifier's worth of them through a single subscription.
Acknowledgment travels in the other direction. A southbound mapping routes an MQTT topic to that same tag, and a command published there calls the OPC UA method behind it:
{
"method": "ACKNOWLEDGE",
"eventId": "q80SzXKZ4kmvxQBGgHNPMg==",
"comment": "Acknowledged by the line supervisor"
}
The command is the tag's value, and the tag's southbound schema describes exactly that shape, so a message that does not match is rejected before it reaches the server. Writing to any tag needs a southbound mapping, which is a commercial feature; everything the alarm path publishes northbound works without one.
Fifteen methods are available this way, covering acknowledgment and confirmation, enable and disable, silence and suppression, shelving, service state, reset, and dialog responses. Edge also asks the server to re-report current alarm state after every reconnect, so an interruption does not leave a stale picture behind.
The upshot: an operator console, a historian, or an analytics service can consume and act on plant alarms from the same broker it already takes process data from, with no second OPC UA client to build and operate.
For tag kinds, the published message shape, and the full command reference, see OPC UA Alarms and Conditions in the documentation.
Secured OPC UA Without a Certificate Authority
Factory networks frequently have no CA at all: every device presents its own self-signed certificate, which chains to nothing. Connecting to those servers over a secured endpoint used to mean maintaining a truststore holding one exported certificate per machine, and redistributing it to every Edge instance whenever a device was replaced or its certificate rotated.
2026.13 adds a lighter route. The new SELF_SIGNED setting trusts a server by the SHA-256 fingerprint of its certificate, listed in a file the adapter reads at start-up — short enough to be emailed or read out over the phone. The checks that still matter stay on: the certificate must be current, name the endpoint being connected to, and carry the identity the server announces.
Deployments that do have a certificate authority get the opposite problem solved. Revocation checking can now be satisfied rather than switched off, because the adapter accepts the CA's revocation list — and it warns at start-up when revocation is being enforced without one.
Underneath both, the validation model is now explicit. A single named preset covers the common cases, and where none fits, each individual check is configurable on its own, with anything left unset defaulting to its strictest value. A relaxed check is therefore always a deliberate line in the configuration, never an omission nobody noticed.
Existing configurations need no changes. Every setting that worked in 2026.12 validates certificates exactly as it did before, and there is no migration step.
The presets, the individual checks, and the fingerprint and revocation list formats are described under OPC UA Adapter in the documentation.
Separate Read and Write Tag Schemas
A tag used to publish a single schema describing what it reads, and that same schema was offered as the write target — including the many fields that can never be written. Tags now describe the two directions separately: what Edge publishes northbound, and what the device will actually accept southbound.
For anyone building southbound mappings, the editor now offers only real write destinations. The write schema has also become the contract the write path validates against, so a malformed publish is rejected before it reaches the device. And it is what made Alarms and Conditions possible in the first place, since an alarm's write shape is a command rather than a subset of what it reads.
Both schemas are served by the same endpoint, selected with a direction parameter — see Northbound and southbound tag schemas.
Breaking Change: writeSchema() Removed From the Adapter SDK
If you build your own protocol adapter, writeSchema() on TagSchemaCreationOutput.DataPointSchema is gone — call southboundSchema() instead. It returns the same thing; the name changed to match the northbound and southbound vocabulary used everywhere else. Adapters that do not produce a write schema are unaffected.
Adapter Configuration Errors Now Reach the Caller
Creating or updating a protocol adapter over the REST API used to answer success before Edge had read the configuration you submitted. If that configuration could not be read — a misspelled setting name, a value of the wrong type, a tag definition the adapter refuses — the adapter was never created, and every later request for it returned "not found". The reason went to the Edge log and the event stream, never to the response.
The endpoints that accept an adapter configuration now convert it before writing it, using the same converter the configuration reload uses, and answer 400 Bad Request when it does not convert. The response names the path through your own payload and carries the reason the adapter gave. Because the check is the reload's own conversion, the API refuses exactly what the reload refuses, for every adapter type.
If you automate adapter creation, expect the new status code. A script that used to see success and then poll until its own timeout expired now fails immediately, naming the field that was wrong.
Additional Improvements
- OPC UA adapters now report a
CONNECTINGstatus while they connect.CONNECTEDused to appear before the connection was fully usable; it now means the adapter is genuinely ready. Anything reading adapter status over the API should expect the new value. - An OPC UA adapter that could not browse now recovers on its own. When Edge fails to build a server's data-type information while connecting, tags, events and values are unaffected, but browsing the address space is refused until that information exists. Until now that state lasted for the life of the connection, and only a reconnect could clear it. A periodic health check now retries the build, so a server that was briefly slow or restrictive no longer leaves browsing shut.
- Editing an OPC UA adapter no longer adds a
messageSecurityModeline nobody wrote. Saving an adapter through the UI or API used to insert the setting into the configuration file. Nothing behaved differently, but the line no longer turns up after unrelated edits. - HiveMQ Pulse agent updated to 3.1.10.
- Dependency updates across the platform, including Netty, Logback, the build toolchain, and a major upgrade of the frontend React stack — reducing exposure to known vulnerabilities in transitive libraries.
Get Started Today
Use the download link to get HiveMQ Edge 2026.13, or find us on GitHub and Docker:
Get started by running
docker run --name hivemq-edge --pull=always -d -p 1883:1883 -p 8080:8080 hivemq/hivemq-edge
Or clone our repository
git clone git@github.com:hivemq/hivemq-edge.git
You may also try out our Helm Chart
helm repo add hivemq https://hivemq.github.io/helm-charts && helm repo update
HiveMQ Team
Team HiveMQ brings together deep expertise in MQTT, Industrial AI, IoT data streaming, UNS, and Industrial IoT protocols. Follow us for practical deployment guidance, best practices for building a secure, reliable data backbone, and insights into how we are shaping the future of connected industries.
Our mission is to transform industrial data into real-time intelligence, actionable insights, and measurable business outcomes.
Have questions or need support? Contact us. Our experts are ready to help.
