Lights will not turn off on my roomba e5

[zaregg]

The problem

After enabling the roomba extension the lights on my roomba e5 wont turn off anymore. I have also tested disabling the integration, after which the lights went out.

What version of Home Assistant Core has the issue?

Home Assistant 2022.10.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

iRobot Roomba and Braava

Link to integration documentation on our website

https://www.home-assistant.io/integrations/roomba

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

There is an active issue about this topic on another repo [https://github.com/NickWaterton/Roomba980-Python/issues/43]()

[home-assistant[bot]]

Hey there @pschmitt, @cyr-ius, @shenxn, mind taking a look at this issue as it has been labeled with an integration (roomba) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

---

roomba documentation roomba source _{^{(message by IssueLinks)}}

[cdekesel]

Same behavior here with Roomba 675

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[lubricatedcactus]

did anyone find a solution to this? all my lights have been on for 3 months

[zaregg]

no i did not see a solution pop up

[B-Lourens]

My guess is that it's because of the "continious" connection setting' or the code behind it; it seems like it keeps the connection to the roomba and thus the roomba active (and thus the roomba). As soon as you de-select it in the integrations' configuration, the lights go out but you also lose the option to control it. I haven't looked at the code, but if possible a polling call every 'user config> could be a better solution.

[lit-af]

Can confirm that this issue is still present with Roomba e5 and Home Assistant 2023.5.4

[arrrghhh]

Issue is still present, Roomba 675 and Home Assistant 2023.7.2

[sassetto]

Also in 2023.9.2 :-(

[knuser666]

Still lights on 🙁

[lubricatedcactus]

On the plus side after being on nonstop for a year, the lights have started burning out on one of my E5's 😂

[asheroto]

Sure enough, if you disable the device in HA, start cleaning, return home, the lights go off after half a minute or so.

Roomba 600 series

[mr-brains]

I used tape, no more lights on my roomba :)

[PA-64]

Same problem here, Rumba series 600. Light always on. HA 2023.11.03

[qdrien]

Came across this issue while trying to solve the same problem so I figured I might share the outcome.

All I actually needed was the ability to start cleaning sessions every now and then. I did not really care about continuous updates on battery levels and the likes, so simply turning the integration off/on was an acceptable solution to me as long as it could be done automatically (so that I do not have to actually do it manually in the HA integrations settings before and after each cleaning session).

If that approach is of interest to anyone passing by, I installed Spook (available through HACS) which among many other things adds actions (as in stuff you can use in automations) to enable or disable integrations. This means a cleaning automation with a Roomba vacuum may now look like so: Enable Roomba integration -> Wait a bit -> Run a usual cleaning session -> Disable Roomba integration (the lights turn off after a minute or so with my Roomba 6XX)

This of course is not a perfect solution (a perfect one would probably need to involve Roomba firmware developers and therefore likely require some kidnapping) but is an ok solution for my own scenario, which ultimately is just about cleaning the floor without turning my house into a matrix-inspired nightclub.

[Orhideous]

It's an upstream issue. https://github.com/pschmitt/roombapy/issues/270

[ilar]

No it's not, the issue isn't that the lights can't be controlled, the issue is that this code is connecting constantly and in ways that are completely unneeded- it's spamming the bot when it's really, really unneeded.

[asheroto]

No it's not, the issue isn't that the lights can't be controlled, the issue is that this code is connecting constantly and in ways that are completely unneeded- it's spamming the bot when it's really, really unneeded.

Indeed! You hit the nail on the head. The lights being on are a symptom of a bigger issue.

[ilar]

OK, SO. I've done a deep dive into the code. I see several problems.

First thing to know and understand is any time you connect to a Roomba's internal MQTT broker, the light on top will come on. There is, as far as I have been able to tell, no way around that for most models/firmwares. At the very least, it doesn't seem to be available for either my 690 or 670, and I've yet to see any dumps or reverse engineering of the app that includes those commands, e.g. dorita's lists of commands. I have not done so myself, primarily because you're not free to do that sort of thing in the land of the free without going to jail for eleven million years, and I have better things to do.

Anyway. Continuous mode, as you can imagine, is a continuous, uninterrupted connection to the roomba. It does not continuously reconnect, or constantly connect like some people believe. This leaves the light on constantly, but has no connection issues. All works as expected, except the light is forever on. I don't think there's much to comment on here.

Where things get interesting is non-continuous mode. How the HA integration thinks roombapy is behaving, how roombapy itself thinks it's behaving, and how the user thinks the HA integration is behaving, are all different.

And all of them are wrong.

So, lets dig into it. From what I've seen on forums, the user is under the impression non-continuous mode has the delay as the amount of time in between HA connecting, grabbing data, and disconnecting from the robot, and is confused when it does nothing noticable at all in either mode.

HA seems to think that roombapy, regardless of setting, can simply be kicked on and then it will take care of ensuring it's connected. Long term, HA will (I think, perhaps I just ended up restarting my server during all of this) eventually notice the 'unavailable's and starting kicking the roomba integration, but that can be any amount of time (I'm not familiar enough with HA to know when that kicks in, or if it can even be relied upon), but roombapy does not actually manage this.

