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