Editing SolarMonitoring

== Principles / Use Cases == (that is, what do we want this system to do?) * Data storage and display would not be tied to any particular hardware in the home. * provide a web page for showing energy collected and dispensed? * alerts on system failure? * alert when the water tank is nearing "full" of hot water? * report monthly, annual etc. energy collected ** for PV ** for thermal hydronic ** for thermal air * ''add more use cases here'' ==Base Hardware== * RPi + Dallas 1-Wire Bus. 1-Wire Bus is a versatile, cheap sensor system that has been in use for decades with thousands of applications. [http://wannabe.guru.org/scott/hobbies/temperature/ example RPi + 1-Wire system here] * For applications where we can't easily run twisted pair network to the RPi, use a USB Wi-Fi adaptor: http://dx.com/p/ultra-mini-nano-usb-2-0-802-11n-150mbps-wifi-wlan-wireless-network-adapter-48166 * Power Supplies: ** [http://dx.com/p/micro-5-pin-us-plug-power-adapter-for-htc-samsung-blackberry-black-185418 black, 3.5' cord] ** [http://dx.com/p/us-plug-usb-charging-adapter-white-166115 Tiny charging head, white] ** [http://dx.com/p/ac-power-charger-adapter-for-iphone-black-grey-us-plug-100-240v-181965 "Apple" style in black/grey] * RPI2 host adaptor gives us reliable communications on long 1-Wire buses + owfs which reads all available 1-wire sensors http://www.sheepwalkelectronics.co.uk/products-adapters.shtml ==More about 1-Wire & RPi== * [http://owfs.sourceforge.net/ The One Wire File System Page] * [http://www.1wire.org/Files/Awtrey/Articles/Intro%20to%201-Wire.doc Intro To 1-Wire] from http://www.1wire.org * [http://www.maximintegrated.com/app-notes/index.mvp/id/148 How to create a reliable 1-Wire Bus network] * Using the OWFS driver: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=27379&p=244418 * Cambridge tutorial: http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/temperature/ * If you only need temperatures, you can use the RPi GPIO pins: http://pi-io.com/apps/temperature/ds18b20/ ===Software=== * OWFS drivers for reading the sensors: http://owfs.org/ * Custom built !DataRe software for collecting, transmitting, storing & displaying the data ===Also Considered=== * RPi + Adafruit board * RPi + Arduino: http://wyolum.com/raspberry-pi-a-la-mode/ * Dallas Semiconductor TINI http://www.futurlec.com/News/Dallas/InternetIC.html * Software: possibly Mister House: open Source Perl http://misterhouse.wikispaces.com/ ===Sensors=== Content moved to [[1-Wire Sensors]] page Huge sensors catalog here: http://www.gemssensors.com/ ==DHW== http://bonmot.ca/HouseData/images/2013-03-20_dhw_t.jpg [http://bonmot.ca/HouseData/images/2013-03-20_dhw.jpg Schematic] ==Software Systems== ===Principles=== Do not expose the in-home device to the Internet: (1) will make the device, and entire house, vulnerable to hacking which will (2) make SHINES liable for damage to customer network, data etc (3) would require SHINES to constantly update and patch all the in-home systems to keep them hardened. Instead, have a central system run by !ShinesRe which clients log into (same model as the microinverter system we installed at Dave Brake's.) ===In Home Device=== * Preferably some variant of Linux * Data collection in Python or Perl * Once every period - five minutes perhaps - the in-home system would collect a (XML probably) data record and write it to a queue. * Periodically (also possibly once every five minutes) the data would be posted via HTTPS to the SHINES mothership. * The units of the data posted will not be raw voltages and state, that is, not "Port 12 is at 16.8 volts". Instead it will be real world units tagged with semantic names, e.g. "top of tank temperature = 55°C" * A configuration file on the in-home device will list the kind and semantic name of each sensor connected to each port; the aquisition software will convert the raw data into real-world units. * Data will be stored in XML in small timestamped files on (SD card) disk. ===Data Transmission=== * Periodically (also perhaps every 5 minutes) any collected data will be posted via HTTPS to the SHINES mothership. * If the connection to the internet has been interrupted, all the items in the to-be-sent queue will be sent. * The post will include a username, password and data collection device name for that customer. * "Received and stored" will be passed back to the in-home device so it can clear that item from the queue. * At the same time some other instructions could be passed to the in-home device. ===Data Storage=== * Data will be received from HTTPS posting and stored in a MySQL database. * Columns will be client name, device name, data collection timestamp, semantic name, value & units. ==Data Display== Possibly start with: * [http://www.klein.com/thermd/ thermd] * [http://openenergymonitor.org/emon/ emon] * https://code.google.com/p/solar-monitoring-project/ * Design page: SolarMonitoringDisplay ==Plan== * Get a RPi and some sensors and start playing * Simultaneously, do some market research. How much would our customers pay for this (a) up front and (b) per month? * Model A: we install a thing and give you the URL to look at the data for e.g. $10/month. Model B: we sell you the thing (for, say, cost + 50% + labour) and set it up and then it's yours; we'll support it for e.g. $50/hour after that. ==Wish List== * Bug List & Feature Request List is here: [[SolarMonitoringToDo]]

Summary:

This change is a minor edit.

Username: