radlikewhoa/happyflowers

happyflowers is an IP5 project at the University of Applied Sciences and Arts Northwestern Switzerland.

happyflowers's Issues

[Web] Input placeholders are buggy in Safari

• Input placeholders remain visible on name field even if input is present
• Input placeholders are visible even if number fields are focused when value is deleted / invalid

Both are resolved if the user moves the cursor into / out of the input. Seems really weird and I'm not really sure what possible solution there could be.

[Web] Add propTypes to React code to improve coding style

All components should have valid prop types defined for all their props.

[RPi] Process does not stay running

When executed on the RPi, the process started by cabal does not stay running. This works on other machines.

[Web] Integrate notification framework

We need to give the user feedback about whether their requests were successful or if there were any errors.

[Web / API] Extend API configuration

Currently the configuration contains only the password to use for authentication. We should extend that to also contain a setting to determine the time period to use for the history view. Maybe in the end we can include further options if we write the configuration reading code as flexibly as possible.

[RPi / Docs] Connect Chirp! sensor

• Connect the Chirp! sensor to the RPi and use I2C tools to check if it's working correctly.
• Read data from the sensor.
• The connection then needs to be documented in the project report

[RPi / Docs] Connect USB water pump

• Connect the pump via USB and allow triggering via GPIO. This has already been tested with an LED so it's just a matter of connecting the pump and giving it enough power.
• The connection then needs to be documented in the project report.

[API] Document Haskell code using Haddock

This is a hard requirement. All Haskell code must be documented properly using Haddock. This concerns modules, functions and types.

https://www.haskell.org/haddock/

[RPi] Read data from moisture sensor

The moisture sensor needs to be connected to the RPi. Measurements need to happen at a defined interval. Ideally, this process should look as follows:

1. The procedure is started, an initial measurement is taken. This measurement is an average of measurements from a defined period, e.g. 1 measurement per second over 10 seconds.
2. The data is added to the database.
3. The RPi triggers a WS event that informs all connected web clients about the new measurement. (This is something we'll do as part of Milestone 2.)
4. Get database entries for settings. Check if the latest measurement falls below the lower threshold. If so, initiate automatic watering procedure. This is a separate procedure.
5. Schedule the procedure itself to run after the interval taken from the settings.

[Web] Document React / Redux code using JSDoc

Even though the JS code is not the most important piece of code in the project it's still nice to have proper documentation, at least of all classes.

http://usejsdoc.org

[Web] Listen to data about new measurements, waterings

Subscribe to web socket events raised from new data (e.g. measurements, waterings.) These updates then dispatch Redux actions which in turn update the data on the front end. This communication is entirely one sided, updates from the RPi are only pushed to the web front end, not the other way around.

[Web] Consider adding additional tooling

• flowtype (https://flowtype.org) for type safe JS code (this most likely means that we'd have to drop react-scripts. Maybe it's wort it though)
• Immutable.JS (https://facebook.github.io/immutable-js/) for immutable data structures in JS (technically it's even a requirement so yeah, we should really get working on this)
• redux-actions (https://github.com/acdlite/redux-actions) for easier action creators and reducers in Redux applications
• sections 8 through 12 in this guide talk about lots of tools that could be useful for us in the project.

[Web / RPi] Integrate livestream

In order to provide a livestream we need to have several things ready:

• Aquire a USB web camera. Any model will do so we can get a rather inexpensive one.
• Set up and run the server on the RPi. This seems quite simple as motion will do most of the work for us. See this tutorial for more info.
• Display the livestream on the web front end. The stream is a MJPEG stream. I'm still researching about browser support. We can either include is as an img or we might have to use a wrapper around it. There's multiple JS implementations for such a wrapper, so I think this is a non-issue.

[RPi] Measure temperature using Chirp! sensor

The sensor allows not only measuring moisture levels, but also the current temperature. In the code we need to read from register 5.

This is an enhancement that we could possibly implement if there's enough time.

[Web] Improve layout on small screens

• Header should be handled more elegantly, maybe not be fixed
• Navigation somehow needs to work on small screens
• Reduce vertical spacing of body

[API] Integrate authentication using JSON Web Token (JWT)

https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
https://bitbucket.org/ssaasen/haskell-jwt

[RPi] Document setup process in README

This includes all required tools and components, requirements about the environment, and how to install dependencies. After reading this guide, users need to be able to set up the device and start all required processes.

[RPi] Improve mockMoisture

The function currently returns a fixed value, thus preventing the pump procedure from being tested properly. We could possibly implement some sort of RNG to create random numbers, but they'd need to follow a structure so that the process does not keep running indefinitely.

[Docs] Create project website

Create a small static website showcasing the project and involved technologies and tools.

[Web / API] Settings

• Web: Layout for settings page
• Web: Pull data from API and display
• Web: Submit data to API
• Web: Display information about progress when loading / submitting (see #6)
• Web: Display notifications for errors / success (see #5)
• API: GET request to retrieve settings data from sqlite DB
• API: PUT request to store changed data in sqlite DB

[Web] Integrate loading indicators

This helps the user better understand if there's any loading / processing going on. In the end, this also prevents them from submitting content again.

In the same area we also need to disable submission buttons if a submission is already in progress to avoid duplicate submissions.

[Web] Enable manual pump activation

Users need to be able to activate the pump manually. This is mostly just for demonstration purposes, but it needs to work without errors regardless.

[API / RPi] Set up WebSockets server on the RPi

We are going to need to add a WebSockets server to enable direct communication between the web front end and the RPi, and vice versa.

There's examples for a server implementation and a client implementation.

https://hackage.haskell.org/package/websockets

[RPi] Build and run GHC 7.10.3

I figured it might not be too much of an issue, running an older version of GHC, but it turns out that our current codebase doesn't compile against this version of GHC. So we either have to rewrite a lot of code in our codebase or try and get the latest version of GHC running on the RPi.

In theory, this should be as simple as installing the latest version of the Haskell Platform, but there seem to be some bugs surrounding this release.

As long as this issue is not resolved we're unable to install all dependencies, thus not allowing us to build the project on the RPi itself.

[API] Integrate error handling for sqlite and file system code

Currently there is no way of telling whether the requests were successful or not. We need to check if the queries and statements were successful instead of just silently failing.

[API] Improve code modularisation

We can at least split models and API code, maybe even more.

[Web] Try out different backgrounds

I've received some negative feedback about the background, we should maybe look into it.

[Docs] Add graphs and references

• Add graphs (they are most of the remaining todos)
• Add references (marked with todo1)

[API] Serve web front end as static files through Scotty

Ideally we'd just have to start up the server and it runs both the API and the web front end. Routes for API methods could then be prefixed with "/api/" or something and all other request just redirect to "/index.html" unless a file with that name exists.