Use of single entity with attributes vs multiple entities without attributes

Development
1

Hello all,

I am currently implementing a new component for integrating Strava analytics into HA:
http://github.com/home-assistant/home-assistant/pull/22151

I am facing a decision which I would like to open to the community.
Strava offers lots of details about activities, clubs, gear and athletes.
My current approach create 4 new sensors:

  • StravaAthleteDetailsSensor
  • StravaLastActivitySensor
  • StravaClubSensor
  • StravaGearSensor

The configuration of these sensors looks like this:

sensors:
  platform: strava
  athlete: me
  fields:
    - max_heartrate
    - weight
  
  platform: strava
  club: 12312412
  fields:
    - member_count

It will create two new sensors of type StravaAthleteSensor and one sensor of type StravaClubSensor. The state property of these sensors is selected by the fields setting.

But this can create quite a lot of sensors. I was considering to change this behaviour by moving all the details into device_state_attributes. This would result in two sensors:

  • 1x StravaAthleteSensor with two attributes max_heartrate and weight.
  • 2x StravaClubSensor with one attribute member_count

But which value should we assign the state attribute in this case?

Do you prefer to have a single entity with a more or less meaningless state, and many attributes describing the actual details.

2

Came here from github as I’ve been watching the PR.

I think lots of sensors is fine but isn’t this easier for people as well? For example if you had them all in device state attributes wouldn’t the user need to create template sensors to view this in the UI?

What is wrong with just having include / exclude lists so users could reduce the number of sensors if they so desired right? This is probably a question for architecture

3

Hi,
I don’t know the API but, how is the data retrieved?
If choosing to have only one sensor with more attributes is it possible to get the information in one shot?
Is the number of requests to the Strava API something we have to worry about?
Are there any limits defined?

I like the way the items are shown in the Integration Panel where each device lists all the available attributes. So yes, I am for the above proposed approach.

Thank you for the involvement.

4

We poll all attributes for one entity (Athlete, Club, Gear or Activity) with a single request. Multiple entities cause multiple requests. At the moment we cache all attributes in separate Python “model” classes so that multiple HA sensors can use the same cached data.

yes.

There are limits. However with reasonable polling intervals, these won’t be exhausted by normal users.

Thanks for the feedback!

5

Unfortunately yes. This is also the main reason why I have not used the device state attributes yet.

6

In my opinion this depends on what those attributes are. The HomeMatic component adds attributes like the RSSI or battery state. Not everybody needs them, so creating dedicated entities would just bloat everything. With attributes users can choose if they want to make use of the data or not.
But of course there may be values that are useful in any case. Those I would see as candidates for dedicated entities.

7

I vote sensors then.

Maybe a combination of both the common data points as sensors you can include/exclude and dump everything in a sensor for each model. I mean I’m not too sure how many people would want the average temperature of there last ride for example but I bet they’d probably want the last rides miles as a sensor etc but if its in device state attributes they can get it.

8

I’m currently working on a hacky flask app for displaying my “This week” km totals in Hass, so a templating sensor approach would be welcome for user who want to process the sensor data further. A include/exclude paradigm would please the “i really need the average temperature of my last three rides on odd tuesdays” crowd :slight_smile: as well as the just give me the number for my last ride people.