Client Libraries in other Languages
Closed this issue · 5 comments
I'd like to use node.js for my brewblox services & plugins. Is there an API spec to be able to publish / emit events or any plans to have other clients in other languages?
Apart from "runs in Docker container", we have no hard requirements for services.
https://github.com/BrewBlox/brewblox-automation/ is written in Node.js / TypeScript. You could draw examples from there.
If you want to publish data, this is the spec: https://brewblox.netlify.app/dev/reference/event_logging.html
@steersbob Awesome! I'm more into the coding side of things and have 0 experience with these types of hardware systems. I just love brewing and want to bring in some sort of automation into my system & future systems. :). Great work.
I have so many questions regarding hardware side and it's pretty hard to figure it all out without being too annoying I suppose.
My first one, it being unclear, is if I could set this all up without a BrewPi Spark and just a Raspberry Pi 3 or 4 + Brewblox on local docker cluster or synology nas.
My first one, it being unclear, is if I could set this all up without a BrewPi Spark and just a Raspberry Pi 3 or 4 + Brewblox on local docker cluster or synology nas.
Yes. We also have a simulation mode for the Spark, so for development work you don't even need that.
Feel free to send me a message if you want an invite to the Slack channel.
@steersbob Email sent :)
We don't support using GPIO pins of the pi. That's because the Spark is not just toggling pins, it also runs all the control algorithms: PIDs, filtering, sensor reading, hardware driving, etc.
This is a deliberate design choice: we want the control to run on an embedded system that only runs our control firmware. That way we can guarantee stability.
The Spark is fully autonomous to keep the temperatures in control. It doesn't depend on a network connection, the pi, or anything else to regulate the temps.
The pi is used as a server for data logging, serving the UI, and high-level automation.
We want process control to be as close to the hardware as possible, without external dependencies. This means a central server for high-level stuff, and one or more low level embedded devices for critical control.
Our big picture for future hardware is still a central server connected to multiple smart hardware nodes. These hardware nodes are autonomous for low-level control. They push data to the server and get new settings from the server. But the server is not part of the control loop.
At home I don't use a pi, but run the server on my Synology. The Spark is still part of the system. The NAS replaces the pi.
For your automation needs, perhaps the javascript sandbox provided by the automation service is already sufficient.