Differences

This shows you the differences between two versions of the page.

--- vrm_portal:vrm_juice_json_api_notes [2015-01-27 09:51] – [VRM JSON Juice API notes (draft)] mvader
+++ vrm_portal:vrm_juice_json_api_notes [2019-01-22 10:16] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== VRM JSON Juice API notes ======
+====== VRM JSON Juice API notes (DEPRECATED!)======
+The VRM Juice API has been deprecated in favor of the VRM v2 API. See new API documentation here:
+https://vrmapi.victronenergy.com/v2/docs
 ===== Introduction =====
@@ Line 19: / Line 23: @@
 ===== Juice backend work list =====
-Below is a list of changes that will soon be implemented in the Juice API
+  - Make it clear that sites/attributes is deprecated, since idDataAttribute is in the input. The new one is sites/get_attributes_by_code.
-  - Add a few lines to the documentation (https://juice.victronenergy.com/build/apidoc/) to make it clear what the verification_token is for, and how it should (or could?) be used. Same for version and for client_version. What is the functionality behind that? Specify that it should be ‘200.a’, and explain that it is for backwards compatibility in case we need to change the API.
-  - Rename the documentation, now called 'Victron Energy 2.0 Webservice API Specification' to 'VRM JSON Juice API documentation 2.0'.
-  - The documentation does not make clear what the difference is between sites/get_site_attributes and sites/attributes. Perhaps it is possible to add an explanation per function? In that case I think it should be:<code>sites/attributes: Request one or more attributes from a site, based on idDataAttribute.
-sites/get_attributes_by_code: Request one or more attributes from a site, based on DataAttribute code.
-sites/get_site_attributes: What is this for?</code>
-  - Add a unit to the formatValueWithUnit example in the documentation, attribute object, so that the difference between that one and the formatValueOnly is more visible.
-  - We need to make it possible for users to request the generated solar energy. That table stores kWh data for several things. Ofcourse we could make it all very nice and customizeable, like we did with the attributes queries, but I think it is better to keep this one simpe. My proposal is to make a new method, sites/get_energy_data. Input is version, sessionid, verification_token, siteid, instance, client_version. Put in the documentation that the value to be put into that instance parameter is always 0. Output is:<code>
-{
+===== Postman App for Chrome: useful to test! =====
-    "data": {
+https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop
-        "energyAttributes": []   -> listofenergyattributes
-    },
-    "status: { etc. }
-}
-energyAttribute object:
-{
-    "code": "ATTR_CODE",
-    "instance": 0,
-    "total": 1233,
-    "formatValueOnly": "%.2F",
-    "formatValueWithUnit": "%.2F kWh",
-}</code>I have left the idDataAttribute out on purpose, since we decided some time ago that all frontend work should use the attribute codes instead.
-  - To many details in an error code are visible, see other email to Rutger.
 ===== DISQUS =====
 ~~DISQUS~~