Background

I have an old TV which was acquired used, without a remote. The power button has become a little finicky. Rather than going out and buying a new TV, or a universal remote, I thought it would be fun to build one. I had a Sparkfun ESP8266 dev board that wasn’t currently being used, and an Amazon Echo Dot in the same room as my TV, so I decided to make an Amazon Alexa-controlled remote rather than build a physical one with buttons.

As I had mentioned in my last post, I’ve built Alexa skills before, and to do this, you need to build a web service that Amazon’s servers can reach – something on the public Internet that can handle HTTPS. I wanted this service that was handling Alexa calls to control this ESP8266 in my home. I don’t like opening up ports on my home firewall, so I had to figure out a way to control the ESP8266 on my home network like every IoT device you can buy off the shelf. I hadn’t done this before, but I knew it was possible.

There seem to be a number of services to make this easy – I came across Blink.io and PubNub. Blink, in particular, seems like a good choice, as there’s sample code for the ESP8266 micro-controller I had decided to use. But in the end, I decided to use web sockets.

Building the solution

Most of the Alexa Skills tutorials are built on Amazon’s Lambda serverless compute service. But using websockets with Lambda seems to require using Amazon’s API Gateway, and I decided that was too much to take on for this particular project.

I setup the new skill on the Alexa portal, which I configured to call a VM I built out on Azure (I had free credits available there!). On this VM, I hosted a program I built with Node using Alexa’s ask-sdk-core library, and the websockets/ws library to build the web socket server handling the connection from the ESP8266.

On the ESP8266, I used the ArduinoWebSockets library to build the web socket client. Getting the ESP8266 to send IR commands to the TV was super simple. I connected an infrared LED to pin 4 of the ESP8266. Some article I read suggested using a transistor to increase current supplied to the LED, so I did. I used the IRremoteESP8266 for IR, and found the IR codes for my TV on http://irdb.tk/.

There is no authentication mechanism built in to web sockets. I decided that as I’m not scaling the service, and I’m just playing around, not to worry about it – if you use the code below, beware! The side effect is, every web socket client that is connected to the service will receive every command sent through the skill.

Solution in action

Here are some videos of the solution in action:

If you’re interested in trying something similar, you can check out the code here: https://github.com/raudette/AlexaTVRemote

I love my bike – it is a workhorse I can park anywhere, a mid-1990s hybrid. After years of limited maintenance, in the past year, I’ve had to replace a tire, cassette, all the cables, pads, grips, and shifters. I’ve also just upgraded my headlight and taillight – the improvements that have been made in bicycle lighting over the last 15 years have been incredible.

I’m using my bike more this year – my downtown office recently moved to a building with badge access indoor bicycle parking and showers, with towel service, for cyclists – what a cool perk. So, I’ve been biking to work for the first time since I started at this company in 2006, 17 km down Yonge St in Toronto, about twice a week since June.

My rides have been great. Drivers along my route leave a lot of space. But it’s hard to assess risk. The City of Toronto keeps detailed data on cyclists killed or seriously injured. There have been 11 KSIs on my route since 2008. But how do I compare that against, say, the risk of the 30 km drive to my Mississauga office? I’ve been rear-ended 3 times since 2010 commuting by car to Mississauga, but all have been at low speeds, only resulting in damage to my car – the consequences of getting hit on my bike are far more severe.

I was trying to think about what I could do beyond riding cautiously and ensuring I am visible. And, I have to say, a part of me is just always on the lookout for small, fun projects.

Envision a bicycle dashcam

Bicycle dashcams have been done before, by Cycliq and others. But I envision something difference, a bicycle dashcam that could:

• Recognize the license plates of the cars around you. From a picture, it would look at the plates on all the cars, and then associate a plate number with the picture
• Record the speed of the cars around you
• Record the proximity of the cars around you
• A driver readable display, ie: “Driver ABCD1234, your current speed is 45”. Like a mobile Toronto Watch Your Speed program sign. Would a driver allow a cyclist more space if they were aware their actions are being logged?
• Log this data on a remote server
• Share this data, with a group. Perhaps associate “near miss” data from many cyclists, and identify troublesome areas, or troublesome cars.

Introducing my Bicycle Dashcam, Mark I

