Lockdown LED Clock

A year or two ago, I picked up a WS2812B LED strip, but, for the life of me, could never think of anything useful to do with it.

Recently, however, I came across these LED powered clocks.

This feels like a project that will combine a few things:

  • ESP MCU
  • Real Time Clock
  • WS2812B strip
  • Maybe some Alexa integration?

Since I’m working from home for the duration, due to COVID-19, I get to recoup my usual commute time and put it towards something.

My starting point will be hooking up the strip to an ESP32 and trying to light one of the LEDs. I plan on a series of posts as I work towards my own clock!

Do we have any hot water?

A common occurrence in our house is bath time.

Another common occurrence is not having enough water for afore mentioned bath.

Our hot water is provided by a system boiler/unvented cylinder arrangement and I use a Nest to control the hot water (more on that later). The current schedule has it running the boiler for thirty minutes each day.

What is very annoying is that on some bath days we have ample hot water and on others, we don’t. We end up boiling the kettle to make up the difference. I don’t like the idea of just turning on the hot water as we might just be heating water that is already hot enough.

How much hot water do we have?

The first thing to figure out is how much how water we actually have. As I’ve mentioned, one some days we have ample and on other days we run out. Why does this happen?

Here are a few of the main factors that spring to mind:

  • The duration of the showers in the morning.
  • The ambient temperature in the loft.
  • How much washing up we’ve done.

The image above shows the basic operation of an unvented cylinder. Cold water enters the tank at the bottom and hot water exits at the top. The coil inside the tank is connected to the boiler and is responsible for actually heating the water in the tank. The whole thing works off the principal that the hot water will sit on top of the cold water and be pushed out the top.

My plan, therefore, was to attach temperature probes to the cold water entry and hot water exit and see what I could measure.

I was also interested in trying to measure the effect of the loft temperature on heat loss.

The Sensor

With my requirement of three sensors, I set about building a circuit that included an ESP-8266 and three DS18B20 temperature probes.

The DS18B20 uses something called the OneWire protocol, which means you can connect multiple sensors in parallel and use a single GPIO to read all the values. I found an excellent tutorial on the subject here – https://lastminuteengineers.com/multiple-ds18b20-arduino-tutorial/

With the long DS18B20 probes attached
The three temperature probes connected to the D1

For power, I wanted to use an off the shelf power supply. As these are mostly 5v, I added an LV1117V33 LDO. This little device accepts up to 7v input and outputs 3.3v, which was perfect to power the D1 and the sensors. To this, I connected a barrel input.

Powering the device with a 5v power supply

Software

I had originally planning on writing my own software to read the values from the sensors and send via MQTT to my HA instance. I actually did write my own software and even got the auto-discovery working, but as I wanted a web UI running on the device, so I could change easily change WiFi and MQTT settings, going down the custom road made little sense.

I was vagly aware that the excellent Tasmota Firmware (which I use in lots of smart sockets) did have some form of sensor support, so I did some reading. It turns out that not only did it support the DS18B20 sensor, it supported multiple ones 🙂

I flashed it onto the D1 mini and, after setup, navigated to the Configuration page.

You can select Module type as Generic (18) to gain access to the various GPIO pins on the device. I had connected the data wire of my sensors to D4, which is GPIO2. I choose teh DS18x20 option.

Setting up GPIO2 to handle the temp sensors

Once I hit save, the device rebooted and, lo and behold, the temperature started flowing into the UI!

Housing

