One of the great things about this Challenge is the information sharing, by the contestants.
This has been extremely helpful for those of us less comfortable with software, and I certainly appreciate it. .... so thanks.
Thanks
As well as thanking Christian and our sponsors, I'd like to thank the Australia/New Zealand element14 Marketing and the Sales department for going out of their way to assist.
Because the necessary parts aren't listed, they have arranged to purchase via the Singapore site.
So I sent the list to them and they did all the hard work for me ....
cheers.
Photo source Pin by Susan Roode Dean on minion party | Pinterest
It might surprise people to see how much behind the scenes activity is required, not just to organise these Challenges, but to implement them as well.
In my case this includes sorting out the shipment issues with Customs, which has involved a number of staff at Newark resolving issues they thought they had covered.
And who can forget Christopher and his weekly round-up/reminder. 
(yes this is early because I have 180m of fence to replace on Wed/Thursday, and I predict a self inflicted headache on Friday, due to a drinking buddy staying on Thursday night. ...)
Planning
When I applied for this challenge I had a concept and a general idea of the implementation.
When I was accepted I firmed up my initial thoughts, but due to a large list of other tasks (that had been shuffled already), I hadn't filled in what bits would do what.
I knew there would be some delays before receiving the parts, and did some research in order to see how best to use the generous voucher that element14 provided, and sent that order away.
After that it got a bit piecemeal with separate bits of paper, following blogs, working through some of the issues I had, trying this and that, and generally jumping about.
So last night I went back to good Engineering principles where planning is paramount.
IMO good Engineering is 90% planning and 10% implementation (and so far most people seem to agree), so time to plan and stop fiddling.
I documented what I was going to monitor, named it and sorted out the various bits required to insert it into OpenHAB.
While I had seen this, I hadn't sat down with it and my plan to fully understand what I needed to do.
It was also a time to remember what sensors were going to do what and what alternatives I had to source or build.
I like the EnOcean sensors because they don't require power, however there are some instances where I might not be able to use them.
1. Power monitoring.
2. Hot Water temperature.
3. Movement Sensors
For the Power Monitoring I have previously indicated that double insulation is a must, and therefore it will need external power (It's hard to get light into a box inside a switchboard).
I do have a current probe, but whether I can attach it to a STM3xx sensor analogue input and correctly configure it is unknown.
For the Hot Water I need to measure the temperature of the pipe leading out of the cylinder (or Gas unit in my case) and short of strapping the chip to the pipe, its best I use a probe that can fit to the pipe under the insulation.
The motion sensors require constant power to work, even if there was enough power, it won't work if the light is off.
This means it needs external power, and is therefore a waste of the sensor which could be used for other things.
So in the meantime my plan is to implement a couple of external solutions.
Frederick and I have been looking at the feedback options for the RF Mains switch units, so the same solution that communicates with these, can also be utilised.
Documentation
Having good documentation means that the 'wicked do everything' device you've just designed, built and installed can be fixed.
We see this at work, where the paperwork to support something is delayed as 'they haven't finished it' .... ie the planning was less than 90/10 and maybe empirically derived.
source http://www.thefreedictionary.com/empirical
There is certainly very good documentation for the EnOcean products, although a note on the default firmware features for the STM3xx sensors in the overview documents might be handy.
The users manuals for the various sensors more than adequately describe how to configure them.
Photo source me, myself and I
Getting the Raspberry Pi up and running has been covered. There is a wealth of information available, and with the extra tips already blogged here, should not be an obstacle.
The OpenHAB is feature rich and very adaptable, but is difficult for anyone starting out.
I'm hoping that at the end of this Challenge someone can put it together into a simple guide that anyone can follow.
While it appears we we have concentrated on using OpenHAB, many of us are (or intend to) use MQTT and this is part of eclipse.org ( iot.eclipse.org — IoT development made simple ) along with some other protocols and tools.
Their aim is " Our technologies aim at establishing an open IoT/M2M platform to be used by anyone." so keep an eye out to see which bits get used.
That leaves eLDERmon and how all the bits are joined.
This is the overall picture based on the concept.
My work last night resulted in this spreadsheet.
I detailed the input naming, groups and the sensor, so hopefully a cut and paste is all that is required.
(see eLDERMON_spreadsheet attachment)
Presentation
Part of my concept is being able to present the data in a manner that makes any concerns obvious.
Because an instant view of Granny's place won't convey the right information, I need to allow for both instant and graphing the information.
Thankfully fvan has documented adding two sources onto a single graph.
[CaTS] ForgetMeNot - Week 3: Data persistence and charts with OpenHAB
which was something I was contemplating doing.
I also found that the standard icon range didn't completely cover my needs, so I have been looking for extras.
What If
While searching around I ran into this.
Photo source What If Minions Take Over Winter Olympics [Fun Illustration]
So it got me thinking what it would look like if we took over element14 ...
Mark
