Final Post:

This summer I, along with Zen, created an interactive telemetry map interface for our campus that allows end users to easily monitor energy consumption and atmospheric data through a centralized system.
The only resources we used were the Mango API, and open source HTML, JavaScript, and CSS for the web interface.
Our goals were to:
  1. Create an interactive map of our campus
  2. Show generic data when hovering on a building
  3. Create a generic graphing utility
  4. Integrate our web interface into the Mango server
  5. Integrate Mango data into our web interface
  6. Add data points into the Mango database from different sensor types (Control By Web & TED PRO)
  7. Create arithmetic data points to show total usage, production, etc
  8. Troubleshoot compatibility issues between our interface, Mango, and the existing sensors
  9. Make the end interface publically accessible
  10. Document the entire creation process
The solutions we developed were the:
  1. Use of open source technologies to create an SVG based interactive map
  2. Use of open source technologies to create JavaScript based data point mapping
  3. Implementation of Mango JQuery API to integrate data points with web interface
  4. Experimentation with Mango database to successfully integrate multiple types of sensors into a centralized system using the HTTP retriever and TCP/IP data sources
  5. Creation of user permissions and groups, in order to allow end users to access parts of the database
  6. Creation of a versatile web interface that can be adapted to any type of centralized database and querying API
  7. Documentation of entire process and publication of code onto the Energy lab servers
From this project, I personally learned how to set up a telemetry system, how to conduct metadata analysis, and the power of energy micro grids. I also gained the experience of working on a professional project with direct communication to the CEO and Lead Programmers of Mango, in order to craft an optimal solution with given constraints by a specific deadline. On the larger scale of the school, community, and planet, this project allowed me to put data into the hands of the community. Through this easy to use interface, all of the campus’s data is now easily accessible to both the students and the faculty, encouraging engagement and analysis. Through a bigger involved community, we can move more cohesively toward a more sustainable future at HPA. Finally, by making data trends and solutions more apparent to those in charge of making changes, this project will leave behind the legacy of being one more step forward in HPA’s growth towards a more sustainable future.

1 comment

How to use our interactive telemetry map interface:

  1. Go to http://10.14.4.33:8080/ and use username="hpa" and password="hpa".
    This step is temporary, we have already contacted the developers in order to create an auto-login feature so that the telemetry map can be publicly accessible.
  2. After logging in, you will automatically be forwarded to http://10.14.4.33:8080/public-dashboards/index.shtm.
    Note the graphing utility under the page which you might have to scroll down to see on smaller screens.
  3. Hovering your mouse over one of the red buildings brings up a window with the current sensor values for that building.
  4. Left-clicking your mouse over one of the red buildings will automatically load that building's energy consumption data into the graphing utility at the bottom of the page.
  5. this can be done multiple times in order to compare, contrast, and correlate between data points.
  6. Hovering your mouse over the graph displays the data point name, timestamp, and value.
  7. Data points can also be selected through the top-left input of the graphing utility.
  8. Points of interest are
    "main_energy"=total campus consumption measured at Helco meter,
    "pparray_solar_energy"=array of solar panels behind E-Lab,
    elabsolar_energy="solar panels on top of E-Lab,
    The input also allows you to graph atmospheric data, such as temperature, CO2 levels, and relative humidity.
  9. Clicking on the data point name under the graphing utility toggles whether or not it is displayed on the graph.
  10. Clicking and dragging the mouse along the graph highlights the region in red and then zooms in.
  11. You can also change the timerange of the graph using preset values or the custom range selector at the top of the graphing utility.
  12. You can also select how you want to display the data.
  13. This allows you to do complex interpretations like cost with the integral option and a factor or value stability with the delta option.
  14. Using this interface, you can see trends over time, and specific energy signatures, such as the power cycling caused by the refrigerators.

0 comments

Mango System (8/12/2015)

Today we continued fixing up our mango system.
One problem we noticed was the scale, as the total energy consumption showed up as less than the consumption of one building.
We found that this was because the CBW returned a value with unit kW, not W.
We also noticed this problem with the pparray and elabsolar.
Once we created meta datapoints tp scale it by 1000, it all works!
The main_energy is much higher than all the other values, and is a larger sum than all things we measure.
We are having trouble with the provided autologin script.
We tried implimenting it the way the ORU http://205.143.136.105/oru-public/index.htm site did:
but it still sent us from our public dashboard :8080/public-dashboards/index.shtm to the login page. :8080/login.htm
We decided to post the forum: http://infiniteautomation.com/forum/topic/1941/public-dashboard-auto-login-issue
We are awaiting a response.
Besides this one issue, we have everything else fixed with Mango and my web interface.
We are now working on creating the Netatmo PHP app that will query all the data and display it as HTML text.
Here is a good tutorial we found: http://robertan.com/home/2015/05/15/testing-netatmo-weather-station-and-using-php-api/

