Whilst I await delivery of more WS2812 LEDs, I wanted to start investigating how I can leverage the Alexa Gadget Toolkit integration, so that when I set a timer using Alexa, my LED clock can show the countdown.
I found an open source project called nixie-timer, which had an Alexa Integration and was written for the ESP32
After a few hours of digging around, I had a very basic idea of what the code was doing. I started by trying to replicate the flow using the OOB ESP-IDF.
After many, many, many hours, I realised that I really didn’t know what I was doing, so I went back to the nixie-timer code and added the btstack ESP32 port into my code. This meant I could at least follow the samples provided.
I began trying to run some code myself, but the Bluetooth radio wouldn’t even start. I then took one of the BTStack examples and used that as a starting point. At least they worked.
After more hours, I got the code running, with the occasional kernel panic as I figured stuff out..
Eventually, I got it responding to the Alexa queries and receiving the messages for wakeword, timeinfo and timer.
Exactly what I wanted to achieve. I’m not 100% sure I know what’s going on, but I’ll get more understanding over time.
For starters, I want to use timeinfo to set the internal clock and then I want to use the timer command to display the countdown of an alexa timer.
Now that I’ve moved back to ESP-IDF, I’m going to have to bin my existing Arduino code which powers the LED strip and look at how to make that work.
Happy with progress.
My other WS2812 strip arrived the other day, so I’ve got to look at cutting and connecting the two strips to form one long 180 LED strip. Then I get get a feel of the overall diameter and cut some MDF to house the damn thing.
In Part I, I covered the basics of controlling the LEDs. This covered the hands of the clock.
The second part of my investigation covers time and how to make the clock tick. The ESP 8266 I am using for this prototyping work doesn’t include a Real Time Clock, so I was required to add an external one.
With the module connected, I turned to the code. I’m using Arduino for this as it’s easy to prototype and there are lots of libraries!
This starts the clock. In reality, as the module I’m using is battery backed, this step should only be performed once, but I found that having a fixed “time” would make debugging the lights a little easier.
I plan to revisit this code to ensure that I grab the current time from the internet when required.
Using the time is achieved by reading it.
//get the time from the RTC
RtcDateTime currentTime = rtcObject.GetDateTime();
char str; //declare a string as an array of chars
//print the time for debugging.
sprintf(str, "%d/%d/%d %d:%d:%d",
currentTime.Year(), //get year method
currentTime.Month(), //get month method
currentTime.Day(), //get day method
currentTime.Hour(), //get hour method
currentTime.Minute(), //get minute method
currentTime.Second() //get second method
Each part of the time is available in a named method, so to get an idea of where my LEDs should be, I grabbed the hour, minute and second.
// Fetch the current time
hour = currentTime.Hour();
minute = currentTime.Minute() * 2;
second = currentTime.Second() * 2;
I multiply them as I’m using a strip with 120 LEDs on it.
Building on my LED control code, I make the clock tick by turning off LEDs in the right place.
I use multiple lights to make it more visible. With it now ticking, I hastily assembled the LED strip into a circle using cardboard and sellotape. I ran a length of alarm cable from the strip to the breadboard. To see it in action, I sellotaped it to the wall!
After letting it run for quite a while, I was surprised the hour “hand” hadn’t moved. It took my wife to point out that there aren’t 60 hours on a clock face 🤣
I’m pleased with these initial results.
As for my next steps, I’m not 100% sure. I’ve got to refine the “hands” code. I also need to think about how to mount it on the wall. I suspect it won’t be self contained and I’ll probably have a control box somewhere.
I’ve ordered another strip from the excellent Pimoroni and this will, I hope, let me add another 36 LEDs to the strip, taking it up to 180, which I think will give me a nice resolution.
I’ve got to think about power too. My estimate is that I’ll need around 3.5A to power the whole affair.
I experimented a little more and ended up with a moving yellow light and a pretty static red slash of colour. This was sort of how I imagined the clocking running.
Power consumption was also on my mind. I had read that the each WS2812 on the strip would consume around 80mA. With my intention to power 180 of these, the power requirement was around 12A. This seemed very excessive, especially given the puny wires that were soldered to the strip. If somebody had tried to light them with that power consumption, the wire would have evaporated.
With my initial experimentations, a year before, I was sure I had run a LED rainbow lighting program through it and I new my 3A supply did the job and nothing went on fire.
I hooked it all up and lit all 144 LEDs.
It was only consuming 2.7A, including 200mA required to run the ESP8266 that was controlling it. I knew I’d need another 0.7A to power the intended 180 LEDs. This put the consumption at a little under 20mA for each WS2812.
With the LEDs under control, my next area of investigation was Real Time Clocks. I’ll do a post about that, once I’ve got something to report!
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.
With my requirement of three sensors, I set about building a circuit that included an ESP-8266 and three DS18B20 temperature probes.
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.
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.
Once I hit save, the device rebooted and, lo and behold, the temperature started flowing into the UI!
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.
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.
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.
The third probe I just left hanging in the air, supported by a piece of furniture. My loft really is full of junk!
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.
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.
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.
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.
I carried on through the developer study guy and implemented the basic Light. The messaging flow is now making sense to me. I knew the Microbit’s 16KB of RAM wasn’t going to be enough for any real project, so I decided to bite the bulled and pick up a Adafruit nRF52832 device.
Ordered from www.coolcomponents.co.uk, they arrived pretty quickly. I plugged it in, downloaded the Bluefruit app from the app store and was able to discover and connect to the device pretty quickly. So far, so good.
Unfortunately, I couldn’t flash it my Zephyr project. More digging around, using the Nordic Tools and I discovered that the West tool couldn’t detect the device. Strange, as I could flash it with simple Arduino sketches. I trawled the documentation. Tried changing drivers. Updated the bootloader. Nothing had any effect.
During the umpteenth reading of the Zephyr docs, I finally realised why:
Flashing Zephyr onto the nrf52_adafruit_feather board requires an external J-Link programmer. The programmer is attached to the X1 SWD header.
I have emphasized external in the quote above. I totally missed that key piece of information. More googling and I learn that Segger J-Link is a special protocol and that a small unit is required to interface your computer with the board! Everything fell into the place. The different drivers and the talk of the SWD header.
Unfortunately, my Adafruit boards don’t have a SWD header. Fortunately, the board has space and solder pads for one to be added.
I found a J-LINK device on The PiHut which I ordered, along with a short cable. I’ll wait for that to arrive before I attempt to solder this header onto the board. I’m going to need some steady hands!!
J-Link Device arrived and connected up. Managed to solder on the header without any issue.
I think hooked up my newly purchased J-LINK device. Side node here – I ordered a serial cable with this as PiHut said it was recommended. One came in the box, so the extra one I ordered was redundant! I’ll be writing to them about that.
Running the nordic command shows it has found the J-LINK connector!