Currently the Network class contains too many methods (coroutines), which makes finding the right method for a certain task unnecessary cumbersome. Some methods also only make sense, if certain preconditions are true. For example, reading the acceleration range (read_acceleration_sensor_range_in_g) only makes sense for a sensor device, but not for an STU.
Implementation
One option might be to return different objects (that only provide certain functionality) via a context manager or method. These objects could then store a reference to a Network object as attribute that provides only basic functionality. For example, in the case of EEPROM access we could add a method that creates an EEPROM object, which then uses the Network object for sending and receiving the correct command.
Class Hierarchy
The class hierarchy could look something like this:
classDiagram
class Network {
-connect_sensor_device() : SensorNode
+connect_sth(identifier: [str, int, EUI])
+stu()
}
class Node {
+eeprom() : NodeEEPROM
+reset()
+get_name() : str
+set_name(name: str)
+get_state() : State
}
class SensorNode {
+eeprom() : SensorNodeEEPROM
}
class STU {
+eeprom() : STUEEPROM
}
class STH {
+eeprom() : STHEEPROM
}
class SMH {
+eeprom() : SMHEEPROM
}
Node <|-- SensorNode
Node <|-- STU
SensorNode <|-- STH
SensorNode <|-- SMH
NodeEEPROM <|-- SensorNodeEEPROM
NodeEEPROM <|-- STUEEPROM
SensorNodeEEPROM <|-- STHEEPROM
SensorNodeEEPROM <|-- SMHEEPROM
Examples
Manually Clean Up Network Resources
network = Network()
network.shutdown()
Writing STU EEPROM Data
from datetime import date
async with Network() as network:
stu = network.stu() # stu: `STU`
stu_eeprom = stu.eeprom() # stu_eeprom: `STUEEPROM`
stu_eeprom.write_production_date(date(year=2020, month=10, day=5))
Reading STH EEPROM Data
async with Network() as network:
# network: `Network`
async with network.connect_sensor_device("Test-STH") as sensor_device:
# sensor_device: `SensorDevice`
sth_eeprom = sensor_device.eeprom()
# sth_eeprom: `SensorNodeEEPROM`
slope = await sth_eeprom.read_x_axis_acceleration_slope()
Reading STH Streaming Data
async with Network() as network:
async with network.connect_sensor_device("Test-STH") as sth:
async with sth.open_stream() as stream:
async for data in stream:
pass
Open Questions
[ ] How to handle EEPROM of different sensor devices after connection?
connect_sensor_device does not know, if device is STH or SMH
Possible fixes:
Add attribute to call of connect_sensor_device (e.g. attribute device: stores class of returned object (SMH, STH)
Add method to connect to specific device (connect_sth, connect_smh)
Is it possible to differentiate SMH/STH before connection?
[ ] The class Node (mytoolit.can.node) already exists
Possible fixes:
Move current Node class to different namespace (e.g. mytoolit.can.identifier)
Use different name for current class (e.g. NodeIdentifier, NodeID)
Use different namespace for new node class
Use Device as name for new class
Disadvantages:
“Node” is already used/established as concept for specific hardware device
Derived classes also currently use name Node e.g. SensorNode (in tests)
[ ] How should we handle that only one STH connection is possible?
Description
Currently the
Network
class contains too many methods (coroutines), which makes finding the right method for a certain task unnecessary cumbersome. Some methods also only make sense, if certain preconditions are true. For example, reading the acceleration range (read_acceleration_sensor_range_in_g
) only makes sense for a sensor device, but not for an STU.Implementation
One option might be to return different objects (that only provide certain functionality) via a context manager or method. These objects could then store a reference to a
Network
object as attribute that provides only basic functionality. For example, in the case of EEPROM access we could add a method that creates an EEPROM object, which then uses theNetwork
object for sending and receiving the correct command.Class Hierarchy
The class hierarchy could look something like this:
Examples
Manually Clean Up Network Resources
Writing STU EEPROM Data
Reading STH EEPROM Data
Reading STH Streaming Data
Open Questions
connect_sensor_device
does not know, if device is STH or SMHconnect_sensor_device
(e.g. attributedevice
: stores class of returned object (SMH
,STH
)connect_sth
,connect_smh
)Node
(mytoolit.can.node
) already existsNode
class to different namespace (e.g.mytoolit.can.identifier
)NodeIdentifier
,NodeID
)Device
as name for new classNode
e.g.SensorNode
(in tests)