0 comments

Mango System (8/11/2015)

Today I continued to add more features to my mango interface, as we have already put op all of our existing data points.
One feature we wanted to have was the ability to click on buildings.
Right now, hovering brings up a window with the current values.
We wanted to be able to see all the data for the building by clicking on it.
Because you click on this HTML select element to update the graph, I had to find a way through JavaScript to simulate selecting an option.
I couldn't set the option as a default through HTML because the specific elements do not exist hard coded. All I code is the creation of the menu, it is populated by the Mango API, which only returns active sensors with the user permission. Thus, I had to find a way to select an item that does not exist at first.
Here is the function I wrote, which allows me to select the data point as an input parameter.
However, this would only change the selected value, it would not actually update the chart div.
After an hour of digging through, I found the code that updated the amcharts data provider with the mango data poitns form the HTML select menu was called inside a on('change') function, so I instead moved it out to a complelty new function called refreshChart.
I then call this function once every second.
Now that the amcharts updates with whatever is selected in the menu, I update the menu though an onclickcall on my SVGs, with the correct data point as the input parameter.
It works!
I can hover on a building to see the current values, and click on the building to see all its past data in the graphing utility.
Another feature I wanted to add was the ability to load up the total campus energy consumption value as the default point value to graph.
I accomplished this by calling my function onload inside the body.
Now, when you first go to the interactive map interface, it automatically loads the total energy consumption by default!

0 comments

Mango Data Points (8/10/2015)

Today we finished adding the rest of the control-by-web and the-energy-detective sensors to
http://10.14.4.33:8080/public-dashboards/index.shtm
We decided to continue with TCP/IP for the TEDs, the HTTP Retriever for CBWs, and only TCP/IP if the CBW doesn't render the value on the server instead of the browser.
We then put multiple phases under a single source id they had the same IP.
We then used a Meta data source to add up all of the values.
The meta point returns float sum!
We did this or the Tennis Center,
Energy Lab,
Gates Performing Arts Center,
Dowsett Pool,
Castle Gymnasium & Colson Courts,
Taylor Commons Building,
and the Technology Center & Faculty Workroom.
All of the sensors work!
Now, we have all of the TEDs and CBWs done, and have everything that we are measuring inside the Mango interface.
The empty buildings are empty because they don't measure energy and only measure the atmosphere with Netatmos, which are the next step.

0 comments

MangoES Data Points (8/6/2015)

Today we continued fixing the mango points within Mango.
I started by attaching my variable voltage power supply to the MangoES, so that we could reboot it without SSHing.
We then decided to add some more points.
We found that a control by web was measuring the pool temperature, so we added that into mango.
We then set the read command and the value regex for the individual point.
It works!
I then set the correct read permission for hpa.
Because I set up the page to query the XIDs, it automatically point once it was created.
We then added a new point, because we realized that the elab measures atmospheric data on a control by web.
We set the IP for the sensor.
We then updated the read command and the regex.
It also works!.
Once that was done, we decided to create a sum data point, as many of our buildings measure power in phases.
We then created the point with the variable name.
It didn't work.
We decided to email Joel and Terry about this issue.
They suggested using the metadata source instead.
We then setup the script to return an arrhythmic sum.
It works!

0 comments

MangoES Data Points (8/5/2015)

Today I contianed to add data points to the new 33 Mango machine.
I started by indexing all of the sensors, their buildings, their IPs, and their type.
ELAB:
  • 10.14.54.2 elab energy (CBW)
  • 10.14.43.1 energy solar UPS (CBW)
  • 10.14.14.1 elab-inverters (CBW)
  • 10.14.35.1 inverter temperatures (CBW)
  • 10.14.41.1 energy a-b panels (CBW)
  • 10.14.42.1 energy c-panel and wind (CBW)
  • 10.14.65.12 elab solar (TED)
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Union:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
English:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Math:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Language:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Social:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Technology:
  • 10.9.250.8 energy it building 3 phase (CBW)
