Busloom 0.4.0: alarms, discovery, reports, and protocol diagnostics

Discovery now searches the network, not one guessed endpoint

TCP network discovery checks every usable address in a bounded IPv4 subnet. It combines the local neighbour table with active probing and treats ports independently, so the result is a concrete list of Modbus endpoints in IP:port form rather than a list of machines that might be relevant.

The same workflow covers open TCP and Modbus/TCP Security endpoints. A TLS certificate that is not trusted by the current profile no longer makes a listening Modbus device disappear from discovery; trust is resolved when the operator chooses to connect.

RTU discovery received the matching treatment. A scan can cover explicit baud-rate, parity, data-bit, stop-bit, and Unit ID ranges with an estimated request count, deterministic results, progress, and cancellation.

• Every confirmed TCP or TLS result includes its IP address and port.
• The active endpoint is visually distinguished from other results.
• A discovered endpoint can be applied directly to the connection profile.
• RTU scanning has no arbitrary probing cap; the selected range is the limit.

Alarms belong to tags, while alarm state belongs to the session

A tag can now carry high, low, or exact-state alarm rules. Numeric rules support clearing hysteresis, every rule can require a continuous activation delay, and evaluation uses the same decoded engineering value shown in register tables and Trends.

The Tag alarms diagnostic separates pending, active, acknowledged, and cleared events. Acknowledging an alarm records that an operator saw it; it does not pretend the condition has cleared. Transition history stays bounded and session-local, so monitoring does not silently turn the project file into a historian.

Alarm evidence can be exported explicitly as JSON. No alarm writes to the device, starts automation, or sends a notification behind the operator's back.

• Create alarms from a register context menu or the dedicated Add alarm flow.
• Use decoded numeric and boolean values instead of raw presentation strings.
• Acknowledge individual alarms or the current active set.
• Export the transition history for later analysis or test evidence.

Trend windows can leave a presentation-ready report

Machine-readable exports are still available, but they are not always what belongs in a commissioning report. The selected 1 minute, 5 minute, or Session Trend window can now be rendered directly to PNG or a single-page PDF.

The report carries the visible series, colours, engineering units, observed ranges, time bounds, project and non-secret device context, plus alarm activity from the same window. Each series keeps its own observed range, matching the normalized live chart instead of implying that unlike units share an axis.

• PNG for tickets, chat, and quick evidence.
• PDF for reports and handover documents.
• The exported window is the window currently visible to the operator.
• File writes use the same bounded, native artifact boundary as other Busloom exports.

Protocol Diagnostics exposes the server functions normal tables do not

The new Protocol Diagnostics workbench covers safe FC08 diagnostics, FC11 and FC12 communication-event data, FC17 server identification, and confirmed FC22 mask writes across RTU, TCP, and TLS.

Results are decoded into named fields without hiding the evidence. Each operation retains its latency, attempt count, exact TX frame, and exact RX frame, while Raw Traffic and Connection Health use the same specialist function names.

State-changing FC08 subfunctions are intentionally excluded. FC22 follows the profile's read-only policy and requires an explicit write confirmation.

The first public device definition is available

Busloom can now browse the public busloom-devices catalogue and import a reviewed register map through the existing definition preview. The first entry is the Eastron SDM630-Modbus V2 three-phase energy meter.

The catalogue is data-only. It cannot supply endpoints, credentials, certificate material, automation, or executable code. Importing a definition creates an ordinary unsaved project edit; after Apply, the project remains self-contained and works offline.

• Definitions are grouped by manufacturer in a public Git repository.
• Every import is validated, previewed, and applied explicitly.
• A catalogue refresh never mutates an existing project in the background.
• The repository is ready for additional reviewed manufacturer maps.

Unit ID 0 is available where a device actually needs it

Connection profiles now accept Unit IDs from 0 through 247 over RTU, TCP, and TLS. This is useful for gateways and non-standard devices that expose address zero as a request/response endpoint.

RTU discovery still probes addresses 1 through 247. In standard Modbus RTU, address zero is broadcast and a compliant device does not reply, so showing it as a discoverable slave would produce a misleading workflow.