HiveMQ Edge Protocol Adapters

Three things can be wrong, and each fails at a different place. In none of them does HiveMQ Edge itself fail to start.

The first two are decided by reading the configuration alone, so no device is consulted and connecting could not produce a different answer. The third covers everything the server gets a say in. The node is not a condition of the declared type, no notifier can be reached, a narrowing node lies outside the notifier’s hierarchy, or the server does not answer in time. It is evaluated when the subscription is created, so it is evaluated again after a reconnect.

type and filterType accept the browse name of any of these:

The hierarchy is additive: each type carries every field its parent does, plus its own.

Edge calls the method and publishes what the device returns as a response. Edge does not retry, buffer, or interpret.

A method call has a side effect, so Edge does not retry a call on your behalf. If a response does not arrive, the method can still have run. Only the device’s state tells you whether it ran.

Edge guarantees nothing about requests that you publish while you change a configuration. If a request must not be lost, do not publish into a configuration change.

A method tag carries two fields in its definition:

After the adapter connects, Edge verifies three things about the tag: that the node exists, that the node is an object, and which methods the object offers. If Edge cannot verify the tag then, the first request to the tag verifies it again. A method tag that fails verification does not stop the adapter, and does not fail the adapter’s other tags.

The first setting governs the other two. With method calls off, Edge gathers no request parameters, so the other two settings have no effect, and the mapping editor disables them. With method calls on, the other two are independent of each other. For a request whose response you do not need, select only the first setting.

In config.xml, an absent element means false.

Exactly one southbound mapping can match a tag and topic filter. If two mappings match, Edge does not choose between them and reads no method-call settings at all. Method calls through such a mapping fail as if the first setting were off.

A method tag needs a northbound mapping, which publishes the responses. No northbound setting is specific to method calls.

If a method tag has no northbound mapping, Edge still runs the calls and discards the responses.

With a reply address, Edge publishes one copy of the response per northbound mapping configured for the tag, not one copy in total.

A method request must carry methodName in its payload. In the schema on your topic filter, declare methodName as a required string property.

A request can carry correlationData and responseTopic in its payload or as MQTT 5 properties. In your schema, declare both as optional string properties.

If you save a mapping with This mapping carries method calls selected in the UI or through the REST API, and your schema does not require methodName, Edge writes a warning to the log, but still saves the mapping. Edge does not check a mapping that you write into config.xml. To test your schema, Edge validates an empty object against it, and warns unless the validation reports methodName as missing. The test finds a requirement in a root required array, in an allOf branch, or behind a $ref. If you state the requirement only under a condition, such as in an if/then pair, Edge warns although your schema is correct. If one branch of an anyOf requires methodName and another does not, Edge does not warn, although such a schema accepts a request without methodName.

The example’s fromNorthSchema is the schema on your topic filter. {} checks nothing, so it does not require methodName, as The schema on your topic filter above advises. Replace it with your own schema.

Three conditions together make a southbound message a method call:

Edge consults nothing else. A message that fails any one of the three conditions is not a method call.

A response fails the first condition, because a response names the method in responseMethodName. If a response arrives where Edge reads requests, Edge quarantines the response because it names no method. The response calls nothing.

The distinction matters because a reply address can name any topic that Edge can publish to, and a northbound mapping’s topic is equally free. If a method tag’s responses go to the topic where the tag’s own requests arrive, every response lands where Edge reads requests. Because a response cannot pass for a request, no response triggers a call.

Edge enumerates all methods of the object that your tag names, and of that object’s type. Edge also enumerates the methods of every type up the chain that the object derives from. You can call a method by its BrowseName in two cases:

You can also call any of these methods by the node id of the method node. Edge matches the node id only against the methods it found this way. If a nearer type declares a method of the same name, Edge does not offer the farther type’s declaration, and its node id is not found.

To call a method, Edge reads the method signatures from the server: which methods exist, and the arguments of each. Some servers restrict access to their type nodes, so this read can fail. If the read fails:

Edge promises nothing beyond these three points.

An object can expose two methods with the same name. OPC UA requires a browse name to be unique on a type definition, not on the instance that a method tag points at. One object can therefore carry a Start from each of two vendors' interfaces.

The value of methodName therefore takes two spellings. Edge tells the spellings apart by whether the value contains a semicolon:

Use the plain name. If two methods share it, Edge refuses the request, and the log lists both node ids. Put one of them in methodName instead.

