What Changed in HART 7?
HART has evolved through revisions, and HART 7 is the one that mattered most because it brought wireless into the family and sharpened the protocol's diagnostics. Knowing what a revision adds - and why a host and device must agree on revision - saves you from the confusion of a new device whose features an old host cannot see. This page explains the headline additions in HART 7 and why device revision is a real compatibility factor. It is for engineers specifying instruments or wondering why a host does not show a device's newer capabilities.
HART 7 in one line: HART 7 is the protocol revision that added WirelessHART as a standardized wireless transport, richer standardized device diagnostics, event notification so devices can report changes proactively, and longer device tags. It is a superset of earlier HART, so HART 7 devices remain readable by older hosts for basic data, but the newer features are only usable by a host that also supports HART 7.
The Headline Additions
The most consequential thing HART 7 did was bring wireless into the standard. WirelessHART, standardized as IEC 62591, is the HART 7 wireless transport, so the mesh networking that lets battery-powered devices report over the air is not a separate protocol bolted on but part of the HART 7 family. This is why WirelessHART and wired HART share the same command set and device model - they are two transports under one protocol revision. The WirelessHART overview page covers that transport in depth.
HART 7 also strengthened diagnostics. It defined a richer, more standardized way for devices to report their health and specific fault conditions, moving beyond the basic status bits so that a host can understand more about what is wrong with a device without relying entirely on device-specific extensions. This is part of why HART diagnostics became genuinely useful for predictive maintenance rather than just a fault light, because more of the useful health information is available in a standardized form.
Two further additions round out the picture. Event notification lets a device proactively report that something changed or a threshold was crossed, rather than waiting to be polled, which pairs naturally with the more capable diagnostics. And HART 7 lengthened the device tag, giving the longer, more descriptive tag names that modern asset-management practice expects. Together these made HART 7 devices better citizens of a plant that wants rich, self-reporting instruments rather than mute analog sources.
Why Device Revision Matters
HART is designed so newer revisions remain backward compatible for the basics: a HART 7 device still answers the universal commands an older host knows, so an older host can always read its identity, dynamic variables, and status. This is why you can drop a modern transmitter onto a system built around an earlier HART revision and get its core readings. Backward compatibility for fundamental data is a deliberate and durable property of the protocol.
What does not carry backward are the newer features. An older host that predates HART 7 has no way to use event notification, the richer diagnostics, or the longer tag, because it does not know the commands and structures HART 7 added. So a HART 7 device connected to an older host works, but only at the older host's level, and the newer capabilities sit unused. This is exactly the situation where an engineer wonders why a device's advertised features are missing - the host, not the device, is the limiting revision.
The practical rule is to check that the host and its device descriptions support the revision of the devices you deploy when you want the newer capabilities. Reading a device's revision - the identity data command 0 returns includes it - tells you what it can do; matching your host and DD library to it tells you what you can actually use. The device ID page covers the identity fields, and for full use of HART 7 diagnostics and events, both the device and everything reading it need to be at that revision.
Frequently Asked Questions
What are the main features HART 7 added?
HART 7 standardized WirelessHART as a wireless transport, added richer standardized device diagnostics, introduced event notification so devices can report changes proactively instead of only when polled, and lengthened the device tag. Together these turned HART devices into richer, more self-reporting instruments while keeping backward compatibility for basic data with older hosts.
Can an older host read a HART 7 device?
Yes, for the basics. HART 7 devices still answer the universal commands an older host knows, so it can read identity, dynamic variables, and status. What an older host cannot use are the HART 7 additions - event notification, richer diagnostics, and the longer tag - because it does not know the newer commands. The device works, but only at the host's revision level.
Is WirelessHART part of HART 7?
Yes. WirelessHART, standardized as IEC 62591, is the HART 7 wireless transport, so it is part of the HART 7 family rather than a separate protocol. That is why WirelessHART and wired HART share the same command set and device model - they are two transports under one protocol revision, which lets the same device data and commands work over either.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.