search

osks / hass-gardena-smart-system

Moved to https://github.com/py-smart-gardena/hass-gardena-smart-system
Apache License 2.0
4 stars 2 forks source link

RFC: Additional attribute for mower devices #18

Open Jpsy opened 4 years ago

Jpsy commented 4 years ago

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 image

Example: Error condition image

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

https://github.com/py-smart-gardena/hass-gardena-smart-system/pull/13

So this issue can be closed.