MeTIOT 0.1.0__tar.gz

metiot-0.1.0/.gitignore

@@ -0,0 +1,26 @@
+venv/
+**/build*/
+
+CMakeCache.txt
+CMakeFiles/
+cmake_install.cmake 
+install_manifest.txt
+
+*.o
+*.obj
+*.lo
+*.la
+*.d
+*.a
+*.so
+*.dylib
+*.dll
+*.pyd
+
+*.pyc
+*.pyo
+dist/
+*.egg-info/
+
+*~
+.vscode/

metiot-0.1.0/CMakeLists.txt

@@ -0,0 +1,18 @@
+cmake_minimum_required(VERSION 3.10)
+project(MeTIOTPythonLibrary LANGUAGES CXX)
+
+set(CMAKE_CXX_STANDARD 23)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+
+include(FetchContent)
+FetchContent_Declare(
+    pybind11
+    GIT_REPOSITORY https://github.com/pybind/pybind11.git
+    GIT_TAG        v3.0.1
+)
+FetchContent_MakeAvailable(pybind11)
+
+add_subdirectory(src/MeTIOTCommunication)
+
+add_subdirectory(src/python_bindings)

metiot-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Microelectronic Technologies
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

metiot-0.1.0/PKG-INFO

@@ -0,0 +1,53 @@
+Metadata-Version: 2.2
+Name: MeTIOT
+Version: 0.1.0
+Summary: Communication handling for all MeT IOT devices
+Author-Email: Cody Jackson <cjackson@micr.com.au>
+Requires-Python: >=3.8
+Description-Content-Type: text/markdown
+
+# MeT IOT Communication
+
+## Protocol Information
+
+Communication between MeT IOT devices and this library are conducted over TCP sockets. To see more in-depth details about this protocol including encryption standard see [Protocol Docs](docs/Protocol.md)
+
+## How To Use
+
+For all information on **how** to use go to [HowToUse Docs](docs/HowToUse.md). Also see examples of use in the [Examples folder](examples/)
+
+## How to Compile
+
+Linux based systems:
+
+1. Create and navigate into build directory
+```bash
+mkdir build
+cd build
+```
+2. Compile library using CMake
+```bash
+cmake ..
+cmake --build . --config Release
+```
+3. Export path to python
+```bash
+export PYTHONPATH=./src/python_bindings:$PYTHONPATH
+```
+4. Now you can use the library. If you first want to test it you can try
+```bash
+python3
+```
+```py
+import MeTIOT
+client = MeTIOT.DeviceClient("0.0.0.0", 12345)
+type(client)
+client.connect()
+```
+
+## How to Add More Features
+
+**WIP** docs
+
+
+

metiot-0.1.0/README.md

@@ -0,0 +1,45 @@
+# MeT IOT Communication
+
+## Protocol Information
+
+Communication between MeT IOT devices and this library are conducted over TCP sockets. To see more in-depth details about this protocol including encryption standard see [Protocol Docs](docs/Protocol.md)
+
+## How To Use
+
+For all information on **how** to use go to [HowToUse Docs](docs/HowToUse.md). Also see examples of use in the [Examples folder](examples/)
+
+## How to Compile
+
+Linux based systems:
+
+1. Create and navigate into build directory
+```bash
+mkdir build
+cd build
+```
+2. Compile library using CMake
+```bash
+cmake ..
+cmake --build . --config Release
+```
+3. Export path to python
+```bash
+export PYTHONPATH=./src/python_bindings:$PYTHONPATH
+```
+4. Now you can use the library. If you first want to test it you can try
+```bash
+python3
+```
+```py
+import MeTIOT
+client = MeTIOT.DeviceClient("0.0.0.0", 12345)
+type(client)
+client.connect()
+```
+
+## How to Add More Features
+
+**WIP** docs
+
+
+

metiot-0.1.0/docs/API_REFERENCE.md

