BrewBlox Tilt Service

General
#163

I also ferment in a stainless conical inside an upright freezer. What I’ve done successfully in the past is to “move the mountain to Mohammed”, in other words I run the Raspberry Pi inside the freezer so that the Tilt’s Bluetooth signal only has to span some fermenting liquid + the thickness of the fermenter wall. The WiFi signal emanating from the cold RPi is sufficient to link up with the rest of the home network. Admittedly it doesn’t hurt that one of my WiFi access points is just above the freezer.

Caveat: my past experience has been with BrewPi, and I haven’t yet done attempted this setup since getting my Spark3 and changing to BrewBlox.

#164

Yeah thanks for that. It’s a bit of a conundrum. I didn’t want my rPi to be in there if I was going to run the freezer for very long to cold crash or what have you. I may try this but all of my actuators are in a project box mounted outside the freezer so would be a total changing up of how things are wired/organized. I wish the Brewblox/Tilt service could work with bluetooth dongle and not the onboard BT. If that changes in the future I may come back to Brewblox (wink wink, @j616s). As it stands, I am trying to get what I need from my $20 inkbird controller and logging gravity/temps with Brewer’s Friend/Tilt Pi and the BT dongle/USB extension cord.

#165

I have my relays & such in a project box too. But with my new BrewBlox setup I rarely have the Pi and the Spark physically connected via USB. So my controller / switching logic sits outside (on top of) the freezer. The RPi and the various temp / SG sensors are inside the freezer. I have cold-crashed with the RPi in there, with no apparent long-term harm. Once the beer is fully crashed I sometimes move the RPi outside the freezer since by that point there are no longer relevant SG changes to track. Hopefully you’ll get the BT dongle working soon and can experiment similarly.

#166

Thanks. That’s a great idea. I have a spark v2 but I guess I could upgrade to rPi 4 and mount inside freezer. Then, connect to the spark/project box with a long USB cord.

#167

A new rPi and a $60 BT repeater from TILT are sounding pretty good about now.

#168

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?

#169

‘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.

#170

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

#171

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?

#172

That is how you update, yes.

Is there anything useful in the logs?
docker logs brewblox_tilt_1

#173

I’ll check this evening. I didn’t get SSH working over VPN so I can’t check at work :slight_smile:

#174

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

#175

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.

#176

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.

#177

Thanks for the info. I tried to PM you about slack but it said I’m not allowed to message you.

#178

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.

#179

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.

#180

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?
#181

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.

#182

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