Tag Archive: RF


An update on my latest project

Further to: https://tickett.wordpress.com/2012/12/31/a-new-year-a-new-project/ I have discovered quite a few things, and it looks like I’m not going to have to start from scratch (although I may still be designing some form of hardware, it’s hard to tell at this point).

Existing projects/products set out to do something similar:

NPlug- http://www.indiegogo.com/projects/283102/x/2060579

  • Consumption measuring (believed to be more accurate than existing devices)
  • Remote switching
  • WiFi connected (requires no bridge/gateway device)
  • Zigbee 802.15.4 for connecting to other devices
  • USB option (add 3G dongle, additional RF interface etc)
  • SoC running OpenWRT Linux
  • Open source
  • Lots more…
  • £100 (estimate)

This is really meant as a single device and not to be used with every appliance in the home. The device acts like a gateway itself and aims to connect to existing consumption/switching devices such as the IRIS / AlertMe suite.
I have pledged as a sponsor for this project, and hope to get my hands on a prototype- however, the funding has been a bit slow, so please help out :)

AlertMe (IRIS)- https://www.alertme.com/shopping

  • Consumption measuring
  • Remote switching
  • Zigbee
  • Requires the SmartEnergy pack as a bridge/gateway to the internet
  • £25

Ubiquiti mFi mPower- http://www.ubnt.com/mfi#m-Power

  • Consumption measuring
  • Remote switching
  • WiFi connected (requires no bridge/gateway device)
  • Comes in 3 flavours: Single, 3 socket extension cord and 8 socket extension cord
  • Only currently available with US / EU plugs
  • No EU stock currently available (when it is, I will try one with a UK plug adapter)

Belkin WeMo Switch- http://www.belkin.com/uk/c/WSWH

  • Switching only by the look of it
  • WiFi connected (requires no bridge/gateway device)
  • £40

Meter Polug- http://www.indiegogo.com/meterplug/x/2060579

  • Consumption measuring
  • Remote switching
  • Bluetooth only- so unless you’re within range and carrying a bluetooth equipped device, it’s not much good. This being said, the project has been fully funded, so there is clearly demand for such a device.
  • I have asked whether they’ve considered building a gateway device to enable internet connectivity but yet to hear back. Fingers crossed.

Other

  • I have purchased a USB Zigbee packet sniffer in the hope that I can make sense of some of the traffic floating around my house from various “smart” gadgets.
  • Still waiting on delivery of my EVE Alpha board- http://www.kickstarter.com/projects/ciseco/eve-alpha-raspberry-pi-wireless-development-hardwa this should allow me to start doing some cool stuff with a raspberry pi using the gpio pins rather than dozens of USB sticks!
  • The guys over at flukso have confirmed that they will be continuing work on their enhanced hexabus plug once they have another project out of the way: https://www.flukso.net/content/hexabus-plug
  • I sent some details to a few companies in an attempt to understand costings for PCB design, production and assembly. Just one company has responded to date: http://www.newburyelectronics.co.uk/ – for something like the Hexabus plug they’re suggesting (rough figures): £1,000 PCB design (£500 each of the 2), £80 PCB production (£40 each of the 2), £60 parts (excluding several parts they can’t source), £130 assembly & inspection. Bringing the total in at about £270/device (forgetting PCB design)- ouch!

That’ll likely be my last update for a few weeks, as I’m off to Thailand shortly :)

L

A new year, a new project

*EDIT*: Update on this project https://tickett.wordpress.com/2013/01/10/an-update-on-my-latest-project/

So I realise I have been a little quiet on here lately, and so will make it my new year’s resolution to get back in the habit of blogging regularly.

I would like to share some details of a project I’m assessing for feasibility. It is yet to be named but in essence I’m looking at building an Automated Mains Plug / Socket, let’s call it aPlug.

What do you mean by automated?

  • Remotely switchable / “programmable”
  • Monitor / log power / energy consumption

Don’t these already exist?

  • A lot of rf controllable plugs exist but there are a number of limitations- # cannot integrate with other equipment, # cannot operate from outside of the home, # cannot operate without the supplied remote, # cannot determine current state
  • Some power / energy consumption monitoring plugs exist but again, bare limitations- # cannot integrate with other equipment, # require a gateway device to post data to the internet
  • A few devices even exist which address both requirements but- # cannot integrate with other equipment, # cannot operate from outside the home, # require a gateway device (possibly even an entire pc to post data to the internet), # are expensive, # are closed source

