The HA Automated Brewery

. As soon as I step into the brewery theres always something to do – cleaning, brewing, conditioning, moving, customs, and – repairing nearly everything. I started this blog hopefully to document the trials and tribulations of my attempt at automating our brewery and hopefully help any small established craft breweries that “may” be thinking about how to automate their own brewery using nothing other than the tools that the wizards behind HA have given us. Please be aware that this is an evolving hobby project and yes it might change as i detail it.

Before i start –

Some Disclaimers and Transparency:
I apologize to anyone who does not know how to brew beer. This is not a resource of how to brew beer with HA – there are plenty of resources on how to brew beer at home on the interwebs. Just google it!

I will never sell my services to another brewery to set up a version of HA to be used as a control system. HA is open source and a lot of people contribute their own time to making HA the epic platform that it is. Im not creating something from scratch like hundreds of developers, Im standing on the shoulders of giants who have – so dont ask me to set up your system for you for a $.  I will help where I have the time to contribute back to the community.

Dont be a cheapskate when it comes to paying where its due. I subscribe to Nabu Casa – not only for the Remote Access but also to support the HA geniuses that now have permanent jobs at Nabu Casa. If we all did, Im sure that theyd have more than 2 employees. I also contribute to Otto and FRENCK every month because of the sensational work they do.

So lets get on with the story.

Out of Necessity comes the Mother of Invention.
Automating our brewery has become a necessity essentially after years of having to manually control the fermenters (watching the readings from semi unreliable thermocouples solenoids and controllers from china and manually opening a valve of glycol on each tank by hand as the beer is fermenting or conditioning, many times a day 24×7), in order to control the fermentation of our beer. In our brewery we have 15 tanks which means this is not the best setup for both the beer and for me.

The elements have taken their toll

The reason for the unreliability stems from our location on the equator and the quality of the control equipment. The brewery is open to the tropical elements of heat and humidity which means that condensation occurs on anything that gets cold. Essentially everything is wet and subsequently fails because the equipment is not designed for these conditions.

At four years old, every single sensor, controller and solenoid has gone faulty and its time for an upgrade – Home Assistant style!

Before I start, I do have to give credit where credit is due (and I will do throughout whenever I implement something successful) to the LEGENDARY people that have helped in this journey.

Paulus Schoutsen: and your team for making such an amazing platform to use as the foundation for this project. I know its still got a long way to go to making it more domestically acceptable to the masses, looking back at the last 12 months has been astounding, 5 years from now (wow!).
Never allow it to become dumbed down because, in the end, the use cases are phenomenal, both industrial and domestic. I love it that we have the easy version and the advanced version.
Pascal Vizeli: for making a simple to install version of HA called Hassio.
Otto Winter: Without ESPHome, the diversity of the physical connections to the outside world (the brewery) would make this project impossible.
DrZzs: Your Squirrel-iness has been the source of much inspiration and frustration (cos you just cant stay on one track) via your videos.
FRENCK: Addons – thank you. All the bits that are missing, you made them. (Oh and I love your choices in music but not so sure of your beer choices)
Phil and Rohan: for making the job of detailing breaking changes easier by listening in the car on the way to work.

Payback in full: If you guys ever make it to Singapore, I am eternally grateful so beers are on me!

I cant forget the amazing community we have around us, and its this community that is the future for HA, in whatever form it takes.
HA Community: Although I dont post on the forums, I use them a lot for reading when I cant find a video that helps.
Discord Communities: Between DrZzs and the HA Discord channels and all the Mods within, thanks for being patient with me esp when Im frustrated.
Custom Card Developers: Raymond Julin (nervetattoo) for the simple thermostat card. Ryan Meek (maykar) for the compact custom header. Thomas Loven (thomasloven) for card modder as well as all the other card makers out there. Bram Kragten for the custom history graph card.

Having come from more basic platforms in my home  automation setup  I’dve never survived the HA journey without any of these people or communities.

Thank you all.

Objectives of the Project

I always like to ensure I have a clear set of “Must Have’s” as well as a few “Nice To Have’s” as objectives. Im sure that this list will evolve, but there is a BAM (bare assed minimum) Id like to achieve:


  1. Make it reliable
  2. Make it simple (my colleague is not so tech savvy)
  3. Redundant Remote access
  4. Automated
  5. Temp monitor and control of fermenters and brite beer tanks
  6. Logging

