Block-based and/or custom numbering

[jacoscaz]

From @veodko's comment on #26:

As for the numbering use case, I've seen actual BACnet devices often follow this pattern of numbering objects in "groups" that reserve space for any future updates of the object list.

So something like:

Configuration block 1

AV1001
AV1002
AV1003

Configuration block 2

AV2001
AV2002
AV2003

this allows easy future updates when you know new objects could be added in the future. Prevents shifting current instance numbers (let's say some clients rely on them, that would cause troubles) and keeps things organized.

Technically, this could also be addressed by allowing users to choose their own numbering. However, having to maintain numbering turned out to be a minor hindrance during preliminary testing. Perhaps best way forward is to make block-based numbering the default while allowing users to optionally provide their own numbering.

[jacoscaz]

Note that custom numbering is also being asked for in #28 .

[wz2b]

Thank you — I appreciate it. Automatic numbering was a great addition, but there are still cases where fully static instance numbering matters for interoperability and long-term stability. Part of my interest in explicit numbering is to guard against unintentional changes over time.

If I understand the “block” idea correctly, it seems like a constrained automatic mode. I think that is a good idea too. PostgreSQL has a somewhat similar concept (as does Oracle):

CREATE SEQUENCE av_seq
  START WITH 1000
  INCREMENT BY 10;

In your case it would need to be per object type, which makes it a bit more specialized.

That said, block-based numbering feels more complex than what I would do. My choice would be:

1. allow the user to set the instance ID explicitly when needed
2. optionally provide a helper interface/callback for custom numbering strategies
3. if the user doesn't set one themselves, fall back on a default instance number generator implementation that mimics what auto numbering does today

That way the common case stays simple, but more advanced autonumbering use cases are still possible without this library having to grow built-in support for every numbering scheme.

For example, a user might want:

• reserved ranges by configuration group
• only even or odd instance IDs
• increments of 10 or 100
• numbering derived from an external mapping or existing site standard
• numbering that's looked up from some custom configuration data

If custom numbering is delegated to user code, then the library does not need to keep revisiting special cases like these.

If you want help implementing this please ask.

[jacoscaz]

@veodko @wz2b if you are in a position to test, could you please have a look at #31 ? Example file at https://github.com/bacnet-js/device/blob/e27725dd052aef54147e5f39dd2b69871d7790c4/src/examples/12-object-numbering.ts .

As suggested by @wz2b , I've added the option of passing a BDObjectNumberProvider implementation to BDDevice to give consumers as much freedom as possible when it comes to numbering patterns.

[wz2b]

Sure can, but not until the weekend.