RAP Systems · Lawnswood Technology Limited
Release notes — what has changed in each firmware release, newest first.
There are two ways to update, and which one you can use depends on what has internet access.
HG1Discover, the Windows utility, downloads the firmware to your PC and sends it to the gateway over your local network. The gateway itself needs no internet connection — only your PC does, over Wi-Fi or a second network adapter — so this is the route to use on an isolated or air-gapped network, and the easier one when updating several gateways.
System Update, on the gateway's own web interface, has the gateway fetch the firmware itself and shows you what has changed before applying it. This needs the gateway to have internet access.
Either way the update happens only when you ask for it. The gateway does not check for new firmware on its own, so it is never updated without someone deciding to. Updates keep your configuration, and the gateway returns to its previous firmware by itself if an update does not start correctly.
Remote access - Files left on the gateway by the factory setup of remote access, and no longer needed once setup is complete, are now removed. This also happens on gateways already in service when they install this update. Remote access works as before: the web address and passwords do not change, and it stays on or off as you left it. - The gateway no longer registers a second, unused remote address alongside its web address.
Device page - The green and grey dots beside each value now show whether the value is current. In MUX mode, a brief scan error could turn values that are read only once, such as the tag and ranges, grey for good even though the device stayed online. These values now stay green while the device is online. In gateway mode, the dots did not turn grey when a device went offline. They now do, and turn green again when it comes back. - A value that stays grey on an online device is one the device does not report, for example fields that HART 5 devices do not support.
Help - The on-device help for firmware updates now describes when a new version is kept, and the troubleshooting section covers a gateway that restarts by itself shortly after an update.
Reliability - Fixed the cause of the storage errors that could occur in the first minutes after an update. Saving the update status could briefly interrupt other reads and writes to the gateway's storage; a read was retried, but an interrupted write could switch the storage to read-only until the gateway restarted. The recovery added in 2026.10.202 stays in place as a safeguard.
Reliability - Occasionally, in the first few minutes after an update, the gateway's storage could switch to read-only to protect itself after a failed write. Settings could not be saved and the automatic Modbus map could not be rebuilt until the gateway was power-cycled. The gateway now detects this within 15 seconds and restarts itself, which clears it. If it happens three times in a row the gateway stops restarting and keeps running so that it can be investigated, and each occurrence is recorded in the update log. - After an update, the gateway confirms the new version only once its storage is writable as well as the gateway software running, so an update that cannot save settings is not kept. - The automatic Modbus map is only replaced, and the gateway software only restarted, when the new map has been written in full. Previously a failed write could restart the gateway software with no map.
Modbus writes to the transmitters - A new setting on the Configuration page, Modbus Writes to Devices, chooses what Modbus clients may do: Only read (the default), Change device settings, or Change settings and run maintenance actions (zero, trim, fixed loop current, simulate, reset, lock, burst, poll address). Writes refused by the setting get exception 1. - Writes to device settings reach the transmitter again, and the value it accepts appears in the matching read register. Settings made of several values are sent together, whichever order the registers are in, and a block write stores every value before anything is sent; any value you do not write is sent as the transmitter has it, never as zero or a default. - A write the transmitter does not answer, or that a busy multiplexer holds up, is tried again every 2 seconds, up to 5 times, while the device is online. If the same setting is written again in the meantime, only the newest value is sent. Maintenance actions are not repeated if only their reply was lost. - Configuration downloads (the write coil and the Commissioning page) send only what you changed, and report a failure if the transmitter refused any of it. - Action registers (self-test, reset, zero, set range to the current value) act on a non-zero value only; writing 0 does nothing. - Analog output settings are read from the transmitter, so changing one of them no longer sends zeros for the others. Writing the number of response preambles changes the right value. A loop current trim is applied once, not twice. - The user-command registers follow the same setting: at Change device settings they accept read commands and configuration downloads, and at Change settings and run maintenance actions also self-test, device reset and PV zero. Any other command number gets exception 3.
Modbus behaviour - A request that starts on an unmapped register now gets exception 2 (illegal data address), as the Modbus specification requires. Gaps after a mapped start still read as zero. If your client polls from an address that has no register, move its start to the first mapped register. - Modbus function 65, used only by retired internal tools to read and write any value in the gateway, has been removed. It now gets exception 1, like any function code the gateway does not support.
Multiplexer mode - Polling through a KFD2 multiplexer is about 50% faster, and HART-IP requests and gateway polling share the multiplexer without disturbing each other. - A transmitter whose reply the multiplexer delays is no longer reported offline, and a busy multiplexer no longer causes repeated retries of the same commands. - Deferral Mode is always Full on a multiplexer: while a PC tool uses the virtual serial port, the gateway pauses polling and HART-IP answers Busy until the tool has been quiet for 10 seconds.
Virtual serial port (PC tools) - A new connection takes over from the previous one, so a PC tool that lost its link can reconnect straight away. - HART frames from the PC reach the loop intact even when the network splits them into pieces, and a pause inside a frame no longer drops the connection.
Reliability - More precise timing on the HART link, in both modes, ends occasional lost replies. - A device is reported offline after about 10 seconds without an answer, not after a single missed poll, so a brief disturbance on the loop no longer raises an offline alert or MQTT offline message. - If an MQTT broker keeps accepting the connection and then dropping it, the gateway waits longer between attempts, from 5 seconds doubling up to 5 minutes, instead of reconnecting continuously. - The gateway no longer occasionally reports a failed configuration download or reset when the transmitter carried it out, under heavy HART-IP use. - Each Modbus TCP connection no longer writes several lines to the system log.
Web interface - Screenshots in the built-in help now display. - The Remote Access dialog no longer shows passwords again when it is reopened: a password is shown once, when it is created, and is cleared when the dialog closes.
HART-IP - The option that allows software to make changes is now labelled Allow software to change device settings and run maintenance actions, which is what it has always allowed.
For gateways working with a Pepperl+Fuchs KFD2-HMM-16 HART multiplexer:
- Rebuild & Scan completes again. Since April it could run without finishing, so newly connected transmitters were never found. - Transmitters behind the multiplexer come online reliably after a restart. A busy multiplexer could stall the start-up reads. - A transmitter that is disconnected and reconnected no longer shows a reading of zero while it is being found again. - HART-IP works through the multiplexer: HART-IP software can see and read the transmitters connected to it.
For every installation: if a device does not answer its first identity request after a restart, its settings are read again until complete, instead of staying incomplete until the next restart.
If you are updating from a version earlier than 2026.09.199, this release also includes HART-IP (off until you turn it on). Earlier than 2026.09.198, it also includes alerts by email, webhook and MQTT (off until you turn them on; chapter 14 of the User Manual). Earlier than 2026.09.195, it also includes device settings that are always read in full after a restart, even if a message on the HART loop is lost; and for MQTT, a device details topic, the device's own diagnostics in each reading, and no false zero readings after a restart. Earlier than 2026.09.190, it also includes MQTT publishing that recovers on its own after a lost broker connection.
HART-IP software can now reach the gateway and the HART devices on it over the network, on port 5094 (UDP or TCP). Signed in as an engineer, open HART-IP from the home page and press Start. HART-IP never pauses polling, so Modbus, MQTT and alerts stay live while it is in use.
It is off until you turn it on, read-only unless you allow software to change device settings, and by default accepts connections only from the gateway's own subnet. If older HART-IP software that worked with an HG1 Plus cannot add the gateway, tick HG1 Plus compatible and rescan. A factory reset from the CFG1 terminal turns HART-IP off and clears its settings. Nothing else changes.
If you are updating from a version earlier than 2026.09.198, this release also includes alerts by email, webhook and MQTT when a device stops responding, reports a failure or asks for maintenance, when a reading goes above or below limits you set, or when the gateway stops reading its HART devices (off until you turn them on; chapter 14 of the User Manual). Earlier than 2026.09.195, it also includes device settings (range, units, damping, sensor limits) that are always read in full after a restart, even if a message on the HART loop is lost, which affects every installation; and for MQTT, a device details topic, the device's own diagnostics in each reading, and no false zero readings after a restart. Earlier than 2026.09.190, it also includes MQTT publishing that recovers on its own after a lost broker connection.
The gateway can now tell you when something needs attention. Open Alerts from the home page, enter your mail server or a webhook address, press Send test, then Start. You are sent a message when a device stops responding, reports a failure or asks for maintenance through its NAMUR NE 107 diagnostics, when a device's reading goes above or below limits you set, or when the gateway stops reading its HART devices, and again when each is back to normal.
Each message ends with a link to the gateway on your network and, while Remote Access is on, a link that works from anywhere. Value limits are set per device in the Alerts dialog, in the device's own units. Office 365 and Gmail need an app password rather than the account's own. A webhook can post to Slack, Power Automate, Node-RED, ntfy and similar services. With MQTT Publishing on, each alert is also published on the device's alert topic.
A condition must last 30 seconds before it is sent, alerts close together go out as one message, and a restart or update does not send a flood of them. Chapter 14 of the User Manual covers the settings.
Alerts are off until you turn them on, and nothing else changes. A factory reset from the CFG1 terminal now also clears the alert settings, as it does the MQTT settings.
If you are updating from a version earlier than 2026.09.195, this release also includes: device settings (range, units, damping, sensor limits) that are always read in full after a restart, even if a message on the HART loop is lost, which affects every installation; and for MQTT, a device details topic, the device's own diagnostics in each reading, and no false zero readings after a restart. Earlier than 2026.09.190, it also includes MQTT publishing that recovers on its own after a lost broker connection.
The gateway can now tell you when something needs attention. Open Alerts from the home page, enter your mail server or a webhook address, press Send test, then Start. You are sent a message when a device stops responding, reports a failure or asks for maintenance through its NAMUR NE 107 diagnostics, when a device's reading goes above or below limits you set, or when the gateway stops reading its HART devices, and again when each is back to normal.
Value limits are set per device in the Alerts dialog, in the device's own units; leave them empty for no limit. Office 365 and Gmail need an app password rather than the account's own. A webhook can post to Slack, Power Automate, Node-RED, ntfy and similar services. With MQTT Publishing on, each alert is also published on the device's alert topic.
A condition must last 30 seconds before it is sent, alerts close together go out as one message, and a restart or update does not send a flood of them. Chapter 14 of the User Manual covers the settings.
Alerts are off until you turn them on, and nothing else changes. A factory reset from the CFG1 terminal now also clears the alert settings, as it does the MQTT settings.
If you are updating from a version earlier than 2026.09.195, this release also includes: device settings (range, units, damping, sensor limits) that are always read in full after a restart, even if a message on the HART loop is lost, which affects every installation; and for MQTT, a device details topic, the device's own diagnostics in each reading, and no false zero readings after a restart. Earlier than 2026.09.190, it also includes MQTT publishing that recovers on its own after a lost broker connection.
After a restart the gateway reads each HART device's settings: range, units, damping and sensor limits. If a single message on the HART loop was lost during that read, the rest were skipped, and the range could stay at zero, including in the Modbus registers, until the device was next disconnected. The gateway now carries on past a lost message and repeats the read until it is complete. This affects every installation, and everyone should install this release.
MQTT publishing gains three things:
Device details. Each device is described on its own topic: manufacturer, device type and ID, revisions, range, sensor limits, damping and alarm setting. It is sent on connect, whenever anything in it changes, and once a day, so an asset register or maintenance system can see which instrument is where, and when one is replaced or re-ranged. It is on by default and can be turned off in the MQTT Publishing dialog.
Device diagnostics. When a HART device reports additional status, each reading now names the conditions, such as failure, out of specification, maintenance required, function check or electronic defect, together with the raw status bytes. A change is sent at once.
No false readings. For a few seconds after a restart a device is back online before its first reading; MQTT used to send zero during that time, which a historian would record as real. It now sends no value until the device has been read, and a variable the device does not provide is sent as empty rather than zero.
No settings need altering.
If you are updating from a version earlier than 2026.09.190, this release also includes MQTT publishing that recovers on its own after a lost broker connection.
If the connection to your broker was lost in certain ways, the gateway could stop publishing and never start again, even with the broker reachable. The MQTT indicator showed red and the message count stopped, but nothing else looked wrong, and only restarting the gateway brought it back.
The gateway now watches its own connection. If it has been disconnected for more than a minute and a half, it rebuilds the connection itself and carries on. Readings taken while it was disconnected are still sent when it returns, as before.
If your publishing has stopped for no apparent reason, this release fixes it. Anyone using MQTT publishing should install it. Nothing else changes and no settings need altering.
MQTT Publishing can now send your readings to Microsoft Azure IoT Hub. Choose Azure IoT Hub as the service, enter your hub address, set the identifier to the device ID you created in Azure, upload that device's certificate and key, and press Test.
Azure is strict about names. The device ID in Azure, the identifier in this dialog and the name inside the certificate must all be the same, or Azure refuses the connection without saying why. Azure also chooses the topics itself, so the topic prefix is ignored, and it accepts only one connection per device at a time. Chapter 13 of the User Manual covers all of this.
That completes cloud publishing: any MQTT broker, AWS IoT Core and Azure IoT Hub, each one tested against a real account before release.
Publishing to any other broker is unchanged, and nothing you have already set up needs altering.
If you are updating from a version earlier than 2026.09.185: this release also adds MQTT publishing, and the gateway now keeps its network address after a firmware update. It may take one last new address as this update installs; if you cannot find it afterwards, use the fixed address printed on the label.
MQTT Publishing can now send your readings straight to AWS IoT Core. Choose AWS IoT Core as the service, enter the address from your AWS console, upload the certificate and key AWS gives you for the device, and press Test.
The policy attached to that certificate decides whether it works, and AWS refuses a connection it does not like without explaining why. It must allow this gateway to connect using its own name, and to publish to your topic prefix. If you tick Keep the last reading on the broker, the policy needs to allow retained publishing as well, which AWS treats as a separate permission. The policy created by the AWS console wizard allows only its own tutorial topics, so replace it. Chapter 13 of the User Manual covers all of this.
Publishing to any other MQTT broker is unchanged. Azure IoT Hub is still to come.
Also in this release: if settings are incomplete, Test now says what is missing instead of showing an empty message. A factory reset from the CFG1 terminal clears the broker settings, password and certificates, so a gateway leaving your site does not take your broker credentials with it.
If you are updating from a version earlier than 2026.09.185: this release also adds MQTT publishing, and the gateway now keeps its network address after a firmware update. It may take one last new address as this update installs; if you cannot find it afterwards, use the fixed address printed on the label.
The gateway can now send live readings to an MQTT broker as they change, for dashboards, historians and analytics. Open MQTT Publishing from the home page, enter your broker address, press Test to check it, then Start. Readings are sent when they move by more than a percentage you choose, at a heartbeat interval regardless, and immediately whenever a device goes offline or its status changes. The connection can be encrypted, and readings taken while the broker is unreachable are held and sent when it returns. Chapter 13 of the User Manual covers it in full.
The status bar now carries an MQTT indicator, and published readings include engineering units and the device long tag.
Until this release the gateway asked for a network address in a way that made it look like a different device after each firmware update, so a DHCP server usually gave it a new one. It now identifies itself by the MAC address printed on its label, so the address stays put, and a DHCP reservation made against that MAC will hold.
Please note: because that identity changes with this update, the gateway may take one last new address as it installs. If you cannot find it afterwards, use the fixed address printed on the label, or look for its MAC address in your router.
A factory reset from the CFG1 terminal now also turns remote access off. It already cleared the remote access passwords, which left a connection nobody could log in to.
Also in this release: when remote access is reached from outside, only the Engineer role can install firmware. The view-only Operator role could previously reach the firmware upload page.
If you are updating from a version earlier than 2026.09.179: remote access, once you have turned it on, now stays on through a firmware update. It used to be switched off by every update.
If remote access was turned on, installing a firmware update switched it off, and it had to be turned on again from the web interface on the local network. It now stays as you left it, on or off, through every update, including this one.
Resetting the gateway to factory settings with the CFG1 terminal now also turns remote access off. The reset already cleared the remote access passwords; turning remote access on again generates new ones.
The About page no longer lists a HART-IP server, which the gateway does not provide.
If you are updating from a version earlier than 2026.09.178: each gateway now also has its own fixed address in the range 169.254.x.x, printed on its label, for connecting a PC directly. Previously every gateway used 169.254.100.1. See the release notes for details.
Every gateway gives itself an address in the range 169.254.x.x, derived from its MAC address and printed on the label. It is fixed for the life of the unit and no two gateways can clash, so several on one cable or switch each keep their own. Connect a PC directly, set its adapter to obtain an IP automatically, and browse to the address on the label.
Previously every gateway used the same 169.254.100.1. Only one gateway on a network can hold that address, so where several were connected together, one answered and the rest could be reached only through DHCP. Gateways running firmware older than this release continue to use 169.254.100.1, so a network with a mixture of old and new gateways is unaffected.
The address is present at all times, alongside a DHCP lease or a static address, and it is no longer lost when you change anything in Network Settings.
Static addresses must come from a private range: 192.168.x.x, 10.x.x.x or 172.16-31.x.x. Network Settings refuses an address in 169.254.x.x and says so at the time. That range is reserved for the addresses devices assign themselves automatically, and the gateway already has one of its own.
If you are updating from a version earlier than 2026.09.175: a static address in 169.254.x.x used to be accepted, work until the gateway was restarted, and then be discarded, leaving the address field blank in Network Settings. Any gateway left with no address by that fault is returned to DHCP on update so it can be found on the network again.
Each gateway now has a single link-local address: the one derived from its MAC and printed on the label, in the form 169.254.x.x. Connect a PC directly, set its adapter to obtain an IP automatically, and browse to the address on the label.
Gateways running 2026.09.176 could hold three addresses at once on a direct cable - the one on the label, the older shared 169.254.100.1, and a third that the gateway chose at random when no DHCP server was present. Only the label address means anything to you, so the other two are gone.
Gateways running firmware older than 2026.09.176 continue to use 169.254.100.1, so a network with a mixture of old and new gateways is unaffected.
Static addresses are unchanged and must still come from a private range: 192.168.x.x, 10.x.x.x or 172.16-31.x.x.
Every gateway gives itself an address in the range 169.254.x.x, derived from its MAC address, and it is printed on the label. It is fixed for the life of the unit and no two gateways can clash, so several on one cable or switch each keep their own. Connect a PC directly, set its adapter to obtain an IP automatically, and browse to the address on the label.
Previously every gateway used the same 169.254.100.1. Only one gateway on a network can hold that address, so where several were connected together, one answered and the rest could only be reached through DHCP. Gateways still take 169.254.100.1 as well when nothing else is using it, so existing instructions and older labels keep working.
The address is always present, whether or not a DHCP server is on the network, which makes it the dependable way to reach a gateway on a bench or an isolated network.
Static addresses are unchanged and must still come from a private range: 192.168.x.x, 10.x.x.x or 172.16-31.x.x.
Fixed: a static IP address in the 169.254.x.x range was accepted, worked until the gateway was restarted, and was then discarded — leaving the gateway with no fixed address and the address field blank in Network Settings. Introduced in 2026.09.171.
Static addresses must now come from a private range: 192.168.x.x, 10.x.x.x or 172.16-31.x.x. Network Settings refuses a 169.254.x.x address and says so at the time, rather than appearing to accept it. The 169.254.x.x range is reserved for the addresses devices assign themselves automatically, and the gateway already takes one of its own.
Any gateway left with no address by the earlier fault is returned to DHCP on update, so it can be found on the network again. If you had set a static address on such a unit, set it again from a private range.
Network Settings also now displays a configured address correctly instead of leaving the field blank.
If the gateway application fails to start repeatedly, the RUN LED blinks instead of staying dark. A gateway that has not come up is now identifiable at the panel, without a network connection.
A factory reset using the configuration terminal left the gateway without its tag definitions. They are now restored along with the rest of the factory configuration.
The gateway can be returned to its factory configuration with a wire link, the same method HG1v2 owners already know. Power the gateway off, fit a link between the CFG terminal and 0V, power on, then remove the link.
The gateway's hostname and administrator password are kept, along with its security keys and remote-access credentials - those identify the unit rather than configure it. Everything else returns to how it left the factory.
On a network with more than one gateway, every gateway except the first took around two minutes longer to start and reported an internal fault afterwards, even though it was working normally. Start-up is now unaffected by how many gateways are present.
The gateway's internal maintenance interface no longer accepts connections from the network and no longer carries a built-in username and password. It now uses the gateway's own credentials.
Gateways running much older firmware previously needed two updates to reach the current release. One update is now enough, whatever version the gateway is starting from.
Roughly half of all update downloads failed their integrity check and had to be retried by hand. Downloads now retry automatically and report their result correctly.
Each gateway is now given its own password when it is built, replacing the shared one used previously. The password is recorded securely at manufacture and can be supplied by RAP Systems support if it is ever needed. Gateways shipped before this release are unaffected.
Updating could regenerate configuration that had been changed on the gateway. Regeneration is now limited to the files that are genuinely rebuilt from your settings.
A custom Modbus register map could be replaced when the gateway rebuilt its automatic map. Custom maps are now left alone.
The firmware the first HG1v4 gateways shipped with. If your gateway has never been updated, this is the version it is running, and everything listed above has happened since.
Updating from 2026.05.150. A gateway still on its original firmware reaches the current release in a single update, whatever version it is starting from, and keeps its configuration. Versions numbered below 2026.05.150 were used during development and were never fitted to a shipped gateway.