Started a new thread to let separate discussion
I've been thinking thru the automation aspects of RE system, given that I have existing HA - albeit
For more traditional aspects (no RE type inputs at present)
So herewith my attempt at defining "RE" sensing/automation requirements (as distinct from
More traditional HA inputs and outputs)
I've tried to structure below In a logical way we can then discuss each "block" prioritize effort
As we think best, and use a structured approach to how we gather and display data
RE sensing/automation blocks
1) PV array
2) Charge controller
3) Inverter /charger
4) battery bank
5) Generator
6) Weather
7)Solar radiation
(it's probably part of weather, but I include it separately because of it's complexity)
8 ) Loads DC and AC
9) Environmental sensors
What/how to get from each block
1) PV array
a) Fixed array
b) tracked Array
general: most useful/important data can be accessed via CC via modbus BBP
- PV string voltage and current (given its DC, and very high voltage and current)
options here are expensive and limited. .. And aside from fault monitoring - possibly don't yield ROE/I
Summary : at present IMHO we "leave it up to the CC" to manage and report
- panel temp (very useful and important) via a simple temp sensor glued to rear? Of panels
(Suggest a few to be able to get an averaging across each array)
Need to support More than one array for those with multiples
Suggest we allow for n sensors per array and x arrays (pick some reasonable number for n and y)
2) Modbus data from CC into BBP - "done" (zoneblue/Ross pls take a bow)
3) inverter /charger
a) inverter
load
status
etc
b)charger
load
status
etc
4) battery bank
a) Bank voltage (CC) - done
b) cell voltages (see other forum posts),
c) cell temps simple sensor attached to batteries
- glued on side of cell
- attached to terminal ... This measures the conducted heat out of battery onto battery terminal
Note the temp sensors are so cheap, could put one "between each cell"
5) generator
Needs a mix of voltage, current and environmental
a) start battery (voltage)
B) AC voltage,current and power output ;
AC current transformer CT (lots of work already done on this)
c) status : running, standby, manual,
d) oil and water temp
e) room temp
F) CO gas sensor
Note some generators likely provide some of above already via a status panel etc
However we can plan for worse case and assume all above need to be sensed
6) weather
A very well (over done) aspect in HA already ... So many options, hard to summarise "how"
As a minimum the RE block needs
a) ambient temp (near array, possibly "under array" also
b) humidity
C) atmospheric pressure (barometer)
d) wind speed and direction (not sure the relevance for PV?)
As a minimum BBP can have its own sensors for a) b) c) , or access a separate weather
Station .. As ZB points out ... Can use off shelf weather station and sniff it's RF (eg 433MHz )
But there are myriad of options around
(Happy to separately share my experience on this)
7) solar radiation and insolation
(Other thread topic)
a) pyranometer
b) solar "test array"
c) simple solar (eg photodiode ambient light )
Note some weather stations also have above "built in"
8 ) Loads
A) DC loads
Use low cost Hall effect breakouts circuits to measure DC current
Various modules avail off shel, to measure up to 30A + per circuit
Can measure individual circuits and look for faults and monitor loads
B) AC loads (see generator 5b above)
Plenty of ready avail options .. Just need to "read" into BPP
9) environmental
Mostly covered above
a) room temp sensors (battery room, inverter room)
b) gas sensors (CO, hydrogen, fire, smoke ) as applicable for each location
There are low cost breakouts boards that can achieve each of above
As you can see - the list is biggish - hence need to "prioritise" .. Hope I haven't scared Zoneblue
I will separately document my thoughts on the various methods to achieve each of above
We can use above list as a reference start point - and add to it as required
*********
Edits
- split item 1) into fixed and tracked
- Inverter (deleted inverter specific comments)
22/10 split module 3 into inverter and charger
BBP sensing modules vs BBP "itself" (the core)
BBP Core
- the heart of the system
- designed for always ON
- low power
- capture and log data
- display data
- ARM platform
- Linux based
- centrally located (in protected environment)
- limited onboard IO for local sensing
- scaleable capability (memory, processing)
Sensing Modules
- distributed (possibly many)
- remote to BPP core
- harsh environments
- ultra low power
- wireless option
- various IO and sensor options
- scaleable IO
- low cost
BPP Core : options
( refer separate thread by zoneblue "ARM board evaluation"
Don't post replies here on the core)
- cubieboard
- beaglebone black
- RPi
- others
Sensing module : options
- Arduino family (ATMEGA based)
Many different modules available with various IO
Interface to BBP via:
Wired (USB, I2C, SMB, SPI)
Wireless (xbee, RFM12, many other low PWR options)
-PIC
-xbee
Wireless with some limited onboard DIO ADC
-Rpi
Could fit into this category also but ..
It kinda sits between the core (memory and processing lower than other options)
And sensing module (where it higher cost makes it less attractive as c/w other options above)
- above list far from exhaustive (more a reflection IMHO of where the optimum choices lay)
IMHO
we should logically separate BBP sensing from the BBP core functions
Sensing in many cases will be physically separated also (except where using the
More limited Onboard IO on whichever BBP core platform used)
We need to keep the number sensing module variants manageable for BBP core
And re-use available "libraries" and support as much as possible
ZB
Per one of your posts in other thread
Pls feel free to use any of above in TBB wiki - as you think relevant
I agree that it may be better to maintain some things via the wiki and have them tracked and updated
In wiki
Eg the "sensing module" structure
Just a thought
Module 6a : weather Temperature Sensing
.These are simply a readily available selection I've found, from what appears
To be popular sites - to provide a starting point for information
1) DS18XX. : Dallas 1wire interface
DS18S20 : parasitic powered, ±0.5°C Accuracy from -10°C to +85°C
DS18B20 ; non-parasitic or parasitic, ±0.5°C Accuracy as above
( -55°C to +125°C measurement range)
Ds1822 : parasitic/non-para. "Eco version" ±2°C Accuracy from -10°C to +85°C
Pricing
DS18B20
- component only $4 (used on many breakout and other boards)
- waterproof housing with PVC lead $10
- high temp waterproof with PTFE lead $15
(Sparkfun.com. Adafruit.com)
2) TMP36. : analog interface (ADC)
Power supply voltage 2.7 V to 5.5 VDC
Output voltage 0-1.75V
10 mV/°C scale factor
±2°C accuracy over Operating Range: âˆ'40°C to +125°C
Price $2 raw component
(Sparkfun.com)
3) Tm102. : 2wire Bus SMB
Mounted on PCB
Accuracy: 0.5°C (-25°C to +85°C)
$6. (Sparkfun.com)
Summary:
for temperature only sensors that are collocated or remote to the sensing module,
Dallas 1 wire interface appears the most popular and functional, it's easy to daisy chain and only requires a pair of wires, the sensors are cheap and available
In various options (bare, waterproof etc), good accuracy and temp range.
For local sensor on ADC input, TMP36 feasible but with lower accuracy.
Disclaimer
I am not in any way affiliated with any of the above companies, web sites, or
Manufacturers of the modules or components
There are no doubt other ways to achieve these outcomes, and other web
Sites and suppliers that stock these and/or comparable units
Module 6b/c/d weather sensing : humidity/barometer and temperature combos
1) commercial weather stations
Various models from various manufacturers
- hard wired proprietary interface
- 1wire interface
- RF (433MHz, 900Mhz, and various) Proprietary protocols, but in many cases are published or reverse engineered
Too many options to document here
note 1wire weather instruments and sensors are popular and low cost
Where a base station display/monitoring unit is not required
(A good low cost solution for sensors only)
2) Combo sensors : humidity + temperature
A) RHT03 : "maxdetect" 1wire bus (NOT. Dallas 1wire)
Humidity from 0-100% RH
-40 - 80 degrees C temperature range
+-2% RH accuracy
+-0.5 degrees C
$ 10. Sparkfun.com
B) DHT22 : " maxdetect"1wire bus (NOT Dallas 1wire)
Similar to RHT03 above
$13 Adafruit.com
DHT11 $5 lower precision version of DHT22
C) SHT15. : 2wire serial bus
Measurement range: 0-100% RH
Absolute RH accuracy: +/- 2% RH (10...90% RH)
Repeatability RH: +/- 0.1% RH
Temp. accuracy: +/- 0.3°C @ 25°C
$42 sparkfun.com
D). HIH6130 : I2C bus
Breakout PCB
Operating Voltage: 2.3-5.5v
Compensated humidity range: 10-90% RH
Compensated temp. range 5-50°C
True temperature-compensated digital I2C output
$30 sparkfun.com
E) HIH4030. (Humidity only ). : ADC
humidity analog voltage output
PCB
$17. Sparkfun
F). HH10D. : I2C
Breakout board
$10. Sparkfun.com
G). SHT11. : 2wire serial
$35 Adafruit.com
H) HT3-R1-A. Humidity/temp : Dallas 1wire
$58 Hobby-boards.com
3) combo sensors : barometer and temperature
A) BMP085 : I2C
Pressure sensing range: 300-1100 hPa (9000m to -500m above sea level)
Up to 0.03hPa / 0.25m resolution
-40 to +85°C operational range, +-2°C temperature accuracy
$20 Adafruit.com Sparkfun.com
B) MPL115A2. : I2C
Lower precision than BMP085
$12. Adafruit.com
C). MPL11-5A1. : SPI
$13. Sparkfun.com
D) B1-R1-A barometer only : Dallas 1wire
$60 hobby-boards.com
Summary : a range of different interfaces are available, most are
Local only (where module/sensor is co-located with interface ).
Dallas 1wire is proven to operate over long distances, maxdetect also
Claimed to allow 100m
There are no ADC options available for barometer.
selected options for BBP need to depend on
- core platform onboard support for one or more of noted interfaces
- BBP. support for arduino/PIC interfaces (sensors dont connect direct)
This will be important for distributed/remote sensors
notes
1) all above sensors have arduino library available
Library availability for other OS (eg Linux) needs research
2) RPi shields have not been listed
Disclaimer ; same as previous (see temp sensors)
Wow - to paraphrase the movie Jaws (http://m.youtube.com/watch?v=8gciFoEbOA8&desktop_uri=%2Fwatch%3Fv%3D8gciFoEbOA8) "You're gonna need a bigger acronym". How about VBBBP. For very big .....
Just to be clear - I'm not suggesting that it should support all of these modules
I wanted to show the range - and in particular show the range of different
INTERFACES
Eg ADC, i2c, SMB, SPI, 1wire
That they use ... Which presents the dilemma as to which "interfaces" to support in BBP
Hence my suggestion that we initially standardized on a minimal number of
Interfaces
In respect to the number of sensors connected - this shouldn't be too bad - if it's mainly a
Capture/log/graph/display function in BBP .. It should scale to some reasonable number
Eg database entry gets setup for each sensor and simply stores the data .... Then it can be
Called up to display accordingly
However - again I'm thinking a modular approach by using arduino or similar "sensing modules"
Is best
And have them report to BPP in a "common format" - thus reducing the load on BBP to
Do any low level sensor computations (do that in arduino) .... And reducing the number
Of physical interfaces BBP needs to support to
"Listen for arduino sensor reports"
Quite a comprehensive outline there. I for one am quite keen to have the option to integrate weather in some optional form into this thing, and i like your idea of scalable remote sensor satelite units.
In general, in my ideal world the central arm board, would interface with everything else via ethernet. The reasons are these:
- with switchs, scalable to 255 devices.
- robust
- high voltage isolation.
However its not an ideal world, and ethernet isnt exactly a low power means of communication. I recently measured a 5 port switch and found it used 0.6W idle, plus 0.6W per connected link. Its the rj45 isolation transformers im told.
Some inverters etc only have serial/usb/bluetooth. So we will clearly need to provide support for those. Most arm boards have a 4 pin serial header, which could be used to get reliable serial interface independent of the usb implementation on board. But how to cope with more than one? I know squat about that. Most baords also have one or more of gpio, i2c,spi. Can we have a daughter board of some kind with interfaces to the remote units?
In terms of the BB software its modular, you just add a module for each RE device, but i define module loosely, ie a module for each unique remote sensor unit, or online query, online publish, whatever.
I will start another thread on the project scope.
Yes agree Ethernet would be nice ... But for some installations where distances between
Various units (eg generator locate some distance away, likewise panels in a convenient ground location,
Water pumps at damn/well, storage tank .... You get the idea I'm sure)
To run Ethernet cabling presents some issues
- cost of cable
- cost and effort for conduit and or burial
- lightning!! (Ethernet cable is yet another way to bring lightning into the "control room" )
And presents more earthing and SPD issues potentially
but wifi presents an interesting alternate (yes there are self contained wifi compliant sensor modules out there ..)
Consider a fully self contained low PWR wireless sensor module for perhaps $25 + LiPo battery + small local solar cell With a distance of 100m Tx range
.. All up cost maybe $45 .... Now compare to cost of 100m cat5e, plus conduit plus burial effort!
.... Hmm I know Which way I'm going to go ! (Not lazy, just practical)
And the sensor module will NOT send the lightning back :) ... And when it does get fried, it's fast to
Replace (imagine digging up that 100m of cat5e when lightning fries it ... Somewhere along its length)
I'm working on my "dissertation" for this thread on wireless modules ... Just haven't got there yet
Quote from: Gregy on October 20, 2013, 02:58:03 AM
Consider a fully self contained low PWR wireless sensor module for perhaps $25 + LiPo battery + small local solar cell With a distance of 100m Tx range
.. All up cost maybe $45 .... Now compare to cost of 100m cat5e, plus conduit plus burial effort!
There's direct-burial cat5 cable. Saves on the conduit. Perhaps.
I chose to run an old WRT54GL, re-flashed with dd-wrt, as my ethernet connection to the battery room.
I had ethernet there already, but decided to use wireless:
1. I already had access point(s) available
2. I needed 4 devices, the WRT54GL already has a 5-port switch.
3. I wanted galvanic isolation and a bit of an air-break
Cost: picked up a bunch of them for about $15 each.
Oh, additional: the WRT54GL actually has two TTL RS232 serial ports onboard.
Using OpenWRT and a $3 converter from ebay, you've got a linux-capable device with ethernet, wifi, multiport switch and RS232 for almost nothing.
Measuring AC power/energy sources and loads in off grid setup
Module 3b (inverter source/load)
Module 5B (generator source)
Module 8b (AC loads)
****** What to measure and where ****
METHOD 1
Inverter data
Power/energy
- input from generator (any AC source)
- used by inverter for battery charging
- supplied to AC loads (output)
This data should be available from inverters I would expect, But that will be inverter specific, and dependant on capability
To access data from inverter
METHOD 2
Using qty 2 (or 3) separate power/energy sensors
1) Generator
AC energy/power (ouput) delivered
One Uni/directional energy/power sensing unit
Easy to locate at AC load/source panel (or generator output)
2) Inverter/charger
AC power/energy (input/output)
a) consumed by inverter specifically for battery charging
(eg when Using generator or other AC source)
b) Generated from batteries = supplied from inverter AC ouput to system (all AC loads)
this would be one bi-directional (power/energy) sensing unit
scenario 1
a) no generator or other AC power sources, only one sensor on 2) above required
b) separate inverter and charger, two sensors required (one each on inverter and charger)
Scenario 2
Use a additional sensor on generator output
Assumption is that by using subtraction, it's possible to determine Power/energy supplied from generator to :
a) battery charging
AND
b) AC connected loads
( some of the generator power flows to Both depending on respective demands)
Note : there are different methods for achieving the subtraction method Depending on where sensors sniff power
Scenario 3
Use three (or more) sensors and possibly avoid the subtraction method or cater for various combinations to Sniff all power flows
(Generator, inverter, charger, "all" AC loads)
3) power/energy consumed by individual AC. Loads
Additional Uni directional power/energy sensors as required for individual AC load circuits
(Eg heater, different sections/circuits of house, individual appliances)
******* how to measure ********
there are many of "Off shelf" systems for monitoring power/energy
All typically use a "non invasive" method to measure AC power with Current transformers "CT"
Measuring power and energy has a lot of complexities - that others have already "Solved".
.... So lets not reinvent the wheel here!
What we are seeking IMHO - is a way to get this data into BBP (Again my "modular sensing" thinking ) so we can Log/display/use as part of BBP decision making
So IMHO we use an available off shelf system that we can "capture" the data ..
Which brings me to
openenergymonitor.org. Project
Which is very impressive and has done a LOT of work on power/energy monitoring
Including work on Solar PV energy monitoring and control,
However it appears to be Focussed (to date) on
- monitoring grid tie PV systems with nett metering /feed in tarrifs
- using excess PV energy for local AC heating loads and decision making on when to use
Note however - with No local battery storeage the decision making process is quite different than our off grid scenario, and also the monitoring requirements for power flows differ considerably
Here are a couple of links that give a. Idea of how monitoring is being used
In grid tied PV systems
"Solar PV Monitoring System Application ....... For wireless web-connected solar PV monitoring system that monitors both generation and grid import/export"
http://openenergymonitor.org/emon/applications/solarpv
"A project to design and build a controller to route surplus P.V. energy into the domestic hot water supply"
http://openenergymonitor.org/emon/mk2
**********
Using Openenergymonitor.org. for module 3b 5b 8b Sensors for BBP off grid
1) emonTX v2 kit "sensing node"
http://openenergymonitor.org/emon/emontx
Apparent Power, Real Power*, Power Factor* and AC RMS voltage readings*
3 x CT Current Sensor input (measure power in 3 separate circuits)
Optimized for Low PWR operation, can be powered from 5V USB (or 3.3V)
Onboard low PWR Wireless transceiver
Up to 16 DS18B20 Dallas 1 wire temp sensors
Atmega328 "arduino" onboard (with its GPIO exposed)
Arduino sketch (program) "ready to go"
Only "downside" is that the units are supplied in kit form (ok for those
Of us comfortable with soldering)
EmonTX v2 kit £27. Plus CT £10ea. (CT source able elsewhere also for $12)
** Edit 21/10 **
emonTX V3 fully assembled version due any moment
Note it has onboard support for 3xCT + 1xCT (4 in total)
http://openenergymonitor.blogspot.com/2013/08/emontx-v3-progress-update.html
2) emonBASE. "Wireless base station transceiver"
Ethernet network interface
"Send data packets to a web server"
communication with emonTX nodes
Four different options available
"Nanode"kit £35 (bout again needs building)
"Nanode RF SMT" .£35 fully assembled from Nanode.eu (the developer)
Raspberry Pi plus RFM12 expansion board (more expensive than above options, Although more powerful, but claimed to be more difficult to setup)
3) emonGLCD. "Display unit"
LCD display of power, energy etc
Wireless transreceiver (receive data from nodes, transmit to base)
It appears the energy computation (integrating power over time to calc energy) Is done in this device? TBC
It also communicates with emonBASE to send temp to server, and get "time" from Internet To sync it's local clock
Very simple "add on" that gives an instant dIsplay!
£55 (kit)
Question/details as yet unclear (I am still researching)
1) is it possible to hardwire interface direct to emonTX sensor node and get data
Via serial interface (USB? I2C? SPI? Etc) into BBP
2) where is the energy calculation done? Possibly in emonBASE? or as I suspect in either or both emonGLCD and emonBASE
Summary: Whilst it's possible for us to "hang a CT of some ADC inputs" on BBP ...
There is a LOT of work behind the scenes to measure Instantaneous voltage, current, calculate power, integrate to get energy et al
So why not use an emonTX and emonBASE to do all the work - and let BBP capture and Log the data from the Ethernet interface on emonBASE
As the data is already in the "Ethernet domain" - shouldn't be too difficult To get the data into BBP (it's all open source !)
Wireless is an advantage (for adding more remote modules - another topic To come )
and separating BBP From inverters and other equipment
Zoneblue - I believe this answers the questions you posed to me
IMHO - we absolutely re-use the existing Openenergymonitor.org project,
It's very complementary to BBP with minimal overlap
(Note I haven't as yet searched their development threads to determine if there
Are off grid versions under development.. But as it exists now it can pretty much deliver All we need)
And my final caveat ... Of course if the inverter provides the data (as it should, But often may not)
then just stop reading at method 1 at top
Wow big post !
Thoughts?
edit history :
21/10 updated scenarios for split inverter charger, number power flow/CTs and cleaned up formatting etc
21/10 added link to forthcoming emonTX V3
Ross
Wrt54gl All good points - I will rethink further - I think I may even have one in my discarded
Items box
Agree that it provides lots of functionality and of course Ethernet connectivity.
But if it's wireless how do you power it remotely?
I'm thinking of a very low power wireless node with onboard GPDIO ADC - that needs
5V @40mA when transmitting - and way lower when it goes into sleepy mode
That can be powered from a. LiPo and charged with a smallish solar cell
The lipo can power it for days without charging ! And it can even report it's own battery state
Wirelessly
The wifi/Ethernet router gives much different and greater capability for sure.
But no wifi router is going to achieve the above power consumption where only limited
Connectivity is required - and can be delivered via small wireless module
we are comparing different requirements .. Apples and grapefruit :)
Measuring DC loads (DC current)
Module 8a
A selection of sensors/circuits available to sense DC loads (DC current flow)
1) DC current under very high voltage using non invasive current transformers
Uses a special CT and circuit to sense DC current with high voltage isolation
Could be used for measuring PV array current total (or from individual strings/arrays)
Discounted because of cost ($120 fixed core CT; $150 split core CT)
CC should provide enough details for Its high voltage (PV array) input
2) DC current shunt
Very low resistance ("shunt") generates a small voltage across it
(Ohms law applies - voltage generated is directly proportional to current flowing)
Eg 500Amp 50mV is common in solar PV battery installations
When current shunt is connected to battery negative it's termed "low side"
For low side shunts, measure voltage to ground across shunt (no common mode
Issue to deal with)
Low side seems to be the more common is solar PV Battery installations
Current can flow either direction (charge vs discharge) so voltage can swing +/- as measured referenced to ground across the shunt
note this referenced to ground, and not battery negative - which is not connected to ground directly, but is connected to ground via the shunt)
Voltages are very low and cannot be measured by ADC directly, but need
An amplifier
(Note a good quality DMM can accurately measure 0.1mV ranges, however
5A = 0.5mV which is quite a low voltage to measure)
A CC with a battery shunt monitor (eg midnite wizbang JR) does all the work
Summary: how to measure
A) for CC it's assumed BBP will be able to access (wizbang) shunt current flow
Data via modbus
B) inverters with current shunt measurement (eg battery monitor kits)
Should likewise enable access to this data
C) systems without access to current shunt data, it's possible to amplify
And measure shunt voltage (further details available )
3) DC loads
Hall effect devices allow monitoring DC (and AC) current "through" a special IC That is isolated from its ouput - which could be analog voltage of one of the Various serial interfaces
The DC current flows through the Hall effect chip (it's effectively in line with The circuit)
Various modules/breakout boards available ; below a selection I've found
Current shunts use a measurement resistor - below a selection of devices with "onboard" shunt,
But in some cases can be removed to use external shunt
A) various Hall effect sensors with ADC ouput
* ACS709. : 30A. ADC
Bi-directional current 30A "continuous " (but needs heat sinking)
70A (max short term transient)
Note the warnings about temperature and heat generation
2.1kv isolation
Output voltage proportional to current (can use ADC to read)
$10 Pololu.com
* ACS711EX. : ADC
100v isolation
bi/directional +/- 31A version
bi/directional +/- 15.5A version
Output voltage proportional to current (can use ADC to read)
$4 pololu.com
* ACS714.
G* ACS 715 0-30A (Uni directional) $10
D) attopilot DC Voltage and AC current sensor with analog output (ADC)
Three diff versions using inbuilt current shunt
50V/180A
50V/90
13.6V/45A
$20. Sparkfun.com
E). ACS712. 0-5A AC or DC current
With opamp for gain for improved accuracy
$10. Sparkfun.com
F) INA219 : I2C
High side DC Current and voltage shunt sensor 26V +/-3.2A
Inbuilt 0.1ohm shunt resistor (can be removed and replace with external shunt for Higher currents)
I2C interface
$10. Adafruit.comp
G) INA169. High side current shunt monitor. ADC
Onboard shunt resistor for 5A (for 5V ouput)
$10 Adafruit.com
Summary ; majority of DC current sensors provide analog ouput (suitable for ADC)
All above boards supported by arduino with respective sketch available
can also be read directly into ADC if available on BBP core platform
Many different options for various DC Currents (and voltages)
Disclaimer (see above posts)
In reply #10
Method 2
2) inverter
Scenario 2......
Assumption is that by using subtraction, it's possible to determine
Power/energy supplied from generator to :
a) inverter battery charging
AND
b) AC connected loads
There is also the variant where the Off Grid system has Inverter and Charger as separate units.
ADD #1
Using Openenergymonitor.org. Sensors for BBP off grid
in link from Openenergy I found this, the JEENODE
http://jeelabs.net/projects/cafe/wiki/
sold here: http://jeelabs.com/
Westbranch
Good point.
If I understand correctly,
In this scenario it also includes a generator? And the inverter and charger are separate units.
If so, then I think it needs the three sensor scenario? To measure all the respective power flows.
1) generator output
(current can flow into battery charger AND AC loads directly)
2) Battery charging input
(AC power used by charger to recharge batteries)
3) Inverter output
(Power supplied to AC loads from inverter using batteries)
Is my above assumptions correct?
Or can it still be done with two sensors and subtraction? (I need to make a diagram for myself)
yes, that is correct, Gen power, no grid, inverter separate from charger.
Inverter has an auto transfer switch, which shuts off output from the battery, note: there is still a tare load to measure, while the charger is supplying watts to the battery,
However there is also a setup that could also run as you described in point 3.
It is called Generator Support where both gen and Inverter jointly power loads based on parameters the operator sets . These are usually based on the Genny's max output. This feature is found in top end systems.
see this posting http://www.wind-sun.com/ForumVB/showthread.php?18459-Demonstration-of-Generator-Support
Ok - so is I think 3 sensor will cover majority of cases
I'm now speculating to myself about the "multi inverter" case
Eg with 2 inverters (quite common) tied together ... Is it possible to get
To appropriate point to measure combined AC power input/output (I'm assuming the AC dist panel)?
. I'm sure there are other very special
Cases that might need more, eg with more than 1 generator, or of course when a grid is introduced
the emonTX device has 3xCT capability in the v2 version so it can cover
All the popular scenarios with one unit
Of course it's possible to add additional units to expand ... So scales easily
I think we have the base cases covered with 3
Yes there are installations with 2 stacked inverters for 240V (in nominal 120V) systems.
Another option is where an Outback PSX-240 is used to supply 240V from a 120V supply.
http://www.altestore.com/store/Enclosures-Electrical-Safety/Miscellaneous-Electrical-Parts/Transformers/Outback-PSX-240-Autotransformer-with-Fan/p4089/
Yes agree that 3 should cover the bases, for instance, I have 2 generators which I use as needed
ie 3000W - Bulk charge, 1000W Absorb/Float charge
1 CT on the combined generator output could measure "generator" (one or other or combined?)
I assume you can't run them together. Unless you have a sync panel/system
Or maybe you have two different chargers ..... Ay oh my head is now spinning .. Stop
If BBP can allow for "up to 2x emonTX " boards (total 6 CT sensed power flows) that should be enough.
Most users will need only one, but we can allow for 2 for the more complex scenarios
(Also enables separate circuit monitoring of AC loads ... For the numerically obsessive amongst us :)
Agree?
Thanks for the NAWS link, I've been lurking over there and reading LOTS
I saw and read the write up you refer - which really helped my understanding and planning,
But also threw me various dilemma - which in due course I will ask for guidance in
Their newby forum
I will edit the reply #10 post above to reflect the above scenario changes
Greg
Yes, that number of sensors will likely be sufficient. No the gens will not be running at the same time. Manual start right now. Will have a selector switch to choose where power comes from.
In an Off Grid setting, redundancy is king, so that you have a way to keep going , if albeit at less than full capacity. My house wiring will be split into heavy and light loads , with a 6oow inverter powering the light loads, pun intended, as it will run, 24/7, all lighting and sat. internet related loads. The big boy will run fridge and other appliances associated with the cooks department... and it has a sleep mode.
This is my solution, using what I had and will be upgraded as needed.
Yes Chris is a very knowledgeable sort, with a unique setup. That post is a great resource.
PM me if you need some assistance, my PV experience has been a growing phase over the last 6 years.
westbranch
can you pls re-read the reply #10 and check my changes and logic per above discussions
ive tried to make scenario 2 a bit more generic; also cover the multi power flow cases in scenario 3 which is a bit more open ended now
emonTX V3
just found this update ... fantastic! - fully asssembled SMD version due soon
It has 3xCT + 1xCT (4 in total) - so this expands the power flow sensing capability
also has a "low pwr" option (with reduced functionality)
also a great reference schematic
http://openenergymonitor.blogspot.com/2013/08/emontx-v3-progress-update.html
so now a fully assembled version of the sensing node and the base are avail
i have updated reply #10 post accordingly
emonTH
a temperature and humidity remote sensing module... coming soon
http://openenergymonitor.blogspot.com/2013/06/emonth-prototype.html?view=magazine
ZB - its starting to look like your "ethernet" wish is becoming a reality .... and all using a single "emonBASE" ethernet gateway
with wireless RF for the remote nodes - at least that what its looking like to me ....
in a later blog 18/10 - he has measured prototype battery consumption (with sleep mode) ... and claims
battery life of 3+ years ! hmmm no solar charging or anything required for that remote node!
I retract my earlier supposition of overlap with openenergymonitor ... seems there could be overlap,
however that means less interfacing development for BBP - and more ethernet data available for it to ingest! .. a good thing
more ethernet "food for thought" to deliver ZB wish ..
https://shop.wickeddevice.com/product/nanode-gateway-no-radio
A Nanode gateway (no RF) with ethernet built in
100% open source sw
On chip web server allows remote control of I/O.
6 analogue sensor lines with 10 bit A-D converter.
Up to 14 digital I/O lines.
Serial Inter-Nanode Bus â€" allows Nanodes to be slaved together.
it does appear quite power hungry (definitely not for battery)
... and at $24 fully built ..... I can see it offering strong competition to other similar devices ....
Greg re #22 I think you have got a good description, it covers what I was thinking. :)
Greg, i just want to say the research you are doing on this is suburb and fantastic. I had the same initial response to openenergymonitor as you did, that it was bound too tightly to grid tie. However the whole open principle, to me, just begs that we find a way to cooperate with those guys. Maybe we can develop a new remote emon board that has specific support for dc measurements?
Do we need to make some kind of formal introduction to/with them?
Gees Greg, that looks like heaps of fun:
https://shop.wickeddevice.com/product/nanode-tutorial-complete-product-kit
Its almost enough to tempta guy to learn to code in 32K bites.
zb
if your ordeing the wicked starter kit, perhaps order one these also
https://shop.wickeddevice.com/product/assembled-low-power-sensor-and-transmitter-node
"simply add up to 4 sensors â€" analog or digital â€" just by soldering them onto the pads"
not a lot of details on it - im trying to find more info
... but for $20 you get a very low pwr remote sensor that can take 4 ADC
arduino and nanodes et al
zb quote "learn to code in 32k"
the neat thing about arduino and these environemnts - its already been done (by many) and all the
code is posted open source ... and tons tutorials and example "sketches" (programming code)
so scaling the devices for difffernet sensor inputs is "simply" a case of adding in more snippets
of code ( a GY over simplification)
even myself as a "non programmer" should be able to become familiar and adapt existing sketches
zb
thanks for the kind words - the research has been a interesting exercise .. there is a little more to
come but im nearing the end of completing each module ;
environmental sensors
wireless sensors ( i think you can guess where im headed on that)
BBP interfaces (in conjunction with our other posts on architecture and interfaces)
are the three final peices im working on
ref openenergymonitor.org
my thinking exactly - i had already been doing some reading in their forum to understand what correct
protocol may be for our intro, also ascertain interest and any activity that may already be working on
off-grid adaptations of emontx and emonbase (eg modified sketches)
my thoughts however to date
1) both hw modules are arduino - hence great for what they do, but limited onboard processing and memory cw BBP (they fit your architecture diagram as nodes for bbp to access)
hence my "complementary" comments ... partic if we limit BBP to not replicate what they are already doing very well - and simply use it for the very off grid and other module tasks ive outlined above
2) at present it looks like their focus is to send data up to the webbased server for processing and display (unclear exact "local" capability provided by emonbase ... but indications it can be
interogated locally via ethernet) more research underway
and of course they have that very neat local display!
... more to come ...
Quote from: Gregy on October 19, 2013, 02:30:01 AM
Started a new thread to let separate discussion
I've been thinking thru the automation aspects of RE system, given that I have existing HA - albeit
For more traditional aspects (no RE type inputs at present)
RE sensing/automation blocks
1) PV array
...
What/how to get from each block
general: most useful/important data can be accessed via CC via modbus BBP
- PV string voltage and current (given its DC, and very high voltage and current)
options here are expensive and limited. .. And aside from fault monitoring - possibly don't yield ROE/I
Summary : at present IMHO we "leave it up to the CC" to manage and report
- panel temp (very useful and important) via a simple temp sensor glued to rear? Of panels
(Suggest a few to be able to get an averaging across each array)
Need to support More than one array for those with multiples
Suggest we allow for n sensors per array and x arrays (pick some reasonable number for n and y)
...
We can use above list as a reference start point - and add to it as required
I sort of agree that a lot of useful data concerning the PV array can come from the CC.
Some thoughts on this:
- meaningful data is probably limited to when the CC is in BULK MPPT mode as in this mode the CC is extracting the maximum it can from
the PV array
- a larger capacity array that can exceed the CC current limits is more difficult for the CC to manage (and provide meaningful data) when the array is able to generate more power than the CC can handle.
- in ABSORB and FLOAT modes the CC limits current from array and is happy to waste excess power. In these modes the CC cannot provide an useful data on PV array capability.
The CC's primary function is to manage the charging of batteries and maximising battery life. It does not really care where the power input is coming from, PV, turbine etc.
Therefore making maximum use of the PV resource will need to detect when the CC is demanding maximum power from the array and when it is not.
The Classic can provide, via modbus register, info on which charging mode it is in and the current its taking from the PVs and the input voltage.
Some features of the Classic CC when dealing with a PV array
- in BULK MPPT the current will be maximum the array can provide OR the maximum current limit setting as defined by user. Voltage will be near the MPP voltage for the panel
- in ABSORB and FLOAT the current is limited but the array voltage will rise above the MPP voltage and may reach (almost) the PV open circuit voltage
- the MPPT tracking software in the Classic will, every so often, unload the PV array for up to 25 seconds (time based on obsrevations) for a deep scan or partially unload array for a quick scan. one effect of this is that the PV voltage will riae to PV OC voltage until the scanning is complete and the PV array is loaded again. Note - a side effect of this is that reports, eg in local app, will show max input V as the OCV for the array.
- The
interesting AUX2 PWM can be used to divert power to another device. However, as pointed out in previous threads the PWM diversion process starts at a defined voltage below the set point for ABSORB or FLOAT and direting to a large enough load could prevent these set points being reached. Some experimenting with load balancing is the way to go.
- The Classic input volts and amps meters are not 100% accurate but do give an approx indication of input values.
The
ideal power diversion should (IMHO) occur as cloase to the power source as possible.
WIth a PV array the power is diverted from the array of a section of the array WITHOUT using the CC to manage this diversion.
A BB application is ideal for this PV array diversion application.
The BB will probably need to give power priority to the CC so that the basic business of battery charging is completed.
Any diversion control (algorithmn) will need to take account of the CC's mppt loading and unloading of the array.
The BB must be able to appropiately unload the diversion load to allow the CC to resume battery charging as needed.
dgd
Quote from: Gregy on October 19, 2013, 02:30:01 AM
RE sensing/automation blocks
1) PV array
a) Fixed array
b) tracked Array
Not sure how these two PV array 'configs' would fit into BB logic.
I know RossW has done a lot of good stuff with tracked arrays and the graphs he posted some time ago do show some clear benefits to
array tracking.
Nevertheless I do get the feeling that with PV prices where they are, that tracking costs could soon, if not already, exceeed the costs of just installing more PVs.
No matter though, just my opinion, I'm sure the tracker vs bigger array debate may be pointless...
dgd
DGD
yep i think you have nailed it very well
my thinking was to use Module 7 (reproduced below) to be able to estimate the available power from production array
***********
7) solar radiation and insolation
(Other thread topic)
a) pyranometer
b) solar "test array"
c) simple solar (eg photodiode ambient light )
************
which makes me think my above description needs modification
this module is actually to "predict instantaneous available power from production array"
using one (or combo) of options a) b) c) for solar radiation/insolation to help it predict (note i may be incorrectly using the terms )
ANd then BBP provides a calculation (because it "knows everything" - thats why we need all info in one place.. aka BBP)
opportunity power available = predicted array total power - CC reported power usage
(details from CC regardless of its respective charging mode)
this calc can be instantaneous , averaged over some time period? or other?
and then presents (and perhaps enable control) the estimate of opportunity power avail
note it will also need to have a CC efficiency factor to subtract CC pwr losses also
notes: im making assumptions (for which i admit i dont have experience)
1) the CC can report its PV sourced instantaneous power consumption regardless of its present mode
2) its possible to "load up" the CC by switching in additional loads via one of 2 methods
DC loads/AC loads via inverter (note loading up PV panels at DC high voltage directly is a different case to also be meausred/ managed)
.. and do this by minimising disruption to battery charge state (which is kinda where we started this discussion:) .. in our quest to use opportunity power (for fixed loads - not PWM controllable "variable" loads) and not disrupt battery charging
Q: can the CC ramp up to supply more DC current for the additional DC loads and AC inverter loads, whilst maintaining current to battery and not disrupt its charging mode ?? (assuming the sum
of all loads on CC is within the predicted/actual available power to it from PV .. aka module 7)
my above assumptions need validation, otherwise the whole idea collapses ?
we parallel posted
yep again
module 1)
the ability to capture "power" data from fixed vs tracked array - opens up opportunity to measure
(and perhaps debate :)
and quantify the whole fixed vs tracked ... to compare the benefits , costs et al
it wasnt so much to give BBP logic .. in this case it was more just measurement (i think) coupled
with module 7
and yes i agree ... with falling PV panel prices, in many scenarios im sure the additional tracked costs
become a limiting factor (inc reliability issues) ... and of course for those in high wind loading locations, eg hurricane etc .... fixed is a no brainer
... but for space limited situations, tracking may be a necessity (not to open the debate here)
In bouncy moving taxi on way to airport. Will post more when I get somwhere comfortable and with a real keyboard!
DGD
im very much thinking out aloud ("TOA") here ....
your very relevant thoughts now drive us IMHO towards defining the BBP
- "decision modules"
- "output modules"
(my random terminology)
one we have Input sensor data (eg from sensing module structure)
this leads to the obvious "so what to do with it all"
so by defining what we want to do with it - then defines the output modules and hence then to the decision modules (and internal logic)
for example
we want output modules for:
- using opportunity "fixed" DC loads
- using opportunity "fixed" AC loads
- using opportunity PV loads (your preffered case : putting a fixed or variable load onto a PV array)
and then we define the algorithms for each in the "decision modules"
a diagram would help i know ... but Something like
sensor module/s data >>>> decision module (algorithms and logic) >>>> output modules
working backwards from a prioritised "what do we want" list, also
help prioritise input sensor modules
ZB - pls jump in here - as im not sure how you envisage and/or have
already established BBP sw structure
thoughts?
... and a heads up - my temporary excess time aberration has come to a sudden (as expected) halt,
at short notice im departing for a new country and new role today, and hence my prolific posting
will diminish ... pls stop cheering :)
at least all the information ive generated can now "soak for a while" whilst everyone digests it :)
ZB - not sure when i will get a chance to send the other text doc ... as im now IPAD only IT challenged
I originally made a code seperation between input modules and output modules, but changed my mind. For now. Mostly because monitoring is the task list priority.
But to my mind a code module relates to a discrete piece of hardware, (plus more amorphous things like reading or writing to other servers.) That disscrete 'device' may have either or both inputs and outputs.
However for your purposes of controlling say a generator or diversion load then a simple relay board off our coms bus, would qualify as a new peice of hardware, and hence a new code module.
Modules are all alike run regularly, so what they actually do is irrelevent from my point of view. So Im just calling them 'modules'.
As to what happens for logic that needs to consider data from multiple modules, im still pondering on that. Thus far im guessing some kind of hybrid datapoint . As an eg: the sum of all power inputs, from two say brands of charge controllers, plus one inverter/charger.