This is a TypeSpec library for defining eBUS messages on a high level.
It comes with decorators for the eBUS specific aspects of circuits, messages, fields and data transfer, as well as eBUS specific data types.
Once a message is declared in a typespec file, it can be converted to ebusd CSV format using an emitter.
This library is also used for generating ebusd message configuration files.
This is a short overview of the decorators offered by the library:
- source address
QQ:@qq(QQ) - target address
ZZ:@zz(ZZ) - message ID
PB,SB,ID*:@id(PB, SB, ID*)
when using inheritance:- base ID:
@base(PB, SB, ID*) - ID extension:
@ext(ID*) - inheritance: ``@inherit(...)`
- base ID:
- message chaining:
@chain(...) - message direction:
@write,@passive - message condition(s):
@condition(model, values) - message authorization:
@auth(level) - field location:
@in,@out - field divisor/factor:
@divisor(number),@factor(number) - field value list:
@values(...) - field unit:
@unit(...)
All the standard eBUS base data types like UCH etc. are available in the Ebus types namespace under:
Ebus.Num: numeric+bit typesEbus.Str: string types including hex sequenceEbus.Dtm: date/time type
The identification message is available in the Ebus model namespace under:
Ebus.Id: read/write/broadcast versions of identification message
The CSV emitter is available as with the following parameters:
It can be used via tsp compile --emit @ebusd/ebus-typespec <tsp files>.
Here is a small example of a message carrying just a single byte:
import "@ebusd/ebus-typespec";
using Ebus;
using Ebus.Num;
@zz(0x08)
@id(0x01, 0x02)
model Message {
field1: UCH,
}This fits to an eBUS byte sequence like this
ff08010200 / 0105
that transfers the Message from source 0xff where the target 0x08 replied with a value of 5 for field1.
This library also provides the following scripts via npm:
tsp2ebusd: converts TypSpec file(s) or stdin to an ebusd CSV file or stdout and can also send the output directly to an ebusd instance having the "--define" feature enabled.
See here for the documentation generated from the source.
Following the TypeSpec style guide with these additions/exceptions:
- template models are supposed to be in camelCase (instead of PascalCase), e.g.
model tempSensor {temp: UCH, sensor: UCH}
- default models (inherited from by "real" models) are supposed to be in camelCase (instead of PascalCase), e.g.
versus a "real" model, e.g.
@base(8, 9) model r {}
@inherit(r) @ext(1, 2) model Temperature { value: UCH, }
- the name of value lists in
enumis supposed to begin withValues_followed by the name of the message or field referring to, e.g.enum Values_manufacturer {...}
- due to absence of an option to include models in a namepsace from another namespace, the construct for inclusion is putting these namespaces into a union named
_includes:union _includes { NamespaceModelName, // <= unnamed entry inlines the referenced definition or emits an "!include" instruction (if includes is set in the emitter options) _include: NamespaceModelName, // <= entry with a name starting with "_include" explicitly emits an "!include" instruction named: NamespaceModelName, // <= named entry emits a !load instruction (if name does not start with "_include") // etc. }