@@ -0,0 +1,138 @@
+# API Reference
+
+The `MeTIOT` library provides a high-level interface for interacting with MeTIOT IoT devices via TCP. The core of the library is the `DeviceClient`, which manages the connection, event loops, and protocol handling.
+
+## 1. Client Library Components (`MeTIOT`)
+
+The `DeviceClient` class is the primary entry point for all device interactions.
+
+### Lifecycle Management
+
+#### `DeviceClient(ip: str, port: int)`
+
+*Constructor* | **Module:** `MeTIOT`
+
+Initializes the client object with the target device's network information.
+
+* **Arguments**
+    * `ip` (str): IPv4 address of the device.
+    * `port` (int): Communication port.
+* **Errors:** Raises `SocketError` if the IP address is invalid or unsupported.
+
+#### `connect()`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Establishes the TCP connection and performs initial handshake/device discovery.
+
+* **Errors:** Raises `SocketError` if the device is unreachable.
+
+#### `disconnect()`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Safely closes the active TCP connection.
+
+---
+
+### Protocol & Identity
+
+#### `get_protocol_handler()`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Returns the `ProtocolHandler` specific to the current device type. use this to encode/decode bytes.
+
+* **Returns:** `ProtocolHandler`
+
+> [!TIP]
+> Use this instead of the deprecated `get_specific_protocol_handler()`
+
+#### `get_unique_id()`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Retrieves the globally unique 64-bit ID assigned to the hardware.
+
+* **Returns:** 8-byte Device ID.
+
+#### `get_device_type()`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Identifies the model/type of the connected device.
+
+* **Returns:** `MeTIOT.DeviceType`
+
+---
+
+### Asynchronous Operations
+
+#### `assign_handlers(on_data, on_warning=None, on_fatal=None)`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Registers callback functions for the background listening thread.
+
+| Argument | Signature | Description |
+|-|-|-|
+| `on_data` | `(device, header, data)` | Triggered on successful packet reception. |
+| `on_warning` | `(device, msg)` | **Optional.** Triggered on non-fatal issues (e.g., CRC mismatch). |
+| `on_fatal` | `(device, msg)` | **Optional.** Triggered when the loop crashes or 10 warnings occur |
+
+#### `start_listening()`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Spawns a background thread to monitor the TCP socket. **Requires handlers to be assigned first.**
+
+* **Errors:** `LibraryError` if `assign_handlers` has not been called.
+
+#### `send_packet(packet: bytes)`
+
+*Method* | **Module:** `MeTIOT.DeviceClient`
+
+Sends a raw byte buffer to the device.
+
+* **Arguments:** `packet` (bytes): The encoded payload.
+* **Errors:** `SocketError` on transmission failure.
+
+
+> [!IMPORTANT]
+> **WIP** Document. Below text may not be correct.
+
+## 2. Protocol Handler Methods (Accessed via `client.get_protocol_handler()`)
+
+The methods available on the protocol handler instance depend entirely on the connected device type. The protocol handler also contains universal utility methods for packet handling.
+
+### 2.1 Universal Protocol Utility Methods
+
+| Method | Returns | Description |
+|-|-|-|
+| `deconstruct_packet(packet: bytes)` | `tuple[int, bytes]` | Decodes the packet buffer, validating CRC, performing COBS unstuffing, and returning the Data Header and raw Data Payload. |
+| `interpret_data(data_payload: bytes)` | `dict` | Interprets the raw Data Payload into a key-value dictionary using known Sub-Headers and Data Types. Keys match the Data Field purpose (e.g., "Temperature_C"). |
+| `fetch_last_packet()` | `bytes` | Returns the raw byte buffer of the last packet successfully created by this protocol handler instance. Useful for re-sending after a `MalformedPacketNotification`. |
+
+### 2.2 Fish Tank Protocol Methods (`Device ID: 0xFF`)
+
+These methods are available if the device type is "Fish Tank"
+
+| Method | Returns | Purpose | Arguments |
+|-|-|-|-|
+
+## 3. Protocol Constants (`MeTIOT.ProtocolConstants`)
+
+These constants are integers representing the 1-byte Header/Sub-Header codes used in the communication. All constants mentioned here are the exposed constants. In other documentation the codes here are referenced as *Device-to-Library Codes*.
+
+### 3.1 Standard Data Header Codes
+
+| Constant Name | Value | Description |
+|:---|:---|:---|
+| `MalformedPacketNotification` | `0xFF` | Notification for a corrupted/unparsable packet. |
+| `DeviceIdentifier` | `0xFE` | Response from the device containing the Device ID and Unique ID. |
+| `DataTransfer` | `0xFD` | Unsolicited data/status update from the device. |
+
+### 3.2 Fish Tank Data Header Codes
+
+| Constant Name | Value | Description |
+|-|-|-|

