House Resource Management Software: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
m (Undo revision 228479 by Eric (talk))
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Basics=
{{Hint | Moved to https://github.com/gbroques/ecovillage-resource-management-spec}}
*Software to manage the resources of a house in a cyclical closed-loop system.
==Introduction==
*Sub-component of the [[Village Resource Management Software]].
Software to manage the resources of a house in a cyclical closed-loop system.
 
Sub-component of the [[Village Resource Management Software]].


=In Depth View=
House resources are defined as:
House resources are defined as:


Line 81: Line 82:
'''TODO:''' In reality, a house would likely have ''multiple'' sources for any one resource. For example, energy may come from solar, wind, and bio-gas digestion. The above diagrams don't account for this yet. Expand this to waterSources, foodSources, and energySources?
'''TODO:''' In reality, a house would likely have ''multiple'' sources for any one resource. For example, energy may come from solar, wind, and bio-gas digestion. The above diagrams don't account for this yet. Expand this to waterSources, foodSources, and energySources?


=Material Flows=
==I/O==
*A house can be defined in terms of I/O, or '''inputs''' and '''outputs'''.
A house can be defined in terms of I/O, or '''inputs''' and '''outputs'''.
 
===Inputs===
Inputs are unique to a geographic location or bio-region, and result in resource generation.
 
For example, in the mid-west of the United States, an input to a house may be '''rain-water'''.
 
The house would have a rain-water harvesting sub-component that adapts the '''input''' of rain-water to the '''resource''' of water.


==Inputs==
Other geographic locations may have different inputs that lead to water resource generation such as ground-water, salt-water, river-water, glacier-water, or spring-water -- and each water input would need a different sub-component to adapt it to a water resource ready for human consumption.
*Inputs are unique to a geographic location or bio-region, and result in resource generation.  For example, in the mid-west of the United States, an input to a house may be '''rain-water''' .  The house would have a rain-water harvesting sub-component that adapts the '''input''' of rain-water to the '''resource''' of water.  Other geographic locations may have different inputs that lead to water resource generation such as ground-water, salt-water, river-water, glacier-water, or spring-water -- and each water input would need a different sub-component to adapt it to a water resource ready for human consumption.
* '''Is this software for ONLY self sufficient homes, or does it integrate with the [[Village Resource Management Software]] as well?  Utilities in would use this, if not just rain etc?
*Possible Utilities:
**Potable/Drinking Water
**Electricity
**Fuel Gas (if plumbed)
**Internet
**Phone


==Outputs==
===Outputs===
TODO: Define outputs.
TODO: Define outputs.


Line 102: Line 102:
==Principles==
==Principles==
See [[Village Resource Management Software#Principles]].
See [[Village Resource Management Software#Principles]].
=
==In==
==Out==
*
=Internal Links=
*[[IOT]]
=External Links=
*

Latest revision as of 18:25, 25 July 2020


HintLightbulb.png Hint: Moved to https://github.com/gbroques/ecovillage-resource-management-spec

Introduction

Software to manage the resources of a house in a cyclical closed-loop system.

Sub-component of the Village Resource Management Software.

House resources are defined as:

  • Water
  • Food
  • Energy

Thus, a House, in the software can be thought of as a generic interface with the following methods:

  • getWater()
  • getFood()
  • getEnergy()

House-interface-plant-uml-diagram.png

Plant UML Source
@startuml
interface House {
  getWater()
  getFood()
  getEnergy()
}
@enduml

You may have several implementations of this generic House interface to meet the needs of people in different bio-regions.

For example, a mid-western house.

Mid-western-house-implementation-plant-uml-diagram.png

Plant UML Source
@startuml
interface House {
  getWater()
  getFood()
  getEnergy()
}

class MidWesternHouse implements House {
  getWater()
  getFood()
  getEnergy()
}

' Responsible for the collection, storage, and purification of rain-water
class RainWaterHarvester << (M,#FF7700) >> {
  getWater()
}


class AquaponicGreenHouse << (M,#FF7700) >> {
  getFood()
}


class SolarPanelArray << (M,#FF7700) >> {
  getEnery()
}

MidWesternHouse ..> RainWaterHarvester
MidWesternHouse ..-> AquaponicGreenHouse
MidWesternHouse ..> SolarPanelArray
@enduml

TODO: In reality, a house would likely have multiple sources for any one resource. For example, energy may come from solar, wind, and bio-gas digestion. The above diagrams don't account for this yet. Expand this to waterSources, foodSources, and energySources?

I/O

A house can be defined in terms of I/O, or inputs and outputs.

Inputs

Inputs are unique to a geographic location or bio-region, and result in resource generation.

For example, in the mid-west of the United States, an input to a house may be rain-water.

The house would have a rain-water harvesting sub-component that adapts the input of rain-water to the resource of water.

Other geographic locations may have different inputs that lead to water resource generation such as ground-water, salt-water, river-water, glacier-water, or spring-water -- and each water input would need a different sub-component to adapt it to a water resource ready for human consumption.

Outputs

TODO: Define outputs.

  • Human waste
  • are there others?

Principles

See Village Resource Management Software#Principles.