notes
KeeganForelight
2 years ago
parent
9b2c956635
commit
39b7b491a5
@ -1,59 +0,0 @@
|
||||
### 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
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
## Daily Updates
|
||||
|
||||
[1-18](daily/1-18-23.md)
|
||||
[Jan 16-20](weekly/Jan-16-20.md)
|
||||
|
||||
@ -0,0 +1,122 @@
|
||||
## 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
|
||||
|
||||
### 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
|
||||
|
||||
**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.
|
||||
- serves
|
||||
- Hyper Specific functions such as SetFreq() etc.
|
||||
Loading…
Reference in New Issue