New NodeMCU Project: Garage Door Monitor

The Objective

For whatever reason, our garage door opener doesn’t work reliably when it’s cold. Only the remotes that are inside in the warmth actually work so we have to remember to close the garage from inside the house. Sometimes it’s forgotten and the garage door is left open. There’s no way to see whether or not the door is open from inside the house. Thus, this project came to mind.

The main objective is to create a wireless way to know whether or not the garage door is open.

The Planimg_20170126_190721

The plan is to use two NodeMCU boards. One inside the garage will talk to the other inside the house. The one in the garage will be connected to a limit switch which will be closed when the door is closed. The one inside the home will have some sort of indicator that will tell us whether the door is closed or not. This will likely just be a labelled LED.

These Two Don’t Like Each Other

I received the two NodeMCU boards in two weeks from China. The experiments trying to get them to talk to each other (one as an access point, the other as a client) did not work out. I went hours trying to get something going but I couldn’t, so I went back to something I knew already, which is to have it talk to some PHP code hosted on my website.

The NEW Plan

I wasn’t planning on having the internet involved but I actually think it’s going to be a better idea. This way, I can get something going with just one board and then integrate the second one into the project later. I can check the status of my garage door right from my phone’s web browser from anywhere. The future is here people!

 

The new plan has a couple phases.

Phase 1: Set up one NodeMCU in the garage with the limit switch. The switch will send the status to my website which I can then check to see the status of the door. I can use some PHP code to send me an email if the door has been open unusually long.

Phase 2: Have the second NodeMCU connect to my website and build hardware around it so that anyone that walks in the front door can see whether or not the door is closed.

Progress Update

img_20170129_151905

It’s been going pretty well so far, even with it’s problems. I’ve got two limit switches sending values to a MySQL database hosted on my website. (The full process: It accesses a URL with the switch values inserted into them, and then some PHP code on that page grabs them and inserts them into the MySQL database table.)

BTW, I am using the Arduino IDE to program the NodeMCU.

screenshot_20170130-091040-01

I have no issues with it inserting values. The big issue I’ve been having is I haven’t gotten it running for longer than two hours at a time. I don’t know if it’s something on the server’s end or if the NodeMCU is hanging or something. It took me a while to get it to wake from deep sleep without doing something weird so I suspect it may have something to do with that. If this issue keeps going on, I may stop it from deep sleep and see how that goes. It’ll draw more energy but I’m leaning toward giving it a wall plug.

Keep Following the Project

I hope you enjoyed this first update post about my first NodeMCU project! Stay tuned for more!

screenshot_20170131-174839

If you’ve got Instagram, follow me as I’ve found it to be an easy way to share progress updates as they happen.

A Dry Christmas (Light Show 8 Update)

In the first update for my next Arduino Light Show, I went through some of my experiments with my fountains. After some thought, I had planned on scaling it back but, in the end, I decided to scrap the fountains all together from the next light show. Despite the loss of the fountains, there are still new things to see!

img_20161019_181202

OK, so this is not really new. I made this weird Christmas tree last year. It was rather last minute so I didn’t do much with it. The plan now is to incorporate it into a new Light Show. Actually, it’s going to be the main feature.

I did a little bit of cleaning up. I cut the base into a circle and painted it black, trying hard to avoid painting over the LEDs.

img_20161021_194229

Here’s something new… well, again, sort of. I’ve done LED “spotlights” before by strapping 5mm LEDs to a servo motor. What’s new this time is that I’m using two servo motors per spotlight to make it pan and tilt. I’m also using WS2812B LED modules like on the tree. More movement and color should make the spotlights more interesting than before.

img_20161112_225030

After testing out the concept, I made an army of four.

img_20161119_204021

Some LED tests.

20161119_221619

I painted the spotlights all black as much as I could so that they’ll blend into the darkness.

So that’s the current state of the next Arduino Light Show. I had some other ideas in mind but I wanted to leave lots of time to get what I have here ready and programmed. We’ll see how the next little while goes. Thanks for reading!

The BIG opening update for the next Fountain Show

If everything works out in the very end, this will be one of my best projects to date. And really, with everything that has happened so far, it has been one of my best projects to date even if nothing actually works yet. I’ve experimented and learned a lot and, even with the bouts of wanting to quit, I really want this project to work because, again, it will be my best.

20160711_102151

I made a pool for the fountains out of scrap polypropylene sheets I got from work. I painted it all black because I thought it would benefit the lighting effects, as well as hide any imperfections better.

The white support beam running through the pool is where I would mount the fountain nozzles and LEDs.

20160711_113934

I’m trying my best to keep things organized and clean. I drilled holes for the pump wiring so that there wouldn’t be any excess wiring sitting in the water. I also used a silver marker to label them.

20160711_173741

Things started coming together as I had imagined. I used transparent tubing from the pumps to nozzles mounted on the support beam. The nozzles were made out of tubing that’s slightly more rigid. There’s also a smaller diameter tubing that I hot glued to the end to reduce the opening.

20160711_173830

Looks good so far…

