A few months back, after we discovered mould growing on our bathroom ceiling, I replaced the wall mounted extractor fan with an in-line model, mounted in the loft. I never grasped how important the position of the van was in relation to the source of steam and the source of fresh air. Without going into too much detail, the new vent, directly over the shower, is doing its job.
My extractor fan, like most people’s, is wired to the lighting of the bathroom, so turning on the light also turns on the fan. I have two problems with this:
- You need to have the light on, even if it’s the middle of the day.
- The fan runs in the middle of the night after a trip to loo.
The first point is my preference. I like natural daylight, so it does annoy me having to turn on the lights. Opening the window just isn’t as effective as the fan. And whilst the in-line unit I purchased is very quiet, in the dead of night, you can hear it roaring away .
It would be nice to only have the fan on when needed e.g. having a shower. Some fans use humidity sensors, but inline fans don’t have that option. Besides, they require the humidity level to rise enough to trigger them, which kinda defeats the point. My wife suggested we add an extra switch to control it, but it’s not practical as I’m not able to get a wire down into the socket. I’ve started looked at some sort of smart alternative.
The plan
I’ve been thinking about a solution and I’ve got an idea that I think will work. There are three parts to it.
#1 Add a temperature sensor to the hot water pipe that feeds the shower. I’ve built one for my son’s room, battery powered, so we can see how hot/cold his room gets during the night. The temperature sensor could tell when the shower is running as the pipe would get up to 50 or 60 degrees Celsius.
#2 Disconnect the fan from the bathroom light and control it using an ESP8266 and a relay. This will allow it to be turned off and on via an MQTT instruction. I will also reduce the fans overrun to zero and control that via software instead.
#3 Create an automation to engage the extractor fan when the temperature sensor reaches a certain temp and to turn it off when the temperature drops back down.
The Temperature Sensor

For this project, I’m planning on using a variation on my own home made temperature sensor.
In order to have a fast response response to changes in temperature, the unit is going to have to be powered constantly. Fortunately, there is an easy access between the shower pipes and the cupboard under the stairs. I’ll be able to run a cable up there with ease.
The Fan Control
The fan that I’m using in my bathroom is a bog standard inline extractor. It takes three inputs. Mains power, live and neutral and a switch live, which is tied to the bathroom lights.
My plan was to use the existing mains power to power my control circuit and to put the switched live under the control of a simple relay, rather than the light switch. I will also use Hass to manage the fan’s overrun, rather than using the inbuilt circuit. This gives me more control and flexibility.
I have a few Hi Link transformers, which take mains voltage and spit out 5v. The Wemos D1 boards I have will take a 5v input and the small relays I have are also powered using 5v.

The operation of the control would be pretty basic. Using MQTT, it would listen for a run command, the body of which would hold a count in minutes. When received, it would engage a relay to the switched live input of the fan. Once the specified number of minutes elapsed, it would disengage the relay and the fan would stop. If a run command was received whilst the fan was already running, the time would just be reset. If a stop command was received, the relay would automatically disengage.
The controller would also publish its current state when it was changed, something that isn’t necessary, but useful for keeping Hassio up-to-date with changes it didn’t cause!
I assembled a small prototype using some veroboard and a relay I had. It is a low trigger relay, which means it’s engaged when the the indicator input has a low voltage. This is a little annoying (it’s using power to engage the contact). I ordered a high trigger relay, but pressed on with the prototype just the same.

Sadly, this protoype didn’t work! Everything powered up, but the program on the ESP8266 didn’t appear to boot up. Experience taught me this was because of a lack of power, but I expected no more than 300mA to be drawn by both the relay and D1 board.
I attached my bench supply to get a better view of the power consumption.

So it’s wasn’t a power issue. I poked around a little more and after reviewing the MQTT logs, I was happy that the code on the D1 was actually running correctly. This was puzzling. All information pointed to the relay being a problem.
I reconnected to my PC via USB and ran the code again. Everything worked perfectly.
As I’m using a low trigger relay, this means that the relay engages when the output PIN is set to ground. Using my multi meter, I measure the voltage across the PIN and got a value of 0.095V

Reconnecting my rectifier, I tested the voltage again and got a different value!

Bench power gives 0.11v when the output pin is set to LOW
The penny then dropped. What if the cut off was 0.1v? I quickly popped a resister in series and bingo, the relay engaged!
As I already knew, the low trigger relay didn’t align with my requirements, so aside from a fun diversion, this wasn’t a problem I needed to solve.
HASS control
With the fan control hardware prototype up and running, I turned my attention to Hass control. As I was using the MQTT protocol, this was very straight forward.
After some experimenting, I had to bin my approach of passing the running time as part of the body because of how MQTT works in HASS. Whilst HASS will issue MQTT commands for a particular device, it also listens for status changes from the device. The body of these two messages must match up. For example, if I issued START5, my board would respond with START5 and HASS would turn the fan yellow to indicate its running. If I send the MQTT command outside of HASS (MQTT directly, for example) with a body of START10, HASS won’t identify the fan has started and its state would be wrong. I don’t want to force myself into relying only on HASS to start the fan. Commands like START and STOP are sufficient enough for my needs.
It’s not the end of the world. The fan already has a fixed overun time, so I won’t be any worse off. In the future, I could look at another MQTT command that could dynamically change the overrun time.

More to do
The idea was sound, but I have much more work to do.
- Replace the replay with a high-trigger one
- Connect the control unit to the extractor fan
- Connect the temperature sensor to the hot water pipe
I will cover these in future posts on the subect!