My Mark I dashcam consists of a Raspberry Pi 3 with a Pi Camera (v1.3), a battery pack, running a small Node application which takes pictures, tries to recognize license plates with OpenALPR, controlled through a phone friendly web interface.

Testing and Results So Far

On the Pi 3, it takes between 8 and 800 ms to capture a photo with the Pi Camera, and another 7-8 seconds to run the OpenALPR license plate recognition process. I haven’t looked into optimizing this, but I would be curious to see how fast this could get by adding a processor optimized for these tasks, like an Intel Neural Compute Stick.

I’ve taken my prototype on a few drives, and a 5 minute bicycle ride. I don’t know why I even tried using a Lego frame to mount the dashcam to my bike – it only held together for a few minutes of riding, and completely fell apart – I’ll have to come up with something better for bicycle testing.

In the car, over a 30 minute drive (~120 photos) in traffic, about 15 license plates are identified. OpenALPR works exceptionally well – it can pick out the plate numbers even when it would be hard for a human to do so from the same photo. The limiting factor is the Pi Camera. At a stop, the pictures are fine, and OpenALPR will recognize the plates.

However, as soon as the car is in motion, the image is washed out.

I have spent some time tweaking the photos taken by the Pi camera, trying out different modes. So far, I haven’t been able to get great results.

As I look to take this further, I’ll look at other Pi camera options, run further tests on my bicycle, perhaps move the project to a mobile phone app, as my phone’s camera is significantly better than the Pi’s. Also, I may explore inexpensive LED matrix screens for the driver readable display.

Source code: https://github.com/raudette/plates

Six years ago, I built a wifi-controlled pop bottle sailboat. Smartphone control wasn’t great, so I turned my decommissioned weather station into a remote control.

My re-used weather station project board is a homemade Arduino board, with an APC220 transceiver radio. I added two rotary potentiometers for rudder and sail control. I removed the Raspberry Pi in the boat, and connected another APC220 transceiver to the Arduino Uno that controlled the sail and rudder servos.

We drove to Downsview Park and launched the boat.

Control still wasn’t great:

• Controlling the sail and the rudder is fine, but with the boat just floating on the pop bottles, the rudder has very little effect. Our boat design itself needs improvement – I think this is currently the greatest issue.
• My transmitter and receiver code could use some optimization – as I was troubleshooting at home, my code limited updates, and was only sampling every second – controls seemed “laggy”.
• I’m using very inexpensive TowerPro MG995 servos, which many advise against using. They were fine for playing around with interfacing, but they are slow, they seem to have a hard time holding their position, as well as not consistently reaching their programmed position.

I did write my phone number on the boat in case the boat got stuck in the middle, and someone else eventually found it. In the end, it wasn’t required. We just played with the controls as the wind carried it to the other side – probably about 100 m.

Maybe some time over the next 6 years, I’ll optimize the RC code, install better servos, and improve the boat design by adding a keel.

Ever since I read about the ESP8266 in Make magazine in 2015, I’ve been wanting to build something with it. I picked up a Sparkfun ESP8266 Thing Dev board at Creatron, probably a year ago, and let it gather dust.

Enter 35 degree weather. I have a window air conditioner, that I install in a metal sleeve built into our wall. For some reason, the sleeve is sloped such that water flows INSIDE. When the A/C runs on humid days, the water it collects from dehumidifying can leak inside, creating an unpredictable annoying mess that has to be cleaned up.

I could pickup a commercial leak sensor, but that’s not fun, the mobile app is probably not very good, it probably sends more information than needed to its cloud service, will never receive updates, and it seems like we’re always reading about IoT device vulnerabilities.

So, I bought a water sensor ($2.20!) in June, connected it to the dev board, and started to write a client in the Arduino environment for the ESP8266, and the server in Node.js. Then summer happened. Today, it’s August, its only 24 degrees outside, the A/C is off, and I’m done! The client reads the sensor every 10 seconds, and calls the server with a standard web service call, which will check the sensor reading, and send an alert by email if a water leak is detected.

The code is simple, but I had challenges getting the ESP8266 to HTTP POST a JSON payload. It seemed every example I found used different libraries or versions than the ones I had installed. I eventually got it working.

In the end, we didn’t have any leaks this summer in any case, and I don’t expect to make use of this project. If you’re interested in checking it out, you can download the code here: https://www.hotelexistence.ca/projects/watersensor.zip