Knowing how dusty my attic can be, I wanted to house the electronics in something, just to keep it clean and tidy. I had some Hammond enclosures (https://www.hammfg.com/electronics/small-case) and one of them seemed perfect.

I drilled four holes. One for each of the temperature probes and one for the power connector. The probes are held by three IP68 glands. Not necessary at all, but I just had them and thought they’d suit.

All the holes drilled and the sensor glands added
Circuit board installed
Lid on.

Once I had it all assembled, I plugged it in. It was at this point I wished I had some sort of indicator light to tell me it was powered or connected to the internet. I had to wait a minute, but eventually the Tasmota appeared on my list of connected clients.

Installation

I have a pretty standard unvented cylinder. There are two pipes entering at the bottom, the cold water inlet and the hot water return to the boiler. The hot water outlet is at the top.

My hot water tank in all its glory!
I stuffed one of the probes under the lagging at the top
The cold water inlet at the back – It isn’t even fully lagged!
I stuff another probe up against the cold water.

The third probe I just left hanging in the air, supported by a piece of furniture. My loft really is full of junk!

The data

The reading from the probes

From the three probes, I could have a guess as to which probe was were!

The 15.8 was the ambient temperature in the loft, with the 19 and 48 degree measures pointing to the inline and outlets.

Measures taken first thing in the morning

My hot water turns on for 30 minutes each morning (30 mins because the Nest Thermostat won’t let me do anything shorter). I looked at the temperatures when I got up around 7am and I could see the top temp was at almost 60 degrees.

Next Steps

I’m going to let this setup run for a few weeks and note the days we run low/out of hot water.

Combined with better control of my hot water (I’m thinking of replacing my Nest’s control), I think there is an opportunity to reduce the time my hot water needs to actually be turned on.

Other things might be possible, such as extra hot water when we have guests over (using their connection to the house WiFi as an indicator of presence). Or ensuring these is hot water for washing the dishes at 6pm each night.

I’ll post an update, once I’ve got some findings!

Update 24th Feb

With the sensor installed for over a week, I pulled a graph from Home Assistant.

A week’s worth of readings

The green line, which reaches the highest values is the outlet temperature. You can see the rather pronounced peaks and troughs. The orange line represents the inlet temp and that does spike a little, each morning, when the heating is turned on. The red line is the ambient temp of the loft. It does vary by a few degrees.

From the graph, it’s very obvious when we’re very low on hot water!

I also find the temperature loss over the course of the day to be interesting. This is obviously a function of the ambient temperature in the loft, but also, I suppose, of the temperature of the incoming water.

I’m in the process of upgrading my Home Assistant instance and I hope to be able to retain more data than I can do right now. I’d like to be able to compare summer months to winter months, so I need a few months of stored data to perform that comparison.

More to come!

Shelly 1 Relay

With Den Automation facing immanent demise, I’ve been looking at alternatives.

I came across the Shelly 1 relay, quite by accident, whilst looking at some Sonoff stuff. It immediately piqued my interest, mostly because it taught me that I didn’t know anything about lighting circuits in the UK.

I’ve installed my fair share of lighting fixtures during the rennovation of my home and whilst I was astonished at the number of connections in a ceiling rose, I never really took any time to investigate why.

Image result for ceiling rose wiring
Typical ceiling rose wiring arrangement in UK home

I had made my own attempts at automating lighting when I first moved in. This was a crude affair, which involved putting a Sonoff Basic relay in between the rose and bulb.

Whilst functional, the downside was that flipping the physical switch turned the relay off. Bye, bye, remote switching.

This is where the Shelly 1 comes into play.

Shelly 1 Wi-Fi WLAN switching actuator 16 A SHELLY SHELLY 1
The Shelly 1 relay. Small, but powerful 🙂

I came across an excellent post, which explained how to connect the little unit to a UK ceiling rose, which is well worth checking out – https://gist.github.com/lordneon/aecf24035a4dc5e6b950977e37aeb930

Essentially, the Shelly 1 is connected to the permanent supply, so it’s always on, regardless of the physical switch. The Shelly is also connected to the physical switch, so it knows when it’s been flipped.

This means that the light can be turned on and off via an API *and* by the existing light switch! I immediately ordered some.

A Christmas tree of relays.

My order included two Sonoff Minis, but I choose the Shelly1 to begin with as it supports MQTT control out of the box (which bypasses the Shelly Cloud – local control all the way). I know the Minis have to be flashed with Tasmota firmware to support MQTT and I didn’t want to get distracted!

Installation

WARNING! Please don’t attempt anything related to mains electricity unless your confident in your ability. Always remember to isolate circuits from the fuse board before doing anything!! I am not responsible if anything happens.

Installation was very straight forward with the help of the excellent WAGO connectors. Following the diagram, I installed the Shelly 1.

Wiring Diagram
https://gist.github.com/lordneon/aecf24035a4dc5e6b950977e37aeb930
The Shelly 1 wired in!

Once I’d restored power from the fuse board, I went through the configuration process. This followed the standard pattern of connecting to the Shelly’s WiFi network, connecting to my own WiFi network and then entering the MQTT server address and credentials.

It worked first time!

I set it’s Switched Live mode to edge, so that means that any change in the physical switch will turn it on or off, perfect for my needs.

Adding the Shelly to my Home Assistant required the addition of an MQTT entity with the appropriate topics.

  - platform: mqtt
    name: "Shelly-1"
    state_topic: "shellies/shelly1-B8B728/relay/0"
    command_topic: "shellies/shelly1-B8B728/relay/0/command"
    payload_on: "on"
    payload_off: "off"   

I repeated the process on another light in my house.

This was installed into a standard plastic ceiling rose, but unfortunately the cover wouldn’t close due to the thickness of the Shelly.

As this is pretty unsightly, I’ve decided to find a nice ceiling rose with the space to hold the Shelly before I install any more.

I’m so happy with these, they are a perfect replacement for my defunct Den switches. I’ll be replacing all of Den’s switches with these Shelly 1s once I find a good rose.

Den Automation and the Cloud

A few months ago, Den Automation Ltd appeared to drop off the face of the earth. My hub disconnected from the internet and the Den app would only work whilst I was at home.

I should point out that I invested in Den via Seedrs.

Continued Operation is possible

I took time to try and understand the protocol and eventually managed to write some code that allowed me to continuing using them. I created a Flow in my Home Automation installation using NodeRed. This essentially bridged messages from my Hass over to my Den Hub.

This has been reasonable successful, but there are some issues.

#1 The Den Hub needs to be restarted every week or so. I don’t know what’s happening, but I suspect the MQTT server they are using has a memory leak. After a few days of successful operation, it disconnects from NodeRed and refuses new connections. A restart clears this.

#2 Speed is inconsistent. Sometimes operating a light or socket from within HA will result in speedy action from the Den unit. Sometimes it takes several seconds and sometimes nothing happens.

#3 Disconnections from the switches and sockets. This has happened my bathroom switch. It just no longer operates or sends its state. I guess it has lost contact with the Hub. I might try and reset it, but I think that’s probably a crap shoot since I have no App to guide the process.

Liquidation

Den Automation Ltd. are officially in liquidation.

As somebody who invested in both shares and product, I’ve been hit twice.

I’m also in the process of trying to recover some of the money I spend on pre-orders, as some of the items were never delivered. I’ve submitted the paperwork, but I have yet to get a response.

End of the line

With Den officially in Liquidation, there is no longer any hope for the company.

I’ve also decided to start the process of removing all their products from my home. First to go was the double socket connected to my Kitchen’s TV. I’ve replaced this with a Sonoff switch (flashed with Tasmota).

I’ve had a great experience with the Shelly 1 relay product, so my plan is to remove all the Den light switches upstairs and restore the original switches, with Shelly relays going into the lights.

Cloud Control

The loss of Den’s cloud crippled the product for most people who had purchased it. I was lucky that I was had the knowledge and tools to determine the local protocol and leverage it from my own ends. Sadly, I wasn’t able to help anyone else.

Den’s local control ability was the primary thing that attracted me to their product line. The relied on the Cloud for user account’s and when that went, their app became useless, actually logging the users out. Not as “local” as I had hoped.

Sonos’s recent announcement about their hardware has made me come to the conclusion that any hardware that needs a Cloud is bad. It’s hardware you own, but don’t own. I’ve got £250 of Den products that I can’t really use because a company was poorly managed, despite the product itself being fully operational.

Google did the same thing a few years back killing off a smart home company called Revolv. Pulled the plug and turned off all the hardware.

I’ve got some Nest products in my house and all this has me wondering how long they will last!

Xiamo Aqara Wall Switch

With news that Den Automation were likely going into administration (due to massive debt) and the discontinuation of their Cloud services, my dreams of adding more Den switches were well and truly dashed!

I’d added a few Aqara temp sensors and contact sensors to my Home Automation setup and I discovered that they had a property Wall Switch, one that claimed to work without a neutral wire. I’d ran into this limitation before with smart switches. I found a vendor on Aliexpress and ordered some. After some issues with packages being returned and duty being paid, they finally arrived.

Nice packaging and the trip from China didn’t damage the boxes too much!

I ordered a single gang and a pair of two-gang switches. Aside from everything being in Chinese (I think) they looked pretty solid.

On inspection of the individual units, I realised immediately there would be some issues.

First, there was the depth of the backing box. It was around 27mm, which I knew would be too deep for the boxes I my own house. I had the same problem with the Den switches, but they provided a spacer to compensate. These switches had no spacer.

The second problem was the two gang switches weren’t double pole, meaning the two way switches I had hoped to replace were out of bounds. I should have guessed this really. I had some other two gang switches in my house, which might be good candidates to replace.

Installation

WARNING! Please don’t attempt anything related to mains electricity unless your confident in your ability. Always remember to isolate circuits from the fuse board before doing anything!! I am not responsible if anything happens.

So, back to basics. Did they work? I turned to my trusty test rig!

My simple test rig for testing switches and lights.
The switch in action. Responsive with a solid feeling switch action.

Confident the switch actually work, I chose the downstairs toilet switch to replace. It was a single gang switch, which mirrored my test rig.

A simple live and switched live setup. Perfect!
I reconnected the earth to the backing box.

Amazingly, the switch did fit. Mostly down to the thickness of the wall plaster and the empty backing box.

The unit, with the switch cover removed fitted flush to the wall.

I popped the cover back on and clicked it a few times to confirm it worked.

Looks okay

Adding to my Home Assistant

This part proved more difficult.

The scan for a new switch didn’t find anything. I tried it several times, resetting the Aqara switch over and over. It was only after I put my laptop down in frustration that I spotted lots of new entries under the “Lights” section!

Turns out it was treating them as Lights, but calling them Smart Plugs.

Not a big deal, but something to watch out for.

I synced Home Assistant and it popped up as a Plug.

The Aqara shows up as a Smart Plug

I choose the toilet for another reason. My son is using the toilet now and, due to his height, or lack thereof, he has to shout for somebody to turn on the light.

I installed one of the Aqara Push switches at my toddler height

A button for a little boy

I then took the opportunity to install Node-RED and to configure a simple flow. When the event from the button is detected, it will turn on the switch above for three minutes.

Simple Node Red flow

Summary

It’s a nice bit of hardware. I’m a little mystified about how it *actually* it works. I’ve read that it only works with dimmable bulbs, so I guess it doesn’t actually every disconnect the circuit. It’s reliable and switches pretty quickly. It doesn’t suffer the same limitation as the Den Automation switches, which can only be switched once every minute.

Due to the limited design of the two gang switches, I can’t replace any of the two way switches in the house. There are two other two gang switches in my house. One of the boxes is packed to the gills, so I won’t be touching that.

The outdoor lights might be an option, but I haven’t opened up the switch to take a look.

All in all, it seems like a pretty solid offering. The depth of the switch is certainly an issue and the lack of a supplied spacer might result in you having to mix and match with some off the shelf ones, which isn’t ideal.

Aqara also do a battery version in the same style, so you can mix and match. I’ve picked a few of them up too and I’m hoping to use them in conjunction with some Shelly 1 relays to swap out the two way switches.

Den Automation – API

With the very sad news that Den Automation is having financial troubles, I decided it was time to revisit my investigation into the protocol that Den uses.

I had read on their website that they used both a cloud based and local network approach. In fact, this was one of the things that appealed to me most. Offering local control is an important aspect in any smart home as it insulates you from internet outages.

I had looked into their protocol a few weeks after setting up my Den hub, but it turned up a dead end for me.

Based on what I’d learned my own adventures in IoT, I started working under the assumption that the local protocol would be HTTP based and use probably use mDNS. Using Charles, the populate iOS proxy, I was able to capture some of the traffic from my phone whilst using the Den app.

Unfortunately, all the requests were targeted at Den’s cloud. I was able to see the details of my deployment, the various switches and sockets, but I wasn’t too interested in taking this approach, since I had Google Home and Alexa integrations already setup.

I fired up WireShark and used Apple’s guide on how to intercept all traffic from my iPhone – https://developer.apple.com/documentation/network/recording_a_packet_trace

I immediately spotted a HTTP request, which was a protocol switch request. More digging and some Google-fu and I leaned that this was just MQTT over websockets on port 1884

I loaded up MQTT Explorer and fed in the details (IP address of my hub and Port 1884) but got a 401 (Authentication failed). This was progress as I knew some thing was listening.

Fast forward a few hours and I’d extracted this packet. Thanks to this protocol document ( http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/MQTT_V3.1_Protocol_Specific.pdf ) I was able to determine this was a connect request (0001), which contained a username and password.

The request to login, with a client name of MQTT and the username and password

Armed with some credentials, I fired up MQTT Explorer and was connected.

After a few minutes, I started to get information over the connection! MQTT Explorer includes the # and $SYS/# subscriptions, so it basically gets everything published by the hub.

I knew that the device was one of the double sockets (the TV was on) and it was sending measurements!

{“43de2329-8808-57bc-af5b-ea01bd6a6d11”:{“online”:true},”c8de59a4-29e5-52ad-84b5-2574f005544b”:{“software”:[{“type”:”USER_1″,”version”:”1.3.0″}],”battery_level”:29,”online”:false,”status”:{“0”:{“last_state_changed”:”2019-08-09T15:46:24Z”},”1″:{“last_state_changed”:”2019-08-09T15:46:24Z”}}},”7039ee52-d25a-59c5-b957-844ff067233f”:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:false,”status”:{“0”:{“state”:0,”shutter”:1,”nfc_tag”:{“uid”:”04:cd:be:d2:35:5e:80″,”atqa”:”0x44″,”sak”:”0x00″,”version”:0,”name”:””,”type”:”APPLIANCE”,”keep_on”:false,”timeout”:{“enabled”:false,”duration”:0}},”last_state_changed”:”2019-10-09T11:18:17Z”},”1″:{“state”:0,”shutter”:1,”nfc_tag”:{“uid”:”04:f2:97:ca:35:5e:80″,”atqa”:”0x44″,”sak”:”0x00″,”version”:0,”name”:””,”type”:”APPLIANCE”,”keep_on”:false,”timeout”:{“enabled”:false,”duration”:0}},”last_state_changed”:”2019-10-09T10:59:42Z”}}},”1cef1fcd-3aa7-5a49-80b4-ea98b85c5827″:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:true,”status”:{“0”:{“state”:1,”shutter”:1,”nfc_tag”:{“uid”:”04:61:8a:7a:33:5e:80″,”atqa”:”0x44″,”sak”:”0x00″,”version”:0,”name”:””,”type”:”APPLIANCE”,”keep_on”:false,”timeout”:{“enabled”:false,”duration”:0}},”last_state_changed”:”2019-10-09T18:04:06Z”},”1″:{“state”:1,”shutter”:1,”nfc_tag”:{“uid”:”04:5a:b2:d2:35:5e:81″,”atqa”:”0x44″,”sak”:”0x00″,”version”:0,”name”:””,”type”:”APPLIANCE”,”keep_on”:false,”timeout”:{“enabled”:false,”duration”:0}},”last_state_changed”:”2019-10-09T18:04:08Z”}}},”c0713ae1-1913-5ab7-944b-d94ea4b5477d”:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:false,”status”:{“0”:{“state”:0,”is_ready”:true,”last_state_changed”:”2019-10-09T17:30:34Z”}}},”4f832cb2-824f-58dc-87ad-5a89e121b653″:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:true,”status”:{“0”:{“state”:0,”is_ready”:true,”last_state_changed”:”2019-10-07T17:23:55Z”}}},”59607912-dda1-5e97-9e3d-6b065b9288db”:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:false,”status”:{“0”:{“state”:0,”is_ready”:true,”last_state_changed”:”2019-10-08T18:59:02Z”}}},”5a008677-5c2e-5405-a6b8-357a7e64642a”:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:true,”status”:{“0”:{“state”:0,”is_ready”:true,”last_state_changed”:”2019-10-08T21:19:37Z”}}},”8016c79f-8502-5b5c-b480-bb6361af1398″:{“software”:[{“type”:”USER_1″,”version”:”1.4.0″}],”online”:true,”status”:{“0”:{“state”:0,”shutter”:0,”nfc_tag”:null,”last_state_changed”:”2019-10-07T11:13:41Z”},”1″:{“state”:0,”shutter”:0,”nfc_tag”:null,”last_state_changed”:”2019-09-29T12:54:36Z”}}}}

Switching stuff on and off

After more digging around, I eventually capture the Publish command used to control the state of the individual devices.

A 142 bytes WebSocket message sent when I turned on a switch
The content is an MQTT publish (0011)

This enabled me to update the state and thus turn the switches on and off.

I’ve created a simple web app – https://denclient.azurewebsites.net/ – which can be used to control the connected hardware. You just need to use the same process as I did to sniff the packets.

At the time of writing this, the Den app was still working for me, which enabled me to perform some basic packet sniffing. Since I performed this investigation, the Den App is no longer working. I presume that AWS/Azure have killed the Den backend due to unpaid bills.

Set extractor fan to automatic – Part 1

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.

Converts mains voltage to a steady 5V DC, perfect for Wemos

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.

The initial prototype

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.

W1 and the relay (engaged) draw 347mA, well below the 0.6A rating

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

USB power gives 0.095v when the output pin is set to LOW

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.

Tapping this runs the fan

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!