Modifying mains is tricky business, and not something a hobbyist should do. But Julius found a way!

Julius needed to take control of mains power for a few different applications, but he wanted to do it legally, and safely. After a few different iterations, and a long journey of Arduino discovery, he now has a fantastic working system. Here’s what we learned when we chatted with him.

Wow, there’s quite some backstory here Julius. Can you fill us in on how you got going with this project, and your background in Arduino?

My interest in Arduino started when Johnathan Oxer (Freetronics) generously included a Leostick in the Linux Conference Australia swag in 2012. I was amazed with what I saw at the conference, particularly around how a community of hackers came together around a device and shared, laughed, committed and produced something amazing. Leostick Tunes was an implementation of the RTTL ringtone sound engine, as used on the old Nokia (non-polyphonic) phones, In the end, you uploaded a function that took a string containing the RTTL ringtone, and your tiny little Leostick started playing the song on its internal buzzer. The faces in that room and the shared joy of exploration was wonderful. Now it’s a list of names around some code in a GitHub repo, but to witness it first-hand, was beautiful and physical manifestation of the kind of collaborative efforts that open source is often lauded to have given rise to; where code is the shared language, but people are the real stars, and projects rise and fall on the strength of collaboration. This project worked, and I was truly inspired.

After the high, the device languished in a drawer for a while. I’d pulled it out and had another go, but somewhere in there I’d had changed laptops and had issues installing drivers or something, as it wasn’t the typical Arduino Uno that is so ubiquitous and compatible now. I’m not quite sure, but I don’t think the Arduino IDE had a board manager back then either. Anyway, turned out I didn’t use the Leostick again, but that wasn’t the end.

I attended a Linux user group some time later and overheard someone complaining that Arduino wasn’t real electronics, and that all it was good for was blink, and that nobody could make anything cool with it. I figured there was an element of truth in that, certainly that the simplicity of the Arduino belied the many years of hard work required to understand electronics from core concepts. Yet still, part of me took offence to the delivery of that message; it wasn’t true that it couldn’t be used to make something awesome because I’d seen it! And so I went away to prove the contrary. In the end I created a Space Invaders clone using an Arduino Uno, some protoboard, some LEDs and transistors, and ultimately it was featured on hackaday, which you can see at https://hackaday.com/2012/08/06/yet-another-arduino-blinkenlight-thing-actually-pretty-cool/

I’m not sure if the message I was sending was actually received by anyone, but it proved a point to myself, and it raised a few solid laughs when I did present it at a meeting a few months later. I never told anyone, but at the end of the game the song played was lifted straight from the RTTL player we’d made in the LCA lab session, and the buzzer (which my Uno didn’t come standard with) is from a Fisher & Paykel washing machine!

So anyway, I’d spent maybe 50 hours on that project, and aside from the skills I was accumulating I really learned a lot about myself. I’d always felt I didn’t have what it took to do electronics; maybe the high priesthood had trained me into thinking that! I certainly wasn’t a star at maths, and the coloured rings around resistors confused me (they still confuse me, so now I just keep them in little drawers and check them with a multimeter!), yet I just pushed forward one step a time and focused on what I did know, then incrementally extended it. To me, what I was doing was amazing and new and exciting, and most importantly, I was motivated! I understood that motivation in and of itself was the single driving force behind my accomplishment. I am not afraid of that word, because to me at that time, finishing that project was a milestone. One that made me feel giddy, even! And upon reflection I realised all the small but positive choices I’d made along the way, I’d done without any external force. I even wrote down those choices, so to remind me of my accomplishment forever.

So I’ve included that here, because it’s relevant; not only to the Space Invaders project, but to the fermentation controller (up next), and to anything else that comes my way in the future. What I learned was to back yourself. To follow the fun. And most importantly (though this is not written down), avoid the nay sayers. Always remember that people who inspire your motivation are the awesome people who deserve your time and attention. Those people who sap it, not so much!

So anyhow, I’d made a couple of other devices, one that listened to IR and turned on the TV and PC at the same time, and off again. And another one that was supposed to heat the kettle, using an infrared heat sensor, but that ended up keeping an eye on the temperature of my motorbike instead!

My approach is that these things are there to be played with and evolved and tinkered with, and only actually left alone when we’re either bored of it, or they’re achieving something nearly ideal for their use. At which point they can then just sit there and be used. The TV thingie is doing that, and so is the fermentation controller, which is going to be the feature of this article. Except... it’s not a fermentation controller anymore; but to tell that story I should start at the beginning.

