ollz272 / garden-server Goto Github PK

We should look to only supporting a subset of period resolutions that will be useful. Those can be:
None = Raw
1 minute
5 minutes
30 minutes
60 minutes
1 day

With recent changes we need to incorporate zones and weather into the views.

I think most of the logic can stay the same. On the plants list page, we'll group by zone. We'll have a button that allows for adding new zones. When creating a plant, a list of zones that user has will be used.

Additionally, on a plant page, we should display the latest weather.

We also should have on the plant page a way to create alerts for that plant.

Somewhere we should also have a notification list for logs that haven't been read yet.

Lots of changes to the models recently. We need an API for:

• Zones
• Weather

Additionally, plants should return what zone they're from

All the cool kids use poetry. Time to switch to poetry 🤷🏻

Write a github action to push a docker image to a repository

Need to write a good test suite and implement this in CI

implement ruff into the pipeline

Probably best once zones are introduced.

• - Zones/plants should have a postcode. On submit, we'll do an api look up to grab the lat/lon https://postcodes.io/
• - Create a model that can store weather data. Probably adhere to https://open-meteo.com/.
• - Create a management command for populating this data.
• - Create a cloud function/scheduler/thing that runs this once a .... day?

Self describing, linting in CI

Alerts are user defined limits on how their sensors should behave, and we should implement a system of tracking these.

Lots of stuff needed for this

• A Database model that links to a sensor and defines the alert
• • Alert should probably contain a Threshold Value, an equality operator, and maybe a time spent/number of datapoints in that threshold.
• Once we have alerts we need a database model that can log these.
• • This would be akin to a database model thats linked to an alert and a sensor, with a datetime, and maybe some context. TBD.
• We'll need a way to "scan" for these.
• • Maybe a system of running these on google cloud every 15 mins or so?
• Finally once we create an alert we'll need to... do something.
• • Maybe to investigate once the above is done.

At the moment the way we create sensors is kinda weird, and complicated as an inline form. Worth splitting up as:

1. Once plant is created, have a "manage plant" view.
2. In the manage plant view you can configure plant specific things
3. There should also be a list of all sensors, with the ability to create, manage and delete these individually.

This should be more scalable if features are added to sensors.

Expose the data thats collected to a csv download that can be downloaded

REST framework is kinda overkill here, and https://django-ninja.rest-framework.com/ is quite simple and fast. Worth rewriting the API to be minimal but effective

some N+1 issues are popping up.

Zones can contain plants and should be the bedrock of the app.

For initial version we should:

1. Create a new zone app
2. Create a zone model, with a name and a user
3. Have a link between plants and zones
4. Create an "indoor" and "outdoor" zone for each user if they have a plant in that zone.
5. Link the plants to these new zones
6. Deprecate indoor.

Probably need some defined units rather than letting everyone choose. Need to investigate properly...

Lets get this thing deployed on google cloud run!

• Fix docker image to use poetry
• Set up conventional commits commit hook
• Set up repo to make a new release based on semantic versioning.
• Push new docker release to GCP on release.
• Set up GCP to run new image on cloud run

We have the chart API which can be used internally (maybe we move towards using that on the FE), but would be good to also allow the data itself to be grabbed from the api using query params to specify bits.

Make the login and registration form look pretty