Access json data at different levels in one REST sensor

Feature Requests
1

With this data:

{
"one_one": "1_1",
"one_two": "1_2",
"two": {
  "two_one": "2_1",
  "two_two": "2_2"
  }
}

You can’t get both the value of "one_one" and two_one": "2_1" as attributes of the same REST sensor. You can do something like this in sensor.yaml:

- platform: rest
  resource: http://WHATEVER
  name: SOME
  unique_id: sensor.some_sensor
  value_template: '{{ value_json.one_two }}'
  json_attributes:
    - one_one

or you can do

- platform: rest
  resource: http://WHATEVER
  name: SOME
  unique_id: sensor.some_sensor
  value_template: '{{ value_json.one_two }}'
  scan_interval: 3600
  json_attributes_path: "$.two" 
  json_attributes:
    - two_one

But you can’t get both into one sensor’s attributes without creating additional dummy sensors (and having to do that for more than just a few will REALLY clutter the states, and also make using the UI difficult, as suggestions when e.g., adding lovelace cards could be cluttered by many sensors with very similar names).

So, I would like request that you can either access by standard dot notifications, so:

- platform: rest
  resource: http://WHATEVER
  name: SOME
  unique_id: sensor.some_sensor
  value_template: '{{ value_json.one_two }}'
  json_attributes:
    - one_one
    - two.two_one

Or allow templating for json_attributes, or anything else that makes this possible.

2

Your request doesn’t make sense because you end up with the same result as if you just exposed the main attribute via json_attributes.

e.g.

- platform: rest
  resource: http://WHATEVER
  name: SOME
  unique_id: sensor.some_sensor
  value_template: '{{ value_json.one_two }}'
  json_attributes:
    - one_one
    - two.two_one

would require you to access the attribute via two.two_one, which is already what you would use if you used this instead (which is valid)

- platform: rest
  resource: http://WHATEVER
  name: SOME
  unique_id: sensor.some_sensor
  value_template: '{{ value_json.one_two }}'
  json_attributes:
    - one_one
    - two
3

If I’m understanding what you’re saying, then that way of doing it isn’t very useful in practice, when you have keys with a lot of (sometimes nested in several levels) data. If exposing two, as in your second example, then I’d have the dictionary:

{
  "two_one": "2_1",
  "two_two": "2_2"
}

in the attributes. In my case (I actually did try that before posting this), the nested attribute is one of about 40 associated with the top level key. So doing it this way gives me super long attributes in my sensor. If looking at the states page int he UI, I can barely fit the sensor on one page since it’s so long.

With the way of doing it I’m suggesting, the attribute would just be the 2-digit integer that I actually need.

I get that the data I want is present somewhere in that long dictionary of the attributes, but I don’t want the “mess” of all the stuff I don’t want/need being shown in the attributes. It makes it cumbersome to use certain aspects (such as scrolling through the states tab of Developer tools).

1 Like