Anyone who has been near the hobby of making beer, will know it can fast become an all-consuming passion. I was no different. The application of practical science in the systematic reduction of beer faults can be a lifetime’s work, and there are many many ways where a logical and process-driven approach can pay big dividends! At the stage I was at, I needed to control the temperature of my fermentation because so much of brewing is about providing the perfect living conditions for yeast. For the most part, you have to do something pretty dire to yeast to kill it. But minimising yeast mortality, indeed, minimising yeast stress, is key to producing beer that is absent of poor flavours. Essentially, making beer is merely producing a sweet, sticky liquid that is balanced by the bittering of hops, with an appropriate amount of healthy yeast added, after which it is allowed to ferment in a controlled environment.

Following the (very) well trodden path of my home brewing predecessors, one of the easiest ways to gain reasonable control over the fermentation environment is to put the fermenter into a fridge. For some people that’s all they do, as it’s a very good insulation vessel. I already had an old fridge; the freezer thermostat was broken, but the main fridge was fine. My fermenter fitted inside okay, so we were good to go. That wasn’t sufficient as the internal temps did end up at ambient, it just took a while. Generally ambient was >18 degrees Celsius so I needed it to function as a fridge. But the fridge was designed to keep things cold. The factory thermostat topped out at 10 degrees Celsius or similar, so I’d have to do something else to maintain my target temperature of 18. One possible approach was to continue to use the standard thermostat, but modify it in such a way as it was operating in the desired temperature range. This is well discussed at www.brewpi.com/fridge-hacking-guide

I also wanted over and under temperature alarms and a digital readout of the set temperature versus the actual temperature, so I really needed some kind of temperature controller.

Wow, that’s quite a story. Thanks to Jon at Freetronics for kicking off your interest! Mains switching is always a challenge to achieve both legally and safely. How did you come up with this idea?

There are now several thermostat-type temperature controllers on the market: one mainstay is the STC-1000 but that requires wiring 240V. I had some requirements already, and an aversion to playing with mains voltage so the STC was out. Next was the ITC-308, which was pre-wired, but the format meant I’d have bulky 240V cables going all over the place when really all I needed was an in-line switch/relay to emulate the operation of the factory thermostat. I’d seen some 433MHz wireless AC sockets at Jaycar and I figured it would be nice to use one of those and not have to worry about wiring or even cabling. That meant the controller could be somewhere obvious and the only cables involved would be the temperature sensor(s) and some DC to power the device.

Awesome - they’re a great way to safely “hack” mains control, and we’ve done a few versions like that ourselves too. Did you consider generating the 433MHz transmission yourself, or figured “hacking the remote” worked just as well?

