Skip to content

Unify driver send()/run_sequence() and add a transmit priority - #161

Open
markus-becker-tridonic-com wants to merge 2 commits into
sde1000:masterfrom
tridonic-com:driver-send-priority
Open

markus-becker-tridonic-com wants to merge 2 commits into
sde1000:masterfrom
tridonic-com:driver-send-priority

Conversation

@markus-becker-tridonic-com

Copy link
Copy Markdown

What

Collapse the two driver entry points — send() (one frame) and run_sequence() (a sequence) — into a single send() that accepts either a bare Command or a sequence, and add an optional transmit priority.

This implements the driver-API changes we discussed: EnableDeviceType belongs in the driver, one method runs both commands and sequences, and priority is chosen by the caller's intent (IEC 62386-101 Table 22 / 103 §9.14) rather than guessed from the command class.

Details

  • One method. send(msg, *, priority=5, progress=None) wraps a bare Command in a trivial one-shot sequence and runs it through the same transaction loop, so a single command still returns its Response. The per-frame transmit is now the private _send_frame(cmd, *, priority).
  • EnableDeviceType in the driver. The loop auto-prefixes EnableDeviceType for any command with a non-zero device type — now for bare commands too, not just sequences. This removes the need for trivial device-type wrapper sequences.
  • Transmit priority. priority must be in 2..5 (anything else raises ValueError, as requested). The first forward frame of the transaction goes at that priority and every subsequent frame at priority 1, forming a 101 §9.3 transaction. For LUBA this replaces the old class-based isinstance() guess with the caller's value on the wire; SCI has no wire priority field, so it accepts and ignores it. HID dongles transmit at a fixed priority, so there it is validated but has no wire effect.
  • Back-compat. run_sequence() stays as a deprecated alias of send() emitting DeprecationWarning.
  • Scope. Applied to the serial drivers (LUBA, SCI) and the HID base (tridonic/hasseb). The legacy sync/async drivers in dali/driver/base.py, tridonic.py, usb.py, hasseb.py are intentionally untouched.

Tests

dali/tests/test_dummy.py gains coverage via the serial fake (which now records (command, priority) per frame): bare-command EnableDeviceType auto-prefix, no prefix for device-type 0, priority rejection outside 2..5, priority acceptance for 2..5, first-frame-priority / continuation-priority-1, and the run_sequence deprecation warning. Full suite: 123 passed.

The serial DriverSerialBase previously had both a per-frame send() and a
run_sequence() that drove a sequence generator. These collapse into a
single send() that accepts either a bare Command or a sequence: a bare
Command is wrapped in a trivial one-shot sequence and runs through the
same transaction loop, so a single command still returns its Response.
EnableDeviceType auto-prefixing for non-zero device types now happens in
that one loop, covering bare commands as well as sequences, which removes
the need for trivial device-type wrapper sequences.

send() takes an optional priority (IEC 62386-101 Table 22, values 2..5;
anything else raises ValueError). The first forward frame of the
transaction is sent at that priority and every subsequent frame at
priority 1, forming a 101 §9.3 transaction. For LUBA this replaces the
old class-based isinstance() priority guess with the caller's intent
(see 103 §9.14); SCI has no wire priority field, so it accepts and
ignores the value. The per-frame transmit is now the private
_send_frame(cmd, *, priority).

run_sequence() stays as a deprecated alias of send() so existing callers
keep working with a DeprecationWarning.
Mirror the serial driver change in the hid base class shared by the
tridonic and hasseb USB masters: send() now accepts a bare Command or a
sequence, wrapping a bare Command in a trivial one-shot sequence and
running everything through one transaction loop that auto-prefixes
EnableDeviceType. run_sequence() becomes a deprecated alias of send().

send() validates priority against the IEC 62386-101 Table 22 range 2..5
(raising ValueError otherwise) for a uniform driver API, but HID dongles
transmit at a fixed priority, so the value has no effect on the wire.
The CommunicationError retry behaviour and the exceptions_on_send
override are preserved per frame.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant