Project Logs

Collapse

• Building the PSU​

  Jason • 09/19/2019 at 20:55 • 0 comments

  Since I was now going to re-build my LED controller’s power supply for the 3^rd time as I was getting ready to add another project to the central PDU; I decided to go big.  Include everything I needed with room to grow.  Add power monitoring so I know what was being used and whether I was close to overloading the power supply.

  Since DIN rail terminal blocks and breakers are easy to sources, standard size and easy to move; I decided to go with a din rail setup.  Cable management will be an requirement to keep everything looking good.  The management outside will be cut at 45deg angles to keep the faces looking clean.  The unit will be mounted to some shelving I have in my basement using some u bolts.

  Since my RPI3 that controlled my home automation was just sitting on a shelf, I decided to also include it in this project.   I got a DIN rail module that included a terminal block for the GPIO header so I can use them at a future time to provide LED status lights for the home automation or provide future relay control for the LED PSU.  The USB hub powers the PI and interconnects the Z-Way and Zigbee USB hubs.

  Both the high and low voltage systems have volt and amperage meters so I can monitor the load on the system and make sure everything is operating normally.

  Safety add-ons:

  Since taking these photos; I have added a ground loop on each DIN rail to prevent a nasty surprise if a hot wire hits a din rail while I am working. On the low voltage system, the power supply has builtin short detection and will kill power to the low voltage side of the system.  On top of that I added a GFCI break to the high voltage supply to kill power to the system if something or someone hits a high voltage wire.

  Plans are in the works to add 5Amps and 10Amp breakers for each LED strip so that an issue in one part of the house won't cause a major issue. Additionally a service disconnect will be installed to isolate the power for the PSU.  Currently I have to unplug it from the wall.  

  Testing Layouts:

  Final Layout. One(ish) section for high voltage, once section for low voltage, 1 section for the PI and 1 spare section:

  Cables ran and first power up:

  PI mounted the the module. Mounted to the shelving:

  High voltage section and future home of the service disconnect:
  

  Low voltage section:

  Home automation section: 

• Automated Curtain Rod Module

  Jason • 09/16/2019 at 16:21 • 0 comments

  The first new module that has been installed since the PSU has gone live was a MEDTech’s Remote Control Electric Power Traverse Curtain Rod controller.  The motor supported the ability to add your own controller via an RJ12 plug.  It breaks out to COMMON, OPEN, CLOSE and STOP wires.  I ran a CAT5 cable so I could use the 4 remaining wires for a possible future open and close sensor for when the ESP8266 reboots it would know the state of the curtain.  I choose not to wire this to the Raspberry PI because I like to have each control system to have its own controller to help isolate any issues.
  

  This module consisted of my room sensor (https://hackaday.io/project/167632-just-another-room-sensor), an RJ12 breakout (https://www.amazon.com/gp/product/B00KDKMZHI/) a relay module I had laying around.  All this was mounted on a spare piece of polycarbonate and that in turn was mounted to the DIN rail (https://www.amazon.com/gp/product/B0787WX58B/).  I left room on the polycarbonate so a second room sensor or JR12 breakout could be installed for any future control system that is needed.

  One lesson learned was not to install the relay on the control panel until all the bug were worked out. It was not fun having to run up and down the stairs to verify the correct relays were triggering….

  Board being assembled.  The relays are interlocked and the commons are tied to the NC connection from the relay to the left.  Relay one on the far left is STOP, relay 2 is OPEN and the 3rd is CLOSE.  By interlocking the relay, there is no way to send it more than one command.  I did not want to make any assumption that the motor could handle receiving both an OPEN and CLOSE command at the same time.

  Project code is running off of ESPHome (https://esphome.io/components/cover/time_based.html) and my control file can be found here: https://github.com/jchambers2012/JARS/blob/master/windowscontrol.yaml

  Wire guide from MEDTech:

  Mounted:

View all 2 project logs