DMAC/internal/notes/weekly/Jan-16-20.md

# Jan 18
### Planning
**Monitoring Changes**

I want to refactor the reactor stuff to be less method oriented as far as data collection. For example, the monitoring stuff is all about events that happen pretty infrequently. It makes sense to then use a channel on the device side to just feed relevant status updates back to the reactor. I think that this makes the most sense because this will synchronize updates and leverage the rarity of events to cut down on errant calls.
- pros
    - less repitive method calls needed
    - less device locking
    - localize the information to different packages
- cons
    - extra memory for channels and duplicate storage info
        - could just remove status from dm?

**New Idea**

I can leverage wireguard to do server-> reactor  connections even beyond the testing phase

Changes:
1) move device coordinator into device package
2) expose relevant methods to reactor interface
3) clarify individual package responsibilities
4) add stuff server side to create/destroy grpc connections as the information is rendered client side
    - this might be scuffed but oh well

### Package Separation
**Reactor**
- coordinator
    - creates initial link to the server
    - creates database client
    - creates and starts a device coordinator

**Device**
- coordinator
    - searches i2c bus for connected devices
    - spins up managers to control the connected devices
    - relays information back up to the reactor coordinator
- manager
    - control over singular device
    - has the core information that will be needed across any type of device (name, status, address etc)
- sub-manager
    - fine grained struct with methods specific to the device

**Server**

Going to ignore for now because I am lazy
- central coordinator starts up database connection config etc
- reactor coordinator
    
### TODO
**Monitoring Changes**
- [] change methods to channel based
    - [] internal methods with spins
    - [] pass structs with interface for methods


# Jan 19

### Orginizational changes

What structure makes the most sense for the devices?

#### Top-Down

Ex) DeviceManager -> SensorManager -> DOManager -> Manager

**Pros**
- probably a less complex interface layout?


**Cons**
- annoying to keep/pass state
    - i.e. atlas needs the address to pass to the I2C but right now the devicemanager is storing that. Have to pass down via start which doesn't make a ton of sense

#### Bottom-Up

Ex) DOManager -> SensorManager -> DeviceManager -> Manager

**Pros**
- top level manager has access to common info
    - i.e. address, name etc
- can easily define common functions and use this to pass info upwards
- still don't have to import device manager as interfaces can handle getting/setting stuff

**Cons**
- might get ugly with interfaces
    - there might have to be a bunch of interfaces in the device package to handle nesting the manager itself
    - this might not be true though as the device coordinator dictates what interfaces are needed, and already it doesn't really use any of the dm functionality

**What would it look like?**
Device coordinator would call NewDeviceManager, 

### Outline of functionality

Hopefully by going over what is expected of each manager, it will become clear what the layout should look like

**Device Coordinator**
- responsibilities
    - starting/stopping device managers as devices connect/disconnect
    - maintaining a map of the devices and their status
    - updating the server with this information at set intervals
    - pass the I2C client to the device managers

**Device Manager**
- responsibilities
    - struct to store information that is used by any type of device
        - i.e. Address, Name, Config(prefix and file)? Status?
        - probably don't need status as this can be determined via IsActive()
        - config might be helpful to have, could pass up to managers via a Get function
    - start/stop as requested by the device coordinator
- serves
    - broad functions such as SetName(), GetName(), etc.

**Sensor/Controller Manager**
- responsibilities
    - provide corresponding broad struct that will be consistent across types of each
        - i.e. sensors all have sample rate
    - provide methods all will use such as TakeReading()
- serves
    - more specific functions such as GetSampleRate(), Set...

**Specific Managers**
- responsibilities
    - provides specific functions that a certain sensor/controller might need
        - i.e. pwm will need setFreq, DO might need a conversion etc.
    - broadly will need access to I2C for comms
- serves
    - Hyper Specific functions such as SetFreq() etc.

### Trying Bottom-Up

Right now, I am using some hybrid format which doesn't really make any sense. It goes

DeviceManager -> DOManager -> SensorManager -> Manager

This just feels *wrong*

**Changes**
- Going to use the specifc -> broad becaus it seems intiuitive
    - the most common methods/information is at the base and propogates up through the more specific managers
    - should make it simplier to define
- maybe go back to the unified package? Not quite clear what the purpose of seperate is beyond convience
    - although... the idea of the device manager as a reusable peice makes enough sense to potentially keep it as a seperate package
    - I'll stick with the seperate for now and keep it unless it becomes unworkable

### I2C Changes
The i2c bus is locked at the device level, so I am going to rewrite the bs to just use a function with no struct and remove the whole passing of structs garbage

#### For tomorrow
What I have now works, but it is still pretty backwards. Need further improvements and need to start thinking about what a websocket might look like in the current model