Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decrease Amount of Methods/Coroutines of Network Class #53

Open
3 tasks
sanssecours opened this issue Feb 22, 2024 · 0 comments
Open
3 tasks

Decrease Amount of Methods/Coroutines of Network Class #53

sanssecours opened this issue Feb 22, 2024 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@sanssecours
Copy link
Member

sanssecours commented Feb 22, 2024

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 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
Loading

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?
    • Is this even a problem?
@sanssecours sanssecours added this to the 2.0.0 milestone Feb 22, 2024
@sanssecours sanssecours mentioned this issue Feb 22, 2024
3 tasks
@sanssecours sanssecours added the enhancement New feature or request label Apr 9, 2024
@sanssecours sanssecours modified the milestones: 2.0.0, 3.0.0 Sep 12, 2024
sanssecours added a commit that referenced this issue Sep 30, 2024
For more information, please take a look at [issue #53][].

[issue 53]: #53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant