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 ATmega328p (aka Arduino microcontroller) to make use of these items and create a standalone Ethernet control unit.
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 take care when working with any high voltages. Good advice here.
There are two versions of firmware for this unit
- One that allows you to use this with a webpage - no xAP required.
- xAP enabled.
The source code for both versions can be found in the HAH Google project.
https://github.com/dbzoo/hah/tree/master/userapps/arduino/EthRelay
The only dependency is the EtherCard library API from Jee Labs.
Web Enabled
The web interface has been designed so that it works from a mobile phone or tablet surface, however any browser is good.
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:
- /main.html - Outline shell
- /main.css - Style sheet
- /main.js - JQuery javascript to populate the UI
- /list.json - JSON data of the state of the relays
- /relay0 - Toggle relay
- /relay1 - Toggle relay
There is no password or security mechanism so if you are going to expose this web-server on the internet you might want to consider altering the code and/or putting this behind an authenticating proxy.
xAP Enabled
Watch the short demonstration video of a unit being controlled with a 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.
target=dbzoo.ethrelay.unit:relay.*
This should operate on both relays.
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. Given this is the case there is no wildcard subaddress 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.
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. 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.
Sample xAP message to toggle relay 1
xap-header { v=12 hop=1 uid=FFBEE900 source=dbzoo.acme.test class=xAPBSC.cmd target=dbzoo.ethrelay.unit:relay.1 } output.state.1 { id=* state=toggle }
If you are using a Joggler to control this relay, here is a snippet to get you started
<button NAME="ethrelay1"> <label> <text>EthRly 1</text> </label> <gridX>2</gridX> <gridY>1</gridY> <style>glossy_button_off_.png</style> <xAP> <schema>xAPBSC</schema> <uid>FFBEEF01</uid> <source>dbzoo.ethrelay.unit:relay.1</source> </xAP> <mode>control</mode> </button>