So Ive chosen the following hardware:
     (which has now since changed – read on)

  • Raspberry Pi 3b+
    Less hackable (than a PC)
    Small and low power
    CHANGE: (Im not not using the Pi for Hassio – see below)
  • Hassio
    Allows Remote Access thru Nabu Casa
    Logging of temperatures and switches
  • Asus Router
    Using a 4G dongle so it doesnt clog up our existing tap connection
    A duplicate test system will be set up at my home so I can build things at home as well
  • ESPHome
    Lots of different sensors
    Ability to remotely control a specific node by connecting to it directly
  • Dallas DS18b20 Temperature sensors
    Small and Accurate
  • An old 3G phone that does usb tethering

I am sure that there will be more added to this list as I go along but its a start.

This blog will assume a couple of things:

  1. You as the reader are familiar with HA/Hassio, config.yaml, automations, integrations but not necessarily an expert
  2. You are familiar with ESPHome.

The Beginning

So after an initial thought as to how I was going to do this, I got to it and it wasnt a great start. I had all the parts to make up a prototype and began to assemble the bits one night after I got home from work. In the end I was up until 1am wrestling with ESPHOME and trying to get my stupid DS18b20 sensors to be recognized by ESPHOME with no success. As the documentation says, you insert a line:

# Example configuration entry
  – pin: GPIO23
# Note you don’t have to add any sensors at this point

The idea of this is to find the hex vale of the sensor attached to the D1 Mini. At which point you copy the address and add it back into the ESPHome yaml file and “supposedly” Viola! its supposed to work.

Do you think it was going to be that easy? Nope! I had 10xD1 Mini boards I had ordered from AliExpress and and 5xDS18b20 sensors I had from my “Vera” days. When I added the lines to the ESPHome yaml file to detect the IDs of the sensors, I found that things were inconsistent. At first I thought that it was ESPHome not recognizing the sensors. In previous experiments with things like Bruh’s multisensor sketch directly into the 8266, I continually got reboots and flaky performance. I was hoping for more reliability from ESPHome, but my cynicism regarding reliability with regards to all things arduino/esp was at an all time high at this point. The sensors “should have been good”. After all I had been using them on my Vera and Homeseer Zwave network (though a Fibaro Door sensor) but ended up decomissioning them when I migrated to HASSIO.

And then, add to the confusion, I bricked a D1 Mini while flashing it which just added to the frustration. It was just getting ridiculous; some of the sensors would be recognized (sometimes) and others would not. In the end I wasted 6 hours with these stupid things and ended up going to bed, frustrated, with no resolution.