There is however, one possible hope! The hexabus plug: http://signup.hexabus.net/ – I am trying to make contact with the guys behind the hexabus plug to determine where the project is currently, where it’s headed etc. Regardless, the great thing about the project, it is open source- which means the schematic / parts list (BOM) have been published: https://github.com/mysmartgrid/hexabus – unfortunately the PCB layout doesn’t appear to’ve been, but again, I’m hoping it will be shortly.

This project has also sparked the interest of the guys over at flukso, and became the center of a talk at one of their meetings: https://www.flukso.net/files/presentations/flukso.20121026.hack_hexaplug.pdf – where they have suggested a minor tweak to enable interconnectivity with jee labs devices (they include a PCB layout, which suggests they likely have them- I am trying to make contact with them too!)

Even if I manage to make contact and get details of the existing device I still have a lot to tackle…

Network connectivity
I’m currently looking at options, but it makes sense to try and learn from the lessons the guys behind LIFX: http://www.kickstarter.com/projects/limemouse/lifx-the-light-bulb-reinvented
They have essentially gone down the route of creating a mesh network with “slave” devices, then using a “master” device to bridge to the local area network (LAN) and essentially the internet. This ultimate is a gateway device but “in disguise”- and unless I can miraculously find a way of driving down the cost I can’t see any other approach being feasible?

Prototyping
I am making contact with a number of companies who design, produce and assemble printed circuit boards (PCBs) as a number of the components involved in the device cannot be soldered by hand nor can the circuit(s) likely be built using a simple breadboard. I imagine this is going to be a real challenge as the cost for “one-off” or very limited production runs is likely to be extremely high.

Software / Firmware
I have coded some simple arduino / atmega programs in the past, and worked with some of the jeelabs devices but I will certainly be needing assistance to build something as complex as this if it’s going to be robust enough to put “out in the field”. My hope is that developers will show a keen enough interest and we can build something as a community. The devices will be reprogrammable so new firmware can be flashed with relative ease. The problems will come when a hardware change is required…

Certification
Regardless of whether a device is faced with mains voltages or whether a device is aimed at developers I anticipate some form of certification being required- this could be tricky (especially on an evolving device).

Funding
To gauge interest, boost funding, promote the project and hopefully attract some developers, testers and contributors I would like to run a kickstarter project- unfortunately it’s a little chicken & egg as I need at least some form of prototype before I can reach out to the community. I have however drafted a project so I am prepared if I do get that far: http://www.kickstarter.com/projects/tickett/736265394?token=98a4e52f (so far just some notes, and the reward levels are pure guesswork).

I just knocked the artwork up from a few google images:

I have asked someone to design some artwork for a t-shirt, so I will see if they can come up with a cool concept :)

Where Next?
Yes, it’s far too early to be thinking about that, but I can’t help it!

  • Multi socket extension lead type device with individual socket switching and consumption monitoring
  • aSocket, essentially a mains socket with the device inside so no “plug” is required
  • Other plug types (I am based in the UK so this is where I intend to initially focus)

At this stage I’d appreciate any feedback, or expressions of interest etc

Happy new year to all

Lee

More 433Mhz RF Hacking

I touched on the smoke detectors and door/window sensors I ordered last week: – here are a few more details.

The smoke detectors were £5.75 each – http://www.ebay.co.uk/itm/260990530306#ht_3800wt_1385 (all now sold out, but more available on a separate listing from the same seller – http://stores.ebay.co.uk/greatgougo)
The door/window sensors were £2.50 each – http://www.ebay.co.uk/itm/200759112077?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649#ht_500wt_1170 (shop link if/when the listing ends – http://stores.ebay.co.uk/HI-AYY-STORE)

The RF signals broadcast by both devices are not decoded by the RFXCom receiver/transceiver RFXtrx433. This meant finding a way to receive and decode myself.

