I was thinking about implementing it this way as well. But, isn’t possible to build this into one device with all of the attributes contained within? Not that it matters, but this would also be more efficient on the API.
Correct, I am having issues getting it to work as json_attributes
However, I am a bit novice at this, so it could totally be user error. What @stevemann posted works, but isn’t there a better way to handle this type of data.
Yes, your idea is sound: create one sensor to retrieve all the data and, ideally, store it as attributes to be used by other sensors (one per attribute). This minimizes the number of times Home Assistant polls the remote data-source.
The challenge is parsing the received data’s structure (a list containing a dictionary). The RESTful sensor’s json_attributes option is rather limited. It expects the received data to be a dictionary and nothing but a dictionary.
Another way to do this is to retrieve all the data into the RESTful sensor’s state. As long as the data doesn’t exceed 255 characters in length, this is a viable option. Then you use template sensors to extract the portions you want from RESTful sensor’s state. However, you have to use regex_findall_index to perform the parsing because the data will no longer be handled as a JSON object once it’s stored in the sensor’s state.
I only use the sgv and trend in my CGM monitor, (Trend is a numeric value for direction). I am a rank novice with JSON and I found it more straightforward to extract the data from the current.json REST API.
The implementation of json_attributes missed the mark. It doesn’t work when the json object is a list of dictionaries. It only works when it’s a dictionary. Very poor implementation if you ask me. Rest and Commandline sensor needs json_attributes_template that MQTT has. Then people can properly extract the info they want in ANY json object.
Agree 100% and it echoes what I said in a previous post about ‘fit and finish’ issues, namely inconsistencies in behavior or operation (or outright deficiencies) that need to be addressed before 1.0. I see it as an initiative that ought to be driven by the project lead because of its comprehensive scope.
Here’s a slightly improved version of my previous example. To mitigate the possibility that the received data may exceed 255 characters, the RESTful sensor’s template extracts and stores only what’s needed (and discards the balance).
I’ve implemented them both, and they are working great. But, it seems like using separate API calls (what @stevemann is doing) for each element might make more sense (to this novice user).
For simple actions like displaying the values in Lovelace, the separate sensors work better.
I get the feeling there may be a misunderstanding because the example I provided does, in fact, use a separate sensor to display each parameter.
sensor.bryan_cgm is exclusively for data-collection. The data it collects is consumed by the other three sensors. Don’t even bother displaying sensor.bryan_cgm in the UI.
These three Template Sensors get their data from sensor.bryan_cgm.
sensor.sgv
sensor.trend
sensor.direction
They are suitable for display in the UI (i.e. graphing with an appropriate card).
The approach I’ve presented reduces the number of requests to the REST data-source (Nightscout). One RESTful sensor collects the data and the three Template Sensors consume it. This is more efficient than having three RESTful sensors where each one independently gets the same data. That’s three requests for the same data every 30 seconds instead of just one request.
Just one slight change from the code @123 provided. I added unit_of_measurement: "mg/dl" to the sgv sensor so lovelace can display a graph in the card.
If I test that in the Template Editor, using your original data, it reports the appended time parameter (as an integer value representing the difference in timestamps between now and the reading … if I’ve understood the supplied template):
NOTE:
Because it is using the space character as a delimiter, none of the data values are allowed to contain a space. For example, should the direction parameter potentially have a value consisting of two words then you cannot, obviously, use the space character as a delimiter. In that case, the template can be easily modified to use a comma as a delimiter.
I am using my nightscout JSON file to import blood sugar. On top of this I would like to summarize daily insuline usage (basal/bolus) and carbs. Anybody found a way using the api/v1/treatments json to do this?
