livebox:ethrelay

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
livebox:ethrelay [2013/09/10 12:28] – [xAP Enabled] minerva9livebox:ethrelay [2015/06/01 06:15] (current) – Change SRC URL brett
Line 1: Line 1:
 ====== Ethernet Relay Unit ====== ====== Ethernet Relay Unit ======
  
-Using a couple of off the shelf components; Ethernet module and 2x relay unit; we have purpose built a controller using the ubiquitous m328 (aka Arduino microcontroller) to make use of these items and create a standalone Ethernet control unit.+Using a couple of off the shelf components; Ethernet module and 2x relay unit; we have purpose built a controller using the ubiquitous ATmega328p (aka Arduino microcontroller) to make use of these items and create a standalone Ethernet control unit.
  
 {{:livebox:p1000723.jpg?direct&600|}} {{:livebox:p1000723.jpg?direct&600|}}
 +
 +The main board requires DC power (7.5V .. 9V). The onboard 7805 regulator gives us the power for the micro and the relays. A 3.3V regulator keeps the ethernet module happy. The use of four-way DuPont female to female cables for hooking up the relay & ethernet module allows flexibility when mounting these parts in an enclosure. A red LED indicates that the unit is powered. A reset button is provided. 
 +
 +The relay board has a couple of opto-isolated relays. Each rated at 10A for 250V. Be sure to [[http://www.penguintutor.com/electronics/electrical-safety|take care]] when working with any high voltages. Good advice [[http://www.hse.gov.uk/electricity/faq.htm|here]].
  
 There are two versions of firmware for this unit There are two versions of firmware for this unit
Line 9: Line 13:
   * xAP enabled.   * xAP enabled.
  
-The source code for both versions can be found in the HAH google project.\\ +The source code for both versions can be found in the HAH Google project.\\ 
-http://livebox-hah.googlecode.com/svn/trunk/userapps/arduino/EthRelay/+https://github.com/dbzoo/hah/tree/master/userapps/arduino/EthRelay
  
 The only dependency is the [[http://jeelabs.org/2011/06/19/ethercard-library-api/|EtherCard library API]] from Jee Labs. The only dependency is the [[http://jeelabs.org/2011/06/19/ethercard-library-api/|EtherCard library API]] from Jee Labs.
- 
 ===== Web Enabled ===== ===== Web Enabled =====
  
Line 22: Line 25:
 As the sketch by default is configured to use DHCP it's best that you setup your DHCP server to send out a static IP for its MAC address.  Its MAC has been hardcoded as de:ad:be:ef:00:24  (dead beef 0024). As the sketch by default is configured to use DHCP it's best that you setup your DHCP server to send out a static IP for its MAC address.  Its MAC has been hardcoded as de:ad:be:ef:00:24  (dead beef 0024).
  
-Under the covers it's exposing the following URLS:+Under the covers it's exposing the following URLs:
   * /main.html - Outline shell   * /main.html - Outline shell
   * /main.css - Style sheet   * /main.css - Style sheet
Line 34: Line 37:
 ===== xAP Enabled === ===== xAP Enabled ===
  
-Watch the short [[http://youtu.be/AT-DL1DpMtg|demonstration video]] of a unit being controlled with a [[xapflash#joggler|joggler]].+Watch the short [[http://youtu.be/AT-DL1DpMtg|demonstration video]] of a unit being controlled with a [[xapflash#joggler|Joggler]].
  
 As xAP is a broadcast protocol there is no need to know the units IP address. Having the unit use DHCP creates a ZERO configuration installation. As xAP is a broadcast protocol there is no need to know the units IP address. Having the unit use DHCP creates a ZERO configuration installation.
Line 45: Line 48:
 **Technical explanation why this does not work** **Technical explanation why this does not work**
 The problem is the receive ethernet buffer is also used for sending as we are tight on RAM.  So after the 1st relay WRITES its response into the buffer and transmits the 2nd relay when it goes to look inside for the incoming xAP frame that triggered processing it'll only find the outbound message and all the xAP parse states are messed up. The problem is the receive ethernet buffer is also used for sending as we are tight on RAM.  So after the 1st relay WRITES its response into the buffer and transmits the 2nd relay when it goes to look inside for the incoming xAP frame that triggered processing it'll only find the outbound message and all the xAP parse states are messed up.
-Given this is the case there is no wildcard subadress logic.  This is not a big problem just something to be aware of mostly everybody uses direct addressing anyway.  We might be able to fix this by separating the buffers for Tx/Rx but it's not a high priority item to fix.+Given this is the case there is no wildcard subaddress logic.  This is not a big problem just something to be aware ofmostly everybody uses direct addressing anyway.  We might be able to fix this by separating the buffers for Tx/Rx but it's not a high priority item to fix.
  
 Apart from that it's fully xAPBSC compliant.  It will send out a xAPBSC.event when it gets a xAPBSC.cmd to say it did something. Apart from that it's fully xAPBSC compliant.  It will send out a xAPBSC.event when it gets a xAPBSC.cmd to say it did something.
 If nothing happens for 2 mins it will send out a xAPBSC.info for each relay unit to let you know they are still there. If nothing happens for 2 mins it will send out a xAPBSC.info for each relay unit to let you know they are still there.
 Unit heartbeat will occur every 60 seconds and will include an ip= field so you can tell where this unit is. Unit heartbeat will occur every 60 seconds and will include an ip= field so you can tell where this unit is.
 +
 +The following image shows how the unit looks on xfxViewer.
 +\\
 +{{:livebox:ethrelay_xap.jpg?600|}}
 +
  
 Sample xAP message to toggle relay 1 Sample xAP message to toggle relay 1
  • livebox/ethrelay.1378816092.txt.gz
  • Last modified: 2013/09/10 12:28
  • by minerva9