Quantcast
Channel: OpenEnergyMonitor
Viewing all 196 articles
Browse latest View live

How to build an Energy Monitoring Android App part 1

0
0



Glyn and I have wanted to have an android app to make it easier to access energy monitoring data from phone's and tablets for sometime.

Last year we took part in a student project to develop an Emoncms Android App with Mathew Keegan who was studying at the time at Aberystwyth University. Mathew made good progess on the foundations of the app which I've uploaded to github here: https://github.com/emoncms/AndroidAppDev/tree/master/MathewKeeganAberUni

I've been trying to learn a bit of Android app programming to understand what Mathew has developed. I followed a couple of Hello World tutorials and then explored networking and how to update the display. I've written up my notes as a tutorial: How to build an Energy Monitoring Android App part 1 here:

How to build an Energy Monitoring Android App part 1


Im going to try and continue development in this style by writing tutorials of how to do each step.

I think we should all be able to build our own software (if we want to) and given the rising use of tablets and mobiles as our personal computing devices having at least a basic understanding of how to build an app is enlightening and satisfying to see the results on your phone. Even if you've only dabbled in software before I would like to encourage you to try the tutorial, please ask me if I can clarify anything and feel free to send me a github pull request with edits to the tutorial.

My next tutorial will focus on how to use android graphics canvas to draw a graph that looks like the myelectric graph in the myelectric emoncms module.

I've posted this blog post on the forum's here which is a better place to discuss:


Gwynedd Council Award 2014

0
0
Many thanks to Gwynedd Council (our local council) inviting us along to the Gwynedd Business Week dinner and presenting us the 'Special Contribution to Gwynedd's Economy' award week before last. 


It's great to be recognised locally for our achievements, especially being an open-hardware business where everything we develop is open-source both hardware and software. It shows that there is a different way of doing things, technology business does not always need to be about closed IP, open-source works and open-source hardware businesses could be a way to have local employment not just here in North Wales but all over the world.

Trystan stepping up to receive the award 

A little side story about the slate plaque: We love the slate plaque, slate is very appropriate material to the area; North Wales was once the slate mining capital of the world. Nowadays the slate quarrys and mines are far fewer, many being dormant landmarks in the area used as recreation areas (e.g. our personal favourite, rock climbing :-D ). One underground cavern is used to house a 1.7MW pump storage hydro-electric power station which is the second largest in Europe  and 8th largest in the world

View from the Llanberis Slate quarries - the round building is a vent hole for the 1.7MW pump-storage hydro power station underground...very cool!  

Diolch yn fawr Cyngor Gwynedd! 

How to draw a myelectric style bar chart

0
0
Part of the android app tutorial series: How to build an Energy Monitoring Android App P1
Both the myelectric emoncms module and the soon to be myelectric android app have a bar chart that is written using the 2d graphics canvas. This short guide details how the bar chart is built and the first part is written to be applicable for different programming languages with examples in each particular language to come at the end, there's one for android java canvas at the moment.





Writing custom graphs is not as complicated as I initially imagined it to be. Once you have a grasp of 2d graphics canvas sometimes its easier to write your own graph to get the style that you want. The myelectric graph was written from scratch in order to achieve a precise look: simple color scheme, bar height values overlayed on the bar, kWh label in the top-left corner.

Tutorial: How to draw a myelectric style bar chart


emonPi Raspberry Pi Energy Monitoring Shield - Prototype Dev Update

0
0
For a while now I have been working on developing a Raspberry Pi energy monitoring shield. Here is a preview of the first prototype design.

The emonPi is not designed to totally replace the emonTx V3, but rather to complement it. I see the emonPi fulfilling two applications:

1. As a low cost Raspberry Pi add-on shield to make all-in-one home energy monitoring unit based on the Raspberry Pi.  We will produce a version of the emonPi board on it's own (without enclosure, HDD and LCD), maybe even with just SMT components ready assembled (like the Arduino Lenoardo) to being the cost down further.

2. As a high quality, robust and nicely enclosed stand-alone energy monitoring unit and web-connected base station with LCD status display, built in hard-drive for local logging and backup. The emonPi has also been designed to be perfect for installers of heat-pump monitoring systems which require many temperature sensor wired up (see temperature sensing part of my forum post update) as well as power monitoring.

The emonPi has got an option for RFM12B / RFM69CW radio to enable it also to act as an emonBase, receiving date from other wireless nodes such as emonTH (room temperature and humidity node), emonTx V3 (energy monitoring node) and transmitting the current time to the emonGLCD LCD display.

Since the emonPi is an energy monitor sensing node and remote posting base station all-in-one and coupled with a status LCD this should make system setup, installation and debugging easier. The emonPi should also be great for remote administration since with the correct network config the Raspberry Pi can be accessed remotely, log files checked and even upload Arduino sketch firmware onto the emonPi's ATmega328.


Development has been documented in an ongoing open forum thread: http://openenergymonitor.org/emon/node/3937

My latest update post can be viewed here: http://openenergymonitor.org/emon/node/3937#comment-21865

emonPi - Raspberry Pi Energy Monitoring Shield Prototype 

emon Pi Features 

  • Two channel CT monitoring with AC sample input 
  • Ability to power the Raspberry Pi and an external HDD without the need for an additional USB hub, emonPi can also function without a HDD
  • RJ45 DS18B20 on-wire temperature bus to allow many temperature sensors to easily be added using a RJ45 breakout board for heatpump monitoring applications 
  • PWM and IRW I/O's on RJ45 
  • Status LCD
  • Compatible with RaspberryPi model A and model B 
  • Option for RFM12B / RFM69CW with SMA antenna to receive or transmit data from other sensor nodes
  • OOK (on-off keying) transmitter footprint for controlling remote plugs etc. 
  • ATmega328 with ability to remotely upload sketches vis Raspberry Pi Serial 
  • Open-source hardware, firmware and software 
  • High quality custom made, wall mountable enclosure
   

End-plate silkscreen draft:

See G+ album for more photos: https://plus.google.com/b/114424977493521882459/photos/+OpenenergymonitorOrgpage/albums/5999656723837107313

 LCD demo:




Please join in the emonPi's open-development forum thread if you have any ideas of thoughts to contribute:
http://openenergymonitor.org/emon/node/3937#comment-21865


The disadvantages of the emonPi compared to the current emonTx V3 are:

  • Only two CT channels, no (approximate) 3-phase
  • Due to higher power requirements of the Pi, the emonPi can't be powered from batteries, 5V DC USB mini-B is required. 
  • Again, due to higher power requirements of the Pi, the emonPi can't be powered from an AC-AC adapter, for real power a 5V DC and 9V AC adapter will both be required. 
  • Requires wifi connectivity or Ethernet to reach the location where the utility meter is located
  • Larger enclosure than the emonTx V3

    Emoncms time-series feed engine documentation

    0
    0
    I've been working over the last few days on writing documentation on how the emoncms time-series feed engines work (phpfiwa, phpfina and phptimeseries). The documentation is an early draft at this stage and I would very much welcome comments.

    https://github.com/openenergymonitor/documentation/tree/master/BuildingBlocks/TimeSeries

        Emoncms time series database development history
        Variable interval time series
        Fixed interval time series
        Fixed interval with averaging time series

    On a related note out of an interest in creating a version of emoncms that will run and log to SD cards without wearing them out so fast I've started to look at how the write load created by the emoncms feed engines can be reduced through in memory buffering and writing in larger blocks to disk, initial testing suggests that it could be reduced by potentially more than a 1000x on systems with 30+ feeds, maybe several 100x on systems with only a few feeds.

    See forum post: http://openenergymonitor.org/emon/node/5319

    emonGLCD V2 SMT Development

    0
    0
    For sometime now the emonGLCD has been lagging behind other OpenEnergyMonitor hardware units in terms of development, we're still selling it only in thru-hole DIY kit form.

    We've been thinking about updating it to SMT pre-assembled for some time, however we've been dragged our heels somewhat since there has been thoughts that maybe a smartphone app could fill the same function. However I believe a physical LCD display unit fulfils a slightly different role to a smartphone app. I believe in certain circumstances there is certainly value to having an always-on low power LCD display located in a prominent location displaying current power consumption and or generation.

    I have found the emonGLCD with the ambient indication tri-colour LED's to be a really useful easy-to-read indication of solar PV import / export at any given time.

    Doing a quick Google search shows that there are lots of emonGLCD being used and customized for all sorts of purposes we could not even have though of! For example: heat pump monitor, temperature measurements, electric car charge rate etc.

    With this in mind, we have decided to make an SMT version of the emonGLCD keeping the design largely the same (same LCD panel size and same controller chip ST7565). This will mean the current emonGLCD firmware sketches should run on the new unit with little or no modifications.

    I would be interested to heard your thoughts on what you would like in a new version of the emonGLCD?

    Over the past few weeks I've made a start to get a prototype, here is the main design criteria and features so far:
    • ST7565 128 x 64 LCD panel with integrated RGB backlight, specifically this Vatronix unit (to replace the LED's on the current version)
    • Single front facing rotary encoder with push-to-select (to replace the three push buttons the the current)
    • Option for lithium battery pack with USB battery charging circuit and battery voltage monitor
    • Arduino compatiable ATmega328 with RFM12B / RFM1269CW
    • Option for on-board DS18B20 and DHT22 temperature and humidity sensors 
    Using SMT assembly and lower cost LCD unit and enclosure we should be able to reduce the price of the emonGLCD compared to the current version.

    Yesterday I sent off for the first prototype PCB revision:





    Testing the new LCD panel with built in RGB backlight
    These images and more can be viewed in higher resolution in the emonGLCD V2 SMT Development album on G+, I will be periodically updating this album with development photos as things develop!
    https://plus.google.com/photos/114424977493521882459/albums/6016575729643776881#

    Enclosure 

    The enclosure is an important part of the emonGLCD design considerations. We plan to move to a 'proper' custom made enclosure for the new emonGLCD. These are the main options available:

    1.) 3D printed (for small volumes and prototyping, not really possible for 500+ per production run)
    2.) layered laser cut plywood or acrylic (like the Pimoroni Raspberry Pi cases)
    3.) Injection molded plastic

    I'm specifically interested in exploring if/how an enclosure could be made with lowest embodied energy and maximum recyclability.
    We have not yet made much progress on case design nor have we got a designer or manufacturer in mind. If you would like to work with us please get in touch. Equally if you have some ideas on enclosure design I look forward to hearing.

    Please use the the emonGLCD V2 SMT forum thread for comments and discussion: http://openenergymonitor.org/emon/node/5374 

    Reducing emoncms write load and a minimal python version of emoncms

    0
    0
    Over the last few weeks I have been investigating how to reduce the write load of emoncms to explore if it might be possible to achieve long term logging on SD cards.

    A brief summary

    Through a mix of buffered writing of feed data to disk, reduction of the number of meta and average data files written to and use of the FAT filesystem, my home raspberrypi now has a write load of 0.4kb_wrtn/s down from 197kb_wrtn/s.. almost 500x less and the writes are all append only (there's no regular writing of the same part of a file again and again). The question is could this mean years of SD card logging rather than months?

    Write buffering

    A single Emoncms PHPFina (PHP Fixed Interval No averaging) or PHPTimeSeries datapoint uses between 4 and 9 bytes. The write load on the disk however is a bit more complicated than that. Most filesystems and disk's have a minimum IO size that is much larger than 4-9 bytes, on a FAT filesystem the minimum IO size is 512 bytes this means that if you try and write 4 bytes the operation will actually cause 512 bytes of write load. But its not just the datafile that gets written to, every file has inode meta data which can also result in a further 512 bytes of write load. A single 4 byte write can therefore cause 1kb of write load.

    By buffering writes for as long as we can in memory and then writing in larger blocks its possible to reduce the write load significantly. The full investigation with a lot of benchmarking of different configurations including differences between FAT and Ext4 can be found here:

    https://github.com/openenergymonitor/documentation/blob/master/BuildingBlocks/TimeSeries/writeloadinvestigation.md

    A minimal version of emoncms in python

    To make the investigation easier I simplified emoncms down to the core parts needed on a raspberrypi to get basic timeseries graphing: serial listener, node decoder, basic feed engine and a ui consisting of a nodelist and a single rawdata visualisation type and wrote the result in python making use of Jerome and Paul's (pb66) excellent work on the emonhub serial listener and node decoder.
    Here's a diagram of the main components of the python app:


    And some screenshots of what it looks like:

    Node list:



    Basic graphing:





    The source code and an installation guide for this minimal python version of emoncms can be found here:

    https://github.com/emoncms/development/tree/master/experimental/emon-py

    Further development questions (copied from the end of the write load investigation page)

    Is the reduced write load and longer SD card lifespan that might result from using the FAT filesystem worth the increased chance of data corruption from power failure that Ext4 might prevent?

    It would be interesting to compare the performance of the FAT filesystem + 5 min application based commit time with the EXT4 filesystem with Journaling turned off and filesystem delayed allocation set to 5 min instead of write buffering in the application.


    I posted on the EmonHub issues list about this last friday and I've been having a bit of a discussion there with Paul https://github.com/emonhub/emonhub/issues/48

    I've also posted this on the forum's here:
    http://openenergymonitor.org/emon/node/5387

    How CT Sensors are Made...

    0
    0
    Ever wondered how CT sensors are made? I've just been sent these photos of inside the YHDC factory, here we can see the CT windings being wound: 




    Android Tasker & Pebble Smartwatch - Emoncms Notifications

    0
    0
    Tasker is a powerful Android app which can be used to automate all sorts of things on your phone or tablet.

    Using Tasker it's easy to create notifications using data from Emoncms to be triggered by certain events e.g. times of day, location, feed value etc. The possibilities are endless! Once you're done configuring Tasker it's possible to export your setup packaged as an Android app to be easily installed on any device.

    Using Pebble Notifier (which integrates with Tasker) the notification can be sent to a Pebble Smartwatch. Pebble Tasker can be used to activate the task to trigger the notification directly from the watch.




    Here's the Tasker task I used to perform the notification show above, I have setup Tasker profile to activate this notification whenever I get home and at the end of the day at 11pm.  


    I have uploaded a generic version of this Tasker task to GitHub, follow the instruction on the GitHub Readme to import into Tasker. 



    Pebble Smart Watch Emoncms Heating Control Demo

    0
    0
    This post follows on my post a while back on Emoncms heating control, and links in with my previous post on using Tasker to display Emoncms notifications. For details of the hardware and overview of the heating control setup, see the Emoncms heating control post linked above.

    The Pebble is a Bluetooth connected smart watch which works with Apple and Android smartphones. Using an e-ink display the Pebble watches achieves a week of battery life. Very impressive from a hardware point of view. I've been using a Pebble with my Android phone for the past couple of weeks and found the Pebble to be useful for keeping up with notifications while out out and about and especially for controlling music, navigation directions and activity tracking while out biking, running, driving and even swimming!

    The thought occurred to me that the Pebble could potentially be a super convenient way to quickly control my heating. I've got working a simple demo to turn my heating on and off, the could easily be extended to allow setting a set point.

    When the Pebble was first released my friend Ryan Brooks put together a demo to display feed data from Emoncms on the pebble. The code for this demo is up on GitHub, however since then things have moved on, Pebble have released SDK 2.0 and launched the pebble app store allowing many applications to be easily loaded onto the Pebble. One of the more powerful applications is Pebble Tasker, when linked with the main Tasker App on an Android phone the possibles are endless. See my previous blog post on using Tasker to display Emoncms notification on an Android phone. Taking inspiration from Nathan Chantrell's home automation setup using Pebble and Tasker I decided to have a go at directly controlling my heating from my Pebble, here is the result:







    Here are the steps to replicate this system:

    1. Install Emoncms on a Raspberry Pi and enable RF12 Packetgen Module 

    I used the new pre-built SD card image for the low write version of emoncms, downloadable from the link below. This is soon to become our default Raspberry Pi pre-built image once testing is complete

    Following the setup guide enable local logging and configure emonHub

    The heating control setup requires the emoncms Packetgen module. Follow the steps to enable packetgen to work with emonHub. 
    More info on packetgen module can be found: https://github.com/emoncms/packetgen

    2. Setup RFM12B receiver and control relay 

    To perform the actual control of the boiler you will need to setup an RFM12B receiver node with a relay or similar. The actual hardware setup will depend on what you want to control, a JeeLink or partially populated emonTx V2 work well as a good base for the control hardware. See my previous post on heating control for more info regarding the hardware. The packetgen module will provide an example Arduino sketch to upload. 

    3. Install and Configure Tasker on your Android Phone 

    https://play.google.com/store/apps/details?id=net.dinglisch.android.taskerm

    The emoncms API to set a packetgen variable is as follows:

    http://YOUR_EMONCMS_SERVER_IP_OR_HOSTNAME/emoncms/packetgen/update.json?id=4&value=1&apikey="YOUR_RW_APIKEY"

    ID is the id of the packetgen variable (they start at 0) and value is the value to be set, the example above will turn the heating on setting variable 4 which in my setup is a boolean control variable to '1'. You can test if this is working by calling the API in your browser.

    I've created a Tasker template task which calls the above API which can be downloaded from Github and imported into Tasker, follow instructions on Github Readme. Variables should be self-explanatory.

    https://github.com/emoncms/AndroidTasker


    If a successful response is received from the Emoncms server a 'success' notification is displayed, else a fail notification is activated. 



    Home screen Tasker task shortcut widgets can be created on your Android home screen to allow Tasker tasks to be easily activated, or profiles can be setup to turn the heating on as you arrive home / leave work or certain times per day. The possibles are endless! Just make sure your system has some hardware fail-safe so you don't get home to a house like a sauna or worse!


    If you are setting up Tasker yourself from scratch setup GET requst as follows:

    New Task > + new action > net > HTTP GET > enter HTTP API above into host and (optionally) write output to log file 


    4. Install & configure Pebble Tasker on the Pebble Watch


    To map Tasker tasks to allow easy control from a Pebble 


    Other Pebble Tweaks I've found useful

    While not directly relevant to heating control here are some further details of my Pebble smartwatch setup: 

    • Using PebbleBits firmware on the pebble to quickly launch pebble apps from the watch face
    • Using Tasker to Stop / Start Strava 
    • Modern Watchface is my favourite watch face (shown in demo above)
    • Music Boss is great for controlling music and starting podcasts while driving or biking
    • NavMe is great for directions on the Pebble while on the bike  
    • Tasker can be used to send commonly sent SMS's and call favourite contacts direct from the Pebble 







    Monitoring SolarPV, Heatpump and house electric, EmonTx v2 system upgrade example

    0
    0
    Several years ago we did a community energy monitoring project in our local area, Penrhyndeudraeth, North Wales. It involved installing 20 openenergymonitor energy monitors in 20 households and carrying out energy assessment looking at electricity, heating and transport, there is a little more about it and some of the tools we developed here.

    The houses that where most engaged in the monitoring part of the project still have those energy monitors installed and yesterday I went to upgrade one of these systems, I thought Id write a blog post on what I did (written half as a guide) as it might be useful for those using older hardware such as the emonTx V2 and its also quite an interesting example of what you can do with the monitoring system.

    The upgrade essentially involved replacing a first generation nanode basestation with a RaspberryPI basestation running the latest image and also upgrading the emontx v2 that was in place with new firmware that both does the higher accuracy continuous sampling (developed by Robin Emley) and the watt hour calculation on board.

    This particular system is measuring Solar PV generation, household electric consumption and the electrical consumption of a heatpump. It has an EmonGLCD Display running the SolarPV firmware, with the red/green glowing ambient light depending on whether more power is being used than generated or vice versa and the data is also posted to emoncms.org for graphing.

    Here's a system diagram:

    EmonTx:

    Upload to the EmonTxV2 the continuous sampling + watt hour firmware:
    https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV2/emonTx_continuous_watthours 

    The same thing can of course be achieved with an EmonTxV3 but with the added benefit of a fourth channel and only needing the one ACAC Power adapter. If you have the EmonTxV3 upload the continuous sampling + watt hour firmware found here: https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV3/RFM12B/Examples/emonTxV3_continuous_kwhtotals_noeeprom

    EmonGLCD
    Open the SolarPV example: https://github.com/openenergymonitor/EmonGLCD/tree/master/SolarPV

    On lines 68 and 69 change the emontx radio packet defenition from:

        typedef struct { int power1, power2, power3, Vrms; } PayloadTX;
        PayloadTX emontx;


    to:

        typedef struct {
            unsigned long msgNumber;
            int heatpump; // heatpump
            int power1; // house power
            int power2; // solar power
            long wh_CT1;
            long wh_CT2;
            long wh_CT3;
        } PayloadTX;
        PayloadTX emontx;


    I've named the second variable here heatpump instead of power1 and then powers 1 to 3 because power1 and power2 are used as house power and solar power lower down in the firmware.

    RaspberryPI Basestation
    I used the latest (28th of July emonSD image) that has EmonHub (thanks to Jerome and Paul Burnell) and emoncms ready to go but without the local emoncms installation enabled, the PI was just used as an EmonHub gateway forwarder to emoncms.org. I used the nice pimoroni berryblack raspberrypi case so that the installation was tidy.

    Download ready-to-go image: emonSD-28-07-14.img.zip

    To configure EmonHub to post to emoncms.org, SSH into the raspberrypi and put the PI in read/write mode with:

        rpi-rw

    and then open the emonhub configuration file:

        nano /etc/emonhub/emonhub.conf

    Set the dispatcher url to: http://emoncms.org and the apikey to your emoncms.org account write apikey.

    In order to decode the emontx continuous + watt hour radio packet add a node decoder to the nodes section in the emonhub config file at the bottom:

        [nodes]
        [[10]]
            Datacodes = L,h,h,h,l,l,l



    Secure the pi user by changing the password (the default password is raspberry)

        passwd

    Place the PI back in read only mode:

        rpi-ro

    Emoncms configuration

    With the emontx running and the raspberrypi configured as above the inputs will now appear in emoncms.org, but they will be un-named. For this particular installation I named them as in the picture below to correspond to the radio packet format and what I knew I was monitoring on each CT channel.

    I then logged each of the power inputs to a fixed interval with averaging (PHPFiwa) feed and used the Wh Accumulator input processor to record the Watt hour totals. The Wh Accumulator checks if the watt hour total has reset and if it does it continues the accumulation from the last point. I used the fixed interval without averaging feed engine for the watt hour feeds.


    To make use of the higher accuracy calculating of watt hours on the emontx and the recording of watt hour feeds, there is a slightly different procedure for creating dashboard kwh per day graphs:

    Creating a daily electricity consumption graph in a dashboard using watt hour feeds (instead of the old power_to_kwhd method).  


    Create a new dashboard and select visualisations > bargraph.

    Click on the bargraph and click configure to bring up the configuration dialog. Select the watt hour feed that you want to display daily totals from, enter interval, units, dp, scale and delta=1 as below: (Note that you could change the interval here to any interval: hourly, half day, week etc)

    Click save and continue to add any other text and widgets as required. A simple dashboard showing daily consumption and the current power could look like the screenshot below and could be repeated adding a graph for each channel, heatpump, solarpv and house consumption.

    A right to build: An open approach to housing provision: self-provision

    0
    0

    http://issuu.com/alastairparvin/docs/2011_07_06_arighttobuild
    A right to build is a booklet written by Alaistair Parvin of (00 and Wikihouse), David Saxby, Cristina Cerulli and Tatjana Schneider that outlines a clear and comprehensive vision for how a self-provision approach to housing could be the best way to tackle the UK housing crisis while delivering higher quality, higher performance low energy housing.

    Its a deeply inspiring vision of the potential power that empowering, distributive, open ways of doing things, that gives us all agency, to participate in solving problems like climate change can have.

    'A right to build' starts by making an observation that we have become accustomed to an assumption that progress in production is the expansion of mass-produced goods, built by professionals and mass-consumed by citizens, a legacy of the industrial revolution, but far from progress the report provides a strong case that the large house builder model has actually resulted in a deterioration in the quality of housing when measured against modern examples of self-provision and self-build.

    Driven by a combination of massive house price inflation over the last 40 years and the associated treatment of homes increasingly as financial assets, the incentives for higher quality housing has been sidelined with financial values being pursued over use value.

    Who should build?

    “The question is not ‘What homes do we need?, but rather ‘Who should build them?’ “ - A right to build.

    Self-provision


    Self provision of housing is a spectrum of models, the most common characteristic is that the first owners act as the client commissioning their own home. Beyond this there is a varying degree of involvement. From contracting out all of the work or doing a lot of the work yourself (self-build).

    Advantages to self-provision:

    Self provision fundamentally transforms the kind of houses and neighbourhoods that get built:
    • Designed for long term use-value, higher quality: affordability, generosity, sustainability, flexibility, community. Form of production that is structured around valuing those things.
    • Increased affordability. Overall cost often a third less and can be even less if you use your own 'sweat equity' (do a proportion of the building work yourself).
    • More innovative, more likely to explore more innovate architectural styles and newer and higher performing low energy building materials. More likely to create spaces that lead to further innovation: workshops, garages.
    Self-provided housing is intrinsically more capable of delivering better outcomes because the developer is the user.

    Removing barriers to participation

    “The most challenging, but most crucial aspect of scaling the self-provided housing sector is not just increasing capacity for the current self-providing demographic, but coming up with innovative models which lower the economic threshold for participation.”

    It mentions the Walter Segal system for self-build conceived in the 1960s and 1970s which is one historical example of an attempt to do this.
    1. Used an affordable, widely available and easy-to- work with material: timber.
    2. Lowered the skill-threshold for self-builders. With a bit of basic training and common sense, even those who didn’t have mainstream construction skills could put together a Walter Segal house.
    Alaistair Parvin and 00's more recent project is wikihouse an open source low energy affordable home construction system that makes use of modern CNC manufacturing methods and self assembly on site. Wikihouse has a growing global community of people developing design's, sharing them openly online and prototyping these housing solutions. Like Walter Segal's system the aim is to lower the economic threshold for participation both by creating an open source self-build system and all the learning resources and collaboration, peer to peer support systems that can come from online open source projects.

    Towards the end of the report a very good point is made about the mistaken attitude and opportunity lost that often classifies the professional-citizen relationship:

    “Thirdly, by treating citizens only as passive users of a finished commodity provided by professionals, it can actually decrease the usefulness and quality of that commodity (as this booklet has argued in the case of housing) and decrease also the self-reliance and mutual support within communities. Citizens can be treated as passive, rather than active users, and their potential value can be overlooked. As the New Economics Foundation wrote in their 2008 pamphlet on the subject:


    “The reason today’s problems seem so intractable is that public services, and technocratic management systems, have become blind to the most valuable resource they possess: their own clients and the neighbourhoods around them. When these assets are ignored or deliberately side-lined, then they atrophy.””

    This is arguably one of the key principles of open source which is perhaps one of the clearest definitions of a system that enables this, a phrase commonly found in open source projects is that this project is open for everyone. Its open to everyone to make build, improve, modify, share, learn.

    By treating fellow citizens as co-developers, fellow self-providers as equal contributors rather than passive consumers it unlocks this capacity that we all have.

    Read the A Right to build here http://issuu.com/alastairparvin/docs/2011_07_06_arighttobuild

    Alaistair Parvin's TED talk: http://www.ted.com/talks/alastair_parvin_architecture_for_the_people_by_the_people

    Wikihouse: http://wikihouse.cc/

    From the Forum: Using Modbus RS485 to read a SDM630M 3-phase meter

    0
    0

    JBecker writes :

    I am using a modified OpenEnergyMonitor energy monitoring hardware since more than a year now, with one voltage sensor and three CTs for the current measurement of the three mains phases. This system logs via the RFM12 and a Jeelink USB dongle to Emoncms on a Windows Home Server. This setup is running very reliably with an accuracy of better than ~4% compared to my power meter. I think it would be possible to get better accuracy by using individual voltage sensors on all phases.

    In Germany the majority of household have three phase supply. To be able to use three voltage sensors it would be necessary to have three outlets within the distribution (for non-invasive mounting). I have never seen that. This means that you have to ask a friendly electrician to install these outlets. But then the whole thing is not really 'non-invasive' any more (and the OEM solutions becomes quite complex with a lot of cabling). This is a dilemma which is hard to solve.

    So I came to another solution which is quite simple and uses mostly ready-made components:

    I am using Chinese 3-phase energy monitors since some time for professional purposes (PV-Systems with battery storage). A very nice unit of this type is the Eastron SDM630M. This device has integrated shunts for current measurement, a nice little display and an RS485 interface for data readout with Modbus protocol. A lot of measuring values can be read, including imported and exported energy, phase voltages, currents, frequency, reactive power and so on. Parameters for the RS485 can also be set via four small keys and the display.



    For data storage and visualization I decided use the new Emoncms 'low-write' version on a Raspberry Pi. This was installed according to the installation instructions and worked 'out-of-the-box'. The only thing missing on the RasbPi for direct connection to the SDM630 is an RS485 interface.



    To be able to use the already existing software for data collection on the RasPi (Emonhub), I simply made a 'clone' of the RFM12Pi module. This now has an RS485 driver onboard instead of the RFM12 RF transceiver. Software on the RS485Pi board is the Opti-bootloader (same as on RFM12Pi) for Arduino compatibility and a small sketch for data readout via modbus. As the only available hardware UART is already used for communication with the RasbPi I had to use a software serial for the RS485 interface. (The 'ModbusMasterSoft' library I use is a dirty hack of the existing ModbusMaster library and the AltSoftSerial library. I found no decent way to make these two work together, so I had to modify them)

    So the whole installation now consists of:

    - a Raspberry Pi with power supply and the RS485Pi interface board

    - the SDM630 energy meter

    (- and a cable in between :-))

    See forum thread for schematic and code: http://openenergymonitor.org/emon/node/5743



    Emonhub installation/update, replacing the PHP raspberrypi emoncms module

    0
    0
    From Paul Reed's post on the forums here:
    http://openenergymonitor.org/emon/node/5986

    Emonhub is now the recommended method of interfacing a rfm12pi to a local or remote emoncms install, and replaces the PHP and Python scripts which we have previously used.

    Update: This blog post refers to installing emonHub on existing system, if setting up a new system downloading the ready-to-go pre-built RaspberryPi image is the easiest way to get started.

    Thanks to Paul Burnell, the author of emonhub, installation of emonhub can be achieved via a command line, which clones an installation script to automate the installation process.

    To install emonhub:

    $ git clone https://github.com/emonhub/dev-emonhub.git ~/dev-emonhub && ~/dev-emonhub/install

    If you have the raspberry pi module already installed, it's important that it is removed prior to installing emonhub, as only one software can use the serial UART the RFM2Pi is connected to at any one time.

    To remove the existing module, and then install emonhub, enter the following command line;

    $ git clone https://github.com/emonhub/dev-emonhub.git ~/dev-emonhub && ~/dev-emonhub/upgrade

    You will notice that after running this command, that emoncms will stop updating, this is expected until the configuration file is updated as follows;

    $ nano /etc/emonhub/emonhub.conf

    Enter your emoncms read/write api key in [[[runtimesettings]]] and also enter your rfm2pi frequency, group & base id under [[[runtimesettings]]]
    Save your settings, and; $ sudo service emonhub restart

    Problems?
    View the error log; $ tail -f /var/log/emonhub/emonhub.log

    By default this is set to record 'WARNING', however this can be changed to either - DEBUG, INFO, WARNING, ERROR, and CRITICAL by editing the configuration file.

    Paul

    NOTE - This update will not orphan or alter your input processes, feeds, visualizations or feed data, as it only changes the way in which data is fed to emoncms.

    Testing KiCad PCB

    0
    0
    We are always a fan of using open-source software wherever possible. A few years ago I briefly attempted to use open-source KiCad and gEDA PCB CAD software but found them very limiting, clumsy and buggy.

    Recently there have been a raft of shiny looking browser based PCB design tools such as Circuit Maker and Upverter, these look very interesting; the online collaborative development opportunities are obvious and linking into the OctoPart's live component pricing, standard part library and BOM management tools could be a big time saver at the manufacturing stage. Maybe online tools will be the future, however I am a little reserved about having designs locked into a closed online platform.

    In particular I have been keeping a close eye on KiCad developments after I heard CERN had got involved in the development. I was very impressed watching this video showing the newly developed KiCad intelligent semi-auto router in action:


    I think it's time I gave KiCad another try! Today I managed to install KiCad and put together the RFM12Pi schematic and layout the board. Here's my experience:

    I wanted the latest build to get the shiny new features, so I installed the development branch by adding the PPA to Ubuntu:

    http://ppa.launchpad.net/js-reynaud/ppa-kicad/ubuntu

    I installed KiCad build dated 16th July on 32-bit Ubuntu 14.04

    I found I needed to add the line "export KIGITHUB="https://github.com/KiCad";" to my ~/.profile file to get rid of cannot find github footprint errors when running CvPCB (the program in KiCad which links the schematic parts to PCB footprints)

    I followed the fantastic video tutorials from Contextual Electronics to help me get started.


    1. KiCad Schematic Editor, net list must be manually exported to move to the next setp

    2. Linking schematic parts to PCB footprints

    3. Board layout the new interactive router was great (see video above)
    New router options

    Update: the finished Kicad RFM2Pi V2.7 design is up on github:

    https://github.com/openenergymonitor/Hardware/tree/master/RFM2Pi/board/KiCad_RFM12Pi%20V2.7

    Obviously we have considerable lock-in to EAGLE PCB with our historic designs and learning a new software tool is always going to be a slow and slightly frustrating process, however I'm quite impressed that after about 5hrs I think I'm got the hang of basic KiCad functions. I will seriously consider using KiCad for new designs in the future. I think the increased effort will be worthwhile to enable us to be using a fully open-source bit of design software to design open-hardware, what do you think?

    Thinks I liked about KiCad:
    • Interactive router, very impressed with this. Big time saver
    • More intuitive setup of default track widths and net classes 
    • How net and pin names are displayed in the layout editor 
    • How schematic symbols and PCB footprints are handled as separate entities, more intuitive than Eagle IMHO  
    Thinks I miss moving from Eagle:
    • Have a live link between schematic and PCB, KiCad requires exporting and re-importing a new netlist each time there is a change in schematic
    • There are more ready made parts in Eagle libraries then there are KiCad part libraries, but I'm sure this will change. 
    • Being able to highlight all tracks on a particular net by selecting a wire on the schematic (maybe I've just not found this feature yet in KiCad?)

    Snowdonia household energy study, exploring zero carbon solutions

    0
    0
    A couple of years ago Glyn and I and a friend of ours Bethan Gritten carried out an energy study with a local organisation called EcoBro of 17 households in Snowdonia, North Wales including our own.

    We looked at the energy used by each household for electric, heating and transport and what the effect would be of applying the solutions outlined in both ZeroCarbonBritain and Sustainable energy without the hot air, visualising the result using David MacKay's energy stack graphics.

    I've been looking again at this work recently as I find it a really useful and tangible way of looking at the energy problem and I've taken the opportunity to improve the energy stack graphic visualisation and put it up online here:

    Dynamic visualisation:
    http://egni.ecobro.org/data

    The code for it is open source and on github here:
    https://github.com/TrystanLea/energystacks

    Here's a brief run through of what you can see:

    Current Energy Use
    This first graphic shows each households current energy use and where that energy is used:


    24% of the energy used by the households come from renewable sources, whether biomass or 100% green electricity tariffs. The wide range of total energy use per household is quite interesting, using the dynamic tool you can explore the contribution of occupancy and floor area. You can also look at C02 and energy cost per household.

    Solutions for reaching 100% sustainable energy for household electric, heating and transport.

    In both the ZeroCarbonBritain report and David MacKay's Sustainable Energy without the hot air, building retrofit (insulation and air-tightness), heatpumps and electric vehicles form the cornerstone's of both significantly reducing the amount of energy we need to provide the same amount of comfort/utility and making it possible to power the remaining energy demand from electricity generated by sustainable energy.

    The following graphics show's what the effect would be if each household in the study applied these measures:

    1) All households switch current electric consumption to a 100% Green Electricity tariff:


    2) 100% green electric powered heatpumps, Biomass and electric cooking instead of oil, gas and coal. For heatpumps it assumes replacing existing heat input with a heatpump with a COP of 3.0. See step 5 for a very basic application of building performance retrofit work.

    Heatpumps form the cornerstone of supplying the remaining heat demand after retrofit in both Zero Carbon Britain and David MacKay's sustainable energy without the hot air. The performance of a heatpump is highly dependent of course on being designed, installed and controlled correctly.


    3) Switch all petrol and diesel cars to electric cars powered by renewable electricity (Assuming mileage stays constant and an electric car performance of 4.0 Miles/kWh)

    The ZeroCarbonBritain report from CAT suggests a reduction in the number of miles driven through a combination of increased use of pubic transport, walking, biking and better planning of where we live in relation to work/activities in addition to a switch to electric vehicles which are both more efficient than petrol and diesel cars and can be powered by renewable electricity.


    4) Electric trains instead of planes:

    In order to achieve the last 15% and still enjoy travelling long distances we would need a switch from flights to electric train journey's, the model here just assumes that the number of flight miles are replaced with electric train miles powered by renewable electricity and that the destination is reachable by train.



    5) At least 120 kWh/m2.year primary energy for space heating and home electric.

    Improving the thermal performance of buildings by adding insulation and improving the air-tightness should be one of the first measures applied and considered before or at the same time as any heating system changes as in step 2 above. The implementation of applying retrofit measures in the energy stack visualisation model here is only to set a maximum primary energy use requirement rather than to explore what's possible on a house by house basis which would give a better picture of the potential savings from retrofit work.



    Powering Up with Renewable Energy

    The ZeroCarbonBritain report goes into a lot of detail on how the remaining energy demand after applying power down measures can be supplied by renewable energy and also the need for storage technologies to manage the intermittent nature of a fully renewable energy supply. We didnt look into this as part of our study but it would be interesting to explore it in more detail in the future to answer questions such as: what scale of community energy projects such as community wind, solar and hydro should we be thinking of if we are to supply our energy demands after applying power down measures? and how much should we be thinking about energy storage in a more local context?

    There's a lot of things that could be improved about the study. Rather than applying back of the envelope calculations on the effects of applying the various solutions to each house it would be better to look at each house in detail, carrying out a full detailed Carbon Coop home energy assessment for each house on how energy demand can be reduced by up to 70% through retrofit work.

    Related links

    OpenEnergyMonitor page on Sustainable Energy:
    http://openenergymonitor.org/emon/sustainable-energy

    The ZeroCarbonBritain report:
    http://zerocarbonbritain.org/
    Alice Hooker-Stroud, Centre for Alternative Technology, ‘Zero Carbon Britain (Energy)’

    Sustainable energy without the hot air
    http://withouthotair.com/

    Carbon Coop
    Charlie Baker's talk about carbon coop and 80% retrofit at the radical emissions reduction conference


    Where next?
    I would be interested to hear any thoughts on how to develop this work further, where it should go next. Feel free to email me if you have any ideas or would like to discuss: trystanlea at openenergymonitor.org

    Research Project Call for Participants

    0
    0

    In collaboration with Corina Sas from Lancaster University we would like to to evaluate members' experience of building, setting up and using our monitors and how these impact on people's understanding of energy consumption and household practices. The larger aim is to to explore how energy monitoring technologies could be better designed to support sustainable practices.

    A team of researchers for Lancaster will run this study consisting of interviews lasting around 1 hrs. For this, a researcher will visit you in your home at your convenience, or if you live further away from Lancaster/Manchester, then Skype interviews can be arranged. As a thank you will be offer you an organic veg box.

    The plan is to complete the study by end of the year. If you are interested and able to help, please contact the researcher with your available dates: Dr Corina Sas at corina@comp.lancs.ac.uk

    Thanks a lot for your support.

    Please post any questions to forum thread: http://openenergymonitor.org/emon/node/6156

    Introducing RFM69CW

    0
    0
    For sometime now the Hope RF RFM12B module has been our RF module of choice. This module was chosen for it's low cost, decent performance and importantly for us, an active development community. On the software side we use the excellent JeeLabs JeeLib RF12 Arduino library.

    About a year ago Hope RF announced the RFM12B to be 'EOL' (End-of-Life), there has been a degree of confusion as to what exactly this means; currently manufacture of the module is still taking place and supply is still easily available. However, we acknowledged that the time had arrived to look for alternatives since Hope RF no longer offers support or recommends the RFM12B for new products. 

    An obvious alternative that was explored by JeeLabs  is the Hope RF RFM69CW module, it uses SEMTEC designed silicon (as opposed to Silicon Labs in the RFM12B). It's pin-compatible with the RFM12B. Using the updated JeeLib driver the RFM69CW is be backwards compatible with RFM12B helping users of RFM12B to make a smooth transition. Thanks to JCW from JeeLabs and LowPower Labs for the work on developing the RFM69CW Arduino library. We have been working with JeeLabs to source modules and test the driver software.    

    Hope RF RFM69CW


    I will let JeeLabs/DigitalSmarties introduce the module 

    "The recently announced RFM69CW radio module by HopeRF is a compact, powerful radio transceiver module for swapping data packets in the 868 MHz ISM band, using standard and enhanced FSK modulation. Great for sub-compact designs; just 4mm of mounted height from using an SMD precision crystal.

    Though consuming a similar level of power, the RFM69CW receiver section can decode fainter signals than the classic RFM12B. The transmitter section *maximum* output power is +13dBm, considerably higher than the +5dBm of the RFM12B. The current drain at these (adjustable) higher power settings is correspondingly higher. With the better receiver sensitivity, many applications will not need to use the higher transmit power settings, potentially saving on battery life.

    Comparing like-with-like, pairs of modules will generally have greater range and/or better penetration of walls/ceiling than when using pairs of the classic RFM12B.


    The physical module is compatible with the PCB footprint on all current JeeNodes and JeeLinks. For details of the fast-evolving level of software support, see this Forum topic.

    Control is via a fast SPI bus with reduced MPU loading. The recommended power supply range of 1.8 < Vdd < 3.6 V can squeeze almost the last energy out of depleting batteries without needing a boost converter."





    Comparison tabled compiled by http://www.mikrocontroller.net/articles/RFM69


    Early next year we will start transitioning to the RFM69CW, end-users should not notice a difference apart from a new input on the emoncms Inputs page 'RSSI' (Received Signal Strength Indicator), see below.

    To simplify manufacture and module sourcing we will be standardising on 433Mhz, we will make available no-RF versions of units for users who wish to solder on their own 868Mhz modules. See forum thread

    RFM69CW on the emonTx V3.4 

    For early adopters we have limited numbers of RFM12Pi Raspberry Pi Expansion with RFM69CW module in the shop. Using the latest emonHub software (currently in 'Testing' branch) using the RFM12Pi with RFM69CW on a Raspberry Pi should be seamless, emonHub automatically detects the higher baud rate requirement of the RFM12Pi with RFM69CW (56700 as opposed to 9600 with RFM12B RFM12Pi) sets baud accordingly and starts posting RSSI (received signal strength indication) to emoncms.
    RFM69CW on the RFM12Pi on Raspberry Pi Model B+

    Example RSSI value from emonTH in emoncms

    The RSSI readings are very useful as they give a quantitative means of comparing RF performance which should help when deciding on the positioning of units during install and developing better antenna setups.

    RSSI readings from nodes setup in my house (mix of RFM12B and RFM69CW) 

    RFM69CW on the upcoming emonPi Raspberry Pi Energy Monitoring Shield (due for launch in the new year) 

    For more info on the RFM69CW see Building Block Overview Page:

    http://openenergymonitor.org/emon/buildingblocks/rfm69cw

    Kettle vs Blanket

    0
    0
    One of the things I love about monitoring energy is that it can be used to answer questions and inform decisions.

    In my household we have recently purchased an electric blanket, I had always associated such items as an indulgent luxury! However at this time of year the temperature in our bedroom is often only just about in double figures (old property with poor heating and frugal use) necessitating a seemingly moderate luxury of a hot water bottle to warm the bed up a little.   

    I assumed using the new electric blanket would result in an increase in our power consumption, however the energy monitor proved me wrong! 

    Having the electric blanket on for 30min used about 0.1KWh while boiling 1L of hot water to fill at hot water bottle used about 0.16KWh of energy, 60% more! Also the electric blanket does a much better job of warming the bed then the hot water bottle, after 30min it was almost uncomfortably hot even with an ambient temperature in the room of 11 degrees! 


    200W Electric Blanket on for about 30 min

    Kettle heating 1L of water to boiling

    Introducing emonTx V3.4

    0
    0
    Now shipping later this week in the shop is an updated version to the emonTx V3. This is a relatively minor update feature and form factor wise, most users probably won't notice the difference. However when hardware is involved, no update is a minor update!

    emonTx V3.4 is now available from the OpenEnergyMonitor Shop



    The main changes  are under the hood; the ATmega328 Arduino compatible microprocessor is now is now laid down directly on the PCB. This will help with manufacture and give us a few extra I/O to pay with that were inaccessible on RFu328 module that we used on the original emonTx V3.2. The changes also bring us back in line with JeenNode hardware (IRQ and INT connections) which allow us to use the latest RF12 JeeLib library to support the RFM69CW (see separate post).

    emonTx V3.4 Installed

    emonTx V3.4 - production units will have battery holder fitted - omitted for photo to show components

    Features 

    New features on emonTx V3.4 over V3 shown in bold:
    • Measure AC Apparent Power, AC Real power* and AC RMS voltage*
    • 3 x single-phase CT current sensor inputs (100A / 24KW @ 240V max)
    • 1 x high sensitivity single-phase CT current sensor input channel (18.8A / 4.5KW @ 240V max)
    • 1 x RJ45 input for connecting DS18B20 temperature sensors
    • Single AC-AC adapter can power the unit and provide AC voltage measurement
    • An on-board 3x AA battery option withremote monitoring of battery voltage
    • Terminal block access to power rails, digital and analogue I/O and IRQ port for connecting pulse counting sensor / DS18B20 temperature / Aux sensors
    • DIP switch selection of RF node ID and 240V/110V AC adapter selection, see #DIP Switch Config
    • SMA antenna included as standard 
    *when AC-AC voltage adapter is connected


    emonTx as part of the OpenEnergyMonitor system
    The emonTx V3.4 uses an edge SMA connector with an SMA antenna included as standard. We have standardised on 433Mhz (see forum post). The emonTx V3.4 supports and will eventually ship with the new RFM69CW module, this module is backwards compatible with RFM12B. However due to sourcing and lead time issues we have had to use RFM12B on the first batch of 500 units of emonTx V3.4 (now in the shop). When the RFM69CW is used a RSSI (Received Signal Strength Indicator) will appear in emoncms giving indication of signal strength. 

    emonTx V3.4 with RFM69CW and edge SMA connector 
    The emonTx V3.4 has the addition of an RJ45 socket to allow ease of connecting multiple DS18B20 temperature sensors. Screened RJ45 cabling (Ethernet) is commonly available as well as RJ45 splitters and extenders. This makes a quick and easy way to wire up a house / heat-pump etc for temperature monitoring. Power, GND, IRQ, ADC and PWM I/O's are also available through the RJ45 connector, see wiki for pinout and technical details.

    Note: the RJ45 connection is not Ethernet, TCP network switches and routers should not be used 

    RJ45 connector used with RJ45 terminal breakout for connection of multiple encapsulated DS18B20 temperature sensors, DS18B20 temperature sensors are also available wired directly on RJ45 connector

    DS18B20 Temperature Sensor on RJ45


    Certification & Environmental

    The emonTx V3.4 is EMC compliant, CE certified. 

    The unit is manufactured and assembled in the UK using lead free processes, with RoHS and conflict material free components. The enclosure is made in the UK using recyclable aluminium and recycled acrylic plastic is used for the front and rear fascia. 


    Links 

    Viewing all 196 articles
    Browse latest View live




    Latest Images