Make status titles available as state attribute on NibeSystemSensor

[jelgblad]

With this change a user will be able to access a list of heat pump status titles in the statuses attribute on the state of all NibeSystemSensor-entities.

For example a template string like this {{ state_attr('sensor.last_activity', 'statuses') }} will return the following list:

[
  "Heating Medium Pump",
  "Price Of Electricity",
  "Ventilation",
  "Heating"
]

I'm using this to log compressor-status with a template binary_sensor like this:

- binary_sensor:
    - name: "Compressor"
      unique_id: "nibe_status_compressor"
      device_class: running
      state: "{{ 'Compressor' in state_attr('sensor.last_activity', 'statuses') }}"
  trigger:
    - platform: event
      event_type: event_template_reloaded
    - platform: state
      entity_id:
        - sensor.last_activity

Would also be useful if one wanted to replicate the status icons on their NIBE-system in HomeAssistant, to get a glance at what the unit is doing right now, without having to open the NIBE Uplink app.

As previously stated, I'm currently using this in my current system with great success.

[elupus]

This adds it to all system sensors, that is wrong. Add a new system sensor description, and with a state fn grabbing the first status. Then you can extend the description structure with a new optional function grabbing extra attributes.

[jelgblad]

My plan was to go that route initially.
But since these "statuses" are pretty dynamic in nature (they will depend on your unit and settings) its hard to pin down what would be a suitable status to use as main state of the sensor.
My thoughts are to create a sensor called something like "status available" and let the state be TRUE if the statuses-array has any element and FALSE otherwise, then attach the array itself be an attribute to that state just like it is right now.

I'll look into it and then we'll see what you think.

[elupus]

The first entry in the list is the currently prioriatiszed action. So that make sense as state.

[jelgblad]

Well if the intended functionality is for the statuses to be represented in a stable order, then there might be a bug in your code.
NibeSystem.update_statuses() at line #335 here defines statuses as a Set.

Sets in Python are unordered by design and therefore are not guaranteed to be iterated in the same order they where added (Python docs).

Whether this is a bug or not depends on if something else relies on the order of statuses, but it would certainly be a bug if I continued with the suggested solution to set the state of this new sensor.

[elupus]

Well all statuses är "wanted" actions. But yes that would pose a problem. I think i made this this way since if you have multiple compressors (unlikely) two things could be active at the same time.

So im not sure what to do here ;)

[jelgblad]

Would the solution in my latest commit suffice? (Files changed)

I'm totally with you to not bloat every system sensor with the statuses-attribute, and that has now been solved.
The has status sensor will probably not be useful for anything else, but it's a reliable way to access the status attributes.

The primary objective with this PR is to get access the list of statuses in HA. The sensor state isn't really that important. But i think it should be something stable, and not whatever entry in the statuses-set happened to be accessed first.

[mversluijs]

@jelgblad, it's a welcome feature!

[elupus]

Could you make it a count value instead. I len(statuses) and call it status_count.

[jelgblad]

Done!
The status count-sensor now shows the number of statuses available together with the statuses-attribute wich contains all the status titles.

[elupus]

Thanks