Gcac:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Science:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Library:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Pool:
  • 10.14.90.22 pool solar flows (CBW)
  • 10.14.90.21 pool pump flow (CBW)
Tennis:
  • 10.160.8.1 tennis (CBW)
Robertson:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Gpac:
  • 10.14.66.1 gpac energy (CBW)
Taylor:
  • 10.120.8.1 cafeteria (TED)
Gym:
  • 10.14.65.12 gym (TED)
Perry:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Carter:
  • Temp (Netatmo)
  • CO2 (Netatmo)
  • RH (Netatmo)
Total:
  • 10.14.44.1 helco main meter (CBW)
?:
  • 10.180.65.1 cottage1 (TED)
  • 10.180.65.2 cottage2 (TED)
  • 10.180.65.3 cottage3 (TED)
  • 10.180.65.5 cottage5 (TED)
  • 10.14.64.5 hoku energy (CBW)
  • 10.14.6.188 x-320 hoku (CBW)
  • 10.14.26.1 energy-hvac (CBW)
  • 10.14.64.1 Hokuula (TED)
I then decided to work on the interface. and fix the flicker glitch.
Basically, if one hovered on an SVG from the right, the update window would flicker between block and none.
I found that this is because the code to hide the window is called onmouseout of the SVG. This means that onmouseon triggers the window, creates a new z layer between the mouse and the SVG, effectively calling the onmouseout function.
This happened in a loop, which causes the flickering.
To fix this, I manually moved all of the update windows the the right of the SVGs.
Now, when someone hovers on the SVG, there is no way the update window can get between the SVG and the mouse.
I then had to fix the query update problem.
Our page would call the query function on page load, but would then stay still, one would have to reload the entire page to get new data.
Thus, I put my query function inside a window.setInterval, so that the data would update live.
Now, one does not have to reload the page, it automatically stays live!
I then went through all of my sensor queries and changed the last parametor to match the future XIds, rather than the XIds of the test virtual point.
All that is left is to add the actual data points to Mango, and everything should work.

0 comments

MangoES Data Points (8/4/2015)

Today we continued to add more data points.
We started with scripting points, because we needed a way to combine the three phases of a building into a total consumption data point.
Here, we declare the variables through the GUI.
We then assign their sum to another variable.
We then create the data point with the variable.
However, it did not work.
We tried modifying the variables and script, but we still could not get it to return a value.
Also, the return value; statement causes it to crash.
We also decided that we are no longer going to be hosting off of the slow ES, but we will be using the more powerful Mac.
Thus, I had to move all of our web interface over to 10.14.4.33.
I then set up a guest login, and gave it the forwarding URL.
Now, whenever someone wants to look at the data, they just go to http://10.14.4.33:8080/, login, and are sent to the telemetry map.
I then worked on migrating the data sources and data points themselves.
Because they are both the beta version of Mango, there should be no incompatibility errors.
I started by creating a configuration Json object, and importing that into 4.33.
I then had to give the correct read permissions to the guest user.
It now works!

0 comments

MangoES Data Points (8/3/2015)

today we continued trying to get the data points to work on mango.
We started replicating the working CO2 control by web HTTP retriever on 52 onto 72.
Out of curiosity, I tried regexing the XML state page, but that failed.
However, one I changed it back, it worked on 72.
This means that using httprequest only works on HTML, not on XML, so we are limited to only using TCPIP when we need XML.
I then tried getting HTML data from the Helco main meter, but this did not work as the value is loaded once the page loads, not immediately.
Because that wouldn't work, we decided to create a TCPIP source instead of an HTTP retriever.
We gave it the correct regex and set up the point.
It works!
This means that we can only collect data onto the beta mango on 10.14.88.72 in the following ways:
Control By Web TED sensors
TCPIP XML yes sometimes?
HTTP Retriever sometimes? no

0 comments

MangoES Data Points (7/31/2015)

Today we fixed in the user login issue.
Before, they would go to http://10.14.88.72/public-dashboards/index.shtm, but would be directed to the login page.
Once they login, they would have to retype in the URL http://10.14.88.72/public-dashboards/index.shtm.
Because importing the autologin script did not work, we tried to integrate their function into our own page.
It did not work.
Thus, I decided to create a new user for the people who will be using the page.
Here, we are able to set the home URL, so I set it to our interactive telemetry map.
Now, we send them to the IP address.
And once they login, they are automatically forwarded to out map system!
However, they could not see any data.
We then discovered that this was a data point configuration issue.
We then gave read permissions to the hpa user.
We chose only the real data points.
Now, the hpa user can see the data!
Because they are a separate user, they only have read access to the real sensors, with their own login, and are directed to the map, not the point interface.