Next morning, I did a similar thing, wasted more time fighting with the config and these sensors. Sometimes the sensor would supply an address and then other times it wouldnt (I was flip flopping between soldered sensors on wires, then trying them through header wires, all the while with adjusting the yaml file. I even got to a point where (and I think theres a bug) that if theres no wifi config, the Dallas hub config fails.

Day 3 of fighting with these things, I managed to get one board/sensor working. and decided that the best thing to do was to make up a WORKING HUB and test all the sensors I had. So, on a breadboard, using jumpers, I set up the Dallas hub config w the D1 Mini and plugged each of my sensors into a KNOWN GOOD CONNECTED D1Mini as well as a known good DS18b20 as the reference.

So it may seem obvious at this point but at the time it was not – Lo and behold 3 of the 5 DS18b20 sensors were faulty (one with a CRC checksum error). These buggers used to work and they havent seen power in the last 2 years, theres no reason why all 5 should not work! At least 12 hours of my home time lost, a lot of frustration and wife complaining of me keeping her awake at night – its sorted.

Note to anyone trying this: Make up a test bench to test your sensors. Ive done mine like this. A working D1 Mini, that connects to my router, with the firmware flashed with the DS18b20 Hub code. That way I can just plug the sensor in and use a terminal logger to monitor the output (Ive been using puTTY but if anyone has anything better Id love to know). Once you see the address of the sensor, cut and paste it back into the ESPHome yaml editor and you should be ready to rock.

Why the DS18b20 Sensor?

Its been tough trying to find a sensor that matches all the criteria. The main one being size. All the temp sensors Id come across for esphome had been too large. I was even consdering pulling apart a DH22 to see if the SMD parts were salvageable into something I could use.
In the end the decision to use Dallas DS18b20 temp sensors is because of a few reasons.  They need no calibration and probably the most importantly reason is they’re small and supported by ESPHome. Additionally they are 1 wire sensors (not that Im using them in this mode) but being digital theres no chance of a temperature error unless they go fully faulty which will probably result in a NA in the measurement. At which point I can detect the faulty sensor and alert HA. Unlike a thermocouple which tend to add resistance as they age. The down side to all of this is that if a DALLAS does go faulty, its not a straight switch of sensors. BUT to be realistic the update of the sketch isnt too bad.
In my case, they needed to be small enough so as to fit into the thermowells in the bright tanks and fermenters which were designed (in china). the original sensors were PT100 K Type Thermocouples. While PT100 thermocouples are narrower and have a much wider range (and possibly offer more resolution), they aren’t supported natively within ESPHome without another ADC connected to the D1 Mini. That ADC also chews up 4 GPIOS on a WemosD1 and adds another layer of confusion and complexity which in the end could be a possible failure point.

So Ive resorted to making my own “thermocouple” to fit into the thermowell of the tank.

The size of the Thermowell in the Brite Beer Tank

Essentially its a DS18b20 soldered onto the smallest shielded 3-core wire I can find and then heatshrinked over the top of it, with a dab of silicone on the end to seal the deal. Once heatshrunk, I squeezed the end, hopefully in an effort to stave off the condensation inside the thermowell. Before anyone says…. yes I have tried the waterproof DS18b20’s but they wont fit in the thermowell as the metal shroud is too wide – so this is what Ive had to revert to – making my own.

Minaturizing a DS18B20

So once I had a working system and the ability to pre-test sensors and get thier addresses it was down to the code which was simple enough thanks to Otto Winter:
(side note: excuse the indent formatting for some reason wordpress removes it)

  name: fv3
  platform: ESP8266
  board: d1_mini

  ssid: “XXXXXXX”
  password: “XXXXXXX”

# Enable logging

#Enable Home Assistant API
password: ‘XXXXXXX’
password: ‘XXXXXXXX’

# Dallas setup including the pre-determined address
# 2 Second polling to try to avoid network congestion
  – pin: D2
  update_interval: 2s

  – platform: dallas
  address: 0xD40215657BCAFF28
  name: “FV3 Temp”

# Decided to add this in so that it made for an easy diagnostics situation
  – platform: wifi_info
  name: FV3 IP Address
  name: FV3 Connected SSID

# Relay to switch the solenoids for the glycol cooling on and off.
# Originally I had this sketch set up for the relay boards rather than the D1 hats
# The sketch has been edited to suit the hats (read relays vs hats below)
# additionally, should they lose power I need them to go Normally open
# so that the cooling turns off by default.
  – platform: gpio
  name: “FV3 Solenoid”
  pin: D1
  inverted: yes
  inverted: no
  restore_mode: RESTORE_DEFAULT_OFF
– platform: restart
  name: “FV3 Restart”

I had originally purchased 5 relay boards from our local electronic maker shop due to my impatience of wanting to get the job done and not have to wait for Aliexpress or the like to deliver – only to find issues with the implementation.

Relays vs. Hats

I initially bought seperate relay boards cos they were 5v and because the relays themselves looked like they had a pullup/transistor and an opto-coupler. In actuality they were floating which left them in a state of unknown. Additionally the output of the Wemos didnt appear to be a true 5v. On top of that, the relay board itself operated in inverted mode and was a SPST switch which made the unit ON when the voltage was 0V and would not open at logic 1 (about 4.2v)

The concept of buying separate relay boards instead of hats was that it made for smaller installation in a project box. It would allow me to install the relays using hookup wire to the Wemos. In the end even using hookup wire which also was a mistake. The hookup wire is such a small gauge to fit in the hole of the Mini that eventually the wires would snap off after some manipulation in the box.

So i gave up on that idea and tested my patience and bought a whole heap of Wemos Mini Relay hats. (best move short of my temp sensor rig) and used headers and header pins to connect the sensor to and then altered the ESP sketch to match.

D1 mini with the Relay Hat. Ive marked it as BBT6 because it has a DS18B20 already attached

I assembled the units and used the headers as female sockets to connect the temp sensor as well

Boxing it all up

The ESP8266 controller boxed up


Pitfalls with the ESP Controllers

ESPHome is not a PLC
I love ESPHome. Paulus (HA) and Otto (ESPHome) have made a great platform with which to make so many different things work. BUT in an industrial environment, PLC’s rule. All industries put redundancy high on the priority list, and in a brewery (built for a cost) there will always have many “single points of failure”. My experience has been in Television Engineering, where redundancy is super important. In brewing, while its not as instantaneous (the thermal weight of 1000L of beer doesn’t change within seconds) but it WILL change within an hour at the height of fermentation, so, redundancy is important.
The advantage with a PLC is that if you lose power to the PLC, when the power is resumed, in theory, the PLC will have retained its settings and will continue where it left off OR if the control system fails the PLC will continue doing the last set of instructions it was told.
In the case of HA and ESPHome, if the PC fails, youre stuffed, if the router fails, youre stuffed, if the ESP controller fails youre stuffed. If the phone fails (or you don’t pay the bill) you’re stuffed. So all you can do is try to think of ways to prevent levels of failure.
The number one way of providing a level of redundancy is to ensure whatever you can runs off battery.
So the phone, and laptop run off their own internal battery. The ESP controllers run from a 240V- 24v supply that also controls the fermenter solenoids which are hooked up to a UPS (which also has the router on it)
A future improvement is going to be using the bang_bang platform in the ESP controllers so that the controllers themselves only need power to do what they need to do and that they have semi-PLC functionality.
Obviously backups/snapshots of HA are made nightly, and I have two copies of the VM as backups too, one is stored on a USB stick.
Additionally I have made 3 spare controllers for the fermenters and the bright beer tanks and they are also included into the HA instance so that a replacement is quick and easy.

Powering it all up.


While in a domestic environment having DISCOVERY turned on, it has a tendency to pick up things you just dont expect. My advice, before you do any integrations or add any devices to HA, turn DISCO off. It will save you a lot of heartache.

Coupled with this, occasionally I found that when adding a controller HA (or esphome) may not find the controller first time around. For some reason the entity still gets added. However, as the entity may not be complete, when HA discovers the entity on its own, it will create the entity with a _2 eg: bbt1_2

So, best to leave the DISCO turned off.

Also, for the same reason, only add one entity at time and then make sure that that entity works fully before proceeding onto the next entity. Dont try to add a whole heap of entities at a time. If HA gets confused or ESPHome does’nt connect a controller properly (which does happen), the result gets messy.

I did use a test system at home though while I had a half completed system at the brewery and I had not fully completed all of the sensor/controllers. I used the guest network on my router and gave it the same SSID as the brewery SSID and had a Pi instance of Hassio running on the network, so as I made up a controller I could add it to my home system to test the temp sensor and the solenoid control BEFORE i took it to the brewery to install it. I still have it running at home so that I can complete other sensors I havent got to yet.

Remote access

Nabu Casa and Remote Access
At home i came from Vera and Homeseer, both of which have remote access as standard. And its a fantastic benefit to have it in HA, to be able to see whats gg on in the brewery is a real plus. What would be epic, is if we could get different user accounts tied to one instance of HA. Id be able to set up an account for my colleague that is a simplified version of the overall picture. Something that doesnt need too much education. I suppose thats where custom header card comes in, which I havent implemented yet but its on the to-do list.

Speaking of remote access – its all well and good having nabu casa for the UI, BUT if the VM fails, you will need to have the capability to be able to restart the instance of the VM. If nothing else, windows10 has a nasty habit of installing updates which, when the laptop restarts, sometimes doesnt boot up the VM. So with that in mind Ive installed teamviewer, and RealVNC as a backup. The only caveat to RAS is the router and the phone. The phone is connected to the router via USB tethering and is not enabled by default. So if the phone ever goes faulty or flat, you have to be physically there to enable USB tethering on the phone. So you ask why am I using a phone for internet access instead of a dedicated internet line? Well all our taps (30 of them) run on a self pour system using NFC prepaid cards and the router that they run on is flat out – our internet is connected to this router for the vendor to gain access remotely when they go down. The volume of traffic in the HA system would totally max the tap system out.
Eventually we will get a dedicated internet line for it but for the moment, a USB tethered phone will have to do.

PC vs. Pi

Originally I had wanted to use Hassio a Pi. Which i had bought and made up the original prototype system on. While I know there are other ways of executing this using hassbian etc, I knew that using the pi was eventually going to bite me in the bum, and that would end the project from a reliability standpoint. There were lots of obvious advantages to using the Pi route, cheap, efficient simple rollout, more secure etc but because of the SD card issue where SD cards break because of multiple writes, and I HAD to maintain history of the tank statuses no matter what, I had to retire then Pi in favour of a Win10 Laptop using VirtualBox

The Win10 laptop gave me some advantages that I didnt originally have in the Pi

1: Remote Access via RealVNC and TeamViewer
Primarily using a PC allowed me to remotely access the machine, which also meant I could see the Router admin page, so if an ESP decided to go belly up in HA I would see if it was a connectivity issue in the router or something else. Also it was easy to implement.

2: A VM allowed me to create a backup/redundant instance that could be put into production instantly should there be a problem with the production version. This has saved me more than once, where I have “stopped the server” or sent the shutdown signal via the VM only to have the instance not start back up again. The VM starts however Hassio does not. Remember – always ONLY restart Hassio never “stop the server” or “power off” the VM.
(sidenote: if anyone knows how to get an instance of Hassio in a VM up and running again from stop server mode, please let me know)

3: Built in battery means a built in UPS which is very handy in our brewery because we are pretty much maxxed out on the power department and power trips occur all the time. Coupled with the “tropical unreliabilty” of things like fridges, chillers and just anything that connects to power, we can suffer a power trip in the middle of the night and not know it.

4: SSD reliabiluty and speed. With the SSD instead of a SD card (I originally had a car cam microSD card in the pi to increase reliability) But there was .always a lurking demon as to “How” reliable will a car cam SD card be with 14 tanks continupusly writing set temp, solenoid actions and temperature data at 2s interervals? I just didnt want that spectre of failure hanging over the end result which would see the people that use it judging it as a “domestic” and less professional project.

So unfortunatley I retired the Pi in favour of Hassio on VirtualBox running Win10 on a SSD

Display and Ux – or the lack of it, vs. Making it work like it used to.

Originally I had envisioned that all interactions would happen on a phone and there would not be a “work facing” display. If nothing else, a display would need to be weatherproof and waterproof so as not to get damaged. Problem is that my colleague is old school and is definitely NOT tech savvy, and is used to very tangible/tactile interactions with the controllers which posed me a challenge. So it meant that a display had to be installed (I ended up installing it in a spot in the corridor that is out of the wet-area. So my challenge was how to make the UI work in a way that he was used to, BUT at the same time bring a certain level of WOW into this new system.

Enter Lovelace and Custom Cards.

The Main UI “at a glance” view

Essentially I took the retired pi and installed raspbian on it and launched a fullscreen browser on it and connected it to a 41inch TV screen in portrait mode so everything would ft on the screen and look very similar to the control panel we have in the brewery. I also used an airmouse in the absence of a touch screen (maybe later) but that allowed us to manipulate values and control tanks as we need.

Simple Thermostat card is great, it uses a very similar concept to the LED/BUTTON controllers we have in the brewery. The only issue is that the “cool” control would be better off being labelled “auto” (the set temp is automatically controlled) to allow my colleage the same terminology that we currently use.

I dont know anything about python or JS to be able to rewrite the label so I placed a input_bool below the mini thermostat card that says auto, and used a button card to represent it in lovelace and a short automation to turn the mini thermostat into the mode we need. The added benefit to this was that the input_bool retains its state across reboots, so then all I needed to do was detect the state at HA startup and then set the mini thermostat into the right mode.

However since implemetning this, HA got a climate control update, that brought with it some breaking changes, that I need to sit down and fix when I do finally update HA.

Ideally I’d like to change the word “cool” to “auto”

Custom History Graph Card: The other helpful card is the custom graph card. It has all the sensors/entities I need. Tank set point, tank temp, solenoid state. There are a few flaws with the card but at the moment it will suffice. Firstly, it doesnt allow setting of a range of values, it auto ranges by itself. Typically an ale ferments at 18-20 degC so having a range that runs from 0-40 shows no resolution. So I created two dummy sensors that had values of 10 degC and 25 degC and added them to the graph card.
Also, a slipup for new players. Make sure your Units of Measurement for all your sensors match. If your unit of measurement is degC on one sensor and deg C on another, these get logged into the history database as two separate UoM and display seperately (two sperate graphs, split, on one card rather than overlaid on each other on a single graph). If you go to change the UoM to match, you have to wait 12+H for the graph to log a complete new set of values with the new UoM (degC) before you get to see the sensors overlaid with each other on the same graph.

There are so many benefits of this card one of which is the solenoid state being shown. As a ferment comes to an end the heat generated by the yeast activity slows, so you can tell when a ferment has almost finished.

Lovelace display showing all the tanks and the History Graph

Making it better through automations

Automation in this brewery has had to have some creative thinking.
The most basic automation had to be to do with the glycol solenoids. The solenoids are made in china and unfortunately they get stuck either in the on or off position. If the solenoid get stuck in the on position the tank will chill the beer (ideally most fermenting beer needs to be held at 18-20 degC) down to freezing and a 1000L of freezing beer can take weeks to warm up (the tanks are insulated so even tho SG is 30 degC ambient, it can take forever to get a beer back up to temp) If the solenoid doesn’t open, then the beer will heat up due to yeast activity and over ferment. Using the old control system we found that to ensure that best way to ENSURE that the solenoid did the right thing was to cycle the solenoid multiple times to “unstick” the solenoid.
So any climate automations that get triggered do the following while a beer is fermenting:
Beer is too warm – chill the tank: turn solenoid on (1s) – turn solenoid off (1s) – turn solenoid on
Beer is too cold – warm the tank: turn solenoid off (1s) – turn solenoid on (1s) – turn solenoid off

Pushbullet is my friend (and MQTT)

Obviously Ive got to a point where I need to know if something catastrophic is occurring. So Im using pushbullet and MQTT to receive notifications of anything that HA can sense. My home HA instance connected to the brewery instance via MQTT with visual alerts on the tablet mounted in my house as well as audible ones thru TTS, and I use Pushbullet to send alerts on my phone if Im mobile.

The alerts I send are as follows:

Send an alert if the HA restarts
Send an alert when HA is back online
Send an alert if any of the ESPHome controllers go offline.
Send an alert if a beer goes OVER the climate set temp by +2degC (too warm)
Send an alert if a beer goes UNDER the climate set temp by -2degC (too cold)

If I get any of these then I can log in via Nabu Casa and see what is going on.

Additional Sensors and things that are needed

As I said, this project is an evolution in a lot of ways. Knowing what to replace, knowing what is needed, and inventing new things that help me in what I do. As such I know Im not finished and there are a bunch of sensors that I need to add around the brewery moving forward.

Hot Liquor Tank (HLT).
The current temp sensing is done via a glass thermometer on the side of the tank and the temperatures seem to vary wildly. Coupled with the error inherent with bad eyesight means our strike water can vary +-4 degC. We currently use a certified calibrated digital thermometer that we throw in the top of the tank to measure. The major issue with it is that there is no thermowell to mount a new sensor in the tank, and the old glass thermometer is on a threaded mount that is essential to the integrity of the tank.

Also, as a fail safe, I also need to install a power sensor on both the HLT and the Kettle to determine their state either on or off at the end of the day. The brewery would probably burn down if either one of them boiled dry. As both the kettle and the HLT are three phase at about 90A each phase Im hoping that the rating of the new Shelly EM is good enough to measure just one of the phases to determine the state.

Brewery Temperature
Our brewery is pretty much open to the elements and its super hot and it gets hotter when the Kettle, Hot Liquor Tank and the Mash Tun is full. From a human comfot standpoint it would be good to know how hot things are in the brewery. I would also like to install a humidity sensor, except the brewery is pretty much 100% humidity all the time and Im not sure how accurate the DHT22’s really are. I have 4 of them at home and they all read different even though they can be next door to each other.

Cold Liquor Tank
Because we are in the tropics we rely on close to freezing water to chill the wort before it hits the fermenter. We use the water (from the HxG) into the Hot Liquor Tank for the next days strike water. Occasionally the water freezes due to a big glycol coil in the middle (at -4degC) and we run out of cold water in the runoff because the bottom of the tank turns into a big ice cube. It will be good to have it close to 0degC and automated to ensure it doesnt freeze.

Battery Level Sensor
Best to have a battery level sensor for the laptop to send a pushbullet automation to notify me of the impending shutdown of the laptop.

InfluxDB and Grafana logging
Unfortunately in the UI Ive set the the graph card to only show the last 10 hours of data. At 24 hours the graph was far too small to distingush any usable data. That said, if need be, Id like to be able to scroll through a ferment to see what has happened over the entire duration of the ferment.