MVP UI: Hacking the UI for new uses


#1

This topic will be my findings on the ease/difficulty of adapting the OpenAg-UI for use by the MVP (Minimal Viable Product). The MVP is a simplified food computer (~$300) based on a Raspberry Pi brain running Python code. The latest version has been written to log data to CouchDB. The hope is that since both the MVP and PFC are using CouchDB, that the UI could be modified to work for both.

Initial impressions are that this will work, in spite of the data differences. While the UI is a large collection of Java Script (built on Node), most of the js is low level functions. It appears to be abstract enough that the key differences are in the /home/pi/openag_ui/dist/openagconfig.json file. This file, and views created in CouchDB appear to be sufficient to hide the MVP differences.
The UI can run as a service within CouchDB, so that each individual MVP could have its own unique set of charts.

At this time the MVP has two differences from the PFC.

  1. Data is stored in a table named: mvp_sensor_data (instead of environmental_data)
  2. The data file has more attributes, and each value reading is a separate record:
  • timestamp (GMT)
  • object_name (unique identifier, meaningful or meaningless; ie. “si7021-Top”)
  • status (default = “Success”)
  • attribute (temperature, humidity, …)
  • value (as string)
  • comment

These posts will record what it takes to customize the OpenAg-UI. Initial impressions that this will require:

  1. Creating the environment database within CouchDB to match the PFC
  2. Build a set of views in mvp_sensor_data with functionality similar to the PFC
  3. Modify openagconfig.json
  • Change: environmental_data_point (point to mvp_sensor_data database and views)
  • Change: chart - create new charts for MVP needs (variables)

Much of what appears in openagconfig.json is also in main.js. I suspect that the build routine moves one to the other (likely json to js); as the process seems to be a building of the dist, then importing the dist into CouchDB to make it a service.


$300 Food Computer
#3

I think it makes more sense to build a UI from ground up and make it specific to the MVP instead of forking openag-ui, it might take a couple of extra days to give a foundation to the project but it will be a good trade off. In terms of technology, react is clear winner in front end and i don’t see anything replacing it anytime soon. The community, the libraries and everything around is much better than angular or any similar front end MV* framework. Design and Layout can definitely be reused from openag-ui.

Again this is just my opinion and i am not a great front end dev.


#4

@nav
I reached a similar conclusion. Take a look at http://openagbloom.ddns.net:8000 and let me know what you think of this direction. This is simple html with links to charts (SVG images generated by python) and a jpg photo. There is a background process that regenerates things once an hour. The server is nothing more than Python’s simpleHTTPServer. Check Github for the code and install directions (https://github.com/webbhm/OpenAg_MVP_UI),
Having said all of that, I am at a fork in the road. I am looking at lighttpd as a server, as it can handle Python requests for dynamic stuff (forms, interaction with GPIO pins - relay switches). I am just getting started with it, but results so far are promising. My test server is at: http://openagbloom.ddns.net:8080/cgi-bin/test.py This is where I plan to experiment and see how IoT I can make things. And all of this is running on the same Raspberry Pi!
By staying with CouchDB, we should still be able to be a part of the OpenAg community and share data.
I need to take a look at react.


#5

I was unable to check the links, probably having downtime. Sorry i have been quite occupied and consumed by work and not able to put my thoughts into it, but i don’t have much experience with python to comment on use of it. I lean more towards nodejs and javascript for web/api dev related stuff, i can definitely contribute a thing or two in those stacks. I personally like the low memory footprint node.js has and node 8 has come up really well and i am leaning on that for all my development and it will be a while before i can open source my work as it requires a lot of sanitization.
CouchDB definitely is a good choice to share data with OpenAg community and can borrow a lot of functionality from PFC2.0.