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 - MVP
#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.


#6

@webbhm, question for you, how did you expand your MVP Dashboard to graph all that data versus just showing 1 day’s worth of data? I have been trying to figure that out and even started a topic asking such Can you expand the graphing range on the MVP Dashboard to show more than 24 hrs but then I cam across your link and I see you have more data on your graphs, etc.

Thanks in advance,
staiano


#7

There are two points where the data is throttled.

  1. The query where the data is retreived from the database
  2. The array manipulation of the data

I am not sure which version of the code you have, so the following may not exactly fit what you see, but you don’t see the exact same lines of code, you should see similar.
In the TempChart.py, getResults function the query has a “limit”:250 or limit=250) This restricts the results to return 250 records from the database. I make this a rough number, depending on the type of chart. If I combine temperature and humidity (to calculate dewpoint) I am getting about two records per day.
Another option is to set a data range on the query (which you may not see in this code). The query is the main place where the data is controlled and limited.
The other control (which I don’t always use) is to set a size on the arrays that are build when the records are being processed.
The chart displays whatever is sent to it.


#8

We literally just built it in the last two weeks so I believe we are working with MVP ver. 2.1 from GitHub. My TempChart.py has …limit=60 which seems to correlate to the number of points my graphs show. I will play around today and let you know.

Thank you very much.


#9

I tend to confuse myself as I am working on future versions and looking at v3 and beyond, and forget what is the ‘current’ version for most people. I also have multiple repositories in github, and sometimes people experiment around and grab a newer version.
You should be able to change things by modifying that number and saving the file. The ‘throttle’ on the query should be the only limiter of the chart for that file.