I’m trying to create a table with temperature readings at specific times throughout the day.
So for example:
---------------------------------- 7am----10am----1pm
----------------------Sensor 1----20------21-------18
----------------------Sensor 2----25------30-------27
I use multiple command line sensors to retrieve a value from the default SQLite database(utilizing SQL queries in python and transforming that data to floats).
Now every sensor gives me one reading for a specific time, so the first sensor gives the value at 7 am, the second gives the value at 10 am, etc…
How can I display different entities’ values in each column of the flex table card?
@Ildar_Gabdullin thanks for answering so quickly.
OK, the one-row=one-entity policy is what I feared.
So how do I define a template sensor with all the necessary attributes?
If I understood you correctly, I need a new entity in my database with one collum for each value at a specific time.
So how can I do that and how will I feed it values?
Will the same entity be usable with other dashboard cards?
Any links to guides I can follow?
I am using the flex-card to show some stock data (yahoo finance integration).
Is there a way to make a column data (lets say the stock price) having the url, embedded (https://finance.yahoo.com/quote/AAPL), so when clicking on the cell value, you go to the web site?
If yes, how to I code this, https://finance.yahoo.com/quote/ and then adding the value to the url?
Yup, the flex-table-card is a bit tricky to set up, particularly with sensor attributes. I have several tables and am finally getting the hang of this (rather nice) card. If anything is wrong, then all you get is a pink square with an error message…
I have manipulated my data into different sensor arrays, so my names will not match yours, however, the following works for me:
Sensor - octopus_agile_prices (which has an attribute)
Attribute - array (which is an array of objects)
Start time - from (which is the Octopus valid_from)
Export value - export (which is the Octopus export price - I have combined both import and export into one array using JSONata, but that is another story…)
The entities: include should be the sensor (at the top level only).
This makes the card look at the sensor. Then for each column we want, we set the data as the attribute name, which makes the column look at the attribute.
Then for the value, we need the ‘modify’ operator to pull out the field from the attribute, hence ‘x.field_name’ where x represents the entity attribute, and the field name is the bit we want.
The fact that the (final) data is an array causes the card to display rows based on each value in the array.
(errors and omission excepted)
EDITED extra ‘columns’ was an error!
WARNING - the ‘modify’ function calls JavaScript eval() as part of what it does, and this can be a security issue, hence the use of this feature is avoided by many.
Now I am curious…
Since you specified only one “sensor.octopus_outgoing” sensor, then only one row is expected to present in the table - how do you get many rows? Also, a person above provided a screenshot from “Dev tools → state” where there is one “results” attribute which is an array. And in your example you specified an “array” attribute. - I see that you edited the code, it differs from a screenshot.
Since your code is a GUESS not a really working code - I also doubt that it will work.
Can anyone propose me a sensor with a similar structure?
I need it for testing…
OMG, you are right - the code works.
I used an OpenWeatherMap sensor:
The strangest thing for me is that:
– there is only ONE sensor is specified - so only ONE row is expected;
– the attribute “forecast” is an array - so a “forecast[2].condition” syntax is supposed to be used:
My code certainly works for me, and yes I have spent a lot of time experimenting with this card to try and figure out how it all works.
My sensor attribute is an array, and rather obviously I called it ‘array’ because it is…
The tricky part about this card is the way it works out the 1 entity = 1 row OR multiple values = multiple rows (same entity - one value per row).
If you have a sensor with one value, then that ends up in 1 row. The columns then become holders for different sensor values.
If you have a sensor.attribute with one value, then that ends up in 1 row. The columns are again for different sensor or sensor.attribute values.
If you have a sensor.attribute that is an array, then that ends up with each row=1 item from the array, but the card cannot get at the data directly, hence the use of the modify function.
The code behind the card seems to cast the card into one-row / multiple-rows per entity based on the first item it sees, and then you have to work with the card based on that. Takes a little bit of thought and a lot of experimentation to get the best from this.
Hoorah! Yes that works! Although I had to remove the second columns: in your suggested code. And your explanation is really helpful in aiding my understanding, thank you.