The identifier after the semicolon is whatever the server assigns: s= for a string, i= for a number, g= for a UUID in its full form 8-4-4-4-12, and b= for base64 bytes.

Use the method’s actual node id, which is what Edge matches. A node id names a node by its identifier, and the identifier need not be the same string as the browse name. If the two differ on your server, copy the node id that your browser shows for the method. Do not build a node id from the name.

Give the namespace in either of two forms, as you can for a tag’s own node id:

Prefer the URI form. A namespace index is a position in the server’s own table, and the index is valid only for the session that reads it. A server can renumber the table. A request that you store, retain, or replay then names a different method, and nothing warns you.

methodName always needs the namespace. A tag’s node id accepts i=85 for namespace 0, but in methodName a value without a semicolon is a plain name. Write a method of namespace 0 as ns=0;i=....

When Edge refuses a request, the log lists node ids in the URI form wherever the server publishes the namespace’s URI. Two exceptions: Edge prints a node id of namespace 0 as i=... without a namespace, and a namespace without a published URI in the index form. Add ns=0; before you use a node id of namespace 0 in methodName.

Address such a method by its full node id. The plain-name spelling does not work for such a method, because Edge reads methodName as a node id whenever the value contains a semicolon.

Only the first semicolon separates the namespace from the identifier. Everything after the first semicolon is the identifier, so nsu=http://vendor.example/Boiler;s=Start;Stop resolves to the method whose node identifier is Start;Stop in that namespace.

On MQTT 5, you can send correlationData and the reply address as properties instead of payload fields:

One mapping setting governs both sources. If you select Requests carry correlation data, Edge reads correlationData from whichever place carries it.

A value present in only one place is the value Edge uses. If both the MQTT 5 property and the payload field carry a value, the two must agree. Edge uses the property’s value and refuses a request whose two sources disagree. A blank Response Topic property carries no value, so Edge then uses the payload field.

A reply address must match exactly, as text. Edge normalizes nothing. Edge does not trim the address, does not fold its case, and does not treat a trailing slash as equivalent. An MQTT topic is a byte string, and a/b is not a/b/.

correlationData must agree, and Edge compares generously. The payload field must be a string. Edge compares that string against the property’s bytes in three forms, in this order:

Any one match is agreement. Edge itself publishes the third form. If you take correlationData from a response and send it back unchanged, it therefore agrees with the property that it came from.

A disagreement is a syntactic error. Edge republishes your request on $invalid/ followed by the topic that you published to, publishes no response, and does not call the device.

A JSON string cannot hold arbitrary bytes. If your correlationData holds arbitrary bytes, send it as the MQTT 5 property alone, and omit the payload field. The rule is that two present values must agree, never that both must be present.

You do not write this schema. Edge generates it from the object’s methods when it verifies the tag.

The schema lists every argument of every method on the object, all optional, and gives each argument a type where it can. Some arguments stay "any value"; the subsections below name them. An argument name that no method declares therefore fails validation before Edge calls the device. The schema cannot express a set of arguments that depends on the method name, so the schema names every argument of every method, unpaired. Every type that the schema states is correct, and the adapter catches a mismatch between an argument and the method that you named.

null is a value, not a way to leave something out. An argument, or a field inside a structure argument, accepts null only where its OPC UA type has a null value: a String, a ByteString, a NodeId or a LocalizedText, for example. Edge then sends that type’s null value to the device. One exception: for a String argument or value on its own, Edge can send only an untyped null, because the OPC UA library inside Edge cannot carry a typed null String. A server that checks argument types can refuse it with Bad_TypeMismatch, as a Siemens S7-1500 does. Inside a structure or an array, a null String keeps its type. An array never accepts null: see Array arguments. Where the type has no null value, Edge refuses null. For a number, a Boolean or a DateTime, the request schema refuses it. For an enumeration or a structure, whose schema states "any value", Edge refuses it when it converts the argument, and publishes the refusal as a response. The same rule holds for an ordinary value write.

Every method argument carries a declared type. The server publishes that type as part of the method’s signature, and Edge reads the type when Edge browses the object.

Edge converts an argument whose declared type is one of the 21 well-known builtin types that OPC UA defines. For each, send this:

Alias names. A server can define its own type as a name for one of the 21. Edge asks the server what the name stands for, and converts the argument accordingly. Duration is a name for Double, measured in milliseconds, so Edge converts a Duration argument and you send a JSON number.

