I can’t speak for what @j616s is or isn’t planning, but last I heard, the biggest issue was finding some free time for development.
We have tooling for both backend services and UI plugins. The latter is still experimental.
Feel free to PM me if you have any questions, or would like an invite to the Slack channel.
Yeh. Anything beyond the current graphing/metrics is waiting for me to have time/drive to do it as the integration is just a spare time project for me.
If you’re talking about driving the fermentation process using the tilt, that goes against the design ethos of keeping everything that does that on the micro-controller for reliability. In theory, the tilt service could poke the APIs that change setpoints etc. But I’m not certain the tilt & its bluetooth connection is reliable enough to trust with that. The older models at least struggle to get through a single brew in a stainless fermenter. The new ones may be better in that regard. And there may be fallback schemes you could use so the unreliability of the sensor isn’t a problem. But, as I say, that needs development time.
Thanks for the info. I tried to PM you about slack but it said I’m not allowed to message you.
I fully understand. I had originally considers using the tilt for temperature but decided the drop outs in signal will be too problematic.
My plan is just to make a single simple controller that will work with a temp sensor and tilt together.
The Spark does not have Bluetooth, so it is better to let a pi handle that. We will probably include Bluetooth on a future hardware revision, but this will not be on the particle platform.
I’d be interested in working on this - I’d really like to have my Tilt output temperature and gravity measurements. Then, the temperature can be used in place of the 1-wire sensor for the beer temperature (in the slower PID loop, keeping a hardwired sensor for the fridge temp in the faster loop), and the gravity can be used to drive a fermentation schedule.
Do you have any guidance on writing plugins, or pointers to where I can find existing code to start from? The plugin and boilerplate repos are very barebones, leaving me wondering at least:
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:
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.
I’d heavily advise against using the Tilt’s temp to drive ferm schedules. In my experience, the Tilt is nowhere near reliable enough. I still think triggering progression through steps based on SG is useful as long as there’s a method of triggering manually as backup. After all, some method of measuring SG is better than no method. But the wired sensors are far better at the job of reading temp.
I second the opinion against using the Tilt temperature or SG as input to fermentation control, for these reasons at minimum:
Havin an issue where data is not being shown on the tilt service.
tilt_1 | 2020-02-14T12:35:27.504683562Z 2020/02/14 12:35:27 ERROR brewblox_tilt Error when publishing data ConnectionRefusedError(111, "Connect call failed ('172.17.0.1', 5672)")
Any suggestions
Initial errors seem normal: it complains until the eventbus is done starting up. Does it also not send data after that?
Yep and the errors keep on going.
Its the same on my setup as well as the one I posted earlier. I’ll post new logs from each of them so you can see.
Oh, I think I get it. Tilt is running host mode, and need an eventbus port published. That’s an edit in a file we just reset.
Try adding the docker-compose.override.yml file, with content:
services:
eventbus:
ports:
- "5672:5672"
Could you please run docker-compose config? That should show if it correctly interpreted the override.
After that, you can also fix it by setting the ports config entry in docker-compose.shared.yml
This will break next update, unless you update with --no-copy-config
Edit: the best solution is to edit docker-compose.yml, and add the following entry under services:
(indented two spaces)
eventbus: { ports: ["5672:5672"] }
So looks like its not being interpreted correctly.
Output of docker-compose config.
I’ll add it to the other file. and let you know.
datastore:
image: treehouses/couchdb:2.3.1
labels:
traefik.frontend.rule: 'PathPrefixStrip: /datastore'
traefik.port: '5984'
restart: unless-stopped
volumes:
- /home/pi/brewblox/couchdb:/opt/couchdb/data:rw
emitter:
image: brewblox/brewblox-emitter:rpi-edge
labels:
traefik.frontend.rule: 'PathPrefix: /emitter'
traefik.port: '5000'
restart: unless-stopped
eventbus:
image: arm32v6/rabbitmq:alpine
restart: unless-stopped
history:
image: brewblox/brewblox-history:rpi-edge
labels:
traefik.frontend.rule: 'PathPrefix: /history'
traefik.port: '5000'
restart: unless-stopped
influx:
environment:
INFLUXDB_DATA_INDEX_VERSION: tsi1
INFLUXDB_DATA_WAL_FSYNC_DELAY: 1s
INFLUXDB_HTTP_LOG_ENABLED: "false"
INFLUXDB_LOGGING_LEVEL: warn
image: influxdb
restart: unless-stopped
volumes:
- /home/pi/brewblox/influxdb:/var/lib/influxdb:rw
mdns:
command: --port=5000
image: brewblox/brewblox-mdns:rpi-edge
network_mode: host
restart: unless-stopped
spark-one:
command: '--name=spark-one --mdns-port=5000
'
depends_on:
- datastore
- eventbus
image: brewblox/brewblox-devcon-spark:rpi-edge
labels:
traefik.frontend.rule: 'PathPrefix: /spark-one'
traefik.port: '5000'
privileged: true
restart: unless-stopped
tilt:
command: -p 5001 --eventbus-host=172.17.0.1
depends_on:
- history
image: j616s/brewblox-tilt:rpi-latest
network_mode: host
privileged: true
restart: unless-stopped
volumes:
- /home/pi/brewblox/tilt:/share:rw
traefik:
command: '-c /dev/null --docker --docker.domain=brewblox.local --entrypoints=''name:http
Address::80 Redirect.EntryPoint:https'' --entrypoints=''name:https Address::443
TLS:config/brewblox.crt,config/brewblox.key'' --defaultentrypoints="http,https"
'
image: traefik:v1.7
ports:
- 80:80/tcp
- 443:443/tcp
restart: unless-stopped
volumes:
- /home/pi/brewblox/traefik:/config:rw
- /var/run/docker.sock:/var/run/docker.sock:rw
ui:
image: brewblox/brewblox-ui:rpi-edge
labels:
traefik.frontend.rule: Path:/, /ui, /ui/{sub:(.*)?}
traefik.port: '80'
restart: unless-stopped
version: '3.0'
Ok so worked in the other file. However I cannot check any of the items in the list, including the Spark-one items. As you can see they have all unticked themselves.
We pushed a fix for that a few hours ago. Run docker-compose pull to get it.
Thanks Bob, That’s working now.
Great support as usual.
