Allow sub-object in data selector

[Veejer]

Suppose I have an attribute named: my_data. My data is an object that contains another object named: more_data. Inside more_data is a field named: my_field. The problem is that the data selector can only access the top object as in:
data: my_field

I can use the modify selector to access the rest of the object as in:
modify: x.more_data.my_field.

However this means that I cannot use the fmt selector and would therefore have to add additional code in the modify selector to format the data.

So, I propose that the data selector be able to use dotted notation to access the correct field. For example:
data: my_data.more_data.my_field

This allows me to use the fmt option if I choose or I can continue to use the modify option to format the x value.
The modification I propose should be flexible enough to allow any number of sub-levels.
This modification should only apply to attributes and not to any other entity key.

[jata1]

Just checking in to see if this feature has been merged and released. The documentation seems to suggest it has but I can't get it to work. Using modify: x.blar instead but keen to change to this once released.

[ildar170975]

Have you tried smth like this?

      - name: long_state -> subattr
        data: long_state
        modify: >-
          x.subattr

[jata1]

Thanks. Yes that is what I currently do and it works fine but thought this solution was better and I would like to avoid using modify: x.subattr

[jata1]

In the docs (data column examples), this is included
"When accessing attributes, sometimes an attribute object will itself contain objects. In that case, you can access the lower object using dotted notation. eg: object1.object2.field1"

[ildar170975]

Hmmm, strange, I think I never used this (at least do not remember).
This does not work:

[jata1]

Yep. I found the same. I think this will be a great addition if/when it gets implemented/released.

I have an entity for connected devices on my LAN that uses nested objects/attributes. So it would literally require - object1.object2.field1

It is working fine using modify so I was just interested to see if I could get it working...

Thanks for helping/discussing this with me :-)

[jata1]

one more question. See below for attributes for an entity. For the 'actions' attribute, I want to return the 'data' value. How would I do this?

I have tried the following...

`weekdays:

• workday
  timeslots:
• 00:00:00 - 04:00:00
• 04:00:00 - 05:30:00
• 05:30:00 - 19:00:00
• 19:00:00 - 22:30:00
• 22:30:00 - 00:00:00
  entities:
• climate.gas_heater_thermostat
  actions:
• service: climate.set_preset_mode
  data:
  preset_mode: sleep
• service: climate.set_preset_mode
  data:
  preset_mode: activity
• service: climate.set_preset_mode
  data:
  preset_mode: home
• service: climate.set_preset_mode
  data:
  preset_mode: comfort
• service: climate.set_preset_mode
  data:
  preset_mode: activity
  current_slot: 2
  next_slot: 3
  next_trigger: '2023-07-10T19:00:00+10:00'
  tags: []
  icon: mdi:calendar-clock
  friendly_name: Gas Heater Weekdays`

[jata1]

Please ignore last post - got it working.

[ildar170975]

@jata1
Here is a thread for this card, some solutions provided:
https://community.home-assistant.io/t/flex-table-card/461173

[daringer]

mmmh, for me the following works e.g. for weather:

type: custom:flex-table-card
title: Test-case nested attributes
entities:
  include: weather.*
columns:
  - data: name
  - data: forecast.0.condition

the 0 makes somehow sense, as forcast contains multiple items (objects) with condition ... that's kind of very explicit - not optimal ...

[ildar170975]

@daringer
Assume some attribute is a list (like in the weather entity):

Noticed this works:

          - name: value_1
            data: list_attribute.1.value_1

and it creates ONE row for a particular array's element (as it is expected):

But I cannot extract data from all array's elements like:

          - name: value_1
            data: list_attribute.value_1

Have to use modify then:

  - name: value_1
    data: list_attribute
    modify: x.value_1

P.S. As for me, I am rather satisfied with the current behaviour.