You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of 1.53, it is possible to load additional device integrations into TSR as 'plugins'. This is intended to be an escape hatch when you need to make an integration for an internal system or for when an NDA with a device vendor does not allow for opensourcing. We still encourage anything which can be made opensource to be contributed back.
4
+
5
+
## Creating a plugin
6
+
7
+
It is expected that each plugin should be its own self-contained folder, including any npm dependencies.
8
+
9
+
You can see a complete and working (at time of writing) example of this at [sofie-tsr-plugin-example](https://github.com/SuperFlyTV/sofie-tsr-plugin-example). This example is based upon a copy of the builtin atem integration.
10
+
11
+
There are a few npm libraries which will be useful to you
12
+
13
+
-`timeline-state-resolver-types` - Some common types from TSR are defined in here
14
+
-`timeline-state-resolver-api` - This defines the api and other types that your device integrations should implement.
15
+
-`timeline-state-resolver-tools` - This contains various tooling for building your plugin
There are a few key properties that your plugin must conform to, the rest of the structure and how it gets generated is up to you.
29
+
30
+
1. It must be possible to `require(...)` your plugin folder. The resuling js must contain an export of the format `export const Devices: Record<string, DeviceEntry> = {}`
31
+
This is how the TSR process finds the entrypoint for your code, and allows you to define multiple device types.
32
+
33
+
2. There must be a `manifest.json` file at the root of your plugin folder. This should contain json in the form `Record<string, TSRDevicesManifestEntry>`
34
+
This is a composite of various json schemas, we recommend generating this file with a script and using the same source schemas to generate relevant typescript types.
35
+
36
+
3. There must be a `translations.json` file at the root of your plugin folder. This should contain json in the form `TranslationsBundle[]`.
37
+
This should contain any translation strings that should be used when displaying various things about your device in a UI. Populating this with translations is optional, you only need to do so if this is useful to your users.
38
+
39
+
:::info
40
+
If running some of the `timeline-state-resolver-tools` scripts fails with an error relating to `cheerio`, you should add a yarn resolution (or equivalent for your package manager) to pin the version to `"cheerio": "1.0.0-rc.12"` which is compatible with our tooling.
41
+
:::
42
+
43
+
## Using with the TSR API
44
+
45
+
If you are using TSR in a non-sofie project, to load plugins you should:
46
+
47
+
- construct a `DevicesRegistry`
48
+
- using the methods on this registry, load the needed plugins
49
+
- pass this registry into the `Conductor` constructor, inside the options object.
50
+
51
+
You can mutate the contents of the `DevicesRegistry` after passing to the `Conductor`, and it will be used when spawning or restarting devices.
52
+
53
+
## Using with Sofie
54
+
55
+
In Sofie playout-gateway, plugins can be loaded by setting the `TSR_PLUGIN_PATHS` environment variable to any folders containing plugins.
56
+
57
+
It is possible to extend the docker images to add in your own plugins.
58
+
You can use a dockerfile in your plugin git repository along the lines of:
59
+
60
+
```Dockerfile
61
+
# BUILD IMAGE
62
+
FROM node:22
63
+
WORKDIR /opt/tsr-plugin-example
64
+
65
+
COPY . .
66
+
67
+
RUN corepack enable
68
+
RUN yarn install
69
+
RUN yarn build
70
+
RUN yarn install --production
71
+
72
+
# cleanup stuff we don't want in the final image
73
+
RUN rm -rf .git src
74
+
75
+
# DEPLOY IMAGE
76
+
FROM sofietv/tv-automation-playout-gateway:release53
0 commit comments