notes

internal/notes/index.md

@@ -1,3 +1,3 @@
-## Daily Updates
+## Weekly Planning
 
 [Jan 16-20](weekly/Jan-16-20.md)

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

@@ -1,4 +1,4 @@
-## Jan 18
+# Jan 18
 ### Planning
 **Monitoring Changes**
 
@@ -53,7 +53,7 @@ Going to ignore for now because I am lazy
     - [] pass structs with interface for methods
 
 
-## Jan 19
+# Jan 19
 
 ### Orginizational changes
 
@@ -86,6 +86,9 @@ Ex) DOManager -> SensorManager -> DeviceManager -> Manager
     - 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
@@ -95,6 +98,7 @@ Hopefully by going over what is expected of each manager, it will become clear w
     - 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
@@ -118,5 +122,22 @@ Hopefully by going over what is expected of each manager, it will become clear w
 - 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