0 comments

MangoES Data Points (7/30/2015)

Now that we were able to successfully integrate the gym_energy sensor with our hover map page, we decided to extend it to the identical cafeteria TED sensor.
We began by creating a new TCPIP data source with the appropriate ip address. .
We then gave it the same read command and regex as the one we used for gym_energy.
However, it did not work, the page returned "not a number".
We then checked on mango ans saw that the point is not returning a value.
This is concerning, as the sensor is without a doubt alive at http://10.120.8.1/
In addtion, we can verify our regex by looking directly at the XML at: http://10.120.8.1/api/SystemOverview.xml
We do not know what the issue is, as the sensor is live, but Mango cannot read from it, despite using the exact same query as gym_energy, as they are both the exact same TED pro model.

0 comments

Mango HTML & Javascript Web Interface (7/29/2015)

Today we successfully integrated the graphing utility and one of our own real data points into the telemetry map interface.
We started by building the graphing utility itself.
We had to figure out which libraries the code needed.
For some reason, we needed the @import url line, so that we would not have the weird years at the bottom.
Inside the JavaScript, we removed the unnecessary menus, and gave it a default value of 1000 query-able sensors.
We then create inputs for the user, and a div for the graph .
Here is the working output:
You simply select a sensor from the drop down menu, and amcharts does the rest.
You can also graph multiple data points and change the range.
We also tried to get it to auto load a data point.
However, it did not work.
I then migrated the graphing utility into the telemetry map.
We started by importing the correct libraries.
We then had to incorporate the code for creating the chart into the code for querying the sensors.
I decided to place the graph code inside a library import declaration.
I then put my function for retrieving strings into the library declaration as well.
After that, I ran the function to initiate the graph, and to query all the sensors.
Finally, I close the library deceleration, and declare my hover functions.
The graphing utility works on our map page!
Once we accomplished that, we decided to add in a real data point, instead of the demo voltage one.
We started by understanding the relationship between the data source, the data name, and the data point.
Here is the hierarchy we have decided upon:
building_atmo
|___building_co2
|___building_temp
|___building_rh
building_xml
|___builiding_energy

Here is gym data source:
we gave it the same name and XID.
We also had to set the host, port, and delimiter.
Then, we had to edit the point, to have the correct name, XID, read command, value regex, value index, unity, and logging interval.
It works!
I then changed my JavaScript to call the QuerySensor with the new xid, and it returns a value to the hover window, and I can graph it using the utility at the bottom!

0 comments

MangoES Data Points (7/28/2015)

Today we fixed the data point issue on the new MangoES system.
Because the new mango used a completely new API, we had to find out how to get the data again
We started by by looking at the example code for a simple text display.
This uses a new format of importing the Jquery and MangoAPI library, and runs the new code inside that declaration.
The function call has also changed in accordance with the new API.
I then added my own inputs parameters, converted it into a function, and parsed the text.
Here is the output.
Once this was fixed, I tried to see if I could access the public dashboard without logging in, as it is inside the public-dashboards folder and it uses the new mango API.
It did not work.
I then integrated this function into my old interactive map, so that I would be able to query data on the new mango, as my old code no longer worked.
I started by declaring the query function inside the import declaration.
I then queried all of the sensors inside the declaration loop.
Outside of the loop however, I declared my hover functions.
Once I figured out that it only worked this way, I saved it to:http://10.14.88.72/public-dashboards/index.shtm and it all worked perfectly with the test data point!
Our next steps are to create a new graphing utility with the new API, and put all of our data points into the Mango system with the correct XIDs.

0 comments

MangoES Data Points (7/27/2015)

