Can you kindly share some photos?

Description

With changes of file structure & software architecture (and improvements in my own programming ability), clean up and adjust the Hub: Manager scripts to work & function better than previous version.

Acceptance Criteria

• Event Predictor can accurately predict events
• Document how to setup Adafruit IO [and IFTTT events]
• Document how to setup and DB uses

Description

With (finally) the addition of Endstops and Encoders in the code, the 3D models for mounting them must also be updated.

Acceptance Criteria

• And endstop for the close position must be mountable
• An encoder must be mountable
• Make interchange 7mm shorter so that the curtain has more room to overlap. This helps with privacy and light

Description

With the release of the auto-updating ability, the feature lacks the ability to run scripts that are possibly required for updating.

Acceptance Criteria

• Using the same process as done with the DB, call shell commands with version .sh files
• Move DB & SH update files to an Update folder

Relies On

#18

Description

As a curtain user,
I want my hub to find nodes on my network and set the IP of the Hub,
So that I do not need to set static IPs for my hub and nodes.

Acceptance Criteria

• Node information can be updated
• New curtain JSON format is used
• DB reflects new smart Node information centralization (node has an idea about its length, direction, position, etc)
• Hub system reflects above DB changes

Parent

#17

Can you kindly share some photos?

Description

As a SmartCurtain user,
I want to add Bearer Token security,
So that others cannot use my app without authorization.

Description

As a curtain hub programmer,
I want to be able to tell a curtain what percentage open I want the curtain to be,
So that I do not have to worry about calculations and states of the curtain when developing additional functionalities.

Acceptance Criteria

• Curtain Node is able to determine or assume its current location
• Curtain Node & Hub communication through JSON (detailed in the documentation of NodeQuery branch)
• Curtain Node is able to have attributes reset by JSON
• Curtain Node is able to go to a percentage open based on determined/assumed location
• Curtain will determine its location on startup if hardware is available to do so

Stories

• #21
• #18
• #16
• #15
• #10
• #9
• #8

Preceding Stories

• #21

Description

As a curtain node user,
I want a way to update the curtain node's information, get information, and activate events,
So that I can prevent hardware damage, have it communicate more dynamically, and operate more simplistically (from a higher level).

Context

The communication between Node and Hub is currently very limited. This will add more actions for the node, to improve data and operations flows.

Acceptance Criteria

• Ability to request current information about curtain (id, location, length, etc)
• Ability to activate an event
• Reset the curtain (move to home and then back to know actual location)
• Update curtain information (length, IP, direction, options, etc)

Branch

NodeQuery

Parents

#17

Desciption

Add ability to uninstall Hub features from Raspberry Pi (or other Linux device)

Acceptance Criteria

• All cloned data, files, and folders are removed
• Linux service is disabled and deleted
• Logs & folder are removed
• DB (not DBSM) is deleted

Description

The motor currently determines location based on endstops & stepping. It also needs an encoder for manual or alternative (to stepping) movement tracking.

Acceptance Criteria

• The Node is able to know its location & movement with an encoder

Follows

#16

Description

When a node receives an event, if the node’s stored location differs from its hardware determined location, the curtain resets with auto correct. EG, if the stored location is 0%, there is a close end stop, and the closed end stop does not read closed before movement, then the curtain will go to closed before moving to the desired location.

Context

The curtain will sometimes be positioned differently than where the software thinks it is (eg there is no encoder and the curtain is moved manually to or from an end stop). This spike adds the node the ability to determine if it needs to move to redetermine its actual location so that it can more accurately move to its desired location.
This requires an endstop.

Possible Implementations

If

1. Known location (where curtain thinks it is) is an end and the hardware location reads curtain location as not an end
   • Move to the known end (where the curtain thought it was)
2. Known location (where curtain thinks it is) is not an end and the hardware location reads curtain location as an end
   • Current location can be guaranteed, so update known location.

Acceptance Criteria

• [ ]

Possible feature that is not yet confirmed to be desired. Allow integration with Home Assistant.

Acceptance criteria

• Events are driven and managed with Home Assistant
• No loss in functionality

Description

As a front end user,
I want to receive HTTPErrors from the backend in the form of a JSON,
So that my front end can receive consistent data formats.

Description

If the curtain is already at the desired location according to hardware or its self state, have it ignore the any further steps in the Movement::activate function.

Context

Currently, even if the curtain is already in its desired position, the Movement::activate function proceeds through all of its steps. Having the curtain check whether it already is at its desired location for each of the conditions in the decision tree (if-else statements) complicates their logic. To have it done initially helps to simplify the logic flow.

Possible Implementations

Check if hardware/software determined location is desired location. If it is, branch out of logic flow and do nothing. If "tricking" the curtain to move to another location is necessary (EG no hardware and the curtain has been manually moved), the curtain location can be set in the activation JSON. Hardware is assumed to always be correct (IE if an endstop is triggered, then that takes location precedence over JSON received values).

Acceptance Criteria

• Checking if the curtain is already at the current location is the first node in the decision tree for what movement steps to take.
• If the curtain is already at the desired location, the decision tree ends there.

Description

When an event that duplicates a movement (EG Close, Close OR Open, Open) occurs, an Exception should be thrown if the curtain is not smart and is safe to prevent a damaging action. This exception throw does not prevent the HTTP request that triggers the action.

Steps To Replicate

Create an event to open curtain. Create another event to open the opened curtain.

Area Path

Hub/Event/Damage

Possible Solution

Reverse the logic of the if statement and scope the send request expression to be within it.

Description

As a Maintainer,
I want Curtain Event and location to be expressed in an integer percentage form,
So that movement and communication development can be uniform and simplified.

Context

The JSON communication to activate the Node is being updated to allow additional features. With this update, relative positioning is a feature (EG "I want the curtain to move this percentage open") so that the Hub does not necessarily have to know the exact length of the curtain.

Acceptance Criteria

• Update DB
• Update Hub code
• Update Node Functions

Branch

NodeQuery

Parent

#17

Description

When the curtain is not activated for several days, the node has to be reset (ie unplugged and replugged).

Context

The curtain that has this issue is the one where the Mac Address is changed using the esp_wifi_set_mac function. The other curtain that does not use the esp_wifi_set_mac function does not have this issue. The network statically assigns all IPs.

Possible Causes

1. Because the network statically assigns the IP based on Mac Address, the Mac address may reset after a period of inactivity to the ESP's default. Looking into known issues of the esp_wifi_set_mac function could provide useful.

Possible Solutions

1. If the above theory is correct and it is a known issue, there may be a proposed known solution. Additionally, gathering information about the network (attached devices) may provide useful.

Complete pages for Web UI to create future events, edit/delete future events, & change options.

Acceptance Criteria

• Events can be deleted
• Curtain information can be updated

Preceding Stories

Description

If an event fails to activate add functionality for activation packet to resend

Context

Possible Implementations

Acceptance Criteria

• Events will send another packet for same event information if no response received
• Feature can be turned off and on