metiot-0.1.0/docs/DEVICE_PROTOCOL_DEV_GUIDE.md

@@ -0,0 +1,23 @@
+# Device Protocol
+
+## Current Device Protocol Implementation
+
+**Challenge:** Our `DeviceClient` class's `protocolHandler` is of the type `std::unique_ptr<AbstractProtocol>` which stops us from calling device protocol specific functions (e.g., function to create a calibration packet with specific parameters.)
+
+**Solution:** Ideally the python programmer using this library simply calls the same function to get all of their device specific commands regardless of the device type. The solution to this issue is during the python function call `get_specific_protocol_handler` we automatically resolve exactly what protocol data type we are using (stored in `deviceType` for simplicity) then we dynamically cast the `std::unique_ptr<AbstractProtocol>` type into what ever the device protocol actually is.
+
+## Creating New Device Protocols
+
+> [!NOTE]
+> The above information in `Current Device Protocol Implementation` is important to read to understand *why* you are doing the following
+
+When creating a new device protocol (to support device specific protocol commands) following these steps should lead to success:
+
+1. Add protocol .hpp file to `include/protocol/` and .cpp file to `src/protocol/`.
+2. Create a class inheriting `AbstractProtocol` (This gives access to required functions like `constructPacket`).
+3. Copy a similar workflow to other reference protocols. Function called -> Create data field -> Call constructPacket() -> return packet.
+4. Add your new device type to `enum class DeviceType` in `include/client.hpp`.
+5. Modify the device identification function in `src/client.cpp` to support your new protocol.
+6. Modify `/src/python_bindings/bindings.cpp` to support your new protocol. You need to add support for protocol specific functions as well as support for dynamically casting the `AbstractProtocol` pointer to your Protocol pointer.
+
+> If you want to add more OUTGOING fields or any protocol related header/subheader names add them to `include/protocol/protocol_constants.hpp`.

metiot-0.1.0/docs/PYTHON_LIB_GUIDE.md

