@ShadowFist Good spot. I wasn’t aware of this setting. Perhaps I had it enabled previously. This brings back the attributes for the entity as they used to be. Thanks for making me aware of this.
@tom_l I understand, and it makes sense to move away from attributes that should be their own sensors. The issue really is how data is forwarded on to an InfluxDB database. With the attributes attached to the entity as I want to have, the InfluxDB integration inserts these attributes as fields in the same measurement, which is nice. So it looks like this in the database:
> select * from RHTsensors where time>now()-5m
name: RHTsensors
time battery domain entity_id friendly_name host humidity linkquality temperature value voltage
---- ------- ------ --------- ------------- ---- -------- ----------- ----------- ----- -------
1731016532160275000 100 sensor rht_sensor_kitchen_temperature RHT Sensor Temperature (Kitchen) hass 87.61 69 18.51 18.51 3000
1731016563039998000 79.5 sensor rht_sensor_lounge_temperature RHT Sensor Temperature (Lounge) hass 79.08 174 16.32 16.32 2900
(The only downside here is that the temperature is stored twice in the database - once from the temperature attribute, and once from the entity state and appears under the field name “value”. As far as I’m aware, there is no way to prevent this “value” being inserted, and only inserting the attributes).
You can also do things like
> select temperature from RHTsensors where time>now()-5m group by friendly_name
which will return all the temperatures associated with the RHT sensors.
Using the “group by” in this way wouldn’t work if we piled all temperature data on our system into a measurement called “temperature”. It could return all kinds of things unrelated (e.g CPU temperatures, which have nothing to room temperatures).
Ultimately, it is nice to have multiple fields associated with each entity. At the moment, it doesn’t seem possible with the InfluxDB integration to specify multiple fields. You only get the entity’s state, which always appears as a field called “value”. So using the attributes is a workaround.
The reason it makes sense to have temperature/humidity/battery etc as multiple fields in the same measurement is because the sensor physically acquired the data at the same time, and transmitted it all at once. So the values should all share a timestamp and be tied together.