These articles together form the source that I drew inspiration from. I didn’t have to do my own signal timing analysis which sounds fascinating but complicated. The above code examples however are written either for Raspberry Pi, or for Arduino using different models of Fine Offset sensors and transmitters.
The next step was to figure out how to receive the sensor data being transmitted to the display base station. There’s plenty of articles on the web describing parts of the puzzle, but I didn’t find any one article that explained it all. For testing I used a Freetronics LeoStick and a 433MHz RF receiver module set up on a breadboard, so I could leave the original sketch still running on my desktop feeding data to the web. The LeoStick was particularly easy to use as I could just plug it into a USB port and test code from anywhere in the house without being tethered to power.
My birthday was coming up and an online retailer had a tempting online discount so I ordered one of these:
It’s a common ‘generic’ model made by Fine Offset, WH-1081, sold here by many retailers as an XC0348. Of course I had to wait until my birthday to actually ‘receive’ it and then it was back to work and no time to play. Finally it did get put together, and it has sat out the back on a small table to test it. Firstly I haven’t had an opportunity to get on the roof, and secondly, if I want to do some decoding of the data it is much easier if you can observe it close up, and test the sensors individually. Although some data is probably inaccurate, such as wind, the readings generally agree with the weather bureau. Here’s its current position:
I ran some testing code on the MPL3115A2 breakout board and that worked fine first time, giving me altitude and temperature readings immediately. I then tried to incorporate that code into my existing sensor reading sketch, using the barometer mode. At this point things suddenly stopped working nicely. The serial monitor debugging showed it just stopped when trying to initialise ethernet. I began cutting out bits of code, so that it wasn’t reading other sensors. It then seemed to start sending data and then restart, but the loop would not run.
Next night I sat down and started over with the existing sketch, but with it only sending the barometer reading, and it worked. I was able to add the other sensors back in, one at a time, and it still worked. I did cut out some unnecessary debug statements here and there to try to cut the code size down. Finally, I have everything working, but can’t explain why it didn’t work before and why it does now. I was thinking that perhaps the EtherTen wasn’t up to the task, and I might need to go up to a Mega board.
Obviously there is a bit of redundant data here, so it is just a useful way of testing the different device interfaces. What is somewhat hard to explain is why I have 3 different temperature readings given these devices are supposed to be calibrated to a high degree of accuracy. For example at the moment readings are 24.37 °C (DS18B20), 23.80 °C (DHT22) and 22.75 °C (MPL3115A2).
I put in an order to Little Bird Electronics at Christmas to take advantage of a 10% discount coupon, so I added a few bits and pieces that might come in handy. First off was a DHT22 temperature and humidity sensor, which is readily available with lots of examples around. First I tested it with some sample code, and then modified my existing ‘weather’ station code. So now I have two different measures of light levels, two temperature readings and humidity. There is a slight difference of about half a degree between the two temperature sensors, so I wonder which one is more accurate? The Xively feed immediately picked up the two new data streams, and as a bonus my iPhone app also recognised them.
I also bought an MPL3115A2 barometer/altitude sensor which looks interesting, but it is my first experience of the I2C bus and it appears that to run long distances to an outside sensor it needs a bus driver of some sort, so this one is going to take more effort. The code looks rather daunting too.
Just picked up one of these Belkin WeMo switches to try out. I wasn’t worried about the motion-sensing switch version, just the plain single outlet. On opening I expected to find more complicated setup instructions, and thought I would have to set up port forwarding on my router so I could control it over 3G from the phone. Considering the average home user wouldn’t know how to do this, I wondered how they would make this easy to do. However, it doesn’t work this way.
Anyway, it was incredibly easy to set up:
Plug it in. I plugged in a reading lamp as a test. The LED alternately blinked blue and orange. I tried the manual switch and the lamp turned on and off.
Download the WeMo app from the app store. Launch the app, then it asks you to go into Settings to join the phone to the WeMo’s local WiFi network.
The app begins setup and once finished, the single remote switch appears in a list view.
That’s it! At this point you just hit the button in the list item and the light turns on and off.
The app notified that a firmware update was needed, which installed with no problems.
So, first experiences are favourable. I’m still curious as to how remote control works from outside the WiFi network. I am assuming that the device must be sending requests out to a server somewhere and polling for state changes.
At the moment I’m probably just going to use it to switch the Christmas lights (when they actually get set up). This saves me going outside or down to the garage to switch the powerpoints off. We do have some old-style mechanical timers around but this is far more fun.
Belkin also publish an SDK for WeMo, which is a nice change considering that most manufacturers have no interest in making their devices open or interoperable. Building the demo app for my iPhone immediately finds the configured WeMo outlet and I can switch it from the iOS simulator. I do wonder what security implications this may have, but assume that only devices recognised by my local network can control the WeMo switch. Some testing may be required.
Xively has a heap of APIs so you can access your feed data in other ways rather than just loading up the web page. I was able to use their sample code to put together a simple iOS app that lets me check the temperature and light levels in my study at any time, from anywhere. It’s nothing fancy but a good proof of concept.
So I got hold of a Freetronics EtherTen early this year and started getting familiar with it. After getting a multi-colour LED to change colour I hooked up a tempreature sensor and got it reporting temperature as a simple web server. It’s still sitting on my study desk at the moment. To see this remotely on the web I had to figure out how to do port forwarding on my router.
About this time I discovered Cosm, and hacked up a feed so that I could push my data to their site, and thus make the data visible without having to open a port on my network. Cosm turned into Xively, so I rewrote the sketch to incorporate the API changes. You can check the feed here.
A bit later I dug out a couple of LDRs and hooked them up so I can measure light level too. There are two because they are different types and I wanted to check their sensitivity. The temperature sensor is hanging off the edge of the desk at the moment.
Here’s a shot of the Xively feed. This is the last 7 days and you can see the daily cycles. Some days the curtains may be closed, and some evenings a light may be on. The light levels are inverted, so when it is bright the resistance and thus the graph drops.