Today we worked on the data points on the new MangoES device.
However, it would not show up when we went to the IP address.
We knew it was not a problem with the browser or the device, as the connection is refused, not failed.
We eventually fixed it with
cd /opt/mango/bin
sudo ./ma start
However, the mango would still die after a while.
We then looked at the warnings right before we reset it.
Apperently the excelreports module was causing the problem, so we disabled it.
After this, we realized that we are creating a public dashboard, not a private dashboard, as we do not want end users to log in to the actual system.
We copied over the files and changed the appropriate links, and the restAPI worked perfectly on the old 52 machine.
However, it still required a user to login , and it directed the user to login.shtm if the right cookies did not exist.
We then found a autologin script, made by the Mango developers, so we included it in.
However, it did not work.
We then figured out that their example was outdated, and we had to change the reference filepath.
It still did not work.
We then looked through the public-dashboards examples to see if there was a different API we needed to use.
However, all the public examples were login pages except for rawXhr: http://10.14.88.72/public-dashboards/rawXhr.htm
But this did not work:
We know that it is not an issue with reading the virtual data point "voltage", as the private dashboards examples work with it fine.
We also tested this public dashboard on 52 and 33, and none of them work.
Here is the console log:
This one, which requires a login, works.

0 comments

MangoES Setup (7/23/2015)

Today we continued setting up the MangoES server.
We tried SSHing into it, but we kept getting refused.
After a while, we determined that the ssh server is actually on port 2222, not port 22.
We can now ssh into it!
Once, that was fixed, and we could ssh into it, we decided to give it a static IP adress.
To do this we had to edit the /etc/network/interfaces, and add the adress: 10.14.88.72.
Once that was all setup, we removed the HDMI, put the case back on, connected eth0, power, and set it up to run headless.
However, we then had an issue with sudo.
The OS would hang.
To fix this we had to add the localhost to /etc/hosts.
Now, we can use sudo!
once that was fixed, we decided to work on the Mango side of things.
We saw that the webserver was enabled, but it was on port 80, not 8080.
http://10.14.88.72/index.shtm
However, we could not find the actual mango directory, as it was not in /var/www/ or /home/mango/.
Instead, it was in:
/opt/mango/web/modules/dashboards/web/private/index.shtm
Once we figured that out, we coppied over our map files, and set it up at:
http://10.14.88.72/private-dashboards/index.shtm
It works!
We just need to migrate our data points over to the mangoES.

0 comments

Mango HTML & Javascript Web Interface (7/22/2015)

Today Zen and I began the process of duplicating our entire sensor network onto the Mango system
Because my Query function uses the Rest API's XID method, the point heiarchy does not matter to the webpage.
I just need to create data points with the appropriate XID.
We then began to add another energy data point: http://10.14.4.52:8080/data_sources.shtm
We then add a new TcpIp data source.
We then give it the XID that will be referenced by the JavaScript Rest API.
We also give it the correct host,
port,
and delimiter, so it knows where to get the data and how to parse it.
Once that is doen, we create a new data point.
We have to give it the appropriate
name,
XID,
data type,
set it as query-able,
give it a read command,
set a value regex,
and give it a value index.
After that is set, we also have to specify the
unit,
chart colour,
plot type,
logging type,
interval logging period,
value type,
chart type,
and chart limit.
However, it did not work.
In the meantime, we got the MangoES, an embeded sytem that is optimized for Mango.
In order to power it, we needed to splice our own power cord.
It works!
We then took it apart so that we could interface with it.
We found that there is a micro HDMI port on the circuit board, which we connected a display cable to.
Once we logged in, this came up!
we now have a headless Linux machine for running Mango that we can interact with through a shell.

0 comments

Mango HTML & Javascript Web Interface (7/21/2015)

Today I worked on fixing the javascript value storage issue.
After Steven and I dug through the API, we discovered that that the mangoRest.realtime.getCurrentValue function takes in another function as an input parameter, and crafts that into a ajax template promise internally.
This allows the server to capture the value and return it inside the function.
It also explains why my return did not work; I was not returning the value to my own function, I was returning it to the promise ajax template.
Because I could not return the value or set it to a global variable without changing how the API functions, I decided to utilize HTML as a proxy for temporarily storing the value.
However, this did not work.
After about an hour of debugging I found that this was because the mangoRest.realtime.getCurrentValue function does not immediately return a value.
In other words, I am trying to read a value that does not exist yet.
I then modified my code to only call my HTML retrieval function once my querry function returns a value.
However, this did not work either.
Because the promise is handled internally by the API, my own query function returns as done once it starts the request, not once the request returns a value.
Again, because changing this would require modifying the core Rest API, I decided to look for more alternatives.
We decided to go back to the dashboard templater for the master graph, as that will utilize user input, and we will populate HTML divs with the QuerySensor function.
Here is the new, parsed, formatted ouput:
Rather than individual bar charts, each value is rendered from the XID as text.
I then integrated it with my index page, so that each SVG would trigger a hover window that contains the above information.
Curiously, I had to change my index.htm to a .shtm file: http://10.14.4.52:8080/private-dashboards/index.shtm
I then called my querries at the top, and assigned it to the appropriate divs.
My divs are contained inside the update window that is triggered by the SVG.
Here is the output:
I then expanded my code to create hover windows for all of the buildings.
Our next step is putting all of the sensors into mango, so that I can reference them by their unique XIDs, creating the master chart with the dashboard templater, and using the Netatmo API to allow us to integrate their data into our network.

