New entity for lawn mowing robots

[yeah]

Last year, I've written a component for Husqvarna lawn mowing robots and from the forum responses it seems there's quite some interest in it.

The code can be inspected on my repo fork.

For my purpose, I have used the existing vacuum entity. It fits nicely as lawn mowing robots behave pretty much the same way as vacuum robots.

However, the naming doesn't fit, so I'd like to spark a discussing about what should be done. Two options come to mind:

1. Create a new lawn_mower component duplicating most of the vacuum code
2. Rename vacuum to something more generic like something along the lines of robot or roaming_bot (could be included in existing discussion in Architectural review of vacuum entity #29)

I'm happy to try implementing either after we have a consensus about the approach to take. It will probably make sense to wait for the outcome of #29 as well if we're going with option 1.

Thanks for your feedback!

[michaelarnauts]

robot seems like a good name for these things imo.

[balloob]

I think that it should be a new component. Code can be copy pasted from the vacuum component if needed. Just like lights and switches are very similar (turn on/off, dimmer/brightness) yet are different components.

[wijnandtop]

+1 on the generic robot on this, working on supporting gardena sileno mower (still a custom_component though)

Code: https://github.com/wijnandtop/home_assistant_gardena

[colinfrei]

I'm working on a component for worx landroid mowers, and also thought it'd be good to have a separate component, so +1.

[eavanvalkenburg]

I've been working on a Bosch Indego lawn mower component with some folks, so would love to have a entity type for that as well!

[MartinHjelmare]

The way forward here is a new separate entity integration named lawn_mower.

The next step before someone can start implementing it is to define, here in this issue, the services and entity state properties needed. Please limit them to only actuator related things. Sensor measurements like battery level should not be part of the lawn_mower integration but separate sensor entities.

[grm]

Hello,

I am the maintainer of the py-smart-gardena library (https://github.com/py-smart-gardena/py-smart-gardena) and hass-gardena-smart-system (https://github.com/py-smart-gardena/hass-gardena-smart-system) integration.

I am open to develop the entity, that is something i thought about for some time now.

For a first version, these are the minimal info i would include.

Here are the entity state i see for such a device :

• name: the name of the mower
• activity : represents what is currently doing the mower, could be on of these : CHARGING, STOPPED, MOWING, PARKED_WAITING_SCHEDULE, PARKED_SCHEDULE_DISABLED, UNAVAILABLE
• operating_hours : a number of hours the mower has been mowing from the beginnning
• error : a string representing the current error
• last_error : a string representing the last error
• model : a string representing the model of the mower
• link_level : a number representing the connection quality or level

As services, i would see :

• start_mowing : to start immediately the mowing
• start_schedule : to enable scheduled operations
• park_until_next_schedule : to park the mower and wait for next schedule
• park_and_disable_schedule : to park the mower and disable schedule

I am not sure it is the best place to discuss about these, but what is your opinion about it ?

Thanks,
Jérémie

[MartinHjelmare]

• name: this is part of the base Entity class and nothing specific for the lawn mover entity.
• activity : this should represent the main state of the lawn mover entity. CHARGING, STOPPED, MOWING, PARKED_WAITING_SCHEDULE, PARKED_SCHEDULE_DISABLED sound ok. UNAVAILABLE is already set by using the available Entity property.
• operating_hours : this should be a separate timestamp sensor entity.
• error : this should be a separate sensor entity.
• last_error : this should be a separate sensor entity.
• model : this is already part of the common device info entity property.
• link_level : this should be a separate signal strength sensor entity.

The services sound ok.

Please do some research among different brands and see what support there is for these services and states.

[eavanvalkenburg]

The terminology that mine uses (Bosch platform) is Docked (both for the state and the command) rather than parked, but either works, I also have sensors for Next Scheduled Mow, which I find very useful reminding me of making sure the lawn is clear.

I think the park_and_disable_schedule might be a bit too specific, on Bosch those are completely separate commands. So I think the services should:

• Mow/start_mowing
• Dock/Park
• Pause - this stops the mower where it is, for instance if you notice the lawn is not clear
• set_schedule/start_schedule
• disable_schedule

In terms of sensors, I also have Percentage Lawn Mowed, Battery, a X and Y position, Update Available, next to the ones that are mentioned.

Would love to also work on the implementation @grm

[nelsonblaha]

Husqvarna has the 'paused' concept as well. I figured @grm's "STOPPED" state covers it.

"DOCKED" might be a superior choice of term to "PARKED" since it clarifies that charging is occurring, whatever individual brands opt to call it. It might be well to choose PAUSED over STOPPED when stopped away from the base for the same reason, but it just could be my Husqvarna bias suggesting it's clearer.

[Jc2k]

For other entities with batteries, the sensor, battery level and battery charging state are all seperate entities now. So charging should probably be a seperate binary_sensor too. There is already a device class for it.

[eavanvalkenburg]

Yeah that makes sense @Jc2k!

I figured @grm's "STOPPED" state covers it.
There is a difference I think between the state STOPPED and the service STOP, for the state I'm indeed fine STOPPED or Paused, but the service I think there is a slight difference between paused and stopped (just like in music)...

[donoghdb]

@grm i use the ha-automower for my Automower. I found the information on the leaving the dock "Leaving charging station" and "Going to charging station" very handy to see what is happening. It would be good if some of this information is included. Also, i have my own script that mirrors the husqurvana app, where i park the mower for a time period and then start it again.

[MartinHjelmare]

To summarize this topic, here's how the new integration should be designed:

New integration name: lawn_mower

How different features should be implemented

• name: this is part of the base Entity class and nothing specific for the lawn mover entity.
• activity: this should represent the main state of the lawn mover entity. If the mower is unavailable that's set by using the available Entity property.
• model: this is already part of the common device info entity property.
• error: this should be a separate sensor entity.
• last_error: this should be a separate sensor entity.
• operating_hours: this should be a separate timestamp sensor entity.
• link_level: this should be a separate signal strength sensor entity.
• measurements like battery_level, percentage_lawn_mowed etc: measurements should be separate sensor entities with appropriate device class set if a device class is available.
• enabling and disabling the lawn mower schedule should be represented by a separate switch entity per schedule.

Entity design

• Entity class name: LawnMowerEntity

• The LawnMowerEntity base should return the activity attribute as state.

• Mower entity specific attributes:

  • activity: a string enum, with the following attributes:
    • error: the mower is in error and needs human intervention
    • paused: the mower is paused away from the dock, no activity will be resumed
    • mowing: the mower is currently mowing
    • docked: the mower is docked

• Mower entity services:

  • start_mowing
  • dock
  • pause - this stops the mower where it is, for instance if you notice the lawn is not clear

[thomasloven]

Is activity not just state?

[MartinHjelmare]

Yes. The LawnMowerEntity base should return activity as state. Platforms should not implement state as that is guarded by the model design.

[mikey0000]

If no one is actively working on this I'm going to make a start on it. Happy to help out if someone else is working on it. Previous PR branch is gone so can't start there, though likely not a good place to start anyway....

[MartinHjelmare]

Please go ahead. 👍

[mikey0000]

made a start today, just want to note, the Luba i've reverse engineered, supports multiple schedules/scheduling also known as job plans, start mowing should be fine with the edge mode, zones and so on. Eventually would want to expose each schedule somehow. ideally can setup multiple plans and start mowing dependant on a plan, anyway late night thoughts ;-)

Will open draft in a couple days time I think.

[langestefan]

please also consider OpenMower :)

[MartinHjelmare]

Further features that need services can be implemented per integration. We start small with the most common features in the base integration. If we see that many integrations support a specific feature we can discuss to add it later.

[mikey0000]

@MartinHjelmare I noted that strEnum is available in python 11 but not 10, advice please as strEnum is a good choice for the activity enum. Thanks

[mikey0000]

So most things are ready for review, not sure entirely what I might need to additionally do for frontend but I'm going to keep working away at that one. Draft PR open on that one as I work away at it.

[MartinHjelmare]

The core team discussed the new lawnmower entity this week and we suggest we break out the enabling and disabling of the schedule to a switch entity. What do you think?

I've also asked the frontend team to make a suggestion for the frontend design.

[mikey0000]

Replying up here to keep it cleaner, I agree. My understanding this would then change the following.

Activity DOCKED_SCHEDULE_ENABLED and DOCKED_SCHEDULE_DISABLED become single DOCKED

Services for enable and disable are removed in favour of separate switch entity.

Can you please update the answer to reflect this?

[MartinHjelmare]

I've updated the selected answer. 👍

[mikey0000]

Lawn mower entity Pull requests:
Link to core integration pull request: home-assistant/core#93623
Link to brands pull request: home-assistant/brands#4561
Link to frontend pull request: home-assistant/frontend#17558
Link to documentation pull request: home-assistant/home-assistant.io#28546
Link to developer documentation pull request: home-assistant/developers.home-assistant#1875

[mikey0000]

As a simple switch yes I think I can agree with that. One small question though, how would we do configuration of a schedule/schedules in future? This would be a different command? So if we had multiple schedules, those would be multiple switches? (I don't take issue with this I actually think this would be a good thing) Just some initial thoughts. Thank you again for your help in this. 13/08/2023 6:58:48 pm Martin Hjelmare ***@***.***>:

…

The core team discussed the new lawnmower entity this week and we suggest we break out the enabling and disabling of the schedule to a switch entity. What do you think? I've also asked the frontend team to make a suggestion for the frontend design. — Reply to this email directly, view it on GitHub[#894 (reply in thread)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AALDOPKL3JRXQHV2W4B4LE3XVB3GXANCNFSM6AAAAAAYGVSZKE]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AALDOPJE67HUPTICR7XJUZDXVB3GXA5CNFSM6AAAAAAYGVSZKGWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAMZVUQ.gif]

[MartinHjelmare]

The schedule can probably be represented by a calendar entity.

[mikey0000]

What I imagine is once schedules are created this would be the case. enable/disable schedule switch entities which in turn has calendar entities for days/schedule + other entities for zones, mow heights and so on.

Creation of a schedule would just be a service yeah? Which would be unique to each mower anyway.

Just trying to forward think to what lawn mowers are becoming aka my Luba with multi-zone multi-schedule.

I'm really just brain dumping my thoughts. The one thing I personally want out of Home Assistant is to take over scheduling instead of relying on the lawn mowers scheduler as they tend to be quite dumb. I imagine these can be exposed per integration as services.

Can you please update the answer with this new change for enable/disable being a switch entity. I'm going to update all the Pull requests with it removed. Thanks

[MartinHjelmare]

Yes. Exposing a way for the user to add more than one schema per mower, if the mower supports more than one schema, can be done via a custom service for the integrations that support this.

[mikey0000]

Starting a discussion about "docking" being an activity state.
Luba supports this. Can others chime in with other mow bots that support it as well?
husqvarna_automower supports state_returning. (as supported by vacuum?)

[crazyfx1]

Gardena has the state "SEARCHING" as in "searching for the docking station".

[frenck]

I think we should start with the set now defined. Adding new states generally is a discussion on how many could support such a thing (which is, I think, not the moment right now).

We can always add stuff later on (removing things, however, is problematic).

../Frenck

[mikey0000]

All good with me, I overlooked that docking wasn't on the list and somehow never noticed. So wasn't intentional that it was left/added. MartinHjelmare FYI fixed now.

Perhaps we continue this discussion anyway and resolve it/decide on it and it can be added later if that is the decision?

[frenck]

Closing this architectural discussion, as the entity component has been merged and now part of Home Assistant.