@@ -0,0 +1,125 @@
+# Guide - How To Use the Library
+
+This guide provides practical steps for using the MeT IoT Python client library. For details on the underlying packet structure, see [TCP_PROTOCOL_SPEC.md](TCP_PROTOCOL_SPEC.md).
+
+## Installation
+
+The MeT IoT library is *soon to be* available on PyPI.
+
+```bash
+pip install x
+```
+
+## Device Discovery
+
+MeT IoT devices broadcast their presence using Zeroconf (mDNS). The library includes a function to listen for and find available devices on your local network.
+
+1. **WIP**
+
+## Connecting to a Device
+
+Establish a persistent TCP connection and perform the initial device identification handshake.
+
+1. **Create Client:** Create a client with the device's IP & Port.
+    ```py
+    import MeTIOT
+
+    client = MeTIOT.DeviceClient("192.168.1.100", 12345)
+    ```
+2. **Connect:** Use the `connect()` method to connect to the device.
+    ```py
+    client.connect()
+    ```
+    **Behind the Scenes:** After connecting to the TCP socket, the client sends a Device Identification Request and waits for the Device Identifier response. This identifies the device type and its unique ID.
+
+3. **Device Protocol:** For sending and interpreting message you will need a protocol handler.
+    ```py
+    protocol = client.get_protocol_handler()
+    ```
+    **Behind the Scenes:** After the connection has happened and the device type is identified that devices unique protocol class will be assigned to the client. This protocol class comes with its own unique methods. You can find all unique device protocol methods in the [API Reference](API_REFERENCE.md).
+
+## Receiving Data
+
+This library uses a dedicated thread to listen for unsolicited data transfers from the device. You should register callback functions to handle incoming data updates.
+
+> [!NOTE]
+> **Prerequisite:** You must first follow [Connecting to a Device](#connecting-to-a-device) creating a client, connecting, **and** fetching the device protocol.
+
+1. **Define Async Callbacks:** Create function to process incoming data object, warning messages, and fatal errors. You will likely have different data processing function for each device type you expect to handle.
+    ```py
+    def my_update_handler(device, header, data):
+        print(f"Received message from {device.get_unique_id()} with header: {header}")
+
+        match header:
+            case MeTIOT.Incoming.General.Data:
+                # Use the protocol handler to interpret the raw bytes into a dictionary
+                deviceProtocol = device.get_protocol_handler()
+                telemetry = deviceProtocol.interpret_data(data)
+                print(f"Temperature: {telemetry['Temperature_C']} C")
+
+            case MeTIOT.Incoming.MalformedPacketNotification:
+                print("Device reported a communication error.")
+                # Since the library is stateless, you must track your last
+                # sent packet locally if you wish to re-send it (Recommended).
+
+            # Example of modular expansion for specific devices
+            # case MeTIOT.Incoming.FishTank.SpecificAlert:
+            #     print("Fish tank alert!")
+
+            case _:
+                # Handle other commands defined in the API Reference
+                pass
+
+    def warning_handler(device, msg):
+        # This function is optional
+        #
+        # When this function is called the warning handling is already handled by the library. This function is just for debugging.
+        print(f"Device {device.get_unique_id()} has non-fatal warning: {msg}")
+
+    def error_handler(device, msg):
+        # This function is optional
+        #
+        # When this function is called a fatal error has occured and the listening loop has stopped. The device will no longer listen for messages.
+        print(f"Device {device.get_unique_id()} has fatal error: {msg}")
+    ```
+
+2. **Register the Handler/s:** Attach the handler/s to the client instance.
+    ```py
+    # --- To assign all devices the same handler ---
+    client.assign_handlers(on_data=my_update_handler, on_warning=warning_handler, on_fatal=error_handler)
+    # If you do not want to specify an on_warning or on_fatal handler they can both be removed
+    # client.assign_handlers(on_data=my_update_handler)
+
+    #   OR
+    # --- To assign different devices types unique handlers ---
+    #
+    # devType = client.get_device_type() # Fetch the current device type
+    #
+    # if (devType == MeTIOT.DeviceType.FISH_TANK):
+    #     client.assign_handlers(on_data=fish_tank_update_handler, on_warning=warning_handler, on_fatal=error_handler)
+    # elif (devType == MeTIOT.DeviceType.UNKNOWN):
+    #     print("Unknown device type. Assigning generic handler")
+    #     client.assign_handlers(on_data=generic_update_handler, on_warning=warning_handler, on_fatal=error_handler)
+    ```
+    **Behind the Scenes:** The client initiates a background listener thread to monitor the socket. When a message is detected, the library automatically handles the decoding and verification (CRC/COBS). It segregated the payload into its `header` and `data` components and dispatches them directly to your handler.
+
+## Sending Commands
+
+To send a command (like changing a setting), use the client objects protocol handler for high-level command methods.
+
+> [!NOTE]
+> **Prerequisite:** You must first follow [Connecting to a Device](#connecting-to-a-device) creating a client, connecting, **and** fetching the device protocol.
+
+1. **Create Packet:** Use the device-specific methods on the `protocol` object to generate the complete, ready-to-send packet buffer.
+    ```py
+    # Example for sending a calibration command to a Fish Tank device
+    # The protocol method generates the Data Payload + Header + CRC + COBS.
+    packet = protocol.create_fish_tank_calibration()
+    ```
+
+2. **Send Packet:** Supply that packet buffer to the client's send function.
+    ```py
+    client.send_packet(packet)
+    print("Calibration request packet sent.")
+    ```
+    **Behind the Scenes:** The protocol handler wraps your command with mandatory overhead (CRC and COBS encoding), ensuring the device can validate the integrity of the message upon receipt.

metiot-0.1.0/docs/TCP_PROTOCOL_SPEC.md

@@ -0,0 +1,182 @@
+# TCP Communication Protocol Specification
+
+> [!NOTE]
+> This documentation details the technical specifications of the protocol used for all TCP communication. **It is not required** to be read or understood for general use of the associated Python library. For usage instructions, please refer to the [How To Use](HowToUse.md) documentation.
+
+## Protocol Scope and Usage
+
+This protocol governs all TCP communication between MeT IoT devices and external clients (e.g., standalone library, Home Assistant integration).
+
+## Connection Initilization Sequence
+
+This sequence desribes the steps a MeT IoT device and the client library take to establish and identify a connection.
+
+### Initialization Sequence
+
+1. **Discovery:** The device broadcasts a Zeroconf (mDNS) packet for initial discovery.
+2. **Connection:** The client library connects to the device's TCP socket.
+3. **Request:** The client library sends a **Device Identification Request** command.
+4. **Response:** The device responds with a **Device Identifier** response packet.
+5. **Operation:** Regular data exchange begins.
+
+### Device Identifier Response Packet
+
+This specific packet is sent by the IoT device to the library during connection initialization.
+
+![Device Identifier Response](images/DeviceIdentifierResponse.jpg)
+
+The Data Payload (within a Data Header `0xFE` packet) contains the following information:
+
+* **8-Bit Device ID:** Specifies the type of device (e.g., Fish Tank).
+* **64-Bit Unique Device ID:** A unique identifier for the specific device instance.
+
+## General Packet Format
+
+All data over the TCP connection adheres to a common structure.
+
+![Packet Diagram](images/Packet.jpg)
+
+### Packet Structure Breakdown
+
+| Field | Bytes | Description |
+|-|-|-|
+| COBS Header | 1 | Marks the start of the packet and contains information for COBS decoding. |
+| CRC | 2 | 16-bit Cyclic Redundancy Check for error detection across the entire data payload. |
+| Data Header | 1 | Identifies the overall purpose or type of the packet (e.g., data transfer, identification). |
+| Data Payload | 0-n | The main data content. Its exact structure depends on the Data Header. |
+| COBS Trailer | 1 | Marks the end of the packet, always the value `0x00`. |
+
+### Purpose of Protocol Components
+
+* **Consistent Overhead Byte Stuffing (COBS):** Ensures reliable packet delimitation by guaranteeing the packet trailer byte (`0x00`) never appears in the body of the packet. The header contains essential information for the receiver on how to decode the data.
+* **Cyclic Redundancy Check (CRC):** A 16-bit code used for robust error detection. If the received CRC does not match the CRC recalculated from the Data Header and Payload, the packet is discarded as corrupted. The CRC algorithm is based on: G.D. Nguyen, “Fast CRCs,” IEEE Transactions on Computers, vol. 58, no. 10, pp. 1321-1331, Oct. 2009.
+
+## Data Header Commands and Flow
+
+> [!NOTE]
+> All relevant **Bytes** columns in tables **do not include protocol overhead** and only include the length of the header + data. The protocol overhead specifically refers to COBS trailer, COBS deliminator, and 16-Bit CRC which make up for a total of **4 bytes not included in those values**.
+
+The Data Header (1 byte) is the first piece of information after the CRC and determines the primary function of the packet.
+
+### Standard Library-to-Device Commands
+
+These are requests or notifications sent from the client library to the MeT IoT device.
+
+| Purpose | Data Header | Data Payload | Bytes |
+|-|-|-|-|
+| Malformed Packet Notification | `0xFF` | (None) | 1 |
+| Device Identification Request | `0xFE` | (None) | 1 |
+
+### Standard Device-to-Library Commands
+
+These are responses or unsolicited notifications sent from the MeT IoT device to the client library.
+
+| Purpose | Data Header | Data Payload | Bytes |
+|-|-|-|-|
+| Malformed Packet Notification | `0xFF` | (None) | 1 |
+| Device Identifier | `0xFE` | [1 byte Device ID + 8 byte Unique Device ID](#device-identifier-response-packet). | 10 |
+| Data Transfer | `0xFD` | [Variable-length structure.](#data-field-format) | n |
+
+### Device Identification Codes
+
+This 1-byte code is carried in the **Device Identifier** packet (`0xFE`).
+
+| Code (1 Byte) | Device Type |
+|-|-|
+| `0xFF` | Fish Tank |
+| ... | *(Future devices)* |
+
+## Data Payload Structure (Header 0xFD)
+
+When the **Data Header** is `0xFD` (Data Transfer), the **Data Payload** is structured as a series of repeating **Sub-Header** and **Data** fields.
+
+### Data Field Format
+
+![Device Data Field Diagram](images/DeviceData.jpg)
+
+The Data Payload consists of one or more data points, each preceded by its own Sub-Header. This pattern repeats until the payload ends: `Sub-Header`, `Data`, `Sub-Header`, `Data`, ...
+
+| Field | Purpose |
+|-|-|
+| Data Sub-Header | Identifies the specific data point (e.g., "Current Temp"). |
+| Data | The actual data value, interpreted based on the Sub-Header. |
+
+### Supported Data Types
+
+> [!IMPORTANT]
+> The following standard C/C++ data types are supported for transmission within the **Data** field:
+>
+> * `int8_t`
+> * `int16_t`
+> * `int32_t`
+> * `int64_t`
+> 
+> *All unsigned variants of the above data types are allowed*
+>
+> The following data types *can* be used but research must first be conducted to ensure each devices architecture support the same byte length.
+>
+> * `float`
+> * `double`
+
+## Device-Specific Protocol: Fish Tank
+
+This section details the custom commands and data formats specific to the Fish Tank device (`Device ID: 0xFF`). The Fish Tank protocol still inherits all commands defined in [Data Header Commands and Flow](#data-header-commands-and-flow).
+
+### Fish Tank: Library-to-Device Commands
+
+| Purpose | Data Header | Data Payload | Bytes |
+|-|-|-|-|
+| Sensor Attribute Request | `0xFC` | None | 1 |
+| Calibration Values | `0xFB` | *To be decided* | |
+
+### Fish Tank: Device-to-Library Commands
+
+| Purpose | Data Header | Data Payload | Bytes |
+|-|-|-|-|
+| Sensor Attribute Response | `0xFC` | *To be decided* | |
+| Calibration Finished | `0xFB` | 1-Byte Sensor Address | 2 | 
+
+### Fish Tank: Data Sub-Header
+
+> [!NOTE]
+> Values marked with *(decimal value)* are multiplied by 100 before transmission then divided by 100 when being interpreted. This only gives an accuracy of up to 2 decimal places.
+
+| Sub-Header | Data Field | Data Type |
+|-|-|-|
+| `0xFF` | Temperature *(decimal value)* | `int16_t` |
+| `0xFE` | Humidity *(decimal value)* | `uint16_t` |
+| `0xFD` | pH *(decimal value)* | `uint16_t` |
+| `0xFC` | Oxidation-Reduction Potential | `int16_t` | 
+| `0xFB` | Dissolved Oxygen | `int16_t` |
+| `0xFA` | Conductivity | `int16_t` |
+| `0x00` | Data End | (None/Blank) |
+
+### Fish Tank: Sensor Attribute Aquisition
+
+During the devices startup it allocates a unique I2C address and stores the device type for all devices on the I2C bus. For later use (like calibration) we will need to store this information so we know what types of devices are currently associated with the device.
+
+#### Sensor Attribute Response Command
+
+I2C Address:Device Type pair can repeat as many times as required.
+
+![Fish Tank Sensor Attribute Response](images/FishTankSensorAttributeResponse.jpg)
+
+#### Sensor Device Types
+
+> [!NOTE]
+> A Fish Tank device can have multiple of the same type of device so its important to sort by their I2C address not.
+
+| Code | Device Type |
+|-|-|
+| `0xFF` | Temeprature Sensor |
+| `0xFE` | Humidity Sensor |
+| `0xFD` | pH Sensor |
+| `0xFC` | Oxidation-Reduction Potential Sensor |
+| `0xFB` | Dissolved Oxygen Sensor |
+| `0xFA` | Conductivity Sensor |
+
+### Fish Tank: Calibration
+
+#### Calibration Values Command
+
+#### Calibration Finished Command

metiot-0.1.0/pyproject.toml

@@ -0,0 +1,16 @@
+[build-system]
+requires = ["scikit-build-core", "pybind11"]
+build-backend = "scikit_build_core.build"
+
+[project]
+name = "MeTIOT"
+version = "0.1.0"
+authors = [
+    { name="Cody Jackson", email="cjackson@micr.com.au" }
+]
+description = "Communication handling for all MeT IOT devices"
+readme = "README.md"
+requires-python = ">=3.8"
+
+[tool.scikit-build]
+cmake.version = ">=3.15"