Make Sequences be entities

[luixal]

Is your feature request related to a problem? Please describe.
When working in a dashboard, if you want to show and control your sequences, it's a lot of work as you have to get data from the attribute in the controller entity. This can't be done without hacking a little bit or using cards like custom:button-card.

Describe the solution you'd like
Make sequences be an entity, just like zones. That way, it's state and info could much easies accessed.

Describe alternatives you've considered
Using templates and custom button-card using the controller as entity just for grabbing sequence info, but you got a lot of unnecessary information and long code just to get some values.

Additional context
Add any other context or screenshots about the feature request here.

[rgc99]

This has been an idea for some time. It would make accessing parts of the sequences a bit easier. Getting to nested sequence zones within the sequence would still require some effort.
What values are you looking for, give me a list as a starting point. These would be presented as attributes on the entities.

[luixal]

Right now, I'm using the info from the controller entity attributes in my sequence card. I'll comment below the fields I use/consider important to have:

  - index: 0
    name: Diario # important
    enabled: true # important
    suspended: null # important
    status: 'off' # important and could replace the enabled and suspended fields
    icon: mdi:stop-circle-outline # important
    start: '2023-10-18T22:00:00+02:00' # important, but I would rename it to match zones field next_start (see below)
    duration: 2856 # important
    adjustment: '%85.0' # important
    schedule:
      index: 1
      name: Tarde
    zones: # i only use this to show the number of zones that run on this sequence.
      - index: 0
        enabled: true
        suspended: null
        status: 'off'
        icon: mdi:stop-circle-outline
        duration: 510
        adjustment: ''
        zone_ids:
          - '1'
     - index: 1
       ...

In addition to those fields, I will add these:

• current_zone: zone that is running now
• next_zone: zone that is going to run next
• percent_complete: just the same from the controller or zone

Also, taken from zones, for consistency:

• next_name
• next_duration
• next_start

Also, would you change services to match the behaviour of zones? This is, i.e manual_run. To manual run a zone I call the service using zone entity as a param, but to manual run a sequence I have to use the controller entity and the sequence index as a param. I guess this was because sequences don't have an entity, would that work the same way as zones with this change?

What do you think?

Thanks!

[rgc99]

Thanks for the feedback, it helps to know what you are looking for. There has to be some ground work done to position sequences more as a queue like zones and controllers. It does it at the moment but a bit expensive.

I would expect to support services as you suggest, but not perhaps in the first cut. At present service calls that operate on sequences go through the controller but this would be shifted to the sequence entity.

[luixal]

Here in Spain winter is coming so I already disable irrigation, but I can test new versions as it wouldn't had an impact in maintenance, just let me know in this issue or open a discussion :)

Services issue is the least important thing, it's just about consistency between zones and sequences once they both are entities.

Thanks!

[rgc99]

The coding is complete for sequence entities but no support for services. Please install from repository and review.

Some discussion about attributes is required. Sequences are a list of sequence elements. Each element represents one or more physical zones with additional attributes like duration, delay, repeat etc. Most attributes make sense and are implemented; index, enabled, suspended, status, adjustment, schedule_count, current_start, next_start. Some questions about zone_count, current_zone, next_zone and should they be the sequence element or the physical zone. There could be need for additional attributes.

Further questions and thoughts:
time_remaining & percent_complete. Should this be the overall sequence or the active element? Perhaps both.
current_duration & next_duration. As above.
What about the state, icon, status, adjustment, duration etc. of the active element?

Most cards can display attributes but they lack the ability to easily access nested attributes so they have to be flattened out. Perhaps a set of attributes that relate to the active element - which by the way, can be none in the case of the delay between elements - represented by the pause in the sequence status. Maybe the attributes could be prefixed with active_. active_duration, active_time_remaining. Is next element details required in which case another set is required. Maybe have current_element_ and next_element_ prefixes. This would create current_element_duration, next_element_duration etc. I am also happy to entertain some prefix other than element.

[luixal]

Hi,

My "rule of thumb" here would be the physical logical domain of the data. I'll explain my pov along your post.

The coding is complete for sequence entities but no support for services. Please install from repository and review.

I guess you migrate the info blow to the new entities, but services are to be called on the controller entity. Not bad on my side, although it would be nice to have.

Some discussion about attributes is required. Sequences are a list of sequence elements. Each element represents one or more physical zones with additional attributes like duration, delay, repeat etc. Most attributes make sense and are implemented; index, enabled, suspended, status, adjustment, schedule_count, current_start, next_start.

Totally agree.

Some questions about zone_count, current_zone, next_zone and should they be the sequence element or the physical zone. There could be need for additional attributes.

Not sure if I understand, but I consider zone_count, current_zone and next_zone attributes of the sequence entity. Totally.

Further questions and thoughts: time_remaining & percent_complete. Should this be the overall sequence or the active element? Perhaps both. current_duration & next_duration. As above. What about the state, icon, status, adjustment, duration etc. of the active element?

Both info (sequence overall and current zone) make sense for me. If I'm making a card to show the sequence status, I would like to show overall info about the sequence and the current zone. Main problem I see here is about duplicating info in case it affects HA performance too much.

Most cards can display attributes but they lack the ability to easily access nested attributes so they have to be flattened out. Perhaps a set of attributes that relate to the active element - which by the way, can be none in the case of the delay between elements - represented by the pause in the sequence status. Maybe the attributes could be prefixed with active_. active_duration, active_time_remaining. Is next element details required in which case another set is required. Maybe have current_element_ and next_element_ prefixes. This would create current_element_duration, next_element_duration etc. I am also happy to entertain some prefix other than element.

Not sure about the nested problem, as this cards are really custom and quite complex, I always end up using custom:button-card and i can access all information from there, but I see the point about having it flattened out. Much simpler and opens a wider palette of cards you can use.

About the prefixes, I guess you would have:

• no prefix, current_duration: about the sequence overall
• current_zone_duration: about the running zone
• next_zone_duration: about the next running zone

Funny thing, I hit the delay issue when making a card for a senquence and was quite annoying. The pause status is a nice move but, if a sequence can be manually paused (not sure about this), maybe a delayed status would be better as you can tell apart (different color, status icon, etc.).