From 42332990ed74c36066b7ed523498b22f9fca3ba2 Mon Sep 17 00:00:00 2001
From: KeeganForelight <keegan@arch.com>
Date: Thu, 19 Jan 2023 10:53:03 -0500
Subject: [PATCH] notes

---
 internal/notes/index.md            |  2 +-
 internal/notes/weekly/Jan-16-20.md | 25 +++++++++++++++++++++++--
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/internal/notes/index.md b/internal/notes/index.md
index 2825a11..09c9d5b 100644
--- a/internal/notes/index.md
+++ b/internal/notes/index.md
@@ -1,3 +1,3 @@
-## Daily Updates
+## Weekly Planning
 
 [Jan 16-20](weekly/Jan-16-20.md)
diff --git a/internal/notes/weekly/Jan-16-20.md b/internal/notes/weekly/Jan-16-20.md
index 66f4437..7774293 100644
--- a/internal/notes/weekly/Jan-16-20.md
+++ b/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