20160711_173902

Heat shrink and electrical tape was good enough insulation with all of the water splashing every where. I decided to try another method of waterproofing certain connections which was to use short pieces of tubing and flooding it with hot glue on both ends. The connection in the picture is the splicing of the fountain wires to my own solid-core wire which is a likely point for failure.

20160711_194459

Once I was satisfied with the tubing, I threw on some more black paint.

20160714_145703

Next were the LEDs. They’re WS2812B modules (the little circle PCBs you find on eBay). I put them in little plastic cups to protect them from getting wet. They’re open on the bottomside but the LEDs are held inside of the cup with lots of hot glue anyway. I didn’t have any issues while testing them with water.

20160715_213212

And here’s where things started falling apart…

I barely ever used paint until recently, so I learned the hard way that it’s not very water proof, at least when applied on smooth plastic surfaces. As soon as the water started flying, the paint started peeling.

The other concern I saw was the aim of the fountains. The nozzles are round and are attached to a round support beam, so, while it looks good by eye, it didn’t turn out very straight. The pumps struggle if the fountain streams are exactly vertical so I tend to shoot them slightly backward so they sort of look vertical when viewing the fountains from the front. Anyways, I have some ideas on how to fix this which you’ll see in a future post.

The pump on the far left didn’t seem to respond so it either got through my quick dry tests before building or I fried it while setting up.

Also, no idea where the foam and bubbles are coming from…

20160715_215635

So clearly I’ve still got a lot of work ahead of me. Main things on the task list:

  • Scrape off all of the black paint on the inside of the pool. The outside black paint is fine.
  • Double check all of the pumps.
  • Replace support beam and nozzles.
  • Add a drain to the pool somehow.

Thanks for reading!

Happy holidays! (Christmas project 2015)

Last year’s Christmas holiday project was the “Make A Wish” fountain show. My original plans for this year was to follow it up with an updated set but I couldn’t find the time or motivation to do it. Instead, I decided to do something simpler.

20151222_190705_001Behold! A modern-style Christmas tree! It’s made out of foam-core board and has eight sides which are lit up by WS2812B addressable LEDs.20151222_190631With the room lights off, you can get a better sense of what I was going for. I am very happy with the way that it came together, considering how little time I gave myself. This was almost all done on a Sunday.20151221_193338It’s one of my larger projects, with the base being 50x66cm and the “tree” standing at 52cm. I’ll have to find somewhere to put it because I would love to work with it next year.20151222_190933_022One amusing observation which I hadn’t planned for was the fantastic pattern the project projects onto the ceiling.

Thanks for visiting my blog! I hope to find some time to write up a year-in-review-style post as I did last year. Stay tuned!

A look at a cheap USBtinyISP board

On my most recent revisions of my breakout boards for the Atmega328p and Attiny85, I added a 6-pin ISP header. ISP stands for In System Programming, which, as the name suggests, means that the header is used to program the microcontroller as it sits in a circuit, which is especially handy for boards without a way to plug directly into your computer’s USB port or a board with a surface-mount microcontroller.

I’ve never actually used these headers since I was used to using my Arduino Uno to program the microcontroller for both of my breakout boards. To make sure I could add the 6-pin ISP header to the boards correctly, I read up on it from different sources to understand how to make the connections.

attiny85pinoutisp

On the pinout of the microcontrollers, there are pins labelled SCK, MISO, and MOSI. These are three of the six pins of the 6-pin ISP header. The other three pins on the header are pins we all know well: Reset, Vcc, and Ground. The asterisk on my boards signify the first pin of the ISP header, which should be the MISO pin. The illustration of mine uses the pinout image in the Attiny datasheet where the six pins are underlined. I also drew up a simple diagram of the header pinout.

I received a cheap USBtinyISP board from China which took quite a while to get here. Thankfully it didn’t take much longer to get up and running.
IMG_20150704_125604The board came with a 6-pin ribbon cable and a USB cable. The USB cable is so short that it’s virtually unusable since the cable isn’t long enough to get the board to my desk from my computer. Thankfully, I have a longer cable I can use instead.

The first thing I did was to check the pinout of the cable so I don’t plug it in the wrong way on my boards. The easiest way the figure out the orientation of the header is to find Vcc and Ground with a multimeter, where you should see 5v across. It’s a 50/50 chance… so of course I got it wrong the first time as I saw the voltage reading fluctuate in the mV range.

Once I got the orientation of the connector right, I plugged it into one of my boards. I marked the first pin with a little sticker, as shown in the picture above.

Surprisingly, the Adafruit USBtinyISP drivers works with this board. I opened up Device Manager and updated the drivers with their files. The seller of this board had their own hosted driver files, though some poking around showed it was just the Adafruit drivers anyway.

IMG_20150704_124751First up was my Attiny85 Breakout Board. It’s not meant to fit into these half-sized breadboards but bending the power pins a little bit got it in. (If you bought one of these boards, don’t do this. This is a test unit, after all.)

