diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/gen/style.css | 2 | ||||
| -rw-r--r-- | docs/pva.md | 45 | ||||
| -rw-r--r-- | docs/pve.md | 34 |
3 files changed, 77 insertions, 4 deletions
diff --git a/docs/gen/style.css b/docs/gen/style.css index f94cf0e..43012db 100644 --- a/docs/gen/style.css +++ b/docs/gen/style.css @@ -26,7 +26,7 @@ text-align: center; } - figcaption { + figcaption, p { text-align: justify; text-justify: auto; } diff --git a/docs/pva.md b/docs/pva.md index ab9d0d4..7137fb0 100644 --- a/docs/pva.md +++ b/docs/pva.md @@ -1,10 +1,14 @@ # Backgrounds -## Organization - ## Project -## Parties +The concept of mesh structure already existed at the beginning of the turn of the millennium. The first step in this is internet standard 802.15.4. This includes both the physical layer and the mac layer. + +The protocols evolved in the years that followed. 6LowPan, Zigbee and other implementations were the results. Zigbee has evolved and Thread/OpenThread has been added with major companies supporting it. + +Zigbee has been on the market for some time, being used in products such as the Philips HUE and IKEA's Trådfri. The number of products made with OpenThread is more limited. BT mesh applications are still mostly in development. + +In the project we use a mesh network to realize a home automation system. # Project result In year 2 of avans hogeschool blok 2 is the project is domitica. With this project we are going to realise a domotica system using bluetooth mesh. @@ -42,20 +46,55 @@ In this Sprint were finishing the domitca system if finishing is needed. Most of ## Quality of product +- The mesh network once established is stable, and packets can be sent and received reliably (>95% of the time). +- Actions within the network should be propagated after less than 500ms. + ## Quality of documentation +- Source code usage is documented using doxygen-style comments in the header files, describing usage, call signature and optionally edge cases, example usage and/or other details. +- Obscure or ambiguous syntax usage is explained using line comments in source files. +- General software architecture will be documented in following design documents. +- Design documents will be proofread by peers to verify if the explanation is comprehensible. + # Confidentiality This project is MIT licensed. # Project organization ## Organization +This project has three main roles: developer, integrator and scrummaster. In the following section, a fourth role "Project owner" is also included for completeness. Because the project owner is not involved during project development, "all" roles in the following sections refers to only the main three. + ## Roles and personal details +| Name | Role | +| ------ | ----------------------------------- | +| Joan | Project owner | +| Joshua | Developer | +| Loek | Integrator, scrummaster & developer | +| Niels | Developer | + ## Information +While the roles in the table above describe a hierarchial system, all planning and architecture decisions are made democratically. + +### Developer +- Research (during sprint 1) +- Implement user stories in code +- Send pull requests to integrators + +### Integrator +- Merge pull requests +- Version tagging +- Verification + +### Scrummaster +- Track and manage project progress +- Create user stories + # Schedule +As mentioned before, we're using Trello for managing a scrum-based planning. The user stories are scheduled a week before the sprint assessment by default. For a detailed up-to-date version of the schedule, see [Trello](link missing). + # Project boundaries The project has a few bounderies. The minimal requirements is that is works with three switches and three lights. Therefore using our domitica system for relaying numeric values is not possible, for now atleast. additionally, it is an domotica system which means it cannot be used in a industrial environment. And the last bounderie, Is the system needs to use our GUI and does not work with other GUI. # Cost-benefit diff --git a/docs/pve.md b/docs/pve.md index d9d2600..127f7bf 100644 --- a/docs/pve.md +++ b/docs/pve.md @@ -1,9 +1,43 @@ # Introduction +node = one node that contains both a button and a LED +SE = self explanatory # Goal # Requirements ## Functional requirements +| ID | Name | Description | MoCoW | +| --- | ----------------------------- | ------------------------------------------------- | ----- | +| 01 | 3 Nodes | Have atleast 3 or more nodes in the network | Must | +| 02 | Button and LED | Each node has 1 button and 1 LED | Must | +| 09 | Nodes are mesh network | SE | Must | +| 10 | Client connection | Client is connected to both the mesh and internet | Must | +| 13 | Node sensor/actuator | A node contains atleast one sensor or actuator | Must | +| 14 | Node send/receive other nodes | SE | Must | + ## Technical requirements +| ID | Name | Description | MoCoW | +| --- | ------------------------------- | --------------------------------------------------------------------- | ----- | +| 03 | Controlling mulitple nodes | One or more buttons can control one or more LEDs | Must | +| 04 | Simulate node | The application can at least simulate 1 button and 1 LED | Must | +| 05 | Virtual node | The simulated node can interect and be interacted with physical nodes | Must | +| 06 | Dynamic node (un)registration | Nodes can dynamically be registered during runtime | Could | +| 07 | Nodes can register other nodes | Nodes can be provisioned by other nodes | Could | +| 08 | Smart interface node and client | Wireless conection over BLE or J-link | Could | +| 11 | Monitor and control | Client can monitor and control mesh network | Must | +| 12 | Groups | Nodes (inputs/outputs) can be bound to groups | Must | +| 15 | Nodes can sign (in/out) | (via Client) | Must | +| 16 | Read sensor via mesh network | SE | Must | +| 17 | Read actuator via mesh network | SE | Must | +| 18 | Nodes share configuration | Nodes share configuration over mesh network | Must | +| 19 | Client read and control nodes | SE | Must | +| 20 | Border router in mesh network | SE | Must | +| 21 | Client can connect nodes | SE | Must | +| 22 | Dynamically (dis)connect nodes | Nodes functionality can be (dis)connected during runtime | Must | + ## Boundary conditions +| ID | Name | Description | MoCoW | +| --- | ------------ | ------------- | ----- | +| 23 | Git/gitflow | Mandatory use | Must | +| 24 | Raspberry PI | SE | Won’t | |