Disclaimer: what you are proposing has significant reliability issues. Any network calls in the input/process/output loop are points of failure. So far the Tilt’s bluetooth connection has proven especially fickle.
That said, we also recommend doing whatever you like in your own code =)
Your proposal requires both a backend service, and a UI plugin.
The service would be responsible for reading the Tilt, and writing to the Spark service. (Anything that must continue happening when you close the UI). You can also split reading/writing between @j616s service, and yours.
The UI plugin can be used to configure your service.
The service can register REST endpoints that are reachable from both the UI, and other backend services. You make them accessible from the UI by declaring a PathPrefix label in your docker-compose.yml so the Traefik service can forward http requests.
You can also send block updates to the REST API of the Spark service. To view the spec for the Spark API, go to https://<pi_address>/spark-one/api/doc.
This same endpoint is reachable from your service as http://spark-one:5000/spark-one/api/doc.
The client code for the Spark can be found here:
To consume data from your service in your UI plugin, you have three options:
- publish data to the eventbus, and view in graph/metrics widgets.
- this is useful for values, less so for configuration, and useless for strings.
- poll the backend service every few seconds / manually.
- simple, but clunky.
- implement an SSE endpoint in your service endpoint.
- nicer than polling, but more complicated.
Personally I’d first build a polling version, and maybe switch to SSE somewhere down the line.
The block you’re interested in would be https://github.com/BrewBlox/brewblox-ui/blob/develop/src/plugins/spark/features/TempSensorMock/types.ts.
A typical update is to read the block, set the data/value property, and write the changed block.