refactor environmental state storage method

[jakerye]

Current code served its purpose to get software off the ground but it is time for a refactor.

Considerations

1. code is difficult to understand
2. saving entire state every 10 minutes is not memory efficient -- just save deltas -- can generate timeseries data in view function for charts
3. abstraction to average all sensor variables of same type is overly simplistic -- should be more explicit about location and sensor type

Expansion on point 3

• by location: e.g. air temperature top != air temperature bottom -- should there be coordinates?
• when will we ever have multiple air temperature sensors at the same location outside of a test environment? (no -- hack for testing 2 sensors at same position can be just to set them at diff locations)

[jakerye]

• will likely want a coordinate system when we get to tracking individual cultivars (e.g. cultivar sites)
• how to structure coordinate system (center is at center of the light? bottom left corner of cultivation area? what about a reservoir?)
  • this breaks down quickly.....maybe orient around volumes?....sensor at a specific point but sensing a volume? how does this work for air, light, water reservoir, or soil?
  • what if doing SWC and the raft is moving up and down?
  • what if light can move up and down?
  • is there a simple / flexible framework for speaking intelligently and accurately about this?

[jakerye]

• differentiate between sensing point / sensing region -- sensing point is the 6DOF coordinate of the sensor -- sensing region is the 9DOF volume
  • multiple sensor types can share the same region
  • regions should be averaged
  • regions can have sub-regions (e.g. foliage region can be divided into halves (top/bot, left/right), octants, etc.)
  • perhaps regions are keyed? and can have parent regions?

[jakerye]

exploring method in cultivation-zone branch

[jakerye]

this is workable for now...until more pressing use case comes along the current solution is fine