Having spent some time with IR on Arduino in the past, I figured it might be easy. Turns out that the only reason IR for Arduino was easy (for me) was that I’d found Ken Sherrif’s library, and he had a preset for “Turn on a Panasonic TV”, which worked. I think I did it about 50 times in a loop before I could convince myself that yes it did work, but when I came to 433, things were a little harder. I didn’t have a library to fall back on, and although I was able to get something from my Jaycar 433 receiver, I wasn’t able to get any useful action from my playback of the recorded signal. I had no idea of the encoding nor any way to test if I was playing back what I had received (I haven’t yet splurged on a Rigol DS1024z but I think I stopped that approach altogether when I considered there were various negotiation protocols involved and I’d have trouble replicating those. As it turns out, a few months later after I presented the controller to my local group of Linux users, and we’d arranged a group buy of similar gear, some fellows at my local hacker space managed to do everything with their 433MHz transmitter! And that’s why you hang out with smart people - to get smarter! Anyhow, my approach was to just hack the remote; and it was already apart on the bench when I’d tried to Google the onboard integrated circuit.

Once the remote was apart, I traced the various buttons and saw how they worked. Essentially the board had a series of buttons, all with 12V on one side, and ground on the other. Pressing the button allowed 12V through to the other side and the IC did its thing to send the correct signals. I figured that whatever smarts were required to make the 433MHz stuff was already done via the IC, so there wasn’t much point in me trying to replicate that. As it happens, this was a good approach, as the IC allows for some fancy pairing of multiple remotes to the same socket (which I use now), and if I’d been able to DIY the 433MHz stuff, I’d still not have thought of that until it was too late. So the basic process is to use the Arduino to send 12V to the low voltage side of the button, for each of the 6 buttons (on and off for 3 sockets).

Pretty straight forward. And at least you know all the challenging waveforms are already covered! How are you powering the Arduino and hardware?

From a DC plug pack. The Arduino runs on 5V but will accept up to 12V via the DC plug. The remote itself runs on a small 12V battery, so powering it via DC was easy enough. Both devices share the same 12V DC source, and for the remote I just routed power from the bottom of the standard Arduino DC plug to where the remote plugs in. Simple and elegant.

But from my experience in mounting a temperature display on a motorbike, I decided it’s best to make everything dismountable from the start. Therefore, the remote is connected to the controller by two cables: one two-core cable for the 12V, and cat5 for the various signal wires required to trigger each of the buttons.

I recalled a time when I was fooling around with a 12V car battery. I’d hooked up the ground to the battery terminal, and was readying to affix it somewhere when I dropped the other end onto the positive terminal. Maybe I should have known better, but at that moment it fused itself in place. And so when I saw the insulation starting to smoke, my first reaction was to pull the cable off. Of course it didn’t come off, it stayed right there, resisting my effort and now glowing red into my hand. That hurt - a lot. And at that point I think I started to fear electricity.

So as you can imagine, I really wanted to prevent any shorts. One way I thought it may happen was if the 12V from the DC made its way to the 5V rail of the Arduino; that would have cost me time and $25 for a new Arduino! I knew I had to keep things separate so I did some research and came up with a nifty little thing called an “optocoupler”, which has six pins, but I only had to worry about four of them. It worked like a switch, as I could trigger the switch using the same code I’d used to blink an LED in Arduino code. Simple! I could put 12V on one pin and get 12V on another pin if the LED was on. I could manage that. But that means four pins for each thing I wanted to switch (plus the other two that I could ignore). For any given AC socket, there are two optocouplers required (one for on, and one for off). So that’s eight pins so far, ignoring the other four. But a brew fridge is often required to do more than just cool - sometimes it may need to apply heat too. So that’s another two optocouplers, making 16 pins to care about and 8 to ignore.

Wiring all that up wasn’t much fun, and I think I did the two and then stopped for a while. Eventually I got back into it - probably after I’d run out of more fun stuff to do. The hardest bit was keeping track of the various pins as I flipped the board over and back, and over and back again.

Veroboard can often be a challenge. It’s funny how muddled all those connections can get flipping the board back and forth! Are you simply listening for one input (time or temp, etc), or can you combine variables for “if > 6pm and >30°”, etc?

For the brew controller (at that time), I didn’t have a need for any time-related functions, so the hardware didn’t yet include a real time clock (RTC). I had some pretty simple logic, which was simply turn the fridge on if the current_temp was higher than the set_temp (or else turn the fridge off), Due to an effect called “hysteresis”, there’s a lag between when the fridge came on, and when the current_temp approximated the set_temp. Often the current_temp would swing below the set_temp with the fridge on, and current_temp would go higher than set_temp with the fridge off. As a function of the thermal mass inside the fridge, if set_temp was fixed, current_temp would oscillate either side of it, and when current_temp and set_temp were close, the oscillations would be higher frequency (which happened more often). Of course, messing around with the threshold can reduce the number of oscillations. Subsequent to all this I learned that programatically setting these thresholds in an attempt to reduce the temperature differentials in a closed loop “learning mode” is the way to achieve quite accurate temperature control (this is what the PID controllers do).

So I had thresholds okay, but then I discovered a compounding problem; it turns out that the compressor in the fridge doesn’t like being turned off and back on again quickly. The recommendation is that you wait at least five minutes for pressures to equalise (or something), so that the starting load on the compressor isn’t too high. Thankfully I didn’t break my compressor, but what I did discover was that I needed an RTC to measure how long the fridge had been running. Being Arduino, I just went and bought one easily enough, but then realised that the pins I needed to use conflicted with stuff, so I went away and had a sulk. Beer drunk, I mapped out a new pin assignment schema and (the following day) resoldered appropriately.

And of course, that meant my basic logic was no longer sufficient. I now needed something approximating:

if (current_temp > set_temp) AND (duration > 300 seconds) then turnthefridgeon() 

where duration is the time that the compressor has been running. This then meant I had to somehow be able to record duration in seconds. I’m from a UNIX background, so doing time math in seconds is easy if we can represent the time in seconds since Epoch. From Wikipedia, “UNIX time (also known as POSIX time or UNIX Epoch time) is a system for describing a point in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, minus the number of leap seconds that have taken place since then”. Right. So I record Epoch (in the NV RAM onboard the RTC) when I activate the compressor, and then I can easily do the math to determine the duration for which the compressor has already been running.

Now - time_when_compressor_was_last_activated = duration.

Okay, so I just needed to call some Epoch time thingie from the time library... except nobody had written exactly what I needed, or my Googling couldn’t find it, so I managed to pull apart someone else’s efforts and recode it to suit my needs (go open source!), which I found at http://forum.freetronics.com.au/viewtopic.php?f=15&t=6506

I must admit that seeing my LCD output in UNIX time was a profound pleasure.

So that was the temperature controller done. I ran it for a while and it worked well enough. As it happened, the fridge itself was outside and it was summer, and someone said to me “dude, it’s 35 degrees on your deck, and you’re trying to maintain a controlled environment in there”. Fair point. By the time I’d ended up having a fridge inside, the brew controller had been sitting around too long and had been repurposed.

As a computer systems engineer, if a problem can be solved by automation then it’s a problem that I don’t have to deal with again, so instead of dealing with problems, I just deal with automation problems instead (two problems instead of one!). Anyhow, at the time I had an eight-year-old boy who thanks to the love of his mum, loved to read. This meant at bedtime (i.e., lights out), despite polite requests, not so polite requests (and so on), the lights didn’t go out. That was the problem. The solution? Arduino! I wrote a new sketch that turned on a given socket as a function of time, and the Star Lights Controller (for want of a better name) was born!

“If a problem can be solved by automation then it’s a problem that I don’t have to deal with again” - words to live by! But you’re right, automating a process can be tougher than the original problem! Do you have any manual override functionality? Say if your boy wakes up in the night and you need to turn the lamp back on?

Yes. Because I simply simulate the button press on the remote, I can physically press that same button to manually send the same signal.

But even better than that, the remote system I ended up choosing allowed me to pair more than one remote to a given socket. So we actually have another remote stuck to the wall outside his room. This way he (or we) can press the button assigned to the socket in his room and the lights turn on. And at bedtime (lights out) the controller will turn them off again. Well, in fact I got clever. He’d complain that the lights just went off and he had no warning so I now have the device turn the lights off for 5 seconds, which indicates it’s 10 minutes to lights out. Then for 10 seconds with 5 minutes until lights out. For this, I was quite pleased I could reuse my UNIX time function again!

Ah the UNIX timestamp... whatever will we do after the UNIX Epoch in 2038? Probably just add a one... Anyway - anything else we should know about your project?

It still works! Except my boy worked out he could pull the LCD off the Arduino stack and the net effect was that it wouldn’t turn his lights off! I’m thinking the next version would be electrified like the car from Robocop. That’s a joke by the way!

Those cheeky kids! They’ll always find a way! If you started this project again from scratch, with the knowledge you have now, what would you change?

Having to reflash the device to transition to and from daylight savings time is a bit of a pain. I should have included a physical on/off switch and used that to implement a DST time offset.

The system has no idea if the lights actually went out, since there’s no feedback. I’ve been very lucky that there’s been no issues with reception of the 433MHz signal, so it’s been quite reliable in that way. I have other systems where they fail badly because they have an internal record of state, but can’t test that against reality. Have you ever seen a CNC mill break itself in the absence of functional limit switches?

I’d probably more closely examine what was available on the market. When I did get the fridge inside our house, I thought of all the effort I went through with the homebrew controller, and just went and bought an ITC-310. It did everything I wanted, and where I didn’t like the cabling design, I just fixed that instead of reinventing the whole wheel.

One thing we don’t really do is effectively cost our time. Sometimes we’re on a high, running on motivation and it’s all awesome. But sometimes the motivation is gone, and we’re running on emotional energy that also has a finite limit. It’s easy to believe in the sunk cost fallacy where “your decisions are tainted by the emotional investments you accumulate, and the more you invest in something, the harder it becomes to abandon it”. I think it’s important to try and remain objective, and make sure you can sustain yourself until the project is complete.

That’s true, but there’s a learning experience as part of it, which we can’t usually put a price on. What exciting (non-time efficient) project are you working on now?

I have a new job at the moment, and I’m working on introducing continuous integration into the supercomputing environment at the Bureau of Meteorology. It means we can do reliable and repeatable software builds. But if I get the chance to play around, I’m either making more beer or playing Factorio. You’ve never played Factorio? Oh my, well I’m so glad you asked... check it out at www.youtube.com/watch?v=Dl6VJv61rKk

Oh - so nothing much then (we’re joking!). Thanks for taking us through this project and your history - we can’t wait to see what you come up with next!