How to make an Amazon Echo Dot work with your old HiFi system (with a little help from a Raspberry Pi)

So I imagine many people connect their Echo to a modern Bluetooth speaker which achieves the convenience of always being on and the eco-friendliness of not using much energy when idle. Well, I haven’t got one of those. I have an old JVC stereo which you have to power on manually. Luckily I also have a Raspberry Pi which, as you will know, is able to solve pretty much any real world problem.

1. Convenience

I do not want to have to press the power button on the HiFi to hear the Echo.

So you’ve plugged the Echo into your hi-fi (and not even bothered to remove the Airplay device which you never wanted but couldn’t afford Sonos), now what?

You need to use the awesome power of the Raspberry Pi to….control an infrared LED. I admit that controlling a single LED seems a waste of the Pi’s abilities but at least it’s cheaper than forking out for a Logitech Harmony hub.

Don’t have an infrared LED? No problem. Just desolder one from a remote control.

Then follow some instructions on how to get your Raspberry Pi transmitting IR signals.

If you can’t find the Lirc codes for your remote then you can use Lirc to record the signals from your remote. Of course you’ll need an IR receiver to do that. Don’t have one? Just desolder one from a set-top box.

Eventually, you’ll end with something that looks like this:

I should stress that electronics is not my forté.

I followed Amazon’s tutorial on how to create a Smart Home Skill. If you want to do it in Java and need some inspiration then look in my GitHub repository. I’ve even started creating the domain model which doesn’t seem to exist in the Alexa skill jar. ProTip™: When using Java in an AWS Lambda start an instance with a lot of memory so it loads faster.

I did have a problem enabling the skill from the Alexa app on my phone. In the end, I got it to work by using Firefox and pre-logging into my Amazon account (it took quite a few attempts though).

The last piece of the puzzle is to “web-enable” the IR functions of your Raspberry Pi so that the AWS Lambda function can call it. To get going quickly I used a Python project from this guy. You’ll need to create a hole in your home network by mapping a port to the Pi. I will deal with this security issue another day (I don’t want China turning on and off my home electronics).

At this point, I can now say “Alexa, turn on the kitchen hifi”. Convenience achieved.

Bit of delay switching on the hi-fi as the AWS Lambda takes time to start.

I have also considered attaching a PIR sensor to the Pi so that it turns on the hi-fi when you walk in the room.

2. Eco-friendly

I often forget to turn off electronics when I go to bed – I don’t want to leave the HiFi on all night

Now that all the hard work has been done this part is pretty simple. The simplest approach I could think of was to use systemd timers to schedule a curl call late at night. One minor issue being that I wouldn’t know whether the HiFi was currently on or off. Luckily sending the ‘AUX INPUT’ command over the infrared switches on the HiFi. So I can guarantee that the HiFi will be off by first sending this command followed by the ‘POWER’ command a few seconds later. This means the HiFi will briefly be turned on even if it was already off but that’s acceptable.

Another way might be to set up an Alexa “scene” so that I can turn off lots of electronics when I go to bed.


For my next project, I need to buy another Echo and another Raspberry Pi so I can control my TV. If a can control my Roku then hopefully I can make Alexa play a movie from my:- Netflix; Amazon; Now TV; Plex services.

Java 8: A poor man’s functional language

It’s all about immutability

I was having a pint with some Java peeps the other week and was hopelessly trying to explain why Java 8 is not a proper functional language (I’m thinking about
Haskell and Scala…not Clojure because this text is already in brackets and I don’t want any more of them).
We were 2 pints in and I think I opened with something like, “it’s all about immutability”. This statement provoked absolutely no response from those gathered. In fact, I whittled on for another 2 minutes without eliciting so much as an eyebrow raise. I tried to backtrack with, “you remember what Josh Bloch says in ‘Effective Java’ about immutability. It never made sense to me at the time but now I see why”… still nothing.

The reason it never made sense to me is because it was wholly error prone. The developer had to make sure all fields were final and that getters and setters were defined properly. Then you had to make sure equals and hashCode methods were correctly implemented. Admittedly you could get the IDE to generate all this boilerplate for you but you still had to go through the bore of doing it. Enter Scala’s case class. No need to generate boilerplate. No temptation to make introduce mutability into the class – because you can’t.

Why is immutability key? Well, there’s the quick response how it makes concurrency safer and hence easier. But why is that? Well if concurrency is safer then it’s most likely because your code is less side-effecting. I would go on to argue that if there are less side-effects then your code is most probably easier to read and easier to reason about. I’m sure many would disagree as Scala code can have the unfortunate propensity to never declare variables. A lack of variables can create dense code which takes more than a cursory glance to understand – but you do get used to this, trust me.

If code is easier to reason about then, I would argue, it follows that more complex business logic can be written. As Scala achieves higher levels of abstraction (e.g. with Futures) then it is possible to write code that does more, faster and better.

Immutability makes even more sense when you consider microservices or technologies like Akka/Spark. If units of data are being sent to remote systems then they must have gone through some serialisation/deserialisation process. This marshalling and unmarshalling of data is inadvertently enforcing some kind of immutability as memory pointers must reference some finite object graph. So what? If you are writing code that works with immutable data then you are most likely writing code that will work with all these new fandangled data processing systems. Which is a good thing!

An imperative programmer could counter with the argument that immutability is not “performant” and causes extra garbage collection. “Sorry, I see you are working with a list of a few thousand elements. Are you having some performance issues? Can your 486 not handle all that object creation and GC? …..oh no wait you have a 4Ghz i7. Yes I forgot it’s not 1990 anymore”. I have no doubt that working with immutable data incurs much more object creation and copying. But if you consider my point about how more complex business logic is easier to implement and understand then which is more expensive?

  1. New Xeon core server
  2. Team of developers trying to work out how some low-level, imperative code works (i.e. Java)

Gas! Gas! Gas!

Continuing from my how to create your own (gas) smart meter post…

Now that I have all the meter reading values I can produce a D3 graph comme ça:

Not massively useful I’ll admit but it’s a start. What I’d like to see is how much gas I’m using a day. So I’ll need to group the values by day and map them to another form. Map? Group? That sounds like a job for Scala!

The stored data is very simple:

A little bit of Scala allows us to workout the amount of gas consumed each day. I’m not saying this is the best way to do it – more just an excuse to use Scala.

Actually, as the boiler runs in the morning and the evening, I’d like to see the difference between am and pm usage.

(I have another version of these methods which are curried but I thought they were a bit nuts to show publicly).

At which point the data becomes a bit too structured making it difficult to feed to D3. So we flatten it again to:

Then we can get our daily usage graph:

Gridlines correspond to the right-hand axis so you can see cost. That’s a lot of gas being burned.