Edge refuses an argument of three kinds of type. Edge does not call the device, and the log names the argument and its type.

A Float or a Double argument takes a JSON number only. If you send "NaN" for such an argument, the request fails the request schema. The response direction differs: see An output that JSON cannot express.

A structure argument is a JSON object, keyed by the structure’s field names, exactly as Edge publishes a structure that it reads from a device.

Use the field names that the server’s own definition gives, and match their case. An analog item’s Range has the fields Low and High.

Send every field that the definition does not mark optional. Edge refuses a structure that omits a required field, and does not choose a value for the field. The device acts on any value that Edge picks. To omit an optional field, leave it out of the object. You can omit optional fields only at the end of the structure: Edge refuses a structure that omits an optional field and gives a later one. A null does not omit a field: it is the field’s null value, as described in The request schema above.

Send no field that the definition does not declare. Edge refuses an unknown field name rather than ignore it. Edge refuses a misspelled "temprature" as an unknown field. Edge does not drop it and send the structure without the temperature that you meant to send.

The request schema describes a structure’s fields, so the shape is checked before Edge calls the device. Some fields stay as "any value" inside that description: a field whose type is an enumeration, a field of a builtin type that Edge accepts in two forms, a field of an abstract type, and a nested structure that Edge cannot resolve. Edge checks them when it converts the argument.

Edge reads a structure’s definition from the server twice. When it browses the method, it reads the definition to describe the argument in the request schema. If that read fails, the schema states "any value" for the argument, and Edge still verifies the tag. When you call the method, Edge reads the definition again to convert the argument. If that read fails, Edge refuses the argument, and the log names it.

An enumeration argument takes three forms, and Edge accepts any of them:

The third form is what Edge publishes for an enumeration inside a structure. You can therefore send a structure that you read from a device back unchanged, unless the structure has a field that Edge cannot send: a field of an abstract type, such as BaseDataType or Structure, or a union field. Edge publishes a plain enumeration (a variable, or a method’s output) as the integer, and accepts the integer back.

On a server that gives the enumeration a definition, Edge refuses a number that the enumeration does not define. The log names the values that the enumeration does define. A device that receives an undefined value can act on it rather than refuse it.

Some servers give an enumeration no definition, typically servers older than OPC UA 1.04. Such a server can still list the enumeration’s names, but Edge does not use that list. Edge then accepts only a number, bare or as value, and accepts any number unchecked.

On a server that gives the enumeration a definition, Edge refuses an object whose two fields disagree. The fields disagree when the enumeration gives the name and the value to different values. Edge resolves the conflict in favor of neither. A caller who changed one field and not the other meant something, and nobody can know which field holds the intent. Send one field, or both fields in agreement. Without a definition, Edge uses value and does not check name.

The request schema states "any value" for an enumeration argument, because Edge’s schema model cannot state a set of permitted values. Edge checks the value when it converts the argument, and publishes a refusal as a response rather than as a quarantine.

If the method declares an argument as an array, send a JSON array. Edge refuses a bare number and does not wrap it for you.

The schema states no array length, whatever the device declares. An OPC UA array dimension is a maximum rather than an exact size, so a declaration of five elements does not mean exactly five. The two directions differ:

Nothing reports an undersized call. Consider a programmable logic controller (PLC) whose method takes a fixed-size array. The missing elements usually keep the values that they held before, which can include the values from your previous call. Send the number of elements that the method expects.

A multi-dimensional array must be rectangular. Every list at the same depth must have the same length, and Edge refuses a request whose lists disagree. The log names the depth and both lengths.

Edge compares lengths per depth, not per parent, which is why the third line is refused.

An array never accepts null, whatever its element type, and neither does a list inside a multi-dimensional array. To send an array with no elements, send []. OPC UA treats a null array and an empty array as the same value, so [] says everything that null would. A device can still refuse [] for an array of fixed length: a Siemens S7-1500 refuses it for an Int32[5] argument with Bad_InternalError, and Edge publishes the refusal as a response. The elements of an array accept null where their type has a null value: ["a", null] is a valid String array.

A server states each argument’s shape as a value rank. Three of the possible ranks do not fix a shape:

For these three ranks, the schema states only "any value", because Edge’s schema builder cannot express "a single value or an array". Edge therefore takes the shape from what you send. If the shape does not match the method’s real signature, the device can refuse the call. Edge then publishes the refusal as a response.

Most arguments do not fall here. A concrete method usually declares a concrete shape, and the schema then describes and checks it.

