I’m using a piece of code that uses the REST integration to create a sensor from a specific resource.
The code is not something I have written myself and I don’t have the skills to adapt it to my needs.
It’s several lines of code.
The sensor it creates has a state that is one long string which contains five sets of information. It is from this string I would like to extract the “value” portion, which at the time of writing is the number 1 for all five.
It’s not that important if it ends up being one sensor with five attributes or five separate sensors, although I would prefer one sensor with five attributes.
What is this “piece of code” you are referring to because it doesn’t sound like it employs either of the two REST integrations I mentioned. If it does use one of the two aforementioned integrations, please post the “several lines of code”.
rest:
scan_interval: 3600
resource: https://www.astma-allergi.dk/umbraco/Api/PollenApi/GetPollenFeed
sensor:
- name: "Græs (prognose)"
icon: mdi:grass
value_template: >
{% set region = '48' %}
{% set pollen = '28' %}
{% set prognose = (value_json | from_json).fields[region].mapValue.fields.data.mapValue.fields[pollen].mapValue.fields.predictions.mapValue.fields %}
{% set data = namespace(predictions=[]) %}
{% for p in prognose %}
{% set data.predictions = data.predictions + [{'date': p[6:10]+p[2:5]+'-'+p[:2], 'value': prognose[p].mapValue.fields.prediction.stringValue}] %}
{% endfor %}
{{ data.predictions | sort(attribute="date")}}
It’s a sensor that collects Danish pollen figures.
“Græs” means grass. “Prognose” means prediction.
Region = 48 is for the western part of Denmark (east is 49).
Pollen = 28 defines the type of pollen (grass in this example).
There are several other sensors for other pollen types, but for the sake of simplicity I just pasted the code for one single type.
Thanks for posting it. Now I understand that the “piece of code” is simply the configuration of a REST sensor.
I added it to my system so that I could view the data it produces. Its template selects and reformats a portion of the received data (because the received data doesn’t guarantee the dates are in ascending order and they’re presented in a non-ISO format).
Now you have the means to create separate Template Sensors for Day 1, Day 2, etc. Alternately, you can create a single Trigger-based Template Sensor that reports each day as a separate attribute. If you intend to track/graph the history of each day’s value then you will need to record them as separate Template Sensors (not as attributes of a single sensor).
When it comes to this kind of thing you got one of the best guys on the job, @123 is one of the best folks to help on HA. I’ve enjoyed seeing his solution!