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 #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

[billchurch]

I'm down for this as well. Using the custom component and seems to work well.

[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.

[MTrab]

Any news on this?

[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
• _operatinghours : a number of hours the mower has been mowing from the beginnning
• error : a string representing the current error
• _lasterror : a string representing the last error
• model : a string representing the model of the mower
• _linklevel : a number representing the connection quality or level

As services, i would see :

• _startmowing : to start immediately the mowing
• _startschedule : to enable scheduled operations
• _park_until_nextschedule : to park the mower and wait for next schedule
• _park_and_disableschedule : 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.
• _operatinghours : this should be a separate timestamp sensor entity.
• error : this should be a separate sensor entity.
• _lasterror : this should be a separate sensor entity.
• model : this is already part of the common device info entity property.
• _linklevel : 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.

[grm]

Ok, i'll do some checks and rework the split asap !

[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)...

[thomasloven]

Maybe also consider edge cutting as a service? See #267.

[grm]

Hello,

Thanks everyone for your feedback !

Here is a second version of the possible entities/services

Entity base (already available):

• name : name of the mower

Entity common (already available):

• model : the model of the mower

Entity mower :

• activity : represents what is currently doing the mower, could be on of these :
  • ERROR : the mower is in error and need human intervention
  • PAUSED: the mower is pause away from the dock, no activity will be resumed .. (I am not sur this one does not conflict with error ? what do you think ?)
  • MOWING : the mower is currently mowing
  • PARKED_WAITING_SCHEDULE: the mower is parked and waiting for next schedule start
  • PARKED_SCHEDULE_DISABLED : the mower is parked and the schedule is disabled

Entity : usage entity (timestamp maybe ?)

• operating_hours : a number of hours the mower has been mowing from the beginning

Entity : error entity (maybe this already exists)

• error : a string representing the current error
• last_error : a string representing the last error

Entity: signal strength (maybe this already exists)

• link_level : a number representing the connection quality or level

Entity: Rechargeable (or battery using the existing entity - have to check what already exists)

• charging : a number representing the battery level
• battery level : the battery level of the lawn

Entity: Updatable (maybe this already exists)

• update_available : an update is available for the integration/device

As services, this is what emerges :

• start_mowing : start mowing
• dock : sends the command to dock the mower
• start_schedule : enable scheduling
• pause : Pause the mowing process, either by parking it or not
• disable_schedule : disable the scheduling process

Regarding other entities, I have the feeling they are specific to Bosch ones : Percentage Lawn Mowed, a X and Y position Regarding edge cutting, I am not sure any solution is using it .

For the last two point (entities and edge cutting), does someone has seen any of these functionalities on mowers ? (in order to see if we should include them or not ?)

What do you think about it ?

Jérémie

[MTrab]

I'm the maintainer of the landroid_cloud integration in HACS - Worx Landroids have edge cutting routines, but I havent been able to find the right trigger for this yet.

Other than that, it's great that someone is taking on this issue :) Been thinking of it myself, but haven't had the time to start yet.

[grm]

Thx for the support !

By trigger, you mean the api call/endpoint ? is it available in public API ? ot only through their own application ?

For gardena, there is a public API and a one other dedicated to their front - which is so bad because the one dedicated to their front has much more functionnality !

Jérémie

[MTrab]

There is no public api for Landroids ;) All is by sniffing the traffic ;) But is't only recent, and apparently only on newer models, you are able to trigger the edge routine from the app. So I'm trying to see if I can get access to an account with a newer model than my own.

[eavanvalkenburg]

@grm do you already have a branch you're working on for this? and if not @MartinHjelmare which entity would be a good template to start from, probably Vacuum is closest?

[grm]

Hello,

Yes i do have a local branch for now ! I will push it asap !

Jeremie

Le mer. 14 juil. 2021 à 15:26, Eduard van Valkenburg < @.***> a écrit :

@grm https://github.com/grm do you already have a branch you're working on for this? and if not @MartinHjelmare https://github.com/MartinHjelmare which entity would be a good template to start from, probably Vacuum is closest?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/architecture/issues/40#issuecomment-879890691, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAARGI5VBNBYKFMWGSON72TTXWGBDANCNFSM4FFWO5ZA .

[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.

[eikowagenknecht]

Hello, Yes i do have a local branch for now ! I will push it asap

@grm Any news on this? I'm using the gardena integration myself and while the vacuum device works fine I'd really love to see a real lawnmower device type!

[crazyfx1]

What is the status on this? Spring is here and the mower is already working in my garden :)

If we don't get the code from @grm maybe we have to start from scratch to get a first proposal online in a PR to discuss further.

[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.
• _lasterror: this should be a separate sensor entity.
• _operatinghours: this should be a separate timestamp sensor entity.
• _linklevel: this should be a separate signal strength sensor entity.
• measurements like _batterylevel, _percentage_lawnmowed etc: measurements should be separate sensor entities with appropriate device class set if a device class is available.

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_schedule_enabled: the mower is docked and waiting for next schedule start
  • docked_schedule_disabled: the mower is docked and the schedule is disabled
• Mower entity services:
  • start_mowing
  • dock
  • pause - this stops the mower where it is, for instance if you notice the lawn is not clear
  • enable_schedule
  • disable_schedule

[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.

[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.