Edge refuses a request that carries a whole number whose magnitude reaches 2^53, which is 9007199254740992, for an argument of an integer type. The largest whole number that you can send is 9007199254740991. Only the two 64-bit integer types, Int64 and UInt64, have a range that reaches this limit.

Every southbound write, whether a method call or an ordinary value write, passes through the southbound mapping’s field schema validation and transformation. Edge runs this step as JavaScript, and JavaScript holds every number as an IEEE 754 double. As a consequence, an adapter cannot always tell whether a number that it receives is exactly the number in the original MQTT message. For example, if the adapter receives 9007199254740992, the original message contained either 9007199254740992 or 9007199254740993. The OPC UA southbound path is conservative and rejects every whole number that can be the result of rounding: every number greater than or equal to 2⁵³, or less than or equal to -2⁵³. The rule applies to a method argument and to an ordinary value write alike. The rule does not affect floating-point numbers. Other adapters can be more lenient.

Test for errorCode, and for nothing else. If errorCode is present, the call failed. If errorCode is absent, the call succeeded. No success flag exists, and no other field answers the question:

Edge writes correlationData to both the payload field and the MQTT 5 Correlation Data property, on every response to a request that carries it.

If you send both, the property and an agreeing payload field, the response carries the property’s form: the payload field reads base64: followed by the base64 form, not your text.

If you send correlationData as text alone, it comes back verbatim, so you can match it as it stands. If you send it as the MQTT 5 property, the payload field holds it with a prefix. To recover the bytes, strip base64: and decode the rest. An empty correlationData survives the round trip and travels as base64: with nothing after it.

Two facts force this encoding. The Correlation Data property holds binary data, and a JSON string holds text, so the payload cannot carry arbitrary bytes unaltered. Also, the audience of a response is not necessarily the caller, because a request can name any reply address. The subscriber that reads the response can be an MQTT 3 client with no property to read. For such a client, the payload is the only field that it sees.

When statusInfo is present, it holds up to three parts, each only when there is something to report:

If there is nothing to report, statusInfo is absent. The presence of statusInfo does not signal a failure, because the third part appears on calls that succeed.

Edge publishes an output that it cannot decode as null. To read a structure that a method returns, Edge needs the field description for that structure. Edge reads the description from the server. Without that description, Edge publishes that output as null and publishes the rest of the response unchanged. Under the output’s name, the entry in undecodedOutputs carries three things:

An output that Edge cannot decode does not make a call fail. A call that succeeded keeps value and sets no errorCode. A call that the device reported as failed keeps its errorCode. A failed call’s deviceOutput goes through the same decoding. An output listed in undecodedOutputs can therefore be the device’s explanation of why it refused, rather than a method’s result. Edge logs a warning. Edge may read the type description again, for example after the session to the device is re-established, so a later call can decode the output.

A structure that OPC UA itself defines, such as Range or EUInformation, is different. Milo, the OPC UA library inside Edge, decodes it without the server’s description. Edge needs a description only to publish the structure as an object, and takes it from Milo when the server gives none. If Edge cannot use either, for example because it cannot read the server’s type hierarchy, it publishes the output as text: the library’s own rendering, such as Range{low=1.5, high=9.0}. Edge logs a warning, and statusInfo says nothing about it. Such an output arrives as a string where the response schema states an object.

If a Float or a Double output holds a value that JSON cannot express, Edge publishes the output as a string: "NaN", "Infinity", or "-Infinity". The schema states number for such an output, because JSON has no number for these values.

You do not write this schema either. Edge generates the response schema from the object’s methods. The response schema describes the output arguments in the same way that the request schema describes the input arguments.

The schema declares every output nullable, whatever its type, because any output can arrive as null when Edge cannot decode it.

Edge does not validate a response before Edge publishes it. You can validate a response yourself against the response schema.

Edge checks every request before it calls the method. It checks correlationData only if the mapping has Requests carry correlation data selected, and the reply address only if the mapping has Requests carry a response topic selected. These are the syntactic checks:

If any one of these checks fails, Edge quarantines your request. Edge republishes the request on $invalid/ followed by the topic that you published to, and stops. The method does not run, and you get no response, not even on a reply address that you named.

Edge publishes your request to $invalid/, byte for byte. A client that subscribes to that topic receives the request. If no client subscribes, the request is gone. Edge assembles its own view of the request’s fields separately, and attaches that view only to the payload that Edge hands the adapter. Nothing of Edge’s appears in the quarantined copy. The quarantined copy carries no MQTT 5 Response Topic or Correlation Data property. Either property can be the reason for the refusal, so Edge does not copy it.

A request that passes every syntactic check reaches the method. Edge publishes a response to your reply address or to the mapping’s own topic:

The two look the same to you. A refusal that Edge makes carries the same fields as a refusal that the device reports. You can therefore match responses to requests without knowledge of which side failed the request.

In three cases, Edge refuses a southbound write with no response and no quarantine:

For a method call, these three are the only refusals that produce neither a response nor a quarantine, apart from an internal error in Edge. They apply to every other southbound write as well, except that a write to a REFRESH tag never reads the tag’s node id. A value write never gets a response, so no refusal of a value write is reported, whatever its cause.

Read errorCode as a name. It carries the OPC UA status code by name.

If you receive Bad_NotExecutable, your request is correct. Retry it. Executable is a runtime attribute, so the same request can succeed later. A pump that refuses Start while interlocked reports exactly this.

The server can also refuse a call before it reaches the method. These codes are not specific to method calls:

Edge also sends codes itself, without a call to the server:

Transport and session failures reach you unchanged, with the code that the failure carries.

Several causes account for this.

First check whether Edge quarantined your request. Edge then publishes your original payload to $invalid/ followed by the topic that you publish to. To see the payload there, subscribe to that topic before you publish. The log names the check that the request failed: a JSON path for a schema failure, or a named fault for an unpublishable address or a missing method name.

Or the mapping does not read a reply address at all, and the response goes to the mapping’s own topic. Check the southbound Requests carry a response topic setting. A request that carries an address that the mapping does not read is valid, and Edge discards the address.

Or the tag has no northbound mapping, and nothing publishes a response at all.

Or the request met one of the three faults that are not reported.

Or the request arrived while Edge saved the mapping, or while the adapter started. See What a configuration change does to traffic.

Or you configured a Data Hub data policy that applies to the response and drops it. Edge then records the dropped message in its event log, at debug level, with the reason Policy prevented onward delivery of inbound PUBLISH.

What happens to a method call while its adapter restarts is unspecified.

We believe that this list of causes is complete, but we can have missed further corner cases.

The OPC UA adapter writes a lifecycle line whenever its condition changes. Edge writes each line to the log and publishes it as an event in the event log, with the same text. Every line has four parts, separated by a semicolon and a space:

The last lifecycle line of an adapter tells you what works now. A connected adapter is not yet ready for method calls: Edge reports the connection first and reads the method signatures afterwards. When you see a line like this one, method calls are ready:

A start in bad weather can look like this. The device is unreachable at first, and the adapter retries by itself. It then connects, but cannot read the methods of the tag valve. Later the session to the device is lost:

The schema check needs the tag’s generated schema, and Edge resolves that schema while the adapter starts. A device that has not responded yet has no schema to give. Edge then registers an empty schema and logs the fact:

Edge shall resolve the schema again when you restart the adapter. The rule applies to every tag kind, not only to method tags.

An empty schema constrains nothing, so a valid request passes the schema check. Edge still refuses an invalid request, but the adapter makes the refusal, so Edge publishes a response instead of a quarantine:

Edge’s own syntactic checks are unaffected, and so is the schema on your topic filter. A missing method name and an unpublishable reply address come from the request itself, not from the tag’s schema. Edge therefore still quarantines those faults.

This section describes what happens today. It is not a promise.

Any configuration change can restart the adapter, so what this section describes applies to any configuration change, not only to an explicit restart.

While Edge saves a mapping, requests that you publish to that mapping go nowhere. When Edge saves a southbound mapping, Edge removes the mapping’s subscription and registers it again, before it resolves the tag’s schema. A request that arrives before the subscription exists again matches no subscription, and Edge discards the request. Edge publishes nothing to $invalid/ and logs nothing against the request. A request that arrives while Edge resolves the schema waits, and Edge processes it once the mapping is ready.

The same holds while an adapter starts. Until Edge registers a method tag’s subscription, requests to its topic reach no subscription: the broker accepts the requests and Edge drops them.

If a request must not be lost, do not publish into a configuration change.

A response that you do not ask for can also arrive. A response goes to a topic like any other message, so every subscriber to that topic can receive it. Such subscribers include a subscriber that connects after the request, and every northbound mapping that you configure for the tag. After a configuration change, Edge can publish a response to an earlier request again. If a caller correlates by correlationData and matches responses to its own requests, such responses do not affect the caller.

How strictly the adapter validates the certificate an OPC UA server presents is configured through exactly one of two mutually exclusive settings:

Setting both is a configuration error and the adapter refuses to start. If you already know your environment, Choosing a configuration maps it straight to the right setting.

From version 2026.13 onwards, tlsChecks additionally accepts SELF_SIGNED and NO_VERIFICATION, and tlsChecksFull, allowList and revocationList are available. Earlier versions offer only the NONE, APPLICATION_URI, STANDARD and ALL presets.

Nothing changes when you upgrade, and there is no migration to perform. Setting neither is the same as tlsChecks=STANDARD. The NONE, APPLICATION_URI, STANDARD and ALL values keep exactly the meaning they have always had. An existing configuration therefore validates certificates after the upgrade precisely as it did before. No configuration file needs editing and nothing is rewritten. The two new values, SELF_SIGNED and NO_VERIFICATION, and the tlsChecksFull axes only take effect where an operator asks for them.

tlsChecksFull exposes the six axes the presets are built from. Every axis is optional, and an omitted axis takes its strictest value. An empty tlsChecksFull therefore means maximum validation, and every relaxation is a visible, deliberate entry in the configuration file.

Revocation asks one question: has this issuer withdrawn this certificate? Only the issuing CA can answer it, and it answers by publishing a certificate revocation list. The adapter is given that list through the <revocationList> element:

The path may be a single CRL file or a directory of them, in PEM or DER. A PKI that publishes one CRL per issuing CA is the common case, so pointing at a directory avoids concatenating them by hand. Every CRL under the path applies to whichever issuer signed it.

Like the fingerprint allow-list, the file is read once when the adapter starts and never written, so it can be a read-only artifact. Refreshing a CRL means restarting the adapter.

A refused connection carries an OPC UA status code. A failed trust decision reports Bad_SecurityChecksFailed, and the specific cause is in the message that accompanies it. A failed identity or hygiene check reports its own status code instead. The first row is the exception: it arrives before any certificate has been seen at all.

Factory networks often have no CA. Every device presents its own self-signed certificate, which chains to nothing a public CA bundle knows about.

Chain validation is not impossible in that situation. A self-signed certificate placed in the truststore is its own trust anchor, so trustMode=CHAIN will accept it. What that costs is a truststore holding one certificate per machine, exported from each device and redistributed to every HiveMQ Edge instance whenever a device is replaced or its certificate rotated.

Fingerprints are the lighter answer to the same problem. Instead of a trust anchor, the adapter can be given the SHA-256 fingerprints of the specific certificates it should accept. A fingerprint is short enough to send by email or read out over the phone, and it deploys as a read-only file.

The allow list is a plain text file. It holds one fingerprint per line, in hexadecimal, with : separators optional and case ignored. A # starts a comment.

tlsChecks=NO_VERIFICATION accepts whatever certificate a server presents, without establishing any trust in it:

Individual checks can still be switched back on through tlsChecksFull. The following accepts any certificate but insists it carries the expected ApplicationUri:

The address for tags can be found in TIA Portal in the Address column of the PLC Tags table . For PLC tags, this value can be used as it is directly in HiveMQ Edge.

If you cannot get the addresses directly from TIA Portal, you can use the following format to construct the address:

Format for bit addresses:

Format for byte addresses

Example: %I205.0 or ´ %QB207

Where the Memory-Area-Code is one of I(Inputs), Q(Outputs), D(Direct peripheral access), M(Markers), C(Counter), T(Timer), DB(Data block).

And Memory-Size-Code describes the size of the variable value. The codes are X(1 bit or 8 bytes), B(1 byte), W(2 bytes), D(4 bytes).
For detailed information on which code maps to which type, see S7 Types.

The data block addressing scheme is:

%DB<Data-Block-Number>:<Byte-Offset>.<Bit-Offset>

%DB<Data-Block-Number>:<Byte-Offset>

Example: %DB10:20.0 or %DB10:22

The Data-Block-Number is displayed in the tree view on the left in your TIA Portal, behind the name of your data block, enclosed in [] brackets or on the top of the data block view.

The Byte-Offset (and Bit-Offset) can be found in TIA Portal in the Offset column in the data block view

The setting for optimizing block access can be found in the properties of the data block in TIA Portal.