Roombapy, meanwhile, thinks that the delay is simply how often it checks to see if it's still connected to the robot in non-continuous mode. It still attempts to always be continuously connected, it just now actually checks every now and then, and tries to reconnect if it's not.

You probably think that sounds backwards, and it's because they're poorly named, and there shouldn't even be a 'connect once ever without checking status again' option (continuous mode), in my opinion. Anyway, connecting to the robot is actually pretty robust- there usually isn't a need to reconnect, but frankly it should be checking anyway because that's how HA expects it to run. Why doesn't it work like that in non-continuous mode?

Because the delay function has a bug. Instead of CHECKING every 'delay' if we're connected- it simply hard connects every delay- which promptly causes an error 111 because the robot is already occupied with ourselves and the whole thing comes crashing down into a disconnect and stops working- because HA assumes roombapy manages itself, and the periodic connector gives up after 3 tries.

    def periodic_connection(self) -> None:
        """Periodic connection to the Roomba."""
        # only one connection thread at a time!
        if self.periodic_connection_running:
            return
-       self.periodic_connection_running = True
        while not self.stop_connection:
            try:
-               self._connect()
+               if not self.periodic_connection_running:
+                   self._connect()
+                   self.periodic_connection_running = True
            except RoombaConnectionError as error:
                self.periodic_connection_running = False
                self.on_disconnect(MQTT_ERROR_MESSAGES[7])
                self.log.warning("Periodic connection lost due to %s", error)
                return
            time.sleep(self.delay)

        self.remote_client.disconnect()
        self.periodic_connection_running = False

connect() checks if the connection is already running, but _connect does not.

So that's our first issue- continuous shouldn't exist, and non-continuous needs a reasonable delay to prevent spamming, but also to check before connecting.

Which brings us to the actual issue at hand- not being connected 24/7. Honestly, my opinion on this? The delay field should be set in the backend, lets call it 1-5 seconds. This isn't a server ping, this is just deciding how much CPU to use. Frankly, 30s would be fine as well.. That never needs touched by the end-user imo- as such, "Delay" needs removed from the integration UI. "Continuous" should change to mean what is currently the 'non-continuous' setup.

Non-continuous then means we connect only at certain times, which keeps the light off most of the time. So, lets consider two codepaths:

