I am using the tilt service now for the first time and it looked promising at first. But two days ago it stopped logging. I thought maybe the battery was empty but after doing a brewblox-ctl down and up it worked again. What can cause this? And is there a way to reboot only the Tilt service instead of the whole brewblox?
‘docker-compose restart tilt’ assuming tilt is the name of the service.
As of why the restart us needed, @j616s can hopefully help with that.
docker restart brewblox_tilt_1 is the command you want, Ithink
As for the issue, when did you last update? I pushed a fix for needing restarts about 2 weeks ago that seems to have sorted things on my end
I think I am using the last version, I installed it 1,5 week ago I think.
Updating is done with brewblox-ctl update right?
That is how you update, yes.
Is there anything useful in the logs?
docker logs brewblox_tilt_1
I’ll check this evening. I didn’t get SSH working over VPN so I can’t check at work 
What is stopping this from being used for more than just graphing?
I’m looking into creating a spark style controller using something like the particle argon to interface with one wire sensors, relays and the tilt.
Thanks
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:
- How do I create a plugin with output ports that can be connected to other plugins’ input ports?
- Can plugins produce and consume data on the RPi (eg, could you have an output port and an input port that don’t correspond to blocks sent to the Spark)? If so, what’s the API for generating and consuming this data? And example would be the Tilt having an output port that reports the SG measurement, and a modified fermentation schedule plugin having an input port for that.
- How can a plugin specify a dummy temperature sensor that will be loaded onto the spark, and how can the value for that sensor be updated when new readings are available?
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.
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.
1 Like
I second the opinion against using the Tilt temperature or SG as input to fermentation control, for these reasons at minimum:
- Tilt temperature readings lack the necessary scale. Tilt’s temp accuracy is quoted as +/- 1 degrees F, and I’m not sure of its resolution (how many digits to the right of the decimal), but your Tilt might be reporting 73F when the true temp is 1+ degrees from that.
- you can’t control where the Tilt floats. In my case (stainless conical) there is an appreciable temp diff between the liquid right next to the wall of the fermenter vs. in the middle of it, especially during a ramp up or down. And in reality it’s the temp at the midpoint of the liquid, well below the surface, that I’m interested in which is why I depend on a OneWire sensor in a thermowell.
- the Tilt doesn’t always freely float. I’ve had dry hop bags cause it to read values 10 or more gravity points above or below what a hydrometer sample tells me. And there is ongoing debate about how much impact there is on a Tilt from the krausen and other stuff also floating at the top of a fermentation.
- similar to the above point, during active fermentation the Tilt shows a lot of fluctuation in its SG readings (due to CO2 bubbles and other floaties?). If you’re dependent on SG for process control, and readings are fluctuating right on the edge of some control point, your process could fluctuate as well if you don’t smooth out the noise (like the ‘D’ in a PID algorithm).
1 Like
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"