I already had a few jeenodes (http://jeelabs.com/products/jeenode) knocking about and a 433Mhz plug (http://jeelabs.com/products/ook-433-plug) – there are many alternatives available. I fired up some sketches from the jeelib library (https://github.com/jcw/jeelib/) but wasn’t getting any output when triggering the door/window sensors or the smoke detectors;

I found a discussion on the jeelabs forum (http://forum.jeelabs.net/node/87) which led me to an application called ProtocolAnalyzer (http://wiki.nethome.nu/doku.php/analyzer/start). ProtocolAnalyzer describes a real simple circuit design which brings the RF signal voltage down to a safe voltage to pump into the microphone/line-in port:

I didn’t even have the right components so I improvised:

I only had a 4K7 variable resistor rather than fixed, and I think those fixed resistors are about 370 ohm so I doubled up. I didn’t have any capacitors, so I’ve omitted for the time being but that might be the reason I’m getting slightly inconsistent results as you will see later.

I fired up ProtocolAnalyzer and immediately started to see data coming in (without activating the sensors)- this suggested my CurrentCost devices and such were probably being heard. Many of the signals were being identified as conforming to the "Pronto" protocol, but the data wasn’t very helpful (nor was the way in which it was being displayed). To read the data you had to drill-down on each record. As I ultimately wanted to compare a large result set in an attempt to find patterns and work out which bits/bytes/words meant what this wasn’t really practical.

So I disabled all of the decoders and enabled just the raw signal capture:

I could now drill down and determine the pulse spec:

Which I could then use in an Arduino sketch to capture data. I used the ookRelay2 sketch and modified the Home Easy (HEZ) decoding function to decode my new devices:

class HezDecoder : public DecodeOOK {
public:
HezDecoder () {}
// see also http://homeeasyhacking.wikia.com/wiki/Home_Easy_Hacking_Wiki
virtual char decode (word width) {
if (400 <= width && width < 1600) {
gotBit(width <= 600);
return 0;
}
if (width >= 3000 && pos >= 5) {
for (byte i = 0; i < 6; ++i)
gotBit(0);
alignTail(64); // keep last 56 bits
return 1;
}
return -1;
}
};

As soon as I activated one of the sensors data started to flood in:

[ookRelay2]
HEZ 51 85 171 42 51 3
HEZ 166 106 85 101 102 32 51 85 171 42 51 3
HEZ 153 169 90 85 153 3
HEZ 51 85 171 42 51 3
HEZ 51 83 171 42 51 3
HEZ 51 85 171 42 51 3
HEZ 166 106 85 101 102 32 51 83 169 42 51 3
HEZ 51 85 171 42 51 3
HEZ 170 86 85 102 6 50 51 85 171 42 51 3
HEZ 51 85 171 42 51 3
HEZ 204 85 171 42 51 3
HEZ 51 83 181 170 50 3
HEZ 51 85 171 42 51 3

I’m not 100% sure of the reason for the receptions (I think some protocols rebroadcast multiple times to enable validation). Nor am I sure of the reason for the discrepancies (you can see most of the packets are HEZ 51 85 171 42 51 3 but a few contain different values).

I took the most common result and recorded it along with the jumper position (presumably indicating the home code):

I followed a methodical approach of moving the jumpers and recording the result- ending up with a pattern something like:

ABCD-EFGHIJ?? IJ GH EF AB CD
NNNN-NNNNNNNN HEZ 51 51 51 51 51 3
NNNL-NNNNNNNN HEZ 51 51 51 51 179 2
NNNH-NNNNNNNN HEZ 51 51 51 51 83 3
NNLN-NNNNNNNN HEZ 51 51 51 51 43 3
NNLL-NNNNNNNN HEZ 51 51 51 51 171 2
NNLH-NNNNNNNN HEZ 51 51 51 51 75 3
NNHN-NNNNNNNN HEZ 51 51 51 51 53 3
NNHL-NNNNNNNN HEZ 44 51 51 51 181 2
NNHH-NNNNNNNN HEZ 51 51 51 51 85 3
NLNN-NNNNNNNN HEZ 51 51 51 179 50 3
NHNN-NNNNNNNN HEZ 51 51 51 83 51 3
LNNN-NNNNNNNN HEZ 51 51 51 43 51 3
HNNN-NNNNNNNN HEZ 51 51 51 53 51 3
NNNN-NNNNNNNN HEZ 51 51 51 51 51 3
NNNN-NNNNNNNL HEZ 51 51 51 51 51 3
NNNN-NNNNNNNH HEZ 51 51 51 51 51 3
NNNN-NNNNNNLN HEZ 50 51 51 51 51 3
NNNN-NNNNNNHN HEZ 51 51 51 51 51 3
NNNN-NNNNNLNN HEZ 43 51 51 51 51 3
NNNN-NNNNNHNN HEZ 53 51 51 51 51 3
NNNN-NNNNHHNN HEZ 85 51 51 51 51 3
NNNN-NNNNLLNN HEZ 171 50 51 51 51 3
NNNN-NNNHNNNN HEZ 51 53 51 51 51 3
NNNN-NNHHNNNN HEZ 51 85 51 51 51 3
NNNN-NHNNNNNN HEZ 51 51 83 51 51 3
NNNN-HNNNNNNN HEZ 51 51 53 51 51 3

So I could see that the jumpers in pairs appeared to directly affect each byte of data being returned. I think built this table to demonstrate how I think they correlate:

DDDD-AAAAAAAA
3210-76543210
A0 = Not Used
A1 = Not Used
HEZ AA32 AA54 AA76 DD32 DD10
NN = 51
NL = 43
NH = 53
LN = 179
LL = 171
LH = 181
HN = 83
HL = 75
HH = 85

Next steps:

  • Configure each of the sensors with unique jumper configurations
  • Determine and position the sensors
  • Add the 433Mhz receiver to the jeenode connected to my raspberry pi (running DomotiGa) and modify the sketch to decode these signals as well as receiving 868Mhz broadcasts from other jeenodes
  • Tweak the DomotiGa code to interpret the received data

Home Automation Update

Not a lot to say- just a quick update. I’ve ordered a few more bits to add to the home automation project. These have already come:

-RFXCom 433Mhz transceiver
-Byron 433Mhz switch, pir, remote plug/socket & "in ceiling switching module".
-Linksys SPA3102

And I’m still waiting for (or haven’t ordered):

-433Mhz smoke alarms
-433Mhz doorbell
-433Mhz door/window open/close sensors
-Wifi or 433Mhz bathroom scales

Here’s a quick shot of one of the raspberry pis hooked into a little portable LCD, the RFXCOM transceiver, the CurrentCost EnviR and a Jeelabs Jeenode:

The next step I decided to tackle was getting a few real basics pieces of information from my Enigma2 digital satellite receiver into DomitiGa. I decided to use the nifty little shell script module to execute:

#!/bin/bash
rm current
wget -q http://192.168.0.222/ajax/current
cat current | grep "Name:" | sed 's/.*: (.*)<.*/1/'
cat current | grep "Title:" | sed 's/.*: (.*)<.*/1/'
cat current | grep "Recording Status:" | sed 's/.*: (.*)<.*/1/'

Which returns three lines with: The current channel, programme and whether a recording is in progress. I hope to take this a lot further and start capturing stats from my VDSL & ADSL modems, fileserver etc. You can see the satellite details below "Sky: Lounge":

I have been meaning to get my gas meter, hot & cold water monitored for a long time. The gas meter is relatively straight forward as it provides a convenient RJ11 socket with pulses- I just needed a sketch to load onto a jeenode to catch and report these pulses. I decided to try the sketch from the OpenEnergyMonitor project (http://openenergymonitor.org/emon/emontx) found here: https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTx_Pulse

I made some changes:

-Set freq to 868Mhz
-Set nodeID and networkGroup
-Unset UNO

I think that’s it:

/*
EmonTx Pulse example

An example sketch for the emontx module for
CT only electricity monitoring.

Part of the openenergymonitor.org project
Licence: GNU GPL V3

Authors: Glyn Hudson, Trystan Lea
Builds upon JeeLabs RF12 library and Arduino

*/

#define freq RF12_868MHZ // Frequency of RF12B module can be RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. You should use the one matching the module you have.433MHZ, RF12_868MHZ or RF12_915MHZ. You should use the one matching the module you have.
const int nodeID = 2; // emonTx RFM12B node ID
const int networkGroup = 212; // emonTx RFM12B wireless network group - needs to be same as emonBase and emonGLCD needs to be same as emonBase and emonGLCD

const int UNO = 0; // Set to 0 if your not using the UNO bootloader (i.e using Duemilanove) - All Atmega's shipped from OpenEnergyMonitor come with Arduino Uno bootloader
#include <avr/wdt.h> // the UNO bootloader

#include <JeeLib.h> // Download JeeLib: http://github.com/jcw/jeelib
ISR(WDT_vect) { Sleepy::watchdogEvent(); }

typedef struct { int power, pulse, misc1, misc2; } PayloadTX;
PayloadTX emontx; // neat way of packaging data for RF comms

const int LEDpin = 9;

// Pulse counting settings
long pulseCount = 0; // Number of pulses, used to measure energy.
unsigned long pulseTime,lastTime; // Used to measure power.
double power, elapsedWh; // power and energy
int ppwh = 1; // 1000 pulses/kwh = 1 pulse per wh - Number of pulses per wh - found or set on the meter.

void setup()
{
Serial.begin(57600);
Serial.println("emonTX Pulse example");

rf12_initialize(nodeID, freq, networkGroup); // initialize RF
rf12_sleep(RF12_SLEEP);

pinMode(LEDpin, OUTPUT); // Setup indicator LED
digitalWrite(LEDpin, HIGH);

attachInterrupt(1, onPulse, FALLING); // KWH interrupt attached to IRQ 1 = pin3 - hardwired to emonTx pulse jackplug. For connections see: http://openenergymonitor.org/emon/node/208

if (UNO) wdt_enable(WDTO_8S);
}

void loop()
{
emontx.pulse = pulseCount;
pulseCount = 0;
//Serial.println(pulseCount);
send_rf_data(); // *SEND RF DATA* - see emontx_lib
emontx_sleep(10); // sleep or delay in seconds - see emontx_lib
digitalWrite(LEDpin, HIGH); delay(2); digitalWrite(LEDpin, LOW); // flash LED
}

// The interrupt routine - runs each time a falling edge of a pulse is detected
void onPulse()
{
lastTime = pulseTime; //used to measure time between pulses.
pulseTime = micros();
pulseCount++; //pulseCounter
//Serial.println("Pulse!");
emontx.power = int((3600000000.0 / (pulseTime - lastTime))/ppwh); //Calculate power
}

void send_rf_data()
{
rf12_sleep(RF12_WAKEUP);
// if ready to send + exit loop if it gets stuck as it seems too
int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;}
rf12_sendStart(0, &emontx, sizeof emontx);
// set the sync mode to 2 if the fuses are still the Arduino default
// mode 3 (full powerdown) can only be used with 258 CK startup fuses
rf12_sendWait(2);
rf12_sleep(RF12_SLEEP);
}

void emontx_sleep(int seconds) {
for (int i=0; i<seconds; i++) {
delay(1000);
if (UNO) wdt_reset();
}
}

L

Jeelabs 433 Mhz OOK Plug

It’d been on back-order for some time but finally over the Christmas break arrived in the post :)

I wired soldered the few parts and tried a few of sample sketches in the Arduino IDE but nothing… I gave up as some other jobs had to take priority.

A few weeks later some discussions kicks off over on the Jeelabs forum: http://forum.jeelabs.net/node/764 and Ed Voncken pointed out a few discrepancies in the documentation and provided some tips on building and testing the board on his blog: http://edvoncken.net/2011/12/assembling-the-jeelabs-ook433-plug-part-1/

My big faux-pas was not soldering the jumper R1 (no resistor is required). I also opted for soldering the bridge between P and the middle pad rather than + (as it looks like the 433 Mhz receiver board is marked up for the + 5V which are provided via PWR as opposed to the + which only provided 3.3V).

Now I fired up the ookScope2 sketch, fixed the pin mappings (OOK_PIN = 16 and OOK_POWER = 12) uploaded to the device and launched the serial monitor:

Woah, that’s a lot of data… but quite expected as I have 9 currentcost devices transmitting, 2 oregon scientific devices and probably some other stuff I’ve forgotten about.

I retried the ookDecoder sketch now that I know some real rf data is acknowledged- and to my amazement there was some sensible output:

[ookDecoder]
546892
HEZ BAAAAAA700
1055900
HEZ BA8AAA8F02
1057592
HEZ BEBA1200800700

Apparently these are home easy transmissions- though I don’t have any home easy or compatible devices in the house (that I’m aware of)- so my only guess is that they belong to my neighbours!

I need to do some more research into whether the currentcost protocol can be decoded and find a working sketch for my oregon devices then start to consider purchasing some remote mains sockets.

L

%d bloggers like this: