Can Busloom import any vendor PDF automatically?

No. Register maps vary too much to make unattended interpretation trustworthy. Normalize the table, import structured data, and verify it against the device.

What belongs in a public device definition?

Reusable model data such as groups, tags, addresses, types, units, source limits, and authoritative references—not site-specific connection settings.

Should an import overwrite tags I already edited?

Only through an explicit merge choice. The preview should identify additions, updates, and conflicts so local work is never replaced silently.

How to turn a vendor register map into a reusable Busloom project

Normalize each row before importing

For every value, capture the source table and revision, function or address space, printed address, zero-based PDU offset, register width, data type, byte/word order, scale, offset, unit, access, and notes. Never discard the original notation; it is how another engineer traces the project back to the manual.

Calculate the zero-based register address

Build sources around safe contiguous reads

Group adjacent values only when the complete range is documented and within the device's request limit. Respect holes, access boundaries, and firmware-dependent registers. Keep tags grouped by machine meaning rather than reproducing every PDF page as one oversized table.

Commission the import against hardware

Start with one known stable value and inspect the raw response. Verify a second value that changes in a controlled direction. Check a boundary at the end of every source range. Only after those checks should the project or public device definition be treated as reusable.

A public definition should contain the model's register map, not installation-specific serial ports, IP addresses, Unit IDs, TLS keys, or credentials.

Clean the source without losing provenance

Vendor spreadsheets often use merged headings, blank continuation rows, hexadecimal offsets, repeated units, and footnotes that alter the meaning of a whole range. Flatten those presentation features into explicit columns, but retain the document name, revision, page or sheet, and original printed address. A normalized row should always be traceable back to the source.

Resolve ambiguous cells before bulk import. A blank access field may mean inherit from the group, unknown, or not applicable. A width of two may mean two registers or two bytes. Record the decision rather than letting an importer guess silently.

Separate reusable model data from project data

The reusable definition should describe what the model exposes: address space, PDU address, register count, data type, order, scale, unit, name, group, access, limits, and notes. The project should describe this installation: port or host, Unit ID, certificates, polling intervals, site naming, selected views, and alarms.

This split lets a public definition be updated without publishing customer endpoints or overwriting local choices. Import should copy reviewed metadata into the project through a visible merge, not create a permanent hidden dependency on a remote catalogue.

Preview additions and updates
Never delete local tags silently
Show address and type conflicts
Keep connection profiles project-specific
Record the imported definition version

Review the map as code and as live data

First review the structured diff: unexpected address shifts, duplicate names, overlapping multi-register values, unsupported types, missing units, and changed source limits. Then review the live device: one stable value, one deliberately changing value, source boundaries, and any wiring-mode or firmware-dependent groups.

A definition is ready to share when another person can trace every important field to a source and reproduce the verification steps. Corrections should update the definition version and source notes. Site-specific exceptions belong in the consuming project unless they reveal a genuine model or firmware variant that the public catalogue should represent.