Internet of Curtains version 0.1

My outside curtain box has reached its first prototype.  If you recall my post about IoT, I am working on a box that can control my outside blinds and also send a ton of sensor data back to a command center.

For my first prototype, I was focusing on the high-voltage power.  Here’s where the power comes in:


Standard plug with a little power switch and a fuse.  Nice when you’re dealing with 240V.  To make the switch and fuse work, this is the wiring on the back:


The socket-thingum I use already wires one phase to the fuse (the metal plate at the bottom), so I just have to continue the tradition to the switch (the blue loop on the left).  One might reasonably argue I should have used a brown piece of wire for that loop or swapped the brown and blue wires, but eh.  Also I obviously shouldn’t quit my day-job to become a solderer – that’s a job better suited for Chinese toddlers with their delicate little hands.

The entire reason I want high voltage in the first place is because my blinds take 240V in.  To do that, I made this contraption:


Power comes in at the lower right from the socket and is split out to the wire running along the bottom, which ends in a plug from Molex that plugs directly into my power supply.  This is not used for now.  The brown wire goes into both of the relays on the left, and the output of the “normally closed” pin of the relays go to the join at the top right.  That’s three wires which takes zero and two phase wired (one for up and one for down).  One might even more argue that I should not use the yellow/green wire for zero (that is normally used for ground and should not be part of the circuit!), but this is just a prototype; the final version will not have this extra piece of wire but instead plug in the wire from the blinds directly, and that’s a nice blue/brown/black + earth piece of wire.

I could have hooked up the relay differently; here I allow sending power to both up and down at the same time, which should not happen; by instead hooking the “normally closed” output of the one relay into the input of the other, I could instead have made a switch where I had one switch for up/down and one for move/in place.  I decided against that as it will be harder to make a manual override as this requires two presses to start moving from still instead of just one and if you press both up and down at the same time you are dumb anyway.

At the left, we see 5V power for the relay (red/black) and two signaling wires.  These plug into the brain of the operation:


Currently, I use a Raspberry Pi 3 for control.  That’s way more than what is needed and is mostly based on the simplicity of getting started and also I had one, whereas I have not received the actual board I want to use for control.  Right now, power and signals to the relays are just hooked directly up to the signal pins of the Pi (bottom right).  At the top we see HDMI and micro USB for display and power, and at the left we see Ethernet and USB for internet and mouse/keyboard. I use the keyboard all techies swear by, the Keyboard for Blondes.

To control, I’m using Node RED, a super-simple visual language for controlling the outputs of the Pi:


I use pin 11 and 15 for signaling and have hooked it up to simple switches on the screen for controlling whether they are high or low.  Pin 7 at the bottom is used to control a separate LED so that’s probably more important.  Node RED also allows me to trigger using a web-service, so I’ll probably extend the prototype with that and then integrate into OpenHAB for centralized control along with my Hue lights or Homebridge, which allows me to integrate with Apple Homekit, so I can tell my watch to open or close the blinds.  From what I see in the source code, it should also be possible to use OpenHAB with Homekit, so I might try that as well.

So far, this actually all works and shows us a glimpse of the world of tomorrow:

For the next version, my first priority is to go away from using the signal pins directly from the Pi and instead using an I2C extender:


As you can see, it has actually already been hooked up to the Pi (that’s why there’s extra wires going out of the Pi above).  The pins at the top of the board comprise 8 extra signal pins, the jumpers in the middle allows configuration of the I2C address of the board, and the sockets on the right allows daisy-chaining with other I2C devices (such as the sensors I’ve yet to receive).  The reason for using I2C instead of just using the signaling pins directly is that the board I will use in the end doesn’t have direct signaling pins; just one I2C port.  The reason I’m not using it right now is that I’ll need to install extra modules for Node RED to be able to control I2C and also that the board came with zero documentation, so I’ll have to somehow Google that or reverse-engineer what to send it.

Next is also hooking up the neat little power supply I have instead of that micro USB one I currently use, so everything is powered from the one plug at the top of the post.


The main reason I’m not doing so right now is that there’s literally no reason to, and as the power socket has a lot of exposed wires, even when switched off, I prefer not having it switched on while working.  This goes counter to me wanting to have the Pi switched on because I use that for looking up documentation while I work.  That’s a safe and sane way of working.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.