1. 'Cleaning Connection,' which is that we connect to the roomba, do a set of commands/setprefs if needed, and stay connected until it emits a 'docked' event. This is triggered either by manually firing a 'clean' action in HA, or on schedule, using the schedule we get from the roomba when we first connect to it. After all, when it's cleaning is when we want the most up-to-date info, and the light on top will be on anyway. This also preserves future integration options like live-mapping while cleaning.
2. 'Check-in connection', which is simply connect, issue any commands/setprefs needed, disconnect. This would be scheduled in the integration UI, which can keep things up-to-date without constantly having the thing lit up, and probably defaults to 4x a day or something? Or, alternately, you set it to zero and it never does a check-in without you hitting a 'sync' button on the modal, perhaps? Or is there a way to make opening the modal itself trigger an action? Not familiar enough with HA to know, I literally just started 2 days ago.

Regardless, the entities of the roomba won't particularly change on it's own other than schedules or physical interactions (and this is HA, we're not manually starting our roomba), so we don't need to stay connected to it to keep fairly good information imo. We won't have 'Unavailable' entities values either, because it can just keep the last known value.

roombapy needs fixed anyway, and I created a PR for that part, but does this sound like a potential path forward for the roomba integration in HA?

[ilar]

Thinking about this further, I think this could be neatly solved with home-assistant having a connect_until_docked(commands=[], set_prefs={}, seconds_until_check_docked=0) It would stay connected once docked an additional 5s just to make sure events are wrapped up.

At that point, Non-continuous mode could:

1. Connect just before a scheduled clean with connect_until_docked(seconds_until_check_docked=300, which would get information just prior to, and throughout, the entire cleaning process
2. Use connect_until_docked() at scheduled intervals to keep information up-to-date, but also catch on and stay connected during unscheduled cleaning events.
3. Use connect_until_docked(commands=[], set_prefs={}) to send any preferences or commands, while staying connected during unscheduled cleaning events.
4. Use connect_until_docked(commands=['clean'], seconds_until_check_docked=10) to kick off an impromptu clean.

That would, I think, cleanly handle all situations with the user-options:

• Always Stay Connected (will keep the upper light lit on your device)

And if that's unset:

• Check-in Interval In Seconds (0 never checks)
• Additional Check-in Interval In Seconds When Not Fully Charged (0 never checks)

The last would simply be check every X seconds if we are not at >97% charge and are charging. If so, do a quick connect_until_docked to get updated battery information. I can't think of any situations where this doesn't cover ensuring good data while not lighting it up all the time.

The only other addition I can think of is using some kind of scheduler instead of Check-in Interval In Seconds, or a blacklist when it shouldn't check, to ensure it doesn't light up at night, but I don't know enough about how home assistant forms are created to know if that's realistically possible with the built-in components- worst case, two time-pickers with 'blacklist start time' and 'blacklist stop time.'

[lubricatedcactus]

Thank you so much for your work on this @ilar. This intergration has been broken for a year and a half now and no one has been able to fix it. I hope your research leads to a cure.

[ilar]

Anyone know if there's anything I need to do re: the PR on roombapy? If pschmitt is busy I don't want to bother him, but I also want to make sure I didn't inadvertently e.g. flag it as draft or forget to assign it for review, for example. (and I did check those, that's not it lol)

I'm more used to gitlab than github, so I probably messed something up.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[lubricatedcactus]

I guess it could be great if someone had the skills to create a working version of this for HACS

[Write]

The PR in Question is : https://github.com/pschmitt/roombapy/pull/296

@ilar is there any reason you didn't keep up with answering the review ? Thanks for your findings.

[ilar]

I have a pending comment there- it's never been approved or something? So it doesn't show up.

EDIT: ah, aparently it wasn't pending approval, it was waiting for me to click 'finish review'.

[Write]

I have a pending comment there- it's never been approved or something? So it doesn't show up.

EDIT: ah, aparently it wasn't pending approval, it was waiting for me to click 'finish review'.

I'm guessing this doesn't fix the underlying issue? Thanks anyway.

[OkuuTheEngineer]

Just got an E5 today ans running into the same issue. Doesn't bother me as much, but it'll nag at me for a while.

[SirNanos]

Roomba 692 having this issue, it's also causing the battery to drain quite fast when off the dock. I am using Home Assistant Core 2024.8.2

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.