RFC: Additional attribute for mower devices

[Jpsy]

RFC for a new, combined attribute for mower devices.
I especially ask @osks and @wijnandtop here for feedback.

Currently we have two attributes that both provide information about the current state of the mower: activity and last_error_code. The separation is somewhat artificial, as whenever there is a real error, activity will switch to NONE. Consider the following examples...

Example: Normal operation

Example: Error condition

In my automations I find myself again and again looking at both attributes to derive the full mower status. In the previous custom component of @wijnandtop we had that information condensed into a single data point - the state of the mower. Working on my automations I come to the conclusion that this was closer to reality than spreading the information over two attributes.

My suggestion is to add (!) a third attribute that will compile the information of both attributes into one. When activity != "NONE", the new attribute would copy activity. Otherwise it would contain last_error_code. The existing attributes would not be touched or removed. We would not lose anything and would gain a condensed data endpoint.

Does this make sense to you?
If you agree, what would be your proposals for the attribute name - e.g. activity_or_error, combined_status, status_unified, ...?

Please comment.
I would create the code and issue a PR.

[wijnandtop]

@Jpsy I'm really curious about all automations you have running since you're using quite some attributes of all entities :-)

I personally don't have any automations yet relying on these attributes.

As far as I remember I didn't condense any data into one datafield, but there are quite some differences between the api used by the official app at the time I did the reverse engineering. There was even data available which isn't in the official API.

I do see the value of this commodity attribute, on the other hand maybe keep the implementation "pure" and create a "virtual sensor" in HASS.

Bottom line, no strong preference from my side.

[osks]

I think it makes sense, but I haven't thought too much about it. Perhaps just call it status?

Could you open an issue in the new repository (py-smart-gardena/hass-gardena-smart-system) and continue there please?

[Jpsy]

py-smart-gardena/hass-gardena-smart-system#13

So this issue can be closed.