Troubleshooting

No answer at all

Connection refused. hart-sim serve listens on 127.0.0.1:5094. A host on another machine, in a VM or in a container needs --host 0.0.0.0. Neither HART-IP nor the control channel has authentication, so do this on a network you trust. The control channel stays on loopback unless you also set --control-host.

hart-sim poll finds nothing. Is the server running, and on that port? By default poll tries all 64 addresses over TCP. Is your host using UDP? hart-sim serves both on the same port.

A request gets no answer, but others do. hart-sim is strict: a bad checksum, a request for another address or a malformed frame gets no answer, as on a real loop. Check the checksum, and that the long address matches. The long address carries only 14 bits of the expanded device type, so 0xFA01 is addressed as 0x3A01.

Everything times out. Is a no_response or delay fault set? hart-sim clear <tag> removes all faults of that device. A delay on UDP delays all UDP clients, because there is a single UDP thread.

IPv6 does not work. HART-IP here is IPv4 only.

Unexpected response codes

Code	Meaning here	Check
2, 3, 4	invalid selection, value too high or too low	the values in the README's command list
5	too little data	the length of the request
7	write protect	write_protect fault; commands 38 and 48 are not blocked
9-12, 14	range and unit checks	span against min_span, limits against sensor_limits
32	busy	a busy fault; send it again
64	command not implemented	the supported list in the README

Values

The loop current does not follow the PV. Is it saturated, fixed by command 40 or in multidrop mode? Command 6 fixes it at 4 mA, but a polling address in a bench file does not. That deviates from the wording of the HART specification.

The current is stuck at 21 mA or 3.6 mA. That is the alarm current of a sensor_failure, chosen by alarm in the profile.

After clear, a drifted value does not return. Clearing drift stops it, but keeps the offset so far. Restart the bench to start over.

The tag changed, but inject still wants the old one. The control channel addresses a device by its original tag, also after command 18 or 22 renamed it.

A range change behaves differently from a real device. Commands 36 and 37 apply the same limit checks as 35, while a real device's command 37 keeps the span.

Your host does not accept it

hart-sim has no device descriptions (DD), a made-up manufacturer ID and byte layouts from public sources, and it has not been tested against real HART hosts. A host that insists on a DD or a registered device type will not accept it. Please open an issue with the frames, which Wireshark decodes.