I was able to upload the blink sketch directly from the Arduino IDE, with the Attiny85 settings and setting the programmer to “USBtinyISP “. The timing of the blink sketch was weird the first time I tried it, which made me realize I must have previously burnt the bootloader to use the 8MHz internal clock instead of the default 1MHz. I decided to try burning the bootloader so it would go back to using the 1Mhz clock. The USBtinyISP was able to do it and the sketch ran perfectly.IMG_20150704_124905Now for the Atmega328p Breakout Board. To upload through the USBtinyISP and the Arduino IDE, I can’t just click Upload like I did with the Attiny85 board. I have to hold shift when I click the Upload button to Upload Using Programmer. This is supposed to upload the sketch to the microcontroller without needing a bootloader. Once I upload a sketch with the USBtinyISP, I can’t upload a sketch if I place it in an Arduino Uno, so I guess that uploading with a programmer erases the bootloader…? To be able to use the microcontroller on an Arduino Uno again, I have to burn the bootloader with the USBtinyISP board. It’s not a big deal, but it’s something I have to remember to do so I don’t get confused why things aren’t working later on.

So with the FTDI and USBtinyISP programming tools at my disposal, I’m very excited to get the next revision of my Atmega328p Breakout Boards as they have headers for both devices. Stay tuned for news on that! Thanks for reading!

Something new for my toolbox: FTDI Basic

IMG_0001smI decided to pick up an FTDI board so that I can explore a new way to program the Atmega328p, specifically to see first-hand that it works so I can implement an FTDI header in the next Atmega328p Breakout Board. The FTDI Basic is a Sparkfun board, though I purchased it from RobotShop because they can ship within Canada.

I believe the one feature that sets it apart from the USBtinyISP (what you use those 6-pin ISP headers with on the Arduino, etc) is that enables you to do serial communication. This makes it a lot better for prototyping since you can debug using the serial monitor.

The original purpose of the Breakout Board was to take over from your Uno once you are finished prototyping… not really to use it to prototype. Technically speaking, there’s nothing wrong with prototyping on the Breakout Board, but it’s not currently breadboard-friendly and it only got a programming header (ISP) in the last revision. It sounds like an excuse, and it is, but to keep the board small while keeping the pins in order, it’s hard to organize the traces in the restricted amount of space to make the board breadboard-friendly. It’s a learning process with each board and revision so I hope I have learned enough to make it happen with the next one!
IMG_0001smAnyways, in short, the FTDI Basic works perfectly. I tested it with this Atmega328p setup on a breadboard. After installing the FTDI drivers, I was able to upload new sketches and print things to the serial monitor.

The one odd thing is that I had the understanding that to upload using the FTDI board, I had to hold shift while clicking Upload in the Arduino IDE, which changes it to “Uploading Using a Programmer”. That didn’t work. After a few searches, it turns out that changing the Programmer in the IDE to “Arduino as ISP” does the trick.

Getting up and running with the FTDI Basic so quickly makes me eager to get it into the next Atmega328p Breakout Board. I’m on the fence about keeping the 6-pin ISP header since you have more functionality from the FTDI chip (serial communication). I’d like to keep both, but if I can’t fit both on the small board, the 6-pin ISP header would be the one to go. Stay tuned!

The bad servo-RF mix

A long while back, I purchased a couple of RF transmitter and receiver pairs. My idea was to make a remote controlled robot. I did do some experimenting with it before but nothing came of it at the time. I tried some more experiments today and, well, I broke more things, but I also confirmed a few other things that will sway where this project goes, if it does go anywhere.IMG_0001For the transmitter, I used an Arduino Uno. At first, I used it for the receiver, just so I could make sure the communication was working fine via the serial monitor. Once that was ready, I swapped the transmitter and receiver on the two systems. Using the transmitter on the Uno allowed me to change what was being sent instead of setting up a hardware circuit with buttons.IMG_0002Here’s the receiver. It uses my ATmega328p Breakout Board (Rev B) and my old AMS1117 voltage regulator board. I used my 16 SMD LED board and an LCD for debugging purposes.IMG_0003Before the servo motors were thrown into the mix, I tested the communication between the two separate systems. I’ve gotten the hang of it. I can edit the transmitter code to send as many characters I want. The only time I need to touch the receiver code is to change what the system does with the received data (the conditional logic).

I accidentally wired the power connections (Vcc and Gnd) to one of the servos backwards. It got really hot at that point and now it doesn’t work. I decided to take it apart for fun and will share those photos in a future post.

And after that, my problems with the servos continued as I realized the servo and virtualwire libraries try to use the same interrupt timer. To get around it, I’m trying to use the ServoTimer2 library which uses another timer. It wasn’t working properly for me so I’ll have to look into it more, but I think I’m just using the library wrong. You can take a look at my code on GitHub. It would make things easier if I just used DC motors instead of servos, but I’d rather use parts I already have. I do have another idea for these RF pairs so, even if this project is lost, you’ll still get to see them in action elsewhere…

Thanks for reading! Stay tuned if you’ve ever been interested in seeing the innards of one of these micro continuous rotation servo motors! That’s coming up next!