0 comments

Mango HTML & Javascript Web Interface (7/20/2015)

Today I continued working on the issue of assigning the sensor value to a unique JavaScript element.
In order to overcome this, I tried to return the sensor value as the output of the function, so that I can simply call the same function with different input parameters, and it will return the appropriate outputs.
I start by returning my variable QuerrySensorValue inside the mangoRest function:
I then call the function as the input of the document.getElementById, in order to pipe it to wherever I want.
However, It returns undefined.
I tired adding 500 to the value, to check if it is really a float, and it worked.
This means that the problem is not in accessing the variable internally, but in accessing it externally.
I also created a temporary function called value() that returns a float, so that I could check if amcharts takes it in as output.
This worked, so my approach of returning a value in a function is possible.
I then tried to return the output of the mangoRest function, while also returning the output of the currentValue function, in order to get the original value that is created internally.
However, this results in an object object error.
this means that the internal return that I wrote does not register.
Presumably, returning currentValue.value does not work.

0 comments

Mango HTML & Javascript Web Interface (7/17/2015)

Today I worked on fixing the graphing display properties.
I spent hours going through the API in an attempt to find out how to assign unique value fields.
However, it did not work, despite using the exact code shown in the API examples:
Thus, I decided not to use Mango's own bar chart constructor, I decided to create my own.
http://10.14.4.52:8080/private-dashboards/test1.shtm:
I started by going through their Rest API, and retrieving the data into the simplest possible format; a string.
I then piped it into a div and it worked!
My next step was to insert my custom amcharts template code.
Once I did this, I had to find a way to pipe the queried value into the graph.
I decided to return the value once the function is called, so that I can simply call it when I am creating the data provider.
Instead of setting it to a static value, I call my function here:
However, it did not work.

0 comments

Mango HTML & Javascript Web Interface (7/16/2015)

Today we finally fixed the group select configuration issue!: http://10.14.4.52:8080/private-dashboards/test.shtm
We apparently had to switch our entire code from using the dashboard templater API to the Mango rest API.
This was because the dashboard templater is designed for user input, so it only calls a refresh() once a grouplist is clicked on.
Instead, we switched to the Rest API, which matches the XIDs to the point values on page load.
Once we learned this, we had to impliment the Rest code thorough a bar chart, and here is the resulting code:
He start by creating pointconfigurations with unique datapointmatchconfigurations and XIDs. the datapointmatchconfigurations are shared by each graph, but the XIDs are completely unique (19x76)
We then add a barchartconfiguration with the correct div id and datapointmatchconfiguration.
We leave the category field as the name and the value field as the value.
Once that is done, we have to actually implement the Mango Rest API.
we start with the getALL function, which actually queries Mango and returns the data values for each XID.
There is also apparently a required showError function, as the code crashes without it.
Nevertheless, the end result is a graph identical to the one created using the dashboard templater, the only difference is that I do not need to click on the target folder inside the point hierarchy in order to make it load the data.
Next, we started configuring the amcharts to match the template we designed for the hover windows.
I copped over my code from the live editor into the bar chart constructor.
However, this was the result.
This was because the constructor only takes in the datapointmatchconfiguration id as input, and creates a graph for each data point, which is why there were 4 graphs for all 3 data points.
When I only have one graph code, here is the result:
However, this is unusable, as the data needs to be shown on different scales, and given other colors, to distinguish them as unique data points.
In order to do this, I had to change the valuefield from "value" to a specific xid.
This did not work either. I then looked into the API and saw that the constructor follows the format of:
new BarChartConfiguration(‘divId’, [dataProviderIds], AmChartJSON, mangoChartMixins, options)
Thus, I decided to put in my own datapointmappigns.
This too caused the graph to not render.
I then spent time on the amcharts live editor to figure out how to fix the graph, and saw that the data structure is organized into
category == individual data point
column == individual graphs
In other words, I have to find a way to map individual data points to the individual graphs, or individual columns to individual categories.

0 comments